#ubuntu-devel 2005-08-01
<lamont> I can't kill things from the archive once they're there
<lamont> infinity: you around?
* lamont bets he's sleeping still
<ogra> Mez, konversation is up
<Mez> ty
<hughsie> ogra: email sent to maintainers of libnotify
<Burgundavia> ogra, I promised the inkscape developers that I would try and get .42 in Breezy, if I had to use my last dying breath, so I have to try. The majority of the inkscape devs use Ubuntu as well
* \sh will smoke the last cigarette for yesterday :)
<ogra> hughsie, wow, thanks :)
<ogra> \sh, to late :p
<\sh> ogra: i said yesterday ;)
<Mez> lol @ ogra's changelog
<ogra> its over :)
<Mez>    * bumped cdbs build-dep back to 0.4.21 to make backports happy
<Mez>      the "dont ask me again for KDE packages, how can a IRC client
<Mez>      be 7MB big ?" release
<\sh> ogra: i heard you and I will work on xorg today to give daniels some rest? ;)
<ogra> hehe
<\sh> spreading rumours...I had to close all private chat windows here because of your firefox sentence ,-)
<hughsie> ogra: http://www.interplace.com/gif/mrjihad.jpg
<hughsie> i just wet myself :-)
<ogra> heh
<\sh> ogra: and I thought daniels writes poetry in his changelogs ;)
<ogra> :) i try to keep up with him :)
<ajmitch> \sh: you'll have to start spicing up your changelo entries now that they'll be for main :)
<\sh> ajmitch: no problem...I will learn some new words from JaneW, afrikaans that is ;)
<ajmitch> hehe
* \sh is going to bed now...G'night everybody :) And again: thx a lot :)
<pitti> good night
<Nafallo> infinity: rock php5!
<hughsie> pitti, ogra: I've got to sleep now as I'm working tmw. If either of you two see daniels can you ask him about the dbus thing please.
<Mez> Backports announced: http://www.ubuntuforums.org/showthread.php?p=273253
<ogra> hughsie, sure, i'll do... have a nice night...
<hughsie> ogra: cool, thanks. See you guys tomorrow.
<ogra> yep, thanks for all the effort, night
<Mez> was that to me ogra?
<Mez> hmm, wow... It's even updated my xcaht vesion - we didnt backport that again
<ogra> Mez, nope, to hughsie
<Mez> ah
<Mez> :D
<Mez> w00t for official backports
<Mez> hehe :D
<Mez> ogra, can you link this topic in #ubuntu's topic
<Mez> http://www.ubuntuforums.org/showthread.php?p=273253#post273253
<Mez> wait
<Mez> I'll tinyurl it
<Mez> http://tinyurl.com/8f93v
<Mez> just add something regarding backports :D and point to that
<ogra> Mez, can you ask Amaranth or crimsun ? i'm about to go to bed
<Mez> ah kk
<Mez> if they're awake
<crimsun> (reading backscroll)
<ogra> Mez, there are more admins...
<Mez> kik
<Mez> crimsun, can you di it ?
<crimsun> sure, sec.
<Mez> ty
<|rockinnerd|> Hello, all. I am trying to do what is described here: http://componentizedlinux.org/Members/ghe_rivero/howtos_for_dummies/howto_dummies_part_1 with a hoary base from archive.ubuntu.com/hoary.  do you consider this a good idea to figure out how ubuntu and other debian-based systems work "under the hood"?
<Burgundavia> |rockinnerd|, progeny is not a normal linux distro. They are doing wierd and cool things
<|rockinnerd|> I'm basically doing what they say, but instead of using sid, i'm using hoary
<Burgundavia> you may break your distro, so don;t do that on your main box
<|rockinnerd|> ... and trying to figure out how anaconda works
<|rockinnerd|> Burgundavia, i'm working in a chroot environment, can i still break it?
<Burgundavia> no idea
<\mbp> |rockinnerd|: less likely, but still possible
<\mbp> depending on how much experience you have with such things
<\mbp> s///much less likely
<|rockinnerd|> Also, here's an idea: How about a Ubuntu Net installer? It can just debootstrap the base system (no x11) from the cd, and then launch Aptitude to allow people to configure exactly what is on their distro
<|rockinnerd|> thx Burgundavia and \mbp
<Mez> |rockinnerd|, I broke my comp with a chroot
<Mez> I linked /tmp into it so I could use X
<Mez> and managed to wipe it when I logged out of the pbuild!
<|rockinnerd|> huh.
<|rockinnerd|> btw does the archive.ubuntu.com/hoary have _all_ of the packages that are available to ubuntu, or just the bare minimum?
<crimsun> (that's more a #ubuntu question, but archive has the _official_ ones)
<|rockinnerd|> shit, it's trying to install over my base system
<Keybuk> sabdfl's alarm just went off for the TB meeting
<Keybuk> explains why he's always late ... :o)
<Burgundavia> rofl
<luis_> he using evo? ;)
<tseng> oh right, tuesday
<Mez> lol @ Keybuk 
<Keybuk> luis_: his strange phone contraption
<luis_> ah
<schweeb> daniels: hah, nice changelog on xauth
* Aegir eyes his freshly burnt Colony 2 CD
* Aegir puts a label on it before it gets lost in a pile of un-named CD's. A fate no linux distro deserves
<Mez> no CD does
<Mez> cept AOL
<TerminX> ugh, I upgraded today and now gedit won't work with files on mounted SMB shares
<Aegir> Hmm, interesting effect when the ink doesnt completly dry on the CD when you put it in the drive...
<Aegir> Atleast the ink's dry now...
<Aegir> BRB...
<Mez> lol @ Aegir
<jp> hi all
* lamont -> class
<Burgundavia> mdz, got another request for you. Sync screem from unstable. The current version (which is the same one in hoary) is very unstable and hangs frequently
<mdz> Burgundavia: send email to james@ubuntu.com, CC me, with rationale and subject [sync]  <package>_<version>
<Mez> Burgundavia, poke elmo for that :D
<Mez> lol
<Burgundavia> mdz, cheers, ok
<Mez> or not
<Mez> lol
<Burgundavia> mdz, the inkscape is coming as well
<mdz> Burgundavia: likewise for the other one
<mdz> Burgundavia: a strong rationale will include "I built and tested it on breezy and it fixes the issues with the current version"
<tseng> mdz: im guessing you are too swamped to fix up mythtv?
<Burgundavia> ok
<mdz> tseng: you would not believe me if I told you
<tseng> mdz: :/
<robertj> is dual-head autoconfig a goal for breezy/
<tseng> mdz: i can only imagine.
<tseng> mdz: ill see if i can make it go anywhere now that X is only slightly below unusable
<mdz> tseng: when I came home from travelling last week my house was full of water from a burst pipe
<tseng> oh man. were you in the hurricane area?
<mdz> no
<mdz> just bad plumbing and bad luck
<tseng> sorry to hear that.
<tseng> mdz: hm if breezy doesnt stab you in the back, it will get you in the front. mythtv died on X before, now its not a fan of GCC4
<mdz> tseng: I thought I had already changed it to build with g++-3.4
<mdz> it may be that the packages in my repository are newer than breezy
<tseng> mdz: hm didnt look at it super close. but it dies on some scary compiler warnings
<tseng> sh is the motu expert on those
<tseng> he likes to beat his head against them for hours on end
<mdz> perhaps he would like to take over maintainership of them ;-)
<daniels> he can take my gcc4 bugs
<bddebian> heh
<tseng> mdz: id take myth if the damn thing would build
<daniels> like the miscompilation of i810_drv (seemingly) that occasionally makes your video BIOS execute invalid code, but only on the first VBE run (so you have to reboot all the time to test), and not always
<bddebian> Is mythtv in main?
<tseng> of course not
<bddebian> I didn't think so, I was just thrown off by -devel I guess..
<bddebian> Sheesh
<tseng> we can talk about !main here w/o being stoned still :)
<daniels> holy shit
<daniels> so my panel has been working fine for weeks
<daniels> seb closes the bug last night
<daniels> 14381 daniels   25   0  135m  37m 9768 R 66.3  3.7   1:20.59 gnome-panel
<tseng> holy hell
<tseng> thats bigger than beagle
<bddebian> tseng: Where are you pulling mythtv from to build?
<daniels> tseng: my record is 2GB RSS
<tseng> bddebian: archive.debian.org
<tseng> bddebian: er, .ubuntu
<bddebian> Ohh
<bddebian> Just apt-get source?
<tseng> yes.
* bddebian updates his pbuilder first..
<daniels> bloody hell
<bddebian> I thought hell was hot, not bloody?
<bddebian> Heya tritium 
<tritium> hello bddebian, daniels
<daniels> tritium: morning
<WebWiz> is there a definition of 'a little less broken' :)
<bddebian> Uhm  < 'completely broken' ?
<lu|away> I booted a liveCD with the current X packages this afternoon.
<lu|away> it had some weirdness in driver detection
<lu|away> oh, and xrdb was missing
<lu|away> but otherwise, worked fine
<WebWiz> lu|away, wonderfull thanks
<lu|away> your mileage may vary :)
<WebWiz> i got a mkfontdir binary yesterday so i could get X working
<WebWiz> but now Breezy has its own mkfontdir right?
<WebWiz> i think the keyboard is still messed with breezy,  i hit alt-tab and nothing happens lol
<daniels> works for me
<bddebian> Is xmkmf missing/broken from something?
<daniels> missing
<bddebian> OK, thx
<bddebian> daniels: Did that get split from xutils in xorg?
<daniels> bddebian: it will, yeah
<daniels> in the meantime, it just doesn't exist
<bddebian> OK
<Speedy2> A quick question -- it seems that oddly libgcj4-dev depends on gcj3.3 instead of gcj4.0 .  Is this a bug?
<madclicker_> looking for 2.6.11 installer
<Speedy2> Also, according to this: http://archives.free.net.ph/message/20050701.004404.f6514e25.en.html , eclipse is in the repos, but I can't seem to find it
<bddebian> There are a few eclipse packages
<Speedy2> bddebian: In which repo?  I have universe/multiverse/backports enabled, but I can only seem to find eclipse-nls-sdk
<bddebian> I don't know for sure but a quick "apt-cache dump |grep eclipse" yeilds several
<Speedy2> This is what I get
<Speedy2> apt-cache dump | grep eclipse
<Speedy2> Package: eclipse-nls-sdk
<Speedy2>   Depends: eclipse-platform 2.1.2
<Speedy2> Package: eclipse-platform
<bddebian> Speedy2: Have you done an update recently?
<Speedy2> bddebian: Just a few seconds ago
<bddebian> Weird.  What archive are you using?  Just archive.ubuntu.com?
<Speedy2> That's the first one in the sources.list
<bddebian> I mean, not uk.archive... or us.archive.. ?
<Speedy2> Correct, no country archive specified
<bddebian> Speedy2: Strange.  I don't know, sorry
<bddebian> wb crimsun 
<crimsun> danke bddebian 
<mdz> Speedy2: it's in breezy/universe
<Speedy2> mdz: I'm using Hoary.  I assume it wouldn't be a good idea to install from breezy, eh?
<mdz> Speedy2: depends entirely on your comfort
<bddebian> Ooohh, Hoary, duh.
* bddebian just blindly uses breezy and doesn'tthink
<Speedy2> mdz: Is the Eclipse in Breezy compiled with gcj ? (how complex is that really?)
<mdz> Speedy2: yes it is
<Speedy2> Well, I'll give it ago, what the hell!
<fabbione> morning
<bddebian> Hello fabbione 
<Speedy2> bddebian: I added breezy universe, which other repositories would I need to satisfy eclipse-platform's dependencies?
<bddebian> Speedy2: You are adding breezy universe to a Hoary install?
<Amaranth> Speedy2: main, multiverse, and restricted
<Speedy2> Amaranth: Thank you
<Speedy2> bddebian: For eclipse.  I'll watch what it installs
<Amaranth> Speedy2: I hope you don't like X.
<Speedy2> Amaranth: eclipse-platform requires libs that bork breezy?
<Amaranth> Speedy2: I just told you to fully upgrade to breezy and you didn't even notice. I think you should wait.
<bddebian> How can I tell what repo apt is getting a package from ?
<bddebian> Without installing that is :-)
<crimsun> apt-cache policy $package
<bddebian> Thx crimsun 
<crimsun> np
<lamont> infinity: you around?
<Speedy2> A program I'm compiling is failing, missing "ansidecl.h" -- what set of headers would that be in?  I haven't found it
<bob2> what are you compiling?
<bob2> that doesn't appear to be in ubunt
<Speedy2> bob2: I'm cross-compiing GCC for an ARM target
<bob2> that sounds like something from the gcc source
<Speedy2> It fails with: "ake[1] : *** No rule to make target `../include/ansidecl.h', needed by `regex.o'.  Stop."
<bob2> you're using toolchain-source?
<Speedy2> bob2: Correct
<jasoncohen> when can i expect a patched mozilla thunderbird package for hoary? It's been nearly two weeks. 
<jasoncohen> and will it have it's security updates backported- or will the upstream version be packged?
<jasoncohen> *packaged
<jsgotangco> jasoncohen, its always security update backported
<bob2> except firfox
<bob2> which is now 1.0.6 in hoary-sec
<jsgotangco> bob2, the latest update is a new package you mean?
<jasoncohen> bob2, that's what i expected. any idea what's holding back the thunderbird backport?
<jasoncohen> *thunderbird security fix backport from 1.0.5
<jasoncohen> i think the same issues might occur with thunderbird though since 1.0.5 made API changes requiring 1.0.6 to fix extensions
<bob2> jsgotangco: no, the latest update is just 1.0.6
<jasoncohen> well, backports has now officially transitioned to ubuntu servers. the package naming changed as well
<jasoncohen> quit nice- fast download speeds + the packages are signed 
<Speedy2> bob2: I think I got it -- I had to create a build directory seperate to where gcc4.0 was extracted
<jasoncohen> ah, cool and now backports has source
<bob2> yay for not violating the gpl!
<pitti> Morning
<daniels> 2/win 122
<fabbione> elmo: can you please install:
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: kernel-wedge (>= 2.05ubuntu2) linux-headers-2.6.12-4-amd64-generic linux-headers-2.6.12-4-amd64-k8 linux-headers-2.6.12-4-amd64-k8-smp linux-headers-2.6.12-4-amd64-xeon libxxf86vm-dev
<fabbione> on concordia breezy chroot
<daniels> dooooomed
<daniels> tseng: package ifolder kthx
<daniels> argh, I suck
<daniels> so I was working on xauth while very tired
<Treenaks> </oldnews>
<daniels> and the code had #ifdef SIGALRM all through it
<daniels> so I put in autoconf checks to see if SIG{HUP,PIPE,ALRM} were defined
<daniels> if so, AC_DEFINE(SIGALRM, 1, [Has SIGALRM] )
<daniels> the upshot of this is that xauth sees the signal numbers for ALRM, HUP and PIPE to be 1
<daniels> and that I didn't need to put those checks in at all
<daniels> headdesk
<sivang> morning all
<sivang> morning pitti 
<pitti> Hi sivang 
<sivang> pitti: how are you?
<pitti> sivang: very secure :-)
<mvo> hehe
<mvo> good morning btw :)
<pitti> Hey mvo
<mvo> hello pitti, thanks for cleaning up after me for vim
<sivang> mvo: you created security holes that pitti cleared? :)
<pitti> no, just an obsolete patch
<sivang> pitti: ah, cleaning obsolete patches is probably always good
<pitti> mvo: bad that the build doesn't fail because of that in the first place
<mvo> pitti: *nod*
<sivang> daniels: what's SIGALRM means?
<Treenaks> sivang: it's the signal that gets sent by alarm(2), for example
<sivang> daniels: what use does xauth do with SIGALRMs ? 
* Treenaks guesses that xauth does a lot more than most people expect
<pitti> fabbione: is it legitime for a postinst/postrm to fiddle with /etc/modules?
<pitti> fabbione: i. e. add or remove something to/from it?
<fabbione> pitti: /etc/modules is a config file.. you treat it as any other config file
<infinity> lamont : Ugh, been sick all day and out of it.  Sorry.  Did you need me? :/
<comadreja> fabbione: kismet and wpasupplicant stopped working with -4 kernel 
<comadreja> fabbione : I have a ipw2200
<fabbione> comadreja: read the changelog
<fabbione> it's not a bug
<fabbione> it's on purpose
<comadreja> oh, thanks
<fabbione> either a working stable driver with less features
<fabbione> or a broken ipw2100 and unstable ipw2200
<fabbione> what would you choose?
<fabbione> :)
<comadreja> I've got a ipw2200 ... hehe the unstable 2200 :D
* Treenaks is with comadreja on that one ;)
<comadreja> I need wpasupplicant
<fabbione> it might come back in the next kernel if i get enough people to test the ipw2100
<fabbione> in the mean while stable > *
<comadreja> that's ok, I'll keep -3 meanwhile, no problem
<Treenaks> which version of ipw2200/ieee80211 was in -3?
<comadreja> how do I know ?
<comadreja> I'm running it now
<Treenaks> comadreja: check dmesg output? maybe it tells you?
<Treenaks> (I removed the old one, so I don't have the changelog?)
<fabbione> Treenaks: check the changelog
<fabbione> it's all documented there
<fabbione> i don't write KB of changelogs for nothing
<fabbione> iirc -3 had 1.0.4
<comadreja> 1.0.4 yes
<comadreja> latest is 1.0.6
<Treenaks> fabbione: the changelog for -3 is also in -4?
<comadreja> just below
<Treenaks> a
<Treenaks> ah
<pronik> can anybody help me to workaround xorg bugs?
<Treenaks> pronik: promise more beer to daniels, and they'll be fixed ;)
<Burgundavia> daniels is also working on an email to get everybody up and going
<Burgundavia> so the best answer is to have patience
<pronik> Treenaks: I can promise, but he's too far away I guess
<pronik> But does "Error loading new keyboard description" mean what I think it means - he can't find or parse keyboard definitions?
<pronik> I've also lost all terminal colors - both rxvt and xterm complain "can't get colour 'Black', continuing without"
<pronik> Burgundavia: where will this e-mail get posted to?
<Burgundavia> pronik, probably ubuntu-users
<fabbione> Treenaks: tsk!
<fabbione> :P
<fabbione> of course.. the changelog is always there for historical reasons
<fabbione> exactly because of what you are trying to do
<fabbione> Treenaks: if it is not detailed enough.. let me know
<Treenaks> fabbione: no, I'm stupid, sorry :)
<Treenaks> fabbione: I need to read first, ask questions later :)
<fabbione> Treenaks: ok thanks.. you took away from me the worst task of making you aware of that :P
* fabbione adds a few coolness point to Treenaks
<\sh> hmm
<\sh> I think I have to work from the debian version...
<\sh> why is ostingGeek [~HG@200.48.233.220.exetel.com.au] 
<\sh> banned?
<azeem> did you ever meet him?
<Burgundavia> \sh, trust me, it is for a good reason
<ogra> \sh, because he is _most_ annoying
<\sh> ogra: k...only wanted to know :)
<Burgundavia> \sh, he has been banned from one other channel I follow (#openttd) and they are thinking about it doing it on another (#inkscape)
<ogra> \sh, we kept him in -moto as a channelpet ;)
<ogra> \sh, ... and because i never giveup hope on people :)
<Burgundavia> seb128, I swear this totem-video-thumbnailer bug was fixed, but I cannot find the upstream bug report --> http://bugzilla.ubuntu.com/show_bug.cgi?id=12991
<\sh> ogra: u r a good guy :)
<seb128> what bug?
<seb128> oh, that
<ogra> \sh, sometimes i think i'm rather a silly guy... especially in case of HG :)
<seb128>      - don't thumbnail files constantly if they're changing (Ubuntu: #1573).
<seb128> from 2.11.1 change
<\sh> ogra: believe me...if you'd received my phone call this morning, concerning the funeral of my grandma...u won't think like this anymore 
<Burgundavia> seb128, thanks
<mdke> tseng, around?
<seb128> I've closed the bug
<Burgundavia> yes
<sivang> ogra: dhlobach is like you , not giving up on people :)
<ajmitch> evening all
<hughsie> pitti, ogra: ping?
<pitti> Hi hughsie 
<hughsie> pitti, hi. 
<hughsie> pitti, I've got the libnotify maintainer to release libnotify tomorrow as 0.0.1
<hughsie> is that too late for freeze?
<pitti> hughsie: what do you need it for?
<ogra> hughsie, i dont think so, since seb128 wanted to package it anyway
<hughsie> well, don't /need/ it per-se, but gnome-power-manager picks it up if it's insalled and looks a whole lot nicer
<seb128> pitti: gnome-applets can use it too
<ogra> pitti, it shows notification messages from the system tray...
<pitti> ograI know, it sounds interesting
<ogra> hi hughsie btw :)
<hughsie> ogra: hi :-)
<hughsie> did either of you guys speak to daniels?
<seb128> pitti: we want it anyway, so not a big deal to upload it and give it a shot
* ogra is just struggling to get the hwdb patches into hal again...
<pitti> seb128: sure, merely adding a library can't break much
<hughsie> pitti, famos last words... :-)
<hughsie> ogra: what is is you guys do to hal-device-manager anyway?
<seb128> pitti: oh, and upstream has delayed eggcups to 2.14 for the desktop ... we are free to use it, but not forced.
<ogra> hughsie, device manage only has a sall change (a button to run hwdb-client)the worse stuff are the changes to hald it needs :)
<hughsie> ogra: i guess. it's a bit fedora in places
<ogra> hughsie, i have one that could go upstream as soon as i can myke it apply (lsb release data in the computer device)
<hughsie> ogra: you sure davidz wouldn;t accept upstream patches
<hughsie> oga: ignore :-)
<ogra> hughsie, not all of them.-...
<ogra> hughsie, my dmidecode patch is ugly, i wouldt want it upstrema, i only need the data for hwdb...
<Burgundavia> I need an ftp that needs login to test a bug, anybody got one that I can test?
<hughsie> ogra: gotcha. spoken to daniels?
<ogra> hughsie, the /proc/cpuinfo and /proc/meminfo patches might clash with your acpi patches, havent tried them yet
<hughsie> ogra: should be okay... but davidz might not like all the extra nodes
<ogra> hughsie, nope, he was already away when i started my day...
<hughsie> bolocks
<ogra> hughsie, i'll try to merge devices in hal... else we'd have two processors in there...
<hughsie> ogra: sounds good :-)
<ogra> hughsie, since you have the acpi processor data and i have the /proc/cpuinfo data :)
<hughsie> ogra: post it upstream and see what davidz says
<ogra> hughsie, yes, but first they need to apply again ;) its all written for 0.4.7
<hughsie> 0.4.7, ouch
<ogra> and i have to get them in before 11th
<hughsie> 0.4.7 is very different to 0.5.3
<pitti> mozilla
<hughsie> you've the whole linux -> linux2 restructuring
<ogra> yes, but i wrote them all as separate files so its mostly only copying them to linux2 and make the matching changes to osspec.c
<hughsie> ogra: okay, not the end of the world then.
<ogra> nope, just eats time *sigh*
<hughsie> ogra: could you try to package CVS g-p-m on ubuntu? See what your patches clash with.
<ogra> hughsie, arent the g-p-m patches already upstream ? 
<ogra> (the hal side )
<hughsie> ogra: the help file and stuff, yes
<ogra> so mine shouldnt clash ...
<hughsie> ogra: ohh, you mean the events support or the battery.* devices?
<ogra> hughsie, nope i mean the processor device you create in hal.... from the /proc/acpi data... i create a processor device too but from /proc/cpuinfo
<hughsie> that was in 0.5.2 i beleieve
<ogra> yes, thats where i'm porting them to
<hughsie> couldn't your patch just add into acpi.c into the processor_refresh lump?
<ogra> what if a system has no acpi support ? will your processor device in hal exist ?
<hughsie> no.
<ogra> so mine have to override this...
<ogra> since /proc/cpuinfo will always be there
<hughsie> yes, but you can still try to search for the node based on capability or something
<hughsie> you could add if found, create and add if not found
<ogra> something like that...
<tseng> daniels: dude, ifolder is like 4 packages
<ogra> ifolder is crack
<ogra> (but daniels loves crack, we all know this :) )
<hughsie> I need daniels to look at dbus 0.35 for me
* tseng shudders
<ogra> hughsie, he sits in .au ....
<hughsie> ogra: I know, but he should be using GMT :-)
<ogra> hughsie, naah, we all live with UTC here ;)
<hughsie> ogra: okay, but my g/f idn't going to like it :-)
<ogra> hehe
<ogra> as long as you convert hr too everything is fine :)
<hughsie> ogra: I'll let you tell her that. I have to shower and get to work. Catch you guys later
<ogra> its just that you loose all your other friends... but you win a wonderful community on IRC ;)
<hughsie> lol
<ogra> hughsie, i'll poke daniels about dbus 0.35 if he's around
<ogra> meh
<\sh> damn...all the merges are loosing the cxx trans stuff
<ajmitch> \sh: they shouldn't if done right
<ajmitch> got an example?
<\sh> ajmitch: well...if everything works fine, no dropped patches yes..
<ajmitch> \sh: whoever does the merges has to watch for dropped patches..
<\sh> ajmitch: yes :) 
<ajmitch> or whoever reviews the prospective MOTUs work ;)
<\sh> ajmitch: what I'm doing here? ,-)
<ajmitch> hey I have been helping a little :)
<jsgotangco> bye guys i have a dinner appointment :)
<jsgotangco> see you guys later
<ogra> have fun
<ajmitch> bye 
<maswan> fabbione: we now have the rsc configured, so we should be able to reboot buttercup more quickly. :)
<maswan> fabbione: also, do you know if the watchdog support would be worth enabling, or will linux go nuts about it?
<fabbione> maswan: yo..
<fabbione> maswan: nice.. i think the watchdog support works fine
<fabbione> it's worth a try
<fabbione> maswan: Trave11er reported the 2.6.12 from ubuntu boots
<fabbione> so it might even be worth upgrading
<fabbione> but i don't feel comfortable in rebooting it without console :)
<sivang> fabbione: have you gotten successful reports about installing breezy (2.6.12) on a pSeries machine yet?
* mvo curses at his network provider
* ogra adjures pitti to go online again...
<fabbione> sivang: yes one.. i think
<fabbione> there was one bug that has been fixed.. so i guess it should all work by now
<ogra> mvo, complain at \sh, its all his fault ;)
<sivang> fabbione: oh goody. Was it fixed upstream?
<fabbione> sivang: it was a problem with the installer
<fabbione> the kernel should be ok
<fabbione> sivang: just test it and report..
<fabbione> you have such a machine.. i don't
<sivang> fabbione: ok, should I grab a new daily installer image?
<fabbione> yes
<sivang> fabbione: /me is on to it. Thanks
<mvo> ogra: I will if he is around. I'm connected with isdn right now because the cable modem does no longer get a connection
<ogra> mvo, \sh  just came back.... ;)
<sivang> fabbione: btw, where can I which bug was fixed? where are the changlogs for such a thing?
<\sh> lol
<\sh> mvo: u r 1511?
<ogra> \sh, DO
<ogra> :)
<\sh> yay...nobody from HSI support
<\sh> ogra: yes...1511 ;)
<maswan> fabbione: Well, I'm on campus now. :)
<fabbione> maswan: when are you going back to the campus again?
<fabbione> i am sort of busy today to play with buttercup
<fabbione> (it's building since you bring it up again yesterday ;))
<maswan> fabbione: Well, I should be working this and next week, so
<maswan> fabbione: after that I'll be further away from connectivity
<fabbione> maswan: perfect! i will ping you tomorrow if you don't mind too much
<fabbione> yeah next week i will start VAC :)
<baggins> Hi there. I'm interested in writing/helping write a X.org configuration tool.
<maswan> fabbione: sure
<fabbione> maswan: thanks a lot
<carstenh> azeem: i just read your comment on the firewall gui (using /lastlog firewall). sounds good, i will think about pros and cons of that idea. thanks.
<ogra> Kamion, ping
<carstenh> azeem: but i guess we will not change our plans about that. we will see :)
<Kamion> ogra: pong
* Kamion fixes up a bunch of default Bugzilla component assignments
<Kamion> minor details like assigning gcc to doko
<ogra> Kamion, have a look at http://vljubovic.members.epn.ba/ldseed.txt, does that look ok for you ?
<doko> heh, I did clean up the gcc reports two days before :-/
<ogra> Kamion, its for the Lightweight Desktop bounty
<Kamion> ogra: I don't understand why there's an "ubuntulite-icewm" that "includes icewm, icepref and rox-filer"
<ogra> oh, yes.. i overlooked that... vedran ?
<vedran> it also does some configuration
<ogra> vedran, could you split that into the single packages ?
<vedran> well just use regular packages :) but ubuntulite-icewm configure icewm to use rox-filer as desktop
<Kamion> ogra: console-tools and usbutils are both in minimal and shouldn't be in the lightweight-desktop seed too
<ogra> vedran, ^^^^
<vedran> ok i'm logging ;)
<Kamion> presumably this seed would depend on standard
<ogra> yes
<Kamion> otherwise it doesn't seem too bad
<Kamion> I haven't run germinate over it to work out the size
<Kamion> perhaps somebody else could do that; more people need to get used to using germinate
<Kamion> you'll need to grab the breezy seeds, drop this new seed into them, edit STRUCTURE accordingly, and use germinate's -S switch to point it at your local seeds
<\sh> does anybody have problems mit libXrender.la on amd64?
<vedran> Kamion: I can't do that until tommorow :(
<ogra> vedran, that'd be enough...
<ogra> vedran, we just have to have it done until your SoC time is over
<ogra> which is aug. 11th ? if i'm not wrong... so plenty of time
<Kamion> there's a germinate package in breezy which will be suitable for that
<vedran> ogra: sep 11th afaik :)
<ogra> oh
<ogra> even better :) (i already felt in a rush)
<vedran> Kamion: any idea how to properly solve the icewm/rox integration? (it's just one file in /etc)
<Kamion> vedran: doesn't rox-filer register itself with the x-session-manager or x-window-manager alternatives (whichever's appropriate)?
<Kamion> alternatives would be the usual way to solve this
<ogra> it will require some small changes to the package if its not using the alternative system yet
<ogra> (but it already should do it)
<vedran> Kamion: i'm not sure that would do it, it needs to be added to icewm session
<vedran> that is, icewm starts rox-filer as its desktop (the thing with icons)
<vedran> its already done in xfce, i need to look how
<Kamion> what does icewm do for its desktop in its default configuration?
<Kamion> as packaged
* ogra guesses nothing
<vedran> nothing iirc
<\sh> ogra: can u do me a favour? or are u extensivly busy? :)
<ogra> \sh, the latter... 
<ogra> what would be the favor
<ogra> ?
<\sh> ogra: apt-get source grip
<Kamion> vedran: does it have any kind of directory into which packages can drop session entries?
<ogra> \sh, done
<\sh> and check in your amd64 pbuilder if it builds..or if it throws a nice libXrender.la error...if yes, please put an autotools dance in the rules file in the configure target and rebuild it again
<\sh> I don't want to use the buildds again for testing ,-)
<\sh> in the meantime I'm trying to help mvo more
<Kamion> vedran: also, let's say somebody (not using your configuration) was running icewm and installed rox-filer. Would they want it to set itself up as the icewm desktop?
<ogra> \sh, pbuilder running
<vedran> Kamion: thats the problem, i'd like people to say something like "apt-get icewm-roxfiler-desktop" and get all preconfigured
<\sh> thx man...short away
<vedran> Kamion: icewm session is just one script, not directory, and needs to be placed in /etc/skel
<TWD> Is anyone working on the DialUp Support goal atm? 
<ogra> \sh, libtool: link: cannot find the library `/usr/lib/libXrender.la'
<Kamion> vedran: (I'd be happier with a name like icewm-roxfiler-desktop than with ubuntulite-icewm, FWIW; it describes more clearly what it does, and it's more branding-friendly)
<Kamion> vedran: /etc/skel??? gross
<ogra> rather ugly :)
<Kamion> vedran: please try to make that site-wide configuration instead
<Kamion> see Debian policy 10.7.5 for rationale - /etc/skel is difficult to support correctly
<vedran> Kamion: ok I've found a better way :) I'll make a fixed package tommorow
<Kamion> cool, thanks
<fabbione> doko:   curl_7.14.0-2ubuntu1: successful
<doko> heh, nice
<\sh> ogra: can u put in the rules file a aclocal-1.x automake-1.x and autconf and libtoolize? I'm just curious..cause on all other archs it worked
<ogra> \sh, later thi evening... i'm curretly very busy getting my hwdb patches into hal
<\sh> ogra: np
<\sh> ogra: actually I'm w8ing for Mithrandir to reactivate my account
<Kamion> http://lwn.net/Articles/145024/#Comments <- "Ubuntu's parallel startup is the worst"
<Treenaks> it is?
<bob2> it has parallel startup?
<Kamion> claiming that starting gdm early isn't really a win because there's so much else going on
<Kamion> and that something that starts after gdm screws up X
<tseng> well they should test it
<Kamion> read the article - it's somebody saying that from experience
<ogra> hmm, i have to try runlevel 3 ;) never booted into this *g*
<infinity> 'tree' isn't in main?... My life may come to an end.
<bob2> if only you had upload priveleges!
<infinity> I do, but this is about seeds.
<seb128> doko: around?
<seb128> grrrrr
<infinity> I guess it's time to write a MainInclusionReport for tree!
<seb128>  firefox (1.0.6-1ubuntu2) breezy; urgency=low
<seb128>  .
<seb128>    * Don't ship firefox-dev with firefox-nspr.pc and firefox-nss.pc.
<seb128> 
<infinity> Cause, y'know, installing from universe makes me a sad panda.
<doko> seb128: yes
<seb128> that breaks epiphany-browser ... why this change?
<seb128> it FTBFS now 
<doko> because the headers are not in the package
<ogra> seb128, because we dont like epiphany  :)
<ogra> pitti, !!!
<seb128> doko: ?
<pitti> Hi
* bob2 pittis the fool
<seb128> doko: please put that back so epiphany-browser can build
<doko> there is no /usr/include/firefox/nspr directory in the package
<doko> seb128: no, it makes OOo2 FTBFS
<seb128> firefox-dev: /usr/include/mozilla-firefox/nspr/nspr.h
<ogra> pitti, i reworked the lsb_release patch .... are you fine if i send it to you wit a patched Makefile.am and you do the automake patch again ?
<seb128> includedir=/usr/include/mozilla-firefox
<seb128> Cflags: -I${includedir}/nspr
<seb128> 
<seb128> doko: that's before your upload ... what's wrong with that ?
<doko> seb128: ehh, since when are these included? is libnspr.so there as well?
<pitti> ogra: sure
<ogra> pitti, indeed only in the end if all my patches re in again...
<seb128> doko: for ages
<ogra> pitti, i also sent it upstream... curious if david will accpt it :)
<doko> seb128: definitely not ...
<ogra> pitti, thanks :)
<pitti> ogra: I doubt it, but let's hope :-)
<seb128> doko: the package has not changed for months ...
<ogra> pitti, come on, the lsb patch is non intrusive and its a nice feature for lsb based distros :)
<seb128> doko: anyway this .pc is right, it points to existant .h files so please revert your change
<pitti> ogra: you have to convince David, not me :-)
<ogra> pitti, i know :)
<ogra> pitti, i must admit i dont really care, i sent it to the ML... if he likes it, ok. if not i'm still fine :) i wont put time into discussing it with him :)
<doko> seb128: the nss headers are still missing
<doko> seb128: the .so links are missing. this is just wrong. keep the files out, fix epiphany-browser please
<seb128> grrr
<seb128> I'm going to change firefox myself
<fabbione> elmo: ping?
<seb128> I've enough to do with GNOME atm without getting that b0rked
<doko> seb128: please don't. this IS WRONG!
<elmo> fabbione: ?
<crispin> doko: the firefox-xpcom .pc file depends on firefox-nspr ....
<Treenaks> elmo: did you see my mail re: upload rights?
<fabbione> elmo: did you install the B-D on concordia?
<doko> seb128: that's not right way. reverting a fix, because you say you don't have time to fix your packages
<elmo> fabbione: eh, what b-d?
<elmo> Treenaks: yes, I haven't had a chance to look yet
<fabbione> elmo: ok.. just a sec. i will grab the list again
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: kernel-wedge (>= 2.05ubuntu2) linux-headers-2.6.12-4-amd64-generic linux-headers-2.6.12-4-amd64-k8 linux-headers-2.6.12-4-amd64-k8-smp linux-headers-2.6.12-4-amd64-xeon libxxf86vm-dev
<seb128> doko: this is not a fix, the browser are built with firefox and these files are needed
<fabbione> elmo: these ones...
<fabbione> concordia breezy chroot please :)
<seb128> doko: is some .so are not listed by the package put them here, that's the fix
<fabbione> elmo: it was probably lost in the scroll back.. nothing too important
<seb128> doko: dropping files is not fixing anything, it's just running away and breaking other packages
<doko> seb128: no, you have to use the things provided by libnspr-dev and libnss-dev.
<seb128> I don't want to build with mozilla
<doko> seb128: you do want to build with libnspr-dev and libnss-dev
<seb128> no, that's mozilla
<doko> seb128: it is
<seb128> I don't even have these packages installed
<doko> seb128: currently you _pretend_ to build with firefox
<doko> so where do you get the nspr and nss libs from?
<seb128> typo
<seb128> anyway I don't want to build with /usr/lib/pkgconfig/mozilla-nspr.pc
<seb128> but with /usr/lib/pkgconfig/firefox-nspr.pc
<pitti> seb128: would it help if firefox produced libnspr instead of mozilla?
<doko> pitti: yes, it would
<seb128> pitti: sure
<pitti> seb128: we need to do that anyway if we want to demote mozilla
<seb128> which is correct fix
<seb128> not what doko is doing
<pitti> that would be a pretty severe deviation from Debian, but oh well...
<seb128> that's the only way to move mozilla to universe anyway
<doko> seb128: you use the mozilla libs and the firefox libs. THATS CRAP!
<pitti> seb128: but still, I don't see the problem of build-depending on libnspr-dev, regardless of which source package produces it
<seb128> doko: read again what I said
<doko> seb128: typo: you use the mozilla libs and the firefox headers
<seb128> doko: make firefox build these packages instead of dropping the .pc
<pitti> btw, I don't know what doko is doing, I didn't follow that
<seb128> pitti: it's dropping firefox-dev .pc files which breaks epiphany
<seb128> s/it's/he's/
<ogra> pitti,    * Don't ship firefox-dev with firefox-nspr.pc and firefox-nss.pc.
<ogra> last upload iirc
<seb128> doko: 
<seb128> $ ldd /usr/bin/epiphany  | grep firefox
<seb128>         libgtkembedmoz.so => /usr/lib/mozilla-firefox/libgtkembedmoz.so (0xb7fb0000)
<seb128>         libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7eff000)
<seb128>         libplds4.so => /usr/lib/mozilla-firefox/libplds4.so (0xb7efb000)
<seb128>         libplc4.so => /usr/lib/mozilla-firefox/libplc4.so (0xb7ef6000)
<pitti> doko: does libnspr4-dev have the .pc file?
<seb128>         libnspr4.so => /usr/lib/mozilla-firefox/libnspr4.so (0xb7ec4000)
<doko> pitti: the libnss.pc file is referencing /usr/include/firefox/nss, which is not there, and it references /usr/lib/libnss.so, which is not provided by this package
<seb128> $ ldd /usr/bin/epiphany  | grep mozilla | grep -v firefox
<seb128> $
<pitti> seb128:  libnspr4.so => /usr/lib/mozilla-firefox/libnspr4.so (0xb7ec4000 <- that's SOO wrong
<doko> pitti: yes, but seb128 does not want to use it
<seb128> pitti: why?
<seb128> doko: where am I using mozilla libs?
<pitti> seb128: libraries belong into /usr/lib, and once we change libnspr4-package, we expect that packages using it get the fix as well
<pitti> seb128: otherwise we quietly duplicate libs, which is evil 
<doko> pitti, seb128: I'm forwarding you a mail I sent to the Debian mozilla and firefox maintainers. The best way would be to build the libs from it's own source and make the other packages use them
<infinity> seb128 ; They're compatible libs anyway, or they bloody well better be if the SONAME is the same, so why do you care if you link to the public ones (from Mozillaa) or the private ones (from Firefox), except that the latter is JUST PLAIN SICK AND WRONG...?
<pitti> doko: that's exactly what I had in mind, I just look whether this is possible
<pitti> doko: seems easy, subdir nsprpub/ even has its own configure
<seb128> infinity: building with firefox or mozilla doesn't give the same behaviour, I guess there is a difference somewhere
<doko> pitti: yes, nss is the problem
<pitti> seb128: that's a bug then
<seb128> pitti: what? firefox and mozilla are different ...
<pitti> seb128: right, but libnspr4 should behave the same
<infinity> seb128 : The browsers are, but those libs shouldn't be..
<elmo> fabbione: done
<seb128> crispin: heeelp :)
<seb128> crispin: what does change when you build with firefox or mozilla ?
<crispin> lots and lots of things :-)
<doko> http://ftp.mozilla.org/pub/mozilla.org/nspr/releases/
<Kamion> oh, hi crispin
<doko> http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/
<crispin> hi Kamion 
<doko> pitti: ^^^
<seb128> crispin: why if the libs are the same? :)
<pitti> doko: yay
<crispin> I don't know the details of the nspr changes, but certainly an epiphany built against ff won't work against mozilla libs
<doko> I wanted to start these, but currently ENOTIME
<pitti> crispin: it's not building against FF, it's building against the basic nspr lib
<crispin> the nspr bits might be compatible between ff and mozilla, but there is no guarantee
<pitti> crispin: if they aren't that would be abug
<infinity> I could see that for xpcom and gtkemebdmoz
<crispin> certainly the libgtkmozembed.so in ff and mozilla _are_ different
<infinity> But nspr and nss should be identical.
<pitti> crispin: for sure
<doko> crispin: but we currently use firefox's nss headers. so we already are wrong
<crispin> besides, the .pc files in the current ff package are screwed
<seb128> what .pc? doko just droped them :p
* Kamion goes to drive his fiancee to a dress fitting; back in an hour or so
<crispin> firefox-gtkmozembed (which is what ephy uses) depends on firefox-xpcom, which depends on firefox-nspr (which isn't there)
<doko> Kamion: you stay, or do you work some hours until you drive her back? ;-)
<Kamion> stay there, but it shouldn't take that long; the dress has already been selected :)
<fabbione> elmo: thanks
<seb128> crispin: so what is to change?
<crispin> seb128: hmm, well I suppose in theory if the firefox-dev package was made to depend on libnspr4-dev and the .pc files were fixed, that might work, but I doubt anyone has tried that
<infinity> crispin : Right, and it should be ffox-gtkmozembed -> ffox-xpcom -> moz-nspr, as far as I can tell.  nspr has no need ot be duplicated.
<carlos> mjg59_, hi, around?
<pitti> infinity: upgrading from warty's ffox is a mess, but I'm slowly making progress...
<pitti> infinity: how's tbird?
<crispin> infinity: yeah, that might work, but I wouldn't like to make any guarantees
<rtcm> seb128: shouldn't gnome-smproxy be removed from /usr/share/gnome/default.session now that it is deprecated upstream? should i file a bug about it?
<crispin> we (galeon/epiphany) have _a lot_ of trouble with ff / mozilla API changes 
<pitti> infinity: btw, in warty the new ffox breaks all the locale packs, could you please check that for tbird as well?
<infinity> pitti : Oh, ouch, I hadn't thought of langpacks.
<mjg59_> carlos: Hi
<seb128> rtcm: good catch, please fill a bug, thanks
<pitti> infinity: not the langpacks itself, mozilla-firefox-locale-* in my case
<carlos> mjg59_, daf told me that perhaps you could help me a bit with a problem I have with my Lenovo X41 battery
<pitti> carlos: btw, any ETA on the translation tarball? if I don't finish that by friday, seb128 eats me for breakfast
<infinity> pitti : Are those not geenrated from the same sou-- Oh, no, they're not.  Suck.
<crispin> oh, and of course ff-dev should drop the nspr headers if it changes the pc files and dependancies :-)
<mjg59_> carlos: I can try...
<carlos> pitti, I was offline yesterday but I had it more or less working, got a problem and had to leave so I hope you will have it today (if the script finish on time, if it takes more time, tomorrow morning)
<pitti> infinity: $ grep 'Package: mozilla-thunderbird-locale' /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_warty_main_binary-i386_Packages
<pitti> [warty]  martin@donald:~$
<carlos> mjg59_, I got it last week and I'm not able to use it without the power plug for more than 1 hour and a half 
<pitti> infinity: lucky you
<bob2> what's up with http://cdimage.ubuntu.com/dvd/current/ only having amd64 stuff?
<carlos> mjg59_, and the laptop mode is on
<Amaranth> bob2: openoffice2 deps
<Amaranth> err, wait
<infinity> pitti : They're in universe.
<pitti> infinity: that's why I said "lucky you" :-)
<Amaranth> language-support-en depends on something from openoffice but the openoffice2 package conflicts with that one
<bob2> cdimage.ubuntu.com seems to have a bunch of issues
<bob2> is that elmo or Kamion country?
<doko> crispin: nss should be built from which source?
<infinity> pitti : We have the green light to break universe packages willy-nilly with these updates?
<Amaranth> bob2: That's main uploader country. :)
<pitti> infinity: most of them were obsolete even with warty's tbird
<bob2> Amaranth: ?
<doko> Amaranth: the oo2 conflicts are resolved in m116
<Amaranth> bob2: unbreak main and cdimages will pop out :)
<infinity> pitti : Oh, so they are.  Interesting.
<Amaranth> doko: cool
<pitti> infinity: so it should only be necessary to update about 5 packages for universe (would be cool if we did)
<bob2> Amaranth: for hoary
<infinity> pitti : We need to do britney runs or something to prevent releasing with obviously broken packages like that.
<pitti> infinity: I didn't meet britney so far, is she nice?
<pitti> infinity: luckily all mozilla-locale-* packages are in universe, too, so at least I didn't screw up that...
<pitti> (for warty)
<infinity> pitti : -de, -fr, and -nl are the only installable ones.  The rest are broken anyway.  So, I'll just be breaking the last 3. :/
<pitti> infinity: oh, I only checked warty, not hoary
<infinity> pitti : The hoary ones depend on versions between 1.0 and 1.1, so we're safe there.
<mjg59_> carlos: Is this the big battery or the small one?
<pitti> infinity: cool; I remember that I thought of that when I brought them in shape
<crispin> doko: no idea, I don't know how the ff / mozilla code interacts with nss
<infinity> pitti : britney, as in the "testing" script.  Not that we should use "testing", it would completely break our workflow, but using britney occasionally to check for "Ooo, we have 800 completely uninstallable packages" might be nice.
<mjg59_> carlos: And can you unplug it, then put the contents of the files in /proc/acpi/battery/* somewhere?
<carlos> mjg59_, the small one
<carlos> mjg59_, sure
<pitti> infinity: would it be possible to run that with "imagine I would put these security uploads to warty-security"?
<pitti> infinity: or is it just "see that you broke it"?
<infinity> pitti : If you had a packages file for the proposed updates, sure.
<Amaranth> (gedit:7085): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed :/
<Amaranth> anyone know what that means?
<infinity> pitti : Use your packages file as the input (sid), and the union of warty and warty-security as the target (testing), and let it go.
<lamont> infinity: was more making sure you'd seen the /query and weren't going to mess with the chroots I was in...  but they're back to normal now
<doko> infinity, pitti: Kamion said, he was working on it
<infinity> lamont : Ahh, yeah, I saw it.  Also, ghc6 needs gcc-4.0 porting, which I never got around to doing.  Did you hack on it at all?
<lamont> infinity: about 2 seconds worth
<lamont> see #ubuntu-motu scrollback for my bitching when I quit dealing with it about 7-8 hours ago
<infinity> Heh.  Did you get to the point where you have any patches to show for it, or would anyone else taking up the torch be better off starting from scratch?
<\sh> doko: ping -> fbi fixed
<\sh> elmo: ping -> what do u need from me, for gpg key main include? should I mail u again my gpg pubkey?
<lamont> infinity: ghc/includes/Storage.h, comment out the extern that causes GC.c to fail.  That gets you to where I tossed my hands in the air.
* lamont --> work
<infinity> lamont : Alright, I'm trawling upstream CVS right now, looks like they've been committing gcc-4.0 fixes.
<ogra> pitti, do you know where callout.h dissapeared in hal ?
<lamont> infinity: I threw it back to sispoty and siretart - probably good to make sure there's no dup effort
<lamont> really running
<pitti> ogra: no, sorry
<ogra> argl... it was dropped completely .... 
<ogra> damned
<\sh> grrrrr....diff between pbuilder and sbuild was, that sbuild is parsing the build-deps in reverse order?
<infinity> ...?
<infinity> \sh : In what case?
<\sh> e.g. Build-Depends:  libxorg1-glu-dev | libglu-dev 
<infinity> Uhm, libxorg1-glu-dev isn't a package.
<\sh> and sbuild makes: libglu-dev is a virtual package provided by: xlibmesa-glu-dev libglu1-mesa-dev libglu1-xorg-dev
<\sh> what? 
<infinity> Try libglu1-xorg-dev
<\sh> aya
* \sh needs new glasses...where is the eye-specialist
<infinity> (But it's going away in daniels' next upload anyway, so get used to using libglu1-mesa-dev)
<infinity> Or, "Hi, GL and GLU are still seriously in flux, have a nice day."
<sebest> hi, any pointer to create initrd ?
<infinity> I need to upload some less broken mesa stuff, xorg -44 will drop GLU (so we only have one implementation), mesa needs to head to main, and a weird dpkg bug that triggers in some mesag-dev installations needs to be fixed or worked around.  Did I miss anything?
<siretart> infinity: whats bad about libglu1-xorg-dev? it is the same as in debian
<\sh> infinity: so I wasn't wrong...I doesn't really matter what I'm writing as GLU build-deps...it's always wrong ;)
<siretart> sebest: mkinitrd(8)
<infinity> siretart : Nothing's bad about it, except that as part of X modularisation, mesa is going back where it belongs -- to upstream mesa, rather than having an extra copy in Xorg that Xorg builds libs from.
<infinity> \sh : Possibly, yes. :/
<infinity> \sh : We're pushing to get this all a lot less confusing (and less ever-changing) as quickly as we can.
<infinity> \sh : For now, though, build-dep on liblgu1-xorg-dev, since we know it works (and you get to see if your packages actually build), and I'll go over verything in a semi-automated fashion after we fix the xorg/mesa overlaps and rebuild anything that may need it.
<\sh> infinity: forget my sarcastic comments...I was wrong..that's it
<\sh> but funny, that ia64 was behaving differently...
<infinity> \sh : ia64 may have a dirty chroot.  That can cause unexpected behaviour.
<bddebian> Heya
<infinity> \sh : Due the aforementioned dpkg bug, some mesa-related builds are leaving chroots broken.
<doko> \sh: thanks for the fbi upload. did you change anything in the source?
<\sh> infinity: so we can also have a problem on amd64 with libXrender.la?
<\sh> doko: yes...i included in the build-deps: bsdmainutils, cause hexdump was needed on ppc
<doko> \sh: please reupload as ubuntu1
<\sh> eek..ok
<\sh> doko: but grip is giving me a headache
<infinity> \sh : What's this about Xrender.la?... That should be long gone.  Which build log are you looking at?
<\sh> infinity: http://people.ubuntu.com/~lamont/buildLogs/g/grip/3.3.1-2ubuntu2/grip_3.3.1-2ubuntu2_20050727-1200-amd64-failed.gz
<\sh> infinity: and it's only occuring on amd64
<ogra> infinity, fails here locally too
<infinity> \sh : And yes, if you change the source, use -XubuntuX, as those are the only revisions that won't get automatically overwritten when the archive is in sync mode.
<infinity> \sh : Kay, that means amd64 probably needs some libraries to be updated.  I'll look at it and fix it tonight.
<\sh> infinity: thx
<doko> \sh: it's likely a pkgconfig file, which still references the .la file
<bddebian> Heya highvoltage
<highvoltage> hu bddebian. how are things?
<\sh> doko: let me check again..I'm really sad, that I'm a pkgconfig noob :( 
<bddebian> highvoltage: Not too bad thanks.  You?
<Kamion> doko: are we getting the OOo2 milestone without the conflicts soon, then? it's blocking live CDs at the moment
<Kamion> bob2: what's up with cdimage?
<highvoltage> bddebian: had a very productive day, so very well thanks.
<bddebian> Nice
<Kamion> bob2: cdimage is mostly my bailiwick
<\sh> doko: some libs have to be updated, as infinity pointed out..
<doko> Kamion: the OOo2 milestone was upload nearly three weeks ago. ask the xorg maintainer when he likes to unbreak xutils
<Kamion> doko: huh? no, this doesn't match reality
<Kamion> doko: oh, you mean it's FTBFS?
<doko> Kamion: I'm trying to work around now
<doko> doko: yes, it FTBFS
<Kamion> ah, ok
<bob2> Kamion: e.g. http://cdimage.ubuntu.com/dvd/current/ only has amd64
<Kamion> bob2: no live filesystem for other architectures at the moment, due to that OOo2 conflicts thing
<bob2> Kamion: and http://cdimage.ubuntu.com/releases/hoary/ looks like where I'd get a release iso from, but it only ha array 7
<Kamion> bob2: so the DVD build fails
<Kamion> bob2: http://releases.ubuntu.com/hoary/
<bob2> (which iirc was almost identical to releae, but still)
<tepsipakki> is the current X in breezy known not to work? or is my laptop hosed otherwise (been on a vacation for the last few weeks..)
<Kamion> array 7 was reasonably different from release
<bob2> Kamion: yeah, I found it, but it did confuse me a bit :)
<infinity> tepsipakki : /topic
<Kamion> yeah, the layout is not optimal
<Kamion> I kept getting instructions from above to rearrange it, which didn't help ;)
<bob2> haha
<tepsipakki> infinity: I noticed that before i upgraded ;)
<tepsipakki> infinity: I had -34
<HWolf> eh, that deadline mentioned in /topic is passed, btw
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | X is a little bit less broken
<bddebian> HWolf: Aye, days ago :-)
<HWolf> bddebian: it's really tempting to do a 'debian is not ubuntu' right now. ;)
<HWolf> I'll refrain, I'm feeling nice. *smiles*
<bddebian> Doh :-)
<infinity> \sh : Notice such breakages on any other packages recently?
<\sh> infinity: no..it was the first with libXrender.la on amd64..
<\sh> all kde tool builds were fine 
<infinity> \sh : Alright.  It'll be fixed PDQ.  THanks for the headsup.
<\sh> in the last couple of days..even there was no libxrender-dev build-dep actually
<\sh> ok..going home now...later dudes
<infinity> lamont : You're done with crested, right?
<infinity> lamont : The chroot's still dirty and buildd is still stopped, so I'm curious. :0
<infinity> lamont : Alright, I'm just going to assume you're done and clean up.
<pitti> infinity: btw, would it be too much overhead to regenerate the chroots for every package, like pbuilder does?
<doko> ogra: does gcompris belong to edubuntu?
<ogra> doko, yes
<ogra> doko, why ?
<infinity> pitti : Probably not terribly much so, but this method works except when a package is horribly broken (and in odd cases, that's a breakage we only catch, or only catch quickly, on the buildds)
<infinity> pitti : IOW, the current situation isn't optimal, but I don't mind it enough to change it.
<doko> ogra: you did win 12280
<ogra> meh
* ogra wonders whose fault that is...
<pitti> bah, these stubborn ffox locale package drive me up the wall
<HWolf> pitti, drive that useless package up the wall instead, with a good stick. ;)
<pitti> ogra: the patch looks fine (one nitpick, but nevermind), so go ahead and upload if you want
<pitti> HWolf: upgrading Warty's ffox breaks the existing packs, I have to update them as well, but that is totally nontrivial
<HWolf> pitti: I feel for you
<ogra> pitti, i'm struggling with the procfs patch currently... hughsie has added a Processor device so they either clash or we have it two times.... additionally hal obviously uses dmidecode now to create all the additional devices, but rips out very important info needed for hwdb :( its really odd...
<ogra> the removal of callout.{h,c} isnt explained anywhere... there is a new hal_util_callout_device thats undocumented etc... i'm slightly going insane here
<pitti> ogra: me too, if it helps yoou in any way
<ogra> pitti, yes, it makes me feel less alone :)
<ogra> the odd thing is i really dont understand why hughsie added the processor device, its not used at all for/by powermanager... he seems to have just added it because he can but breaks all my stuff with it GRRR
<ogra> there is not even useful info in the device details
<shackan> ogra, are you oliver ?
<ogra> shackan, yep
<shackan> uh, so you're "the guy who wrote the hardware datatabase in ubuntu" (from today's mail)
<ogra> heh, yep
<j^> if nautilus is going to use browser mode by default, it should not have that gigantic X in the side pane
<shackan> mind if I pm you a moment ?
<ogra> go ahead
<shackan> thanks
<j^> this "Tree \/     X" pannel is to big anyway should not be bigger than "Name | Size | etc"
<tepsipakki> hmm, I've found out that on my thinkpad T23 Xorg messes up the console if it is not set up to use the full screen (by telling the kernel as a parameter)
<\sh> re
<\sh> samba :)
<\sh> *hides*
<jbailey> mjg59_: ping?
<mdz> morning
<pitti> Hi mdz
<\sh> hey mdz
<Nafallo> morning mdz :-)
<Kamion> damnit, where are all my objects disappearing off to
<mjg59_> jbailey: Hi
<jbailey> mjg59_: You had asked me about initramfs-tools last week, did you get a chance to see if your stuff would integrate better with it?  The upload I did last night greatly increases the chances of booting succesfully. =)
<mdz> jbailey: does 'your stuff' include RESUME?  that's one of the things I noticed was missing the last time I looked
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> jdub!
<Nafallo> morning jdub! :-)
<jdub> jbailey: does it do DSDT stuff yet? :)
<jbailey> mdz: *blink* D'oh.  Whups, had missed that.
* jdub watches his mirror update... busy week!
<jbailey> jdub: No, but it's as easy to add as resume.
<jbailey> Next upload will have both.
<jdub> sweet, i will switch permanently then :-)
<mjg59_> jbailey: I haven't had a chance to play with it yet
<jbailey> mjg59_: No worries.
<whiprush> jdub lives!
<mjg59_> jbailey: Proper internet should be arriving next week
<jbailey> jdub: Well, with incentive like that! =)
<jbailey> mjg59_: Ah, I hadn't realised you were going without.
* ogra crys...
<ogra> doko, i hate you !
<mjg59_> jbailey: We've been "borrowing" wireless off someone...
<Nafallo> mjg59_: yay! Mithrandir style :-)
<jbailey> For all the times I've had to do that, I almost feel bad having a wep key on my wap.
<\sh> hey jdub...
<bddebian> Bad wep on a wap?  You'd better get that checked. ;-P
<jdub> heh, liblaunchpad-integration
<doko> ogra: Je n'ai pas compris ;-)
<ogra> :p
<sladen> jbailey: I need to carry a second orinoco card so I can crack WEP and show just how pointless it is
<ogra> doko, 43MB source !! and totally ftbfs on amd64
<ogra> :(
<\sh> lol
<ogra> but it fits in my day... porting my hal patches to 0.5.x isnt better at all... apichanges all over :(
<\sh> ogra: u don't know what song I'm listening too ;)
<jani> elmo, ping
<ogra> ehm, pitti ? (re: hal ML)
<pitti> yes?
<ogra> pitti, remember that we worked out that patch together ?
<ogra> :)
<ogra> (the execv is from our patch... he didnt add/change it)
<pitti> ogra: yes, but when the list of possible paths grows that long, then it's time to use the standard PATH feature, I think; of course you can just use your or that guy's patch
<pitti> ogra: right, but he added the search list, right?
<jbailey> sladen: Apparently in Canada (I  haven't verified) there's something where I can be held liable for having an unsecured access point if someone uses it for criminal purposes because I made no attempt to secure it.
<ogra> pitti, i dont like what he did at all... he should have done it in osspec and avoid forking into lsb_release_init if lsb_release isnt intalled...
<pitti> good point
<ogra> pitti, and yes, he added the search list
<ogra> but i dont want to discuss the patch... if they want to take and modify it they should... i trus david that he doesnt add rubbish
<ogra> (to the hal source i mean)
<carstenh> jbailey: the german datenschutzgesetz has a parapraph that could be interpreted in that way too, but i don't know if it _is_ interpreted in that way.
<jbailey> carstenh: I was advised this by the security officer at the last place I worked
<carstenh> jbailey: i guess it is illegal and it is not interpreted in that way
<tepsipakki> i got my X working (first it didn't find module keyboard, because it's now kbd), but now I can't change to console. known issue?
<sladen> jbailey: firewall everything except 80 and 22
<jbailey> sladen: Hmm, I wonder if that counts.
<Amaranth> tepsipakki: install xkbutils
<tepsipakki> amaranth: thanks.. noticed that some keys didn't work..
<tepsipakki> and now it's confirmed that I have to use vesafb for my console, otherwise X messes it up
<tepsipakki> don't recall having such problems on hoary
<tepsipakki> (months ago)
<tepsipakki> i'll file a bug
* ogra kicks hal 
<sivang> jbailey: oh man, can you clain that you are not tehnically able enough to secure and thuse it wasn't your fault?
* ogra steps in front of the buckle, so nobody sees it
<jbailey> sivang: *shrug*, who knows?
<jbailey> sivang: I suspect it's entirely dependant on whether the judge knows what a wireless router is.
<ogra> jbailey, i suspect judges who dont know what that is are getting rare
<\sh> ogra: in germany we have too many of them ;) in some areas ;)
<infinity> \sh : Wireless routers, or judges?
<\sh> judges
<\sh> and also wifi routers which are not configured in a good manner...but it's cheap
<\sh> need to buy btw. some wireless cables ;)
<infinity> \sh : Oh, you can pull libxrender-dev from grip's build-deps again.  T'was a good guess, but wasn't the actual problem. :)
<ogra> probably we could exchange the judges with wireless routers to balance that out
<infinity> \sh : I fixed the real bug and verified that grip now builds.
<\sh> infinity: what was it?
<infinity> \sh : vte needed to be rebuilt to rid its .la file of references to libXrender.la (which went away)
<\sh> ahh :) 
<\sh> as I said
<\sh> those problems we had as well with kde stuff
<infinity> Still?
<\sh> no
<\sh> Riddell got rid of the problems :) 
<\sh> infinity: should I upload again with correct build-deps?
<\sh> after that I will go to bed for 1h
<infinity> \sh : Please, yes.  No point in having incorrect/pointless changes in the ubuntu diff.
<\sh> infinity: as ubuntu3 then 
<infinity> <nod>
<\sh> done...sleeping for 1h now...
<pitti> gotta go folks, see you tomorrow
<infinity> 'Night, pitti.  I'll upload tbird tonight.
<pitti> infinity: I uploaded ffox/warty and the German langpacks, the other packs will keep me busy tomorrow
<infinity> :/
<pitti> infinity: please upload the breezy version first
<infinity> Aye.
<pitti> (with the new orig.tar.gz)
<infinity> Of course.
<pitti> infinity: I brought katie in serious trouble with uploading an orig.tar.gz into -security
<pitti> infinity: thanks, good luck with the update
<pitti> so, good bye, cu tomorrow
<mgalvin> hi all
<bddebian> Hello mgalvin
<mgalvin> i am trying to set up a repositroy and have it mostly working, but i am having issues where the Sources are not being generated properly, any chance someone may be able to give me a hand
<mgalvin> are there any good docs on this anywhere
<mgalvin> i have pretty much been scouring the net piecing together bits of info
<infinity> apt-ftparchive is your friend.
<bddebian> mgalvin: What do you mean by sources aren't being generated properly?
<mgalvin> infinity, thats what i am using
<mgalvin> bddebian, well in my conf file i tell it to use sources and it creates doesn't create a Sources file in dirs where there are sources, it does create Sources.gz though, but when i apt-get update i get errors such as...
<mgalvin> Failed to fetch file:///home/mgalvin/Repositroy/dists/hoary/multiverse/source/Sources.gz  File not found
<mgalvin> (i modeled it after the real ubuntu archives, for now)
<bddebian> mgalvin: Hmm, dunno, sorry
<mgalvin> so it is creating Source.gz, not Sources, and apt-get can't see Sources.gz, even though it is there
<mgalvin> bddebian, thnx anyway
<mgalvin> i'll keep banging on it
<mgalvin> i have gotten it to work another way, but then i complains when i try to sign my Releases file
<mgalvin> got it
<mdz> highvoltage: you know what I want!
<mgalvin> still having problem with signing the Release file though, when use just the Release file it works fine, when i sign it and have Release.gpg also it yells at me
<mgalvin> Failed to fetch file:///home/mgalvin/Repositroy/dists/hoary/Release  Unable to find expected entry  main/source/Sources in Meta-index file (malformed Release file?)
<TheLight> > Jul 21 14:14:20 localhost kernel:
<TheLight> > iiciciciiiiiiiiiiiciiiiiiciiiiciciciiiciiciiic
<TheLight> > iiiciiiiiiiciceiciiiciiiiiiciiiiiciiciciiciciiceiiiiiiiiiiiiceiiiiiici
<TheLight> > ic
<TheLight> > iiiciice
<TheLight> has anyone seen that error before?
<bddebian> Uhm
<TheLight> I can't even begin to figure out where it's from but I belive it has something to do with why I keep getting IO errors
<TheLight> sry, io errors while writing to jfs or xfs on an etherdrive
<hughsie> ogra: do you not sleep? :-)
<ogra> hughsie, hal 0.5.x steals my sleep ...
<hughsie> ogra: lol, i guess
<ogra> hughsie, where is hal_callout_device  gone ? looks like i have to rewrite everything here :(
<hughsie> ogra: not sure to be honest, I know davidz re-wrote a lot of my acpi stuff to get it in 0.5
<ogra> the api changed heavily.... :(
<ogra> hughsie, btw, what for do you have the Processor device ? i dont see the usecase for powermanager ...
<aigarius> upgraded to breezy. was fun. hard to believe the last part of topic. ...
<ogra> aigarius, thats because you didnt upgrade to breezy last week :)
<ogra> hughsie, btw, daniels hasnt been around yet, but i guess we could also talk to mdz, since he had to approve such a intrusive exception from UVF
<hughsie> ogra: sure, no problem
<hughsie> ogra: who is mdz?
<ogra> mdz, busy ?
<mdz> ogra: meeting
<ogra> hughsie, our lead of the distro team... one could also call him our CTO ;)
<hughsie> ogra: gotcha
<ogra> hughsie, so lets wait until the meeting is done
<hughsie> ogra: it would be easy for me to add back the non-glib bindings to g-p-m
<hughsie> but I'm thinking of all the other apps that are switching to the bindings
<hughsie> seems a shame
<ogra> hughsie, i think that would be the preferred method i ubuntu land currently.. because we had to transition _everything_ depending on dbus... and thats a lot
<ogra> tseng, around ? 
<hughsie> ogra: okay, let me remove glib bindings and I'll see what doesn;t compile in g-p-m
<ogra> hughsie, okay, great, thanks for the effort :)
<mdz> ogra: what is the question?
<ogra> mdz, hughsie is upstream for gnome-power... the powermanager we want to use in breezy... he made a lot of changes upstream to match our requirements for ubuntu
<ogra> mdz, but the latest version depends on a higher dbus version...
<ogra> hughsie, can you explain it more detailed ?
<mdz> is the new dbus incompatible with the one we have?  if so, at what level? (abi/api/etc.)
<hughsie> ogra: sorry yes
<ogra> mdz, it seems that a lot of apps are switching and even redhat backports this version to have it in
<hughsie> mdz: dbus 0.35 is pretty much the same as 0.34 but with the glib bindings
<hughsie> no api change that I'm aware of
<hughsie> mdz: lots of apps (gnomey ones) are switching to glib bindings
<hughsie> and it seems a shame not to have this in ubuntu (going to mean lots of patching for you if this doesn;t fall in)
<hughsie> mdz: redhat are backporting 0.35 into FC4, a move that they probably arn;t takinglightly
<seb128> I kind of second that, totem by example wants 0.35 now
<hughsie> mdz: seems a shame to cripple the "new" release
* ogra would like to know how hard our mono breaks with a new dbus ...
<ogra> but tseng seems not to be here
<hughsie> ogra: i don;t think much changed other than bugfixing in dbus 0.35
<Treenaks> hughsie: it did
<mdz> if we're going to put it in, we should do it sooner rather than later
<hughsie> Treenaks, got any details?
<ogra> yep
<mdz> are there any specific risks we should be aware of?
<Treenaks> hughsie: no
<highvoltage> mdz: the downloads were interrupted friday night (my connection died). it's back up now, and i'm not going to bed until i see something boot from this pc!
<ogra> mdz, pitti being unhappy about even more work ?
<mdz> ogra: how so?
<ogra> mdz, pitti seemed not thrilled about the idea
<mdz> how is dbus 0.35 more work for pitti than 0.34?
<hughsie> Treenacks, mdz: In the changelog there are lots of changes to the python and glib bindings but nothing substantial api wise
<ogra> hal recompile... for example... he isnt sure if it works cleanly
<hughsie> hal works with 0.35, i'm using it now
<hughsie> (from source)
<hughsie> (FC4 tho)
<ogra> hughsie, 0.5.2 ?
<hughsie> 0.5.3 actually :-)
* mvo just returns from his flooded cellar
<ogra> do you know if 0.5.2 works flawless as well ?
<hughsie> 0.5.2 hal-device-manager mightnot work right (it works but spews errors)
<hughsie> but hal works fine
<ogra> :(
<hughsie> (due to a fix inthe python bindings)
<hughsie> 0.5.3 works 100% tho
<hughsie> mdz: it seems to longer you leave the transition the more patches you'll have to do in 6 months time
<ogra> hmm, 0.5.3 isnt in debian yet
<mdz> hughsie: we're releasing in less than 3
<mdz> mvo: the water gods are angry
<ogra> hughsie, we are in UVF, that means no new upstream versions until release
<mdz> ogra: ...without review and approval
<ogra> hughsie, except exceptions :)
<highvoltage> elmo: hi elmo.how's that server coming along that you're setting up for edubuntu?
<hughsie> guys: lol
<mdz> dbus 0.35 doesn't sound like a big deal to me
<ogra> hughsie, i.e. gnome-power would have to be one
<ogra> mdz, we have no hal 0.5.3 in debian yet, so our hal would need fixage == work for pitti
<hughsie> mdz, ogra: does gnome-power have to ship with everytging else?
<mdz> ogra: surely pitti is not the only one who can package a new hal
<hughsie> whats wrong with shipping it in universe (or whatever you guys call it)
<mdz> hughsie: yes, we release everything at once and press it onto CDs
<ogra> hughsie, i just want the version you prepared for us ... to be able to connect it to pmi
<hughsie> ogra: not a problem
<ogra> mdz, lol
<ogra> hughsie, it shall be the default fromtend for pmi in breezy... thats why it should go to main and on the CD
<ogra> frontend even
<hughsie> ogra; gotcha
<hughsie> how long till release?
<ogra> 3 months... but feature freeze is august 11th...
<hughsie> is that definate, or could that slip?
<mdz> that is firm
<hughsie> mdz: cool.
<ogra> so time to get gnome-power in for me is short... i have more time to fix and adjust it then
<mdz> ok, so if I understand correctly:
<ogra> oh, great :)
<mdz> - we want new gnome-power for feature golas
<mdz> s/golas/goals/
<mdz> - new gnome-power requires new dbus
<ogra> yep
<mdz> - new hal is also required for new dbus
<mdz> anything else?
<ogra> or fixing of our hal
<highvoltage> can I make a request for the printing of the ubuntu cd's? the different colours for warty was really great- i missed that for the hoary cd's.
<mdz> I'd rather pull 0.5.3 than patch our hal
<ogra> i guess you could also backport patches from 0.5.3
<ogra> ah, ok
<hughsie> mdz: i dont think 0.5.2 -> 0.5.3 was that different
<ogra> i'd like to hear pitti about this... but he's already gone 
<ogra> he wasnt happy about the idea
<mdz> what is the issue with hal 0.5.2 + dbus 0.34?
<hughsie> ogra: if g-p-m used 0.34, would you still want to ship 0.35 for the other stuff?
<mdz> if it isn't api-incompatible, why do we need to update hal?
<ogra> hughsie, not me, but you heared seb128, he could need it for totem
<hughsie> hal itself is okay
<hughsie> mdz: it's hal-device-manager that uses the python bindings
<ogra> mdz, <hughsie> 0.5.2 hal-device-manager mightnot work right (it works but spews errors)
<ogra> <hughsie> but hal works fine
<mdz> hughsie: so there are api changes in the python bindings, but not C?
<hughsie> mdz: not completely sure. I think they were described as "fixes" by J5
<seb128> jui 15 12:06:08 <hadess>        BBB: any reasons why you need dbus 0.35?
<seb128> jui 15 12:07:36 <BBB>   0.34 didn't work, which was a bug according to walters
<seb128> jui 15 12:07:40 <BBB>   so I used 0.35 right away
<seb128> jui 15 12:07:52 <BBB>   also, api changed 0.34->.35
<seb128> I've that from #gnome-hackers
<mdz> who is BBB?
<hughsie> seb128, glib api changed
<ogra> so there _are_ api changes
<madduck> sabdfl: http://science.slashdot.org/article.pl?sid=05/07/27/1417247&tid=160&tid=14
<ogra> ah
<seb128> jui 15 12:16:36 <BBB>   I can try, but I couldn't get 0.34 to eevn register a simple function table
<seb128> jui 15 12:16:49 <BBB>   it would just throw a pointless warning and leave me not-understanding
<seb128> jui 15 12:16:59 <BBB>   0.35/cvs worked out-of-the-box
<hughsie> i think the c api is unchanged
<seb128> mdz: he's working for fluendo and upstream for totem-gst
<hughsie> (g-p-m seemed to work on both without change)
<hughsie> guys, i got a meeting in about 3 mins, so I got to run
<seb128> mdz: upstream for gnome-media and a part of sound-juicer too
<mdz> my feeling so far is that we should bite the bullet and bring in new dbus+hal
<hughsie> could you let me know hat the plan is plz
<ogra> hughsie, i'll inform you about the outcome of this, thanks for all the info
<hughsie> mdz: that would be my best idea too
<mdz> though if pitti has a reasonable objection I would like to hear it
<seb128> mdz: agreed
<hughsie> ogra: thanks
<ogra> mdz, yes, lets wait for pitti
<hughsie> cool, with that I go. cheers guys.
<seb128> pitti said yesterday it's up to daniels
<mdz> daniels?
<ogra> seb128, but he wasnt happy at all about it...
<seb128> jui 15 12:17:46 <seb128>        daniels: do you know if we have planned to stay to 0.34 or go for 0.35?
<seb128> jui 15 13:05:17 <daniels>       seb128: probably 0.35
<seb128> 
<ogra> mdz, daniels packages it... i guess we should move that to someone less stressed
<seb128> and that is from the #gnome-hackers discussion
<mdz> in that case, it sounds like we all agree on 0.35
<mdz> and we should just do it
<seb128> right
<ogra> yay
<fabbione> seb128: hey dude
<seb128> hi
<tseng> ogra: ?
<tseng> ogra: oh
<ogra> tseng, any advantages from 0.35 ?
<tseng> ogra: the exposed api from the mono bindings is static
<tseng> so if we can build against .35
<tseng> nothing really cares
<ogra> ah, so no change at all
<ogra> great :)
<tseng> its usually a rebuild
<tseng> breaks "abi" or something
<tseng> but it works.
<Mez> elmo:ping
<highvoltage> mdz: ogra says that the ltsp packages will only work on hoary, won't it work if i install them on hoary? i just assumed apt would take care of anything it needs. are there specific packages i could just upgrade?
<mdz> highvoltage: you mean breezy, right?
<ogra> yes i said breezy...
<ogra> but i'm not sure how you implemented it, does this limitation cunt for the host too ?
<Mez> elmo:pingmdz: the backports only compile against main yes?
<Mez> grr
<bddebian> ogra: Uhm, did you mean count there?? ;-P
<Mez> mdz: the backports  only compile against main - yes?
<ogra> bddebian, indeed...
<jasoncohen> Mez, congrats
<mdz> Mez: no, it should work exactly the same as the other suites
<mdz> Mez: i.e., main can only build against main, and universe only against universe
<Mez> o_O
<Mez> unknown/gtk-sharp2-unstable_1.9.5-1ubuntu2~hoary1: Dep-Wait by buildd+vernadsky [-:uncompiled] 
<Mez>   Dependencies: mono-mcs
<Mez> but, mono-mcs = in hoary
<Mez> so I think somethings cocked up there
<jasoncohen> anyone know when we can expect a security update for thunderbird? I think thunderbird 1.0.5 introduced API changes which might cause the same problem backporting security fixes for firefox caused
<Mez> (but obviously, I want that killed as it's mono and we dont want mono stuff at the mo
<hughsie> ogra: did pitti have his say?
<ogra> hughsie, nope, i guess he's done for today
<hughsie> ogra: no worries, I'll carry on hacking
<ogra> hughsie, but daniels obviously annouced in june already the inclusion of 0.35
<ogra> hughsie, <seb128> jui 15 13:05:17 <daniels>       seb128: probably 0.35
<hughsie> ogra: okay, that helps, thanks
<hughsie> glib-fication away
<ogra> hughsie, its very likely we'll get it, if pitti doesnt have srtong arguments against it 
<hughsie> ogra: cool
<highvoltage> mdz: sorry, yes, replace first "hoary" with "breezy"
<mdz> highvoltage: you need breezy
<ogra> mdz, even as the host system ?
<mdz> ogra: that's the only system which matters
<ogra> ok
<mdz> you need breezy unless you're going to do everything by hand
<mdz> in which case that completely defeats the purpose of the test
<ogra> ok, i wasnt sure
<highvoltage> mdz: ah, ok. i'll sort it out...
<mdz> highvoltage: I'm pretty sure that I wrote this near the top of the howto
<ogra> mdz, you did...
<Mez> infinity, or lamont, ping
<infinity> Mez : pong.
<Mez> infinity, can you use your "axe" and make amd64/ppc not build acroread :D
<Mez> cause it's only for i386
<Mez> (that's for backprts)
<infinity> Does it somehow hurt for it to be tried on !i386?
<infinity> (That's a rhetorical question)
<Mez> infinity, It just wont build thats all, makes life a lot easier if it isnt tried :d
<highvoltage> mdz: yes, you did. i assumed i could do it on hoary too, sorry, and i though i was just testing the ltsp part, so i wanted to try on hoary since breezy is still kind of broken.
<infinity> Mez : Doesn't make life much different at all, really.   A failed build log is pretty much how we deal with this. :)
<Mez> ... ?
<infinity> Mez : Packages are excluded on a per-arch basis when they break on that arch, or when the whole dependency chain needs to go bye-bye, or something equally evil.  When a package just fails (or doesn't even list our arch in the arch list), we just let the build fail.  It does no harm.
<jasoncohen> Mez, https://launchpad.ubuntu.com/malone/bugs/1598
<mdz> the next generation of buildd magic will just skip the build entirely
<infinity> mdz : The current one does, too.
<jasoncohen> Mez, i can't attach the rules file or source though
<infinity> mdz : But the log is listed as "failed" not "skipped", that's all.  But it IS skipped (we check the .dsc, we're not in it, we skip)
<mdz> seb128: when did libtotem_mozilla.so appear?  it rocks!
<mdz> infinity: but it only gets to that point by actually downloading the source package to the buildd and examining it, no?
<mdz> and there's really no reason for it to even get that far
<ogra> mdz, yeah, its cool.. its there since more then a month
<Mez> jasoncohen, assgned to me, I'll do it when I get upload :D
<infinity> mdz : Yes, that's because katie doesn't tell wanna-build anything about a package except for the version.  That could be fixed, but I doubt anyone cares.
<mdz> infinity: it will be fixed
<jasoncohen> Mez, will you be recompiling 2.70 (hoary) with gtk2 or backporting 2.85 from breezy and recompiling with gtk2?
<infinity> mdz : IN LP, it will be fixed, I meant "it could be fixed in dak/w-b".
<jasoncohen> heh, nevermind- 2.85 still hasn't gone into breezy even though it's been in sid for a while
<Mez> jasoncohen, I will be upgrading breezy, then maybe backporting
<jasoncohen> 2.85 has a more attractive interface
<jasoncohen> i use a checkinstall deb of mplayerplug-in 2.85 compiled with gtk2. 
<jasoncohen> Mez, do you know what's going to happen with the mirromax and other backports servers that currently are not in sync with the official ubuntu server? there are still packages on mirromax that aren't on the official server
<jasoncohen> like mono, firefox etc.
<Mez> jasoncohen, we're working on mono
<Mez> and firefox is vcurrently breaking the buildd
<seb128> mdz: it's for ~2 months but was pretty bugged until 2 weeks ago .. and yeah, it's nice :)
<jasoncohen> Mez, will backports still be packaging firefox? what's the point if the ubuntu security team will be providing new upstream releases to fix security issues (which basically accounts for all firefox updates)?
<Mez> jasoncohen, the point is... simply, we'll keep backporting FF
<infinity> ... why?
<jasoncohen> yeah, why?, heh
<Mez> infinity as the FF version increases, we'll backport it
<Mez> but - as it increases they wont neccesarily put it in h-s
<jasoncohen> i see
<jasoncohen> so, when 1.5 is released for example, that's going to be backported
<Mez> though ff was requested thgrough elmo before the current version
<Mez> so infinity, you can kick that from the buildd if you want to/can
<ogra> Mez, whats the usecase for that if the lates FF is in hoary ?
<jasoncohen> anyone know if this will apply for ubuntu's version of firefox? http://wiki.mozilla.org/Software_Update
<Mez> ogra: as I said, the current one - is a different issue
<Mez> it was piut in the list before the new FF for hoary was put out
<ogra> <Mez> jasoncohen, the point is... simply, we'll keep backporting FF
<jasoncohen> ogra, he is saying that the latest may not be in hoary if for example the latest update isn't security or if a new milestone is released. 1.5 is slated for september
<Mez> yeah, my point was that we will .. but I thought he was on about unofficial
<infinity> Mez : It failed anyway, not much to kick.
<Mez> we keep it in unofficial cause it's too much of a PITA to work
<Mez> infinity? it did?
<Mez> cool :D
<Mez> kick it
<jasoncohen> Mez, if the FF versions on hoary & backports are equal, which will be preferred?
<ogra> Mez, youre a MOTU, why dont you package a firefox-snapshot package for universe so people can play with it... even debian/utnubu might be interested 
<Mez> ogra, sorry... what?
<Mez> jasoncohen, hoary :D
<Mez> ogra - what you mean by firefox-snapshot
<ogra> Mez, if you make a package 1.5, why dont you do it in universe and backport from there, so breezy people can use it too
<ogra> s/package/package of/
<Mez> ogra, I will eventually when it's released :D
<Mez> but I coudl do a snapshot
<ogra> thats what i mean
<Mez> but yeah, I dont have like... upload or anything atm
<Mez> :D
<jasoncohen> i find that mozilla builds of firefox are faster than ubuntu (faster switching pages, starting up). are they compiled with different options?
<ogra> so people dont need additional source entrys to use it
<ogra> s/source/sources.list/
<Mez> ogra: I was just on about backporting it to official when it gets released
<Mez> ogra: not updating unofficial with it - just unofficial = a PITA
<adamh> When I try to debug my OpenGL application, gdb spits out a SIGFPE error from "r200_dri.so". I have to type "c" to continue execution, and the program seems to work. Any idea what's wrong?
<hughsie> adamh: SIGFPE is floating point exception right?
<adamh> hughsie: Yeah, GDB calls it "Arithmetic exception"
<hughsie> adamh, something like division like zero?
<adamh> hughsie: No idea, it's not in my code
<hughsie> lol, okay
<adamh> I don't have debugging symbols for r200_dri.so :)
<hughsie> adamh: that wa my next uestion
<adamh> Though I suppose I could look them up...
<adamh> Recompile whatever package in debug mode...
<adamh> Hahaha, wonderful, xlibmesa-dri -- provided by the "xorg" source (51MB)
<hughsie> adamh, don't envy you
<ogra> adamh, hoary ?
<adamh> ogra: yep
<ogra> adamh, breezy will change that :) modularized X has much smaller ackages
<ogra> packages even
<adamh> ogra: But the source package is the same, isn't it?
<ogra> hopefully not.... else we wouldnt gain anything for the uplods
<ogra> uploads...
<adamh> Well, maybe breezy will solve my original problem :)
<infinity> elmo : [ing.
<ogra> at least it will make it easier for you
<infinity> elmo : ping too, while you're at it.
<adamh> ogra: yeah
<adamh> Oh well, I can live with pressing "c" a thousand times a day :)
<ogra> adamh, try this one ;) http://www.backstreet.demon.co.uk/oddstuff/drinkingbirds/drinkingbirds.htm
<hughsie> ogra: that link is most odd
<dholbach> hi
<ogra> hughsie, heh, yes, but a helpful tool for such cases ;)
<hughsie> ohga: heh
<Lathiat> Is there a working breezy install cd yet?
<hughsie> *ogra: sorry
<dholbach> how do i get umlauts, ... on the newest x.org back? :)
<Lathiat> dholbach: write in english :P
<ogra> dholbach, xomdmap i heard... why did you upgrade ?
<dholbach> ogra: why shouldnt i? is there the don't-upgrade-and-don't-test-new-crack law in place already? :)
<dholbach> hmm, xmodmap... that's not very specific :-)
<ogra> dholbach, why upgrade if you know its missing stuff and totally broken :)
<dholbach> ogra: i didn't loose faith on the way
<ogra> dholbach, my X is still at -34
<mvo> ogra: wimp :P
<ogra> dholbach, but \sh mumbled something about xmodmap and setting a custom modemap 
<ogra> mv:p
<ogra> mvo even
* mvo managed to get umlauts, but he can't reproduce this stunt on any other machine apparently
<ogra> hehe
<infinity> Umlauts are overrated.  We're eliminating spurious accents in breezy, for the good of the planet.
<ogra> daniels, said something about next week for a working X .... 
<dholbach> infinity: if you give me a backslash, curly braces and an <at>-key i'm happy :)
<seb128> hey dholbach
<zyga> mvo: hello :)
<Mithrandir> dholbach: \ { } @
<ogra> dholbach, \ { }
<ogra> @
<dholbach> seb128: hey seb :)
* mvo waves to zyga 
<ogra> missed the @
<dholbach> Mithrandir, ogra: you're too kind
<infinity> dholbach : And now you can copy and paste.  See?
* dholbach cries silently
<ogra> dholbach, you can kepp them :)
<ogra> keep even
* mvo grumbles about broken copy'n'paste in emacs
<ogra> mvo, take vim ! :)
* infinity leaves 3 thunderbird builds going and runs off to find some breakfastish stuff.
<zyga> ogra: it's unethical to propose a holy war in our era ;] 
<zyga> mvo: how's update-manager?
<Mithrandir> infinity: you're adopting thunderbird? :-)
<ogra> zyga, i didnt purpose a war :) i was giving a friendly hint ;)
<fabbione> Mithrandir: it's FTBFS because of X :)
<fabbione> Mithrandir: nothing too fancy to fix...
<zyga> ogra: one religion gives a friendly hint to the other about being inferior ;-)
<jasoncohen> infinity, are you building a patched version of thunderbird for hoary/warty-security?
<ogra> zyga, you know i would _never_ do that, especially not to someone who just called me a whimp because i dont like to break my system intentionally ;)
<lamont__> Mez: acroread: i386                                                       # No source
<lamont__> that's pretty much there...
<lamont__> may be that PaS is out of date on ubuntu's machine, but I don't believe that is the case
<lamont__> infinity: do you have commit access to PaS?>
<dholbach> wb seb128 
<seb128> re dholbach
<gilligan> evening
<OddAbe19> if i dist-upgraded to breezy, besides the known X issues, what am i going to expect in ways of breakage?
<OddAbe19> also.... will keyboard work for EN-US person?
<OddAbe19> or is that still an issue
<infinity> lamont__ : I do.
<lamont__> infinity: ok
<lamont__> did you add acroread today, or was that already there?
<infinity> lamont__ : It's been there for ages.
<lamont__> right.  /me larts Mez 
<infinity> lamont__ : Doesn't change the fact that we tried to build it for hoary-backports.  <shrug>... It also doesn't much matter, cause sbuild stops before going anywhere interesting.
<lamont__> elmo: hoary-backports seems to be ignoring PaS???
<dholbach> infinity, ogra, Mithrandir: eat this:    \ { } [ ]  @   ;-)
<ogra> :p
<dholbach> xkbutils and xinit did the trick
<dholbach> and with backslash and curly braces i can face LaTeX again - see you :-)
<tritium> dholbach, :)
<\sh> jesus
<\sh> I have arunning german keyboard natively
<dholbach> woohoo!
<\sh> thx dholbach  ;) for pointing this out :)
<dholbach> synaptic search for maintainer "daniel stone" helped me :)
<\sh> now..why irssi doesn't understand /set term_type  utf-8
<mvo> dholbach: clever!
<dholbach> mvo: thank YOU! :)
<sladen> \sh: utf8
<\sh> unknown term type
* infinity knew he should have changed the Maintainer field in xkbutils...
<\sh> lol
<dholbach> infinity: you're evil - that'd have been sabotage to my thesis :)
<\sh> jesus who do I have to kiss?
<\sh> sladen: it is /set term_charset UTF-8 ,-)
<sladen> funky.  my config file has    term_type = "utf8";
<ddaa> https://launchpad.ubuntu.com/malone/bugs/1413 files beagle missing as an ubuntu source package on launchpad as a bug. But beagle is not part of ubuntu, it's only in universe.
<ddaa> That's clearly an invalid bug, but I'm not sure how to close it.
<Lathiat> yeh but isnt malone supposed to track universe stuff
<Burgundavia> beagle should exist
<Burgundavia> if the source package is in Ubuntu, it should be in LP
<ddaa> There's a wide spectrum from "not an ubuntu package" "invalid", to "that's not an ubuntu package but I've created a product for you". Obviously i'm looking for some middle ground.
<ddaa> Burgundavia: it's not in ubuntu. It's in Univers.
<\sh> infinity: small ping *g*
<Burgundavia> ddaa, universe is ubuntu
<ddaa> Burgundavia: no, it's not.
<Burgundavia> ddaa, yes it is
<ddaa> universe is unsupported software.
<\sh> infinity: universe/x11/xlockmore_1:5.13-2.1ubuntu2: Dep-Wait by buildd+rothera [optional:out-of-date]  Dependencies: libglu-dev
<seb128> Burgundavia: could you search for duplicate, ask the version, say if you get the issue, etc before forwarding bugs upstream?
<Burgundavia> seb128, sorry
<Amaranth> "I assume GDM isn't really doing well with my keyboard now as it thinks G is enter"
<\sh> infinity: now I'm completly confused :(
<Amaranth> dholbach: help this guy out :)
<\sh> infinity: on i386, ppc, amd64 but not ia64 ;)
<Burgundavia> ddaa, universe is one component of ubuntu
<dholbach> Amaranth: ouch
<seb128> Burgundavia: no need to be sorry, but forwarding this way you give me extra work ... :p
<Burgundavia> seb128, I was trying to avoid that
<Amaranth> http://ubuntuforums.org/showpost.php?p=272903&postcount=7
<ddaa> seb128: since you are the gnome guy around, and more used to dealing with the community than I am, maybe you have a suggestion for me.
<\sh> Burgundavia: your bug...for me it's only flickering
<Burgundavia> seb128, but bugzilla searching is less than ideal
<seb128> Burgundavia: ie: you forwarded a bug on nautilus saying that's with current distro, but submitter didn't say that, do you have the issue?
<Burgundavia> seb128, yes
<seb128> Burgundavia: try sf.net, the BTS or malone ... bugzilla is great :p
<Burgundavia> indeed
<seb128> ddaa: about what?
<Burgundavia> bts and sf.net causes me to want to remove my eyeballs and eat them
<Kamion> bugzilla is so hideously painful compared to debbugs
<seb128> that's not that bad, but the search feature are poor
<seb128> Kamion: you don't handle a lot of bug, that's why you say that
<ddaa> seb128: https://launchpad.ubuntu.com/malone/bugs/1413 this bug reads "Beagle is missing from ubuntu packages. Please add beagle package." but beagle is a universe package.
<Kamion> seb128: sorry, but that's bullshit
<Amaranth> bugzilla isn't bad when you don't have thousands of components to file bugs against
<Burgundavia> Kamion, depends on what you are doing with it. BTS is stronger is some points
<seb128> Kamion: you would have 1500 bugs open on nautilus you would cry with the BTS
<seb128> Kamion: how do I find a dup with a backtrace with the BTS?
<Kamion> seb128: I deal with d-i bugs all the time, there are a billion of those. I'm the openssh maintainer.
<Kamion> (functionally, anyway)
<seb128> Kamion: k, so teach me how to use the BTS 
<Kamion> you keep a mailbox with mail you've received about that package
<Kamion> it's far easier to search than bugzilla is
<seb128> I've a backtrace, I want to look for duplicate on all the packages
<ddaa> seb128: The better thing I'd have to say would be "you are welcome to create a beagle product if you are willing to take ownership of the bugs, but it's not a supported ubuntu package, so this bug is invalid", which is not terribly friendly.
<seb128> I'm not subscribed to the whole BTS
<seb128> Kamion: some GTK crash have dups on different packages, I want to find them
<Kamion> /usr/bin/bts can auto-download piles of stuff for you if you ask it
<Amaranth> ddaa: If it's in universe it needs to be in malone
<seb128> k, so how do I ask for all the opened bug having a funtcion g_some_function with gtk 2.6 on the BTS ?
<Amaranth> ddaa: malone is where we track universe bugs
<Kamion> man bts
<Kamion> man grep
<ogra> ddaa, beagle is in ubuntu breezy and mlone is for universe
<seb128> Kamion: thanks, that's user friendly
<seb128> I'll reply that next time a bug triager ask
<Kamion> also, yes, debbugs definitely needs better full-text search capabilities, and we've acknowledged that for a while; that doesn't mean it's a dead loss or that all the other deficiencies of bugzilla don't matter
* Amaranth doesn't think anyone has ever grep'ed a backtrace
<Burgundavia> Kamion, bts is crap to use on the web interface and try and read from there
<ddaa> ogra: http://packages.ubuntu.com/breezy/source/beagle
<Kamion> like the incredible pain of working offline with bugzilla
<ddaa> that web page reads "universe"
<seb128> Kamion: I get mails about all the bugs with bugzilla too ...
<Burgundavia> ddaa, malone is for universe packages
<Kamion> and can you reply to them? no.
<Kamion> you get a mail and then you have to fire up a web browser to do anything with them
<Kamion> bonkers
<ogra> ddaa, might be, but its in main or will move soon...
<seb128> right, bugzilla is missing a mail interface
<ogra> ddaa, in breezy
<ddaa> bah... I'll just let the distro guys decide this issue, I'm obviously not competent to take a decision on that on. Sorry for the noise.
<seb128> the BTS is missing a ziliion on things
<Amaranth> Kamion: regular users don't want a mail interface
<seb128> it just caught up on bug subscription and versionning by example
<Kamion> Amaranth: developers do
<seb128> that's ages behind bugzilla
<Kamion> seb128: dude, nobody else has ever done versioning
<Kamion> I know of no other bug tracking system with that feature
<Amaranth> Kamion: users are more important
<seb128> bugzilla has a version field
<Kamion> bugzilla has primitive milestones, which are not the same thing
<Amaranth> Kamion: developer interfaces can be hacked on later
<Kamion> Amaranth: whatever, bye
<infinity> seb128 : debbugs had a version field too, and it was about as useful.
<Kamion> I care about making developers' lives productive
<infinity> seb128 : Real version tracking, as debbugs now does it, is pretty cool.
<Kamion> others are much better at caring about users than I am, so I leave it up to them; users are better off that way :)
<seb128> infinity: anyway, I use both, bugzilla is much much better for what I do
<Kamion> and I don't appreciate being told I'm wrong for caring about developers, because somebody has to
<seb128> bugzilla.gnome cares a lot about developers too
<infinity> debbugs' mail interface wins hands down for me, but maybe I'm just a Kamion groupie.
<Kamion> gnome developers are biased towards UI folks
<Kamion> that's a different case
<seb128> infinity: explain to an user he has to mail to add a comment to a bug where he just browsed
<Kamion> funny, we don't hear that particular complaint about debbugs very often
<infinity> seb128 : Yes, dubbugs could use a friendly web interface.  Doesn't change the fact that bugzilla could use a decent mail interface, does it? :)
<seb128> because we don't have lusers
<infinity> (And if someone really cared enough, debbugs would grow a web interface, it's not rocket science)
* Burgundavia disagrees
<seb128> infinity: nop, I agree on that, I just find 100 nautilus bug hard to manage with the BTS
<seb128> harder than 500 bugs with the upstream bugzilla
<Burgundavia> infinity, a really good web interface is actually quite difficult to pull off
<seb128> infinity: ie: searching for crash duplicate is much easy with the query.cgi from bugzilla ... I don't even know how to do the same with the bts
<Kamion> I find my bugzilla bugs pretty much impossible to manage compared to double that number of debbugs bugs, so I guess we'll just have to agree to disagree
<infinity> Burgundavia : "Really good" doesn't seem to be a requirement, if we just want to get bugzilla's functionality.
<wasabi_> ibook still can't wake up with latest ppc kernel. =(
<Burgundavia> infinity, indeede
<Kamion> anyway, maybe I should go have a drink, I seem to be tetchy this evening, sorry
<infinity> Ugh, half an hour to upload thunderbird.  I hate my connections.
<infinity> s/connections/connection/
<seb128> infinity: how do I find crashers listed by the BTS with shortcut_find_position () on one of the comments?
<seb128> real question, I would look if this gtk bug has some dups ..
<infinity> seb128 : Yes, full-text search in debbugs is a missing feature.  Kamion already pointed that out.  Can we move on, please? :)
<seb128> k
<Kamion> like I say, we'll add decent full-text search at some point; it's getting pretty high on the agenda now that we've disposed of the two things that were top of the list
<dholbach> Kamion: for being tetchy you're quite calm - enjoy the drink :)
<infinity> (But you can download the mboxes, keep that synced locally, and use grep to your heart's content.  Not friendly, but it works..)
<seb128> bug triagers are not likely to do this
<Kamion> there was some plan to use lurker, although I'm not sure that'll be feasible; we'll see
<Burgundavia> infinity, thanks I would rather have a nice web interface
<infinity> Kamion : Is the debbugs package even remotely up to date these days?
<Kamion> infinity: no - as soon as I implement vt expiry so that feature's properly finished, I'll upload 2.4.2 or 2.5 or whatever
<infinity> Kamion : Or, better question, since I care about the code, not the package, where is the code maintained now?
<Kamion> infinity: :ext:cvs.debian.org:/cvs/debbugs, module source
<infinity> Kamion : Still cvs.d.o?
<infinity> Kay, cool.
<Kamion> hopefully moving to baz as soon as the import works
<Mithrandir> elmo: did you see my whining about libapreq2 having gone missing in the pool?
<\sh> Mithrandir: can u please xmms-dev (>= 1.2.7) libsqlite3-dev libtag1-dev fftw3-dev
<elmo> Mithrandir: no?
<\sh> phhh
<infinity> elmo : How do things end up with "unkown" as their section in wanna-build?.. Missing overrides?
<\sh> Mithrandir: again..please install those packages in breeze chroot on ravel: xmms-dev (>= 1.2.7) libsqlite3-dev libtag1-dev fftw3-dev
<Mithrandir> elmo: apparently, libapreq2 (source package) is missing from the pool.  That is, .dsc and .diff.gz is missing, orig.tar.gz is there.
<elmo> infinity: yes
<infinity> elmo : If so, we need to "backport" overrides when we backport packages, or stuff in universe doesn't build on hoary-backports (if it doesn't exist in hoary, I assume)
<infinity> elmo : Currently 7 packages in hoary-backports stuck in needs-build and very confused about life for that reason.
<Mithrandir> \sh: fixed, now freshening chroot.
<\sh> Mithrandir: thx
<Kamion> elmo: (that's libapreq2-perl, btw)
<\sh> Mithrandir: hmm...debhelper (>> 4.0.0) is missing :( strange...
<Mithrandir> Kamion: the source package was renamed, it appears.
<Kamion> ah
<Mithrandir> Kamion: hm, no, sorry.  it's libapreq2-perl in ubuntu, but libapreq2 in Debian
<Kamion> nightmare
<Mithrandir> that is, the source package was renamed since it now provides more than just perl stuff.  I wonder if that might have confused the scripts which import from Debian.
<Mithrandir> \sh: better now?
<martinhj> is there a list on what wireless cards network manager supports? I got an old orinoco wifi card wich I have enabled scanning on (not with the drivers shipped with the linus or ubuntu kernel).. iwlist interface scanning works, nm dosn't show any access points
<martinhj> I'm testing this with the all packages up to date in breezy
<ogra> martinhj, pcmcia ? 
<martinhj> ogra: yes
<infinity> In theory, it should work with anything iwlist works with.  In theory.
<wasabi_> It's odd. nm also says it doesn't support scanning with my card either.
<wasabi_> But iwlist has always worked before.
<infinity> In practice, I'm not really sure.
<ogra> i have a orinoco silver here that doesnt work either with NM...
<martinhj> wasabi: nm does not say anything to me
<wasabi_> Yeah, oronico too
<Lathiat> ogra: i've never ahd it work on a pcmcia orinoco
<Lathiat> probably cus theres no scanning support by default
<martinhj> but with cable it helps me to get connected
<wasabi_> Not true. There is scanning support.
<ogra> Lathiat, with some manual fiddling after the boot... but thats indeed not the intention of NM
<wasabi_> There isn't MONITOR support.
<Lathiat> wasabi_: there isnt either.. unless that changed recently
<Lathiat> wasabi_: theres unofficial patches for both
<wasabi_> There has always been for me.
<ogra> wasabi_ neither does work with mine
<wasabi_> Hmmm.
<Lathiat> the scanning might have been integrated into the kernel sometime in the last 6-12 months but im not aware of it
<ogra> wasabi_, silver or gold ?
<wasabi_> airport.
<Lathiat> isnt airport different
<Lathiat> like, its similar, but has a different driver
<ogra> afaik yes
<infinity> That's all fairly moot, though.  If iwlist works, n-m should work, because n-m is using libiw.  Unless n-m is maintaining an internal blacklist (ick)
<wasabi_> It's similar.
<martinhj> Ubuntu should maybe ship those drivers I use with my orinco card now.. seems more stable too: before I had to restart the computer (or a lot of services) when the driver didn't load properly.. happened a lot
<ogra> wasabi_, ariport is pcmcia ?
<ogra> thats news to me
<Lathiat> ogra: its something like pcmcia with a different pinout 
<Lathiat> aiui
<Lathiat> same form factor etc
<ogra> yeah, but my guess is pcmcia is the issue here
<wasabi_> it's not pcmcia.
<seb128> doko: around?
<OddAbe19> if i dist-upgraded to breezy, besides the known X issues, what am i going to expect in ways of breakage?
<OddAbe19> also.... will keyboard work for EN-US person?
<OddAbe19> or is that still an issue
<dholbach> OddAbe19: i have a dj-vu
<ogra> dholbach, fix the matrix then ;)
<dholbach> OddAbe19: you might expect untransitioned/uninstallable packages
<martinhj> breezy seems a lot less responsive than hoary in terms of refreshing the view while draging windows around, redrawing the desktop and such.. has it something to do with new X versions?
<rtcm> martinhj: stepping my toe here but I guess that's caused by the new gtk based on cairo which still lacks some performance improvements
<martinhj> rtcm: oh, so this gtk version is already in breezy? I didn't know..
<\sh> Mithrandir: ping please include as well libxss-dev thx :)
<dholbach> i'm perfectly content with new gtk responsivitywise
<tseng> dholbach++
<Mithrandir> \sh: done
<\sh> Mithrandir: thx
<Burgundavia> it seems only to be the window drawing that seems slow
<martinhj> and desktop redrawing here
<dholbach> *wave* off again
<\sh> cu dholbach have fun and get finished with your work :)
<infinity> Well, I already have slow window updating with hoary, so I'm sure I won't notice a difference at all. :)
<infinity> (If Xorg knew how to talk to PCIe devices, I'd be happier..)
<Lathiat> infinity: xorg doesnt speak to pcie gfx cardS?
<Lathiat> that sucks
<OddAbe19> dholbach, what did you type? i got jarbled -vu
<infinity> Lathiat : It deals with them as raw PCI.
<infinity> Lathiat : Which means they're as slow as PCI...
<dholbach> OddAbe19: deja-vu
<infinity> Lathiat : So, AGP is faster than PCIe, until that gets fixed.
<OddAbe19> oh
<Lathiat> infinity: ah right
<OddAbe19> so generally X is stable right now and works with a dist-upgrade?
<OddAbe19> generally speaking
<martinhj> OddAbe19: I got a lot of errors, but it runs at least
<martinhj> and I can't set the keyboard layout
<infinity> martinhj : xkbutils?
<marcin> jbailey, ping
<martinhj> infinity: at least some errors about something to do with xkb (don't remember what...)
<martinhj> could be
<Lathiat> whats the fix for cant find font 'fixed' ?
<ogra> find the missing mkforntdir 
<tseng> find? :P
<ogra> mkfontdir even 
<tseng> its nowhere
<Lathiat> ah
<Lathiat> can somebody send me a copy? :)
<rtcm> btw, on which package is xset right now? I don't have it
<Kamion> rtcm: none, I think; xbase-clients is still in the middle of modularisation
<Kamion> go back to an old xbase-clients if you need to
<rtcm> Kamion: ah, thanks, dont need it really
<Lathiat> wow ok
<Lathiat> so X is mostly working
<infinity> martinhj : No, I meant "install xkbutils if you want to be able to set your keyboard layout"
<martinhj> infinity: ah, ok.. thanks
<Lathiat> Has anyone noticed the issues with icon sizes being used wrongly and no if its reported?
<seb128> Lathiat: http://bugzilla.gnome.org/show_bug.cgi?id=311318
<Burgundavia> there is a long debate about autopackage in the forums
<Lathiat> seb128: ah, upstream, thanks
<Burgundavia> seb128, http://bugzilla.ubuntu.com/show_bug.cgi?id=12975
<seb128> what about it ?
<Burgundavia> it is a usablity bug
<seb128> bah
<Burgundavia> mpt talked about something similar in his 48 hours rant
<seb128> reassign this bug to you and move it to an another component if you want
<seb128> yeah, gnome-session sucks
<seb128> that's known upstream
<seb128> 2.14 will use libgnomeservice
<seb128> and we are already all sort of rant about it
<TerminX> seb128: how long will gedit be broken?
<seb128> no new of a new one
<Burgundavia> there is that new gnome-session framework thingy coming along, no?
<seb128> and I'm too lazy to spend 10 min to point other duplicates
<Mithrandir> Burgundavia: 23:44 < seb128> 2.14 will use libgnomeservice
<Mithrandir> :-P
<Burgundavia> ok
<seb128> too lazy or too busy
<seb128> anyway this bug has no interest
<Burgundavia> if upstream knows about it, then it is not a major issue
<Burgundavia> I will leave it
<TerminX> if I try to open a file on a mounted SMB share in gedit, I get (gedit:23658): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed
<seb128> TerminX: http://bugzilla.gnome.org/show_bug.cgi?id=310270
* TerminX looks
<seb128> that's probably the same issue
<TerminX> yeah, I think it is.. looks like EOG crashes here too
<martinhj> I got a problem with the Ubuntu kernels... acpi-events does not work...that means that the battery in the gnome panel does not work as it should.. the same issue in hoary and breezy.. in hoary I fixed it with another kernel that was in universe I think (2.11 instead of the ubuntu ones), but now I'm testing breezy the same bug is back
<TerminX> seb128: so is there a fix for it?
<martinhj> is it a known bug?
<seb128> TerminX: no
<infinity> martinhj : Not known to me.  What kind of hardware is this?... ACPI works for me on my two laptops.
<infinity> martinhj : Also, you might want to try talking to mjg59, he's the laptop team lead and resident ACPI guru.
<Mez> elmo: ping
<sladen> martinhj: what make/model of laptop do you have?
<martinhj> infinity: it's an acer travelmate 620
<sladen> martinhj: have you tried with any previous Linux install and had them work?
<sladen> martinhj: or is this a case of ''they've never worked''?
<martinhj> sladen: as I wrote, I got the same problem with hoary, but I fixed useing another kernel than the Ubuntu onw
<Mez> infinity: did you sort that thing with backports on the buildd yet?
<martinhj> one
<seb128> Burgundavia: when clicking on "cancel" of the "open ftp..." dialog, I get a dialog saying it can't open the folder but no retry/hang
<sladen> martinhj: what was the 'other kernel' you used?
<martinhj> sladen: one in hoary universe I think
<martinhj> sladen: I can check it
<Burgundavia> seb128, hmm
<sladen> martinhj: it would be useful, then we can track down what changed!
<martinhj> sladen: 2.6.11-1-686 in hoary's universe
<Burgundavia> seb128, I assume you are running .90
<seb128> yep
<sladen> martinhj: and what's the one that doesn't work?
<martinhj> sladen: (2.6.11-0.2
<martinhj> sladen: not that one
<Burgundavia> seb128, leave them and needinfo for now. I will try with the colony 3 livecd
<tseng> daniels: hell yeah xrdb
<infinity> Mez : I handed it off to elmo to investigate his end of things, I'll follow up with him later on.
#ubuntu-devel 2005-08-02
<seb128> Burgundavia: but that's the cancel from the login dialog, where you pick your username?
<Burgundavia> seb128, yes
<Mez> kool infinity :D thatnks for the update
<martinhj> sladen: the ones official shipped with hoary and the ones I haved tried in breezy (2.6.12)
<seb128> Burgundavia: weird
<Burgundavia> seb128, I am also having a wierd resize issue with nautilus (new browwer mode). I suspect I may just have a borked nautilus
<sladen> mjg59_: martinhj's Acer TravelMate 620 worked with 2.6.11-1-686 from hoary universe, doesn't work with current breezy 2.6.12 kernel, was anything added/changed to try and fix things up?  Apparently acpi-events aren't getting passed through
<Riddell> mdz, Kamion: am I ok to upload a new koffice 1.4.1 i18n package?
<tseng> infinity: do you see an evolution-sharp kick in your future?
<mjg59_> sladen: Nothing I can think of off-hand
<mjg59_> Though it's an Acer, so, well...
<mdz> Riddell: koffice 1.4.1 is already uploaded?
<Riddell> mdz: yes
<mdz> Riddell: yes
<Riddell> thanks
<infinity> tseng : Will it build this time? :)
<martinhj> mjg59_: but it works with kernels from the Linus' tree at kernel.org at least
<tseng> infinity: you know what, let me remove universe from my pbuilder and try that
<seb128> Burgundavia: what kind of issue?
<Burgundavia> seb128, when I open nautilus, it flashes for about 1 sec to full screen, then down the remembered size
<Burgundavia> and i don't have a slow machine
<seb128> weird
<whiprush> I just noticed that today also
<tseng> infinity: deps seem resolveable
<whiprush> also when hitting alt-f2 it does some weird flashing thing
<tseng> infinity: by pbuilder wiht only main/restricted.
<Burgundavia> whiprush, it is jumping 2 workspaces left
<martinhj> sladen: / mjg59_: another thing that does not work with the ubuntu kernels besides the kernel events is that the brightness of the screen does not change when I plug/unplug the cable.. it does with other kernels
<infinity> tseng : Good to hear, cause I already gave it back.
<Burgundavia> seb128, basically, whenever it draws a new window, it is jumping 2 workspaces left
<tseng> infinity: /me fanboys
<tseng> *hide*
<sladen> martinhj: the screen still works with the Ubuntu -686 kernel from universe?
<sladen> martinhj: screen brightness changing on AC change?
<Burgundavia> whiprush, can you confirm that that is what is happening to you?
<mjg59_> martinhj: Yeah. Could you possibly try the latest 2.6.13-rc kernel?
<martinhj> sladen: yes, it does
<tseng> Burgundavia: were you the beagle + blam exploder dude?
<mjg59_> It should have similar acpi code to ours
<Burgundavia> seb128, might this be a keyboard breakage issue?
<Burgundavia> tseng, yes
<seb128> would be weird
<tseng> Burgundavia: please test again in a few hours when evo-sharp builds
<martinhj> mjg59_: from kernel.org or is it something in the repositories?
<Burgundavia> tseng, beagle is currently non-functional on my machine
<mjg59_> martinhj: From kernel.org
<tseng> Burgundavia: i qualified "when evo-sharp builds"
<Burgundavia> ah, ok
<Burgundavia> tseng, cheers
<tseng> im assuming that if your blocker
<tseng> if not, id still be interested to hear back
<Burgundavia> if it isn't, I will file a bug
<tseng> cheers, please assign
<martinhj> mjg59_: wont be doable before monday at least.. I'm going on vacation now.. but when I get home, I will...
<mjg59_> martinhj: Cool, thanks
* infinity scratches his head.
<infinity> tseng : Still fails here.
<tseng> infinity: gar
<tseng> infinity: unresolved build-dep?
<infinity> Still no mono-classlib-1.0-1.1.8.2
<infinity> (which was provided by what, again?)
<tseng> mono source
<tseng> it should just divert to mono-classlib-1.0
<tseng> which makes me wonder why we have it at all, but i didnt make that call
<tseng> im sure there is a rational explination
<infinity> Right, the virtual package is provided by mono-classlib-1.0.
<infinity> Which still doesn't appear to be in main.
<tseng> huh
* infinity squints.
<tseng> but we... seeded it
<tseng> days ago
<infinity> Yes..
<infinity> kamion : Still around?
<Kamion> infinity: just
<infinity> Kamion : Care to skool me on why seeding something to supported a couple of days ago doesn't (didn't?) magically make it jump to main? :)
<infinity> Kamion : mono-classlib-1.0{,-dbg} in this case.
<Kamion> because promotion to main is not automatic
<Kamion> it needs an ftpmaster to run teri
<infinity> Oh, feh.  That makes perfect sense.
<Kamion> it's not on the promotion list though, one sec
<Kamion> oh, er, cron.sync doesn't seem to have run since 21 July
<Kamion> at least, not to completion
<Kamion> # Germinate uses python logging module which clashes with katie's
<Kamion> export XPYTHONPATH=$PYTHONPATH
<Kamion> unset PYTHONPATH
<Kamion> elmo: dude, you called a private module logging? :-)
<restrex> anyone running the latest xorg build?
<Kamion> elmo: I think this is yours to look at, anyway; all I can assume is that cron.sync is set -e'ing out before it gets round to running germinate, but I don't have the cronmail to tell me why
<Burgundavia> seb128, whiprush has confirmed the bug
<seb128> what bug?
<Burgundavia> the wierd jumping workspaces bug
<Burgundavia> https://bugzilla.ubuntu.com/show_bug.cgi?id=12994
<tseng> seb128: heh evince is 100x faster. you rock
<Burgundavia> 2 sec to load. Think we just kicked the crap out of acroread
<seb128> tseng: I've not done a lot for this but thanks :)
<tseng> Burgundavia: i was more bothered by taking several seconds to draw pages as i scroll through
<Burgundavia> tseng, yes
<tseng> Burgundavia: on a 500 page book
<tseng> its now very fast.
<Burgundavia> cool, go none of those
<seb128> Burgundavia: you do alt-F2 and that change workspace?
<Burgundavia> some dialogs cause you to show 2 workspaces to the left while drawing the window
<Burgundavia> after they are finished drawing, they show you the correct window
<Burgundavia> that is what is so baffling
* Burgundavia wants istanbul, so I could just make a capture
<seb128> works for me (tm)
<Burgundavia> well, whiprush has it as well
<Burgundavia> and we tested new users, so it is not something user specific
<seb128> maybe you lack some updates
<Burgundavia> for what?
<seb128> or maybe xorg is borked
<seb128> dunno
<Burgundavia> I have nothing pending to update
<seb128> maybe xorg is b0rked
<Burgundavia> likely
<Burgundavia> daniels, seb128 blames my bug on you
<tseng> ez gtk boog
<Burgundavia> seb128, should I file beagle bugs in bugzilla?
<seb128> Burgundavia: ask tseng
<restrex> anyone have the xbase-clients 6.8.2-35 package to share? Thanks.
<Burgundavia> tseng, https://bugzilla.ubuntu.com/show_bug.cgi?id=13030
<doko> seb128: pong
<seb128> doko: so, what do we need to do to fix firefox?
<seb128> doko: totem FTBFS too now ...
<Burgundavia> tseng, sorry, I am an idiot, please excuse me
<terrex> hi friends, i've just upgraded from yesterday to today (libx11-6, gnome-control-center,..) and when i login, the splash screen freezes and neither nautilus nor gnome-panel load. So i must to select from GDM "failsafe xterm" and then starts metacity & gnome-panel manually. Also gnomemeeting and gaim don't want to start.
<Burgundavia> terrex, that is more a question of #ubuntu
<tseng> Burgundavia: ok for the 3rd time now
<doko> good question. the cleanest thing would be to build nss and nspr from it's own source, use these for other packages, build the shared libs from these packages. if firefox needs it's own copy, then it can ship it's own, but should use it's own names for a libnss and libnspr. so first thing: compare the libs (separate source, mozilla, firefox)
<tseng> Burgundavia: beagle needs an evolution-sharp update
<tseng> Burgundavia: we're working on getting it built
<Burgundavia> tseng, yes, I realized yes, after I saw the build logs
<tseng> k :)
<Burgundavia> tseng, I close the bug with because the reporter was a moron
<tseng> oh :/
<tseng> Burgundavia: meh its alot to keep up with
<jasoncohen> Any backports developers here?
<tseng> jasoncohen: you can try Mez, he's pretty helpful
<jasoncohen> yeah, i was actually looking for him
<terrex> Burgundavia: ok, thanks all anyway.
<jasoncohen> but he's not online
<tseng> hm I guess not
<tseng> seemed like i was just talking to him
<jasoncohen> i was wondering when smeg and other packages will be added to the official backports repository
<Burgundavia> jasoncohen, mez was in #ubuntu-motu as of an hour ago
<jasoncohen> a /whois mez now shows him nowhere
<Burgundavia> I don't see an exit message, so he must have silently dropped and not noticed it yet
<infinity> jasoncohen : When we work out some small snags in the process.
<jasoncohen> ok, so more packages will be added when those snags are figured out?
<Amaranth> last seen 26 minutes ago
<restrex> anyone can share the xbase-clients 6.8.2-35 package ? Thanks.
<mrd`> xrdb b0rked my login I think. :/
<\sh> re
<mrd`> Hm... not xrdb... something else b0rked my gnome login.
<mrd`> Friday, Hoary's going back on my laptop. :)
<mrd`> (Hopefully, I'll have room for a chroot on my new desktop though.)
<\sh> daniels: ping?
<\sh> or someone who's working on Xorg stuff ,-)
<\sh> on amd64...it looks like there is a problem with libXss
<\sh> config.log output from imms:
<\sh> configure:5680: g++ -o conftest -g -O2 -I/usr/include/taglib -shared -L/usr/X11R6/lib conftest.cc -lX11  -lpcre -lsqlite3 -lz  -ltag >&5
<\sh> /usr/bin/ld: /tmp/ccMsAUO5.o: relocation R_X86_64_PC32 against `XFlush' can not be used when making a shared object; recompile with -fPIC
<\sh> /usr/bin/ld: final link failed: Bad value
<\sh> and libX11...forgot to say
<infinity> \sh : Ignore the config.log, it's just telling you to use -fPIC (which the package does, if you look at the build log)
<infinity> \sh : The build failure stems from a (very obviously) missing -lX11 in the linker call.
<\sh> infinity: you mean directly in the configure script?
<\sh> nasty
<infinity> No, I don't.
<infinity> I said it's missing, I didn't say from where, precisely.
<\sh> infinity: ok...i will check it later today...now I have only *censored* sources on my table
<infinity> \sh : If you add 'CXXFLAGS="-fPIC"' before the ./configure call, configure's tests don't blow up, and it finds the libraries it wants. :)
<infinity> \sh : So, there you go.  Merry Christmas.
<infinity> \sh : (I'd recommend 'CXXFLAGS="-fPIC $(CFLAGS)" ./configure ...' to make use of the CFLAGS the maintainer set previously and then never used...)
<infinity> \sh : Oh, and you might want libxss-dev, if you want "screensaver functionality" in the package, whatever that means.
<bob2> ./configure CFLAGS=...
<bob2> or so everyone tells me
<HrdwrBoB> bob2: other way around
<infinity> bob2 : Both work, for different reasons.
<bob2> hm
<infinity> bob2 : My example puts CFLAGS in the environment, which is a variable configure happens to cherry-pick out of said environment, I believe your example has configure interpreting 'FOO=BAR' pairs on the command line as "private environment settings", and it sets those for itself.  Which has the exact same effect.
<mrd`> Is not being able to login to Gnome a known issue for Breezy at the moment (other than my whining earlier)?
<infinity> bob2 : Something along those lines, anyway.  Either way, my example works fine to fix \sh's problem, and I don't much care if it makes an autotools maintainer or two cry (in fact, I'd prefer if it did..)
<bob2> hahaha
<infinity> bob2 : I'm not sure how much of the environment configure preserves, but I'd be willing to bed that for anything other than CC, CXX, CFLAGS, CXXFLAGS, and LDFLAGS, you're correct, having it in the shell's environment won't work, but having it in configure's command line will.
<infinity> s/bed/bet/
<infinity> (note that my previous comment about wanting to see autotools maintainers cry still stands, however)
<OddAbe19> what exactly is Cairo? i was reading the site... is it just a speed/ image improvement for GTK and Icons?
<jdub> OddAbe19: it's an API for vector-based drawing that can use different backends for rendering (such as GL and printing)
<jdub> OddAbe19: because it's more abstract than using X, there are more opportunities for retargeting and optimisation
<calc> er what happened to xutils in breezy?
<calc> there are no binaries in it
* calc can no longer start X due to that issue
<Lathiat> calc: whats the error?
<calc> something about sessreg missing
<calc> xutils has no binaries in it at all including sessreg
<calc> also ice complained afterwards about not being able to find transport: tcp
<calc> er xbase-clients has no binaries either
<calc> what the hell happened to xorg
<calc> did someone forget to build the binaries when they uploaded it last time
<calc> it went from being around 2MB deb to being a 60KB deb
<schweeb> calc: xbase-clients isn't supposed to have any
<schweeb> they were split out
<schweeb> and added as deps
<schweeb> check the deps for xbase-clients
<calc> or not... :)
<schweeb> which binary are you looking for?
<calc> how many deps do you see on yours?
<calc> i see only 10
<calc> i don't have any easy way to cut paste but if you want i can manually type them
<calc> startx for example is gone
<calc> also sessreg
<calc> maybe i have to manually install all the broken out parts due to someone forgetting to actually add them on dep line?
<schweeb> xinit <--- starts
<schweeb> *startx
<schweeb> I think
<calc> yea xbase-clients definitely doesn't depend on that
<schweeb> I just use GDM anyways
<calc> gdm won't even work apparently since sessreg isn't installed
<schweeb> but I'm pinned on a way old version of xbase-clients anyways
<calc> i tried starting x via startx and found out it was missing too
<schweeb> sessreg isn't in xutils?
<calc> no
<calc> nothing is in xutils
<calc> and xutils only depends on 3 things
<calc> i think daniels forgot to update any of the depends lines
<calc> daniels: wake up? :)
<calc> also note that most xorg things on the mirrors are -43 but those two are -42 for some reason
<calc> i've noticed the mirrors always being out of sync for some strange reason
<calc> are the mirror scripts busted?
<calc> i wonder if the missing binaries are why i can't switch out of X via ctrl-alt-F# as well
<schweeb> calc: downgrade to -42
<schweeb> worked for me
<schweeb> just rebooted
<schweeb> and no, the missing binaries are not it
<calc> xbase-client and xutils -42 is the one with the missing binaries
<calc> there is no -43 of them on the mirrors
<schweeb> err
<schweeb> I meant downgrade to -41
<schweeb> and to switch VTs
<schweeb> alt+sysrq r
<calc> where are the old -41 packages?
<schweeb> then alt+f1
<schweeb> on my hard drive :p
<schweeb> if you had -41 ever installed, should be in /var/cache/apt/archives
<calc> heh xinit 1.0 has startx but then doesn't start gnome it just starts 3 xterms, heh
<calc> schweeb: i don't have enough spare space to keep old debs around
<schweeb> *shrug*
<schweeb> my archives are only 529MB
<schweeb> IMO you need to, if you're running breezy
<schweeb> if you don't have half a gig free, you've got other problems
<calc> i'll just reboot into xp
* calc back
<mrd`> schweeb: Not if you run 'apt-get clean' ever.
<schweeb> mrd`: hrm?
<mrd`> apt-get clean empties out /var/cache/apt/archives
<schweeb> right
<schweeb> which is silly, if you're running breezy
<schweeb> a) the pkg manager applet does it for you on a weekly basis iirc
<schweeb> b) you need old pkgs for when stuff breaks
<mrd`> Yeah, yeah, this is the first time I ever tried running unstable.
<mrd`> calc: Also, xbase-clients and xutils aren't out of date, they're just not built from the xorg source package anymore.
<calc> so they don't technically exist anymore?
* calc has run debian unstable for ~ 7 years
<calc> switched to ubuntu late last year
<mrd`> The binaries normally included in those packages are being split out into their own packages.
<calc> mrd`: yea but for upgrade reasons there needs to be something that pulls them in somewhere
<calc> or at least x-window-system-core needs to depend on them individually
<mrd`> calc: I know, and I'm sure the Xorg maintainers know that too.
<calc> x-window-system-core currently depends on both of those non-existant packages still
* mrd` shrugs
<mrd`> I just know what daniels has said.
<daniels> calc: xutils and xbase-clients are no longer built from xorg
<Lathiat> daniels: sooooo... whens xutils gonna work? ;)
<daniels> xutils isn't hugely interesting to me right now; there are more important things
<daniels> anything in particular?
<Lathiat> xmkmf
<Lathiat> for this crack smoking package
<Lathiat> that i want to fix, and needs it to build :)
<daniels> that's a Hard Problem
* Lathiat sigh
<Lathiat> next package
<daniels> it'll probably happen next week
<daniels> it's just behind 'stuff you need to make your desktop workable' and 'make xorg clean-upgradeable from hoary and clean-installable from scratch' on my TODO is all
<calc> daniels: how are upgrades going to work with those two packages not really existing anymore?
<Lathiat> daniels: yeh no problems
<Lathiat> daniels: you know changing font dpi doesnt work so well right?
<calc> perhaps the reason gnome broke on my system wasn't due to all the missing files from xbase-clients and xutils, but it was complaining about sessreg in the log
<fabbione> morning
<daniels> Lathiat: i can imagine that
<daniels> calc: well, eventually xb-c and xutils will become metapackages
<Lathiat> well, good thing i didnt get 1920xsomething @15.4" then :)
<daniels> calc: but the seeds will also get updated
<infinity> daniels : Oh, BTW, was /usr/lib/X11/locale supposed to disappear with the last libx11 upload, cause it very much didn't (just a bunch of spewed messages about the inability to remove non-empty directories, and a bunch of files now owned by no packages..)
<daniels> infinity: no, not at all.  something about turning symlinks into directories being difficult ...
<jasoncohen> does ubuntu have anything similar to Debian's package tracking system which allows you to get up to the minute info on a source package?
<daniels> infinity: if all your programs don't bitch and say OMG NO LOCALES WTF when you start, then you have nothing to worry about
<infinity> Symlinks to directories have to be handled kinda backwards from directories to symlinks.
<jasoncohen> http://packages.qa.debian.org/ is what i was referring to
<infinity> daniels : My programs are fine, since I only have breezy in chroots at the moment. :)
<infinity> daniels : I'm not retarded.  I'm waiting until after feature freeze to start running breezy on my desktop.
<daniels> heh
<fabbione> daniels: did you upload libXcursor recently?
<daniels> fabbione: er, I think to get rid of _XOPEN_SOURCE ... why?
<fabbione> i think that it did reintroduced temporary the libXcursor.la thingy
<fabbione> or one of the package hasn't been B-D versioned properly..
<fabbione> i did build kdelibs way later than the other arches
<fabbione> and i got libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive
<fabbione> checking now what is still bringing it
<daniels> oh, I removed libXcursor.la
<fabbione> probably something on sparc still knows about it
<fabbione> that can only happen if there is a wrong versione B-D or uncatched
<infinity> Install kdelibs' build-deps, and rgrep Xcursor.la /usr/lib
<fabbione> infinity: that's what i am already doing :)
<fabbione> i think it's going to take me less time to rebootstrap breezy than to fix it
<infinity> (Note that tightly versioned build-deps, while handy for the buildds RIGHT NOW, won't make a likc of difference for bootstrappability, because the problem can't "come back" once all the old sources are gone)
<infinity> s/likc/lick/
<fabbione> infinity: yes. given that you build everything in the right order and everything is B-D properly
<fabbione> but if there are leftovers it makes a difference
<infinity> You can definitely build everything in the right order now, afaict.
<fabbione> infinity: not gnome..
<fabbione> because gnome apps didn't get versioned B-D love
<fabbione> only the libs
<infinity> It's just building against a slightly older breezy (say, a few weeks) that might not be perfect.  I'm not sure if that's worth caring about, but if you find things that should have tighteneed build-deps, let me know.
<fabbione> and that's not even completely true
<fabbione> infinity: gtk+2.0 was supposed to have B-D to avoid old binpackges with _XOPEN
<fabbione> fact is that it did build on sparc and still had XOPEN
<infinity> Probably because one or two X libs got missed, those I fixed later.
<fabbione> libqtmcop.la:dependency_libs=' -L/usr/share/qt3/lib -L/usr/lib /usr/lib/libmcop.la /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libqt-mt.la -L/usr/X11R6/lib -lXcursor -lXft -lfreetype -laudio -lXt -lXi -lXrandr /usr/lib/libXcursor.la -lXfixes -lXinerama /usr/lib/libXft.la -lXrender /usr/lib/libfreetype.la -lfontconfig -ldl -lpng -lz -lXext -lX11 -lSM -lICE -lpthread'
<infinity> I didn't bother reuploading gtk+, cause it was fine on the release arches.
<fabbione> so it's libarts carrying it
<infinity> Did Riddell not bother to version his build-deps when he reuploaded arts to fix that? :/
<fabbione> apparently no
<fabbione> infinity: do you want to do that or shoud i just reupload?
<fabbione> the latter will work now...
<fabbione> but still
<infinity> I'm more concerned about scorched earth / autotest, than I am about "can we build against a hypothetical breezy of 3 weeks ago?" test, so if we pass the former, cool.  If we don't, then we can tighten things to make sure we do.
<infinity> I don't much care about the latter.
<fabbione> infinity: this stuff is invisible on the buildds
<fabbione> because they are just too fast
<fabbione> (not that's bad...)
<fabbione> infinity: didn't you notice that people don't even prebuild the pkgs for testing?
<fabbione> they just keep uploading until it does build?
<fabbione> that
<fabbione> that
* fabbione hits the keyboard
<fabbione> that's just not the way it should be...
<infinity> fabbione : Right, but the question is "can the problem come back if we build from scratch?" (and the answer is "no").  We could spend months trying to support "building every package against every possible combination of build-deps that used to be in breezy but aren't anymore".
<infinity> And yes, I've noticed that a lot of uploaders don't prebuild. :/
<fabbione> infinity: yes, i understand and agree
<infinity> Not much I can do about that, except maybe not-for-us someone's pet package until they listen to reason.
<fabbione> but that makes normal building a pain
<fabbione> infinity: i am thinking about micro-ubuntu and stuff like that
<fabbione> if we start building in the wrong order on old machines
<fabbione> bam.. game is finished even before starting it
<fabbione> because we might not be in the condition to efford (time wise) a rebuild
* infinity looks at Keybuk's apparent activity on -changes, and wonders who's doing merges without updating changelos today. :)
<infinity> changelogs, too.
<crimsun> infinity: sorry, I'm guilty
<dholbach> hey
<dholbach> how's the review day coming on? :)
<ajmitch> hi dholbach 
<dholbach> ajmitch: hey andrew :)
<crimsun> hey daniel :)
<dholbach> hey daniel! how's it going?
<crimsun> not bad, did some merging yesterday and today. How are things with you?
<dholbach> i'm fine... thanks - just giving my thesis a break for the review day :)
<crimsun> nice break :)
<dholbach> yeah... the lists are overfull :)
<crimsun> indeed
<dholbach> morning JaneW :)
<doko> elmo: please sync discover (v2, universe) from unstable, the ubuntu patch isn't needed anymore (ack from daniels)
<dholbach> morning doko
<doko> morning all (and dholbach ;)
<dholbach> jsgotangco: morning jerome :)
<jsgotangco> dholbach: hi! how have you been doing?
<dholbach> jsgotangco: nicely, thank you - today is review day, so i take a small break from thesis writing :)
<dholbach> how are you?
<jsgotangco> dholbach: well don't puke, but i've been busy learning rails..hehehe..other than that, we have a meeting later at 14utc
<dholbach> why should i puke? :)
<jsgotangco> heh
<jsgotangco> dholbach: how is school?
<dholbach> jsgotangco: i'll run to university later to see, how my last exam went (maybe they have the grade lists already), and now there are 3 weeks left for writing/hacking the rest of my thesis - i'm quite confident, although it will mean some additional night sessions :)
<pitti> Good morning, world!!!
<fabbione> hey pitti
<pitti> argh, ENETWORK, brb
<bob2> hm, I hope I didn't give pitti my bad network karma
<dholbach> hey pitti! :)
<pitti> Hi dholbach, how's your diploma?
<dholbach> bob2: mvo suffered yesterday as well
<pitti> Moin doko
<dholbach> pitti: in a small break for review day, but going on nicely :)
<pitti> good
<dholbach> pitti: how are you?
<dholbach> Unfrgiven: morning ankur - long time no see!
<pitti> dholbach: fine, after a nice evening with my gf yesterday; now ffox has me back :-)
* dholbach comforts pitti
<pitti> dholbach: oh, it's not so bad any more, I only have to update the locale packs now; ffox itself works. YAY :-)
<dholbach> woohoo!
<pitti> JaneW: Just read Jaime's reply, that's reassuring. :-)
<Treenaks> pitti: except for the not-yet-discovered bug in the locale system ;)
<pitti> yay, Debian uploads are back
* pitti pokes Treenaks 
<pitti> ogra: cool, David seems interested in the lsb patch; is the namespace change any problem for you?
<tepsipakki> seb128: gnome-screensaver does not allow locking the screen, because gnome-screensaver-dialog needs suid-root
<tepsipakki> maybe there is a plan to get past that?
* mvo yawns
<dholbach> morning mvo :)
<pitti> hi mvo
<mvo> morning dholbach, morning pitti 
<mvo> pitti: do your X umlauts work again? 
<dholbach> pitti: i installed xkbdutils, xkeyboard-config and xinit and i was fine again :)
<pitti> mvo: no, broken as usual
<pitti> dholbach: already tried that, no luck
<dholbach> pitti: what helped me was going through the list of packages with maintainer "daniel stone" in synaptic - maybe you find something else *fingers crossed*
<daniels> pitti: have you installed xkeyboard-config with --force-overwrite?
<pitti> no
<daniels> pitti: does setxkbmap -rules xorg -layout 'de(nodeadkeys)' -model pc105, help?
<daniels> pitti: right.  xlibs trashed some of xk-c's conffiles, so reinstall the most recent version with --force-overwrite.
<pitti> I upgraded to xk-c 0.5-3
<pitti> $ setxkbmap -rules xorg -layout 'de(nodeadkeys)' -model pc105
<pitti> Couldn't interpret _XKB_RULES_NAMES property
<pitti> Use defaults: rules - 'xorg' model - 'pc101' layout - 'us'
<pitti> daniels: it even lies; z and y are German, things like . : , ; too
<pitti> daniels: but I can't get an at, pipe, backslash, and umlauts
* daniels frowns.
<daniels> try setxkbmap -rules xorg -model pc104 -layout de
<daniels> er, pc105
<daniels> not pc104
<pitti> oh, now it works
<pitti> even with your first command
<pitti> I reinstalled xk-c again
<pitti> thanks, mate
<daniels> pitti: no worries
<daniels> pitti: now you can use all those crazy extra letters :)
<daniels> like  and 
<dholbach> it took me a minute to find a \ somewhere to write \sh's nick yesterday :)
<dholbach> (before i managed to fix X for me again. :)
<mvo> (backslash)sh :P
<dholbach> exactly :)
<daniels> of course, the real fix there is for sh to make his nick sensible ...
<dholbach> mvo: ^^ wasn't that your exact words? :)
<pitti> daniels: not having |, \, and @ hurted me much more ...
<Treenaks> pitti: @ = shift+2 :)
<Treenaks> pitti: on US
<pitti> Treenaks: that's " on my keyboard
<Treenaks> pitti: like on most European local kbs
<Treenaks> pitti: is the "@" key left of "1" or is that a "logical not" key?
<daniels> @ is altgr+q on a german keyboard
<Treenaks> daniels: *eek*
<fabbione> maswan: ping?
<dholbach> see you later - HAPPY REVIEW DAY!
<sivang> morning all
<pitti> Good morning Sivan
<sivang> pitti: Hey Martin, still very secure ? :)
<pitti> it gets better :-)
<sivang> daniels: morning, how are you and Xorg today? :)
<sivang> pitti: do you know if there is a way to split and already made patch that touches 2 files , into 2 seperate patches ?
<sivang> s/and/an/
<pitti> sivang: vi :-)
<pitti> sivang: just split them in an editor, it's pretty obvious
<sivang> pitti: ok, what should I look out from in doing this?
<pitti> look at the patch, it's obvious
<sivang> pitti: ok, thanks
<jani> sivang, for more complicated cases there's filetrdiff from patchutils
<jani> filterdiff
<sivang> jani: ok, I will look into it if I fail taking the obvious approach :)
<dholbach> re
<fabbione> Kamion: i just uploaded kernel+linux-meta with ABI change...
<fabbione> Kamion: do you want me to upload d-i too?
<seb128> hi dholbach
<dholbach> hey seb128 :)
<fabbione> hey seb128 
<fabbione> seb128: i did a dummy upload of gtk+2.0 to get rid of the XOPEN
<fabbione> no code changes or nothing
<fabbione> only an extra entry in debian/changelog
<seb128> you did an upload you are the maintainer now
<seb128> please update the gtk 2.7.4 now :)
<seb128> wasn't a binary upload good for that?
<fabbione> seb128: i prefer to avoid binNMU where possible
<fabbione> specially because ubuntu2 was around in the archives
<seb128> k
<seb128> I'll do an upload of the new version this morning
<seb128> bah, the autobuilders are fast and users can use their bandwidth a bit :p
<fabbione> seb128: it's already all over :)
<seb128> doko: PING
<sto> Kamion: have you implemented something to have languagepacks on the ubuntu debian-installer?
<mvo> hello seb128 
<seb128> hi mvo
<sto> Kamion: I have a proposal for debian but I want to know if there are other proposals/implementations
<dholbach> seb128: could you add a KILL button to evolution? "exit" doesn't seem to be enough these days ;)
<maswan> fabbione: pong
<fabbione> maswan: i think it's time to change kernel to buttercup...
<fabbione> it died again :(
<fabbione> maswan: i will have a kernel in an hour or so.. it's building right now
<\sh> hmmm...firefox + flash == crash ,-)
<seb128> dholbach: evolution --force-shutdown
<dholbach> seb128: ah i see, thanks :)
<pitti> \sh: you have main upload rights now, go ahead and fix it :-)
<maswan> fabbione: neat
<fabbione> maswan: i will ping you back as soon as i am ready to install it
<maswan> fabbione: ACK
<fabbione> maswan: leave buttercup down for now..
<fabbione> it's more time it takes to stop the buildd than for me to finish the kenrel :)
<ogra> pitti, namespace change ? thats a nobrainer :)
<ogra> morning
<pitti> right
<pitti> Hi ogra
<ogra> pitti, did someone talk to you about dbus 0.35 ? 
<pitti> ENOTIME
<ogra> pitti, ok
<pitti> daniels: do you happen to know about dbus 0.35?
<ogra> pitti, the consensus was that we want it if there are no strong objections from your side... seb128 needs it for the new totem for example
<pitti> ogra: as long as it doesn't break the API, I'm fine for it
<pitti> ogra: if it merely breaks ABI (which it shouldn't either) then recompiling apps would be fine, too
<ogra> pitti, it breaks the python api slightly it seems.... so our hal deviace manager would spill errors... 
<pitti> ogra: is it fixed upstream?
<ogra> with 0.5.3
<pitti> ogra: I wouldn't mind upgrading to 0.5.3, it has lots of bug fixes anyway
<ogra> which is not in debian 
<ogra> ok
<pitti> ogra: sjoerd is on vac, but it's not a biggie to upgrade the Ubuntu versoin
<ogra> pitti, mdz already agreed, but we wanted to hear you
<pitti> oh, cool
<pitti> ok, let's get the new crack :-)
<ogra> thats awesome... so hughsie can make g-p-m eady for us :)
<ogra> ready even
<Kamion> fabbione: it's ok, I'll do it in a moment
<Diziet> Morning people.
<Kamion> sto: no, I really don't want to go anywhere near that; the installer is complex enough without introducing complexity which in my view is unnecessary
<ogra> hey Diziet 
<pitti> Hi Diziet 
<Kamion> sto: I know Petter posted a udpkg (?) patch recently to make tricks like that a little easier
<sto> Kamion: well I need to support a non standard locale, so I have to do it or recompile everything
<Kamion> our approach has been to get the translations into the mainline instead, as they end up better maintained that way anyway
<Kamion> also you probably won't be able to use anything like language packs for the first half a dozen screens or so no matter what you do
<Kamion> well, not without awful initrd hacking
<sto> Kamion: why not?
<sto> I'm doing it
<Kamion> huh, ok
<Kamion> again, don't want to touch that if I can possibly help it :)
<sto> I simply did a wrapper around debconf-loadtemplate
<Mez> elmo: ping
<Kamion> but you clearly had to hack the initrd to get the extra templates in there; they can't just have been loaded with udpkg
<Kamion> because udpkg isn't called until half a dozen or so screens in
<Kamion> infinity: yo, you broke the seeds archive
<sto> Yes, I've put the templates on an udeb package that is installed on the initrd
<fabbione> Kamion: perfect...
<fabbione> Kamion: the kernel is still building on the buildd...
<Kamion> infinity: chmod -R g+w /home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0/patch-79/++revision-lock on chinstrap, please
<Kamion> infinity: and put 'umask 002' in ~/.bashrc somewhere where it will be used by noninteractive shells
<sto> But udpkg is called before excuting the first screen
<Kamion> no it isn't - debconf-loadtemplate is
<Kamion> to load the initial set of templates
<sto> Oh, well, I've changed debconf-loadtemplate
<sto> I thought it was called by udpkg
<sto> as it worked I have not looked too much into it
<fabbione> what was the the C function opposite to atoi?
<fabbione> to convert an integer to a string?
<fabbione> i guess i can just use sprintf :)
<ogra> :)
<Treenaks> fabbione: you could link in a python interpreter to do it for you
<fabbione> rhhrhr
<fabbione> ehhe
<Kamion> sto: rootskel calls it directly
* davyd wanders in
<davyd> is it a known issue that I can't start gnome-session
<davyd> or have I broken something?
<seb128> davyd: update to 0ubuntu3
<davyd> how long till that is in the tree?
* davyd runs update now
<seb128> should already be
<davyd> ok
<seb128> davyd: you can also edit /usr/share/gnome/default.session and fix the numbers
<davyd> well, let me get updated versions of things
<seb128> davyd: you need to update the number of the id=default<n> lines
<seb128> davyd: gnome-smproxy has been dropped and I've screwed when changing the entries numbers ... it's fixed with 0ubuntu
<seb128> 0ubuntu3
<davyd> ok, got the new version
<seb128> cool
<davyd> let's see what else broke
<davyd> does -panel also have known issues?
<seb128> davyd: nop, why? what does it do?
<davyd> it would appear to be hanging
* icaro re
* pitti finally releases warty ffox update - YAY
* icaro is listening to: Tristania - Pale Enchantress
<Kamion> elmo: please sync libdebian-installer from Debian incoming (approved by mdz)
<davyd> hmm, now it works
<Kamion> icaro: I hope that isn't a script
<icaro> Kamion, i'm doing a script to control amarok from xchat :D
<icaro> i'm just trying it
<Kamion> icaro: please disable it for this channel
<icaro> ok...
<Diziet> Why oh why oh why oh why does Gnome need the network to be working for it not to wedge when you log in ?
<davyd> Diziet: it doesn't
<davyd> you may just have been bitten by the bug I was
<davyd> upgrade gnome-session to ubuntu3
<Diziet> I'm using the colony 2 CD install and haven't upgraded anything yet.
<Lathiat> Diziet: you however need a loopback interface
<davyd> that is true
<Lathiat> Diziet: and if you dont have a loopback interface your system is broken :)
<davyd> and localhost should be in your /etc/hosts
<davyd> that may break session handling
<Diziet> In fact it turns out that I _do_ have a working network.  There must be some other reason it's wedged.
<davyd> Diziet: have you checked what version of gnome-session you're running?
<Kamion> colony 2 was 2.11.1-0ubuntu1
<Diziet> davyd: ... ah, Kamion has told you.
<Lathiat> It's quite possible that CD was broken
<Kamion> Lathiat: in what sense? it worked fine in my tests
<Kamion> or I wouldn't have released it
<Lathiat> Kamion: yeh but something could be upsetting it
* Diziet waits for the upgrade.  Joy.
<hughsie> ogra: I'll repeat the question: do you not sleep? :-)
<ogra> hehe
<hughsie> ogra:pitti been about
<hughsie> ?
<ogra> i have to fix my lsb patch for david ;)
<hughsie> ogra: i saw your message
<ogra> hughsie, yes... and it seems we'll also have 0.5.3 :)
<hughsie> ogra: better upstream than patched tho
<hughsie> 0.5.3, yay!
<ogra> yep
<hughsie> okay, let me glib-fy g-p-m
<ogra> yeah :)
<hughsie> first on my hitlist, libhal has to go
<Diziet> Hrmf.  We don't have resolvconf in Breezy it seems.
<jdthood> Diziet: I'm glad you brought that up.
<jdthood> thom tells me that you are now taking care of network-manager.
<jdthood> I'd like to get n-m playing nicely with resolvconf
<Diziet> Um!  I'm only here on Thursdays, to a first approximation.  So perhaps me being in the `middle' so to speak is not ideal ...
<Diziet> n-m> Quite so.
<Diziet> Are we going to have resolvconf then ?
<jdthood> I don't know.  I am just the author/debian maintainer
<jdthood> Currently n-m Depends on resolvconf, so if n-m is going to be in Breezy then so should resolvconf, obviously
<Diziet> I missed the bit in the n-m source code where it drives resolvconf.
<jdthood> It doesn't, SFAIK
<Lathiat> i thought it does
<Diziet> So in what sense does it depend on it ?
<Lathiat> but like
<Lathiat> it was using bind9
<jdthood> The package Depends on resolvconf
<Lathiat> and writing out a config for it
<Lathiat> so i dont really see the use for resolvconf in that situation
<Diziet> jdt: Yes, but why ?
<Diziet> lath: Quite so.
<Lathiat> other than that using bind9 like that is crack
<Diziet> Um, yes, we should get rid of bind9.  We're going to use dnsmasq instead.
<Lathiat> ok so even still
<Lathiat> using dnsmasq, resolvconf has no purpose
<Diziet> If dnsmasq turns out to be too broken we can probably fix something up quickly that'll be better than nothing.
<jdthood> dnsmasq works very well
<Diziet> lath: No, it has the purpose that the patch we have to make to n-m isn't silly.
<Diziet> jdt: Oh, good :-).
<jdthood> And it already works with resolvconf
<Diziet> If we make n-m drive resolvconf then all `just works' ha ha.
<jdthood> s/ha ha//
<Lathiat> Diziet: it just works with bind9/dnsmasq
<Diziet> There's code to drive dnsmasq in there ?  Did I miss that ?
<Lathiat> for bind9
<Lathiat> dnsmasq isnt done yet afaict
<Diziet> Yes, I saw the code to drive bind9.  That's just barmy.
<jdthood> dnsmasq has been around a long time.  It's stable.
<jdthood> And resolvconf already drives it.
<jdthood> So all n-m has to do is call resolvconf to tell it the nameserver addresses obtained via DHCP.
<jdthood> ... by n-m's private DHCP client.
<Diziet> The right answer is for n-m to speak to resolvconf.  Then (a) our stuff just works nicely and (b) people who aren't using dnsmasq can do something else 'cos resolvconf gives a sensible interface.
<Diziet> jdt: Right.
<jdthood> This also provides for graceful starting and stopping of n-m.
<Lathiat> except that that doesnt actually work
<jdthood> Lathiat: what doesn't work?
<Lathiat> jdthood: if you stop n-m, starting it again results in it being useless
<Diziet> Starting and stopping of n-m ?  Why would it want to start and stop ?
<jdthood> Oh.
<Lathiat> Diziet: because if i want to do my own thing with the interfaces
<Lathiat> if i dont stop n-m, it eats them
<Diziet> Oh, I see.  Yes, that makes sense.
<Diziet> So you're saying that when you start it again it doesn't work for some reason.
<Lathiat> right
<Lathiat> at least a few weeks ago
<jdthood> Well, it is beta software.
<jdthood> Not even.
<jdthood> It's improving quickly, though.
<Lathiat> elmo, infinity: can i get lathiat@bur.st whitelisted for changes?
<Diziet> So who's doing the resolvconf package for Breezy ? :-)
<ogra> Lathiat, see the Uploads wikipage... send a mail
<Lathiat> ogra: oh ok
<Kamion> resolvconf hasn't been branched for Ubuntu yet; we can keep on syncing jdthood's uploads from Debian if that makes sense
<Kamion> or otherwise cherry-pick patches
<Diziet> How does this relate to dbus ?
<Diziet> k: `keep on syncing'> Does that mean it's there already ?  /me looks.
<Kamion> Diziet: in universe, yes
<Kamion> resolvconf |       1.29 | breezy/universe | source, all
<Kamion> it'd have to be promoted to main for use with n-m, but that's relatively straightforward
<Diziet> Oooooh!  The light dawns!   universe isn't in the default sources.list !
<Kamion> correct
<Diziet> No wonder I was having so much trouble.
<Lathiat> daniels: ping
<Kamion> deliberately so - it's formally unsupported (although much less so now than it used to be)
<dholbach> brb
<jdthood> You needn't fear big changes in resolvconf from now on.
<madduck> jdthood: come on! WINS integration!
<madduck> jdthood: /etc/hosts generation!
<Burgundavia> pitti, you poor man http://bugzilla.ubuntu.com/show_bug.cgi?id=13041
<pitti> Burgundavia: well, I needed to have the new version in the archive anyway to rebuild against them
* seb128 cries
<seb128> k, guys, somebody need me what is to do with firefox?
<seb128> or I just revert doko's .pc changes
<pitti> seb128: for warty I guess we just need to rebuild it
<seb128> it breaks GNOME builds, and I'm too busy to start repacking libnss, firefox or whatever
<seb128> doko: PING
<seb128> pitti: opinion on this?
<pitti> seb128: about epi build-deps? design-wise, b-dep'ing on and using libnspr4-dev is the right thing
<pitti> seb128: but if that breaks, then just leave it as it is for now
<seb128> it's b0rked now
<seb128> doko has dropped firefox .pc files
<pitti> "now" -> before that
<seb128> and epiphany, totem, devhelp, yelp etc look for that
<seb128> so I just put the .pc files back?
<pitti> can we patch mozilla's libnspr4 lib somehow to make it work?
<pitti> like, copy ffox' one
<seb128> I've no clue, and I've way too many work already
<pitti> we all have, I guess
<seb128> yeah, so not time to break firefox
<seb128> if nobody is going to fix it
<pitti> seb128: I'd revert the change until libnspr4-dev is fixed to work with epy & co
<seb128> and we need to have GNOME building
<seb128> k, thanks
<pitti> but we should keep it in mind, doko wrote the Debian guys IIRC
<seb128> the reply from the Debian maintainer is:
<seb128> "There also may be subtle bugs
<seb128>         exposed by using combinations of versions of nss, nspr + {firefox, mozilla,
<seb128>         thunderbird} that aren't as well tested. I don't know the development
<seb128>         well enough to say whether that is likely to be a problem. "
<pitti> I read that, yes
<seb128> that's not time to do this changes if people are to busy to work ont his imho
<seb128> grumpf
<seb128> "that's not the time to do these changes if people are too busy to work on this imho"
<fabbione> maswan: i have the kernel...
<fabbione> maswan: anytime you want.. i am ready
<maswan> fabbione: ACK
<fabbione> maswan: ROCKANDROLL!
<fabbione> elmo: sparc wins again over ppc :)
<chmj> there is a cheat involved !
<sivang> fabbione: is does? :)
<maswan> fabbione: booting it now, I hope. :)
<fabbione> maswan: ok :)
<maswan> fabbione: Starting OpenBSD Secure Shell server: sshd.
<maswan> fabbione: we can try enabling the watchdog too
<fabbione> maswan: i am already copying the kernel there..
<maswan> fabbione: ack. can fix it when we reboot
<fabbione> maswan: i think it's a good idea to check 2 things in the OBP
<maswan> fabbione: the more changes you do at once, the larger the chance of total success. right?
<fabbione> maswan: clearly :)
<fabbione> maswan: there are 2 options.. one is the watchdog.. the other is the need to have a constant console connected to the serial port
<fabbione> all these hangs might be caused by that option turned on
<maswan> well, we always have a serial console on it
<fabbione> and your console server not keeping power on the ports when not in use
<fabbione> yeah. so did i.. but it was still hanging when i was reboot my machine
<fabbione> now it doesn't anymore :)
<fabbione> the only issue is that i don't remember the names of these options
<fabbione> so we need to look at them
<maswan> btw, the rsc sucks. 'Hostname:       "buttercu"'
<fabbione> ehhehe
<maswan> 8 chars ought to be enough for everybody?
<fabbione> maswan: i am checking security updates too...
<maswan> fabbione: great
<fabbione> maswan: keep an eye on the console.. rebooting now...
<fabbione> GO BUTTERCUP!
<maswan> ok.
<maswan> waiting for it to reset now
<fabbione> maswan: is it still resetting?
<maswan> hacking now
<maswan> now booting
<maswan> not hardware with a proper watchdog, it seems
<fabbione> ahh ok
<fabbione> i forgot you had to play with OBP.. sorry
<maswan> booting now
<maswan> what are the numbers?
<maswan> [   12.800158]  TCP bind hash table entries: 32768 (order: 6, 524288 bytes)
<maswan> [   12.881072]  TCP: Hash tables configured (established 32768 bind 32768)
<maswan> I've never seen that before..
<fabbione> [   12.881072]  <- ?
<maswan> yeah
<fabbione> timestamped printk
<maswan> ok
<maswan> wrapping every 16 seconds, or something like that?
<fabbione> hmm no
<fabbione> it's an abs value from boot time
<maswan> fabbione: Starting OpenBSD Secure Shell server: sshd.
<maswan> well, it goes up to ~15 then restarts from 0..
<fabbione> Linux buttercup 2.6.12-5-sparc64-smp #1 SMP Thu Jul 28 10:10:55 UTC 2005 sparc64 GNU/Linux
<fabbione> maswan: probably it's the -smp effect..
<fabbione> i dunno if the timestamp is xcpu or global
<maswan> it wrapped more than once
<maswan> [   15.634369]  EXT3-fs: mounted filesystem with ordered data mode.
<maswan> [    0.071270]  Adding 490480k swap on /dev/sda6.  Priority:-1 extents:1
<maswan> [   14.572056]  scsi0 : sym-2.2.0
<maswan> [    0.350900]    Vendor: SEAGATE   Model: ST39102LCSUN9.0G  Rev: 0828
<fabbione> yes i am looking..
<fabbione> i dunno..
<fabbione> it might be buggy on SMP
<maswan> oh, well. not particularly important. :)
<fabbione> nope...
<fabbione> maswan: i am glad to say you are the first guy running a breezy smp sparc kernel in the world afaik :P
<maswan> fabbione: whee! :)
* fabbione feels better after having at least one tester...
<fabbione> hey it also means that i don't suck so much as i tought with the kernel :)
<maswan> :)
<maswan> if you want to install breezy on it properly, we can find another 9giger or two ;)
<fabbione> maswan: i am not even sure it can be bootstrapped right now
<fabbione> we have half of gnome FTBFS due to a binutils bug
<fabbione> i am pretty sure we can bootstrap server...
<fabbione> we will switch once breezy is out :)
<maswan> fabbione: ah
<maswan> fabbione: :)
* maswan runs off
<fabbione> maswan: thanks!
<fabbione> cya later
* seb128 read his mails and understand why pitti said "<pitti> seb128: for warty I guess we just need to rebuild it" 
<pitti> seb128: that referred to the statement right before yours: <Burgundavia> pitti, you poor man http://bugzilla.ubuntu.com/show_bug.cgi?id=13041
<Keybuk> ...Microsoft have added a "Search" feature to the Start Menu...
<Burgundavia> I also saw one with a scroll bar in it
<pitti> Keybuk: I saw the menus of some people I know, it badly needs it...
<Burgundavia> the sad part is that you don't really need to do much to get it to that state
<Mez> elmo: ping
<slomo> hmm... who has broken firefox-dev, i.e. the firefox-gtkmozembed.pc file? it needs firefox-nspr but can't find it...
<slomo> ah ok, nevermind... seems to be fixed with the firefox version uploaded a few seconds ago
<mjg59_> Hm. Can anyone remember the wiki page with hotkey keycodes on?
<Burgundavia> mjg59_, yes, just a sec
<Burgundavia> https://wiki.ubuntu.com/LaptopKeycodes
<Burgundavia> mjg59_, is there any way of determining those at install time, or are we going to need to keep a giant database?
<mjg59_> Burgundavia: Thanks!
<mjg59_> It's going to need static tables, but we can work out which to use based on DMI information (in most cases)
<sivang> fabbione: I'm going to be the second ppc64 hopefully soon :)
<fabbione> sivang: too many.. send one this direction
<fabbione> ;)
<hughsie> ogra: got a minute?
<ogra> hughsie, sure
<hughsie> ogra: hi, what do you know about HAL and PropertyModified
<hughsie> I'm spotting a problem with J5's new bindings
<ogra> hmm, thats for polling, right ?
<hughsie> ogra: not polling, events of device change.
<hughsie> oops
<sivang> fabbione: I mean, pSeries :)
<Diziet> network-manager appears not to have a config file.  I wanted to add an option to it.  I suppose it'll have to be a compile-time switch.  Urgh!
<Diziet> Do Gnome people not believe in config files ?
<jdthood> They believe in gconf
<sivang> Diziet: that would be the event driven configuration database, which allows gnome to respond to config changes in a snap :)
<Diziet> gconf is only used in the vpn stuff and the applet, not in the main daemon.
<Diziet> And, also: XML config files !  *vomit*
<bddebian> Morning
<Amaranth> Burgundavia: You know mhearn == TD on GIMPNet, right?
<Burgundavia> Amaranth, yes, why do you ask?
<Diziet> Oh, and of course the daemon doesn't have access to (and shouldn't use) the gconf daemon because it's a system daemon.
<Amaranth> well, i was thinking we might want to take this discussion off the forums
<Burgundavia> Amaranth, the autopackage one in the breezy forum?
<Amaranth> yeah
<Burgundavia> Amaranth, you a forum mod?
<Amaranth> Nope.
<Burgundavia> might be best to lock that thread, as nothing is going to come of it
<jdthood> Diziet: I believe NM access gconf via the nm-applet
<jdthood> I don't know how useful the daemon is if it doesn't have an applet to talk to.
<Diziet> jdt: Ahm.
<Diziet> I think I'll make it a compile-time option.
<Diziet> It's not a think you want a pointyclicky config of, anyway, and I don't want to invent a config file.
<Diziet> s/think/thing
<jdthood> Running a system daemon that depends critically on a desktop applet isn't really the Debian way, but this is Ubuntu.
<jdthood> Things like modularity and choice don't matter here either.  ;)
<Kamion> *cough*
<Diziet> jdt: Harmf.  compile-time option> After all, that's what it currently does for whether to mess with BIND.
<Diziet> I shall be RMS and fix only some of the world's problems.
* Kamion eyes localechooser with malice, speaking of problems
<jdthood> He's root.  He's mean.  He's square.  And he's here to fix just part of the world.</moviepromovoice>
<Diziet> RMS is square ?!  Or I'm square ?  I might become offended :-).
<Diziet> Personally I think I'm more of an abstract manifold.
<highvolt1ge> If RMS is square, then dammit, I'm square too.
<jdthood> Well, no, that's true.  RMS isn't square.  Otherwise his initials would be perfect.
<highvolt1ge> PMPO
<jdthood> (He's not _really_ mean either, beneath that gruff exterior.)
<highvolt1ge> Apparently, he got a message in a dream that he should build a giant canoe and put two of each animal inside, but he misheard and thought that they said "GNU".
<seb128> elmo, infinity, Kamion: I've just uploaded a libnotify package, could you reject it?
<carstenh> JaneW: yes, he did. thanks again :)
<Riddell> elmo: apparantly kubuntu powerpc dvd torrent isn't seeded
<carstenh> pitti: do you prefer a answer via mail or irc?
<Kamion> seb128: rather than trying to figure out how to reject from queue/unchecked/ at short notice, I moved the files into broken/
<Kamion> seb128: what was wrong?
<seb128> Kamion: b0rked Build-Depends
<seb128> ie: the stock dh_make ones :p
<Kamion> heh
<pitti> carstenh: mail might be better for the other guys in cc
<seb128> Kamion: it's a NEW package
<seb128> bah, doesn't really matter, I can fix it as a -0ubuntu2 if that's easier
<fabbione> seb128: libnofity???
<fabbione> notify..
<seb128> fabbione: yeah, why?
<fabbione> it sounds so much something related to inotify
<seb128> no
<carstenh> pitti: ok, who should be in cc? jeff of couse
<fabbione> seb128: ok thanks...
<seb128> fabbione: that's a desktop stuff
<pitti> carstenh: Matt as well, please
<Kamion> seb128: oh, I didn't know, I just saw it in unchecked
<Kamion> seb128: you can reupload as -0ubuntu1
<carstenh> pitti: ok
<seb128> Kamion: thanks
<pitti> carstenh: thanks; great work so far!
<fabbione> seb128: well gamin does use inotify :) it is still a desktop stuff ;)
<seb128> right :)
<carstenh> pitti: i did not see the cc in your mail :)
<fabbione> yay.. gtk is almost built :)
<pitti> carstenh: hm?
<carstenh> pitti: i don't use my usual mailclient at the moment, so i did not see that field in the header
<pitti> carstenh: "mutt sucks less" :-); nevermind
<carstenh> pitti: just a quick question: what do you think about moving the frontend to a own package? i don't see anything about that in your mail
<pitti> carstenh: it should be a separate deb in any case, probably even a separate source package
* fabbione cheers at yet another abi change
<Kamion> what, you're going to -6?
<pitti> carstenh: I didn't assume that anyone would seriously consider to put them in the same deb anyway
<pitti> fabbione, stop draining our bandwidth! :-)
<carstenh> pitti: but not in gst as originally planned?
<mjg59_> Anyone here got an Omnibook?
<pitti> carstenh: ah, I thought you meant "separate from ubuntu-firewall"
<fabbione> Kamion: probably not me.. i am preparing stuff..
<fabbione> Kamion: but yes.. it is required..
<carstenh> pitti: both somehow
<pitti> carstenh: integration into g-s-t would rock of course, but only if upstream adopts it; and you can't use python for that
<Kamion> fabbione: sigh
<fabbione> Kamion: i can't avoid it :(
<fabbione> 8 symbols are changed..
<carstenh> pitti: they would allow python according to a file in the souce (don't remeber which one)
<sivang> carstenh: maybe you are referring to the work by garnacho on the backends,
<pitti> carstenh: oh? then you should at least write the code in a way that it would fit into the g-s-t architecture
<sivang> carstenh: he is wrapping them up to make the possiblilty of accepting commands through dbus
<JaneW> carstenh: great
<pitti> then we had perl, python, and C code in the same package, cheers
<carstenh> pitti: | Our GUI should be usable for all Ubuntu systems and its non-Gnome based derivatives (such as Kubuntu), so we decided to create our own package instead of extending gnome-system-tools.
<sivang> carstenh: so then you could write python frontends and use the g-s-t backends
<pitti> ok, fine for me
<sivang> pitti: true :)
<carstenh> sivang: just a minute, i will search that file
<carstenh> pitti: so we could skip integrating it in gst?
<pitti> if it's too difficult or doesn't fit well, sure
<carstenh> sivang: |Currently, all the backends are in Perl, all the frontends are in C, and all
<pitti> Riddell: ping
<carstenh> the frontend layouts are in Glade XML. We accept backends and frontends in
<carstenh> Python, though.
<carstenh> sivang: from HACKING in the source
<sivang> carstenh: look for liboobs
<sivang> carstenh: (mind the pun ;-)
<pitti> ouch, I read "libboobs" the first time...
<sivang> pitti: hehehe
* Kamion accidentally sets PATH=/foo rather than PATH=/foo:$PATH in a script and wonders why everything breaks
<Kamion> d'oh
<fabbione> lol
<Riddell> pitti: hi
<pitti> Riddell: I'm preparing another round of langpacks since it seems there finally is the time to upload them soon
<Riddell> pitti: split?
<pitti> Riddell: for testing kde, is there any language != English you can reasonably understnad?
<pitti> Riddell: or at least can tell "yes, this looks like lang $foo"?
<sladen> pitti: french
<sivang> carstenh: http://cvs.gnome.org/viewcvs/liboobs/
<pitti> Riddell: into gnome/kde/other
<Riddell> pitti: french is good for me
<pitti> Riddell: ok, fine, thanks
<Riddell> and I'm practiced in en_gb  :)
<carstenh> sivang: just found this url, thanks
<pitti> Riddell: "language != English" ...
<pitti> Riddell: or do you mean en_gb != english? :-)
<fabbione> wow...
<Riddell> well it has translation files
<fabbione> -23h:45m to holidays!
<pitti> I mean, you invented it before those american slang speakers...
* fabbione opens a bottle of champagne
<sivang> carstenh: I worked with garnacho before hoary, so I know few things about g-s-t, don't hesitate to ask. If I don't know I'll just say so :)
<carstenh> thanks :)
<sivang> carstenh: np
<\sh> fabbione: lucky u
<pitti> seb128, Riddell: can you please fetch the packages from http://people.ubuntu.com/~pitti/langpacks/, install them and barf if anything breaks?
* fabbione has been waiting 6 months for this holidays....
<pitti> seb128, Riddell: after upgrading the main langpack, you should get an update notification to install KDE/Gnome, too
<\sh> fabbione: oh..I'm w8ing now 1 1/2 year for holidays :) 
<mjg59_> Is dmidecode really i386 only?
<mjg59_> No amd64?
<carstenh> pitti: i think it would fit and not be too difficult. but users of ubuntu derivates (i.e. kubuntu) should be able to use the frontend too, so i would prefere a own pygtk app
<Nafallo> mjg59_: wfm @ amd64 laptop
<pitti> carstenh: right
<seb128> pitti: lemme try
<pitti> carstenh: ... as long as Kubuntu users can live with gtk :-)
<Riddell> carstenh: what's this?
<carstenh> Riddell: a ubuntu firewall gui
<sladen> mjg59_: doesn't amd64 expect you to use EFI for fetching that crap?
<carstenh> pitti: they could use gtk2-engines-gtk-qt - theme engine using Qt for GTK+ 2.x :)
<mjg59_> sladen: amd64 doens't (so far) have emi
<pitti> seb128, Riddell: hold on, please, the update notification is not working
<pitti> lemme fix that first
<carstenh> hmm, jeff is not here :/
<seb128> pitti: it has worked here
<pitti> seb128: translations? or the notification? or both?
<seb128> pitti: I got the little light bubble with the msg you gave me to translate some time ago :p
<pitti> seb128: ah, cool. In French even?
<seb128> no, did I send the translation to you?
<pitti> seb128: erm, no
<seb128> what I though
<seb128> let me find it :p
<pitti> seb128: do you have sane gnome translations now?
<Riddell> pitti: is it possible to get the charset entry.desktop and flag.png files in the kde-langpacks?  otherwise the user can't choose the language
<seb128> pitti: works fine with GNOME here
<pitti> Riddell: shouldn't be too hard
<pitti> Riddell: I can add some "additional-files" facility into langpack-o-matic
<seb128> pitti: how does this notification stuff works?
<pitti> seb128: /var/lib/update-notifier/user.d/language-pack-de_20050701
<seb128> pitti: ie: I've installed the language pack updates, I got the notification, read the message, installed the gnome languagepacks
<pitti> seb128: that's generated by the postinst
<seb128> pitti: now I log with gdmflexiserver on an another user, and he has the notification too
<seb128> but I've already installed the packages, etc
<pitti> seb128: that's the current design of those notifications, sorry
<seb128> no pb, just curious :)
<pitti> seb128: it immediately appear in all current sessions
<seb128> that's not a current session
<seb128> I've opened it after installing the language packs
<pitti> seb128: oh, hm
<seb128> that mean that a new user will get all the stuff listed on his first loggin?
<seb128> ie: 6 months of notifications? :)
<pitti> mvo: ^
<pitti> mvo: would it be possible to deactivate a notification once *one* user handled (i. e. has seen) it?
<jani> ping elmo
<jani> xfce sync reminder, thanks
<mjg59_> seb128: Around?
<pitti> seb128: oh, update-manager is not running in my session, that's why it doesn't work for me
<lamont> Kamion: at the very least, the ramdisk_size=8192 needs to go from elilo.conf (since the initrd is >9MB atm(
<seb128> mjg59_: pong
<seb128> pitti: oh, k :)
<mjg59_> seb128: So I have a list of laptop keycodes that should be bound to gnome events by default
<pitti> seb128: but that's a bug for mvo, so nm
<seb128> pitti: wait for the translation :p
<pitti> seb128: I have to wait for the Rosetta tarball
<seb128> mjg59_: the gnome-settings-daemon stuff?
<pitti> seb128: and I want to have a final word with mdz
<mjg59_> seb128: Easiest way to do this may be to change the default values in the schemas?
<seb128> k, so I've time :)
<mjg59_> seb128: Yeah
<pitti> seb128: if we can avoid splitting the langpacks, then it would be even better, but that depends on the rosetta activity (I need the tarball for that)
<seb128> mjg59_: yeah, changing the schemas seems to be the right way for that
<mvo> pitti: disabeling it globally once one user has seen it is tricky because the file is stored in /var/lib/update-notifier/user.d
<pitti> mvo: so what do you propose? we have the same problem with the kernel notes - they still appear even after I actually rebooted
<mjg59_> seb128: Ok - I'll send you a list of which keys need changing and what to?
<mjg59_> Or should I just file a wishlist bug?
<mvo> pitti: a small suid application that can remove notifications?
<pitti> eek
<pitti> well, ok, would work
<Riddell> "The Application "update-notifier" has quit unexpectedly."  oh well
<pitti> mvo: would that generally be what we want? declare a notification as handled once the first user sees it?
<seb128> mjg59_: best option is a patch for the schemas, but a list of keys would be fine too I guess :)
<seb128> mjg59_: put that to bugzilla please, easier to keep track of it this way
<mjg59_> seb128: I can't download new packages at the moment, so I'll have to work off the latest I have here - probably not simple to patch
<seb128> the schemas has not changed for ages
<Riddell> pitti: which packages is the /var/lib/update-notifier/user.d file in?
<pitti> ok, so who uninstalled update-notifer on my box???
<pitti> Riddell: it's generated dynamically in the l-p-<lang> postinst
<Riddell> ah hah
<seb128> mjg59_: anyway just put the list if that's easier for you, I'll patch the .schemas
<pitti> Riddell: we can't just ship it since we don't show it if we have a more recent version
<mjg59_> seb128: Cool, thanks
<seb128> np
<Kamion> lamont: ok, I've doubled that in debian-cd
<Riddell> pitti: hmm, I don't see anything in /var/lib/update-notifier/user.d/  after installing all 6 packages
<pitti> Riddell: did you have installed a langpack before?
<lamont> Kamion: the kernel is compiled (ia64) with a default ramdisk size of 32768
<Riddell> pitti: I don't think so
<pitti> Riddell: the note doesn't appear on fresh installs since it wouldn't make sense for them
<pitti> Riddell: this is meant for the hoary->breezy update transition
<pitti> Riddell: so it's actually behaving correctly
<Riddell> pitti: so it checks for a previous langpack-kde-fr?
<Diziet> Spot the problem:    syslog (syslog_priority, message);
<pitti> Riddell: no, for an older l-pack-fr
<pitti> Riddell: for cross-checking, can you purge all packages, install the current breezy version, and dpkg -i them again?
<Kamion> Diziet: format string bug?
<Diziet> How did you guess ?  Just looking to see if it's exploitable.
<Diziet> Who knows.  It sets this thing as the glib logging handler function.
<Riddell> pitti: "Name: Language pack reorganization" has now appeared in user.d
<Riddell> pitti: should langpack-kde-xx-base not have  Replace: kde-i18n-xx ?
<mdz> morning
<mdz> pitti: you need to talk with me?
<wasabi_> Oooh. I like xchat-gnome.
<mdz> Diziet: how is network-manager?  is it going to make it for feature freeze?
<Diziet> What's the feature freeze date ?  (Am I supposed to have known?)
<mjg59_> 11th August
<Diziet> I'm going to have the resolvconf integration finished today.
<Kamion> Diziet: http://udu.wiki.ubuntu.com/BreezyReleaseSchedule, FYI
<Diziet> We're going to run dnsmasq from that.
<Diziet> k: Ta.
<Kamion> er, or not, apparently moved, but you can see that for yourself
<Diziet> Quite so :-).
<Riddell> Diziet: does network-manager have a KDE frontend?
<Kamion> elmo: ping, re libdebian-installer sync
<Diziet> rid: Not AFAIAA.
<Diziet> I note that we seem to be in `UpstreamVersionFreeze' already.  Does that mean we're not supposed to add new packages from universe into main ?
<Diziet> 'cos network-manager is currently in universe.
<Burgundavia> no
<Diziet> Good :-).
<MagnusR> df
<Amaranth> i love freenode!
<Amaranth> i'm throttled right out of #ubuntu, great
<tseng> http://udu.wiki.ubuntu.com/GetOffFreenodeSpec
<dilinger> jbailey
<dilinger> er
<Amaranth> tseng: It'll never happen.
<Kamion> Diziet: no, it's purely about what we import into Ubuntu (main or universe) from elsewhere, although we do start getting more cautious after UVF. Feature goals tend to be obvious exceptions, though.
<Amaranth> tseng: You'll just split the users.
<pitti> mdz: Good morning; sorry, was at the phone
<mdz> pitti: morning
<seb128> hi mdz
<pitti> mdz: I wanted to talk about the final solution for langpacks, but I need numbers for that, and to get them I need the hoary tarball from Rosetta
<seb128> infinity: could you kick epiphany-browser with the current firefox package?
<pitti> seb128: binary nmu?
<seb128> pitti: what binary nmu? it ftbfsed because of the .pc stuff, I want a retry with the new package
<pitti> seb128: ah, ok; I thought you want to rebuild against the 1.0.6 api, sorry
<seb128> oh, no ... somebody has a warty box to try this one? :)
<pitti> seb128: I tried quickly in a chroot, but epy doesn't work in a chroot
<pitti> seb128: "Bonobo couldn't locate the GNOME_Epiphany_Automation.server file. You can use bonobo-activation-sysconf to configure the search path for bonobo server files."
<pitti> seb128: that's the only thing I get if I start epi in a warty dchroot
<seb128> hum
<pitti> seb128: starting mozilla and ffox works fine
<seb128> weird
<seb128> try restarting bonobo
<pitti> seb128: I mean, the file is right there
<pitti> seb128: how?
<seb128> is bonobo-activation-server running from your chroot?
<pitti> no, I guess not
<seb128> I guess that's the issue
<pitti> can I start it manually?
<pitti> seb128: I just do export DISPLAY=:0.0 for ffox
<seb128> usually apps start it when required
<seb128> I'm not sure about this one
<pitti> seb128: in which package is this?
<pitti> $ acs bonobo server
<pitti> gchemutils - GNOME chemistry utils (common test files and binaries)
<pitti> hardly
<seb128> libbonobo2-common
<tseng> nice alias.
<seb128> /usr/lib/bonobo-activation/bonobo-activation-server 
<pitti> seb128: it's installed in the warty dchroot
<elmo> Kamion: done
<Kamion> thanks
<elmo> how usable is vino in hoary?
<Kamion> d'oh, none of my baz archives have been mirroring to chinstrap/rookery for ages
* Kamion "fixes" his configuration
<seb128> elmo: supposed to work fine, why?
<tseng> elmo: works pretty reasonably on 100baseT link
<elmo> seb128: I just remember that at some stage (probably pre-warty), it was only useful for client or something
<tseng> even used 11g
<elmo> yeah, that's what I'll be using, 80211.b
<elmo> well, unless I drag a cable.. hum.
<tseng> it does use XDamage
<tseng> so it might not be that bad
<tseng> theoretically only redraws damaged bits
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<slomo> hmm, does somebody know how to use DEB_SHLIBDEPS_INCLUDE with cdbs? i use "DEB_SHLIBDEPS_INCLUDE := debian/libwavpack0/usr/lib" but this leads to -l :debian/libwavpack0/usr/lib and this warning: "Use of uninitialized value in scalar assignment at /usr/bin/dh_shlibdeps line 138, <COMPAT_IN> line 1."
<pitti> seb128: reproduced
<pitti> seb128: epy is supposed to display a menu if I right-click?
<mdz> pitti: did the rosetta team tell you when they could provide the tarball?
<pitti> mdz: carlos sent me one an hour ago, but it is buggy
<pitti> mdz: wel, it's only 16 MB, but should be ~ 150 :-/
<pitti> mdz: we are debugging this right now
<pitti> mdz: my plan was: if there are so many actual updates from rosetta that the update packages would grow too big to include them on the CDs, I'll go ahead with splitting
<pitti> mdz: if they are relatively small, we can maybe ship them in addition
<mdz> pitti: right
<pitti> mdz: the alternative would be to not ship rosetta updates on CDs
<pitti> and just support downloading them from the network
<pitti> but then we can't install them by default and the user had to manually install the package
<pitti> and that sucks for less bandwidth posessing folks...
<pitti> mdz: ^ are you fine with that? or another idea?
* Diziet files two bugs about the same error message: one that I got it, and one that it was misformatted.
<pitti> s/or/or do you have/
<mdz> pitti: it really depends on the numbers I think
<pitti> mdz: right, I meant, are you fine with that strategy?
<mdz> pitti: yes
<pitti> splitting langpacks really sucks, but I guess we don't have any other choices
<doko> seb128: your argument for reverting the firefox change isn't really convincing: basically you say: I return to the broken behaviour because it works for me, and I don't care about others :-/
<pitti> seb128: meh, merely recompiling doesn't help
<seb128> doko: we talked about it with pitti here and we agreed on that
<seb128> pitti: :(
<seb128> pitti: and yep, right click should open a menu
<pitti> doko: basically we said: "we return to a way that at least works until somebody actually fixes the moz libs to work with epy"
<pitti> seb128: D'oh, so what now? </helpless>
<seb128> pitti: what version of epiphany/firefox do we have? I'll ping upstream
<doko> I'll depend on mozilla-dev again, so I don't care about it anymore. but your're just wrong with the "fix"
<pitti> piphany-browser | 1.7.3-0ubuntu1 | http://archive.ubuntu.com breezy/main Sources
<pitti> epiphany-browser | 1.4.4-0ubuntu2 | http://archive.ubuntu.com warty/main Sources
<pitti> epiphany-browser | 1.6.1-0ubuntu2 | http://archive.ubuntu.com hoary/main Sources
<seb128> doko: everybody is too busy to fix it, and we can't stay for weeks with GNOME ftbfsing
<pitti> seb128: I need to fix 1.4.4, I can't just upload 1.7.3, or this "new upstream" mess will never end
<seb128> doko: out of this your "fix" is just "I remove the possibility to use firefox .pc files because it uses a copy of the libs"
<pitti> seb128: it seems that the API of mozilla-dev didn't actually change syntactically, but semantically it seems
<seb128> pitti: upstream knows about that usually
<seb128> pitti: what version of mozilla ? 1.7.10 ?
<seb128> pitti: BTW how did you fix the bonobo-activation error?
<seb128> doko: BTW what is your issue with using /usr/lib/mozilla-firefox/*.so exactly? Out of the fact that the lib should be packaged at one place to /usr/lib ?
<pitti> seb128: yes, 1.7.10
<pitti> seb128: I installed the warty version of epy in breezy :-)
<seb128> pitti: and what is the issue? doesn't build? crash?
<pitti> seb128: right-click (context menu) and middle-click (open in new tab) are broken
<pitti> seb128: otherwise it works fine
<pitti> seb128: breaking these mouse buttons seems to be pretty common
<pitti> seb128: infinity broke them on backporting patches for warty, I broke the middle button on backporting for hoary...
<seb128> pitti: <chpe> seb128: looks like the standard problem... was ephy recompiled with 1.7.10 ?
<doko> seb128: it doesn't provide the nss headers and library I need
<pitti> seb128: in moz and ffox, the function of mouse buttons is defined in javascript (browser.js)
<seb128> <chpe> hmmm weird
<pitti> seb128: same behavior with the already compiled warty version and recompiling against 1.7.10 (which works fine)
<seb128> pitti: you built the warty version on a warty box with 1.7.10, that's it?
<pitti> seb128: right
<pitti> seb128: since warty-security now has 1.7.10
<seb128> doko: just build with mozilla so, changing firefox the way you did doesn't help you to use firefox and break it for GNOME
<pitti> doko: one idea was to copy the ffox version to the moz source package and check whether all browsers work with that
<seb128> pitti: chpe ask for a build log ... do you have this?
<pitti> seb128: no, but I can generate one
<seb128> pitti: please :)
<pitti> seb128: if only debuild wouldn't break ccache...
<pitti> seb128: I have alias debuild='fakeroot dpkg-buildpackage -i'
<pitti> so no build log by default
<pitti> one day I'll fix that
* seb128 uses debuild and no ccache
<pitti> seb128: after rebuilding ffox, moz, and tbird 50 times in a week you will use ccache, too :-)
<seb128> pitti: chpe says usually rebuilding is enough ... need the log to say something else :p
<seb128> pitti: right, probably :)
<pitti> but this bloody debuild cleans up the $PATH
<pitti> and --preserve-env and --set-env are broken, of course :-/
* crispin swears by ccache for moz/ff builds :-)
<pitti> crispin: do you use debuild?
<crispin> no, I manually build about 15-20 different versions of mozilla :-)
<pitti> seb128: http://people.ubuntu.com/~pitti/shots/epiphany-browser_1.4.4-0ubuntu2.1_i386.build
<pitti> seb128: rebuilding doesn't change anything
<seb128> :(
<seb128> I've pointed it to chpe
<pitti> btw, what channel?
<pitti> no need to steal your time with that
<seb128> #epiphany on irc.gnome.org
<seb128> don't worry, I just IRC ping-pong between chans, that doesn't take a lot :)
<Riddell> does ubuntu come with a GUI system log viewer by default?
<highvoltage> Riddell: gedit
<Riddell> that wasn't what I ment
<highvoltage> oh yes, you use kde.
<highvoltage> kate
<azeem> there's gnome-system-log
<Riddell> azeem: that sounds like it, is that installed by default?
<seb128> yep
<azeem> it's installed here, and I don't think I installed it myself
<seb128> that's a part of gnome-utils
<azeem> cause I never used it
<pitti> seb128: thanks for the translation, I add it to langpack-o-matic
<seb128> thank you :)
<pitti> lifeless: here?
<Diziet> This demented package does all of the building in debian/rules binary.
<carstenh> jbailey: ping
* Diziet laughs and points.  apt has undefined behaviour.
<jbailey> carstenh: pong!
<mdz> pitti: --preserve-env CCACHE_DIR etc. works for me
<pitti> mdz: I tried --preserve-env PATH, and it didn't work
<mdz> pitti: debuild --preserve-envvar PATH --preserve-envvar CCACHE_DIR
<mdz> is what I use with apt
<pitti> odd
<pitti> have to try that again, thanks
<mdz> that certainly worked a couple of months ago, the last time I would have expected it to be in cache
<\sh> hi gentlemen
<sivang> yo \sh 
<\sh> pitti: do u encountered problems with firefox 1.0.6-1ubuntu2 + flash-plugin?
<Kamion> woo, oem-config-locale is now just a frontend over localechooser, rather than duplicating code
<pitti> \sh: works for me so far
<\sh> pitti: new version from today or from yesterday?
<pitti> \sh: I currently have the warty version installed, but AFAIK it worked, lemme try again
<Kamion> how evil would it be to 'mount --bind / /target' just so that I can use some other installer code unmodified?
<\sh> pitti: the new version i didn't test but the one from yesterday crashed...
<fabbione> Kamion: not that evil.. why?
<fabbione> Kamion: but if you modify in one, the second will get the change too.. it's not snapshotting what you are searching, right?
<pitti> seb128: epy resolved, it was PEBCAK, as usual :-/
* Diziet is reminded why sie doesn't use Gnome.  I mean, honestly !  I can't get a root shell because the networking is fucked.  I can't fix the networking because I can't get a root shell.
<sivang> Diziet: why not use recovery mode for single user maintainace ?
<Diziet> And I can't switch to a VC to do C-A-D because my keyboard map has been mangled.
<lamont> dmidecode(4133): unaligned access to 0x600000000000804a, ip=0x4000000000007110
<lamont> dmidecode(4133): unaligned access to 0x60000000000080f7, ip=0x400000000000ce81
<lamont> dmidecode(4133): unaligned access to 0x6000000000008107, ip=0x40000000000[ ok ] 
<lamont> bad dmidecode
<Diziet> No, I broke the networking remotely because I like to have a nice wm.  I was hoping it wouldn't actually break.  So I tried to use my existing session to fix it but no luck.
<Diziet> existing gnome session on the console that is.
<Treenaks> lamont: so it IS i386-specific after all 8)
<lamont> lol
<lamont> it works, just noisily
<Diziet> Oh, the Gnome system / logout / restart computer did work eventually, I just didn't wait long enough.
<Diziet> Except now it's stuck on `deconfiguring network interfaces'.
* Diziet deprives it of electricity.
<seb128> pitti: "PEBCAK"? 
<pitti> seb128: problem exists between chair and keyboard
<infinito> hi everyone!
<seb128> oh, yeah
<seb128> pitti: I've just read on #epiphany
<pitti> seb128: I installed the updated epy deb in my warty dchroot and called the version in my breezy system, stupid me
<lifeless> pitti: yo
<seb128> pitti: nice bug :p
<infinito> is there any way to get gcfilms synced form debian to ubuntu?
<infinito> people on #ubuntu-motu tell me to ask here
<seb128> pitti: anyway just need a rebuild so, that's good news
<\sh> infinito: if it's on UniverseCandidates it will be synced when the time comes..
<pitti> seb128: yes, already uploaded, I'll shove it out soon
<\sh> infinito: but u r free to build a ubuntu package for breezy and upload it to REVU to be reviewed.
<infinito> \sh: it is on debian sid, and for what i understand, that's enough to get synced, but maybe i'm wrong...
<infinito> \sh: i don't have very clear the real process to get pkg into universe
<\sh> infinito: syncing is easy..but doesn't give u and us the security, that it builds with our toolchain...sid is at early state with gcc4 right?
<infinito> yeah, but this is a perl-only package
<infinito> we have packages for ubuntu in our website that works great
<infinito> and the one from sid works as well
<\sh> infinito: ok then...where can I have a look to the ubuntu package from u of gcfilms?
<infinito> http://download.gna.org/gcfilms/ubuntu
<\sh> infinito: ok..I will have a look tomorrow .. but if it's good, u have to convince others to include it...after the UVF
<Kamion> fabbione: no
<Kamion> \sh: eh? synced packages are rebuilt with our toolchain!
<infinito> \sh: don't exactly what you mean....
<\sh> Kamion: yes...I'm talking about NEW packages not in ubuntu
<infinito> \sh: don't know exactly what you mean
<Kamion> \sh: surely you review source packages, not binaries? do you really install random binaries built by people you don't have a trust path to?
<\sh> Kamion: it will go into universe anyways..
<Kamion> I know that
<\sh> Kamion: and I'm building any package again with my own toolset ;) and for new packages I'm testing as well 
<\sh> and I should shut up today..i'm a bit stressed...*closeshismouthnow*
<infinito> \sh: excuse me just one more time.... what im supposed to do?
<infinito> \sh: im really newbie in this ubuntu-dev world...
<\sh> infinito: I will have a look on the package tomorrow...and you should think about an explanation why it should be included in universe after UVF as NEW package...when there is mediamate in the universe archive
<\sh> and now...I'm busy with my beer...*cheers* /away
<infinito> \sh: thanks
<Mez> elmo: whats the best way to contact yu ?
<Mez> you *
<Mez> cause I always manage to catch you when you're busy
<Keybuk> hmm, _lots_ of "directory not empty" errors causing problems upgrading X
* Treenaks handsd Keybuk the knife of ritual daniels-slaying
<Keybuk> we should get daniels over to Brazil, and give him some exotic disease
<Keybuk> If _I_ were in the distro team, this kind of thing would not happen *stamps foot* :p
<\sh> .oO(brazilian shemales) *hides*
<bddebian> heh
<\sh> ok..tomorrow I will do the rest of the merges...and then slang2
<Diziet> Yes, lovely, putting network-manager on my laptop shows up a kernel bug.  It makes ifconfig(8) wedge.
<Keybuk> it did that to me too
<mdz> Keybuk: ipw2100?
<Keybuk> ...now my system's gone into "You must be blind" mode (fist-sized fonts mid-upgrade)
<Keybuk> mdz: atheros
<mdz> Keybuk: ick, perhaps more than one bug then
<Keybuk> seemed to show up on shutdown more than startup
<pitti> bah, I got disconnected
<Diziet> ipw2100 for me.
<Diziet> But the wifi works fine for me in my sarge install with custom kernel.
<jasoncohen> it's been a while since thunderbird 1.0.5/6 was released. Now that Warty & Hoary have security updates for firefox & mozilla, will a thunderbird fix be forthcoming?
<Diziet> Should I edit wiki.ubuntu.com/Uploads to mention the fact that you're supposed to upload source-only ?
<pitti> jasoncohen: it's already in the pipe and built, just waiting for a new enigmail
<Kamion> Diziet: yes, please
<jasoncohen> pitti, great, thanks
<jasoncohen> pitti, will updates be a bit smoother from now one without the slowdown of backporting firefox/mozilla fixes?
<Keybuk> . o O { where did xkb go? }
<pitti> jasoncohen: sure, we decided to use new upstream versions, at least if backporting will take more than a few days
<jasoncohen> pitti, what did you do with thunderbird?
<pitti> jasoncohen: upgraded to 1.0.6
<pitti> jasoncohen: I had the backports working, but it crashed occasionally
<jasoncohen> that's because thunderbird 1.0.5 made API changes 
<jasoncohen> i thought new upstream releases would only be provided on firefox. I didn't realize it was a general rule for all packages which couldn't be quickly backported- but i guess that still only applies to firefox and a few other packages
<pitti> jasoncohen: only for moz, ffox, and tbird, for nothing else
<Diziet> Anyone else want a copy of this n-m mail ?
<Diziet> (Not that it's hugely long or interesting.)
<\sh> g'night guys..
<Treenaks> later \sh 
<carstenh> pitti: sane is "allow connections to _all_ installed services that provide a rules file", any suggestions for a better name?
<carstenh> pitti: i guess that is what you meant with "a restrictive default policy" 
<OddAbe19> is there going to be a way to change from the pathbar back to the location bar? or have both? One thing i dont like about the newer gnome releases is the fact that you can't enter a location in some dialogs
<OddAbe19> is there going to be a way to change from the pathbar back to the location bar? or have both? One thing i dont like about the newer gnome releases is the fact that you can't enter a location in some dialogs
<pitti> carstenh: "restrictive" means "forbid everything but explicitly permitted things"
<pitti> carstenh: as opposed to "permissive" (allow everything but explicitly prohibited things)
<Amaranth> OddAbe19: You can always hit Ctrl-L
<Amaranth> OddAbe19: And there is a gconf key to change it to a location bar
<Amaranth> OddAbe19: If you're talking about nautilus, that is
<Amaranth> OddAbe19: /apps/nautilus/preferences/always_use_location_entry
<carstenh> forbid everything but all installed services is restrictive?
<carstenh> s/^/pitti: /
<pitti> carstenh: sort of, yes, because the installed services need to specify their policy
<pitti> carstenh: but we can't do that in breezy if we don't manage to create policies for everything 
<carstenh> sure, but for breezy+1
<carstenh> and that is what i meant with sane
<OddAbe19> Amaranth, thanks, it's just one of the few factors in my descision to goto breezy (i'm so antsy to try, but scared to)
<OddAbe19> not as stable as Hoary was at this point
<jp> http://restrex.dotgeek.org/shot.png !
<dilinger> oooh
<dilinger> a tree display of channels would make me happy, so happy
<Lathiat> happy happy joy joy>?
<jp> rox! heh
<jp> dilinger http://xchat-gnome.navi.cx/building.shtml
<dilinger> libsexy, eh?
<Lathiat> dilinger: heh yeh, library by chipx86 for things like clickable urls in labels and icons in text boxes
<jp> no, I've not applied for that, I'm asexist dude
<jp> ;-)
<jp> heheh
<jp> yep
<dilinger> Lathiat: chipx86 of gaim fame? :(
<jp> yeah
<Lathiat> dilinger: why the :( ?
<dilinger> gaim's interface pains me
<Treenaks> dilinger: use bitlbee
<mgalvin> hi all
<mgalvin> does any know if apt supports https?
<hubH> jp: if you could fix the default completion scheme, I think lot of people would love y ou
<hubH> the new fancy one is just unusable
<Riddell> elmo: the kubuntu powerpc dvd still isn't seeded.  are you the right person to poke?
<dilinger> hubH: agreed
<hubH> q. when un bugz someone say to discuss it on ubuntu-devel, is it on the mailing list ?
<jp> hubH heh not programmer yet dude, I wanna be one, but now I've not time to learn, next year I'll study computing science, so next year I wanna get involved on programming and helping
<jp> :-)
* tseng is of the belief that studying computer science != programming
<tseng> more like an exercise in futilitiy
<jp> tseng really, now I don't have time
<jp> I could learn, but I'm preparing to join university dude
<jp> so, next year, I'll be in programming times I think
<tseng> ok :)
<jp> :)
<jasoncohen> does the epiphany problem only affect warty?
<pitti> jasoncohen: it's already fixed in warty, btw
<jasoncohen> yeah, i just got the security notice
<jasoncohen> btw, USN-155-1 was never emailed
<pitti> jasoncohen: hm?
<jasoncohen> USN-155-1 was never sent to the ubuntu security announce list
<pitti> indeed, how odd...
<jasoncohen> i got USN-154-1 and then USN-149-3 
* pitti bounces
<jasoncohen> and USN-155-2 just came in a few minutes ago
<pitti> http://lists.grok.org.uk/pipermail/full-disclosure/2005-July/035434.html
<pitti> ^ USN-155-1 on full-disclosure
<jasoncohen> yeah, i saw it a few days ago on https://www.ubuntulinux.org/support/documentation/usn/usn-155-1
<pitti> jasoncohen: I probably overlooked it in mailman, thanks for pointing out
<jasoncohen> the warty firefox update was kind of scary. i've never seen that many CAN's in one update
<pitti> I released it to the list
<jasoncohen> 53 in all
<jasoncohen> pitti, was warty's firefox vulernable to all security flaws in 1.0.1-1.0.5 or just some?
<pitti> jasoncohen: most
<jasoncohen> pitti, why did warty never receive a patch? was it just too difficult to backport fixes?
<pitti> jasoncohen: we started with backporting and went on, but the vulns came faster than we could keep up
<pitti> jasoncohen: and it was very hard to backport to 0.8.3
<pitti> 0.9.3
<ajmitch> morning pitti 
<pitti> this was really unfortunate
<pitti> Hi ajmitch 
<jasoncohen> pitti, well, can you imagine backporting fixes from mozilla 1.7.8 to mozilla 1.7.0 from 3 years earlier
<jasoncohen> i can't imagine the amount of code changes that must have occured
<jasoncohen> that was the situation with woody
<pitti> I can imagine it
<pitti> 1.7.0? 1.4.0 rather?
<jasoncohen> http://packages.debian.org/oldstable/web/mozilla
<jasoncohen> 1.0.0-0.woody.1
<jasoncohen> i read the bug reports...the developers weren't even sure if it was still vulnerable
<jasoncohen> *if it was vulnerable
<pitti> that actually worked?
<ajmitch> true, 18 months of security updates for fewer packages is easier than ~3 years for all of debian :)
<jasoncohen> 4 years
<jasoncohen> 3 years + 1 year after release of sarge
<ajmitch> ah yes
<jasoncohen> and the security team can't prioritize
<pitti> jasoncohen: it might be that Sarge now will receive new upstream versions of at least tbird
<jasoncohen> neither mozilla nor firefox have been patched
<pitti> jasoncohen: at least that's the maintainer's intention
<jasoncohen> pitti, heh, you think so? debian developers are pretty anal about backporting all security fixes
<jasoncohen> they refused to use a new mozilla version in woody
<pitti> jasoncohen: actually we are, too, that's why it took so long
<pitti> jasoncohen: new upstreams just break so many things, see warty langpacks and epy
<pitti> which shows that our general approach with backporting is richt
<pitti> right, even
<jasoncohen> yes it is but not with mozilla products
<jasoncohen> there are just too many security fixes, too often
<pitti> that's not the problem
<jasoncohen> and neither debian nor ubuntu could keep up
<jasoncohen> then what is?
<pitti> but the code is too complicated and intertwinded
<jasoncohen> ah
<dredg> changes between versions that break backported code don't help
<pitti> it uses 34 API levels, javascript all over the place, garnished with 10 XML formats...
<jasoncohen> well, didn't you know that would happen? a day after 1.0.5 was released, 1.0.6 came out
<pitti> jasoncohen: and they can't resist from adding new features to new upstream versions
<jasoncohen> to fix that very problem
<ajmitch> so that's why noone likes taking responsbility for firefox :)
<pitti> ajmitch: right, 'cause that package is TEH SUCK
<pitti> it doesn't even have a patch system
<pitti> mozilla and tbird are much better packaging-wise (of course that doesn't help to cure the upstream mess)
<jasoncohen> and the mozilla team doesn't really like distribution patches
<pitti> jasoncohen: well, the patches are there
<jasoncohen> they would prefer to have users use the upstream release from a QA standpoint
<jasoncohen> since they hear the complaints when something doesn't work
<pitti> jasoncohen: I ported them to our versions, that was not a problem (well, it took some 40 hours, but oh well)
<pitti> jasoncohen: the problem is that it is impossible to find the patches that fix the regressions from the security patches
<jasoncohen> it may not be the perfect solution but using the new upstream release certainly assures quick security updates and will save you a lot of time and grief
<pitti> jasoncohen: and they still use cvs
<pitti> jasoncohen: that's what we finally concluded as well
<pitti> jasoncohen: I tried to work with their cvs, but it's a pain
<jasoncohen> users should just install extensions manually using the xpis
<pitti> cvs so much sucks, especially if you maintain some 40 branches in it
<jasoncohen> and then upgrade after they upgrade firefox
<jasoncohen> that seemed to be part of the problem with the the last security backport (to 1.0.5 fixes)
<jasoncohen> what is debian doing about firefox/mozilla?
<pitti> jasoncohen: they won't have much choice than to upgrade to new upstreams
<jasoncohen> debian's security team seems to prioritize server apps. i see updates for obscure little server packages which are probably used by very few people while the big desktop packages aren't fixed
<pitti> jasoncohen: RedHat had employed an upstream hacker to do security updates for mozilla stuff
<pitti> jasoncohen: and yet they put 1.0.6 into their enterprise distro (!)
<Lathiat> pitti: heh
<jasoncohen> heh
<jasoncohen> what do you think of what they do with fedora?
<jasoncohen> backporting some and new upstream for others
<pitti> jasoncohen: which indicates that two Ubuntu hackers with no code knowledge can't possibly be better than that and win
<jasoncohen> i've never really understood fedora's security update policy but it seems to work. they get updates out quickly
* ajmitch wonders why logrotate's selinux wishlist bug was only just closed in the last couple of days
<jasoncohen> why does mozilla refer to security problems by their own MFSA #s rather than the CANs?
<ajmitch> ah, I was looking at wrong version in changelog
<ajmitch> bother, it's a new upstream version too
<pitti> jasoncohen: they can get them immediately, I suppose, and they have their own schema (much like our USNs)
<pitti> jasoncohen: often, the CAN assignment slacks for a while
<pitti> jasoncohen: but they should indeed use them more regularly
<pitti> jasoncohen: mapping a MFSA to a CAN is nontrivial
<jasoncohen> they should at least give the CANs as well
<pitti> jasoncohen: they do in a few MFSAs
<jasoncohen> that's one reason i didn't like backporting of security fixes on firefox
<pitti> which reason?
<dredg> heh, for added fun, see redhat's changelogs.
<jasoncohen> not all of the fixes in the new upstream were always backported at one time and it was difficult to tell what was missing since the USNs used CAN #s and mozilla uses MFSA's
<dredg> they're _nasty_
<pitti> jasoncohen: hm, sorry; but we generally use CANs since they are much easier to track and more standardized
<jasoncohen> no- i agree with you
<jasoncohen> i want mozilla to follow the standard and give the CANs too
<jasoncohen> but why did you release a patched firefox versoin without all the fixes from the upstream?
<jasoncohen> *the security fixes
<pitti> jasoncohen: hm, I did? you mean the 1.0.2 backported version?
<jasoncohen> yes
<jasoncohen> USN-124-1
<pitti> I applied all patches that were mentioned in their MFSAs
<pitti> darn, silly network; brb
<Lathiat> MFSA = mozilla foundation security advisory?
<jasoncohen> pitti, hey- USN-134-1 included all the fixes from 1.0.4
<jasoncohen> i was referring to USN-124-1
<jasoncohen> it only lists 7 CANs and there are 9 MFSAs...did the CANs include multiple MFSAs?
<pitti> probably two MFSAs didn't apply to us, lemme check
<jasoncohen> MFSA-2005-33 is linked to CAN-2005-0989 which isn't in the USN
<jasoncohen> also, security patches are sometimes spread over more than one security advisory so you dont' know if you have all the security updates from the current upstream release
<jasoncohen> for an example see USN-139-1 AND USN-140-1 - from gaim 1.3.1
<jasoncohen> the updates were seperated over 5 days
<jasoncohen> *seperated by 5 days
<pitti> jasoncohen: for example, MFSA-2005-33 was already fixed before the hoary release
<pitti> http://changelogs.ubuntu.com/changelogs/pool/main/m/mozilla-firefox/mozilla-firefox_1.0.2-0ubuntu5.1/changelog
<jasoncohen> that and the time it takes to patch is really the only advantage of getting new upstream releases. you know you're up to date & secure
<pitti> in 1.0.2-0ubuntu4
<pitti> jasoncohen: oh, gaim patches are easy
<pitti> jasoncohen: I already fixed the gaim package before it became public and released it immediately
<pitti> jasoncohen: and I got to know the other issue only a bit later
<pitti> jasoncohen: but a mere DoS wasn't something I needed to particularly prioritize
<jasoncohen> AH
<jasoncohen> i see
<jasoncohen> i see now
<jasoncohen> but at the time i wasn't sure if it was patched or not
<pitti> CAN-2005-0989 was the MFSA 2005-33
<pitti> jasoncohen: http://people.ubuntu.com/~pitti/ubuntu-cve/fixed.html
<pitti> ^ I use that for tracking, and I just marked hoary as not vulnerable to CAN-2005-0989
<jasoncohen> pitti, i was looking for a site like that. debian testing has one
<pitti> http://people.ubuntu.com/~pitti/ubuntu-cve shows the index
<jasoncohen> btw, what does CAN stand for? i know what CVE is
<dredg> isn't CAN getting renamed to CVE?
<jasoncohen> yeah
<Mez> pitti: ping
<dredg> or did i make that up?
<jasoncohen> common vulnerability and exposures
<pitti> dredg: no, that will happen soon
<pitti> Hi Mez 
<Mez> ah, sorry didnt see you there :D
<Mez> pitti, did you package FF yourself, or were you working from debain stuff?
<Mez> cause I'm thinking of making a firefox-preview release (for those who want to play with 1.5) and was wondering the best place to start
<jasoncohen> Mez, hey, what's going to happen with backports-staging? currently some of the staging packages can't be used with backports because they require libraries from the old backports like libgcc1
<Mez> whether I should start witha  new package, or wheter I should work from the current one
<pitti> Mez: we base all packages on the Debian ones
<pitti> Mez: debian/ is fine, but you should definitively add a patch system to ti
<Mez> jasoncohen, they shouldnt depend on libgcc1 from backprots - that's just bad packaging
<pitti> Mez: moz and tbird have patch systems, but ffox doesn't
<Mez> pitti: It's not a problem to add a patch system to it ... just wondering about making a preview release (for universe of course)
<jasoncohen> Mez, i know that, heh
<pitti> Mez: would rock :-)
<Mez> what's your opinion - is it worth packaging up?
<pitti> Mez: well, if you want to, sure; and we can use the packaging for the final release
<pitti> Mez: but please ask the Debian maintainer for cooperation
<quitte> i have a problem compiling gtk-doc. the error i get is:checking for DocBook XML DTD V4.1.2 in XML catalog... not found
<pitti> Mez: and persuade him about the necessity of a patch system :-/
<jasoncohen> Mez, any timeframe on when official backports will receive smeg, f-spot and other assorted packages that are currently missing
<quitte> i already recompiled docbook-xml but that didnt help. any idea what i should do?
<quitte> lool: if you are there please have a look
<Mez> pitti, I don't know whether he's thought about 1.5 yet - as a preview release... and well, though patch systems are nice, are they needed atm (you are just on about debian/patches right?
<Mez> jasoncohen, we're waiting on elmo and sorting other stuff
<jasoncohen> pitti, why does http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html show packages in hoary as unfixed when hoary-security has the appropriate patches
<pitti> jasoncohen: the mirror where I'M running the scripts lags a bit
<pitti> jasoncohen: last automatic update was almost 12 hours ago
<pitti> and it's only mirrored once per day or so
<pitti> jasoncohen: it'll resolve nicely tomorrow or so
<jasoncohen> ok, because it's still showing mozilla 1.7.6
<Amaranth> oh dear, no smeg in backports?
<jasoncohen> Amaranth, not in official backports
<jasoncohen> it's still on the old mirrors
<Amaranth> oh, that reminds me
<jasoncohen> pitti how about php4, gnupg, gzip, and unzip. are they really vulnerable? 
<Amaranth> Mez: What happens to my gnome-menus 2.10.2ish packages?
<Mez> Amaranth, what?
<pitti> jasoncohen: php4 was a typo in the changelog, nothing real
<pitti> jasoncohen: the gnupg issue is not something we need to be concerned with (very low prio)
<Amaranth> Mez: gnome-menus 2.10.2-0ubuntu1~5.04ubp1
<pitti> jasoncohen: I still have to do gzip and unzip, but they are not very critical and I wanted to do the moz stuff before
<pitti> jasoncohen: there is a fair amount of stuff I need to catch up with, the moz stuff drained a lot of time from me
<jasoncohen> how old is the gzip problem?
<jasoncohen> it shows 03-17-2005
<Mez> Amaranth, what about it
<Amaranth> Mez: breezy doesn't have 2.10.2 :P
<Mez> what version does breezy have?
<pitti> jasoncohen: hoary isn't vulnerable anyway
<Amaranth> Mez: I wouldn't bother putting smeg in hoary-backports if that can't come with it.
<Amaranth> Mez: I'm not willing to deal with the bug reports.
<pitti> jasoncohen: ah, that's the reason, even warty is not affected
<Amaranth> Mez: 2.11.90
<Mez> Amaranth, breezy has 2.11.90
<Amaranth> You can't backport GNOME to hoary.
<Mez> so whats the problem with that version being there
<Amaranth> smeg needs 2.10.2 or newer
<pitti> jasoncohen: I'll clean up that list a bit once I have some time again
<Amaranth> hoary has 2.10.1
<Mez> mmhmm, so hasn't smeg been used in hoary?
<jasoncohen> Amaranth, it does...i'm using it with gnome-menus 2.10.1
<Amaranth> Mez: gnome-menus 2.10.2-0ubuntu1~5.04ubp1 is in backports
<Mez> Amaranth, so why cant we put 2.11.90 in backports official
<Amaranth> jasoncohen: I'm surprised you haven't bitched yet, I got a ton of complaints about things not working or me breaking people's menu until I got them all on that.
<Amaranth> Mez: Depends on a bunch of other 2.11.90 stuff, you'd end up backporting GNOME.
<jasoncohen> Amaranth, i did notice xine is showing up in it's own Multimedia menu and i can't get rid of it
<Amaranth> jasoncohen: ding!
<Amaranth> jasoncohen: http://ubuntu-backports.mirrormax.net/dists/hoary-backports/main/binary-i386/gnome-menus_2.10.2-0ubuntu1~5.04ubp1_i386.deb
<jasoncohen> installing 2.10.2 now
<Amaranth> http://ubuntu-backports.mirrormax.net/dists/hoary-backports/main/binary-i386/libgnome-menu0_2.10.2-0ubuntu1~5.04ubp1_i386.deb
<jasoncohen> i just activated the old backports source
<Amaranth> ah, ok
<Mez> Amaranth, and the problem with backporting gnome is?
<Mez> lol
<Mez> we're planning to backport KDE :D
<Amaranth> Mez: seb128 will murder you
<Mez> lol
<Amaranth> Mez: You're going to keep hoary-backports running past breezy's release?
<jasoncohen> Amaranth, how do i get rid of the multimedia menu. smeg isn't showing it
<Mez> lol
<Mez> Amaranth - dunno yet
<Amaranth> jasoncohen: install those packages and log out/in
<jasoncohen> pitti, so, of the gnupg, php4, and gzip, unzip CANs, which actually affect hoary?
<pitti> EPARSE
<pitti> ah, ok
<pitti> unzip and gnupg
<pitti> but I won't update gnupg
<pitti> it's just not worth breaking gnupg for an academic issue
<pitti> unzip will be fixed soon
<jasoncohen> has it been fixed upstream?
<jasoncohen> i'm using gnupg 1.4.1
<pitti> yes, it's fixed in breezy
<jasoncohen> i'll just do another backport from breezy then
<pitti> OMG, why bother?
<jasoncohen> i need the SHA2 hashes
<pitti> ah, for that, ok
<pitti> but not for that stupid CAN, please
<jasoncohen> so, it's a non-issue
<Mez> lxbc9adp
<jasoncohen> um, this makes no sense
<Mez> f**k
<Mez> stupid thing
<jasoncohen> gaim 1.4.0 has this CAN http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0891 which only applies to gaim .79 to 1.0.1
* Mez slaps ogea you were meant to FIX that bug
<pitti> jasoncohen: it's basically "if I send you 2 million mails and ask you to try to decrypt them and tell me which one succeeded, then I can tell you the first two bytes of your key"
<jasoncohen> hmm, lol
<jasoncohen> and that'll do nothing 
<pitti> jasoncohen: mathematically it is interesting, but not really something you would encounter in practice
<Mez> fabbione: ping
<jasoncohen> pitti, why does gaim 1.4.0 show that CAN?
<pitti> jasoncohen: only in hoary-backports
<jasoncohen> yeah
<jasoncohen> but hoary-backports has the newest upstream release- 1.4.0
<pitti> jasoncohen: because that CAN isn't in the changelogs, but in my override database
<jasoncohen> and that CAN is very old
<Mez> soryr
<Mez> backports. .. /
<pitti> jasoncohen: and I just told my db "fixed in warty, hoary"
<Mez> whats was the problem?
<jasoncohen> ok
<pitti> jasoncohen: I don' track issues in backports
<pitti> I mean, I could add it 
<Mez> what issue in backports ?
<jasoncohen> you shouldn't have to if backports has the newest upstream
<pitti> but h-backports didn't appear in my list until three days ago
<pitti> I'll probably just ignore *-backports in ubuntu-cve
<jasoncohen> Mez, http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html shows gaim 1.4.0 as being vulnerable but the CAN is really old and doesn't apply
<jasoncohen> pitti, do you ever patch issues in universe?
<pitti> that's a community effort
<pitti> in the past, there were some quite active patchers
* Nafallo wissles *
<jasoncohen> pitti, a few php packages were fixed from universe
<jasoncohen> was that done by the community?
<pitti> yes, I don't do them myself
<pitti> I review debdiffs and release packages, but I don't have the time to patch universe
<jasoncohen> what will happen when ubuntu releases its enterprise distro with a longer support cycle? will main be expanded to support more server packages like debian?
<pitti> no idea, we didn't talk about that yet
<jasoncohen> though debain seems to support too many packages and they prioritize for a server and usually ignore desktop apps for a while
<pitti> that'll be a topic on november's conference, I guess
* maswan hopes for AFS :)
<jasoncohen> *debian
<pitti> jasoncohen: indeed, Debian should adopt something like universe as well
<pitti> supporting 15.000 packages with things like some dozen crappy php web apps and other ever-breaking stuff is insane
<jasoncohen> i receive DSAs and i haven't even heard of half the packages being patched
<ajmitch> pitti: heard anoy more about the next conferenve?
<maswan> well, first debian should get aorund to vancouvering some arches... :)
<pitti> no, just the rough time
<ajmitch> ok
<jasoncohen> yup, do you think they will maswan?
* ajmitch will see if he can go again
<pitti> maswan: I don't think that the arches is the biggest problem, it's one of Debian's biggest strengths rather
<jasoncohen> i use sarge for my mythtv box- so i have a lot of php, apache and mysql stuff some of which is in universe in ubuntu
<maswan> pitti: well, the mirror split is really needed.
<pitti> right
<maswan> pitti: the rest is about release team handling ports vs porting team handling releases. if the release team say they can't handle it, some solution needs to be found. the future will tell, I guess.
<jasoncohen> pitti, who tests security updates before being released and why was USN-149-1 released with the known problems in firefox 1.0.5?
<pitti> jasoncohen: I tested them, and ffox worked just fine for me; I tested it with some extensions, flash, video, and several profiles
<pitti> I just didn't test the extensions everybody else seemed to deem as utterly important
<jasoncohen> pitti, if its any condolance, it worked fine for me
<jasoncohen> and i use tab browser preferences
<jasoncohen> i just download the xpi myself rather than using the packaged version
<pitti> jasoncohen: it worked for me, too, otherwise I wouldn't have released it :-)
<maswan> Hmm.. I wonder if you could put a cost at supporting a package over the lifetime of a release
<pitti> but thanks :-)
<jasoncohen> pitti, is an 18 month security support cycle reasonable? is it more difficult to support warty now for example than hoary?
<pitti> jasoncohen: for most packages it's not, and I think 18 months is reasonable
<jasoncohen> it seems that other than mozilla/firefox/thunderbird, all of the updates have been simultaneous on both warty & hoary
<Nafallo> pitti: apt-cache madison openmotif
<Nafallo> pitti: the change in breezy is closing those xpm vulns ;-)
<pitti> Nafallo: openmotif doesn't exist... ???
<pitti> libmotif-dev |    2.2.3-1 | http://archive.ubuntu.com breezy/multiverse Packages
<pitti> ah, multiverse
<Nafallo> pitti: multiverse
<Nafallo> yepp :-)
<Nafallo> the only one for hoary :-P
<Nafallo> s/one/four/
<pitti> gosh, who still uses motif nowadays???
<pitti> why not at least lesstif?
<Nafallo> pitti: ubuntu-cve ;-)
<Nafallo> might aswell backport it for {warty,hoary}-security
#ubuntu-devel 2005-08-03
<pitti> Nafallo: if you really want to do universe updates again (YAY! :-) ), why not start with something more useful like ethereal=
<pitti> ?
<pitti> or clamav, spamassassin, etc.
<pitti> Nafallo: I'd be fine with the new upstream microrelease for ethereal
<Nafallo> pitti: mostly cause ethereal made me stop :-/. I can't get that patch down to better sizes and that made me jump off this train for a while :-/.
<ajmitch> Nafallo: yes, ethereal is a rather evil package for security
<pitti> Nafallo: as I said, if you package and test 0.10.11, that's fine for me in that case (the upstream release is cautious, and porting 15 patches doesn#t make sense)
<pitti> ajmitch: that's why it is in universe, although it's highly useful
* ajmitch uses the top 2 items on the unfixed universe list
<ajmitch> if only phpgroupware didn't take so long to download..
<jasoncohen> pitti, why is it an evil package?
<Nafallo> pitti: oki. I'm sorry I didn't took a chat with you at the time, but now I'm back atleast :-).
<pitti> jasoncohen: it's just evil security-wise :-) it has a very bad vuln history
<pitti> Nafallo: no need to be sorry :-)
<ajmitch> jasoncohen: there are about 20 open CANs for ethereal on that list :)
<jasoncohen> pitti, ubuntu-cve/fixed.html doesn't show CAN-2005-1921 as being fixed for hoary but it is. see USN-147-1 https://www.ubuntulinux.org/support/documentation/usn/usn-147-1
<Nafallo> pitti: as soon as elmo add my key to the keyring I upload bugzilla for warty-security if that's okey? ;-)
<pitti> Nafallo: well, warty's universe is a lost cause, but of course it's appreciated :-)
<jasoncohen> ajmitch, ouch, i didnt' realize ethereal was that bad...what do the security issues involve?
<Nafallo> pitti: the patch have been done for ages actually ;-)
<pitti> jasoncohen: most of them are DoS only, but some are exploitable to code exection AFAIK
<ajmitch> jasoncohen: lots of buggy plugins
<ajmitch> format string issues, buffer overflows if you're unlucky
<pitti> jasoncohen: http://people.ubuntu.com/~pitti/ubuntu-cve/nonvuln.html
<pitti> CAN-2005-1921 	
<pitti> php4	(hoary/main, breezy/main)
<jasoncohen> but USN-147-1 shows CAN-2005-1921 for both hoary & warty
<pitti> jasoncohen: yes, but php4-pear is in universe for hoary (from php4-universe source package)
<pitti> jasoncohen: hoary was fixed more as a courtesy while we were at it
<pitti> and because this was such a nasty one
<jasoncohen> so libapache2-mod-php4 was never vulnerable in hoary?
<pitti> nope
<pitti> well, not against that XMLRPC issue at least :-)
<jasoncohen> pitti, what are the hardest packages to backport security fixes for other than mozilla & firefox?
<pitti> hmmm
* pitti looks at the list
<pitti> jasoncohen: squid is relatively hard
<pitti> and I had some pretty hairy samba patches
<pitti> postgresql was nontrivial, too, but luckily I'm the Debian maintainer :-)
<ajmitch> pitti: phpgroupware has 0.9.16.005-1 in hoary, 0.9.16.006-1 in debian, do you want only security fixes backported?
<pitti> ajmitch: yes, is it so hard?
<ajmitch> not terribly hard
<ajmitch> since I know the upstream source
<Amaranth> nice
<pitti> I don't want to get more sloppy with upstream versions than now
<ajmitch> ok
<Amaranth> i have a 4 line python script that loads up a glade file, shouldn't have any problems right?
<Amaranth> i managed to crash it due to the stupidity that is bonobo docks
<jasoncohen> pitti, so, how long is too long for security updates? even on hoary, it took quite a while to get firefox updates (over 2 weeks)
<pitti> jasoncohen: because I 
<pitti> spent a whole week with backporting
<jasoncohen> heh, ouch
<pitti> that shouldn't happen any more with new upstream versions
<Amaranth> ooh, this is even reproducable
<pitti> jasoncohen: the minimal patches were  > 200 KB in total
<jasoncohen> when would you have had 1.0.6 out if you just had to package the new upstream release?
<pitti> on the very day I guess
<pitti> updating warty took me three days
<pitti> because 0.9.3 -> 1.0.6 is a hell of a lot of changes
<jasoncohen> 53 CANs
<pitti> but for hoary it was rather trivial
<pitti> jasoncohen: also because I had to update all language packs and stuff
<pitti> and sort out ancient patches
<Nafallo> pitti: why does ubuntu-cve say debian's ethereal is vulnerable? :-)
<pitti> Nafallo: because they didn't put CANs in the changelogs
<pitti> and I didn't manually add them to my db
<pitti> (well, I can't do that for Debian anyway)
<Nafallo> pitti: hehe, oki :-)
<doko> Kamion, mdz: python-qt3 was demoted to universe, although it's a build-dep for hplip
<mdz> doko: it's been in universe since warty from what I see
<mdz> doko: also, hplip is in universe right now (only hplip-base is in main)
<doko> mdz: my mistake, wrong merge
<mdz> doko: thanks for getting hplip into shape
<doko> mdz: currently scanning doesn't work, with ort without running as root
<mdz> oh
<mdz> that's not very good
<mdz> did you add hplip to scanner?
* Mez yawns
<Mez> mdz, tseng's willing to help us backport mono stuff, is that cool with you?
<mdz> Mez: in breezy, or as a fork?
<doko> Mez: if that results in a buildable ironpython ...
<Mez> mdz: from breezy
<Mez> to hoary
<mdz> Mez: yes, certainly
<Mez> mdz: apparently, the current mono stuff had already been made to work in hoary (cause they wanted to release a mono livecd)
<Mez> so, it just needs backporting in the right order and stuff
<Mez> doko: I have no idea what that is, so I'm not gonna comment
<ajmitch> doko: well, we don't even have ironpython in breezy yet :)
<doko> ajmitch: yes, because it doesn't build :-/
<ajmitch> doko: great, I see you were the ITP filer.. does it not build with the mono in sid?
<doko> ajmitch: I'll send you and tseng my current packaging, then you test it ;-P
<ajmitch> doko: ok, it might be a good plan to put it in pkg-mono svn :)
<doko> mdz: adding hplip to scanner doesn't help, will look at it later
<Nafallo> I better goto sleep now that all three gerbils sleep in the same pile :-)
<Nafallo> see you all tomorrow! :-)
<pitti> night everybody
* lamont wonders WTH cpqarrayd isn't in breezy...
<lamont> elmo: ^^^
<elmo> because it's a PoS that doesn't work
<lamont> I'll pass that along to taggart
<elmo> I've told him about it
<lamont> did we intentionally strip it?
<elmo> yes
<lamont> ok
<elmo> it false negatives
<elmo> we can pull it into universe if you really want, I just don't want it in main
<lamont> what's a good alternative?
<lamont> if none, lets go for universe, I guess
<lamont> (bdale is playing with a machine, you see...)
<elmo> you really want the HP propreitary gunk
<elmo> but it doesn't work asa daemon
<elmo> or rather it does, but doesn't log to syslog
<Mez> elmo, can you kick ff from backports, and add mono please
<elmo> mez: pls mail me
<Mez> elmo: kk
<Mez> sorry
<hughsie> ogra: ping?
<ogra> hughsie, ?
<hughsie> ogra: you may or may not be aware that libnotify released 0.2.1 today
<hughsie> 0.2.0 was released yesterday, but had some dbus bugs we squashed
<ogra> hughsie, you may or may not be aware that libnotify entered our archive today ;)
<hughsie> okay, nice one.
<ogra> 0.2.1-0ubuntu1
<ogra> :)
<hughsie> quicker than me :-)
<ajmitch> looks like seb uploaded 0.2.1 very soon after 0.2.0
<ogra> thast seb128 .... dont get in his way *g*
<hughsie> you can build g-p-m with --enable-libnotify for all the new goodness
<ogra> yeah, i'll do
<hughsie> you'll need notification-daemon as well for it to work
<hughsie> ogra: i've seen some of the ubuntu/debian patches that create a debian directory in the source tarball
<hughsie> is that for every package?
<ogra> yep
<ogra> a debian package consists of:
<hughsie> should it be upstream? is it easier that way
<ogra> the orig.tar.gz file (original source )
<hughsie> k
<ogra> the diff.gz (all distro changes and the debian dir)
<Mez> ogra, did youy archive php4-universe
<ogra> and a .dsc file that describes the two...
<ogra> Mez, nope
<Mez> just wondering cause you mentioned about ti going into main
<Mez> weird...
* Mez is confused why ti was archived, but not uploaded
<hughsie> ogra: cool, okay, so non of the /debian stuff is easier in package?
<ogra> hughsie, i wouldnt mix upstream source and debian dir
<hughsie> ogra: cool, i'm new to all this debian stuff
<ajmitch> having the debian dir in upstream can be limiting
<hughsie> ajmitch, ok, thanks.
<ogra> except i develop it explicitly for this distro ... but if outher debian based distros want to package it differen mixing upstream source and packaging stuff can get odd
<hughsie> ogra: could you (do you want to) package cvs g-p-m or shall I release 0.1.1?
<ogra> hughsie, as you like... 
<ogra> i can do both... 
<hughsie> ogra: cvs is churning with new stuff at the moment
<ogra> i think we'll have to wait a bit for dbus... 
<hughsie> i'll let it settle then do 0.1.1?
<hughsie> okay, define "bit"
<ogra> daniels is the guy who modularizes X 
<ogra> he's 4/5 throught... i dont know if he can make dbus inbetween
<ogra> s/throught/through
<hughsie> ogra: okay, cool. I'll just keep hacking
<hughsie> you seen the hal patches I've sent recently?
<ogra> i must admit i havent looked deeply...
<ogra> but i saw you sent patches :)
<hughsie> cool, i'm putting lots of the clever logic in hal so that other projects (like battstat-applet can use them
<hughsie> ogra: I sleep now, I'll catch you guys tmw.
<ogra> ah yes, i saw the request from ryan
<ogra> hughsie, great, see you around :)
<hughsie> cool. thanks mate
* mrd` doesn't understand why X is working again.
<Mez> cause daniels = god ?
<mrd`> Possibly.
<mrd`> But... I didn't think I updated any packages that could have fixed it.
<Mez> mrd`, it must have been magic(tm) then
<mrd`> Hm, I did upgrade gnome-session... that could have done it.
<jasoncohen> Amaranth, hey- you were right about needing gnome-menus 2.10.2
<jasoncohen> Amaranth, i logged back in and now the multimedia menu is gone, and several menu entries that didn't show up before are now present. in addition i can delete menu entries whereas i couldn't before
<jasoncohen> Amaranth, this is only a problem with the official backports server because the unofficial mirrors have gnome-menus and libgnome-menus 2.10.2
<Mez> jasoncohen, I can make a special request to James to sort that out
<jasoncohen> thanks
<jasoncohen> Mez, can you get mozilla-mplayer 2.85 into breezy. it's already in sid
<jasoncohen> http://packages.debian.org/unstable/misc/mozilla-mplayer
<jasoncohen> it's been in sid for over a month
<jasoncohen> and 2.75 was uploaded in May
<jasoncohen> anyone here know if the official firefox build can upgrade properly using the included upgrade functionality? the last time i tried it didn't find 1.0.6 and i had to diownload it and install it manually
<Burgundavia> jasoncohen, contat ogra about mozilla-mplayer
<Mez> jasoncohen, ask in -motu
<jasoncohen> ok
<jasoncohen> Mez, i'd like to see a gtk2 version of 2.85 in breezy if possible
<Mez> jasoncohen, tired :d talk later
<jasoncohen> ok
<j^> what happend to network-manager?
<j^> 0.4.1+cvs20050618-3 is totaly broken
<Burgundavia> yes
<Burgundavia> the changelog says that
<j^>  Unfortunately these changes are not properly
<j^>     tested :-(.
<j^> thats not is totaly broken
<j^> any plans to unbreak it?
<Burgundavia> ian is working on it
<jasoncohen> now that ubuntu is packaging the latest upstream release, can they use the real firefox icon?
<mrd`> It's still patched, isn't it?
<jasoncohen> will they be patching it in addition to providing upstream releases?
<Burgundavia> jasoncohen, no idea
<jasoncohen> i have no idea why but browsing feels faster on the official build v. the ubuntu 1.0.6 build. i can't explain it
<jasoncohen> the ubuntu version seems to freeze for a second between switching pages. the official build doesn't
<wm_eddie> I think there might be a bug in shipit's zip code field.  Anyone know who I can e-mail to let them know?
<wm_eddie> (My zipcode is 00976 and the label on the packaging said 976 and the USPS had a really hard time getting it to where it had to go.
<sladen> wm_eddie: mail mako
<wm_eddie> ok.
<Amaranth> jasoncohen, Mez: It's amazing how much of a difference it makes, isn't it? (gnome-menus)
<Mez> Amaranth, meh
<Burgundavia> Amaranth, what do you mean?
<Amaranth> Burgundavia: about an hour ago jasoncohen was telling me how much of a difference gnome-menus 2.10.2 made as far as things working
<Burgundavia> ah
<Amaranth> jasoncohen: btw, the patches for GNOME integration make it impossible to use the official branding
<Amaranth> jasoncohen: for firefox, that is
<astronut> I'm using the live cd to see how well linux handles all of my laptop's hardware....i fixed the PCMIA bus by modifying some PCI stuff, but to get the full features ofmy touchpad, i have to patch the kernel..how can i do this on a live cd? (Can i create a custem kernel on floppy, or reburn the cd, etc)
<OddAbe19> what's the safest (or best) upgrade to breezy at the moment? Dist-upgrade or upgrade? What breakage would dist-upgrade bring versus upgrade?
<sladen> astronut: you shouldn't /have/ to patch your kernel;  is it a synaptics touchpad?
<astronut> sladen, alps, see /usr/share/doc/xorg-(synaptics driver somethign)/README.alps
<Lathiat> astronut: yeh you dont need to patch the kernel
<Lathiat> astronut: just need to modify your X config
<Lathiat> astronut: if you restart X with SHMConfig, you can use the 'tpconfig' to play with the values live, the default values for alps arent too great
<astronut> Lathiat, it won't detect as a synatpics
<Lathiat> astronut: you sure
<astronut> it works, but won't do the scroll....i tried forcing synaptics, dmsesg said not one
<astronut> Lathiat, oh, i've played a while
<astronut> it uses generic drivers to act as just a mouse
<astronut> what's SHMConfig/tpconfig?
<astronut> not on the live cd...
<Mez> hmm, I've just realisede how godamn hot my gf is :S
<Mez> hehe
<astronut> Mez, link?
<Mez> perv astronut
<Mez> but, one sec
<astronut> Lathiat, i spent about 30 minutes trying to figure out WHY my mouse would work after i commented out all Mouse device sections in xorg.conf
<astronut> Mez, you cna't make a statement like that without backing it up
<Mez> lol :d
<Mez> I'm just uploading astronut
<Lathiat> haha mez
<astronut> Lathiat: the livecd puts a synaptics section in here, but i can't force it to use synaptics
<Mez> http://www.cheesenibbles.com/files/mez/emily.jpg
<astronut> and i want to shoot whoever made , the default nick thing in xchat 2.x over the : in 1.x
* astronut whistles
<astronut> Mez: girls like that don't go out with geeks...what'd you do?
<HrdwrBoB> gave her money
<HrdwrBoB> all girls like money
<OddAbe19> hooker's like money too
* astronut nods
<HrdwrBoB> ;)
<OddAbe19> what does that tell me
<astronut> beat me too it OddAbe19 
<OddAbe19> :-p
<Mez> astronut, she's a geek too
* Lathiat kills mez
<astronut> Mez: liar...
<OddAbe19> what's the safest (or best) upgrade to breezy at the moment? Dist-upgrade or upgrade? What breakage would dist-upgrade bring versus upgrade?
<Lathiat> OddAbe19: dont :)
* astronut kills Lathiat while he's cleaning his hands of the blood
<HrdwrBoB> OddAbe19:  the safest way is to not
<OddAbe19> lol, i've been antsey for about 2 months now, but i was waiting for X and GCC changes to end
<OddAbe19> now that they are
<Lathiat> well, X hasn't ended yet
<Mez> no, seriously, she is - lol :D hehe :D her dad works for apple and stuff :D and she's my lil geek (she wont stop pestering me to install kubuntu on her PC for her!)
<HrdwrBoB> astronut: depends, geek doesn't mean you can't be a nice person :)
<OddAbe19> it's less borked
* astronut thought hoary was xorg?
<Lathiat> Mez: bastard
<astronut> or what x transition is that?
<HrdwrBoB> Mez: kubuntu? ick
<astronut> i'm a debian guy myself
<Lathiat> astronut: it is
<HrdwrBoB> my wife isn't a geek, but she uses ubuntu
<astronut> monolithic -> modular tree?
<Lathiat> astronut: yes
<Mez> HrdwrBoB, my gf is and she uses kubuntu :D but each to their own
<Lathiat> astronut: tahts wahts happening
<Mez> and Lathiat what did I ever do to you
<astronut> Mez: once oyu're out of the picture, he can steal her
<Lathiat> Mez: have a good looking geek girlfriend :)
<Lathiat> hrm.. anyone know how i can compare two struct sockaddrs
<astronut> Lathiat: tpconfig isn't in the live cd, what package is it in?
<Lathiat> astronut: tpconfig, oddly enough :)
<Mez> Lathiat, and she loves same kind of music as me and loves gaming, and. ... just... *drools* every geeks dream :D
<Mez> hehe
<astronut> meh...i guess we'll have to do apt-get update
<astronut> not sure how well live cd will like this
<astronut> security/restricted???
<Mez> anyhoo ... am off to bed :D hehe :D
<astronut> E: Couldn't find package tpconfig
<astronut> Lathiat: ?
<astronut> meh...i guess cd's are weird
<astronut> livecd*
<astronut> found it online, installing via dpkg
<astronut> Lathiat: ubuntu@ubuntu:~$ sudo tpconfig  -i
<astronut> fatal:
<astronut> No Synaptics or ALPS touchpad device found
<astronut> ubuntu@ubuntu:~$
<OddAbe19> hahaha, OMG, if i upgraded to breezy (not dist-upgrade) this would happen: 774 upgraded, 0 newly installed, 0 to remove and 400 not upgraded.
<OddAbe19> Need to get 456MB of archives.
<OddAbe19> After unpacking 41.4MB of additional disk space will be used.
<OddAbe19> holy crap
<OddAbe19> is mkfontsdir fixed yet?
<Lathiat> OddAbe19: no
<Lathiat> astronut: did you enable the SHMConfig
<OddAbe19> how would i fix that?
<Lathiat> OddAbe19: wait longer before upgrading :)
<OddAbe19> no
<jasoncohen> Amaranth, what exactly do the patches provide?
<OddAbe19> i don't wanna
<OddAbe19> lol
<jasoncohen> Amaranth, the gnome integration patches in ubuntu's firefox
<Lathiat> OddAbe19: http://blogs.gnome.org/cball has information, but dont come crying in here if its broken
<Amaranth> jasoncohen: the make it use the file chooser and such
<Lathiat> OddAbe19: this is a development channel not a user support channel
<OddAbe19> i know it's development
<OddAbe19> i was courious
<jasoncohen> Amaranth, do you have any idea why i would be getting a slight delay between switching pages in ubuntu's firefox while the official build works fine?
<Amaranth> jasoncohen: nope
<jasoncohen> it only seems to be an issue on ubuntu builds. it works fine in debian
<Amaranth> can someone tell me if they're seeing http://bugzilla.ubuntu.com/show_bug.cgi?id=13066 ?
<jasoncohen> i've noticed in backports as well- but those are just breezy packages
<Lathiat> jasoncohen: could be a pango thing
<Amaranth> ah yeah, probably pango
<astronut> Lathiat: no..where do i do that?
<Amaranth> pango trades speed for being able to render every language ever heard of
<jasoncohen> lol
<jasoncohen> and i need that because....>
<jasoncohen> ?
<Amaranth> *shrug*
<jasoncohen> Amaranth, what languages would i get in the ubuntu build that i don't get in the official build?
<Lathiat> Amaranth: the bonobo docks are oh so broken
<Lathiat> Amaranth: they arent draggable anyway ;p
<Amaranth> Lathiat: i thought so
<Amaranth> you can drag them, once
<Lathiat> Amaranth: and yes happens for me
<astronut> Lathiat: where do i enable that...SHMConfig?
<jasoncohen> both hebrew and russian render fine on the official build
<Lathiat> astronut: in your X config, google, and please ask in #ubuntu, this is a developemnt channel not a user support channel
<Amaranth> Lathiat: if you have editbugs can you say that in bugzilla?
<Lathiat> Amaranth: i dont need editbugs just to comment?
<Amaranth> no, i meant to NEW it
<Lathiat> oh
<Lathiat> yeh well i cant do that
<Amaranth> i suppose i could, but that doesn't look very good
<Lathiat> haha
<Amaranth> a comment will work though, thanks
<jasoncohen> Amaranth, i guess the official firefox build is lighter then because it doesn't require pango or many other dependencies
<Lathiat> jasoncohen: ya, i noticed that using the deer park builds
<Amaranth> well, those are so much faster anyway...
<jasoncohen> yeah, i'm comparing 1.0.6 official to 1.0.6 ubuntu hoary
<Amaranth> those with the GNOME integration will be faster than official 1.0 :)
<jasoncohen> though, doesn't debian build with the same compile options & dependencies?
<infinity> Reasonably similar, anyway.
<jasoncohen> Amaranth, well- doesn't hoary's have gnome integration?
<Amaranth> yes
<jasoncohen> but i only notice the problem in ubuntu- no such "freezing' in sarge
<jasoncohen> or sid
<Amaranth> the gnome integration is a seperate package
<Amaranth> i think
<jasoncohen> yeah
<jasoncohen> mozilla-firefox-gnome-support
<jasoncohen> is already instaleld
<jasoncohen> hmm, the debian version doesn't require the bonobo or gnome dependencies
<Amaranth> bonobo? blech
<jasoncohen> yeah- debian doesn't require the bonobo libs or gnome libs but ubuntu does
<mrd`> Odd, /usr/lib/mozilla-firefox/firefox-bin doesn't use any bonobo or gnome libs.
<jasoncohen> deerpark will have automated security upgrades (and it won't upgrade if it would break one of your extensions dependeing on the setting). that'll be nice
<Lathiat> jasoncohen: thats kinda cool
<jasoncohen> yeah, i just tried an alpha build of deerpark today
<Amaranth> it does binary deltas too
<Amaranth> for the upgrades
<jasoncohen> unfortunately the upgrade system isn't up yet- since releases are done by daily builds
<Amaranth> yeah
<Amaranth> the upgrade system is setup, it's just doing the 1.0 style
<Amaranth> where it downloads the whole thing and reinstalls it
<jasoncohen> do upgrades actually work in 1.0.x?
<Lathiat> problem is
<Amaranth> they do on windows
<jasoncohen> when 1.0.6 came out it didn't show the update
<Lathiat> how does that work on say liniux
<Lathiat> where you cant overwrite the binaries?
<Lathiat> (in many cases)
<Amaranth> it doesn't work on windows when you can't overwrite the binaries either :P
<jasoncohen> yeah
<Amaranth> which is almost never, but they should start planning
<jasoncohen> install in /opt and give user permission
<mrd`> Why not just install in your home directory?
<Amaranth> /opt is off limits too
<Amaranth> you want ~/.local/
<jasoncohen> well, i installed in /home but some don't like doing that
<Amaranth> ~/.local/ should work for most things
<jasoncohen> if the upgrade system is good on 1.5, could the apt package support it?
<jasoncohen> or will official upgrades always be through new .deb packages?
<jasoncohen> i.e - 1.5 is packaged by ubuntu but upgrades are handled by the automated upgrade tool which is configured pre-install
<Amaranth> firefox is C++
* mrd` would hope you just install upstream's packages if you want their behaviour and Ubuntu's are upgraded through apt...
<Amaranth> unless their upgrade tool had g++ 3.3 and g++ 4.0 versions...
<wasabi> Hey so I had this neat idea... and was expecting that somebody had already done it, since usually somebody else does my neat ideas before i Have them.
<Lathiat> wasabi: heh
<wasabi> I want to make a livecd that boots from a flash disk and saves changes in a seperate place.
<wasabi> Basically for an embedded router device.
<ajmitch> wasabi: don't exsting live cds already allow for that?
<wasabi> LiveCD have most of the infrastructure for that?
<ajmitch> iirc knoppix let you save settings on a usb drive
<wasabi> I want to use Ubuntu.
<Lathiat> knoppix basically tars up /etc and /home
<Lathiat> sticks that on a flash drive
<Lathiat> and untars it on next boot
<mrd`> They support booting from a CD and saving to a usb drive... I don't see why you couldn't boot from a usb drive and save to another usb drive or somewhere else if that's what you want.
<wasabi> Ubuntu live CD uses some unionfs or something to track mods.
<wasabi> I want to save the mods.
<Lathiat> wasabi: yeh what you want is like unionfs i think
<ajmitch> Lathiat: right, so you'd want an overlay fs, I can't recall what the live cd does for ubuntu
<wasabi> BAsically on this flash disk, I can stick a file containing the "live cd".
<wasabi> And another file containing the user mods.
<wasabi> And at boot just set it up exactly like hte live cd does
<wasabi> You'd be able to upgrade the device by just replacing that one file on the flash... like a cisco or something.
<Lathiat> well
<Lathiat> not sure thatd work so well
<Lathiat> depends how your 'union' fs works
<Lathiat> a cisco works liek that because it uses a configuration file
<wasabi> Yeah. Are there docs about how the ubuntu live cd works?
<Lathiat> whcih does everything
<wasabi> Oh sure, but so does Linux. It just uses a bunch of config files.
<wasabi> Which need to be isolated. ;)
<Lathiat> sure but
<Lathiat> what if the config file changes format
<Lathiat> or whatever
<Lathiat> or you wanna add stuff to the new version
<Lathiat> .. etc :)
<wasabi> Good question, I'll consider it later.
<wasabi> I'd suspect that the dpkg upgrade routines should be run in some way.
<jasoncohen> Amaranth, so, why does ubuntu's firefox have all these extra dependencies like bonobo libraries and gnome libraries that aren't needed for the debian or official builds?
<wasabi> Just like as if it was really being upgraded.
<ajmitch> jasoncohen: gnome integration
<Amaranth> jasoncohen: For the GNOME integration.
<wasabi> And those would be responsible for making it work, however... just like they are required to do now.
<mrd`> Amaranth: Shouldn't only the firefox-gnome-integration package have those depends though?  Not the firefox package?
<jasoncohen> Amaranth, but gnome-integration is a seperate pacakge
<Amaranth> *shrug*
<jasoncohen> apt-cache show mozilla-firefox-gnome-support --> it has a bunch of dependencies as well
<wasabi> Doesnt' look like much of hte livecd documentation has been changed since warty
<Burgundavia> wasabi, what do you mean?
<Burgundavia> jasoncohen, the ubuntu version of FF has the upgrade notifier working. That FF stuff is a hack for systems that don't have a proper package management system (windows, primarily)
<wasabi> hmm?
<Burgundavia> wasabi, wht about the livecd stuff needs to be updated?
<wasabi> LiveCDDesign
<wasabi> Still talks about Warty, etc.
<Burgundavia> ok
<wasabi> Very little info on Casper.
<wasabi> I'm trying to put together my own custom livecd, and not having an easy go at it. ;)
<Burgundavia> I thought there were some other livecd docs lying around
<wasabi> There are some for modifying the existing live cd
<Burgundavia> ask Luis Villa (lu on irc) about it
<wasabi> but none for creating one from scratch
<Burgundavia> ah, ok
<wasabi> I'm basically trying to create a Really Small one.
<fabbione> morning
<bddebian> Hello fabbione 
<jasoncohen> Burgundavia, you sure? it didn't properly notify me when 1.0.6 was out. how does firefox learn of the new version?
<jasoncohen> Burgundavia, i checked for updates using the official build and none were shown
<Burgundavia> jasoncohen, the Ubuntu build disables the auto checking
<Burgundavia> because we have our own package management system
<jasoncohen> Burgundavia, i know- i was using the official build
<Burgundavia> ok
<jasoncohen> anyways 1.5 will have a much more advanced upgrade system that will allow you to upgrade without breaking extensions
<jasoncohen> and do so automatically
<wasabi> I am so close to having my custom live cd working
<wasabi> except I can't get the new kernel installed somehow.
<pitti> Good morning
<\sh> doko: ping
<\sh> morning :)
<\sh> well...I didn't shower so far....so I have to rush
<fabbione> hey pitti
<tseng> some guy named ian of whom ive never heard trashed network-manager
<tseng> (yay)
<Lathiat> im over network-manager
<Lathiat> its useless
<infinity> I'm supposed to be putting some effort into whipping n-m into shape in the next week.
<infinity> Anyone have any input more useful than "it's useless" or "egads, Ian broke it"?
<Lathiat> infinity: please make it really easy for me to right click it and say "Stop network-manager from managing my devices" and then after that have it have a "Start managing my devices again"
<tseng> infinity: well, the applet doesnt start
<Lathiat> if you did that, i'd love you forever
<tseng> infinity: so i cant much test it anymore
<jdub> infinity: thom and i had a long discussion about integration with ifupdown and resolvconf a while back; pretty sure he wrote notes about it
<infinity> jdub : I'll pester him.
<jdub> infinity: oh, and it was related to making n-m work sanely :)
<tseng> infinity: just sortof extra boggled as there are people who upload to ubuntu who never show their face in the community
<infinity> jdub : Speaking of working sanely, why has no one made the obvious leap to use nscd, instead of switching from one nameserver to another?
<jdub> tseng: ian has just started; he's a well known debian developer :)|
<infinity> tseng : He's a new hire.  He's also the original dpkg author.
<tseng> jdub: cheers.
<\sh> doko: is hplip  build-depending on python-qt3? or on python-sip4-qt3?
<Lathiat> infinity: im told nscd is evil, but i have nothing to base that on
<jdub> infinity: dunno, though there are some strong technical/emotional opinions about nscd.
<infinity> Lathiat : It's not perfect, but neither is running a local nameserver.
<Lathiat> \sh: i saw an upload with a changelog sayign that was removed
<jdub> infinity: (the original reason for using bind was that it was very configurable wrt multiple networks and name lookups)
<Lathiat> infinity: but it affects mroe than just dns?
<jdub> infinity: (nscd and resolv.conf doesn't quite solve that)
<infinity> jdub : I don't dig the idea that a machine with NetworkManager installed can't have a nameserver installed (well, unless you ask the nameserver not to bind to localhost)... Kinda ick.
<Lathiat> infinity: it can
<Lathiat> infinity: network-manager starts its own bind9
<\sh> Lathiat: thx...I should read first -changes then irclogs ,-)
<Lathiat> with its own config file
<Lathiat> the problem is
<Lathiat> it just blanket installs bind9
<Lathiat> and so bind9 runs as normal as well
<infinity> Lathiat : Yes, but still on port 53.
<infinity> Lathiat : Run your own instance, boom.
<Lathiat> that needs to be sorted somehow if we're gona use bind9, tho i hear theres plans to use dnsmasq
<Lathiat> infinity: but it binds to localhost
<jdub> infinity: are you on the networkmanager list?
<tseng> ian attempted to make it use resolvconf
<Lathiat> infinity: so i suppose thats a mild issue
<infinity> Lathiat : the latest packages swapped to dnsmasq, but the same issue survives.  You're eating port 53.
<jdub> infinity: it's worth reading back about this stuff
<Lathiat> infinity: but it would still listen on your real interfaces which is what you really care about
<Lathiat> infinity: s/would/wouldnt
<infinity> Lathiat : You;'d have to hand-configure bind not to bind to localhost, or it'll probably just die on invocation.
<Lathiat> resolvconf woudl be nice
<Lathiat> infinity: bind9 will start fine
<Lathiat> infinity: by default, it binds to * which grabs all it can
<Lathiat> so if it cant get localhost it wont care
<jdub> brb
<Lathiat> resolvconf woudl be nice
<Lathiat> cus then it can use avahi-dnsconfd :)
<infinity> resolvconf is what the current (broken) upload was meant to integrate.
<Lathiat> right
<Lathiat> so it just needs to be unbroken
<Lathiat> :)
<infinity> That doesn't change anything, though.
<Lathiat> whats the issue with just changing /etc/resolv.conf? thats always seemed to work for me
<\sh> but a running bind9 for a laptop install with NetworkManager? 
<infinity> Many applications cache resolver requests, so changing resolv.conf on the fly doesn't buy you much, which is why we're still running a local nameserver.
<infinity> So, resolv.conf always points to 127.0.0.1, and we only update it to update our search lists.
<infinity> (Which is still not ideal, cause we could be cacheing the search lists)
<tseng> its polling the hell out of something, likely dbus
<tseng> but it never draws the little icon bit
<infinity> Little icon bits are overrated.
<Lathiat> heh
<\sh> rushing to work....bbl
<jdub> tseng: how's beagle faring?
<tseng> jdub: 0.12 is pretty solid here
<tseng> jdub: and joe is coming up w/ some more big performance boosts in cvs
<tseng> we just need to get some crap moved to main so evo-sharp can build
<tseng> and it will actually work for people
<bob2> Lathiat: mozilla, e.g. seems to cache /etc/resolv.conf forever
<tseng> jdub: if you get the evo-sharp source yourself, youll be in business
<infinity> bob2 : Which, really, is something we should be fixing in mozilla, not working around it with hideous hacks... :/
<bob2> well, yeah
<tseng> hopefully the fixer isnt @redhat.com
<tseng> or rather, they make it poll the file ocassionally instead of binding more of the desktop to dbus
<infinity> It'll be a cold day in hell before mozilla.org accepts patches to make mozilla depend on dbus, I think.
<Amaranth> dbus is our CORBA or XPCOM
<infinity> I could be a crack monkey, but isn't CORBA our CORBA? ;)
<Amaranth> haha
<Amaranth> dbus is the new one
<Amaranth> something that sounds cool and gets used way to much
<tseng> infinity: we are quick to replace it with something more crackful
<bob2> make it interpret SIGPOWER as "uncache the dns server addresses, idiot"
<bob2> or some other pointless signal
<Amaranth> that we have to spend years ripping out of things later
<jdub> yay for breezy kernels on hoary
<tseng> we should get rml's networkmanager patch
<Lathiat> tseng: which does what?
<tseng> makes it a real tray icon
<Lathiat> how is it not a real tray icon?
<tseng> instead of a proper applet forced badly into the tray
<Lathiat> oh
<Lathiat> heh
<tseng> notice the funny gradient in clearlooks
<tseng> and other subtle badness
<Lathiat> yeh
<Lathiat> and its extra whide
<Lathiat> *wide
<bob2> rml?
<Lathiat> bob2: robert love
<bob2> novell dropped netapplet?
<tseng> dude rml <3 nm
<bob2> I know wh orml is :)
<bob2> but he wrote netapplet to begin with
<infinity> tseng : I'm going to be talking to rml about his patches RSN.
<infinity> tseng : He fixed up some VPN stuff too.
<tseng> infinity: yay.
<Lathiat> i wish vpnc worked at my uni
<Lathiat> it seems to send the same packet the cisco client does to start with, but then nothing happens
* tseng goes back to sleep
<infinity> s/sued/used/
<infinity> -EWIN
<lool> quitte: the configure script first checks for /etc/xml/catalog (which you can override) and then searches for particular catalogs with JH_CHECK_XML_CATALOG calls
<lool> quitte: try xmlcatalog --noout /etc/xml/catalog '-//OASIS//DTD DocBook XML V4.1.2//EN'
<lool> quitte: be sure to have xml-core, docbook-xml, and that docbook-xml's did register
<pitti> Hi mvo
<pitti> morning seb128
<seb128> hey pitti
<pitti> ogra: so mdz ack'ed the new hal upstream version?
<seb128> pitti: have you read the bug I reassigned to you this night about this?
<seb128> pitti: the battstat one
<pitti> seb128: not yet, I'm still catching up with bug triage
<seb128> pitti: http://bugzilla.ubuntu.com/show_bug.cgi?id=12909
<seb128> pitti: current comment on it
<pitti> cool, I wanted to prepare the update anyway
<pitti> it also fixes various issues with udev
<seb128> nice
<seb128> pitti: and about dbus? going to update too?
<pitti> seb128: it seems reasonably safe and some guys need it
<pitti> daniels: do you know whether dbus 0.35 has a new API or ABI?
<seb128> when we spoke about it the other day some guys said only the glib binding stuff changed API wise
<Amaranth> seb128: Does gnome_vfs_monitor_add() use gamin to watch the uri?
<seb128> elmo: glitz (incoming) intltool gdesklets gdesklets-data (the current gdesklets-data ships a pile of b0rked desklets due to API changes and a Debian guys has just cleaned all this)
<seb128> Amaranth: yep
<Amaranth> seb128: trying to find out why my menus don't update :)
<Amaranth> ok, then something in gnome-vfs is broken
<seb128> Amaranth: gamin is b0rked
<seb128> I would bet on gamin
<Treenaks> seb128: will it be fixed before breezy-final?
<Amaranth> gamin debug log says it never got a request to watch the things libmenu says it's setting up monitors for
<seb128> Treenaks: if you send a patch for sure
<Amaranth> the only thing inbetween them is gnome-vfs
<Treenaks> seb128: ;) of course.. 
<seb128> Amaranth: good, debug is welcome too ... I don't really trust gamin and would bet on it anyway though
<Amaranth> it'll have to wait until morning though, it's 3am and things are starting to blur :)
<Amaranth> night all
<seb128> good night
<seb128> oh
<seb128> and how is smeg going?
<Amaranth> i lost all my work :/
<seb128> still an option for 5.10 or you trashed all your changes with your hdd and we should better delay it?
<Amaranth> well, if 0.7.5 is usable it's an option
<Amaranth> otherwise i don't think i'll be finishing 0.8 until late august or so
<seb128> you are the best placed to know what issues 0.7.5 has
<Amaranth> well, as long as you have the fixes from pyxdg CVS 0.7.5 has no issues that i know of
<seb128> Amaranth: k, good, thanks
<Amaranth> of course it dies on badly encoded filenames but the spec doesn't define what to do with those and no one on the xdg list seems to want to decide
<seb128> you had a patch for this, no?
<seb128> can't you just ignore those?
<Amaranth> the patch silently dropped chars that couldn't be represented in UTF-8
<Amaranth> gnome-menus doesn't ignore them
<Amaranth> it shows them then fails to find them to launch them
<Amaranth> so no one really knows what to do with them
<seb128> I would just ignore these files
<seb128> better than crashing
<Amaranth> i'll work on a patch for pyxdg tomorrow
<seb128> cool, thanks
<seb128> 'night
<\sh> pitti: thx..the you ff from yesterday doesn't crash anymore with flash enabled
<pitti> \sh: I didn't upload ffox yesterday
<\sh> pitti: or the day before yesterday
<\sh> the last upload 
<\sh> doko: ping
<doko> pong
<\sh> doko: hplip...u included a build-dep on python-sip4-qt3? or doesn't it use python qt bindings anymore? :)
<\sh> grmpf..who is setting the bugzilla entries to pending upload and is not assigning them to his account...
<doko> \sh: no, not needed
<seb128> doko: cairo 0.6 uploaded
<doko> seb128: ok, will test ... glitz enabled?
<seb128> doko: nop, I've asked a sync from incoming to elmo for that ... 
<seb128> doko: I'll redo a build with glitz when elmo has synced it
<Kamion> infinity: I guess you didn't spot my seed breakage comment from yesterday
<Kamion> infinity: I've unbroken the archive the hard way, by copying patch-80 to a fresh directory that I own, fixing up the permissions, and killing your old patch-80 directory
<Kamion> infinity: please move umask 002 to the top of ~/.bashrc, before [ -z "$PS1" ]  && return
<fabbione> Kamion: how badly would you feel if i upload another kernel today?
<Kamion> fabbione: oh well
<fabbione> Kamion: i did all the "heavy lifting" job before VAC
* Kamion finally manages to commit the seed change for -5 ...
<fabbione> so that i left only a few bits for infinity 
<fabbione> seb128: no i don't have it right now, but i can grab it for you in a minute or two
<highvoltage> hi guys, everyone involved in edubuntu, this is a notice that there will be a meeting this afternoon in #edubuntu to discuss current status. time: 12:00 UTC/GMT.
<seb128> fabbione: would be nice, thanks
<fabbione> seb128: thanks to you!
* fabbione create a new chroot
<fabbione> Kamion: btw.. did you ever get around to fix debootstrap for sparc or is it still untested?
<Kamion> fabbione: still untested probably, I've entirely forgotten what bugs you reported in it, if any ...
<Kamion> ogra: do you use PHP in Edubuntu?
<ogra> Kamion, ha ha ha...
<fabbione> Kamion: no, no bugs.. once you told me that debootstrap was going to be broken for sparc and i agreed on it.. i just don't recall us talking about it anymore.. if it needs testing i can do it :)
<ogra> Kamion, i guess there is not much that more used in edubuntu
<Kamion> ogra: would it break anything if I merged infinity's change to the Ubuntu seeds that switches from PHP4 to PHP5?
<ogra> Kamion, yes
<ogra> :(
<ogra> many of the packages i use arent switched to 5 yet.... 
<pitti> I thought it was supposed to be backwards compatible?
<Kamion> fabbione: oh, that needs arch-specific overrides, I can't do that
<Kamion> ogra: they should depend on php4 then
<ogra> (moodle, mediawiki (which just gets packaged in debian, but they told me these pacages wont be php5 compatible))
<fabbione> Kamion: so what do we need to do exactly? (other than giving it a shot)
<pitti> Kamion: the problem is that we actually intended to demote php4 to universe once we have php5 in main
<Kamion> ogra: if those depend on php4, it'll be fine
<Kamion> pitti: not my problem
<ogra> Kamion, but those will have to move to main
<Kamion> fabbione: try it, report a bug with what breaks
<fabbione> Kamion: make sense :)
<ogra> Kamion, which will keep php4 there too
<Kamion> ogra: I think the seed merge will be fine actually, as long as the dependencies are correct it won't break anything in itself
<ogra> ok
<Kamion> it's only changing the supported seed
<ogra> fine then :)
<Kamion> I need to merge the installer and casper seeds which is a later patch to ubuntu-devel@lists.ubuntu.com/seeds--breezy--0, which is why I ask :)
<Kamion> ok, done
<fabbione> seb128: never mind.. it's still the binutils problems that reflects into the gtk test of lp-integration...
<fabbione> seb128: nothing you can do about it.. thanks tho.
<Kamion> ok, this morning's daily CD build will probably be fucked, but I'm rebuilding it now
<Kamion> "can't find kernel modules" style of breakage
<seb128> fabbione: k
<fabbione> Kamion: uh.. udebs are there :)
<Kamion> fabbione: seeds weren't up to date, I've fixed them
<fabbione> oh ok...
<Kamion> the seeds matter, otherwise cdimage will leave all the kernel module udebs off the CD :-P
<fabbione> didn't we want more space on CD anyway? :P
<Kamion> heh
* fabbione debootstrap sparc...
<seb128> JaneW: YOUR MAIL TITLE LOOKS LIKE SPAM WITH ALL THE CAPS :p
<fabbione> pitti: ping?
<pitti> I'm right here
<fabbione> pitti: before suggesting users to file bugs because /dev/inotify is not there.. do you mind to ask me..?
<fabbione> it's normal
<fabbione> the device is not required anymore
<JaneW> seb128: It's a notice :P
<fabbione> now i am getting hammered by people with "OMG THE DEVICE IS NOT THERE ANYMORE! IT MUST BE BROKEN"
<fabbione> when instead it works perfectly on i386/amd64
<seb128> JaneW: yeah, but you probably want to people to read it and not to trash it with the spam? :)
<fabbione> ia64 and ppc...
<JaneW> seb128: I use caps at times, when I am trying to be LOUD
<fabbione> meh s/ppc/sparc
<pitti> fabbione: sorry, there was no other reply on the udevel list, so I just took seb128's approach of "use bz for bugs"
<JaneW> seb128: sorry, won't do that again then, I guess I aussmed people could read...
<jsgotangco> SURE WE CAN :)
* jsgotangco hides
<Treenaks> JaneW: at least the subject wasn't "Congratulations" :)
* fabbione is tempted to continue pitti's public larting :)
<fabbione> pitti: ok.. don't worry.. just next time let's avoid panic ;)
<pitti> sorry, dude! :-)
<pitti> ok
<seb128> JaneW: no need to be sorry, but I'm used to categorize CAPS SUBJECT == spam and almost trashed this one ... so I just pointed it may have this effect for some people :)
<JaneW> Treenaks: no it;s ok, I am keeping all my lotery winning to myself, I have won at least 20 times now, I'm extremely lucky...
<jsgotangco> Treenaks, lol
<JaneW> seb128: point taken, thanks
<seb128> np :)
<seb128> pitti: thanks for pointing bugzilla to users abusing the list for bugs ;)
<pitti> fabbione: out of interest, what is now used instead of /dev/inotify?
<pitti> this worked with ioctl()s formerly, right?
<Treenaks> pitti: syscalls
<fabbione> pitti: as Treenaks said.. syscalls
<pitti> ah, ok
* Treenaks now reads changelogs ;)
<fabbione> pitti: same reason why we have coverage for 4 out of 6 arches for now
<fabbione> pitti: ppc and hppa don't have syscalls assigned yet
<sivang> Morning all
<sivang> he JaneW 
<mvo> am I blind? or is there no search in malone?
<Kamion> fabbione: at least powerpc is going to be fixed before breezy, I hope?
<JaneW> hi sivang
<fabbione> Kamion: yes yes.. they are fixing them on a daily base
* sivang continues with patching desktop apps for lp-integration. Weekend are just plain fun :)
<fabbione> Kamion: but they are asking the differnet $arch maintainers to assign the proper numbers...
<fabbione> Kamion:   Package lib64gcc1 is not installed.
<fabbione> Kamion: that's needed for sparc bootstrapping..
<Kamion> fabbione: right, that's part of the arch-specific overrides problem
<fabbione> Kamion: ok.. do i need to ask elmo to do something?
<Kamion> because powerpc also has lib64gcc1, but it isn't needed in base there
<fabbione> nope.. but we have nothing in 64bit userland for ppc :)
<Kamion> fabbione: technically yes, but it's "implement a bunch of hard stuff in katie", it's not "flip this switch"
<sivang> Kamion: does that mean that bootstrapping ppc always occurs in 32bit mode ?
<Kamion> I can just bump lib64gcc1's priority and accept the bloat on powerpc I guess
<Kamion> sivang: of course
<fabbione> Kamion: how much will ppc bloat?
<Kamion> debootstrap has no concept of "mode"
<Kamion> it's not a lot, 100KB or so
<Kamion> seems like a DOIT I guess
<fabbione> Kamion: well we are like talking 100KB on ppc or an entire arch out of the game
<fabbione> 100KB are doable...
<Kamion> yeah, one second while I run germinate for powerpc
<fabbione> thanks
<sivang> fabbione: do you recall I asked you about the bu that  rpevented booting on pSeries, where can I read about what it was and how it got fixed?
<sivang> fabbione: (botting from install image, that is)
* sivang apt-get upgrades
<fabbione> bu ? 
<sivang> fabbione: s/botting/booting/
<Kamion> s/bu/bug/
<sivang> heh
<sivang> Kamion: thx
<fabbione> sivang: the installer problem we had was missing drivers in the .udeb
<sivang> fabbione: a couple of weeks ago I tried booting the install image under one of my LPARs, and was unable to get into the grub prompt
<fabbione> if there are other bugs i don't know
<fabbione> there is no grub on ppc...
<sivang> fabbione: ah ok, do you have it in debian bts or something?
<Kamion> fabbione: actually, I don't get it, lib64gcc1 doesn't show up in jessica output
<sivang> fabbione: sorry, yaboot :)
<Kamion> fabbione: can I demote libc6-sparc64 to priority optional? what breaks if I do that?
<sivang> fabbione: still need to adjust to the arch specifics 
<fabbione> sivang: the bug was ubuntu specific.. we readded the drivers to the udeb.. that's it
<sivang> fabbione: ah cool, which drivers were those?
<fabbione> Kamion: one second...
<fabbione> sivang: almost all of them.
<fabbione> Kamion:  libc6-sparc64 depends on lib64gcc1; however:
<fabbione> Kamion: i think there is quite a bunch of stuff that Depends: libc6-sparc64
<Kamion> fabbione: right, libc6-sparc64 is the only thing that needs it, and nothing else in base Depends: libc6-sparc64
<Kamion> fabbione: nope, hardly anything
<Kamion> fabbione: does anything need it but not state a Depends?
<fabbione> Kamion: i am checking...
<fabbione>   libdlm0
<fabbione> and we don't care
<fabbione> ok.. demote it my friend
<fabbione> and see what else breaks :)
<Kamion> $ sudo -u katie ./alicia.new libc6-sparc64 optional
<Kamion> I: Will change priority from important to optional
<Kamion> Continue (y/N)? y
<Kamion> Done
<fabbione> for desktop that stuff is ok to stay out.. but they are almost required for the buildd...
<fabbione> but let's solve one problem at a time
<Kamion> needs to be added to the explicit build-essential list, I'm fixing that now
<Kamion> why does the buildd need it?
<fabbione> Kamion: i don
<fabbione> Kamion: i don't recall the details..
<fabbione> i will check it again later..
<fabbione> i still need to build vim before i can bootstrap properly
<fabbione> and i will test buildd later..
<fabbione> sparc is anyway a bit of a special case...
<fabbione> Kamion: we just got unionfs to build on ppc..
<fabbione> i am definetely going to upload today
* fabbione prepares linux-meta
<Kamion> fabbione: ok
<fabbione> JaneW: i need a name please...
<JaneW> fabbione:  Scintilating Sesame
* fabbione hugs JaneW 
<JaneW> :)
<Lathiat> mdz: ping
<Mez> yes?
<Mez> oh 
<Mez> sorry
<Mez> :P
<Mez> read that as mez
<Lathiat> heh
<pitti> seb128: here?
<seb128> pitti: pong
<cartman> 50 nicely packaged Hoary Cds
<cartman> found its way to my home
<cartman> thank you guys! :)
<pitti> seb128: wrt #11486 (gstreamer sounds bad with alsasink), can we try to apply the patch in http://bugzilla.gnome.org/show_bug.cgi?id=305186?
<pitti> seb128: oh, it's already applied, sorry
<seb128> pitti: we have 0.8.10
<seb128> pitti: yeah
<pitti> darn
<JaneW> Hi all, could anybody who has not updated their BreezyGoals in the last week, please do so.
<JaneW> we need a clear indication of where each goal is, and whether it is going to be finished in time for Breezy
<JaneW> Thanks
<JaneW> I will start contacting anyone who has no update in their goal in the next few hours
<bob2> bear in mind it's well after work hours for .auers
<tseng> yay for firefox crashing
<tseng> JaneW: ok, i cant update anything because firefox wont stay open for 12 seconds
<daniels> pitti: yeah, API and ABI both chagngedc, but its' reasonably trivial; we can easily 
<daniels> pitti: patch the apps using it.  it's a better long-term solution.  i'll knock up a new set of packages on monday for you.
<pitti> daniels: cool; well, it's not really "for me", but for some other spec a guy works on
<Mez> hmm
<Mez> anything that's very likely to break if I install breezy ...?
<Mez> and upgrade it to current)
<tseng> plenty
<Mez> like .. ?
<Lathiat> Mez: X amon g other things
<tseng> like X not starting
<Mez> (I'm just burning a colony 2 cd)
<Mez> I thought someoen said the other day they got X working?
<tseng> BWAR
<daniels> pitti: yeah, we need 0.35
<tseng> firefox must die
<Mez> well, I shall see eh?
<Mez> It cant do much harm as long as I make sure I do the boot partition righ
<Lathiat> http://blogs.gnome.org/callum
<Lathiat> see whats linked from there
<Mez> Error: No such notebook: callum
<tseng> one l
<Mez> http://blogs.gnome.org/calum
<Lathiat> my bad
<tseng> JaneW: can i please email you a status update
<tseng> JaneW: i have tried to login at least 12 times now, firefox refuses to do anything but crash
<JaneW> tseng: absolutely, I can do the wiki part.
<JaneW> tseng: thanks
<JaneW> that applies to everyone
* Kamion has updated most of his, but a couple will have to wait until I dig myself out from the OEMInstaller hole, sorry
<Kamion> so that I can think about them without evicting useful state from my brain
<pitti> tseng: I always use ffox for editing the page, how on earth do you manage to crash it so often?
<pitti> tseng: do you have some weird extensions installed?
<tseng> pitti: its segfaulting
<tseng> pitti: all over the udu wiki
<pitti> tseng: besides, mozilla should work :-)
<Lathiat> bah firefox is crashing isnt it
<Lathiat> i only just noticed now
<tseng> you too?
<pitti> tseng: yes, but it doesn't happen without extensions
<tseng> pitti: hm well
<Lathiat> not on the udu wiki 
<Lathiat> just in general
<Lathiat> and i have no extensions
<JaneW> Kamion: thanks, but mdz is pushing quite hard for updates on all goals now, so I can;t promise to leave you alone until it's done :)
<tseng> pitti: my extensions window has "English (GB) Pack"
<Kamion> JaneW: sure, just saying that's all I can do for now
<pitti> hm, I even have some more
<Lathiat> tseng: hm, so does mine
<tseng> pitti: i have one theme installed (and using)
<Lathiat> tseng: the version on the language pack is 1.0..4
<JaneW> pitti: yes I had that problem until I uninstalled all flash extensions
<tseng> ohh
<Lathiat> could be why
<tseng> i do have flash
<pitti> JaneW: I do have flash installed, works fine
<JaneW> I had to chose between flash and being able to work, was a tough choice ;)
<JaneW> pitti: yeah but you have breezy not hoary...
<sivang> fabbione, Kamion : well, thinking about that you uncovered a missing udeb problem, I think that's not the actual cause of what I was experiencing unde the LPAR, since it never even got to the yaboot screen, so that's probably have to do something with the image layout , or something else more low level
<pitti> JaneW: it still makes a difference? it's the same upstream version now
<davyd> does anyone know about Breezy/AMD64 something in GTK+/GLib being broken?
<fabbione> sivang: can you please file a bug with details?
<pitti> GTK BOOG! :-)
<fabbione> sivang: i don't even understand what you mean by not arriving at yaboot.. did the installer actually worked? or it didn't do anything?
<Kamion> sivang: the missing udeb thing was just this morning's CDs
<Kamion> and not getting to yaboot has zero to do with udebs
<fabbione> Kamion: meh well not really...
<fabbione> Kamion: the i told sivang about the missing drivers inside the udebs
<sivang> fabbione: yes, when I booted the LPAR, I just got straight away a msg from the firmware "no operating system installed" 
<sivang> Kamion: right
<sivang> Kamion: that's why my conclusion
<Kamion> fabbione: that can't possibly be sivang's problem either, his machine almost certainly just doesn't support yaboot
<davyd> pitti: what sort of bug?
<fabbione> sivang: before or after the installer?????
<sivang> Kamion: no it does, SLES9 and RHEL3 do boot
<sivang> fabbione: before the installer, sorry
<pitti> davyd: never mind, that was just a reflex to poke seb :-)
* davyd smirks
<sivang> Kamion: that is , each LPAR is a box in its own regards, at teh hardware level. 
<Kamion> sivang: CD boot or netboot?
<sivang> Kamion: cd boot
<davyd> this is a little distressing
<fabbione> sivang: try a netboot...
<pitti> davyd: sorry
<davyd> nah, it's ok
<davyd> I was just trying to finish some GNOME screenshots
<pitti> davyd: it's a long story
<davyd> so I thought I should grab the latest versions of some things
<seb128> davyd: what is the issue?
<davyd> seb128: try to start a GTK+ app and it segvs
* pitti comforts seb128
<tseng> JaneW: sent.
<Kamion> sivang: CD booting can be finicky, I may well be missing stuff in cdimage
<seb128> davyd: utch
<seb128> davyd: backtrace ?
<davyd> seb128: I'm seeing what I can do in that department
<Kamion> sivang: unfortunately I don't have time to investigate at the moment, but if you can find out what mkisofs flags are used for the SLES9 or RHEL3 CDs then that would be useful
<seb128> davyd: what/when have you updated?
<sivang> Kamion: cool, that's one lead I could use :)
<davyd> seb128: about 5 minutes ago
<davyd> on amd64
<seb128> davyd: cairo 0.6 ?
<davyd> gconf is running, so I must have glib
<davyd> seb128: seems that way
<seb128> pango 1.9.1 ?
<davyd> 1.9.0
<sivang> Kamion: I'm already in contact with a couple of fedora guys so it won't be hard to find that out - futhermore, they have also told me that they use anaconda to create those boot disks, and I might find more stuff to "borrow" from there, does that make sense? (I wasn't aware anaconda produces install disks)
<davyd> hmm, that sounds suss
<davyd> like the buildds are behind
<Lathiat> or it ftbfs
<seb128> davyd: bah, that's random guess ...  a backtrace would be nice
<seb128> davyd: updating just cairo works fine here on x86
<davyd> seb128: gdb doesn't like something...
<seb128> maybe try downgrading cairo to 0.5.2?
<Kamion> sivang: ah, I see the relevant anaconda code, yes
<davyd> cairo_scaled_font_create
<seb128> gar
<seb128> what about it?
<sivang> Kamion: nice, I'm very interested in this, should I just get anaconda's source to read and find out?
<davyd> that's where the segv is occurring, hang on, I'll need to install symbols to get more
<Kamion> sivang: hmm, they invoke mkisofs in a totally different way from the way we do, though
<seb128> davyd: would be nice to try with pango 1.9.1 when your mirror get it
* davyd wonders if there is a cairo -dbg
<Kamion> sivang: sure, 'cvs -d :pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS co anaconda', it's in scripts/mk-images.ppc
<davyd> seb128: I'm using the main mirror
<sivang> Kamion: thanks, I will fetch that now
<seb128> davyd: http://archive.ubuntu.com/ubuntu/pool/main/p/pango1.0/libpango1.0-0_1.9.1-0ubuntu1_amd64.deb
<seb128> davyd: it has it
<Kamion> meh, they build pseries ISOs in a totally different way to mac ones
<davyd> seb128: seems like the Packages file isn't updated yet
<JaneW> tseng: many thanks
<Kamion> I don't want to have to build two ISO images ...
<sivang> Kamion: I had a feeling :)
<seb128> davyd: right, you can get this one and the -common and dpkg -i or wait some minutes for the update
<sivang> Kamion: why don't I try to build that image like they do, see if it works at all and then will think about it?
<Kamion> sivang: you probably won't be able to build it literally like they do
<davyd> seb128: downloading now
<sivang> Kamion: ah, how so?
<JaneW> tseng: I haven;t receievd it yet... ps did you ever get e-mail from me? I mist have tried about 7 addresses for you now...
<tseng> JaneW: i replied to that too
<tseng> uhm
<tseng> JaneW: Unfrgiven (Ankur Kotwal) has owned that for months, ive asked him to update it
<tseng> write(2, "firefox-bin: cairo.c:86: _cairo_"..., 130firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.
<Kamion> sivang: because anaconda != d-i :)
<tseng> ) = 130
<tseng> does this look horribly bad seb128 ?
<sivang> Kamion: ah :)
<Kamion> sivang: you should be able to try cherry-picking mkisofs flags though
<JaneW> tseng: oh that's right... sorry now I recall
<Kamion> sivang: our script is in arch: baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005; baz get colin.watson@canonical.com--2005/debian-cd--ubuntu--0 debian-cd; look in debian-cd/tools/boot/breezy/boot-powerpc
<seb128> tseng: does every gtk app crash? what arch are you using? what did you update?
<tseng> seb128: i updated everything an hour ago
<davyd> haha!
<Kamion> sivang: could be worth trying the -J and/or -T flags
<tseng> oh there goes Evo
<seb128> tseng: and other questions?
<Kamion> as a first guess
<tseng> seb128: x86, and yes
<sivang> Kamion: Ok, I will start experimenting and tell you if anything works
<seb128> tseng: every gtk app crash?
<tseng> moz and evo so far
<tseng> s/moz/ff
<seb128> start gedit?
<tseng> open file in gedit = crash
<Kamion> it may well just need the ISO to have Joliet extensions
<seb128> that's a fileselector crash
<seb128> it's known and not new
<seb128> ok, so that's not every app :p
<sivang> seb128: crashes for me as well
<davyd> hmm, seems there are some XKB issues
<sivang> seb128: my gedit patch is not yet in right?
<seb128> sivang: not, it's not correct
<tseng> seb128: muine isnt crashing either
<tseng> (yet)
<seb128> tseng: getting a debug backtrace would be nice
<sivang> seb128: I will fix it (I already know what's wrong) and ping you when I have refreshed pkgs
<seb128> k
<tseng> seb128: does that mean i have to build all this crap with symbols?
<tseng> hm the cairo stuff resolves
<seb128> tseng: all this crap being libcairo which is like a 600k package
<seb128> libpango1.0-dbg 
<tseng> i have libcairo symbols somehow
<seb128> and use LD_LIBRARY_PATH
<tseng> set to?
<seb128> /usr/lib/debug
* seb128 should update pango to use dh_strip 
<tseng> seb128: tseng.ath.cx/gdb-backtrace is a start
<tseng> but it doesnt resolve everything stiff
<tseng> still*
<tseng> or did i need debug symbols when i did the coredump too
<sivang> Kamion: I'm not sure I understand the cherry-picking mode, what does it entails?
<Kamion> sivang: do you know the term "cherry-picking"?
<Kamion> sivang: it means to select and try things that look good, one by one
<seb128> tseng, davyd: I'm updating gtk, maybe that will fix it 
<tseng> seb128: k
<sivang> Kamion: ah ok, I wasn't aware of that nice english term :)
<tseng> oh blah theres no function names there
* tseng builds cairo
<seb128> tseng: just wait an hour for the gtk update
<tseng> ok.
<seb128> downgrade cairo to 0.5.2 for the moment if you want
<tseng> thanks seb
<seb128> np
<sivang> Kamion: can I produce the test images under i386? or must I produce them under the same arch on which I intend to use them?
<doko> seb128: anything wrong with libcairo?
<seb128> doko: the new cairo/pango seems to have issues
<doko> ok, libgcj doesn't use pango ...
<tseng> JaneW: how about now
<sivang> seb128: (just to be syncd) what issues did you spot with the gedit patch?
<seb128> Build-Depends not updated
<sivang> seb128: ah right :-/
<JaneW> tseng: got it
<tseng> JaneW: cheers.
<Kamion> sivang: i386 is fine, we don't have a separate cdimage machine for each architecture :)
<pef> hello
<ogra> Kamion, how hard would it be to make the network setup in the installer default to manual in the edubuntu installer, assuming i install a standalone ltsp server there is no dhcp around
<sivang> Kamion: cool
<pitti> trulux: ping
<Kamion> ogra: it's one preseed, netcfg/disable_dhcp=true, which is documented in the installer boot screens, press F7 at the isolinux prompt
<Kamion> ogra: want that switched on for Edubuntu then?
<ogra> Kamion, yep, i assume having the machine standalone is the more common case... and i'd like to avoid seeing a errormessage
<Kamion> ogra: surely this is only for the server?
<Kamion> not clients?
<ogra> Kamion, the ltsp server is the default...
<Kamion> ogra: yes, and debian-cd has a non-server config
<ogra> not for the standalone workstation install though
<ogra> oh, that needs to change then too
<Kamion> why? the workstations should default to DHCP I'd've thought
<ogra> but in other news edubuntu daily from yesterday seems to install fine :)
<ogra> Kamion, the Ws should use dhcp, the server not... but the server should be the default
<ogra> currently the WS install is only thought for teachers to run the setuo at home...
<ogra> setup
<ogra> also the hostname should default to edubuntu, but thats marginal
<Kamion> ogra: right - I've changed the server config to default to manual network configuration; please file a Bugzilla bug against debian-cd to get the Edubuntu default changed to server
<Kamion> ogra: for server or workstation?
<ogra> Kamion, for both ? 
<Kamion> ok
<ogra> if i install in my network i'll change it anyway... but the default shouldnt be ubuntu...
<Kamion> ogra: done
<ogra> yay, thanks...
<ogra> from a installer perspective the CD seems to be in a awesome condition... (i'm not at X yet ;) ) kudos Kamion  :)
<Kamion> glad that works at least
<pitti> seb128: I can't reach neither daf nor carlos :-/
<seb128> pitti: maybe they are travelling to go to brazil
<Mez> mako: ping
<seb128> pitti: bah, a few days will not matter, update next week ... 
<mako> Mez: yes
<Mez> With Regards to your email: what is there left pending?
<mako> Mez: umm.. remind me which email i'm talkinb about.. i've sent like 150 today already :)
<Mez> Backports Team formation
<pitti> ah, main network back, brb
<Mez> I asked whether anything was pending, and if so what it was and if I should add it to CC agenda
<Mez> you replied "yes"
<Mez> lol
<Mez> (near enough)
<mako> yes, add it to the agenda
<mako> no, i think that's it
<Mez> what is still pending
<mako> i've talked to matt briefly about it.. if things are rolling, we'll just stamp it at the next meetting
<mako> sorry that it was unclear.. i'm sort of bulldozing through this mail right now :)
<Mez> so, what should I add ?
<mako> creation of backports team
<Mez> kk
<infinity> Kamion : Shit, dude, sorry about the umask.
<Kamion> infinity: no problem, fixed now :)
<daniels> infinity: maybe you should read up on permissions.
<Kamion> haha
<infinity> daniels : Cock.
<fabbione> infinity: yo....
* infinity disappears.
<fabbione> infinity: eheh up to you :)
<fabbione> i had good news ;)
<fabbione> i guess i will keep them for me
* infinity reappears.
<fabbione> infinity: let's move to u-k
<infinity> ?
<tseng> #ubuntu-kernel
<infinity> Right , somehow I thought he meant "let's move to the UK".
<fabbione> dude.. i like beer.. even after 11
<pitti> seb128: so the polypaudio sink is broken? since we will keep esd in breezy, would you mind if I unseed polypaudio?
<daniels> i thought polypaudio was the way of the future
<Kamion> fabbione: my fiancee asks "if you like beer, what are you doing living in Denmark?"
<daniels> fabbione: beer is good, but infinity doesn't like beer.  only alcoholic lemonade.
<daniels> Kamion: i think canonical should pay me relocation to belgoiubgleium.
<fabbione> Kamion: well denmark still produces beer.. i didn't say GOOD.. but well. i am only 6 km from Tuborg :P
<daniels> the second attempt was even worse than the first.
<fabbione> daniels: yeah yeah
<daniels> fabbione: the julebryg isn't bad.
<daniels> not as good as, say, a bottle of chimay blue, though ...
<Kamion> fabbione: maybe you should move to Scotland, it's about as cold as Denmark, they don't close at 11, and you can actually buy decent English beer ...
<jdub> i'm sure they also serve perfectly respectable scottish beer too
<daniels> Kamion: what, the Scottish climate cools the beer down? :)
<jdub> royalist!
<Kamion> the Scottish beer's OK but not as good
<Kamion> daniels: thpppppt
<Kamion> anyway, work ;)
<infinity> Work, a 10pm?
<infinity> s/a/at/
<seb128> pitti: not at all
<seb128> infinity: can you give a retry to epiphany's build
<daniels> infinity: next he'll try to tell us that UTC is the one true timezone.
<seb128> jdub: hey :)
<jdub> yo seb128!
<seb128> pitti: so we stay on esd?
<pitti> yes, polypaudio is still too buggy (some crashes and lack of sound events), ENOTIME to work on it, and we are too close to the freeze
<tseng> jdub: oh, other beagle issue
<pitti> seb128: however, Erik said that upstream is back :-)
<pitti> seb128: so maybe there's again hope for breezy+1 :-)
<seb128> pitti: nice, for 6.04 we will use it maybe :)
<seb128> yeah
<tseng> jdub: 0.12 still expects /dev/inotify to do things normally
<tseng> jdub: we need cvs/next release for the syscall crap
<jdub> ahr
<daniels> seb128: maybe we could use howl for 6.04 also
<Kamion> infinity: no, I mean me ...
<tseng> i think ill test that now, in fact
<jdub> daniels: has howl finally killed off the APSL bits?
<seb128> daniels: you better start to run now
<daniels> jdub: don't think so, I just like giving you shit.
<daniels> seb128: HowlRoadMap, SebastienBacherLead
<jdub> it's on its way, don't know if it's going to be in a sane timeframe
<jdub> i should bug Lathiat about avahi
<seb128> jdub: somebody sent a patch for gnome-vfs bonjour support yesteday (#311882)
<jdub> aha, and bonjour is now bsd, right?
<daniels> only seb128 should be allowed to say bonjour.
<jdub> heh, it's in a tarballs/apsl/ directory
<jdub> seb128: close the bug and tell them the apsl is evil ;)
<seb128> bah
<seb128> all that sucks
<jdub> yeah
<pitti> alsa-utils changes changelog, debian/rules:
<pitti> +       # do not install alsaconf for Ubuntu
<pitti> +       rm -f debian/alsa-utils/usr/{sbin/alsaconf,share/man/man8/alsaconf.8.gz,share/locale/ja/LC_MESSAGES/alsaconf.mo}
<pitti> and control:
<pitti> -Depends: ${misc:Depends}, ${shlibs:Depends}, whiptail | dialog, modutils (>= 2.3.5-1) | module-init-tools, pciutils (>= 1:2.1.11-4), python, linux-sound-base (>= 1.0.9b-1)
<pitti> +Depends: ${misc:Depends}, ${shlibs:Depends}, whiptail | dialog, modutils (>= 2.3.5-1) | module-init-tools, pciutils (>= 1:2.1.11-4), python, linux-sound-base (>= 1.0.9b-1), lsb-base (>= 1.3-9ubuntu2)
<pitti>  Recommends: alsa-base (>= 1.0.9b-3)
<pitti> -Suggests: udev (>= 0.063), lsb-base
<pitti> +Suggests: udev (>= 0.063)
<pitti> really cool now :)
<pitti> I still remember the pain when merging a previous version
<jordi> pitti: hmm, the rm is a bashism. :)
<pitti> argh, sorry, ECHAN
<pitti> sorry for the flood
<tseng> infinity: blargh, tomboy fails on sbuild now because of unseeded stuff now also
<tseng> infinity: is that on its way now?
<aigarius> fabbione, ping
<fabbione> aigarius: pong?
<aigarius> fabbione, I am thinking about when to make full and when to make incremental backups
<fabbione> aigarius: i am officially in holidays since 3 minutes :)
<aigarius> ok
<fabbione> aigarius: but ok :)
<fabbione> hmm
<fabbione> how much does it on average an incremental backup?
<aigarius> 5-10% of a full backup
<aigarius> I am thinking that I could just define a max_days_between_full_backups config option
<fabbione> i would say an incremental to run at night via crontab or on request
<fabbione> and a weekly full as default
<aigarius> and do incremental backups withing that period
<fabbione> but yeah.. configurable it's even better
<aigarius> I want this behaviour to be consistent regardless of use of automatic/manual backup runs
<aigarius> I have got full backups running both locally and trough ssh
<aigarius> now working on incremental backups :)
<fabbione> aigarius: yes, but you did ask me how often... right?
<fabbione> so my suggestion is daily incremental and weekly full
<fabbione> but if you can make it configurable it's even better...
<aigarius> yes, right. good. happy holidays then. when do you plan to come back?
<fabbione> as i just wrote in the mail
<fabbione> aigarius: thanks :)
<aigarius> ah, ok
<pvanhoof> will Ubuntu breezy be xen enabled in it's kernel?
<pvanhoof> and/or is it already? (the current kernel package)
<Treenaks> xen: the hype of te moment
<pvanhoof> Treenaks, but will it be supported by the breezy kernel? :)
<carstenh> aigarius: i guess you don't backup things like /bin and /usr, because they can be restored from the packages that are installed?
<aigarius> carstenh, yes I don't do that by default
<carstenh> aigarius: how do you ensure that the same package-version are installed after restoring a full backup?
<aigarius> carstenh, you can check out my progress at http://koyanet.lv/soc/  . It is a bzr repository, but you can also get the latest version with you browser.
<aigarius> carstenh, I backup "dpkg --get-selections"
<carstenh> aigarius: i think this is nessessary, because new package-versions may have new configuration-files
<carstenh> aigarius: this does von include package-versions
<hughsie> ogra: can i ask a newbie question
<ogra> hughsie, hehe, sure :) these are my favorites ;)
<carstenh> aigarius: i guess you have well thought about the backup :) just my 5 cent ;)
<aigarius> carstenh, a full restore is kind of a special case scenario. the usual use is backup/restore of a single file or a subdir.
<carstenh> aigarius: ah, ok
<hughsie> ogra:I've installed 5.04, and want to upgrade to latest and greatest so I can try our the new dbus and hal and libnotify stuff for g-p-m
<hughsie> how ould i do this the easiest?
<aigarius> carstenh, it would be pretty hard to restore to a specific version if that is not the latest in the repository
<carstenh> aigarius: yes, ubuntu is iirc missing something like snbapshot.d.n
<ogra> hughsie, edit all occurences of hoary to breezy in the file /etc/apt/sources.list...
<hughsie> is that it? then do an apt upgrade?
<aigarius> hughsie, X is quite broken in breezy, so better don't :)
<ogra> hughsie, then run "sudo apt-get update" to get the new package lists
<ogra> hughsie, after this "sudo apt-get dist-upgrade"
<aigarius> or be prepared to use a text mode IRC client for debuging :)
<ogra> hughsie, anfter that have fun in getting X working
<carstenh> aigarius: thanks for the information so far, i will have a look at it if i have time this weekend :)
<hughsie> okay, lol, thanks. how long till x being fixed? hours or days?
<ogra> hughsie, i wouldnt suggest a upgrade to breezy if you are not familiar with working around that X breakage
<Kamion> not hours
<aigarius> IIRC it has been broken for weeks and is improving very slowly
<ogra> hughsie, most likely days... daniels said something about next week...
<hughsie> ogra: okay, thanks. is apt clever, so i did sudo apt upgrade libnotify if would do all the rest? 
<hughsie> of is breezy a development snapshot
<hughsie> (shouldn't be asking q's like this in devel, sorry)
<ogra> hughsie, on breezy, yes... if you do such things in hoary, it will pull in the dependencys
<Kamion> (a) the command is apt-get not apt (b) you use 'install' to upgrade single packages, not 'upgrade'
<hughsie> Kamion, thanks. I want to make sure g-p-m works in breezy with a manual dbus and hal install
<carstenh> pitti: will you be here later to talk with jeff an me about wheter our files shuold be marked as conffiles and about the script that will change the configfile?
<pitti> carstenh: I should still be here for ~ 2 hours
<ogra> hughsie, hal is already updated :)
<hughsie> 0.5.3?
<ogra> hughsie, pitti is fast ;)
<hughsie> pitti sounds like a legend
<hughsie> :-)
<hughsie> dbus?
<ogra> nope :/
<carstenh> pitti: ok, thanks. i hope jeff will be here in the next 2 hours and have some time :)
<ogra> hughsie, thats the one that will take time i guess...
<seb128> tseng: new gtk is apt-gettable if you want to give it a try
<hughsie> ogra: i'll have a go at --prefix'ing it locally
<ogra> oki
<hughsie> thanks for the pointers, i'll five it a go now.
<ogra> yay... so we made you a ubuntite :)
<hughsie> ogra: only on my 2nd pc, laptop if firmly fc4 i'm afraid :-(
<tseng> seb128: got it
<hughsie> i figured i might as well take the plunge
<tseng> seb128: crash
<ogra> hughsie, ah well.... we all started with only one ubuntu install.... they tend to grow through your network... ITS A VIRUS watch out !! ;)
<hughsie> ogra: what can breezy do for a AGP card that gets so hot it's untouchable. I would be inpressed if it would work on X with that.
<ogra> *grin*
<hughsie> ogra: great. just as i though linux didn;t need antivirus
<ogra> it should work... if not, kick daniels to fix it :)
<hughsie> ogra: cool :-)
<ogra> there is no distro that ships a newer X then breezy... daniels is working also upstream....
<seb128> tseng: crash what/when?
<hughsie> i was listening in on your firefox discussion yesterday. whats ubuntus policy on backporting? fc seems to be "upgrade to latest" as it's simplest
<seb128> tseng: update cairo/pango/gtk and restart your app ... if that still crash backtrace is welcome
<tseng> seb128: firefox
<tseng> seb128: i restarted all of X
<tseng> after updating
<tseng> ill get a backtrace later with cairo debug
<seb128> do you have the backtrace and the assertion of what you get on the crash?
<seb128> k
<tseng> the assertion is the same
<tseng> firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.
<tseng> Aborted
<ogra> hughsie, yes, we do this too now, we just changed the policy, since the upstream patches for FF are not easy backportable...
<hughsie> ff tend to update other stuff in a release i've noticed
<tseng> consider that to be a rare exception
<tseng> not a precedent to changing the rules
<ogra> hughsie, before we had a policy to just backport security related stuff to avoid new bugs through new features... 
<hughsie> gotcha, thanks.
<seb128> tseng: k, let me know if you get a backtrace
<tseng> seb128: ok.
<hughsie> so you guys are going to want me to branch CVS ideally when I release 0.2.0 g-p-m?
<hughsie> at the moment i tent to just have one release (CVS!)
<ogra> hughsie, when wil that be ? 
<ogra> 0.2.0 i mean
<seb128> tseng: does anything out of firefox crash?
<hughsie> few weeks at this rate
<tseng> seb128: not yet
<seb128> k, so maybe a firefox issue
<tseng> seb128: im using alot of other stuff
<pitti> hughsie: daniels wanted to update dbus on monday
<ogra> its unlikely we wont change g-p-m after my next package... since the freeze dates are near...
<ogra> s/we wont/we will
<hughsie> ogra: thats cool with me.
<hughsie> i can stick to 1.1
<ogra> so you dont need to branch
<hughsie> you'll package cvs tho?
<ogra> i think so... except you want to roll out a tarball release during the next days while we wait for dbus
<ogra> then i'd take the tarball
<hughsie> ogra: okay, give me a few hours to finish the part-glib-ification in cvs, and i'll do 0.1.2 for you
<ogra> yay
<ogra> seb128, do you have a bug about missing transparency for png's in firefox already ?
<ogra> seb128, ah, nm, its not ff, its the screenshooter that produces them like that already
<seb128> ogra: I don't maintain firefox
<seb128> I don't have bugs about firefox
<ogra> seb128, isnt the maintainer the last one who touched it ? ;)
<Treenaks> ogra: so now IE7beta supports transparent PNGs, but firefox doesn't anymore? :P
<\sh> lol
<ogra> seb128, but the prob isnt ff as i said... my gnome-screenshooter seems to produce them without transparency
<seb128> k
<ogra> i.e. a big black border
<\sh> ogra: use gimp
<ogra> \sh, mm, wil that fix the bug... ?
<ogra> let me first check how outdated my libpng is ;)
<daniels> iz gtk boog
<pitti> elmo: please sync pmount from Debian incoming
<\sh> ogra: no..but will help u until the bug is fixed ,-)
<ogra> \sh, i can live with black borders for now :) its not this important
<ogra> i just wanted to know if its a known bug already....
<daniels> Kamion: can we please move xterm to universe?  i can't be arsed maintaining it.
<seb128> ogra: how outdated your gnome-utils is?
<\sh> daniels: no ways...xterm belongs to X like steven jobs belongs to apple
<\sh> steve even
<daniels> \sh: so find someone to maintain it ... ?
<daniels> \sh: i don't use it myself and we already have a terminal emulator in main
<ogra> seb128, a bit :) 2.11.1-0ubuntu1 
<seb128> ogra: that's probably it
<ogra> yep
<\sh> daniels: what must be done for xterm?
<seb128> try with current one
<ogra> i was suspecting that
<ogra> seb128, i'll do, thanks
<daniels> \sh: someone to keep on top of the bugs, to deal with new usptream versions, and to deal with ishikawa mutsumi in debian and get the debian and ubuntu packages synchronised.
<daniels> \sh: although ishikawa might be handing over to branden robinson, so you may have to deal with it.
<\sh> daniels: hmmm...
<daniels> s/it/him/
<daniels> which other people are far better-qualified to do than me.
<\sh> daniels: it sounds like a nice job *sigh* is it ok for u when I'm doing it after breezy release? cause right now I want to get finished with the universe work and some kde stuff
<Kamion> daniels: :P
<daniels> \sh: sure.
<daniels> Kamion: um, this isn't an xlibs-dev situation.  this is a serious question.
<daniels> Kamion: (and gravity really wants to kill xlibs-dev ...)
<Kamion> daniels: we clearly shouldn't move it to universe; it is widely used
<Kamion> and definitely in the "traditional" category
<daniels> Kamion: even in the presence of g-t and stuff like rxvt?
<\sh> daniels: ok..setteled...I will do it after breezy release in october
<daniels> Kamion: dude, xedit is traditional :P
<Kamion> yes, rxvt is quirky
<Kamion> not nearly so widely used as xterm
<daniels> i haven't even packaged that, and don't intend to.
<daniels> Kamion: not used at all AFAICT.  given that it doesn't work with UTF-8 at all.
<Kamion> and g-t is slow and bulky and really not what some people want
<\sh> daniels: xterm works everywhere (normally) and UTF-8 is sometimes not wanted ,-)
<daniels> to be fair, g-t is actually a lot faster these days.
<daniels> \sh: uhm, if a text editor refuses to even start if your locale is UTF-8, it's complete crap.
<ogra> daniels, youre vouching for moving xedit to main ?
<crimsun> (xterm, I think)
<ogra> crimsun, i know ;)
<\sh> daniels: vi is starting in xterm nicely
<\sh> daniels: anyways...give me a pointer...let me have a look on it...
<daniels> ogra: no, I'm vouching for xedit ceasing to be distributed at all.
<daniels> \sh: um, apt-get source xterm?
<ogra> heh
<ogra> doko, where is wxgtk2.6 ? i need a working audacity for edubuntu
<wasabi> My X colors are all messed up. How can I reset them?
<wasabi> vmware did it. =/
<crimsun> heh, I was just going to ping doko about that for vlc ;)
<ogra> heh
<daniels> \sh: and restore lxterm, koi8rterm, and uxterm (or whatever) from xterm 6.8.2-10, becuase I think they went missing
<daniels> wasabi: try doing a VT swtich
<doko> ogra: needs some fixing, to have both 2.4 and 2.6 installed at the same time
<wasabi> daniels: can't.
<ogra> doko, any ETA ?
<daniels> wasabi: can't?
<wasabi> My GF can't come back if I do so.
<wasabi> Once I go to console, I have to reboot. ;)
<daniels> really?  what the bloody hell sort of driver are you running?
<doko> this weekend
<wasabi> the binary one.
<ogra> yay
<wasabi> DVI out.
<wasabi> Works fine with VGA out.
<daniels> wasabi: matrox?
<ogra> doko, thanks a lot :)
<wasabi> geforce.
<daniels> wasabi: heh.  both pieces.
<\sh> DAMN why can't I SHUT MY MOUTH ,->
<daniels> AHR IT'S THE RETURN OF THE ONE-EYED EMOTICON
<wasabi> Yeah, well, it sucks. But that's the way it has been for about a year now.
<daniels> accompanied by ZIPPY the PINHEAD
<ogra> daniels, mga is totally fucked by intention ? 
<\sh> daniels: uxterm should ne in xterm source + a special lib
<daniels> ogra: nope, it's just that mga only allows DVI through their binary driver because they're a completely closed shop at the moment
<daniels> \sh: um, isn't it just a shell script?
<ogra> daniels, i have a fresh install here, that hardlocks after trying to start X
<\sh> daniels: a wrapper yes..let me have a look first...*grrr*
<ogra> daniels, the console gets a green border and doenst show anything anymore
<\sh> I think I have to marry daniels...sometimes I think it good to have him as wife ;-) he will tell me when to shut up *harhar*
<daniels> ogra: yeah, gcc4 sucks.  the next xorg upload (monday?) will be compiled against a fixed version of gcc4.  in the mean time, try grabbing libvgwha.a from a hoary system.
<daniels> \sh: at least you have two eyes now
<ogra> daniels, i'm fine to run this system in console mode for now... thanks for the info
<daniels> ogra: no worries
<\sh> daniels: I'm not a crippled guy...dodn't u know..two eyes, two arms, two legs, two..nevermind and I'm working...in germany this is really hard to get...so last chance *evilgrin*
<pitti> Hi lamont
<lamont> mornign pitti
<JaneW> hi lamont
<lamont> morning JaneW 
<seb128> Hi lamont
* lamont continues his somewhat binary search for the fatal-to-ia64 kernel config option
<lamont> hi seb128 
<lamont> and everyone else
<seb128> lamont: could you put a retry on epiphany-browser ?
<lamont> sure
<seb128> thanks
<lamont> seb128: done
<hughsie> ogra: well impressed with your updates tool
<ogra> hughsie, apt ?
<hughsie> no, i'm just updating hoary with all the updates
<hughsie> the visual update program
<ogra> ah
<hughsie> much better than fc4
<ogra> kudos for that one go to mvo :)
<hughsie> but fc4's networking tool is better
<hughsie> so it's one all :-)
<ogra> we'll have NM in breezy (hopefully)
<hughsie> ogra: thats cool. where's your services tool?
<tseng> system - admin - services
<ogra> gnome will have the g-s-t tool upstream... we'll use it
<tseng> we have it
<ogra> tseng, not in hoary
<tseng> buh
<tseng> who uses that :P
<hughsie> tseng :-)
<doko> seb128: evolution doesn't work anymore reading from an IMAP server ... started after the latest upload
<hughsie> i'll update soon, but i want x!
<ogra> tseng, people that use X
<hughsie> heh
* tseng users X
<daniels> um, X works fine in breezy
* ogra too, but -34
<daniels> latest X works fine in breezy
<daniels> i'm even running it now
<\sh> yes...I have a german keyboard again :)
<ogra> daniels, haha
<tseng> i think we need mkfontdir
<tseng> yet
<seb128> doko: what does it say?
<daniels> tseng: yeah, mkfontdir is needed, and I have its required library in NEW now
<baggins> hi danies
<baggins> +l
<daniels> tseng: but it won't matter on upgrades from hoary
<daniels> baggins: yo
<baggins> how's it going?
<tseng> daniels: huh, my upgrade from hoary the other day broke pretty bad
<tseng> cant find fixed font
<tseng> and yes i fixed the paths
<daniels> tseng: oh well
<ogra> <daniels> tseng: yeah, mkfontdir is needed, and I have its required library in NEW now
<daniels> baggins: not too badly
<tseng> yes
<ogra> ;)
<doko> seb128: Loading ...
<seb128> doko: with the update from this afternoon?
<doko> ye
<\sh> daniels: u want to have a new xterm-203 in breezy?
<daniels> \sh: sure, if it works
<\sh> lets see :)
<daniels> \sh: it needs --sysconfdir=/etc in debian/rules
<daniels> apparently it doesn't load its app-defaults right now
<\sh> daniels: it has..
<daniels> \sh: hm, ok
<mvo> I need a good name for the NetwidePackageUpdate program. it's called auto-pkg-update-{server,client} right now and that name sucks :/
<bddebian> Heya
<mdz> Lathiat: yes?
<mdz> pitti: yes, I acked the new hal
<pitti> mdz: Good morning! Thanks, ogra and seb128 confirmed, so I already uploaded it :-) It works just fine and fixes a couple of bugs
<\sh> mvo: apucs 
<mvo> \sh: nice and short, but a bit cryptic. what does it mean?
<mdz> pitti: great
<ogra> mdz, first edubuntu testinstall up and running here.... no X though...
<hughsie> ogra: in sources.list, deb http://archive.ubuntu.com/ubuntu/ breezy main restraicted universe
<ogra> hughsie, looks ok
<mdz> ogra: aren't all of the edubuntu apps X apps?
<hughsie> ogra: then sudo apt-get install libnotify doesn't work
<ogra> mdz, not the server part
<ogra> hughsie, sudo apt-get update
<\sh> auto-pkg-update-client'n'server 
<ogra> hughsie, before the install command
<seb128> hi mdz
<hughsie> ogra: i have to update the whole lot?
<carstenh> is it possible to limit the output of packages.ubuntu.org to show only packages in main?
<ogra> hughsie, the package list
<ogra> hughsie, apt-get update only updates the info about available packages
<hughsie> ohh, sorry, yes i did this
<\sh> mvo: it's an abbrev. of your package name...:)
<\sh> mvo: in alphabetic order :)
* lamont notes that http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/breezy-autotest.all.* have many failures in main
<lamont> (if it's marked 'Building', and it's in main, it's almost certainly a failure)
<ogra> hughsie, and s/restraicted/restricted i hope
<hughsie> yes, sorry, transcribing all this from an vnc window
<carstenh> and if not, has anybody a idea to get a list of packages in main that provide a file in /etc/init.d/?
<hughsie> i can do sudo apt-get update libnotify
<ogra> hughsie, just to be sure :)
<hughsie> but that want to download 200mb of packages
<ogra> hughsie, yep... dependency management.... libnotify depends on the stuff it was built against (breezy)
<hughsie> okay, gotcha. I'll give that a go.
<hughsie> my server kicks arse.
<ogra> hughsie, look that there gets no X stuff upgraded... it could break badly
<mvo> \sh: I think apu is a good name, so it will be apu-client and apu-server
<hughsie> i get to keep both bits.
<hughsie> presumably I can just apt-get from non-x terminal in a few days?
<ogra> yep
<ogra> hughsie, daniels said something about monday... lets see
<hughsie> ogra: cool
<ogra> hughsie, for X  (not for dbus)
<daniels> x will hopefully be monday also
<ogra> daniels, also ? 
<Keybuk> daniels: you an I need a word, outside ... :)
* Keybuk hunts for the sodomotron
<\sh> mvo: yeah :) apu sounds good :) 
<ogra> daniels, does that mean you already prepared a new dbus ?
<daniels> Keybuk: not until you fix dpkg.  it's screwing us up trying to build mesa.
<Keybuk> "fix dpkg" ?
<daniels> Keybuk: actually, that might make the word outside even more interesting ...
<daniels> Keybuk: apt-get install leading to dpkg segfaults are bad, ok?
<Keybuk> bug#?
<daniels> ogra: largely, yeah
<ogra> daniels, yay....
<ogra> hughsie, ^^^
<ogra> :)
<hughsie> sweet as
<hughsie> nice one daniels
<\sh> ok..going home..and if everything works fine, daniels will have his xterm tonight
<\sh> bbl
<daniels> seb128: cairo.c, line 86.  dunno if it's in firefox or pango.
<hughsie> anyone want to buy a server?
<Keybuk> so, who wants to help me debug dpkg? :p
<daniels> iwj volunteers
<Keybuk> s/iwj/Diziet/, non? :p
<seb128> daniels: what cairo.c ?
<daniels> seb128: dunno.  that's the fun part. :)
<seb128> daniels: where/how did you get that?
<seb128> daniels: cairo.c is a cairo source file
<daniels> 13:03 < thaytan> firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS &&
<daniels>                  status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.
<daniels> i don't have copies of any source trees with me, so I can't check it out at the moment.  but you sure it's not in pango or anything?
<lamont> Keybuk: what did you do to dpkg?
<daniels> although _cairo_error does look a little sus
<Keybuk> lamont: nothing
<Keybuk> quite literally
<daniels> lamont: broke it on hppa, and only hppa
<Keybuk> I'm wondering whether the zlib security upload broke it
<lamont> hrm... gonna need a really really really big trebuchet to reach .au
<lamont> what's the failure mechanism?
<Keybuk> infinity: *poke*
<lamont> Kamion: ping
<Keybuk> sweet, metacity segfaulted again
<lamont> Kamion: nm
<Keybuk> I didn't need a window manager anyway
<daniels> gtk bug
<infinity> Keybuk : You're not going to like it.
<hughsie> ogra: ubuntu supports rpm?
<ogra> hughsie, through alien, yes... but i'd prefer a .deb from the package if i were you 
<ogra> s/a .deb/a real .deb/
<hughsie> ogra: okay, just seemed like the coke c.e.o saying "is pepsi okay?"
<ogra> heh
<mjg59> So I have a couple of packages that could do with uploading for Breezy
<mjg59> But I don't have upload rights
<mjg59> What's the best approach?
<ogra> alien is a great tool if you cant find any .deb.... but with more then 16000 packages in the archive its seldom that you dont find what youre looking for
<mjg59> (Other than to bully James into adding me to the keyring...)
<daniels> mjg59: step one: buy me beer
<daniels> mjg59: step two: profit
<ogra> mjg59, main ? universe ? for universe, just thriw them at anybody in #ubuntu-motu
<ogra> throw even
<mjg59> Probably universe for now, but targetted at main
<mjg59> seb128: Did you get the bug I filed for hotkey support?
<seb128> yep, I'm busy with cairo/gtk update today though
<hughsie> ogra: bah, real men don'e need X.
<mjg59> seb128: No problem
<ogra> hughsie, true... except when they have to build a distro alone that has two critical places that depend on X ;)
<ogra> (talking about edubuntu)
<hughsie> ogra: pahh, all i need is a curses xchat replacement !
<ogra> hughsie, i doubt i'd make the teachers happy with that ... especially a ltsp install without X is funny :)
<ogra> mdz, ltsp breaks in xlibs installation currently... 
<mdz> ogra: did you file a bug?
<ogra> mdz, nope, because next X is due for monday anyway...
<ogra> mdz, it worked on monday though...
<daniels> how does it break?
<ogra> daniels, non informative with "Errors were encountered while processing: ... " no error above that...
<ogra> i'll investigate a bit more in about 30min...
<daniels> ogra: should work in -43, but -44 will definitely fix
<ogra> it might also be the us mirror... the ltsp script defaults to that... i'll try my next ltsp install with archive.ubuntu.com
<mdz> ogra: there was surely an error above that
<ogra> wait a sec... its in the other room
<daniels> mdz: no, not necessarily
<daniels> mdz: there was a problem (which was only in -42, IIRC), where the last line of xlibs.preinst was test -d foo && bar
<ogra> nope, no other error...
<daniels> mdz: test -d foo fails, and the last exit status is 1
<mdz> daniels: in which case dpkg would have printed a message saying that the exit status was nonzero
<mdz> ogra: please mail me an unabridged copy of the log
<ogra> mdz, ok
<\sh> re
<bddebian> wb \sh
<\sh> daniels: xterm-203 works for me on i386
<mdz> ogra: I don't see it yet
<ogra> mdz, i just reran the install wait a sec
<daniels> \sh: cool
<\sh> u need it now? or in 2h..so I can go and take a nap first ,-)
<daniels> \sh: um, whenever.  i'm not desperate for it.  might be worth emailing ishikawa@debian.org to see what he thinks first.
<ogra> now, could someone tell my why "2&>1 > ltsp.log" swallows the error ?
<bddebian>  2>&1
<ogra> thats what i meant... sorry typo here
<bddebian>  :-)
<\sh> daniels: debian is using the bundeled xterm...hmmm
<daniels> \sh: yeah, but ishikawa -- who did all the work on xfree86 4.2 -- did xterm packages for when it gets split out
<daniels> and it's in our interest to not deviate from debian if we can avoid it
<daniels> so if you chat to him and see if you can get the packages as close together as possible ...
<\sh> k..will email him :)
<\sh> k..mailed him...
<daniels> cool
<ogra> mdz, dpkg: error processing /var/cache/apt/archives/xlibs_6.8.2-43_all.deb (--unpack):
<ogra>  subprocess pre-installation script returned error exit status 1
<ogra> it occurs way earlier in the process and was hidden
<daniels> right, that's probably one of the ones I fixed for -44
<daniels> which will land on Monday
* Kamion re-mirrors his oem-config archive and idly curses baz
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<ogra> daniels, rmdir: `/etc/X11/xkb/geometry/digital_vndr': Directory not empty
<ogra>  seems to be the original reason for the error
<Amaranth> *groan*
<Amaranth> it's something that's supposed to fail on breezy but not make the script exit
<Amaranth> because it needs to be done for a clean upgrade from hoary
<Amaranth> or something like that
<daniels> yeah, I fixed the bug that tanked that
<ogra> oki
* \sh will sleep now at least for two hours
<bddebian> Nighty night :-)
<\sh> laters
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Kamion> mdz: I've just uploaded oem-config. Can I seed it for main? Do I need pitti to look over it for security first?
<HiddenWolf> kamion, any other devel, is that ubuntu-lite project official, will it ever be?
<ogra> HiddenWolf, vedran is working out the seeds... i'm not sure if a iso image is planned, but you will find a ubuntu-lite metapackage
<Kamion> http://udu.wiki.ubuntu.com/LightweightDesktop
<HiddenWolf> good. My roommate just came running up to me with an ancient win2k laptop bsod-ing on boot. 
<HiddenWolf> And I'd like to stick er on ubuntu.
<ogra> HiddenWolf, i'm talking about breezy
<ogra> so you probably should take hoary with a server install and install the desktop manually
<HiddenWolf> ogra, I've given her a windows cd for now, but just figuring out the options.
<ogra> ah
<HiddenWolf> I'm not going to fiddle with a 300mhz/64meg laptop on a saturday night. ;)
<HiddenWolf> nor a friday.
<ogra> heh
<HiddenWolf> would hoary/xfce do for now?
<ogra> sure
<HiddenWolf> ogra, once again, you rock.
<ogra> thanks :)
<vedran> HiddenWolf: try the iso here www.ubuntulite.org it uses a different installer that wipes out your hard drive ;) but otherwise is pretty much the future lightweight desktop seed
<HiddenWolf> vedran: how usable is it, atm?
<vedran> v1.0 works but you have to login as root and configure x.org manually
<HiddenWolf> ah.
<vedran> v1.1 will fix that and other issues
<HiddenWolf> what's the desktop used?
<vedran> icewm
<HiddenWolf> I need something that won't scare away a teenager.
<HiddenWolf> any screenshots anywhere?
<vedran> umm no
<vedran> http://www.linuxcdmall.com/ubuntulite-screenshots.html
<HiddenWolf> lol
<HiddenWolf> that's a ripped off winxp install. :P
<mdz> Kamion: OK to seed
<vedran> HiddenWolf: heh it's just an icewm theme but official ubuntulite will not use that ofcourse
<HiddenWolf> vedran: the site says it's not an official project. Is it not a project yet, or will it never be?
<vedran> long story short - the guy started it independently and we are now trying to merge
<HiddenWolf> Good.
<Kamion> mdz: done
<HiddenWolf> I'm not going to go anywhere else, not for a crappy laptop owned by the dumbest of girls I've ever known. :P
<shackan> vedran, does it have anything good for merging ?
<Amaranth> does icewm support all the fd.o specs?
<HiddenWolf> shackan: if nothing else, a config that runs on "anything"
<vedran> shackan: well mostly package list, some config hacks and the installer has the same goals as oem-installer
<shackan> uhm, the installer seems still the old stile textmode stuf
<shackan> *stuff
<doko> seb128: imap doesn't work with evolution 2.3.6.1 as well
<shackan> are we getting a graphical installer some day ?
<seb128> doko: you already said so
<HiddenWolf> shackan: count on it, if ubuntu is planning to distribute with HP. ;)
<doko> seb128: no, that was 2.3.6
<seb128> doko: ah
<shackan> uh, didn't know that
<seb128> doko: it does nothing?
<vedran> shackan: why graphical? it isn't even interactive :P
<seb128> doko: try to evolution --force-shutdown && evolution
<vedran> guess that beats microsoft for usability...
<shackan> lol
<doko> seb128: same behaviour
<Kamion> shackan: see http://udu.wiki.ubuntu.com/GraphicalInstaller, http://udu.wiki.ubuntu.com/UbuntuExpress
<seb128> doko: it hangs?
<doko> seb128: Clicking on the Tab in the left pane, it says "Loading ..." (the mailbox), then nothing happens. I'm able to click on other things, so the application itself doesn't hang
<seb128> doko: that's using IMAP or IMAP4v1?
<doko> imap4
<doko> seb128: wait, the preferences overview says imap4, but the dialog imap4v1
<ogra> Amaranth, icewm has a own menu system :/
<jasoncohen> ogra, hey, i asked yesterday if mozilla-mplayer 2.85 would get into breeezy. 2.85 has been in sid for over a month and it works here. The releases since 2.7 have made signifigant aesthetic changes to the UI and there have also been some features added I believe
<ogra> jasoncohen, i saw the bug already... 
<Amaranth> what UI?
<Amaranth> there's a UI?
<jasoncohen> Amaranth, yes, if you compile with --enable-gtk2
<daniels> http://thedailywtf.com/forums/39325/ShowPost.aspx
<daniels> argh
<jasoncohen> let me get the bug
<ogra> Amaranth, yes after the totem plugin mplaye now stars thattoo
<Amaranth> Can someone translate for me? :)
<Amaranth> they're doing it because totem got a plugin?
<ogra> Amaranth, totem plugin has a pause and a fullscreen button
<jasoncohen> Amaranth, basically, the debian mozilla-mplayer is compiled without gtk2 support so there are no menus or buttons
<ogra> Amaranth, i guess thats what they added to mplayer too now...
<jasoncohen> if you compile with gtk2 (the default for mozilla-mplayer), you get a more attractive interferace, buttons, and a menu which you can download the stream
<jasoncohen> Amaranth, https://launchpad.ubuntu.com/malone/bugs/1598
<jasoncohen> i've already packaged a new 2.70 deb with the trivial changes
<jasoncohen> ogra, would you be opposed to making the change?
<ogra> jasoncohen, i currently dont have the time for it... but will look into it.. i'm not sure if the current version in multiverse is marillat or sid
<jasoncohen> does marillat even have mozilla-mplayer?
<Amaranth> daniels: that is sad
<jasoncohen> i thought they used debian's version
<jasoncohen> Maintainer: Rene Engelhard <rene@debian.org>
<jasoncohen> so, i guess it's sid
<shaya> anyone having firefox crashes due to cairo?
<shaya> firefox-bin: cairo.c:86: _cairo_error: Assertion `status > CAIRO_STATUS_SUCCESS && status <= CAIRO_STATUS_FILE_NOT_FOUND' failed.
<shaya> do I have to rebuild firefox due to cairo 0.6?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<jasoncohen> i just receivedc DSA-769-1 for gaim. It fixes CAN-2005-2370 but this is not shown on http://gaim.sourceforge.net/security/. Also, CAN-2005-1934 AND CAN-2005-1269 remain unfixed. anyone know where this CAN came from or if it affects hoary?
<Kamion> mdz: I'm thinking that OEMRescue wants to be deferred for breezy
<mdz> Kamion: given that it's always said that it wants OEMInstaller in place first, and OEMInstaller is getting down to the wire, yeah, I agree
<Kamion> mdz: OEMInstaller is in plausible shape now (the main problems are ropey UI, not major lacks of functionality), but OEMRescue is going to take a fair bit more development
<Treenaks> jasoncohen: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2370
<Kamion> so yeah, I'd like to do it right for breezy+1 rather than do a rushed half-arsed job and neglect other higher-priority things
<jasoncohen> thanks Treenaks 
<jasoncohen> heh, i don't get the debian security team. they fix a big in gadu which affects a miniscule number of people but leave firefox unpatched for weeks
<Kamion> mdz: sorry the dependent task took so long
<mdz> Kamion: no problem; rescue was always lower priority
<Kamion> rescue's pretty heavily debated as well, judging from its comments section ...
<mjg59> What C library do we use in the initrd? Any?
<HiddenWolf> jasoncohen: did they ever make sense? perhaps that gadu bug was just easier.
<jbailey> mjg59: glibc and klibc right now.
<mjg59> jbailey: Both? Eww.
<jbailey> mjg59: Likely to stay with glibc for breezy.
<mjg59> Ah, fine.
<mjg59> So usplash doesn't have to be statically linked?
<jbailey> mjg59: I had hoped to do klibc.  It has certain deficiancies.  I got a chance to talk to HPA about them at OLS, and they won't be solved in the timeframe we need.
<jbailey> mjg59: Right.
<jasoncohen> HiddenWolf, they're probably trying to figure out a way to backport the security fixes from 1.0.5 without breaking firefox which neither Ubuntu or Red Hat could do
<mjg59> jbailey: We still need to work out some way to keep the fifo available to it
<HiddenWolf> jasoncohen: well, good for them. ;)
<jasoncohen> Debian would never just package the upstream version. Rather than package a new mozilla in woody, they left mozilla 1.0.0 unpatched for over a year
<HiddenWolf> imho they're just destroying their legitimacy as a rock-solid safe system.
<jbailey> mjg59: We've been talking about move_mount'ing /dev to the new root partition.  If you drop it in there, would it be good enough?
<mjg59> jbailey: Sure, that would do
<mjg59> jbailey: Any preferences about the name?
<jbailey> 'kay.  I'll backport the patch from Debian's udev o cope with that, then.
<Treenaks> HiddenWolf: Yes, but don't forget that the mozilla guys are being dicks too
<mjg59> jbailey: Ah - that's a point. How early will /dev appear, and will it be writable?
<jbailey> mjg59: As long as it's low-conflict, I don't care....  usplash-fifo ? =)
<Keybuk> mdz: #ubuntu-meeting
<HiddenWolf> Treenaks: I'm not familiar with the details, but I got a distinct impression to that extent, yes.
<mjg59> jbailey: If /dev is dynamic, we'll need to create the fifo on boot
<mjg59> So we can't really start usplash until it's appeared
<jbailey> I can mount it right before init-top is run, I guess, to make sure it's available for you.
<mjg59> jbailey: Ok, that would work
<jbailey> mjg59: Are you a C application?  Can you just call mkfifo yourself, or do you need /bin/mkfifo ?
<jbailey> mkfifo(3) rather I mean
<mjg59> jbailey: C, so that's not a problem
<jbailey> Hmm, klibc provides mkfifo  anyway, so it's no big deal either way.
<jbailey> I mean klibc-utils provides /bin/mkfifo
<mjg59> jbailey: Ok. So basically all I need at the moment is the /dev and for vga16fb to be loaded. What's the right way to hook in to start usplash?
<Keybuk> mjg59: #ubuntu-meeting :)
<jbailey> To get vga16b loaded, the best thing is to drop a file called "usplash" that contains the word "vga16b" into /usr/share/initramfs-tools/modules.d
<jbailey> To start it, drop the shell script that does what you need into /usr/share/initramfs-tools/scripts/init-top
<jbailey> It needs to optionally accept one argument
<jbailey> mjg59: Mind if I /msg you with a flood?
<mjg59> jbailey: Cool. Go ahead
<sabdfl> mdz: #ubuntu-meeting for mjg59?
<Keybuk> quickly!  before our net connection drops again! :p
<sabdfl> *cough* *splutter* did i just see usplash?
<Kamion> jasoncohen: dude, we didn't package the upstream version until a couple of days ago either. :-)
<Kamion> previous performance no indicator of future performance, etc.
<jasoncohen> Kamion, yes, i know
<jbailey> mjg59: That emulates a dependancy-based init setup
<mjg59> sabdfl: Yeah, package ought to be ready soon
<jasoncohen> Kamion, but ubuntu learned the error of their ways. It's simply too much of a burden to backport security fixes for mozilla/firefox on multiple distros. why do you think warty was never patched? pitti said he spent 40 hours backporting fixes
<jbailey> mjg59: At the moment it's a hard dependancy.  It will soon be a soft dependancy so that if the thing you depend on doesn't exist, it won't worry about it.
<jasoncohen> that's why debian gave up on woody
<mjg59> jbailey: Ok. In this case, do I need to check for anything?
<mjg59> Modules will be loaded before I run?
<jbailey> mjg59: Nope.  The snippet that I pasted you will basically just do what you need.
<jbailey> oo, good question.
<sabdfl> mjg59: that's awesome news. how does it look?
<jbailey> This might be before module load. =)
<ogra> mjg59, congrats for main uploader status :)
<sabdfl> ogra: fastest confirmation *ever*
<jbailey> Whups, that's before the modules are loaded.
<ogra> sabdfl, yep, i followed it... *g*
<jbailey> mjg59: Will you need anything more in /dev than /dev/console?
<mjg59> sabdfl: At the moment? Ugly :)
<sabdfl> holler if you have specs for the artwork team
<mjg59> jbailey: /dev/fb0 - is udev running at that point? If not, then it'll need to be created
<mjg59> sabdfl: I've passed stuff on to Jane
<sabdfl> ok cool, can't wait to see it
<jbailey> mjg59: It's not.  udevstart isn't called until all the modules are loaded.
<sabdfl> of course, we're all a little scared of breezy over here in chickenpox land, since daniels b0rked keybuk's X :-)
<jbailey> mjg59: I'm' trying to figure out where to add the hook for you.
<mjg59> jbailey: Ok. In that case can you make sure that it exists?
<mjg59> Thanks!
<jbailey> mjg59: Do you want this running before the root file system is mounted?
<mjg59> jbailey: Ideally
<ogra> whee, http://lists.ubuntu.com/archives/ubuntu-users/2005-July/044259.html
<jbailey> Okay.  I have specific premount hooks for when booting off of a local harddrive and when booting off of nfs.   I just need to make a generic one.
<\sh> *yawn* g'evening 
<mjg59> jbailey: Oh, hrm. I could do with the "open" command.
<mjg59> Is that practical?
<jbailey> that's another 115k.  A lighter solution would be nicer if possible.
<mjg59> Arh.
<jbailey> Otherwise, there's no hard limit on i386 for the initramfs.
<mjg59> I can probably implement the VT ioctl stuff myself, I guess.
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<jbailey> mjg59: Depends how much grief it is.  Compared to a stack of kernel modules, it's not big deal, but if it's a trivial convenience it's a bit heavy.
<\sh> hmmm..
<mjg59> jbailey: Nah, I can probably do it myself. No idea why "open" is that big, though.
<jbailey> It's the two console-tools libraries that it depends on.
<jbailey> open itself is 14k
<mjg59> Ah, ok
<mjg59> Building it statically would probably be smaller, but still...
* mjg59 digs through the console-tools source
<jbailey> mjg59: To confirm, I'll give you a generic mount hook.  The means that you'll be able to hop in after all the modules are loaded, and so after /dev is populated with base system devices (So, no lvm, md, or evms).  After that happens, md, lvm, evms, any cryptroot stuff, nfsroot's fetching of an ip address, nfsmount, local mount, etc. happens.
<\sh> infinito: ping
<infinito> \sh: hi!
<\sh> infinito: I just had a quick look on gcfilms
<mjg59> jbailey: Ok. So at that point, /dev/fb0 exists. I create a /dev/usplash_fifo, change to a new VT, splash stuff on the screen
<jbailey> Yup
<\sh> infinito: and I don't think it's ready to be synced from debian to ubuntu
<mjg59> jbailey: After that, things call usplash_write to write stuff to usplash
<infinito> \sh: why?
<mjg59> When we mount the real root, the same fifo exists in the same place. 
<\sh> infinito: it starts out with missing dpatch build-deps
<jbailey> mjg59: 'kay.  Does usplash_write fall back to displaying on the console if usplash isn't running?
<mjg59> jbailey: So we don't do any chrooting in this model?
<mjg59> jbailey: No, but the model I've assumed is that usplash_write is called in addition to echo
<infinito> \sh: i know... buff... our version is patched, but the debian dev seems to be missing
<\sh> infinito: and if I have to change it, then it will get an ubuntu package version stamp and it's not be synced automatically anymore
<jbailey> mjg59: 'kay.  Does usplash_write fail silently if there's no usplash to write to?
<\sh> infinito: so it has to go to our MOTU Review Process
<mjg59> jbailey: Yup, without blocking
<\sh> infinito: and for that, please join #ubuntu-motu to discuss this
<infinito> \sh: ok
<jbailey> mjg59: With an error code?  I think I do set -e usually now, so I'd hate to suddenly have the system die because someone didn't have usplash running.
<mjg59> jbailey: No, with 0 in that case
<jbailey> Cool
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<jbailey> mjg59: What chroot stuff are you thinking of?
<mjg59> It'll error if something goes bizarro-wrong
<mjg59> jbailey: The usplash process started from initramfs ought to be running until gdm starts. Is it going to have the same filesystem namespace once / is mounted?
<mjg59> Hmm. This may be fun :)
<jbailey> mjg59: We'll have to test it.  I don't know what a move mount looks like to a process that's already running.
<jbailey> So far nothing had been persistant. =)
<mjg59> jbailey: It reopens the fifo after every command is written (because it gets closed after the writer disconnects)
<mjg59> So, uh. I have no real idea what'll happen.
<jbailey> Excellent!
<mjg59> Possibly it should communicate over unix domain sockets instead, or something.
<jbailey> Umm, given that you'll have the same /dev in the new place, I suspect it'll be fine.
<jbailey> Like I see it as two possibilities.
<mjg59> But is it the same place as far as an already running process is concerned?
<jbailey> Either move mounts don't affect currently running processes, in which case you'll have the same /dev you always did.
<mjg59> We could do with Al Viro, really...
<jbailey> Or it'll get move and you see the new filesystem layout, in which case we just need to make sure that nothing writes to the fifo between moving dev and moving /
<mjg59> Well, let's go with it as is for the moment and see what breaks
<mjg59> jbailey: Ok, looks like I need /dev/tty%d as well. Is that a problem?
<jbailey> tty's and pty's are there.
<mjg59> jbailey: Ok, sorted.
<mjg59> 6 lines of extra code
<jbailey> Lovely. =)
<mdz> ogra: have you tested ltsp with the new unionfs in -6?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<ogra> mdz, -6 ? 
<mdz> ogra: kernel -6
<ogra> ogra@edubuntu:~$ dpkg -l|grep linux-image
<ogra> ii  linux-image-2.6.12-4-386          2.6.12-4.4 
<ogra> installed this afternoon from yesterdays daily
* ogra upgrades the edubuntu machine
<Kamion> -6 is still in NEW
<ogra> ahh, thats the prob
<ogra> :)
<Amaranth> o_O
<mdz> ogra,Kamion: processing it now
<Kamion> mdz: apt seems to need to build-depend on xmlto now
<mdz> Kamion: that stuff is only necessary for building the source package
<Kamion> mdz: at least, that's what's missing when building mvo's progress-reporting branch
<mdz> the source package ships with pregenerated docs
<Kamion> oh, ok
<mdz> it's sort of a pre-build-dep
<mdz> I think it's documented somewhere-or-other
<\sh> Mithrandir: maswan: can u please update on ravel breezy chroot with: xmms-dev (>= 1.2.10+cvs20050209) libsqlite3-dev libpcre3-dev (>=4.3) libtag1-dev libvorbis-dev (>=1.0) fftw3-dev libglib2.0-dev dpatch automake zlib1g-dev libx11-dev libxss-dev
<Kamion> we're going to have to think about standardising machine-readable representations of that if we're pushing buildability from arch
<Kamion> apart from anything else grumpy will have some difficulty otherwis
<Kamion> e
<mvo> Kamion: it's only needed when doing arch-builds IIRC
* mvo just notes that mdz already said that :)
<mdz> mvo: I want to put out 0.6.40 this weekend
<mdz> mvo: since I forgot to update my chroot and so didn't do the C++ transition on i386
<maswan> \sh: done?
<mvo> mdz: apt--fixes--0 may be interessting 
<\sh> maswan: nope :)
<mdz> mvo: what's there, besides the file auth stuff?
<\sh> maswan: and fakeroot is missing as well :(
<maswan> \sh: what's missing?
<mdz> mvo: and does it change the abi? ;-)
<\sh> maswan: xmms-dev (>= 1.2.10+cvs20050209) libsqlite3-dev libpcre3-dev (>=4.3) libtag1-dev libvorbis-dev (>=1.0) fftw3-dev libglib2.0-dev dpatch automake zlib1g-dev libx11-dev libxss-dev
<maswan> \sh: the breezy chroot on ravel?
<\sh> maswan: yes
<\sh> argl...forget it
<maswan> fakeroot is already the newest version.
* \sh doesn't look 
<mvo> mdz: I hope not :p
<\sh> dchroot missing in \sh fingers
<mvo> mdz: very small fixes, should all be very harmless
<mvo> mdz: what do you thing about adding hashes to the copy method? it seems to be overhead for little gain
<mvo> gowins copy example didn't convince me 
<Kamion> mdz: do you happen to have a complete list of the pre-build-deps? I can't find it
<mvo> Kamion: perlsgml, xmlto, sgml2x, sgmlspl IIRC
<mjg59> jbailey: Can you give me a directory that I need to put my init script in, and a minimum version number for the right hook to be present?
<shaya> anyone having problems w/ firefox?
<mdz> Kamion: it's documented in COMPILING, but it's out of date (only lists the sgml tools, not the XML ones)
<Kamion> ok, I was missing perlsgml and sgml2x, thanks
<mdz> mvo: if you could update that in your fixes branch, that'd be great
<mvo> mdz: I will do that now (will be patch-15)
<mdz> mvo: I'm not particularly interested in goswin's argument :-P
* mvo gigles
<Kamion> apt-get.ja.8.sgml fails to build even with those pre-build-deps
<Keybuk> but Goswin makes such convincing, eloquent and well-considered arguments
<Kamion> nsgmls:/home/cjwatson/apt/progress-reporting/doc/ja/apt-get.ja.8.sgml:3:59:W: cannot generate system identifier for public text "-//OASIS//DTD DocBook V3.1//EN"
<Kamion> and a slew more
<mvo> Kamion: debiandoc-sgml
<mvo> ?
<Kamion> got that
<HiddenWolf> OMG, guys, I'm booting from an old hoaryRC on an old laptop, installing from cdrom, and it's telling me it can't find the cdrom drivers :D
<mvo> Kamion: libsgml-perl?
<Kamion> no such package
<mvo> Kamion: libsgmls-perl?
<mvo> (sorry)
<Kamion> got it already
<Kamion> ah, might be docbook
<tseng> is there a way to save a backtrace from gdb
<tseng> or ill have to paste it out?
<Keybuk> "save" ?
<Keybuk> you can dump core
<tseng> i did dump core
<Keybuk> that's effectively a saved backtrace
<Kamion> 'set logging on', 'set logging file <file>'
<tseng> Kamion: ah, cheers
<Kamion> mvo: ah, yes, 'docbook' did it
<Keybuk> ah, I see what you mean now, duh
<Keybuk> sorry ;)
<mvo> Kamion: thanks, I added that to the coming README
<tseng> seb128: ff backtrace @ tseng.ath.cx/firefox-backtrace.txt
<tseng> seb128: hm its missing "Previous frame inner to this frame (corrupt stack?)
<Kamion> mvo: that branch makes aptitude fail to build, though
<Kamion> (progress-reporting)
<Kamion> cmdline_simulate.cc:41: error: call of overloaded `DoInstall()' is ambiguous
<mvo> Kamion: hm, let me check
<Kamion> oh, it's because you have a second DoInstall() with a default first arg, which can't be distinguished from the zero-arg case
<Kamion> just dropping "=-1" from the second DoInstall() in packagemanager.h ought to do it ...
<mjg59> jbailey: Ok, I have a package - just need to know where to put the init script :)
<jbailey> mjg59: /usr/share/initramfs-tools/scripts/init-premount
<jbailey> mjg59: Do you want the patch now for testing?
<jbailey> mjg59: It'll be version 0.15
<mjg59> jbailey: I don't have stuff set up to test initramfs yet, I'm afraid
<mjg59> jbailey: If I give you a package, can you be a suck^wtester? :)
<mvo> Kamion: yes, thanks. they will later be merged, but this way the ABI does not break
<jbailey> mjg59: Sort of.  My laptop is text-only, pending the return of mkfontdir in breezy.
<jbailey> So I won't be able to test the switch to gdm for you/.
<jbailey> Hmm.
<jbailey> Unless you can do ppc
<mjg59> jbailey: That's ok, without adding stuff to the init scripts it'll just exit after 15 seconds
<mjg59> ppc isn't ready yet
<jbailey> 'k.  I can guinea pig that when you're ready too.  My other boxes are all headless.
<Kamion> mvo: right
<mjg59> Needs someone to write support for scrolling stuff in bogl
<Kamion> mvo: aptitude builds after I tweak apt as above
<mjg59> jbailey: www.srcf.ucam.org/~mjg59/tmp/usplash_0.1-1_i386.deb
* jbailey wishes yet again for package signatures.
<Kamion> mvo: hmm - I think you did break the ABI, though
<Kamion> mvo: aptitude: symbol lookup error: aptitude: undefined symbol: _ZN17pkgPackageManager9DoInstallEv
<Kamion> mvo: (which c++filts to pkgPackageManager::DoInstall(), so seems related
<Kamion> )
<jbailey> mjg59: Got, lemme finish getting this glibc build started and I'll do this.
<mjg59> jbailey: Once I get connectivity next week, I'll be able to test this locally :)
<mjg59> jbailey: Cool, thanks!
<mvo> Kamion: hrm, adding non-virtual functions shouldn't break the abi ... oh well (/me checks again)
<Kamion> mvo: it sounds more like the zero-arg DoInstall() is being optimised into an inline function, or something ...
<shaya> hmm
<Kamion> mvo: it's certainly not present in the compiled libapt-pkg.so - only pkgPackageManager::DoInstall(int)
<seb128> tseng: thanks. I get the crash too, it's not on startup
<Kamion> mvo: shifting the stub DoInstall() function to the .cc file seems to work fine
<shaya> is 2.6.12-6 good?
<Kamion> mvo: do you expect this to work without source changes in aptitude? 'sudo aptitude -o APT::Status-Fd=3 install groff 3>~/foo' leaves ~/foo empty
<tseng> seb128: i know
<seb128> you didn't say so
<tseng> sorry :/
<seb128> np
<seb128> use epiphany as a workaround :p
<Kamion> mvo: boggle - it appears to work with Status-Fd=2 but not =3
<\sh> gentlemen...who is xmms pro?
<\sh> does xmms on amd64 has QUEUE_CONTROL enabled?
<tseng> seb128: good idea
<tseng> i used to use ephy all the time
<Kamion> mvo: oh, never mind, I'm being bitten by a misfeature of sudo with apt-get, but aptitude still doesn't work
<mvo> Kamion: I /msged you a small patch, could you please try that?
<mvo> (for aptitutde)
<Kamion> building now
<Kamion> mvo: that works, thanks
<Kamion> mvo: is the progress number intended to be floating-point?
<Kamion> I guess that's OK, I'll int() it for debconf
<Kamion> or s/\..*// anyway :)
<mvo> Kamion: I haven't really thought about it :)
<mvo> Kamion: does it work now?
<Kamion> mvo: yep, seems to work fine - I'm pondering the base-config side now
<Kamion> will have to make sure debconf works sanely if a package wants to ask a question while the progress bar is up
<Kamion> which will be a little tricky, since unless I'm very careful the debconf database will be locked
<Nafallo> hmm, is it just me or is those amd64 buildds down again?
<mvo> Kamion: right, that sounds tricky
<Kamion> I have a big hack held in reserve in case I can't think of a better solution (run the progress bar inside a debconf frontend that opens everything read-only)
<Kamion> but I can probably make it work with passthrough and a bit of luck
<mvo>  that sounds not too bad to me (also I have virtually no idea about debconf)
<\sh> debconf is nice :)
<\sh> and it's nasty
* Treenaks knows more things like that
* mvo has used debconf as a developer, but never hacked on debconf
<Kamion> having commit access to it upstream helps
<\sh> the debugging mode is totally crap (from a fast debug person point of view) ;)
<Kamion> hm? I find DEBCONF_DEBUG=developer incredibly useful actually
<Kamion> but then I speak the protocol ...
* Treenaks SLAYS cairo
<Treenaks> HARD
<Kamion> of course my current project includes a debconf protocol filter and has its own DEBCONF_DEBUG=filter debugging output - that's kind of fun
<Kamion> work on the installer and you become very familiar with debconf very quickly
* Nafallo guesses his right :-/
<wasabi_> So is there an architecture doc on the new LiveCD infrastructure?
<wasabi_> I think I got a grasp on most of it, but there are some changes I want to make.
<Nafallo> s/his/he\'s/
<wasabi_> Like, disable network config during the dpkg part and move it back to /etc/network/interfaces.
<\sh> Kamion: yes...it's useful...
<\sh> Kamion: but a --debug flag would be a nice2have
<\sh> hmmm...i fixed imms
<Kamion> \sh: thing is that debconf is invoked all over the place, so an environment variable is really easier to use
<Kamion> mvo: hmm, tricky, apt closes all of its fds when forking
<Kamion> or rather, sets them close-on-exec
<HiddenWolf> I've got a very ancient laptop on my hands, and I get a very verbose error starting up alsa. How can I figure out what it is? are you interested in the bug, or not?
<mvo> Kamion: yes, this anoyed me too a lot 
<Keybuk> can we pull devscripts 2.9.x from unstable?
<Kamion> maybe some configuration directive that tweaks the lower bound to mark close-on-exec?
<Kamion> a bit hackish, but ...
<mvo> I have the feeling that mdz will not like that. but some way to have more control over what fds will be closed and which will kept open would be really good
<mvo> but we would need to come up with a clean way
<mvo> (but it has my total support)
<Kamion> it's certainly a showstopper for using passthrough from inside apt
<Kamion> mdz: any thoughts?
<\sh> Kamion: yes I know...
<mdz> Kamion: could pass a bitfield saying which FDs should stay open
<mdz> a la select(2)
<Kamion> bitfields from shell?
<mdz> shell?
<Kamion> base-config is shell ...
<mdz> I only saw from this forward: Kamion mvo: hmm, tricky, apt closes all of its fds when forking
<mdz> a configuration option listing file descriptors to preserve seems doable
<mvo> mdz: yes, a way to tell apt not to close it's fds would be cool
<Kamion> oh, ok. the background is that I want to be able to use the debconf passthrough frontend while installing packages, in order to be able to have a debconf frontend displaying a progress bar while simultaneously not causing any packages that try to use debconf to fall over in a heap
<Kamion> (because the debconf database would be locked
<Kamion> )
<HiddenWolf> ogra?
<mdz> Kamion: apt configuration already has lists; I'd say a configuration item list of file descriptors would be the way to go
<mvo> mdz: something like a list "APT::Interal::KeepFDs" ?
<mdz> we could use that in place of the internal hack too
<Kamion> mdz: that would work for mee
<Kamion> er, me
<mdz> just APT::KeepFDs I'd say
<mdz> or it could stop closing file descriptors altogether
<mdz> it's not necessarily its business
<mvo> mdz: rock, I'll work on this tonight or tomorrow morning. it makes my life in synaptic easier too :) [stop closing is fine with me too] 
<mdz> I'm not sure what the original rationale was; that code is old
<mvo> there are quite a few spots where I really would like to hear from jgg what the rational was (Iterator::_dummy() comes to my mind)
<hughsie> ogra: got a minute?
<Kamion> yes, I could cope with it not closing fds; it's not on a security boundary so I don't see a good reason for that
<Kamion> hmm
<Kamion> I wonder if anything expects to be able to use hardcoded file descriptors
<Kamion> thinking of maintainer scripts that do 4<foo or whatever
<Kamion> it's sometimes hard to avoid that in shell, although you can just pick a higher number
<Kamion> should be fine as long as they don't use debconf within such loops, though, and such code is fragile anyway ...
<mdz> I like the idea of apt providing a fairly sanitized and sanity-enforced environment for dpkg to run in
<mdz> but I don't have a specific case to back it up
<HiddenWolf> daniels, ping?
<highvoltage> mdz: we talked about testing on #edubuntu today. I had a hectic time since i got back... will be playing with your ltsp package this weekend.
<mdz> highvoltage: I am desperate for testing and feedback; I don't think anyone but me and ogra have tried it
<highvoltage> mdz: i'll also be installing a copy on my laptop, so i'll take it to a tuxlab, unplug a server and see how it works from my laptop.
<highvoltage> mdz: i feel bad for not giving you feedback yet, but i'll give you lots of feedback. i just had a real tough past 3 weeks.
<mdz> highvoltage: thanks
* #ubuntu-devel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
(Kamion/#ubuntu-devel) mvo: doesn't build, I think you need ExecFork(int unused=-1) in fileutl.h rather than just (int unused)
<\sh> hmmm....
<\sh> amd64 buildd offline?
<mvo> Kamion: *cough*, fixing that now
<Nafallo> \sh: that's my conclusion. (with a silent yes from both #u-d and #u-m)
<\sh> Nafallo: amen :)
<mvo> Kamion: should work now
<MAPD> hey
<MAPD> isnt here anyone from ubuntu team is it?
<mvo> Kamion: does it build now (after a baz update)? and maybe even work :p ?
<\sh> g'night gentlemen and ladies..
<Kamion> mvo: builds, at least ...
<Mez> hmmm does anyone here have any experience creating FF themes?
<Mez> thunderbird themes*
<Kamion> mvo: seems to partly work; dpkg-preconfigure talks to passthrough, but the .config and .postinst confmodules themselves don't. hmm
<mvo> Kamion: is this releated to the KeepFDs configuration?
<Kamion> I've got -o APT::KeepFDs::=4 -o APT::KeepFDs::=5
<Kamion> tried with higher fds, same
<mvo> Kamion: it will only keep exactly this feeds
<Kamion> mvo: yeah
<Kamion> stracing, this is getting a bit mad
<Kamion> mvo: debconf itself seems to be marking those fds close-on-exec, so it's not your problem
<mvo> Kamion: ok, I'll probably be around another 1h, keep me updated :)
#ubuntu-devel 2005-08-04
<Kamion> mvo: actually, it turns out my test was faulty (I confused myself with the way the passthrough frontend works)
<Kamion> mvo: on fixing the test, it all works just fine. :-)
<mvo> Kamion: *rock* :)
<Kamion> I have a pair of FIFOs by which I'm happily driving debconf by hand
<tseng> if anyone is terribly concerned by this
<tseng> https on the udu wiki takes you to the default vhost
<tseng> which happens to be the presumably guarded launchpad wiki
<sladen> tseng: somebody needs to shuffle the order of them in the httpd.conf so that www.ubuntu.com is the top one
<tseng> sladen: exactly
<tseng> sladen: the irony of ubuntu having chronically screwed up SSL
<HiddenWolf> who is the guy developing bum?
<baggins> what is it with all the codenames? why can't debian and its derivatives just count with version numbers like any normal project?
<Kamion> tseng: the launchpad wiki's being opened up anyway
<tseng> baggins: we have version numbers.
<sladen> baggins: we do.  Ubuntu 5.10 is the next one
<baggins> thanks
<tseng> baggins: and so does debian.
<tseng> sarge was 3.1
<sladen> baggins: (which happens to be the month of release  2005-10)
<tseng> Kamion: good news
<baggins> warty? hoary? sarge? donald? roadrunner?
<baggins> :P
<baggins> ok
<HiddenWolf> warty warthog, hoary hedgehog, breezy badger, grumpy groundhog
<Kamion> (or at least, so I'm told)
<HiddenWolf> and a few more in the pipeline. :)
<baggins> blah
<baggins> :P
<baggins> are they just arbitrary?
<sladen> it is easier (and cuter) for humans to remember names.  This is why we have DNS and domainname rather than typeing out numbers (which is what the computer does anyway)
<Kamion> pretty arbitrary, yes
<HiddenWolf> sladen, and our names are just plain fun, don't forget. :D
<baggins> that's fair enough for arbitrary numbers, but sequences being replaced by arbitrary names doesn't make much sense to me.
<baggins> ah but what do i know?!
<HiddenWolf> baggins: since when do names make sense.
<HiddenWolf> The only logical reason you've got a surname is because your father had one.
<HiddenWolf> Which he has because napoleon told him to make one up.
<HiddenWolf> Every name, word, logo, expression, phrase and language is constructed, someone made it up at one piont.
* sladen thought baggins was a Hobbit rather than a Troll.
<baggins> i'm not trolling, just flamebaiting.
<baggins> or something
<HiddenWolf> sladen, shush, read the CoC :P
<sladen> baggins: :)
<baggins> names sure... we need to give some things symbols... but when you see a version number continuously being referred to by it's symbolic name, you have to go and find out from somewhere... it's not very user friendly, surely? :P
* baggins rambles to a wall
* baggins rambles through a wall
* tseng boggles at the seemingly pointless argument
<baggins> yeah
<baggins> i guess
<tseng> if you find publicity material with consistancy issues, please tell us
<HiddenWolf> Right guys. I've got something happy to share. I converted a teenage girl to linux today.
<tseng> if you are watching development here and cant keep up..
<baggins> ok sorry, i'm just rambling
<tseng> meh
<baggins> i should do it somewhere else
<HiddenWolf> I gave her a usable pc back for her birthday. :D
* HiddenWolf is proud
<HiddenWolf> </rambling>
<Nafallo> goodnight all
<bob2> it'd be awesome if my desktop stopped hardlocking while I slept
<lamont> bob2: sounds like you need to quit sleeping, eh?
<marcin> jbailey, ping
* lamont -> sleep
<pitti> Good morning
<Treenaks> morning
<Treenaks> is it a known bug that eog segfaults?
<pitti> daniels: here?
<pitti> $ setxkbmap -model pc105 de nodeadkeys
<pitti> Couldn't interpret _XKB_RULES_NAMES property
<pitti> Use defaults: rules - 'xorg' model - 'pc101' layout - 'us'
<pitti> Error loading new keyboard description
<pitti> ^ how do I cure that again?
<robitaille> Treenaks: there is nothing in bugzilla about problems with eog
<Treenaks> robitaille: ok, then I need to know how to build debug packages with pbuilder.. does it honor the environment?
* Treenaks hops
<Treenaks> hopes
<robitaille> Treenaks: no idea....never used pbuilder :)
<jasoncohen> is there a reason fsck doesn't work with sudo in ubuntu? after a failed fsck check on my root partition, i was asked to enter my root password which i obviously couldn't or to reboot the system with ctrl-d. my only option was to do a manual fsck off the live-cd. why not just build in support for sudo for such an essential tool?
<HrdwrBoB> if fsck fails
<HrdwrBoB> it should drop to a root prompt
<HrdwrBoB> it does for me
<pitti> pitti@rookery:/srv/language-packs.ubuntu.com/hoary-updates/sources-update$ du -hs
<pitti> 497M   
<pitti> GOOD GRIEF!
<pitti> there actually seem to be folks around who use Rosetta... :-)
<Treenaks> whoa... 500M!?!?!
<Treenaks> of translations?
<pitti> Treenaks: of *updated* translations, compared against the original hoary langpacks
<pitti> -rw-r--r--  1 pitti warthogs 1881192 Jul 30 08:30 language-pack-de_20050729_all.deb
<pitti> for .de alone this makes 1.8 MB of new translations -- not bad :-)
<Treenaks> pitti: that's even more impressive
<Treenaks> pitti: this is for all packages, or only main?
<pitti> Treenaks: only main, I already sorted out the universe po files
<pitti> hum, for actually testing them I need to switch to my hoary box (my desktop), and my gf is still asleep...
<pitti> ok, cu later
<tobias_> Any estimation on when the xkb mess will be cleared up again? X is broken for about 3 weeks now on my boxes:-(
<daniels> xkb works fine
<hunger_> Ah, xkb works again once I have installed a couple of new debs. Why aren't those part of x-window-system?
<daniels> it's in transitioon
* hunger_ sighs. Yeap, I know. But it still is very frustrating.
<hunger_> daniels: I do like your split up debs a lot better than the ones there were before them. You are doing great work.
<hunger_> daniels: But it still is extremly frustrating to have broken X all the time;-)
<hunger_> unfortunately hoary does like this laptop even less than breezy does... so I am stuck with breezy since I want to stay with ubuntu.
<jdub> daniels: what are the extra packages required for xkb love?
<daniels> jdub: xkbutils, xkeyboard-config
<daniels> sudo dpkg -i --force-overwrite /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<jdub> aha
<jdub> thanks
<\sh> morning
<daniels> er
<daniels> s/force-overwrite/force-confmiss/
<\sh> daniels: your email pls...I'll send u the xterm-203 package :)
<daniels> daniel.stone@ubuntu.com
<\sh> thx
<\sh> it's on the way...
<\sh> ok...going shopping :) somewhere in one of those shoppingcenters in Cologne, there is my isdn+sip phone combination and it's only w8ing for me...*yes*
<daniels> heh, enjoy
<doko> ogra, elmo: wxwdigets2.6 is in NEW, approved by mdz. in the meantime you can find it on chinstrap:~doko/uploads
<highvoltage> hi. i need to do some testing under hoary, problem is, that once X attempts to start, my screen goes and stays black (due to buggy i810 drivers, i think).
<highvoltage> so i need to know two things, how can i disable the i810 driver (to prevent the blanking), and how do I fix xorg? (or will this become clear once i fix problem #1)?
<lsuactiafner> highvoltage : this aint the channel for questions like that
<lsuactiafner> #ubuntu
<lsuactiafner> but edit the video driver in /etc/x11/xorg.conf to vesa not 810
<highvoltage> lsuactiafner: ok, thanks
<mjg59> Hm. Suspend to disk seems to be generally faster in 2.6.12.
<sladen> maybe somebody changed the algorithm, there is/was something horrendiously wrong with it, even if I never figured out what
<highvoltage> mdz: should i post my ltsp findings to the ubuntu-devel mailing list only, or can I put them on the wiki as well?
<pitti> doko: here?
<doko> pitti: yes
<pitti> doko: Debian adopted my hpoj derooting patch and, as it seems, all other Ubuntu changes
<pitti> doko: if you have a minute, could you please check whether it still works for us? then we can just sync
<doko> yes, I should forward the hplip patch
<jsgotangco> horaay for pitti
<pitti> it's actually the third derooting patch that's accepted in Debian :-)
<doko> pitti: just replace the driver and use hpoj?
<pitti> doko: no, just a test if it still works as expected; I think mdz still wants hplip, though
<doko> ehh, hplip is the recommended one for most office jets ...
<Nafallo> pitti: what are the others? :-)
<mdz> highvoltage: ubuntu-devel is fine
<pitti> Nafallo: https://wiki.ubuntu.com/DerootificationStatus
<pitti> Hey mdz
<mdz> hi
<Nafallo> nice page :-)
<doko> mdz: is NEW an elmo only thing?
<mdz> doko: no...
<doko> mdz: could you approve wxwdigets2.6 and gcc-3.4 (new binaries for amd64)
<mdz> doko: and powerpc?
<doko> mdz: ahh, yes the 64bit libs as well
<doko> mdz: hmm, then maybe the extra libs built by gcc-4.0 are needed as well
<mdz> doko: hmm?  there is no gcc-4.0 in NEW
<doko> ahh, I see, already in the archive
<pitti> \sh: argh, you infected my ffox, it crashes all the time since today
<\sh> pitti: hmm...after cairo update from today...it works again
<tseng> here too
<pitti> \sh: thanks for the hint, I upgraded libcairo1, let's see
<doko> mdz: are you doing syncs from unstable as well? seb128 requested glitz to build an glitz enabled cairo
* Mez makes a complete bckup of his system ebfore installing breezy
<pitti> Mez: I keep /home on a separate partition, so I can easily switch between several installations on different partitions :-)
<Mez> pitti :D same here :D
<Mez> and I also keep /boot on a seperate partition
<Mez> and my music, my downloads, buildds, stuff like that
<sebest> hello, anyone can tell me what is still broken in X?
<Mez>  pitti though I'm thinking 90Gb for /home and 80 for / might have been wayyyy too big
<pitti> Mez: for /home you can never have enoguh :-) but I create 5 GB partitions for each /
<pitti> /dev/hda3              6595632   4503412   2092220  69% /
<Mez> pitti: whoops then
<pitti> ok, 6 GB, but oh well
<Mez> /dev/hda1             72090684   3303592  65125080   5% /
<tseng> mdz: going to debian-mono team to discuss fixing libmono0 dep problem.
<Mez> pitti, but then I keep like - my music and everything on seperate partitions
<Mez> do do you think my 70Gb (thought it was 80) / partition might be a bit too big?>
<Mez> does gparted let you resize ext3 partitions without losing the data ?
* Mez tests
<hunger> Why does sl-modem-daemon depend on sl-modem-modules-new? it works with alsa here.
<hunger> Can't this get changed to a recommends said modules? They are needed by in some settings, while in others sl-modem-daemon is happy with the alsa driver included in the default kernel.
<crimsun> hunger: perhaps a sync from sid is better.
<mdz> doko: I have not done that before, so it's better to wait for elmo unless it's urgent
<jdub> yo mdz 
<mdz> jdub: sup
<jdub> mdz: was floodage a reason to not leave for LWE?
<Lathiat> firefox crashing is starting to get really annoying
<hunger> Lathiat: I wish firefox was the only thing that routinely crashed on my box:-(
<mdz> jdub: it's one reason, but a more important reason is breezy feature freeze
<Mez> has X been fixed on breezy yet ?
<jdub> mdz: badness; okay :)
<Mez> ah
<Mez> nvm
* Mez reads topic
<infinity> mdz : Do you mind overly if shtool gets germinated into main as a new dependency of php5-dev?  We're already distributing a copy of it IN php[45] -dev, and I'm pulling that copy out in favour of the dependency (yes a recent security vuln has prompted this audit..)
<mdz> infinity: assuming it gets the same review as anything else, I've no issues with it
<infinity> Mmkay.  Will do.
<Mez> grr
<Mez> tyhis is annoying
<Mez> I'm trying to resize something with gparted
<Mez> and it's doing bugger all
<infinity> mdz : Report created.  MainInclusionReportShtool
<jdub> mdz: thoughts on https://bugzilla.ubuntu.com/show_bug.cgi?id=12613 ?
<jdub> mdz: a few people have bugged me about it
<mdz> jdub: people actually use ruby?
<jdub> mdz: politics!
<pef> hello
<HiddenWolf> Anyone around involved with ubuntu-lite?
<OculusAquilae> HiddenWolf: is there a ubuntu-lite project already?
<Amaranth> it's a breezy goal, i thought
<Amaranth> EPARSE, mixed tenses
<jdub> Amaranth: different project
<jdub> HiddenWolf: i know one of the dudes working on it (here in .au)
<HiddenWolf> jdub: do you happen to know about a mailing list, or who I can bug on irc?
<Riddell> mdz: kubuntu main inclusion reports are up
<Riddell> how do I get subscribed to changed on the whole of the wiki?
<HiddenWolf> Can't your subscribe to updates to the RecentChanges page?
<Mez> kamion: ping
<pHr33K`|Dek2on|`> hi guys
<pHr33K`|Dek2on|`> any helpers available
<Treenaks> helpers are on #ubuntu
<zyga> Treenaks: with someone named pHr33K`|Dek2on|` you shoud rather have said 'No, sorry'
<HiddenWolf> zyga: naughty!
#ubuntu-devel 2005-08-05
<Mez> pitti: ping
<Mez> infinity, ping
<Mez> elmo/mdz: ping
<Mez> elmo/mdz/pitt: unping
<Mez> pitti*
<Lathiat> hrm, why does ubuntu switch away from X when you close the lid
<Lathiat> cus it never goes back
<Lathiat> i have to hit alt+f7 every time i open my lid
<Mez> the "lid"
<Mez> ?
<bddebian> Laptop screen?
<Mez> oh... fair enough
<Lathiat> yeh
<Lathiat> on my laptop
<mxpxpod> what happened to the netapplet gnome-panel applet?
<mxpxpod> mjg59: ping
<mxpxpod> I have my dpi set to 75 and firefox doesn't seem to want to follow that
<mxpxpod> does anyone know about that?
<bob2> gnome gets very very unhappy when /home/ fills up
<Amaranth> i bet
<Lathiat> hrm is the usb printer autoa-dd in gnome-volume-manager supposed to work yet?
<Lathiat> doesnt seem to have any idea my printer is a printer
<jdub> Lathiat: not without some extra cups/d-bus/hal integration patches from rh, i *think*
<Lathiat> jdub: ah
<sivang> mornig all
<sivang> morning, eve
<siretart> does anyone happen to have the upstream changelog for evolution?
<siretart> never mind, found it
<doko__> mdz, Kamion: please promote libhsqldb-java to main, OOo2 build-dep
<mdz> doko__: does it have a main inclusion report?
<doko__> mdz: no, I did convert it to use gcj weeks ago. the packaging at least is fine
<doko__> but it's on UbuntuMainInclusionQueue
<doko__> mdz: if it helps, it's already in main (included in the OOo2 source package)
<mdz> doko__: it's a build-dep of ooo2 which is also built from the ooo2 source package?
<doko__> mdz: the patched source is in the ooo2 source package, now that the patch is integrated in the external package, it's using this package
<brach_> question:   for a total noob @ coding (never done it) what language would be a good start in learning? (if their even is such a thing) 
<Burgundavia> brach_, Python is solution Ubuntu favours
<brach_> ahhh mmk
<Burgundavia> s/is the
<Burgundavia> for a similar non-coder, I found it quite easy to get into
<brach_> hmmm sounds good thx!
<Burgundavia> http://www.pygtk.org/tutorial.html
<Burgundavia> that will get you started
<brach_> kool thx for the time
<Burgundavia> np
<Mez> infinity: ping
<infinity> mez : pong, ish.
<Mez> infinity- I'm backporting php5 for hoary...
<infinity> Mez : Don't yet.  It's broken in breezy.  I need to do anither upload.
<Mez> so far it;s building ok, and if it finished the build ok - would you be ok with making the changes to breezy so it can be backported on official servers
<Mez> ah..
<Mez> oh.
<Mez> ok
<infinity> s/anithoer/another/
* Mez hits ctrl +c
<Mez> can you poke me when you've done it
<infinity> What changes are you making to make it build automagically on hoary without issue?
<infinity> I can put those in to the next upload, if they're nonintrusive.
<Mez> so far just B-D
<Mez> dpkg-dev (>= 1.10)
<infinity> Those B-D work on sid and breezy, I'm surprised we're that far out from hoary already.
<infinity> Oh, the dpkg-dev thing, right.
<Mez> and  libpq-dev | postgresql-dev 
<infinity> I'd need to make debian/rules changes to make the dpkg-dev build-dep go away.
<infinity> I probably should anyway.
<Mez> infinity, get rid of dpkg-dev from B-D?
<infinity> (Though, given how many sid/breezy packages have that dpkg-dev build-dep, maybe having the new dpkg in backports isn't such a bad idea)
<Mez> infinity - wouldnt that cause breakages?
<infinity> The dpkg-dev build-dep is intentional, due to dpkg-srchitecture changing.
<infinity> s/srchitecture/architecture/
<Mez> I got that one :D
<Mez> so, if you add the libpq-dev | postgresql-dev change to breezy, and I'll get dpkg added to backports (if you think it wont break things - and we know it backports as it was the "acid test"
<infinity> Well, define "won't break anything".
<infinity> With dpkg-dev from breezy installed, many sources from hoary will fail to build correctly.
<Mez> ah.
<Mez> hmm
<infinity> But with dpkg-dev from hoary, many source from breezy won't build.
<infinity> It's a catch-22.
<infinity> SO, we could never put the new dpkg in hoary-updates, but it MIGHT not be so bad to have it in hoary-backports.
<Mez> hmm
<Mez> I think this one'll have to go through mdz
<infinity> I think we'll need to make some backports-related decisions one way or the other, yes.
<infinity> The new dpkg isn't the best thing to try to backport, but at the same time, many things you want to backport will fail without it (unless you edit debian/rules, which means no more "automated" backporting, and some actual uploading instead)
<Mez> wont they build if they dont rely on the breezy version of dpkg-dev - whats the changes between the two versions
<infinity> So, some thought/discussion probably has to go into this.
<infinity> Do you have both a hoary and a breezy system installed there?
<Mez> pbuilds :D
<Mez> I wiped my breezy cause well - I want X hehe and the colony CD broke
<infinity> If so, type 'dpkg-architecture -l' on both, note the drastic differences, and realise that many (MANY) packages use those variables to determine certain aspects of the build in debian/rules.
<infinity> In the case of php5, however, I realise that people will want to backport it to both hoary and sarge, so I'll fix debian/rules to work with both the old and new variables.  Not a big deal to do so.
<Mez> cool :D
<jdub> yo infinity 
<infinity> yo jdub
<Mez> nice of you to do... though I think we'll need to talk with mdz about backporting dpkg
<jdub> infinity: pleased to see php5 in my main-only mirror update :-)
<infinity> Mez : Or about backporting involving actual source editing.  One of the two.
<Mez> infinity, want me to CC: you ?
<infinity> Mez : Please.
<infinity> jdub : Not as pleased as I am to see php4 getting removed in that same update.
<jdub> heh
<infinity> At least, it should have, unless someone seeded it back in..
<infinity> Or, unless it didn't get demoted yet.  Either is possible.
<infinity> Still, yay to the eventual demise of php4 in supported.
<infinity> Upstream will EOL it before we stop supporting it, and I don't want to become upstream for php4 like I have for php3.
<Mez> infinity, if you can change the package in breezy to work with both hoary and breezy...
<Mez> then isnt it possible to do that to the packages we want to backport
<infinity> mez : My plan is to make sure the breezy/sid sources work with hoary/sarge, yes, but that's not going to happen for every package you want to backport, cause the distro team probably has better things to do with their time.
<infinity> mez : This one's purly a "personal interest" thing, and I'm doing it on a Sunday night. :)
<infinity> s/purly/purely/
<infinity> mez : (ie: non-paid time)
<Mez> infinity - the thing is, couldnt say, a backporter go in and modify the package to work in hoary and breezy and then upload?
<infinity> Mez : If they are in the right keyring, have permission to upload such changes (especially if it's in main), and the changes are obviously not intrusive, sure.
<infinity> Mez : But they'd need to be well-tested on breezy, because breaking a breezy build for the sake of a hoary backport is very unacceptable.
<Mez> infinity, I understand that
<Mez> infinity, what changes do you generally make to make the dpkg-dev sutff work on breezy and hoary
<infinity> Mez : BTW, can you make your IRC client report your real name in the 'ircname' field in /whois, I really hate not knowing who I'm talking to.
<Mez> infinity, people IRL call me Mez
<Mez> hence my real name :D
<Mez> lol
<Mez> but I can change it to the one on my Birth Certificte
<infinity> Mez : Depends.  With some packages, you can get away with s/-gnu$// in a few places, with others you need to be more careful..
<infinity> Samba, for instance, breaks miserably if you just try to remove the -gnu.
<infinity> (Note also that i386- changed to i486, and samba has some pre-cached files in debian/* that rely on that named output...
<Mez> infinity, if only there was an easy way to check which version of dpkg you were working with and use the right rules :D
<infinity> Mez : There is an easy way, but you still need to know what the "right thing to do" is, based on which dpkg-dev version you're using.
<infinity> (And that "right thing to do" depends on how the package is using those variables in the first place... Is it feeding them to autoconf; is it comparing against them to set CFLAGS; is it loading cached static files based on the output; ...?)
<Mez> hmmles..
<Mez> and that is most likely behod my (current) comprehension
<Mez> s/behod/beyond/
<infinity> Anyhow, all the ramifications of this can be discussed at length later.
<infinity> For now, I'll fix php5 for you, so it compiles with no changes on breezy, sid, hoary, and sarge.
<infinity> No hope for warty or woody, so don't ask. :)
<infinity> (Well, warty is possible, woody's too much hassle, I just don't care about either, though)
<HiddenWolf> porting new packages to old apps is counterproductive: users need to upgrade anyhow.
<Mez> infinity - no probs :D CC'inmg to -backports mailing list too
<\sh> what was the name of the tool to compile kernel modules from installed sources?
<infinity> \sh : module-assistant?
<infinity> \sh : (gcc?) :)
<\sh> infinity: yep..found it ,-)
<\sh> lets try the usb quickcam drivers with 2.6.12 ,-)
<siretart> \sh: it would be great if you could test the breezy version, if you are at it. the merge was nontrivial, but it *should* work
<\sh> siretart: i just compiled qc-modules 
<siretart> great :)
<\sh> and I will try it with gnomemeeting ;)
<\sh> I don't have hoary at all ;)
<\sh> hmmm...
<\sh> I installed the module...ok...I installed v4l1-compat ... but gnomemeeting doesn't find anything
<\sh> no /dev/video
<\sh> or /dev/video0
<infinity> Mez : In the future, when you mail IRC logs to people, can you cut out the non-relevant portions of the conversation, it's a bit hard to follow with people coming in/out, side conversations going on, etc.
<infinity> Mez : And the new php5 will be uploaded as soon as I have permission to re-seed shtool to main (which is waiting on pitti to review the InclusionReport), but that should be within a day or so.
<Mez> sorry and ok :d
<infinity> Mez : But please don't bother attempting to backport it before then, cause the current packages and the new ones won't really like each other very much, making partial upgrades weird (they won't BREAK, but apt-get does funny things on php partial upgrades sometimes...)
<infinity> Mez : Oh, and one other request you can pass on to MOTU at large... If anyone requests that you build a php5 module for apache1.3, can you just flat-out refuse, and beg them to upgrade to apache2?... We're really trying to get people to switch sometime this decade. ;)
<infinity> Mez : Feel free to CC me in the response, and I can argue with them, if you'd like.
<tseng> infinity: dude, libapache2-mod-auth-kerb
<tseng> infinity: whered it go :P
<infinity> tseng : Did it disappear?  Did it ever exist?
<tseng> it exists in debian
<tseng> http://packages.debian.org/unstable/web/libapache2-mod-auth-kerb
<infinity> tseng : Not in any Ubuntu release, though.  Looks like it never got synced to start with.
<tseng> ya
<tseng> but it was uploaded Feb 2004
<infinity> tseng : Neat.  Well, I'm sure it wouldn't be a drama to shove it into Universe at this point, I'd just ping mdz first, if I were you.
<tseng> indeed
<tseng> mdz: can we sync libapache2-mod-auth-kerb? its been in debian for over a year it looks like
<Mez> infinity, I will do if someone asks for it
<tseng> mdz: somehow we've not managed to pick it up
<infinity> mdz : For some reason, it (libapache2-mod-auth-kerb) appears to have never been picked up and synced, looks bug-free, same version is in sarge and sid (stableish source, looks like), and maintained by hartmans, so probably sane.
<infinity> mdz : Nevermind.  It (libaapche2-mod-auth-kerb) is here.  One of us is stupid, the other lazy, and we didn't look hard enough.  Ignore the previous babble from tseng and I.
<zul> lol..http://bugzilla.ubuntu.com/show_bug.cgi?id=13106
<infinity> tseng : Dude, it's in the archive, it's just FTBFS.
<tseng> infinity: hm since forever?
<infinity> tseng : people.u.c/~lamont/buildLogs/liba/libapache-mod-auth-kerb/
<tseng> boggle
<infinity> tseng : Either apache-dev is busted (if apache1.3 also currently FTBFS in breezy?  If so, I should upload a fixed version), or liba-mod-auth-kerb itself is broken. Pick one.
<infinity> Ahh, yes, apache1.3 is FTBFS in breezy.  I think we have a patch floating around for that.
<infinity> I'll upload a fix soonish and give-back libapache-* to see if it suddenly unbreaks.
<tseng> rock on
<infinity> I thought fabbione Was going to upload a new apache1.3 to sid, but I guess he never got around to it.  So, I'll upload, then sync.
* infinity looks at that "Was", and wonders how that got capitalised...
<tseng> "The new mod_proxy_ajp module adds support for the Apache JServ Protocol version 1.3 used by Apache Tomcat."
<tseng> imagine that
<tseng> more to beat the mod_jk2 lusers at work over the head with
<tseng> (yes, they use mod_jk2 in production)
<mxpxpod> is anyone else having a problem with firefox not respecting the application font?
<mxpxpod> http://www.reigndropsfall.net/images/firefox-font-problem.png
<Amaranth> mxpxpod: I think I'm seeing something like that.
<mxpxpod> Amaranth: know what would be causing it?
<Amaranth> The fonts on at least gmail are different now, couldn't figure out why.
<Amaranth> Nope.
<mxpxpod> well, it's like all of firefox isn't respecting either the dpi or the gnome application font
<mxpxpod> if you notice, the fonts for the menubar and bookmarks are huge as well
<Amaranth> hmm
<Amaranth> *shrug*
<Amaranth> I don't change the default fonts.
<Amaranth> AndyFitz: hey, what do you think of http://dev.realistanew.com/icon_example.png ?
<AndyFitz> Amaranth: g'day,  ooOOo  I like it !   want an icon for smeg ?
<Amaranth> AndyFitz: please :)
<Amaranth> AndyFitz: something like that, but not sucky :)
<Amaranth> or i can use that for the about and something else for the menus and etc
<AndyFitz> I don't like the ofice or accessories icons lol  they will be changed  :-)
<Amaranth> aye, 22x22
<Amaranth> need something scalable otherwise smeg makes them look like ass :)
<Amaranth> AndyFitz: Do you know if inkscape embeds images into the svg when you save?
<Amaranth> AndyFitz: or does it still point to their path on the filesystem?
<AndyFitz> Amaranth: no it doesn't.
<Amaranth> err
<Amaranth> which does it do?
<AndyFitz> it still uses the relative path 
<Amaranth> damnit
<Amaranth> that means this svg only works on my computer
<AndyFitz> its no hassle to tar ;)
<AndyFitz> as a rule I usually keep all linked images in the same dir as my svg  or sla ( if I'm using scribus )
<Amaranth> well, in order for this to work correctly i need to ship it with humility and have humility installed exactly where it is right now on my computer
<Amaranth> it should really embed a base64 encoded version of the image in as the src
<AndyFitz> Amaranth.  it is capable of reading svg files with embedded images
<Amaranth> i just have to do the embedding myself?
<LinuxJones> Anybody have a rough idea of the number of downloads of Hoary from the Ubuntu servers ?
<zyga> LinuxJones: there is a stat page IIRC
<LinuxJones> zyga, ok thanks, just doing some research for a project I am working on
<Amaranth> ack
<Amaranth> inkscape can load b64 encoded images from href attributes, librsvg can't
<Amaranth> oh, inkscape is using a different attribute, it doesn't work either :/
<CarlFK> http://cdimage.ubuntu.com/daily/current - no i386
<CarlFK> guessing it is being built?
<CarlFK> kinda looking for an ETA
<Amaranth> CarlFK: Next month.
<CarlFK> cute
<CarlFK> what time zone? ;)
<Amaranth> It doesn't build because of a bad dependency between some language packs and openoffice2
<Amaranth> oh, powerpc builds now
<CarlFK> ah - so it is a known problem and may be a while.  all I needed to know
<Amaranth> yeah
<CarlFK> is there any sort of schedule for dayily builds, or is it whenever someone feels like it?
<Amaranth> from the look of it they go out at 9am GMT
<CarlFK> well, that might be the last time someone felt like it
<CarlFK> I suppose I could watch for a week
<Amaranth> it's automated
<CarlFK> ah
<Amaranth> and i don't think there are any logs generated on why it fails either
<Amaranth> at least not that everyone can see
<CarlFK> so if I do an rsync each day at 11, good chance I will be current
<Amaranth> yeah
<CarlFK> 5am for me - good timing
<yccheok> in linux, pthread_setschedpara - higher number means lower priority or higher?
<Keybuk> meh, everyone's being sensible and offline on Sunday
<jdub> morning Keybuk 
<Keybuk> jaaaayyyy-dub
<Keybuk> so I was thinking about hacking "removable-disk media player" support into Rhythmbox, and wanted to bug seb or pitti about the HAL/g-v-m/pmount stuff
<Keybuk> basically want Rhythmbox to treat any removable disk as a separate library, so if you start it without your iAudio plugged in, it just disables the library rather than clearing it out
<siretart> sounds great!
<kent> Keybuk they have that in some development branch of rhythmbox now right?I thought I read about something like that before..
<Keybuk> might have to hunt for that
<Keybuk> I know there's iPod support in main, but didn't know whether they'd done generic removable
<kent> Keybuk as fare as I know, and thats not much, they have a lot of branches of the development of rhythmbox, and I am fairly sure I have read about something like this before..  But dont trust me, Im not an expert.
<Keybuk> I figure we'll need HAL-based automounting first though
<sivang> rehi all
* sivang is debootstrapping yet another breezy chroot
<sivang> been working from three different computers this week
<Lathiat> heh
<sivang> Lathiat: what suck is, that the net connection form here is not that good :)
<sivang> Lathiat: so I'm waiting a bit longer then I am used ot
<Lathiat> heh how "good" 
<sivang> Lathiat: lets check
<sivang> bah, the irc latency is killing me
<sivang> about 750kbs downstream, 96upstream
<Lathiat> sivang: heh
<sivang> Lathiat: yeah. that's as poor as can be :)
<Lathiat> well i only have 1500/256
<sivang> Lathiat: poor you :)
<sivang> Lathiat: I don't think there a private household broadband connection that has 256 upstream in whole .IL :)
<sivang> Lathiat: if you lease a frame relay, maybe
* Treenaks pets his 1M up
<Treenaks> (2M/1M ADSL)
<Lathiat> thatd be nice
<Treenaks> Lathiat: come to .nl :)
<Lathiat> heh
<Lathiat> i can get 8M/1M
<Lathiat> but i'd pay a fortune for it
<Lathiat> and get limited quota and no quota-free 'WAIX' (most ISPs in my city)
<Lathiat> tho i only have 10GB peak and 10GB off-peak (12am-7am) now, but i get unlimited to WAIX
<Lathiat> and there are all sorts of mirrors on waix esp for linux stuff etc so its handy
<pitti> Good evening, ladys, gents, hackers, aliens, etc.
<Lathiat> hey pitti
<Lathiat> pitti: sooo... when will hotplugging printers work like g-v-m-properties thinks it will? :)
<pitti> we recently found a guy who wanted to give printing some love
<pitti> let's hope :-)
<Lathiat> cool :)
<Burgundavia> is this useful to anyone? https://wiki.ubuntu.com/QAtesting
<zul> hey pitti 
<pitti> Hi zul 
<zyga> Lathiat: what's WAIX?
<zyga> pitti: hello :)
<concept10> Any GNOME hackers here
<|quad|> is there a bug with breezy and xorg and detecting keyboards?
<pitti> doko: is hsqldb really necessary for OO.o2? supporting yet another database with a 2 year old vuln that has not been properly handled (as it seems) makes me nervous
<pitti> doko: can hsqldb support be disabled?
<robitaille> smurfix:  ping
<smurfix> ?
<robitaille> smurfix:  would it be possible for your logging bot to start logging #ubuntu-bugs ?
<robitaille> it's probably the only ubuntu channel not in any logs
<doko> pitti: which format should ooo2-base use then?
<smurfix> robitaille: sure, can do
<pitti> doko: you requested only the java interface, not the server package itself? 
<robitaille> smurfix:  thanks
<pitti> doko: so if OO.o2 actually uses hsqldb for storing its data files, why it doesn't need the server?
<doko> pitti: yes, only libhsqldb-java, not all binaries
<pitti> doko: I thought it would provide only yet another driver for connecting to a database
<lamont> and could breezy+1 or so _please_ split oo.o2 into more edible-size chunks?
<lamont> (source that is)
<pitti> doko: that would still pull the source package into main, which makes it a gray zone...
<doko> lamont: we will duplicate the source for breezy
<pitti> doko: so what is it required for?
<doko> pitti: oo2-base is an Access clone
<doko> base == database
<pitti> right
<pitti> doko: so without the package, ooo2-base couldn't connect to hsqldb databases? would that really hurt?
<doko> pitti: so, which database should it connect as an alternative?
<pitti> doko: what's the current default?
<pitti> I mean, if it tries to use hsqldb by default, that'd be wrong anyway since we don't support the server, right?
<pitti> (I don't really have a clue about ooo2-base...)
<doko> pitti: it doesn't need any server
<pitti> <doko> pitti: so, which database should it connect as an alternative? <- if it doesn't need one???
* pitti is really confused
<doko> s/any server/any hsqldb server/
<doko> pitti: just create a new database/file/whatever using oo2-base
<pitti> we support mysql and postgresql ATM, with mysql currently being the more popular, I guess
<doko> pitti: so the server is installed by default, and the user can create database files, copy them and them to a friend?
<doko> s/and/and send/
<Mez> how "unbroken" is X ?
<Amaranth> Not at all.
<Burgundavia> pitti, you are one of the leads on the ia64 port, no?
<niran> Amaranth, for the smeg about box, s/complient/compliant
<pitti> Burgundavia: no, I don't have such a machine
<Amaranth> niran: I know.
<niran> oh, ok
<Amaranth> niran: About 20 people have told me that in 2 days.
<Burgundavia> pitti, who is?
<niran> ha.
<pitti> Burgundavia: no idea...
<Burgundavia> pitti, ok
<pitti> night everybody
<Amaranth> night pitti 
<robitaille> Burgundavia: http://ubuntuforums.org/showthread.php?t=4696  it's old, but there is someone name in that thread (Thibaut Varene)
<Burgundavia> robitaille, it is lamont who does it
<Burgundavia> just remembered
<robitaille> Burgundavia: maybe the wiki page should have a contact name (https://wiki.ubuntu.com/IA64PortStatus)
<Burgundavia> that was the page I was just looking at
* lamont goes to update
<lamont> robitaille: current breezy/ia64 status is that kernels < 2.6.12-6.7 (and > 2.6.10) all fail to boot, very early.
<lamont> that will be fixed in -6.7
<lamont> the hoary install CD that we cut works just fine, if you don't mind one trip to an editor
<lamont> this is just awesome... how do I log out of the wiki, I wonder....
<lamont> mdz/some wiki God... please merge LamontJones and LamontJones2.  kthxbye
<lamont> oh, and use LaMontJones2's auth info, please
<tseng> lamont: you can logout on UserPreferences
<lamont> yeah - found that part
<tseng> lamont: which is likely linked right under search
<concept10> will GNOME 2.12 be in the breezy release?
<HiddenWolf> concept10: yes
<concept10> HiddenWolf, thanks.
<HiddenWolf> Ubuntu releases on the same day as gnome, every single time.
<Burgundavia> HiddenWolf, no
<Burgundavia> we release a month later than .12
<HiddenWolf> Burgundavia: oh, is it? :P
<HiddenWolf> What's the marketing value in that? :P
<Burgundavia> .12 is sept 7th, we are Oct 13 
<Burgundavia> we have been the first to release the new gnome
#ubuntu-devel 2005-08-06
<Burgundavia> it also looks like all the gnome live cds that gnome is going to be handing out will be able to turn into Ubuntu installs
<HiddenWolf> Burgundavia: really? cool!
<Keybuk> whoah, the font size issue _WAS_ gtk bug!
<Mez> Keybuk, fint size?
<Mez> lol
<jdub> HiddenWolf: preview release has been same day in the past (it'll be a day or two after now though)
<HiddenWolf> jdub: yeah, i figured i was being stupid.
<jdub> HiddenWolf: then a month of stabilisation and bug fixing until our final release (which ends up being roughly the gnome point release)
<HiddenWolf> jdub: thanks
<jdub> anytime
<jdub> except shower time
<jdub> which is now
<jdub> i managed to tear my finger tip open this morning
<jdub> right middle
<jdub> very annoying for the typing
<whiprush> type with pencils like the fly did.
<jdub> *click*click*click* OW! *click*click*click* OW!
<HiddenWolf> jdub: be careful then! The community is counting on you being able to type straight. :)
<Lathiat>  jdub ouch
<Lathiat> ok who knwos dbus
<Lathiat> i have some code taht wont work and i cant figure out why
<Lathiat> the other send sends the reply, but i get a reply with no arguments
<Lathiat> and there is no error condition
<Lathiat> (other than it has 0 arguments)
<Lathiat> it was working before and lasttime i had this problem it was because i was passing NULL instead of an error variable
<Lathiat> zyga: west australian internet exchange
<Lathiat> zyga: where most ISPs in my city connect to pass traffic between each other as oposed to international transit
<infinity> Why would anyone want to talk to someone else in WA?
<tseng> there is more than one person?
<Lathiat> heh
<infinity> Hrm, don't you hate thinking "Gee, I knew I forgot something" about 5 seconds after typing "dupload *changes"?
<infinity> I know I do.
<infinity> Oh well, no -v option to dpkg-genchanges just means a short and uninformative email to -changes, could be worse.
<crimsun> yeah, it bit me once when I didn't have ubuntu defined, so it uploaded to ftp-master. D'oh!
<infinity> I remove the default from dupload.conf intentionally to prevent that.
<infinity> So I MUST specify --to debian or --to ubuntu to upload.
<daniels> infinity: my dput is two-fold, and involves an scp to chinstrap first, so I have a few seconds.
<infinity> (And since I upload to both, that's kinda important)
<infinity> Why the two-hop approach?.. What have you got against anonymous ftp uploads?
<infinity> (Or just the fear of broken connections leading to having to upload the whole mess again, because the ubuntu queue doesn't keep files around like the debian one does?)
<mxpxpod> is mpeg_encode in any ubuntu package?
<jammcq> hey guys, mdz has asked me to try out his latest ltsp stuff in breezy. But first, I need to transform this hoary box to be breezy.  any pointers to how to setup the apt/sources file?
<jdub> jammcq: :%s/hoary/breezy/ :-)
<jammcq> that's it ?
<jdub> jammcq: you going to oscon as well as lwe?
<jdub> yeah
<jammcq> nope
<jammcq> not this year :(
<jdub> then apt-get update, apt-get dist-upgrade -u
<jdub> ahr
<jammcq> i was at ols, and just can't be gone that much
<jdub> well, i will see you at lwe anyway :)
<jammcq> yeah, looking forward to it
<jammcq> jdub: you in portland now ?
<infinity> jammcq : Save a copy of /usr/X11R6/bin/mkfont*, s/hoary/breezy/ in sources.list, apt-get update; apt-get dist-upgrade, copy those two binaries to /usr/bin (and /usr/X11R6/bin, some stuff still looks there), install xkbutils, pat self on back.
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | X is a lot less broken
<daniels> infinity: no, no, no
<daniels> jammcq: don't listen to infinity.  just make sure you install xkbutils, xrdb, xprop, xauth and xinit when you're done.
<daniels> infinity: i fixed mkhost* yesterday
<infinity> daniels : Oh, mkfont* came back while I was away from the keyboard?
<jdub> jammcq: sydney, surry hills office ;)
<jammcq> jdub: isn't oscon starting like now ?
<jdub> sort of
<jdub> tuesday evening is the proper kick off
<jammcq> ah
<jdub> mon/tues are tutorials and stuff
<robertj_> it seems like there are entirely too many cons these days ;)
<jdub> plus, being in the future, i get to leave on monday and arrive on monday
<infinity> daniels : Dude, I see no mkfont binaries anywhere, except the ones I copied from hoary.
<mxpxpod> why isn't ucbmpeg in powepc?
<robertj_> it seems like Jeff is a full-time convention attender these days ;)
<jdub> not as bad as mako... yet
<lexhider> daniels: has xfonts made it through yet?
<daniels> lexhider: *cough* no
<daniels> infinity: yeah, well, give it an hour
<robertj_> are things going to be more or less tame by the next colony release?
<infinity> That's the plan.
<infinity> daniels : xfonts-core is FTBFS.
<daniels> infinity: hence 'yeah, well, give it an hour'
<infinity> daniels : <smirk>
<daniels> robertj_: kamion can't really release a colony if nothing works.
<lamont> daniels: you around?
<lamont> n
<lamont> nm, even
<Amaranth> woo, smeg 0.8 might actually see the light of day
<Burgundavia> that is nice
<Amaranth> i've got all of the new framework stuff setup again, i just need to copy chunks of code over to it
<Amaranth> and then add the new features again
<lamont> any console-data literate folks around?
<lamont> Keybuk: you really here, or bouncing?
<Keybuk> really here
<Keybuk> what's up?
<mxpxpod> daniels: ping
<mxpxpod> Amaranth: did you get anywhere with the firefox bug I pointed out?
<Amaranth> mxpxpod: Haven't looked at it at all, honestly.
<Amaranth> I know absolutely nothing about firefox.
<mxpxpod> heh, that's ok
<daniels> mxpxpod: pong
<mxpxpod> daniels: I've got a strange bug with firefox
<daniels> mxpxpod: what's up?
<mxpxpod> daniels: http://www.reigndropsfall.net/images/firefox-font-problem.png
<sebest> hello which package contain xmodmap on breezy?
<daniels> sebest: none of them.  it's a sign to tell you to use xkb.
<daniels> mxpxpod: ... the problem is that your fonts are huge?
<mxpxpod> daniels: just in firefox...
<mxpxpod> daniels: it's like firefox as an application doesn't respect either the dpi or the font setting of gnome
<OddAbe19> wait... X is alot less broken? what still needs fixing?
<Amaranth> OddAbe19: mkfontdir
<sebest> daniels: i think i'm using xkb, but my shift keys doesn't work
<OddAbe19> ahhh
<OddAbe19> yay
<Amaranth> OddAbe19: the thing that still needs fixing is the error you had
<daniels> sebest: then your XKB is broken
<OddAbe19> thanks check check
<sebest> daniels: i'm using a fr beyboard, and for the moment i use xmodmap to make my shift key working again :)
<OddAbe19> thanks
<Amaranth> Guys, let's stop bugging daniels about keyboards and X not starting.
<daniels> OddAbe19: if you've upgraded through breezy, it still bites
* robertj kind of wishes there was a breezy-colony archive
<daniels> sebest: sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<daniels> sebest: and install xkbutils
<daniels> OddAbe19: but upgrades from hoary should be fine, unless you've customised your config
<OddAbe19> daniels, yeah a few nights ago i felt adventourous and dist-upgraded from hoary...
<Amaranth> o_O
<Amaranth> upgrading from hoary is fixed?
<OddAbe19> what changes do i have to make to a customized xorg.conf?
<OddAbe19> now
<daniels> OddAbe19: s#usr/X11R6/lib/X11/fonts#usr/share/X11/fonts#g
<mxpxpod> OddAbe19: you have to update your keyboard config to use the kbd driver
<daniels> Amaranth: yeah
<mxpxpod> daniels: any clue as to what's up with firefox?
<robertj> is that in apt-listchanges/
* Amaranth is completely upgraded in breezy and X isn't biting
<daniels> mxpxpod: no idea, sorry; don't have anything to do with that
<OddAbe19> daniels, i did change that to kbd, but i only go gibberish with the command you posted, what was that?
<mxpxpod> daniels: who would?
<daniels> robertj: no, but it should probably be in NEWS.Debian
<Amaranth> mxpxpod: talk to whoever touched firefox last
<daniels> OddAbe19: change /usr/X11R6/lib/X11/fonts to /usr/share/X11/fonts
<daniels> mxpxpod: i don't think we really have a firefox maintainer at the moment, tbh
<OddAbe19> in xorg
<OddAbe19> cool
<OddAbe19> thanks
<OddAbe19> for all the font paths in xorg.conf now?
<daniels> yeah
<OddAbe19> thanks
<OddAbe19> bbl
<OddAbe19> gotta fix this
<OddAbe19> you rock daniels and the whole team
<OddAbe19> :-D
<daniels> np
<Keybuk> mmm, fist-sized fonts in firefox
<Amaranth> couldn't he have upgraded and used dpkg-reconfigure?
<|QuaD-> daniels.... to get xorg working, i should change all my font paths to /usr/share/X11/fonts?
<Keybuk> fwiw, if you hard-set the firefox DPI setting to 96dpi, it draws things properly
<Keybuk> it's a temporary hack, but it works
<Amaranth> mmm, firefox lockup
<daniels> |QuaD-: yes
<|QuaD-> daniels: thanks
<TerminX> daniels: you aren't packaging xmodmap anymore?
<TerminX> if not, what exactly is the equiv of xmodmap -e "pointer = 1 7 3 2 6 4 5"
<Keybuk> daniels: a bunch of entirely random keys have stopped working -- your bug, or a gnome bug?
<sebest> keybuk what is your keymap?
<Keybuk> xorg/pc105/gb
<Keybuk> things like F12, and the volume keys and stuff
<Keybuk> I _think_ it's a gnome bug, because the accelerator widget still catches them
<daniels> Keybuk: if xev shows them with the right keycodes and symbol names, it's not my problem
<OddAbe19> daniels, works... great... kinda... but it works. Wheel on mouse doesn't move up and down but X works, great job
<daniels> TerminX: i'll package it later but I don't consider it massively important
<Keybuk> daniels: which package is xev in? ;)
<daniels> Keybuk: it isn't, as I discovered last night
<daniels> (this is biting me too)
<Keybuk> wonder if gnome is doing something very silly like using that
<daniels> no way
<TerminX> daniels: alright.. you mentioned sending notice of how to unscrew X on Breezy to ubuntu-devel and ubuntu-users, is there a timeframe for that or are you still sorting out X issues?
<daniels> TerminX: as soon as I upload -44, which I'm still tweaking
<Keybuk> daniels: did you pick a hell of a week to quit drinking coffee or something?
<daniels> Keybuk: hrm?
<sebest> daniels: it seems that changing the keyboard driver is not always enough, i had o change the XkbLayout from "fr-latin9" to "fr"
<TerminX> daniels: alright.
<daniels> i stopped with caffeine at about the start of april
<daniels> so yeah, pretty much bang on 4 months ago
<daniels> sebest: right.  some complex XKB configurations will break, as we switched to xkeyboard-config.
<Keybuk> daniels: so xev doesn't think F12 is F12 ...
<daniels> sebest: fr(latin9) might work
<daniels> Keybuk: what does it think it is?
<Keybuk> KeymapNotify event, serial 27, synthetic NO, window 0x0,
<Keybuk>     keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
<Keybuk>            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
<Keybuk> is all you get
<|QuaD-> daniels: i just changed my fonts to that, i am still getting the same font error
<Keybuk> (no KeyPress/KeyRelease)
<daniels> Keybuk: errrrrr
<sebest> daniels: oki, i think that a lot of people that see keys "dissappearing" in bug report, is because of thing like this one
<daniels> that's XKB sucking, then.  does setxkbmap -rules xorg -layout gb -model pc105, a) help, or b) throw an error?
<daniels> sebest: no, it's because upgrades going through hoary completely smashed xkb.
<Keybuk> daniels: c) neither
<sebest> daniels: btw fr works perfectly no need for fr(latin9) :) good job!
<Keybuk> F11, F12, "Mute", "Volume Down", "Volume Up", "Lock Screen" and "Presentation" don't work
<|QuaD-> daniels: all my entries in my xorg.conf for fonts look similar to this "FontPath        "/usr/share/X11/fonts/misc""
<|QuaD-> is that right?
<daniels> Keybuk: hold on, volume up, volume down, presentation and lock screen aren't in the default UK keymap, of course
<daniels> Keybuk: nor is mute
<daniels> |QuaD-: yeah
<Keybuk> right, but they should at least generate key events
<Keybuk> they used to generate 0x[random two digits] 
<Keybuk> here's a weird one for you...
<|QuaD-> daniels: any idea why it wouldn't work?
<Keybuk> F12 works if you hold down a bucky bit at the same time
<Keybuk> Shift-F12 gives me Shift_L + F12
<sebest> |Quad what is your problem?
<OddAbe19> hmmm... yeah, so far, only thing, scroll wheel goes left right instead of up down
<OddAbe19> i'll file a bug report
<|QuaD-> sebest: could not open default font 'fixed';
<|QuaD-> then there are other lines that follow about fonts not being configured right
<|QuaD-> Could not init font path element unix/:7100, removing from list!
<daniels> Keybuk: hmmm.  works for me.  you haven't got something stupid like f-lock on your keyboard, right ... ?
<Keybuk> daniels: first thing I checked
<daniels> Keybuk: keycodes for f11 and f12 are 95 and 96
<daniels> Keybuk: that's really bong
<infinity> daniels : Meh, libfontenc got NEWed to universe, not main.  xfonts-core will stay FTBFS for a while.
<daniels> Keybuk: could you please clag me the output of setxkbmap -print?
<daniels> infinity: bugger
<daniels> elmo: libfontenc -> main please (it was originally in main, from xorg)
<Keybuk> xkb_keymap {
<Keybuk>         xkb_keycodes  { include "xfree86+aliases(qwerty)"       };
<Keybuk>         xkb_types     { include "complete"      };
<Keybuk>         xkb_compat    { include "complete"      };
<Keybuk>         xkb_symbols   { include "pc(pc105)+gb+compose(rctrl)"   };
<Keybuk>         xkb_geometry  { include "pc(pc105)"     };
<Keybuk> };
<Keybuk> ...dude, where is pc105 defined?
<daniels> Keybuk: /etc/X11/xkb/symbols/pc
<daniels> Keybuk: it includes pc104, which includes pc(basic), which has the F* definitions
<Keybuk> right
<Keybuk> those are just type="CTRL+ALT" though?
<lexhider> .
<daniels> Keybuk: right, that's fine
<Keybuk> Ctrl+Alt-F12 does nothing
<daniels> the only difference between our maps is that I have compose(ralt) and ctrl(nocaps) also
<Keybuk> weird
<daniels> Keybuk: you did --force-confmiss xkeyboard-config, right?
<Keybuk> to?
<Keybuk> I have xkeyboard-config installed
<daniels> Keybuk: right, but xlibs's postinst was sort of deleting a lot of xkeyboard-config's conffiles
<Keybuk> I noticed that
<daniels> Keybuk: so sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<Keybuk> nope, no luck
<Keybuk> will have a bit more of a debug later
<Keybuk> could still be gtk bug
<Keybuk> the fonts thing was, so I'm not ruling it out
<jammcq> daniels: no sign of the 'xprop' package you recommended that I install
<daniels> jammcq: oh, it's waiting for ftpmaster intervention; don't worry about it
<jammcq> k, thanks
<Burgundavia> somebody just posted a bug voting idea on the IdeaPool (to replace the page itself)
<|QuaD-> daniels: how do i get mkfontdir?
<daniels> |QuaD-: install xfonts-utils 6.8.2.1-2 when it hits the archive
<|QuaD-> daniels: ok, i hope that solves my problems
<|QuaD-> do you know when that will be?
<daniels> |QuaD-: when the UK wakes up
<daniels> |QuaD-: it's waiting on manual intervention
<|QuaD-> daniels: alright, thanks for all your help
<daniels> np
<Amaranth> daniels: ooh, we get mkfont* and update-font-dir back?
<sebest> what about adding this to the channel topic : " Over 5 lines? Pastebin: http://deadbeefbabe.org/paste" ?
<Amaranth> when the UK wakes up? they just went to bed :/
<daniels> Amaranth: update-fonts-dir never went away
<Amaranth> err
<Amaranth> then i wrote over the copy in breezy :P
<daniels> it's been in xfonts-utils for ever
<daniels> but in /usr/bin rather than /usr/X11R6/bin
<Amaranth> err, it was in /usr/sbin/ in hoary
<daniels> oh, cool
<jammcq> daniels: sorry to bother you, but the upgrade to breezy is done, but the keyboard doesn't work in X
<lamont> vim ftbfs... sigh
<daniels> jammcq: have you got xkbutils installed?
<jammcq> yepper
<daniels> jammcq: got xkeyboard-config installed?
<jammcq> yep
<daniels> jammcq: any output from setxkbmap -rules xorg -model pc104 -layout us?
<jammcq> well, I get 'Cannot open display 'default display', cuz X isn't running
<jammcq> daniels: btw, this is on a laptop, fresh install of hoary, then the upgrade to breezy. nothing would be lost, if I had to start over
<lamont> daniels: libcaca is it's fault, not xorg's, right?
<lamont> checking for X11/XKBlib.h... no
<lamont> configure: error: cannot find X11 development files
<daniels> lamont: libxkbfile-dev, IIRC
<lamont> woot
<daniels> yeah
<daniels> jammcq: if the server's not starting, I'd need the logfile.  if it's a custom config, you need to change /usr/X11R6/lib/X11/fonts to /usr/share/X11/fonts in xorg.conf.
<jammcq> nothing custom, other than I changed the Fontpath to point to my xfs, cuz mkfontdir wasn't there
<lamont> jammcq: that would be "custom"
<lamont> --> changed xconfig fie
<lamont> file
<jammcq> :)
<jammcq> point taken
<lamont> md5sum can't tell _what_ you changed.
<jammcq> ah
<Amaranth> dpkg-reconfigure should fix it
<jammcq> which pkg ?
<Amaranth> xserver-xorg
<Amaranth> it'll remake the xorg.conf file
<jammcq> but then it'll fail becuase of the fonts missing
<jammcq> http://www.McQuil.com/Xorg.0.log 
<lamont> daniels: XOpenDisplay lives where?
<lamont> nm
<lamont> configure:5201: checking for XOpenDisplay in -lX11
<lamont> configure:5231: gcc -o conftest -g -O2  -DOPTIMISE_SLANG_PALETTE=1  conftest.c -lX11 -lXt -L  >&5
<lamont> how very, um, interesting
* lamont decides that libcaca is, well, caca
<bddebian> hehe
<daniels> lamont: in libX11
<bddebian> Wasn't libcaca on MOTUToMerge?
<lamont> yeah - it includes that, but it gets kinda lost looking for libs...
<lamont> well, it's in _main_
<bddebian> That's strange
<daniels> jammcq: so your server is actually started ... why can't you run setxkbmap?
<jammcq> the keyboard isn't responding
<jammcq> via gdm, I can't login.  I turned off gdm, and run 'startx', and keyboard does nothing
<daniels> ah, ok
<daniels> try changing your driver to Driver "kbd"
<jammcq> it already is 'kbd'
<daniels> jammcq: so your keyboard is totally dead ... hm
<jammcq> well,   Ctrl-Alt-Backspace works
<daniels> interesting
<jammcq> yeah
<daniels> first I've heard of something like that
<daniels> if you can SSH in and run setxkbmap -rules xorg -model pc104 -layout us, against it, does that help
<jammcq> i'll try that now
<daniels> lamont: oh, I bet I know what the libcaca issue is
<daniels> lamont: it's including -L$xlibdir unconditionally
<daniels> but $xlibdir will be blank if they're in /usr/lib
<jammcq> daniels: ok, no output
<jammcq> I had to add '-ac' to the serverargs in startx
<daniels> jammcq: has your keyboard situation improved now?
<lamont> daniels: sounds about right
<jammcq> nope
<lamont> daniels: in any case, #13119
<daniels> jammcq: if not, two things to try -- first one, paste me the output of setxkbmap -print in /msg; secondly, try sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<daniels> lamont: yeah, I saw it go past
<jammcq> k
<mdz> tseng: new packages for universe are OK with me for most of the remainder of the release cycle
<jammcq> mdz: hey, i'm installing ltsp, based on your howto
<mdz> jammcq: thanks for taking the time to play with it
<jammcq> i shoulda done it sooner, but you know how it is
<mdz> very much so
<jammcq> mdz: got an error:
<jammcq>    Errors were encountered while processing:
<jammcq>   /var/cache/apt/archives/xlibs_6.8.2-43_all.deb
<jammcq> E: Sub-process /usr/bin/dpkg returned an error code (1)
<bddebian> \sh: My hero!
<\sh> hey bddebian 
<mdz> jammcq: that's a bug for daniels
<jammcq> daniels was already extremely helpful getting my hoary box upgraded to breezy
<mdz> jammcq: he'll need a full transcript of the upgrade in order to analyze it; it might be a bug he has already fixed in the version he'll upload tomorrow
<daniels> yeah, in this case it is
<jammcq> so, to re-start this tomorrow, do I just re-run the client-build ?
<daniels> (i often don't see things until this window bings purple)
<fabbione> morning
<fabbione> jammcq: yo :)
<fabbione> jammcq: i did add fuse to the kernel on your request. i hope the 2.3.0 version is ok with you
<sladen> scary fuse goodness
<fabbione> sladen: it's going upstream anyway
<sladen> fabbione: excellent
<pitti> Good morning
<Amaranth> morning
<bob2> hey pitti
<Burgundavia> morning
<sivang> morning all
<niran> is there any correlation between package names and launchpad product names?
<bob2> sadly, not in general
<bob2> source package names mostly match with lp names
<niran> but there's no foolproof way to get to the launchpad page for a package?
<Amaranth> from a source package, yes
<bob2> perhaps it's linked from soyuz
<bob2> we had to go back and match source package <-> lp names after the fact
<niran> ah, i see
<bob2> presumably someone made use of that mass of data ;)
<niran> i've been poking around trying to see what data i can use
<niran> but sadly, the only useful i can find i can't actually use because of a gtkmozembed bug
<niran> useful info, that is
<Amaranth> niran: working on gnome-app-install 2.0? :)
<niran> Amaranth, heh, yeah
<niran> Amaranth, i think it's pretty useful at this point
<pitti> Hey JaneW 
<sivang> pitti: Hi Martin, What's up?
<pitti> Hi sivang
<sivang> pitti: do you know how I can see changes of the last update to a baz archive? (baz annotate seems to give me everything)
<pitti> sivang: get-changeset and show-changeset?
<sivang> pitti: k, thanks
<pitti> sivang: or just a quick overview with logs?
<sivang> pitti: how do I produce the logs?
<pitti> sivang: baz logs -s
<sivang> pitti: cool, thanks :)
<Amaranth> niran: You're doing that in Python?
<niran> Amaranth, yeah
<Amaranth> niran: Cool.
<Amaranth> niran: Try not to make it as nasty as http://rafb.net/paste/results/PqVbpC62.html :)
<sivang> pitti: have you seen jamesh lately?
<pitti> no, I didn't
<niran> Amaranth, haha, i have a bit of cleanup to do myself. random unclear array indices will be heaven for anyone else who tries to touch this code
<Amaranth> hehe, i don't have lists, i have gtk.ListStores :)
<\sh> re
<JaneW> hi pitti
<highvolt1ge> morning JaneW 
<sivang> hey JaneW 
<JaneW> hello highvolt1ge  and sivang 
<\sh> morning JaneW 
<JaneW> hi \sh
<sivang> hey \sh , hungry this morning ? :)
<\sh> sivang: hehe :) yes, but I have to chocolate bread rolls on my desk :) and a nice cup of hot coffee :)
<ajmitch> hi
<sivang> \sh: lol, I don't want to start describing what I have here, as Burgundavia may get hungry at us :)
<\sh> sivang: lol..yes :) but Burgundavia has to provide me with some new .desktop files ,-) so he should be hungry for work not for food ;)
<Burgundavia> what is this about hunger? I could use some food right now
<Treenaks> Burgundavia: you know the rules: no fixed bugs, no breakfast
<Burgundavia> right
* Burgundavia predicts no breakfasts for a long time
<Treenaks> I would fix a lot of bugs, if I could have my upload rights back *sigh*
<Burgundavia> Treenaks, why did you get your upload privs yanked?
<Treenaks> Burgundavia: no idea..
<Burgundavia> ah
<Treenaks> Burgundavia: I mailed elmo last week, but got no reply
<Burgundavia> elmo is a busy guy
<Treenaks> yes
<Treenaks> but still :)
<sivang> Treenaks: maybe you should use a sponser , like I always do :)
<Treenaks> sivang: meh
<sivang> Treenaks: You had upload rights to main and universe?
<\sh> hmmm...just downloaded michael lynns presentatioin about the cisco exploit
<Treenaks> sivang: universe
* Treenaks sues \sh into hell and back
<\sh> quite interessting..but old..and for this he had so many troubles now?
<\sh> Treenaks: because of?
<Treenaks> \sh: reading illegal information ;)
<\sh> Treenaks: i don't see any illegal information in it..
<\sh> but I can read out of the court papers, that cisco has more security issues in their IOS (well, who doesn't know that) that they can handle ,-)
<\sh> hmmm...I think I will mirror this document and make it public
<pitti> Hey mvo
<mvo> good morning pitti 
<sivang> morning mvo, how are you today?
<mvo> sivang: morning! a bit tired, but otherwise fine :)
* mvo waves to seb128 
<\sh> ok...I just p*ssed cisco and iss of ,-)
<Burgundavia> \sh, mirror the lynn stuff?
<\sh> http://linux.blogweb.de/archives/70-Michael-Lynns-Presentation.html
<\sh> yepp
<doko__> elmo: please sync openoffice.org-help-de openoffice.org-help-el openoffice.org-help-en openoffice.org-help-es openoffice.org-help-fr openoffice.org-help-it openoffice.org-help-ja openoffice.org-help-ko openoffice.org-help-pt-br openoffice.org-help-sv openoffice.org-help-tr openoffice.org-help-zh-cn openoffice.org-help-zh-tw
<\sh> coffee...
<sivang> bon jour seb128 
<seb128> hi mvo sivang
<doko__> elmo: please sync pygresql python-gdchart
<pitti> Hi seb128 
<seb128> hey pitti
<doko__> elmo: please sync libsigc++-2.0 libsigc++-1.2
<sivang> JaneW: do you know if anyone is working on http://udu.wiki.ubuntu.com/FileManagerImprovement ?
<Amaranth> sivang: err, that's not needed anymore with the new nautilus, i thought
<Burgundavia> Amaranth, there are still some small things to be done
<seb128> a lot of small thing but not really a spec for that
<Burgundavia> I would like to see us simplfy the current UI for Breezy+1
<seb128> using spatial you mean ?
<sivang> seb128: ping me for those "small things" after FF , I may be interested in working on this some bits :)
<seb128> nautilus is not easy code
<seb128> better to work on gst maybe?
<Burgundavia> seb128, the thunar screenie, we are almost there
<sivang> Burgundavia: what is the rhunar screenie ?
<sivang> s/rhunar/thunar/
<Burgundavia> http://thunar.xfce.org/wiki/media/ui/suggestion-20050320/shortcuts_buttons.png
<sivang> seb128: in nautilus, the hard part is probably the plugins stuff?
<seb128> what plugin?
<seb128> this screenshoot is ugly
<sivang> seb128: no specific ones, I mean, becasue you can use it as a shell for other apps, etc..
<sivang> Burgundavia: what is this screenshot of?
<Burgundavia> sivang, a new file manager being worked on for XFCE
<sivang> Burgundavia: nice
<Burgundavia> jdub spotted it
<sivang> seb128: and you can have apps do nautilus integration
<sivang> seb128: (become part of nautilus)
<seb128> elmo: intltool gdesklets gdesklets-data loudmonth libgtk2-perl (experimental) syncs please
<seb128> sivang: no, you can't
<Burgundavia> seb128, don't you mean loudmouth ?
<seb128> Burgundavia: yep, typo
<Burgundavia> seb128, would you mind taking a quick look at screem. The new version in Debian fixes some crashers that myself and others I am seeing
<Burgundavia> s/I am/are
<seb128> Burgundavia: I'm too busy for that, it's blocked by UVF and I don't use it
<Burgundavia> seb128, ok
<seb128> but feel free to try the new version, list what it fixes and ping mdz with your rationnal
<Burgundavia> ok
<sivang> seb128: I see the evince patch has both the configure changes and the code in, would you like me to split this one up as well ? (as I'm doing this for file-roller)
<sivang> seb128: that is, the resulting auto-fo(s) and the directive that created them are split, but the code and the PKG_CHECK directive are in the same patch
<seb128> "has both the configure changes and the code in"?
<seb128> what does that mean?
<seb128> oh
<seb128> I explained to you the other day ...
<seb128> lemme me start again :(
<seb128> s/lemme/let/
<seb128> configure.in is not likely to change on every update
<seb128> configure is
<seb128> so there 1 one patch for the code/configure.ac changes and one for the autotools
<sivang> seb128: ah ok, now I get it right
<sivang> seb128: is there anything wrong in the way I ask you that causes you to answer me wrongly? I want to improve my question asking abilities :)
<seb128> you ask the same questions again and again
<seb128> I've explained already 2 times why I split the patches
<seb128> and we discussed that with pitti here too
<sivang> seb128: right :-(
<sivang> seb128: somehow I didn't get the fact the .in and the result were different things
<seb128> one is source file, the other is generated by the tools
<sivang> seb128: I know, but I deduced wrongly that the changes for those both go in one place, since when you said "autofo is likely to change" I automatically reasoned that for both .in and results
<sivang> seb128: ah well, at least now I will have final patche ready like needed.
<seb128> a source file is not likely to change if you don't modify it
<seb128> a generate file ...
<sivang> ok
<sivang> seb128: but acutally, when I think of it - if I didn't ask that question now (about the inclairity) I would have wasted another cycle of patch creation, so I'd like again to ask you to bare with this, and try give all the relevant info on the first time I ask you, please. (I wish I already knew all the autofu's cracks, but I do not)
<seb128> I try to reply to the question
<seb128> your patches change the configure.ac and the configure so I guessed you knew what you were changing and why
<pitti> daniels: ping
<sivang> seb128: I knew that I was changing the PKG_CHECK_MODULES directive in the source file and I knew this would trigger a change in the resulting output files, but when we talked about the "moving targets" I assumed that the source spec might change as well - how should I have reasoned otherwise? (I'm not bugging, just want to learn)
<seb128> the sources files changes too
<seb128> but less often than autogenerated file than are updated on every update
<sivang> seb128: so why not having 3 patches? one for the C code, 1 for the .in changes and one for the output, that would allows us maximum flexiability
<seb128> because 1 patch for the sourcecode and one for the generated code is enough
<seb128> you want to make a different patch by .c or .h maybe?
<seb128> there is a just middle between, that was the discussion with pitti friday
<pitti> sivang: splitting .in changes and C code changes does not make sense if they really belong together ("I want to add this feature")
<pitti> sivang: the point is not to split patches up to the smallest possible units, but to group them by feature or bug fix
<Amaranth> woo
<Amaranth> i got a GNOME CVS account for smeg
<sivang> pitti: ok
<pitti> mvo: http://changelogs.ubuntu.com/changelogs/pool/main/m/mozilla/mozilla_1.7.10-0ubuntu1/ is empty, any idea?
<mvo> pitti: no, but I can check
<pvanhoof> http://www.pvanhoof.be/informatics_is_like_music.php -- have fun
<mvo> pitti: I regenerate it now, it should be avalable in ~30min
<pitti> mvo: thanks
<sivang> pvanhoof: wow
<pvanhoof> yea, I'm crazy :)
<sivang> pvanhoof: no, I really like the bottom line
<sivang> pvanhoof: very good
<pvanhoof> thanks
<Amaranth> good night all
<sivang> night Amaranth 
<mvo> pitti: changelog should be available now
<pitti> mvo: yep, thanks
<Kamion> /srv/cdimage.no-name-yet.com/debian-cd/tools/boot/breezy/boot-i386: line 242: syntax error: unexpected end of file
<Kamion> oops
<chrissturm> is there a way to fix my keyboard config in X?
<Kamion> well, that explains why CD images haven't been building
<Kamion> Amaranth: the language packs / openoffice.org2 thing is for daily-live builds, not daily (i.e. install)
<Kamion> Treenaks: I don't get it. You're still in the universe upload keyring
<Kamion> cjwatson@jackass:~$ gpg --no-default-keyring --keyring /srv/keyring.no-name-yet.com/keyrings/upload-keys.gpg --list-keys | grep Martijn
<Kamion> pub  1024D/3FA5E031 2004-04-17 Martijn van de Streek <martijn@foodfight.org>
<Kamion> uid                            Marinus Theodorus Gerardus van de Streek (Martijn) <martijn@facecrime.net>
<Treenaks> Kamion: weird
<Treenaks> shall I try again?
<Kamion> Treenaks: what did you try to upload that failed?
<Treenaks> Kamion: lirc
<Kamion> Rejected: lirc_0.7.0.1-1ubuntu3_source.changes: upload is signed by 0x66EF84C6B7B551F4C18D5EF80DA7EFA33FA5E031 but is not in the Maintainer keyring.
<Kamion> Rejected: lirc_0.7.0.1-1ubuntu3.dsc: upload is signed by 0x66EF84C6B7B551F4C18D5EF80DA7EFA33FA5E031 but is not in the Maintainer keyring.
<Kamion> Treenaks: lirc source is in main, not universe
<Treenaks> Kamion: it is?
<Treenaks> Kamion: Section: universe/utils
<Kamion> Treenaks: source, not binary
<Treenaks> oh wait
<Treenaks> that explains a lot then :)
<Kamion> Treenaks: because liblircclient0 and liblircclient-dev are in main, so the source has to be in main
<Kamion> xine-lib build-deps on liblircclient-dev
<Treenaks> Well, it only needs a build-dep addition (libusb-dev)
<Kamion> can you mail me the diff?
<Treenaks> Kamion: sure
<Kamion> thanks
<pitti> Kamion: oh, that reminds me again of that everlasting discussion to demote xine-lib into universe...
<locomorto> hey
<Kamion> daniels: libfontenc promoted to main
<shackan> are there breezy backports yet ?
<bob2> *for* breezy?
<locomorto> if there was it would ahver nothing in it
<locomorto> have*
<shackan> bob2, for hoary ;)
<HiddenWolf> Why would you want backports for a release that isn't stable yet, much less outdated. :P
<azeem> HiddenWolf: upstream version freee
<azeem> freeze, even
<HiddenWolf> azeem: *sigh*
<HiddenWolf> Like you'll notice that. :P
<shackan> well, I need to update some packages but there are no new versions in hoary yet, I just hoped they were in breezy and someone backported to hoary
<chmj> hey shackan 
<shackan> charlie!
<chmj> oh good 
<chmj> wasn't sure it was you 
<pitti> shackan: Hi
<shackan> wow, everyone's here today...
<pitti> shackan: I got your mail, will answer soon; just a quick note, we have the latest hal, and will have the latest dbus (daniels works on that)
<shackan> hi pitti 
<shackan> GREAT
<shackan> pitti, I have 0.4.7, latest seems to be 0.5.4 or stg like that, where do I get it ? :)
<pitti> shackan: hal 0.5.3 is in breezy
<pitti> shackan: 0.4.7 is the hoary version
<shackan> ok, seems I'll have to upgrade ?
<pitti> erm, you *do* test your stuff on breezy, do you?
<pitti> yes, you need breezy for that stuff
<shackan> ok, I'll create a new partition later
<shackan> kitchen needs me, brb
<locomorto> will breezy be using the 2.6.12+ kernel? And thus udev?
<tseng> already done
<pitti> locomorto: we use udev since warty, and breezy has 2.6.12
<locomorto> really? My build complains that I dont have a 2.6.12 kernel
<shackan> pitti, use of breezy was discouraged, that's why I didn't get it yet
<chmj> shackan: it was too much broken then, I think 
<shackan> and now ?
<pitti> shackan: it is discouraged for users who want a stable system, but it is necessary for developers
<shackan> I see
<chmj> shackan: much better, all your stuff has to work on breezy 
<shackan> it will :)
<j^> who can i ping if i would like to see a cvs repos showing up at http://arch.ubuntu.com/?
<j^> in this case http://liboil.freedesktop.org/
<Kamion> j^: lifeless leads the import team
<pitti> Hi carstenh 
<carstenh> hi pitti 
<carstenh> pitti: i hope jeff is here this afternoon and he has time to talk about conffiles
<pitti> yes :-)
<JaneW> Mithrandir: are you the second for OOo2?
<doko> JaneW: that needs to be defined ...
<chmj> daniels, ping 
<JaneW> doko: I see his name is there, but I think I did that last week, just cos you said he was to complete required amd64 bits...
<JaneW> doko: I put your updated in the wiki btw
<JaneW> updates
<doko> JaneW: many thanks, maybe I should just install an alternative browser :)
<JaneW> doko: apparent;ly breezy solves the problem...? I know I had the same problem when I had flash installed.
<doko> I have no flash installed ...
<JaneW> doko: oic, then I have no idea
<siretart> fabbione: would you be interested in another sparc buildd? I a friend would like to offer hardware and hosting
<JaneW> does anyone have an e-mail address for jsgotangco?
<Treenaks> JaneW: PGP key A97B69A0, which lists jgotangco@gmail.com
<JaneW> Treenaks: cool, thanks :)
<sivang> seb128: I give you lp-integration for file-roller sacrifice oh might Seb god of gnome, I hope it is of your liking - http://muse.19inch.net/~sivan/lpint/file-roller/
<sivang> seb128: :)
<retrix> if anyone has some spare time and is interested in testing an ndiswrapper gui, my summer of code project is available at http://www.users.on.net/~spohlenz/ubuntu/
<retrix> could really do with some feedback :)
<jordi> pitti: ping
<pitti> Hey jordi 
<jordi> pitti: hi!
<sivang> yo jordi 
<jordi> how's alsa doing in breezy? Any problems reported?
<jordi> hi sivang 
<pitti> jordi: no major breakages so far :)
<jordi> pitti: I could build it for Debian now
<jordi> ok, uploading then :)
<elmo> doko: wtf is openoffice.org2-filter-so52?
<elmo> ajmitch: ?
<doko> elmo: staroffice 5.2 import filters
<elmo> doko: are they really binary files as the package description implies?
<doko> yes
<elmo> and you uploaded them for main?
<doko> elmo: good question, maybe let them stay in universe, it's not something we should support, but it's there
<elmo> dude, are you screwing with me, or do you have a different definition of binary?
<elmo> (as in without source)
<siretart> elmo: could you please pull piuparts from sid to universe?
<doko> elmo: sorry? the package contains shared libs, which are dlopened
<elmo> doko: is there source for these shared libs?
<elmo> (if so, where?)
<\sh> elmo: what do u need from me, to import my gpg key into the main keyring (TB approval since tuesday) thx for your info ;)
<doko> elmo: in openoffice.org2
<elmo> doko: why does the description call them binaries then?  and why are they split out?
<doko> elmo: they are split out, because they are big, and almost no one needs them, at least not linux users. AFAIK staroffice 5.2 was available on Windows only
<sivang> can anyone fire up evince tell me if he can use it's launchpad integrated items from the "Help" menu?
<sivang> (Seems to have a permission problem)
<doko> elmo: maybe the description can be better worded
<sivang> see if the browser if started at the launchapd url, thx
<elmo> siretart: done
<elmo> \sh: if you mailed your details to keyring that should be fine
<elmo> doko: please at least fix the "binary" stuff, it makes me want to run away screaming
<mjg59> elmo: Have you added my key to the keyring?
<pitti> Hi elmo
<siretart> thanks!
<doko> elmo: already, thought you wanted to stay until I did duplicate the oo2 source ;)
<doko> elmo: will fix
<whiprush> sivang: I have the launchpad stuff in my evince.
<doko> elmo: is there a way for a package (beeing built on a buildd) to know, if it should be binary-all packages as well?
<elmo> doko: no - and you really shouldn't need to know stuff like that
<doko> elmo: ok. did you get my mail about duplicating the ooo2 source package to build the language packs from one package, and the binaries from the other one?
<aigarius> retrix, just to nitpick on you packaging - Section: base seams a bit bold to me - net or gnome would propably be better. other that that it looks nice and simple. any other functionality planned?
<elmo> doko: oh, christ, that
<retrix> aigarius, thanks, still working on the packaging
<retrix> aigarius, still need to implement basic help, and automatically loading ndiswrapper -m
<retrix> aigarius, other than that, im keeping it simple
<aigarius> retrix, I'm in SoC too (http://udu.wiki.ubuntu.com/SimpleBackupSolution, http://freshmeat.net/projects/sbackup/ ). I still have lots to do this week :)
<retrix> aigarius, ah yes, i had a look at ur project before .. its coming along well
<seb128> elmo: intltool gdesklets gdesklets-data loudmouth libgtk2-perl (experimental) syncs please
<janimo> elmo, ping
<\sh> elmo: send
<pitti> re
<carstenh> hi pitti :)
<daniels> Kamion: thanks alot
<daniels> chmj: sup
<\sh> going home...later dudes
<chmj> daniels: dude 
<chmj> daniels: xorg is missing xmkmf 
<daniels> chmj: yeah, I know
<chmj> thats breaks isdnutils 
<Treenaks> isdnutils uses xmkmf?!
<chmj> something like that 
* chmj shrugs 
<bob2> ETOOMUCHCRACK
<aigarius> daniels, Setting up xfonts-base (6.8.2.1-2) ... 
<aigarius> mkfontscale: error while loading shared libraries: libfontenc.so.1: cannot open shared object file: No such file or directory
<daniels> FRIG
<daniels> aigarius: sudo apt-get install libfontenc1
<daniels> headdesk
<aigarius> daniels, just thought that you might want to know :)
<azeem> xisdnload uses imake
<chrissturm> should xkb work in current xorg?
<sivang> seb128: are you able to use evince's launchpad menu items? (I have problems testing it on my dchroot, wanna know if it happens to you)
<daniels> aig	thanks
<daniels> chris	yes
<seb128> sivang: all the stuff I've uploaded work fine here
<seb128> sivang: have you read my mail about file-roller?
<sivang> seb128: yes, already up to it, will be ready shortly
<seb128> k
<pitti> elmo: please sync pdns (new upstream microrelease, but fixes two CANs, and universe)
<sivang> seb128: then probably some missing python lib in my chroot
<seb128> sivang: what does it say?
<doko> pitti: do we have a policy, how the localte is determined?
<doko> does LANGUAGE or LC_ALL win?
<pitti> doko: in which context?
<pitti> doko: oh, LC_ALL wins
<mjg59> LC_ALL
<herzi> abiword and gedit don't appear in my gnome-menu anymore, it is the same with someone else's ubuntu breezy?
<herzi> s/it is/is it/
<pitti> doko: well, LANGUAGE is not an official gettext variable, but something Gnomeish
<pitti> doko: but to be similar to LANG, LC_ALL should dominate everything
<doko> hmm, and something like de_DE should be interpreted as well, or do we need de_DE.UTF-8
<pitti> doko: LANGUAGE should not contain an encoding
<pitti> doko: just "de_DE" or "de"
<pitti> as I said, it's not a gettext variable, but a Gnome h4ck
<doko> but LC_ALL=de_DE should work?
<sivang> seb128: Traceback (most recent call last):
<sivang>   File "<string>", line 5, in ?
<sivang>   File "/usr/local/share/launchpad-integration/launchpadintegration/main.py", line 57, in main
<sivang>     print 'Name:', pkginfo.binarypackage
<sivang> AttributeError: 'NoneType' object has no attribute 'binarypackage'
<doko> pitti: but LC_ALL=de_DE should work?
<pitti> doko: no, that needs an encoding (de_DE.UTF_8)
<pitti> doko: of course it works, but it describes the latin1 locale
<seb128> sivang: weird ... why don't you use the package?
<sivang> seb128: what do you mean?
<seb128> /usr/local
<seb128> that's not the package
<sivang> seb128: ah, when I tried using it from evince for exmaple, I got jamesh's error handeling message "Error showing url: There was an error launching the default action command associated with this location.
<sivang> "
<sivang> seb128: so I figured trying the python script directly
<martink> pitti, how come LANGUAGE is documented in the glibc manual if it's a GNOME h4ck? http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html#Using-gettextized-software
<pitti> martink: oops, sorry, seems that my memory has fooled me
<pitti> martink, doko: LANGUAGE is not documented in locale(7), the precedence rules don't mention LANGUAGE
<janimo> elmo, please sync xfce packages listed in mail sent last week on you nocrew address, thank you
<doko> pitti: I know, but LANGUAGE is the only thing, which is set by the installer, isn't it?
<pitti> martink: hm, even your URL doesn't define the precedence of LANGUAGE
<pitti> doko: no, d-i writes LANG into /etc/environment
<doko> pitti: my last installation did have written: LANGUAGE=en_DE:en
<pitti> doko: it didn't write LANG???
<doko> no
<pitti> my installations always did
<pitti> but I always installed de_DE...
<doko> well, will check later
<seb128> sivang: the url error is quite normal with a chroot
<seb128> sivang: gconftool-2 -g /desktop/gnome/url-handlers/http/command ?
<doko> pitti: en_DE is selected, when you select y german keyboard, and english language
<Kamion> doko: please file a bug (on, er, probably localechooser to start with), LANG should always be set
<pitti> doko: crazy... en_DE is not even a supported locale...
<Kamion> and keyboard REALLY shouldn't imply country choice!
<sivang> seb128: mozilla-firefox %s
<Kamion> if you selected English language and Germany as the country, that would make marginally more sense
<Kamion> although localechooser still shouldn't select it if it's unsupported, it's meant to fall back to a supported locale
<seb128> sivang: can you run that from your chroot?
<crispin> hmm, is it known that xmodmap doesn't seem to exist in breezy ?
<sivang> seb128: just found out I don't have it. /me apt-gets moz-ffox :-/
<doko> Kamion: maybe it was country, I have to check it with a newer install. bug report openend
<daniels> crispin: yes
<crispin> daniels: ok :-)
<HiddenWolf> daniels, what can I expect if I upgrade to breezy atm, lots of X pain?
<aigarius> infinity, ping
<sivang> seb128: that fixed that DOH
<sivang> seb128: anyway, the finalized file-roller is up , can you give it a look and let me know if I need change another thing?
<seb128> sure
* sivang crosses fingers
<daniels> HiddenWolf: largely works
<HiddenWolf> daniels: would you advise me to wait, or is it doable?
* mvo waves to ogra 
* ogra waves back to mvo and the room
<pitti> ogra: !
<pitti> nice to see you
<Keybuk> pitti: are we going to see the "name pmount/gvm devices according to HAL" patch back in for breezy?
<sivang> hi ogra 
<bddebian> Hello
<sivang> hey bddebian 
<bddebian> Heya sivang, how are you?
<pitti> Keybuk: what do you mean?
<pitti> Keybuk: I get /media/<partition label>, and "Computer place" shows "OTi Flash Disk: Pitti USB"
<pitti> Keybuk: doesn't work for you?
<Keybuk> nope, I get /media/usbdisk where I used to get /media/iAudio
<Keybuk> (when the patch was enabled during the hoary cycle)
<pitti> Keybuk: but the device label is in hal?
<pitti> Keybuk: I didn't disable anything like that in breezy
<Keybuk> plugging in my iAudio I get a "/media/usbdisk" which appears as "37.3GB Volume" in Computer
<daniels> HiddenWolf: entirely doable.  just remember to fix your font paths in xorg.conf.
<pitti> Keybuk: can you please send me your "lshal" output when the device is plugged in?
<Keybuk> sent
<ogra> fabbione, around ? 
<Keybuk> the volume appears under an "iAUDIO M3 Digital Audio Player" tree in h-d-m
<pitti> ogra: he's on vac this week
<ogra> pitti, ah.. i forgot...
<HiddenWolf> daniels: ok, cool
<ogra> daniels, any chance that we get ndiswrapper for amd64 in breezys l-r-m ? 
<pitti> Keybuk: hm, where did you send the mail to?
<bddebian> I thought with mad-wifi you didn't need ndiswrappter anymore?? ;-)
<pitti> Keybuk: whoops, it landed in my spam folder, sorry
<mjg59> bddebian: There are plenty of amd64 laptops with unsupported wireless cards
<Keybuk> http://descent.netsplit.com/~scott/lshal.txt
<mdz> morning all
<mdz> elmo: what happened with moin1.3?
<daniels> ogra: um, l-r-m doesn't do ndiswrapper; ndiswrapper is in a separate package.  it also happens to be entirely dfsg-free ...
<pitti> Hey mdz
<ogra> bddebian, does madwifi support all broadcom chipsets ? i had to use ndiswrapper here for my new card...
<elmo> mdz: how do you mean?
<daniels> elmo: if render and xrender source packages are still in breezy, please kill them
<mvo> good morning mdz 
<bddebian> I was kidding folks.. Sheesh, I really need to learn to shut-up
<tseng> Did you mean: midwife  
<bddebian> heh
<Keybuk> daniels: however the result of running ndiswrapper may be violating the GPL with a chainsaw ... depending on your interpretation of "compbined work"
<Keybuk> urgh, can't type
<daniels> Keybuk: right
<mjg59> Keybuk: There are GPLed NDIS drivers
<daniels> Keybuk: but as it stands, the program itself is fine.  what you do with your own drivers that you acquire and your kernel is up to you.
<daniels> Keybuk: as mjg59 says, the drivers you use may be entirely fine to use with the kernel.
<bddebian> Oh you mean like copying CDs?? :-)
<mdz> elmo: I mean that it was intended that it go into breezy, but it hasn't yet
<mdz> elmo: doko said that he uploaded it?  I don't know if those were the Jonas packages or something else
<martinhj> mjg59: concerning our talk about acpi-events on a travelmate 620 and me going to try a vanilla kernel: is 2.6.12.3 ok, or do I need to apply latest prepatch (or anything else)?
<mdz> (there was a discussion about it here on 07-26)
<daniels> bddebian: sure.  i've never burnt a CD or DVD that violated its copyright.
<mdz> daniels: do your most recent uploads clear out the known X installation/upgrade bugs, or are there still some pending?
<bddebian> daniels: Well that's YOU :-)
<elmo> mdz: if he did upload it, I don't think it was to ubuntu
<bddebian> elmo: Do whitelist requests for upload@ubuntu.com go to you?
<daniels> mdz: still one or two pending
<mdz> elmo: at any rate, would you make sure that moin1.3 gets into breezy?
<mjg59> martinhj: Try 2.6.12.3 plesae, yes
<daniels> mdz: almost all squashed though.  straight upgrades from hoary should be fine.
<mdz> daniels: and fresh installs as well?
<chrissturm> daniels: i have trouble with my xkb settings. cant set a german keyboard. what can i do to fix it?
<mdz> chrissturm: #ubuntu, please
<daniels> mdz: no, xlibs will fail to install.  i have the fix for that in hand.
<martinhj> mjg59: gcc4 is ok?
<mjg59> martinhj: I'd recommed 3.4
<martinhj> mjg59: ok, I'll trie that one
<Morgue> pitti: ping
<pitti> Hi Morgue 
<Morgue> hi, it's shackan here, sorry to bother you but.. I just installed breezy, it all a damn mess over here
<pitti> dear seb128, please make rhythmbox stop crashing when I umount my usb stick :-)
<seb128> pitti: try today's snapshot and put a backtrace to bugzilla if it crashes, thanks :)
<pitti> rhythmbox is already the newest version.
<seb128> 0801 ?
<pitti> anyway, just nagging :-)
<seb128> not sure if it has built yet
<pitti> 0.8.8cvs20050714-0ubuntu2
<pitti> seb128: yes, I try 0.8.1
<seb128> k, wait for today's one, I've uploaded like 1 hour ago
<pitti> erm, 0.8.10 then?
<seb128> 0.8.8cvs20050801
<pitti> ah, ok
<seb128> that's the date :p
<seb128> 0801 is today ;p
<Morgue> pitti, gnome does not event start, it this a known problem ?
<pitti> no idea
<pitti> Morgue: did you install colony 2 and upgraded?
<Morgue> installed colony 2 and stop
<Morgue> can't upgrade, since the network doesn't work yet :(
<pitti> what a mess...
<mdz> doko: ping re: moin1.3
<doko> mdz: should be in NEW
<mdz> doko: it is not, and I never saw it there
<robitaille> Morgue: Colony 2 was pretty broken for some users.  My gnome wasn't work at all either on it. Maybe install a more recent version Breezy since  a lot of changes have happens since Colony 2?  
<doko> mdz: ahh, I see my mistake
<mdz> doko: are we talking about the same packages (the ones that elmo used for wiki.ubuntu.com)?
<doko> mdz: probably not. I did use the package from unstable, and packaged that as source moin1.3
<doko> elmo: where can I find your moin1.3 package?
* Mez yawns
<Mez> hey all :D
<Treenaks> hey mez
* Mez tries and sees if Breezy is working yet
<pitti> Hi Mez 
<Mez> evening Pitti
<Mez> hows things?
<pitti> reasonably, thanks :-)
<Mez> reasonably ?
<HiddenWolf> Guys, I've got a nautilus that's leaking memory. How do I figure out what's causing it so I can file a bug?
<pitti> Mez: moz 1.7.11 has a broken upstream tarball, but otherwise fine :-)
<Mez> pitti :D fun
<pitti> Mez: they claimed they only fixed two major bugs and nothing else, and then they removed a whole source code subdirectory
<pitti> elmo: can I please have libart-dev in concordia's breezy dchroot?
<sivang> seb128: what's the verdict for my file-roller ? :)
<elmo> pitti: done
<pitti> thaks
<seb128> sivang: uploaded
<seb128> elmo: thanks for the syncs
<sivang> seb128: yay!
<seb128> mdz: could we update libexif to 0.6.12? There is a soname change, but only main Depends are "gimp gthumb libgphoto2 nautilus". Debian has it for 2 weeks with no new bug. eog requires >= 0.6.12 now, it's built without exif for the moment but that would be nice to build it with it.
<mdz> seb128: ok, CC me on the sync request as usual
<seb128> mdz: k, thanks
<mdz> Riddell: regarding qca-tls, there is currently nothing (seed or dependency) to bring it into main
<mdz> ogra: likewise for tuxpaint
<ogra> mdz, ok
<mdz> at least nothing that anastacia sees
<mdz> is anastacia looking at the edubuntu seeds these days?
<ogra> mdz, http://www.grawert.net/ldm.png
<ogra> i guess not yet...
<mdz> ogra: you guess?  did you talk to anyone about it (such as elmo)?
<Mez> hmm
* Mez pokes daniels 
<ogra> mdz, nope, else i wouldnt guess :)
<bddebian> heh
<mdz> ogra: very nice, re: ldm!  what branch do I merge to get that into ltsp? ;-)
<ogra> mdz, its currently only glade stuff... i'll send you a complete patch as soon as i have a working X setup for any of my ltsp boxes over here... cant test currently
<ogra> (and yes, i saw the hint... i'll set up a ltsp branch for myself soon ;) )
<Mez> hmm
<Mez> xfonts-core not fixed yet?
<ogra> daniels, what about xlibs ? did you upload the fixed -43 ? i need it for ltsp testing...
<seb128> sivang: when will gedit be ready for upload?
<sivang> seb128: I need to talk with jamesh about it, either I create functions inside the helper lib to provide me with bonnobu ui action group, or I have to patch each bonnobu ui app in away that would require seperate translation of it's launchpad items per each bonnobu ui app - I'd like to hear his oppinion before going furhter with bonnobo ui apps, in the meanwhile I will continue preparing you glade / UIManager / manual apps 
<doko> seb128: when will you build cairo using glitz?
<sivang> seb128: what do you think, is bonnobo ui so deprected that we can just do local patches and drop them when its obsolete ?
<sivang> mdz: what's ldm ?
<seb128> doko: when elmo will sync glitz from Debian as said the other day
<seb128> elmo: glitz sync please
<seb128> sivang: that's an option
<seb128> sivang: but you have already patched it, no? what method did you use?
<ogra> sivang, ltsp display manager
<seb128> doko: why do you need glitz for?
<sivang> ogra: thx
<ogra> sivang, the gdm for cool guys ;)
<sivang> ogra: hehe :) nice
<doko> seb128: OOo2
<elmo> seb128: done
<seb128> elmo: thanks
<sivang> seb128: I used local patching ofcourse, however , before going to finish with the other bonnobo ui apps, I realized that whenever we change the launchapd names for actions , or change the laying of the actions (as we can change centrally in ui manager / glade) we would have to redo all the patches per all the patches apps
<sivang> s/patches/patched/
<seb128> have you talked with jamesh about that?
<sivang> seb128: not yet, have emailed him about it, still got no reply
<seb128> k
<sivang> seb128: I think we need at least have function in the helper lib to give us the actions text, so we would be able to control it form the lib
<sivang> seb128: that would save the translation overhead greatly
<lamont__> doko: ping
<seb128> right
<doko> lamont__: pong
<mdz> daniels: setxkbmap seems to still be unusable for me with the latest breezy
<mdz> Error loading new keyboard description
<mdz> daniels: hmm, not entirely, but 'setxkbmap dvorak' certainly fails, though 'setxkbmap us' works
<mdz> daniels: how can I debug this?
<Mez> hmm :D
<Mez> OOo2 = broken
<ogra> Mez, bah, who uses that... 
<Mez> ogra, it's a dependency of ubuntu-desktop
<ogra> Mez, first they should make it compilable on the superior arches ;)
<ogra> i.e. amd64 ;)
<mdz> it does compile; it just doesn't work properly
<Mez> ogra: be nice if you could install breezy :D
<Mez> mdz: it depends on a package that is not installable
<ogra> mdz, oh ? thats new to me...
<Mez>   openoffice.org2-base: Depends: libhsqldb-java (>= 1.8.0.0-2) but it is not installable
<ogra> thats lame
<Mez> ?
<ogra> only a dependency breakage...
<Mez> yeah
<Mez> but that dep breakage breaks the whole breezy install :D
<Kamion> it hasn't been promoted to main yet
<Kamion> it isn't in anastacia's promotion list yet either; I assume it's new
* Mez enables ubiverse on breezy and trues again
<carstenh> pitti,jbailey: ping
<jbailey> carstenh: pong!
<jasoncohen> pitti, thanks for getting the thunderbird update
<carstenh> hi jbailey 
<carstenh> jbailey: we need to talk about conffiles...
<jbailey> Mmm..  chewy chewy conffiles.
<sivang> lol
<zul> hmmm/
<carstenh> jbailey: let's wait until pitti pongs :)
<jbailey> carstenh: No problem.  I'm not running out of other things to do. =)
<carstenh> jbailey: he seems not to be here atm. he told me in a mail you also got, that he'd like to see /etc/default/firewall as a conffile. if a package disables it using firewallconfig --disable and so changes this file, would it be policy-conform?
<carstenh> jbailey: i guess it is not a conffile it will be policy-conform
<jbailey> If that's all that's in it, I'd rather it not be marked as a conffile, snice if the user disables it, it's then easy to accidentally say "Overwrite my changes" at a package upgrade and find yourself locked out.
<jbailey> I'm curious why pitti thinks it ought to be.
<jbailey> carstenh: Did you see Matt's email reply as well?
<carstenh> jbailey: not yet, wait a minute
<jp> jbailey, nice to see evo without 'the bug'
<jp> heh
<mdz> Riddell: now that we have the -backports infrastructure, is there any reason you couldn't use that for your KDE backports?
<Mez> mdz: I've already suggested that
<Mez> we just didnt know whether the KDE stuff would be beyond the wall eyt
<mdz> Mez: and?
<mdz> wall?
<carstenh> jbailey: yes, i just read it. i will reply as soon as i know what is possible according to the policy
<Mez> as far as I know - there are differences between the breezy and the hoary backproted versions that cant be incorporated into them both.
<Mez> so breezy needs to be changed before it'll build on hoary :D
<Mez> aka ... direct upload needed to backport it
<Mez> I havent tried myself yet though... but That's what riddell said to me
<carstenh> jbailey: what about /etc/firewall/conf, they need to change it using firewallconf too. should it be a conffile?
<carstenh> jbailey: or should i create it in postinst?
<carstenh> jbailey: and more important, is it allowed to change it for them using a script?
<mdz> Riddell: I'm interested in the details
<carstenh> jbailey: s/a script/a script provided by our package/
<jbailey> jp: Ah, is it fixed in the uploads seb did on the weekend?
<Mez> mdz, lemme see if I can find the logs
<jp> jbailey it's was fixed on 2.3.5 release
<carstenh> jbailey: i have to buy something to eat now. i will be back in 20 minutes
<jbailey> carstenh: I don't like how easy it is to accidentally wipe out a configuration file with conffile handling.  I get nervous at the idea of suddenly having a pile of firewall policy wiped because the sysadmin got asked a question (s)he didn't understand.
<carstenh> jbailey: so i should create it in postinst and update it in portinst if nessessary and not mark it as conffile
<carstenh> jbailey: back in 20 minutes...
<jbailey> carstenh: That's what I think, but if pitti thinks otherwise, I'd be interested in hearing why.
<ogra> elmo, can you sync bum from sid please
<ogra> (if you havent already)
<Mez> mdz: they're proving elusive - but I'll keep trying
<Mez> mdz: it's because of the HAL stuff in oary being different than in Breezy - Riddell had to write a patch for HAL to work in KDE with breezy; with the patch it wont work in hoary, without it, it wont work in breezy
<Mez> I'm just emailing you logs
<drac> Ubuntu users with ATi cards seem to get restricted-modules-$(uname -r) installed by default and fglrx kernel module (version 8.8.25) from that package gets automatically loaded. This a) Causes troubles for people trying to install new drivers. b) Taints kernel by default, thus making it impossible to write any bugreports of kernel. Is this going to be fixed in Breezy ?
<Amaranth> You're not supposed to file bug reports upstream. :P
<drac> Or is it intended to be this way?
<Treenaks> drac: "new drivers" should only be used from packages
<Treenaks> drac: and you can file the bugs in ubuntu just fine
<Amaranth> Aye, it's a ease-of-use thing.
<mdz> Mez: sounds like it could be addressed with an autoconf test
<mdz> drac: the module is installed by default, but should not be loaded by default
<jasoncohen> drac, most users don't need a newer version of the driver- so it's easier if the kernel module is pre-installed
<mdz> it isn't on my ATI-based systems
<Mez> mdz: well I've emailed you the logs, and I've CC'd Riddell
<jasoncohen> it's only loaded if you use driver fglrx in xorg.conf
<jasoncohen> the default is ati
<drac> mdz, jasoncohen: So I should file bugreport about.. it getting automatically loaded?
<jasoncohen> drac, well, what driver are you using in xorg.conf?
<drac> jasoncohen: radeon
<jasoncohen> then- yes, it shouldn't be loaded
<jasoncohen> lsmod | grep fglrx shows it loaded?
<Mez> mdz: know when the backports buildds are going to be fixed: cause its still trying to build seahorse and firefox (after about a week)
<drac> yes
<mdz> drac: check /etc/default/hotplug (IGNORE_PCI_CLASS_DISPLAY) and /etc/modules first
<mdz> Mez: what led you to the conclusion that the buildds are at fault?
<mdz> Mez: hmm, gcc-4.0.gcc-opt.  I see
<mdz> Mez: this looks to me like simply a bug in the firefox package
<mdz> this has nothing to do with the buildds
<marcin> jbailey: ping
<jbailey> marcin: pong
<marcin> jbailey: hi
<marcin> jbailey: so, what about this CalendarSynchronization goal?
<carstenh> jbailey: changing out configuration-files using scripts is allowed, at least when they are not markes as conffiles, right?
<carstenh> s/out/our/
<jbailey> marcin: You're right that I got confused between the caldav stuff and the ical publishing for evolution and that it's not done upstream yet.
<siretart> jbailey: both? or just one of them?
<bddebian> Hello sabdfl
<siretart> hi mark!
<highvoltage> hi sabdfl
<sabdfl> hey guys
<jbailey> carstenh: http://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html only mentions the maintainer scripts, but I'm more worried about dpkg asking whether or not the defatuls should be okay, and having someone suddenly make their system unusable.
<jbailey> siretart: I don't think caldav is really on evolution's radar yet, even.
<mjg59> jbailey: Hi
<jbailey> siretart: The spec we did at udu basically said "Better iCal is coming, caldav is the right thing and isn't anywhere near existing yet.  Let's try again after breezy releases"
<siretart> :(
<ogra> hey sabdfl 
<whiprush> the status for caldav in their wiki is "Being worked on".
<sabdfl> ogra!
<whiprush> sabdfl!
<jbailey> whiprush: I suspect it's on a branch then, I don't see a mention of it in the changelog.
<siretart> jbailey: so the only possibilty for syncronizing calendars in evolution is using the exchange plugin with a groupware like opengroupware, did I get that right?
<whiprush> jbailey: yeah, definately post gnome 2.12
<mjg59> siretart: Or multisync
<ogra> sabdfl, i had several discussions with thesaltydog since some months... i thought i was clear when i told him we'd sync bum from debian...
<siretart> mjg59: ah, right. thanks 
<jbailey> siretart: Right, and a random reading of google hits seems to make it look like multisync does an adequate job at least.
<carstenh> jbailey: as far as i understand it it would be ok if none of our configfiles is marked as conffile. i don't like them to be conffiles, but i'd like to hear pittis opinion about that too
<ogra> sabdfl, it just hadnt happened yet because MOTU land is very busy merging and transitioning :) but we normally dont loose stuff from our lists :)
<jbailey> carstenh: Cool.  Does this block you from continuing on other bits?
<carstenh> jbailey: and not marking tham as such dpkg would not ask :)
<carstenh> jbailey: i only need to know if it is allowed to go this way
<Mez> mdz: what led me to believe it was that infinity said it had kept being given back to the buildd ...
<bddebian> Bah, where's tseng when I need him? :-)
<Mez> mdz: I sent elmo an email and asked him to kill firefox from the buildd... cause it was requested before the new FF release for hoary
<mdz> Mez: a crucial step when diagnosing any build problem is to read the log of the build
<Mez> mdz: I didnt see any log
<mdz> you can't infer much from the status
<mdz> Mez: where did you look?
<Mez> I was just looking at http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary-backports.all.i386
<mdz> it's been there since 26 July
<carstenh> jbailey: and before i create a package it should be clear if it would be a conffile, since i have to support upgrades
<Mez> I assumed as it was in the state "Building" there wouldnt be any log
<mdz> http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.0.6-1ubuntu1~hoary1/
<mdz> Mez: always look for a log; you can find them by browsing http://people.ubuntu.com/~lamont/buildLogs/
<Mez> ah fair enough... I would have expected it to be set to "faileD" in the List though
<Kamion> packages go back into Building when they're being rebuilt
<Kamion> retried, rather
<Kamion> if something is in Building that doesn't mean it wasn't tried before
* Mez didnt know that
<Mez> but, firefox still needs to be killed
<Amaranth> yeah, those silly things just keep trying
<Mez> it doesnt need to be backported anymore
<lamont__> Mez: Building rarely means currently-building.  Usually it means "failed"
<Mez> lamont, fair enough- what about "Needs-Build"
<lamont__> needs-build means that it will be tried (again?) soon.  It's also possible that it's already building, since the state files are synced over every 20 minutes or so
<lamont__> after it finishes trying to build (state==Building), and fails, then (possibly with manual intervention), it moves into Needs-Build, Dep-Wait, Failed, or Uploaded.
<Mez> lamont - 7 pacxkages have been Needs-Build for the past week or so in backports, and ff/seahorse have been building
<lamont__> interesting
* lamont__ loks
<lamont__> looks, even
<Mez> I assumed that because it was that state, it had been broken
<marcin> jbailey: So, do you expect some work on ical implementation?
<Mez> I did poke infinity :D
<mdz> lamont__: wasn't someone in Debian working on a "how to interpret buildd results" document?
<marcin> siretart: afaik multisync is corrently out of date and doesn't work with current evo release
<Mez> mdz: so even though http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary-backports.all.i386 has been like that for 6/7 days - it's how it's meant to be
<lamont__> mdz: could be... I'll poke around
<siretart> marcin: you mean in universe or doesn't even multisync upstream have a fixed version?
<mdz> lamont__: I think maybe vorlon
<lamont__> Mez: well, at 6-7 days, either all the buildd's are ignoring the packages... there are various reasons that could be...
<lamont__> which is what I mean to determine
<mdz> lamont__: yeah, it was vorlon
* Mez will brb
<Mez> (hopefully)
<mdz> but I think it may be stalled.  something like that would be very nice to have, though
<lamont__> ah... unknown universe packages.
<lamont__> elmo: hoary-backports has some unknown source that needs to be {un,mult}iverse
<lamont__> Mez: those packages are staying in Needs-Build, but you should see build logs for them approx every 30 minutes...
<lamont__> they'll be the spam that's in ~lamont/buildLogs/byDate/today.html
<lamont__> unknown maps to 'main', and those packages aren't in main.  So the build fails because it can't find source for the package.  And then we retry it.
<lamont__> actually, I think those are once every 8 hours
<lamont__> not 30 minutes
<lamont__> mdz: I'll poke vorlon
<marcin> siretart: I know that in hoary multisync and evo from packages doesn't work together
<marcin> siretart: but I also know that multisync package is with latest version available
<lamont__> mdz: looks like maybe a bit of scope-mismatch with vorlon's doc.
* lamont__ adds to his todo
<mdz> maybe I misinterpreted his goal
<mdke> elmo, has henrik spoken to you about pointing a domain at the docteam linode server?
<tseng> bddebian: ?
<bddebian> tseng: Never mind we got it thanks
<tseng> bddebian: ok.
* netjoined: irc.freenode.net -> zelazny.freenode.net
<mjg59> Hmm. My X has stopped starting.
<bddebian> stopped starting?  Heh
<mjg59> Dantis: Please to be fixing libvgahw kthxbye?
<mjg59> Argh.
<mjg59> daniels: Please to be fixing libvgahw
<mjg59> ogra: Ping?
<ogra> mjg59, pong
<highvoltage> ogra: syn
<mjg59> ogra: Hi - I'm playing with gnome-power-manager
<ogra> mjg59, cvs version ?
<mjg59> ogra: Breezy version
<ogra> mjg59, drop that
<mjg59> ogra: Ok. Have you got packages anywhere?
<ogra> mjg59, i'll package the cvs version as soon as the new dbus from daniels is there
<mjg59> ogra: Ok
<ogra> there changed a lot between the current packages and cvs
<mjg59> ogra: Main thing was that it, uh, doesn't actually seem to do anything when you ask it to suspend
<mjg59> Is that fixed? :)
<ogra> mjg59, yep
<ogra> lol, sure
<mjg59> I think the UI needs some work, too
<ogra> mjg59, hughsie is quite often around here now... i think we can address all our concerns directly to get it fixed upstream ;)
<mjg59> Other than that, it seems promising
<ogra> the ui already got some work... bt i havent seen it yet ... without dbusits pretty useless... it uses the new functionallity in dbus extensively
<mjg59> Ok
<mjg59> ogra: Best thing to do for us is to have it configured to call gdm-signal
<ogra> in the scripts/gconf settings ?
<mjg59> Yup
<jasoncohen> pitti, why does http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html show CVE's for php4 that are security issues in mozilla/firefox- not php4? 
<pitti> jasoncohen: as I already said, that was a changelog typo
<pitti> jasoncohen: currently a php upgrade is in progress, we'll fix the changelogs with it
<jasoncohen> pitti, sorry, my mistake
<pitti> jasoncohen: no worries :)
<pitti> jasoncohen: I cleaned up the lists a bit today and did some small updates
<pitti> jbailey, carstenh: I'm back
<carstenh> wb pitti :)
<jasoncohen> pitti, did you do the gzip, unzip and mozilla-thunderbird updates all this weekend?
<pitti> jasoncohen: I did the first two today, infinity did tbird
<jasoncohen> ah
<pitti> jasoncohen: I'm currently fighting with mozilla 1.7.11 again :-/
<carstenh> pitti: did you read our discussion or should i summarize it?
<pitti> carstenh: I didn't read scrollback yet, I just arrived
<pitti> carstenh: are there any outstanding things?
<jasoncohen> pitti, i thought 1.7.10 was the latest. the download on http://www.mozilla.org/products/mozilla1.x/ is 1.7.10
<carstenh> pitti: you said in your mail that you'd like to see /etc/default/firewall as a conffile. do you have any reasons for that?
<jasoncohen> pitti, is 1.7.11 in the works?
<carstenh> pitti: we also think /etc/firewall/conf should -not- be a conffile
<pitti> jasoncohen: no, it's released, it fixes two regressions in mailnews
<pitti> jasoncohen: unfortunately they also ripped out a complete library, so it doesn't build ATM
<jasoncohen> pitti, weird...mozilla hasn't updated their site yet to reflect the new release
<pitti> carstenh: no, the initial profiles should be conffiles, /etc/default/ubuntu-firewall (!, not /e/d/firewall) can be a normal configuration file
<pitti> jasoncohen: I saw the annoucement on full-disclosure or bugtraq
<carstenh> pitti: what about /etc/firewall/conf?
<pitti> carstenh: small files for enabling/disabling which are acually _supposed_ to be changed should be in /etc/default
<pitti> carstenh: i. e. /etc/default/<packagename>
<jasoncohen> found mention of 1.7.11 on mozillazine - http://www.mozillazine.org/talkback.html?article=7019
<carstenh> pitti: sure, but the assignment of profiles to interfaces is done in /etc/firewall/conf
<pitti> carstenh: that sounds fine
<carstenh> pitti: and if dpkg asks a user after ltsp has changed this file to add masquerading if the new config-file should be used he may render his system unusable or at least not work as he expect
<pitti> carstenh: but the profiles itself are stored in a directory?
<carstenh> pitti: sure
<pitti> carstenh: please don't ever try to mangle any but the most trivial config files with maintainer scripts, that will break
<pitti> carstenh: that's why I would rather see some conf.d/-style directories where packages can drop policies in
<carstenh> pitti: and the profiles accept-installed and accept-all are not planned as files, this are internal profiles
<pitti> carstenh: hm, why not make them explicit?
<carstenh> pitti: good question :)
<pitti> carstenh: hardcoding such things is neither elegant nor a good design
<pitti> carstenh: so a good packaging would make it possible to only drop an additional conffile in a conf.d/ directory and change policy with that
<carstenh> pitti: ok, then i will remove these internal profiles and move them to its directory :)
<pitti> carstenh: as soon as you start to write wild constructs with grep and sed into your maintainer scripts, then there will always be one special case where it breaks
<carstenh> pitti: /lastlog worried
<jasoncohen> pitti, i see that the changelogs of firefox & thunderbird now include both the MFSA's and CVE's- very nice
<carstenh> pitti: do you prefer making this case possible and therefor make postint easier?
<pitti> carstenh: "this case" == ?
<carstenh> pitti: see query :)
<jasoncohen> pitti, any chance of seeing MFSA's and CVEs in the USNs?
<carstenh> i.e. after ltsp has added masquerading
<pitti> jasoncohen: well, having them in the changelogs is fine, but MFSAs are just a special case, so I wouldn't like to include them
<pitti> jasoncohen: otherwise folks start to demand Redhat bug numbers and bugtraq ID, too
<pitti> jasoncohen: why do you think they would be important?
<pkern> CVEs should be enough.
<jasoncohen> i guess now it's kind of trivial. I thought it was important before because when i would check the USNs against the MFSA's on mozilla's site it was difficult to know what was patched and what wasn't
<jasoncohen> now that you're using the new upstream release, i guess it's irrelevant
<jasoncohen> pitti, why is it ok to include it in the changelog but not the USNs?
<pitti> jasoncohen: I think the USNs should have a very standardized format
<pitti> jasoncohen: OTOH, linking to more references like upstream patches or numbers is fine for a changelog, which is more developer oriented and package specific
<jasoncohen> ah, i see
<jasoncohen> i didn't realize that
<pitti> well, there is certainly no sharp boundary
<pitti> it just became common practice of me
<jasoncohen> pitti, ...also, why do some packages receive updates in hoary-security that say "increment version number for hoary-security" if the version was already upped for the security update?
<jasoncohen> like gzip went from 1.3.5-9ubuntu3.2 to 1.3.5-9ubuntu3.3 and it was upped once again to 3.4 for no apparent reason
<pitti> jasoncohen: that's a rather bad workaround for having exactly the same version in two releases
<pitti> jasoncohen: I was told to not upload the same version into multiple releaes
<pitti> jasoncohen: so I uplooaded 3.3 into warty-security and 3.4 into hoary-security
<jasoncohen> ah, got it
<pitti> jasoncohen: I think the solution we found for mozilla (0ubuntu04.10 and 05.04) is slightly better, although the numbers look worse
<jasoncohen> why does it matter if the version is the same in two releases? 
<jasoncohen> oh, because everything is in the same pool directory- so you want to keep them independent?
<jasoncohen> pitti, yeah- i was wondering about the 4.10 and 5.04 numbering scheme but it seems to make more sense
<pitti> jasoncohen: compared to naming it 0warty1 and 0hoary1 it always has the correct order, whereas 0warty1 is newer than 0hoary1
<jasoncohen> yeah, makes sense
<jasoncohen> why can't you skip versions - say form 1.35-9ubuntu3.2 to 1.35-9ubuntu3.4 so you wouldn't need a changelog entry just for incrementing
<mdz> pitti: are we affected by 	CAN-2005-1268 or CAN-2005-2088?
<jasoncohen> pitti, sorry for asking all these questions. i'm just wondering how it works
<pitti> mdz: I didn't check the apache thing (2088) yet, still busy with other security updates
<pitti> mdz: what is 2088?
<pitti> erm, what is 1268?
<mdz> pitti: 1268 off-by-one overflow in apache2
<trygvebw> hoho
<trygvebw> what is the meaning of "x is a lot less broken"? does it work, or is it near working?
<jasoncohen> pitti, http://www.xatrix.org/advisory.php?s=6654
<pitti> jasoncohen: thanks
<jasoncohen> np
<pitti> ok, good night guys
<jasoncohen> goodnight
<dholbach> infinity, elmo: could somebody of you sync baobab from unstable?
* dholbach adds a  please  somewhere in between :)
<ogra> mdz, ping, if you have a second, /join #edubuntu
<dholbach> i'm off again... see you soon
<jp> bye!
<Keybuk> meh @ nautilus
<Keybuk> it's putting folders on my desktop in the top-left, not where I drop them/click the menu to make them
<jasoncohen> i have a question about the hoary release notes. It says that in order to upgrade from warty to hoary using apt you should change "deb http://archive.ubuntu.com/ubuntu/ warty main restricted" to "deb http://archive.ubuntu.com/ubuntu/ hoary main restricted" in /etc/apt/sources.list. Won't this however leave the user with warty-updates and warty-security? Even worse, if the user enabled universe and multiverse from warty, h
<jasoncohen> e now has a half warty & half hoar system. 
<dholbach> jasoncohen: it's the usual setup a user has, but you're right, it should be more explicit
<jasoncohen> dholbach, warty-security and warty-updates weren't enabled by default?
<dholbach> erm, well they should
<jasoncohen> hmm...
<doko> mdz, Kamion, elmo: please promote libsigc++-1.2-5c2 to main (replacing libsigc++-1.2-5), synced from Debian
<Amaranth> warty-updates didn't exist
<mdz> Amaranth: eh?
<jasoncohen> Amaranth, was warty-security enabled? i can't seem to find an original warty sources.list
<jasoncohen> gods...ubuntuguide or warty recommended using marillat. what crap
<Amaranth> ubuntuguide, yeah
<jasoncohen> 95% of the time a user can't install some software i find it's because they have a marillat source
<Amaranth> yep
<jasoncohen> found an original sources.list - http://ubuntuforums.org/archive/index.php/t-3916.html
<jasoncohen> i still don't understand why the release notes wouldn't ask the user to change warty-security to hoary-security. 
<mdke> jasoncohen, perhaps the release notes have a bug
<mdke> nobody is perfect
<jasoncohen> mdke, who would i contact about changing it? it's pretty important that users get security updates
<mdke> jasoncohen, file a bug
<dholbach> good night
<azeem> was gnat-4.0 (libgnat-4.0.so, specifically) broken in hoary?
<azeem> it's a broken symlink here
<Mez> mdz: ping
<mdz> doko: you mean 'accept from new', rather than 'promote to main', right?
<mdz> Mez: yes?
<Mez> mdz: Riddell's here now, you can talk to both of us regarding backporting KDE
<Mez>  :d
<ajmitch> morning
<mdz> Mez: I already followed up via email
<Mez> oh, did you?
<mdz> is there something new to discuss?
<mdz> about 2 minutes after I received it
<Mez> ah
* Mez didnt see that
<ogra> doko, according to the recent map on www.redhat.com you and pitti still live in the gdr :) http://www.redhat.com/g/promos/second_intelvid_050726.png
<Riddell> Mez, mdz: it should all be possible, just a case of fiddling with build-deps
<Mez> Riddell, I dont mind that, as I just saidm ut is there any chance you can provide your source packages from your hoary build, or debdiffs from the both of them?
<Riddell> Mez: they're all there
<Mez> nvm, just saw your reply :d
<doko> mdz: yes,  'accept from new', then it lands in universe, then promote it to main
<doko> ogra: apparently the resolution is to low to show the cow barn, where you live ;-)
<ogra> but someone should tell them that their marketing lives 16 years in the past ;)
<Mez> lamont, did you uncover anything on the buildd's regarding backport
<Amaranth> ogra: Someone pulled a bad stock image out, it happens.
<ogra> Amaranth, yep.. 
<Amaranth> anyone else having fonts go all funny in firefox?
<Amaranth> like too small, then bold, then too large and bold
<lamont__> Mez: yes... and I rambled on about it about 10 lines after I said I'd check.
<Amaranth> hmm, maybe it's just slashdot
<mxpxpod> Amaranth: my app fonts are messed up in firefox
<lamont__> unknown/ packages in Lists/* are presumed to be in main.  if they're in any other component, they won't build until the archive is fixed.
<lamont__> and that's an elmo thing
<Mez> ah ...
<Mez> so, is it all fixed?
<mxpxpod> Amaranth: but we've already talked about that :)
<elmo> lamont: no, it's not, unless you tell me about it
<lamont__> I doubt it... unless someone has gotten an ack from elmo... See http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary-backports.all.i386
<Mez> elmo, I sent you an email about it ... :D and I think infinity did too 
<lamont__> elmo: iz in scrollback a few hours back... I was mostly dumping it back on Mez.
<lamont__> there are several unknown/ packages (whcih are really universe) in hoary-backports.
<Mez> lamont - I got grabbed away from PC to job search
<lamont__> for values of several in the vicinity of 6
<lamont__> elmo: I should have emailed you, sorry
#ubuntu-devel 2005-08-07
<Mez> elmo: any news on member email addresses yet? 
<ogra> AndyFitz, !
<AndyFitz> ogra!
<AndyFitz> good morning
<ajmitch> hi AndyFitz 
<infinity> doko : Does openoffice.org2 really need to pull in half the compilers in main as a dependency?  So much for "users don't need development environments"...
<AndyFitz> g'day ajmitch
<ogra> infinity, dont you get the conspiration ? gcc itself is a office environment now including java support, ooo2 is only the frontend ;) 
<Amaranth> oops, i just made smeg run into the gnome-vfs bug
<ogra> wait until we start using gcc as desktop environment too :)
<doko> infinity: no, that was a left over in java-gcj-compat, depending on java-gcj-compat-dev. will be fixed with a sync tomorrow
<ajmitch> ogra: we can't have gcc taking the place of emacs
<ogra> ajmitch, we dont need to, lets integrate them ;)
<ogra> so you finally get mailreader support in gcc'through emacs
<ogra> s/'//
* Mez pets daniels :D he fixed X :D w00t
<infinity> doko : \o/
* Mez smooches daniels a bit
* Mez dances for his working breezy
<Amaranth> Mez: xfonts-utils?
<bddebian> Heh
<Mez> Amaranth, huh ?
<Amaranth> the package that fixed everything
<Mez> xfonts-base :D
<Mez> lol
<Mez> well
<Mez> actually i'm not too usre
<Mez> I er...
<Mez> uninstalled ubuntu-desktop and all dependencies
<Mez> and installed kubuntu-desktop :D
<bddebian> Sacriledge
<Mez> nah it aint
<Mez> kubuntu rules the earth
<bddebian> :-)
* bddebian grabs hold of Mez to keep him connected... ;-)
<Mez> bddebian, I'm restarting X
<lexhider> can anyone confirm a weird breezy evolution behaviour?
<lexhider> tab cycles through widgets, shift-tab doesn't. (note that keyboard's working fine and shift-tab is working in firefox)
<Mez> hmm
<Mez> now I have breezy working
<Mez> maybe i should try sid
* ..[topic/#ubuntu-devel:Mez] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | X is a lot less broken - it works!
<Amaranth> for you
* ..[topic/#ubuntu-devel:Mez] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released | X is a lot less broken - it works (well - kubuntu does - for mez)!
<Mez> doesnt it work for you?
<lexhider> and me as of last night, upgrade from hoary, need to install libfontenc 1st. X working for me though.
<Mez> mako: ping
<Amaranth> yeah, upgrades from hoary should work fine
<Amaranth> it works for me, but i upgraded from hoary and cheated with mkfontdir from hoary
<Amaranth> upgrading from colony 2 is supposedly broken
<Nafallo> wfm, without more cheats than some local rebuilds (adding b-deps) :-)
<Mez> Amaranth, I was originally colony 2
<Mez> but i did a server install
<Mez> I didnt do anything cept remove ubuntu-desktop (and all deps)
<Mez> and install kubuntu-desktop
<Amaranth> ah
<Amaranth> that's why then
<Mez> ... ?
<Mez> It still depends on xserver-xorg
<Amaranth> upgrading from the X in colony 2 is broken
<Mez> which works now
<Mez> sudo apt-get install --reinstall xserver-xorf
<Mez> sudo apt-get install --reinstall xserver-xorg *
<tseng> Mez: uh
<Amaranth> removing everything and reinstalling, yeah
<tseng> Mez: does this ruby thing have *anything* to do with security?
<tseng> Mez: or did i totally miss something
<Mez> o_O
<Mez> didnt they say it was shipping witha  buggy beta version?
<Amaranth> yes
<tseng> buggy as in has bugs
<tseng> not buggy as in exploitable
<Amaranth> hoary-updates material, not hoary-security
<Mez> and beta as in not secure
<Amaranth> but i agree something should be done about it
<Mez> ;)
<tseng> well
<tseng> if you read the bug, i am going to push him back in the hoary-backports direction now
<Amaranth> appearently a couple of large bugs were fixed that break things like rails
<tseng> the diff is too large
<Amaranth> ah
* Mez apologises and er...
<Mez> emails pitti again
<tseng> Mez: do you have a hoary pbuilder handy?
<Mez> tseng: er..... 
<Mez> not in breezy
<tseng> i didnt say breezy
<Mez> I didnt either
<Mez> I said not in breezy
<tseng> so.. the question was
<tseng> do you have a hoary pbuilder handy
<Mez> if i reboot into hoary, yes
<Mez> or I could chroot ...
<tseng> I see.
<Nafallo> Mez: I got a warty, hoary and a breezy pbuilder on my breezy installation :-).
<tseng> Nafallo: wanna help me?
<Mez> tseng: now I have
<tseng> ok, anyone, please build rails from breezy in hoary pbuilder
<Nafallo> tseng: sure, why not :-).
<tseng> and we can resolve this in at least some fashion
<Mez> tseng: for backports?
<tseng> yep
<tseng> the diff is 204k, its not -updates material
<Mez> oh
<Mez> ffs
<Mez> brh
<tseng> buh?
<Nafallo> tseng: what do you want help with? :-)
<tseng> Nafallo: i dont have a hoary pbuilder
<tseng> it will take 30 seconds for someone who already does
<Nafallo> where are the sources? :-)
<tseng> http://packages.ubuntu.com/breezy/source/ruby1.8
<Keybuk> dear gimp, you are not the best program to view images, kthxbye
<tseng> Keybuk: good thing gthumb finally has a maintainer
<Keybuk> actually, I somewhat thing eog is just right
<tseng> Keybuk: it could potentially not suck someday
<tseng> or am i thinking of eog
* tseng shrugs
<tseng> Keybuk: tried f-spot? :P
<AndyFitz> tseng:  f-spot rocks,  but not for once-off viewing  I think
<tseng> once off, no
<tseng> hi AndyFitz :)
<Keybuk> f-spot sucked
<Keybuk> it imported my album, and then ignored the carefully categorised directories everything was in and expected me to do it all again
<Keybuk> ergo I don't use f-sport
<Keybuk> s/r//
<tseng> Keybuk: https://bugzilla.ubuntu.com/show_bug.cgi?id=12613
<tseng> Keybuk: you agree this patch is too large for hoary-updates, right?
<Mez> tseng: building
<tseng> Keybuk: before i fully steer this nice people to backports.
<AndyFitz> g'day tseng.
<Keybuk> heh, probably
<tseng> at that point we could backport a current rails also
<Mez> tseng: rdoc 1.8.1 > 1.8.2 change... 
<Mez> that ok?
<tseng> Mez: hm?
<Mez> rails depends on 1.
<Mez> 1.8.2
<AndyFitz> I discovered that f-spot hidden mode is useful. and not just for pr0n.   you can finally show family and friend photos to your new girlfriend while *skipping past * any photos of ex girlfriends  ;-)
<Mez> 1.8.1 = in hoary
<tseng> Mez: thats the entire point.
<tseng> Mez: of this discussion
<Mez>  ... /
<tseng> RFB :)
<Mez> RFB?
<tseng> RTFB
<Mez> AndyFitz, wha?
<Mez> B ?
<tseng> bug.
<Mez> ah
<Mez> link
<tseng> < tseng> Keybuk: https://bugzilla.ubuntu.com/show_bug.cgi?id=12613
<tseng> if you missed it the last 2 times
<AndyFitz> Mez, nm
<tseng> AndyFitz: oh dude. i got an apple cinema display
<tseng> AndyFitz: pure love.
<AndyFitz> tseng,   pure jealosy
<Mez> tseng: then shouldnt I try a ruby bp instead of a rails bp
<tseng> Mez: did i not say ruby?
<AndyFitz> did you know a cinema display ups your mojo
<Mez> you said rails
<Keybuk> tseng: not got a firefox nearby
<tseng> hm i did
<Keybuk> trying to drive a dvd and not doing too well
* Mez makes a build of ruby instead 
<tseng> Mez: sorry, backport ruby, rails is just the end goal
<Nafallo> hmm
<tseng> i thin Nafallo is building the right thing anyway
<Mez> tseng: ruby = debian native
<Mez> that ok
<Nafallo> I have to fix my mirror weirdness before being able to update stuff :-P
<tseng> yeah I know
<Mez> tseng: life will be so much easier when i get my pbuilds on dev.kubuntu.org.uk working
<Keybuk> aha!  I've found REWIND! :p
<Mez> tseng, seems to build ok
<tseng> Mez: rock on.
<Mez> \o/
<tseng> Mez: any chance we can kick off a backport of ruby1.8 then rails?
<Mez> tseng
<Mez> actually
<Mez> one sec
* Mez checks if he was logging into a breezy or haory chroot
<Mez> nope, it built fine on hoary
<tseng> k.
<Mez> elmo: ping
* Mez wonders why his sound isnt working in hoary
<Mez> hmm
<Mez> it is working
<Mez> just not outputting to soundcars
<Mez> works if I switch to headset
<Keybuk> WHAT KIND OF STUPID FUCKED UP USELESS PIECE OF CRAP SOFTWARE PUTS THE ONLY DOCUMENTATION FOR THE KEYS YOU _HAVE_ TO PRESS IN THE MANPAGE FOR THE CUNTING CONFIGURATION FILE("!("*$(*!("$*
* Mez huggles keybuk
<Lathiat> Keybuk: come again?
<tseng> possessed by the spirit of mjg59 
<Keybuk> ogle, no ui, just keys you press for which the documentation is in the proverbial toilet with the "beware of the leopard" sign on it
<Mez> wtf
<Mez> is going on
<Mez> thats weird.
<Mez> sounds works in breezy but not hoary
<Mez> it used to work fine in hoary
<Mez> tseng: whats your email address again?
<tseng> brandon@smarterits.com
<Mez> tseng@gentoo.org?
<tseng> thats a black hole
<Mez> lmao
<Mez> why is it on your PGP key then
<tseng> dont send mail there if you want me to read it :)
<tseng> because i didnt take it off, I guess
<Mez> lol
<Mez> what did you do to get that?
<tseng> Mez: http://www.gentoo.org/news/en/gwn/20040119-newsletter.xml
<Mez> Gentoo/Hardened, *box window-managers
<tseng> barely touched it in probably a year now
<Mez> tseng: I'm sure you could have chosen a bettter picture
<tseng> but thats my dirty past.
<tseng> Mez: eh
<tseng> i hate pictures
<Mez> hard core metal music?
<Mez> rock on :D
* tseng spins Converge
* Mez shrugs and has no idea who that is
<tseng> probably for the best.
<Mez> but :D nice to know someone has good taste in music :d
<Mez> lol
* Mez isnt really "hard core" metal, but i like like  a lil deathcore etc now and then
<tseng> gah
<tseng> i need to keep looking up the Markdown syntax for links
* Mez shudders and kicks FF
<Mez> hehe
* Mez thinks this comic is sooo right
<Mez> http://www.little-gamers.com/
* Nafallo seconds breezy ruby working on hoary
<Mez> lol
* Mez goes and sets up buildds on dev.kubuntu.org.uk
<Nafallo> hmm
<Nafallo> I should have fixed my sources.lists ages ago ;-)
<Riddell> Mez: that sounds a bit scary
<Mez> Riddell, well, pbuilds :d
<Mez> but, I always refer to them as buildds
<Riddell> ah, fine
* Mez shrugs
<Mez> they do the same job
<Riddell> buildd's use sbuild or something I think
<Mez> yeah they do
<Mez> but pbuilds do the same job
<Mez> cept, you run the commands manually
<carstenh> when a packages in some of its maintainer-scripts changes a configuration-file of an other package which is created in postinst, the first package has to pre-depend on the second one, right?
<Lathiat> anyone else upgrade recently and have lots of gtk stuff crashing all the time again
<carstenh> hmm, bad sentence structur :/
<Nafallo> Lathiat: indeed
* Mez doesnt
<Mez> my kubuntu works shinehly
<Nafallo> Mez: bleeh :-P
<Mez> though my hoarys broke now :d
<Lathiat> Nafallo: hrm
<Lathiat> Nafallo: will a restart help?
<infinity> carstenh : No.
<Nafallo> Lathiat: naah, I had this for days :-/
<Lathiat> Nafallo: oh, that one was fixed before with libcairo1
<Nafallo> Lathiat: or atleast for the weekend
<Lathiat> but i just upgraded now and its happening again
<Lathiat> oh well
<Lathiat> i'll restart mny session
<infinity> carstenh : Unless you have a dependency loop (don't do that, then), packages are configured in order of depends.
<Lathiat> see what happens
<infinity> carstenh : So, your postinst will run after the other package's postinst, meaning it will have the right file available to edit.  No need to pre-depends, unless you need it in your preinst (eww)
<Nafallo> Lathiat: I have a cronjob fetching Packages @ :05 and :35 every our. I'm up-to-date :-). stuff is still crashing.
<carstenh> infinity: i did not know that, thanks a lot :)
<Lathiat> Nafallo: haha
* Mez wonders why all the fonts are bigger in breezy
<Nafallo> s/our/hour/ :-)
<infinity> carstenh : It's in debian policy, section 7.2, I recommend reading it (and many other sections, for that matter)
<Lathiat> i hope this gtk icon size thing gets fixed soon
<Lathiat> its really started to drive me bonkers
<Nafallo> hehe
<jdub> ahr, pants off
<carstenh> infinity: you are right, i'd better read the whole policy from the first section to the last and not only the points that seem intresting to me ;)
<tseng> jdub: yarrrr
<infinity> carstenh : Not necessarily necessary to read it all, you'll forget it anyway, but I'd recommend skimming it, and knowing basically what content it has, so you can refer back to it when you have questions like this, rather than asking around.
<carstenh> infinity: i read that part a very long time ago and thought i would be right with my pre-depends :/ thanks a lot for your help
<infinity> carstenh : THere's a reason why policy recommends mailing debian-devel before implementing a pre-depends in a package, it's because 99% of the time, a pre-depends isn't necessary, and someone will smack you down and tell you so. :)
<carstenh> :)
<Mez> why are all the fonts bigger in breezy?
<infinity> iz gtk bug.
<infinity> (iz also known bug, being worked out, apparently)
<Mez> ah ... fair enough
<tseng> Mez: thanks dude.
<Mez> tseng: what for?
<tseng> for kicking the backport
<Mez> tseng: Itll take a few years till It's in there
<tseng> years?
<Mez> well, it'll be done when elmo gets around to it
<tseng> yes
<Mez> whenever tha tbe
<Mez> mdz: apologies... was using-devel as it was referring to breezy/hoary disputes
<wasabi> Curiously, why isn't there a linux-image-2.6.12-6-k8 ?
<wasabi> or whatever they call amd64s
<infinity> #  linux-image-2.6.12-6-amd64-k8-smp_2.6.12-6.6_amd64.deb
<infinity> # linux-image-2.6.12-6-amd64-k8_2.6.12-6.6_amd64.deb
<wasabi> not running in 64 bit mode.
<wasabi> ie amd64 platform.
<infinity> wasabi : Or are you looking for k8 images on an i386 system?
<wasabi> Just curious.
<wasabi> Yeah, i386 system.
<infinity> Ahh, in that case, the answer is "cause there isn't".
<wasabi> I guess I will be until I know multiarch is done proper. ;)
<infinity> Anyone who wants a high performance k8 system will be running amd64 binaries, not i386.
<wasabi> How is the parallel installation of libs?
<infinity> "Not there yet".
<wasabi> So, your previous statement was wrong.
<infinity> But coming along.
<infinity> What was wrong about it?
<wasabi> Anyone who wants a high performance system will only run amd64 binaries if they use no software that doesn't use a big ass 32bit stack.
<infinity> Oh, for commercial binaries, the ia32-libs package on amd64 should be enough to get them all going.
<wasabi> What about commercial binaries that use gtk?
<mdz> are there commercial apps which link dynamically with gtk?
<wasabi> My company has a number of in house ones.
<wasabi> I mena.
<wasabi> I could build a big ass gtk 32 bit stack.
<mdz> really?  that were bought from another company?
<wasabi> But that's a pain in the ass.
<wasabi> Yeah. Out sourced.
<infinity> Looks like we ship GTK in ia32-libs, yes.
<wasabi> Oh wow.
<mdz> we do have ia32-libs-gtk
<mdz> but I really wouldn't expect anything but oo.o to use it
<infinity> Right, ia32-libs-gtk is GTK 2.0, ia32-libs appears to have GTK 1.2 in it.
<infinity> So, both bases covered.
<infinity> But, yeah, I assumed anyone using GTK statically linked to it.
<infinity> That's generally the case with QT.
<infinity> Live and learn, I guess.
<wasabi> Well, it is nice to know that people actually use GTK I'm sure.
<wasabi> And expect it to have some sort of stability. ;)
<infinity> Stability isn't the issue, when dynamically linking closed binaries to it, you're epxecting standardisation on specific versions.  I didn't think the LSB specified GTK ABI...
<wasabi> Why would a company follow the LSB?
<infinity> Because that's the sane way to make sure things might work on more than one system?
<wasabi> Pssh.
<infinity> (Or, just statically link everything but libc, which is what most people seem to do)
<wasabi> Company's will pick whatever API is available and use it to the best of their ability.
<wasabi> Lesson #1 in commercial software.
<wasabi> Don't give a company an API you don't want them to use.
<infinity> They can use whatever API they want, it's the ABI I'm arguing about.
<infinity> It's not rocket science to statically link a bunch of junk into your binary before you ship it.
<infinity> Sure, it bloats your installer a bit, but it "just works", and customers like things that work.
<infinity> Customers are weird that way.
<wasabi> Eh. Sure. You just overestimate the planning capability of out sourced developers.
<wasabi> Think of it like the Windows realm.
<infinity> I'd prefer not to. :)
<wasabi> You pay somebody, they go type a bunch and get it done as fast as possible, they don't focus on what is best for long term maintainability.
<wasabi> They just get it done and deliver a product.
<wasabi> I can wrangle up the source for this, I just prefer not to.
<infinity> I can't count the number of times Windows programmers decided that downgrading half the DLLs on my system was a good idea, until Microsoft finally built in version overwrite checks to prevent that very problem.
<bddebian> DLL hell? ;-)
<HrdwrBoB> wasabi: depends
<HrdwrBoB> a lot of that is lowest bidder syndrome
<HrdwrBoB> where you get what you paid for
<infinity> wasabi : But yeah, I understand, hunting down source and fixing the root issue sucks when you have an installer that already may work.  So, give it a spin with amd64+ia32-libs{,-gtk} and see if it loves you.
<Amaranth> ook, latest openoffice2 packages break the menu icons
<wasabi> I also worry about stuff like Gnome itself.
<wasabi> People totally want to write software using gnome!
<Amaranth> icon names changed to openofficeorg-19-writer and etc, menu files are still using ooo-writer
<Amaranth> wasabi: I'm totally writing software using GNOME. :)
<mrd`> Does Breezy's kernel still have the initrd-dsdt patch?
<crimsun> mrd`: afaik, yes.
<mrd`> crimsun: dmesg doesn't show the 'looking for dsdt patch' message anymore
<mrd`> ... nevermind... I'm stupid.
* mrd` sighs at his inability to make case-insensitive searches. >_>
<crimsun> heh.
<crimsun> was just about to mention that =)
<mrd`> :-)
<crimsun> morning, pitti 
<pitti> Good morning
<pitti> Hi crimsun 
<crimsun> I wonder what I should do about vlc (universe), since if it's built with ffmpeg support, it needs postproc support, but breezy's libpostproc-dev is in multiverse.
<Treenaks> ok, some ubuntu people use grouphug: http://grouphug.us/confessions/446335517
<pitti> lol
* Lathiat laughs
<HrdwrBoB> crimsun: the vlc ffmpeg can't be seperated?
<crimsun> HrdwrBoB: it is. The version in Hoary included ffmpeg, so it wasn't an issue.
<crimsun> HrdwrBoB: unfortunately, Debian removed that included ffmpeg in the next package revision.
<HrdwrBoB> ah
<Amaranth> crimsun: i'm guessing vlc gets to migrate to multiverse
<Amaranth> crimsun: i find it hard to believe it isn't there now
<Amaranth> crimsun: vlc without ffmpeg is worthless
<crimsun> migrating it to multiverse is probably the most efficient solution.
<crimsun> the ideal solution would be to migrate libpostproc* to universe, but I don't foresee that
<HrdwrBoB> Treenaks: http://grouphug.us/confessions/733850316 ...
<crimsun> I think for now I'll just disable the postproc code
<HrdwrBoB> what use is vlc without it?
<HrdwrBoB> will it work for most peoples purposes?
<crimsun> well if I disable postproc, ffmpeg will just be missing postproc, but vlc will still be able to use ffmpeg
<crimsun> unless you do major tweaking to your pictures, you won't notice any difference
* Amaranth does major tweaking
<Amaranth> i make mencoder cry
<sivang> Morning
<pitti> Hi sivang 
<crimsun> morning JaneW 
<JaneW> hi crimsun 
<sivang> Hi pitti 
<sivang> pitti: file-roller launchpadized is finally in ;)
<sivang> pitti: need to continue at full thrust to completion
<daniels> mjg59: next upload will have it fine, as the gcc fix is already in
<daniels> mdz: setxkbmap -print | xkbcomp - :0
<daniels> mdz: you probably need sudo dpkg -i --force-overwrite /var/cache/apt/archives/xkeyboard-config_0.5-3_all.deb
<lexhider> I've seen a lot of launchpadized stuff in breezy-changes, what's it mean though?
<Burgundavia> lexhider, http://udu.wiki.ubuntu.com/LaunchpadIntegration
<lexhider> Burgundavia, thanks
<Burgundavia> lexhider, np
<sivang> lexhider: we are going to enable users to access launchpad action applicable per each desktop seed app from the apps own help menu
<sivang> lexhider: if you are using breezy, you can check out file-roller , and evince to reach the placeholder page already
<doko> mvo: ping
<mvo> elmo: can you please sync baobab  from unstable (universe package, I ask for dholbach he has network trouble)
<doko> mvo: please can you reupload aptitude? synced libsigc++-1.2 soname
<mvo> doko: ok
<davyd_> is Thom May around?
<davyd_> I would really love to know how to unbreak my NetworkManager
<Treenaks> davyd_: wait for an update, I guess
<davyd_> it is complaining it is missing the binary 'no'
<davyd_> this does not appear to be dragged in by a dependancy
* Amaranth falls over
<davyd_> and in fact, is proving rather elusive to track down
<Burgundavia> davyd_, I don't think that Thom is doing NM anymore
<Amaranth> i don't think thom works on network manager anymore
<davyd_> is anyone working on NetworkManager, or has it been abandoned?
<Burgundavia> someone else is
<robitaille> so what does Thom do these days?  he doesn't seem to do FF either
<Burgundavia> irc nick is escaping me
<Amaranth> robitaille: he got a new job or something
<daniels> davyd_: other people are working on NM
<daniels> and seb128 now maintains firefox
<daniels> everyone send your firefox questions to seb
<Burgundavia> daniels, you are pure evil
<davyd_> daniels: who?
* davyd_ is rather annoyed that his NM stopped working and he can't work out whyt
<Lathiat> because it was broken 
<seb128> daniels: don't cry you can get firefox if you want, I'm not like that
<daniels> seb128: it's all yours.  i wouldn't want to deprive you.
* robitaille thinks of reassigning the 100s of FF bugs in the bugzilla from thom to seb128 :)
<Treenaks> robitaille: you're the reassign-master already
<jdub> yo seb128 
<robitaille> Treenaks:  yeah...I feel guilty of spamming too many people these days...
<Treenaks> robitaille: launchpad should auto-assign Universe bugs to MOTU I guess?
<seb128> hey jdub
<sivang> bon jour seb128 , still didn't hear from jamesh
<seb128> hi
<robitaille> Treenaks: is there a list of all universe packages in LP?  I wonder if it's something that will have to be done manually. If it is what the motu team wants
<Treenaks> robitaille: there should be right?
* davyd_ sighs
<davyd_> does anyone have an old NetworkManager package handy?
<pitti> Morning seb128 
<pitti> seb128: you recently enabled the cairo backend for SVG rendering in firefox, didn't you?
<seb128> hey pitti
<seb128> pitti: no, I've not changed anything to firefox
<seb128> pitti: I've only patched for some bugs but not changed a build option, why ?
<pitti> seb128: oh, I thought, because it build-deps on libcairo1-dev
<seb128> that's not new
<seb128> thom did
<pitti> seb128: I'm currently packaging mozilla 1.7.11 and tried to enable cairo, but it FTBFS due to a cairo API breakage
<pitti> seb128: ok, thanks
<pitti> seb128: if it used cairo, then ffox would be ftbfs now, but if not, nevermind
<seb128> why?
<seb128> ffox uses cairo
<seb128> but they changed like 3 functions and it doesn't use those
<pitti> seb128: ffox and moz call "cairo_create()", but that takes a parameter now
<pitti> seb128: I added a parameter, but then it fails again on another function, then I just gave up and fixed the libart backend instead
<jdub> damn parameters! they get in everything!
<pitti> seb128: I try to build ffox
<jdub> like sand in your swimmers at the beach
<pitti> Hi jdub!
<pitti> jdub: do you know the reason why whe can't ship howl? that was a patent issue, right?
<Treenaks> pitti: Apple/GPL license incompatibility
<Treenaks> afaik
<jdub> pitti: no, the mDNSResponder is APSL2
<jdub> not a license incompatibility between any software
<seb128> ~ cairo_create(void) -> cairo_create(cairo_surface_t *)
<jdub> just a general legal incompatibility ;-)
<seb128> that's for 0.5.0
<Treenaks> jdub: oh, non-free-ness of APSL2?
<jdub> yeah
<seb128> let's ship bonjour
<bob2> how's the Free clone coming along?
<seb128> that's a bsd one :)
* jdub spanks seb128 
<jdub> seb128: the mDNSResponder is still APSL
<pitti> seb128: oh, nevermind, ffox gets build with --disable-svg; a pity :-/
<pitti> seb128: supporting svg would be nice
<seb128> pitti: why?
<sivang> seb128: it's mDNSResponder clone?
<seb128> clone of what?
<bob2> FF 1.5 allegedly hasw working svg support
<pitti> mozilla is built with svg support, too
<sivang> seb128: bonjour, is a clone of mDNSResponder ?
<janimo> bob2, it indeed has I played svg tetris with it :)
<jdub> bob2: stfu, version pimp!
<jdub> sivang: it is an mDNS responder
<Lathiat> sivang: bonjour is apples implementation of multicast dns service discovery
<seb128> pitti: 
<jdub> sivang: bonjour is the api you use to talk to the responder
<seb128> jui 29 22:39:43 <tor_>  seb128: the cairo code in 1.0.x is extremely old at this point, and shouldn't be used.  it was just a proof-of-concept at that time
<bob2> jdub: hey, it comes out in september, plenty of time to move to a new major version after the preview releases
<bob2> janimo: hah, pimp
<pitti> seb128: right, I noticed that; but why not use the libart backend?
<seb128> pitti: that's from #cairo
<jdub> pitti: libart is differently broken ;)
<seb128> pitti: I don't maintain firefox, I use epiphany-browser ... feel free to change it .. 
<pitti> jdub: well, it worked up to 1.7.10, and now upstream removed the code from the sources
<pitti> jdub: I just added it again for now to make it work again
<sivang> jdub,Lathiat : thx
<seb128> daniels: around?
<Mez> hmm
<Mez> gksudo doesnt exist in breezy
<Mez> not in the gksu pacakge anyways
<bob2> it does according to the Contents files
<bob2> (which could well be out of date)
<seb128> $ dpkg -S /usr/bin/gksudo
<seb128> gksu: /usr/bin/gksudo
<\sh> ok..hibernating works...but after coming back from hinbernate, the usb ports and ethernet port aren't reinitialised
<bob2> how did you hibernate?
<bob2> by running /etc/acpi/hibernate.sh?
<\sh> bob2: no...with klaptop applet..and I think it will call something like hinbernate.sh...i need to have a closer look
<bob2> so try and see if the script works
<bob2> it does some neccessary module unloading/reloading for you
<pitti> Hi carstenh 
<sivang> hey carstenh , pitti 
<\sh> bob2: i will debug this later...right now I disabled hinbernating on this hp nc6000
<carstenh> hi sivang, hi pitti 
<pitti> seb128: I want to play around with libnotify, I can possibly use it for the audio hotplugging response
<pitti> seb128: however, which package contains the daemon?
<seb128> pitti: notification-daemon
<seb128> pitti: libnotify package has a test/ dir with a pile of example if you want to play with it
<pitti> uh, thanks. sorry, "apt-cache search libnotify daemon" didn't reveal it
<ogra> pitti, look at hughsies power-manager code for examples ;) he uses it extensively
<seb128> it displays all sort of message on different places of screen
<seb128> better to look on libnotify examples imho
<pitti> $ notify-send Test
<seb128> examples are better than getting bits out of a big piece of code
<pitti> that does fine as a first try :-)
<ogra> oh, i havent looked yet, i didnt know they have examples
<pitti> seb128: the examples should be shipped in /usr/share/doc/libnotify-dev/examples :-)
<pitti> seb128: but I'll look in the source. Thank you!
<seb128> pitti: technically that's a test-suite, but that can be used as examples :)
<seb128> np
<seb128> pitti: BTW that's really trivial to send a notification with it :)
<ogra> elmo, did you get dholbachs sync request for baobab yesterday ? if not, please sync it from debian...
<seb128> is there any plan to move libnotify to main?
<pitti> $ notify-send -t 5 'New sound card detected' 'You can make the new sound card the default device in System -> Settings -> Audio'
<pitti> that'll do for now :-)
<ogra> seb128, if g-p-m goes to main it has to follow ;)
<seb128> pitti: useful, isn't it ? :)
<pitti> seb128: yes, and really trivial
<pitti> seb128: I think I just call notify-send in gnome-volume-manager, that will avoid dependencies and give loose coupling
<seb128> k
<ogra> heh, yes you can clutter your desktop with tons of useless messages... wait for the bad designed UIs :)
<seb128> if you want to use it, that's a 1 function call too
<pitti> seb128: doing this in g-v-m is not a permanent solution anyway
<seb128> notify_send_notification ()
<pitti> seb128: right, I just asked myself whether I should depend on libnotify0
<seb128> Depends: libc6 (>= 2.3.4-1), libdbus-1-1 (>= 0.34), libdbus-glib-1-1 (>= 0.34), libglib2.0-0 (>= 2.7.1), libpopt0 (>= 1.7
<pitti> seb128: but if we will have it in main, then that's a non-issue
<seb128> Installed-Size: 76
<seb128> not a big deal :p
<seb128> pitti: if we push it to main gnome-applets can me use of it
<seb128> s/me use/make use/
<ogra> pitti, just approve the new g-p-m and we'll have it in main :)
<pitti> seems like a good idea if gnome adopts it anyway
* pitti curses at hoary's apache2 which suddenly FTBFS
<pitti> seb128: if I install I new app, it doesn't appear in the menu until I killall gnome-panel; is this still an inotify bug? or a gamin one?
<seb128> pitti: gamin one to change
<seb128> pitti: but there is good news: http://mail.gnome.org/archives/gamin-list/2005-July/msg00062.html
<seb128> "I'm attaching a patch that fixes the reference counting bugs
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=172365 ,
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=302236 , and countless distro
<seb128> specific bug reports."
<seb128> 
<seb128> so maybe next gamin will work now ... :)
<pitti> let's cross fingers...
<seb128> atm notification are b0rked all over the place :(
<ogra> pitti, did you notice that according to www.redhat.com you still live in the gdr ? http://www.redhat.com/g/promos/second_intelvid_050726.png
<pitti> ogra: hm?
<ogra> look at the map :)
<azeem> ogra: reload
<azeem> the changed it
<ogra> HAHAHAH
<azeem> they, even
<ogra> lol, thats funny...
<azeem> http://blog.schmehl.info/Debian/red-hat-europe-map-2
<pitti> ogra: I'm afraid I don't understand...
<azeem> pitti: http://blog.schmehl.info/Debian/red-hat-europe-map
<pitti> ogra: I see a blue shape of europe with three yellow stars
<ogra> pitti, yesterday tere were borders on the map :)
<pitti> ogra: oh, I see on the blog page :-) LOL
<pitti> ogra: the current image doesn't have borders
<ogra> pitti, and apparently it ws older then 16 years :)
<pitti> seb128: AFAICS libnotify0 should depend on notification-daemon, or is there any reason why it shouldn't?
<pitti> seb128: (at least recommend)
<seb128> pitti: I've packaged it before the daemon, but right ... Depends or Recommends ?
<pitti> seb128: well, if you don't want notifications, it should be possible to uninstlal n-d
<pitti> seb128: as long as apps work without the daemon, then Recommends (and explicit seeding) seems to be right
<pitti> seb128: nice examples, some don't work, but most do :-)
<seb128> pitti: which one doesn't?
<seb128> and I agree with the Recommends
<pitti> seb128: test-animation just barfs with some assertion failures
<seb128> right
<pitti> seb128: and I guess test-error is supposed to throw an assert? :-)
<seb128> probably yeah
<Kamion> infinity: could you retry libdebian-installer on ia64, please? "checking for C compiler default output file name... configure: error: C compiler cannot create executables" doesn't look like a problem with the package
<daniels> seb128: iz gtk boog
* Kamion promotes oem-config* to main, since mdz approved it the other day
<seb128> daniels: ah,  you are here :)
<seb128> # Xnest :1
<seb128> Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from list!
<seb128> Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list!
<seb128> Fatal server error:
<seb128> could not open default font 'fixed';
<seb128> 
<seb128> what should I change to start Xnest?
<seb128> that breaks sabayon ...
<seb128> and I would like to play with the new version before uploading it
<pitti> Hi sjoerd 
<janimo> seb128 did you have a modified xorg.conf?
<janimo> in that case the upgrade does not touch it
<janimo> the fonts have moved
<seb128> what font?
<seb128> xorg.org has no X11R6 mention 
<ogra> seb128, which config does xnest read...
<ogra> there must be a custom config anywhere, i doubt its hardcoded
<janimo> I know I had those errors, fonts moved to /usr/share or something
* pitti managed to f**k his kernel and needs to reboot
<daniels> seb128: oh yeah, I meant to fix that
<seb128> daniels: is that something to change locally or something you have to fix?
<seb128> daniels: ie: can I give it a try now or should I wait for your fixed version?
<doko> daniels: do we get a shiny new xorg today?
<daniels> doko: yeah, when I've unpacked my computer
<daniels> i'm sitting in the lounge with my laptop trying to find my charger so I don't have to drop offline in 20min
<daniels> seb128: edit the binary, grep for /usr/X11R6, change it to the right path, pad with NULs as required
<doko> cool, no new empty packages please ;-P
<seb128> daniels: k, thanks. And you have planned to fix it this week? There is no real point for me to update sabayon if Xnest is b0rked
<daniels> doko: which video driver do you use?
<daniels> seb128: i'll try to fix it in -44 (next upload)
<seb128> thanks
<doko> depends, ati and fglrx
<ogra> Kamion, /usr/lib/oem-config/locale/localechooser: line 500: [: de_DE.UTF-8,: binary operator expected
<doko> daniels: depends, ati and fglrx
<daniels> doko: the next release of xorg will have an empty -driver-ati, just for you :P
<Nafallo> daniels: *grumpf*
<doko> daniels: fine, please name the package it -driver-ati-doko ;)
<daniels> heh
<ogra> Kamion, it exits with __main__.WizardException: Menu item keyboard exited 256 (oem-config that is)
<Kamion> ogra: could you run oem-config under OEM_CONFIG_DEBUG=1 DEBCONF_DEBUG='.*' and send me /var/log/oem-config.log, please?
<ogra> sure
<Kamion> thanks
<Kamion> though I do see a problem on that line - fixing upstream
<Kamion> still, debug would be useful anyway to verify that it's that
<ogra> Kamion, it doesnt produce this file by default ? 
<[linesca] > Kamion: you got a minute ?
<ogra> Kamion, [linesca]  is about to test our ltsp on a big HW setup, but he cant manage to get the installer to boot on the blade servers
<Kamion> ogra: it does, but there isn't so much in it by default
<Kamion> [linesca] : I'm kind of buried in complicated code at the moment - how's it going wrong?
<ogra> Kamion, there was no file in /var/log ... i had to rdirect the terminal output...
<Kamion> ogra: oh, right, the oem-config-dm mini-display-manager creates it
<ogra> ah
<Kamion> ogra: sure, redirect the terminal output, that'll do
<ogra> already sent it...
<[linesca] > Kamion, kernel panic pivot_root no such file   428 cannot open dev/console
<ogra> hmm, so i have to look at the mini-display-manaer too :)
<ogra> manager even
<[linesca] > ogra: your fingers work as well as mine :)
<ogra> heh
<Kamion> [linesca] : at what stage?
<[linesca] > Kamion: on boot starting Ubuntu
<Kamion> [linesca] : I mean, when you boot the installer, or after you've run through the first stage of the installer and rebooted?
<[linesca] > sorry on reboot
<Kamion> [linesca] : ok - that'll be an initrd-tools problem. I don't know so much about that; jbailey is the local expert.
<Kamion> I *think* it would probably be possible to fix up the initrd by changing 'MODULES=dep' to 'MODULES=most' in /etc/mkinitrd/mkinitrd.conf and running 'mkinitrd -o /boot/initrd.img-`uname -r` /lib/modules/`uname -r`'; you can do that from the CD's rescue mode
<Kamion> but jbailey will probably want to debug the problem first
<[linesca] > when is he normally around ?
<ogra> he lives in canada
<ogra> so in a hour or two i'D guess
<[linesca] > still in bed then :)
<[linesca] > ogra: I got stuff to do, I will try to get this resolved later
<ogra> [linesca] , ok, thanks for the effort :)
<[linesca] > np, I am keen to see what you guys have done
<jordi> carlos: hey
<carlos> morning
<jordi> carlos: I remembered I have doctor at 17:30. Maybe I arrive home a bit later than 19:00, I hope that's ok
<carlos> jordi, I will be here, just ping me when you are back
<sivang> ogra: are oem-config packages already available? 
<jordi> ok
<ogra> sivang, look at the archive...
<sivang> Err http://archive.ubuntu.com breezy/universe oem-config 0.1
<sivang>   404 Not Found [IP: 82.211.81.151 80] 
<bob2> does dak itself update dists/ and pool/ in the right order?
<Kamion> sivang: it's in main
<Kamion> update
<sivang> Kamion: I just did :-/
<sivang> Kamion: I'll retry, thx
<Kamion> cjwatson@jackass:~$ zcat ftp/dists/breezy/main/binary-i386/Packages.gz | grep-dctrl -PXnsFilename oem-config
<Kamion> pool/main/o/oem-config/oem-config_0.1_all.deb
<sivang> Kamion: works now
<sivang> wow, nice , can one use this to configure his ubuntu system not neccessairily use it for oems ?
<sivang> doh, that's what it meant to do - reading the pkg description
<ogra> sivang, its the "run after first boot" tool
<Kamion> sivang: I only intend to support it for OEMs at the moment
<sivang> Kamion: so regular users who install ubuntu get to do configuratoin before the first boot as was before?
<Kamion> sivang: yes, absolutely
<Kamion> I don't want oem-config to be part of the default install path
<Kamion> but it's reasonably generic, so one *could* use it for post-install reconfiguration
<Kamion> and of course that's a straightforward way to test it
<sivang> Kamion: looks somewhat freindlier then debconf's front end, is the kyboard layout detection code from smurfix's ?
<Kamion> sivang: not at the moment, no
<Kamion> I'm not sure I'll have time to work that in for breezy
<Kamion> it is actually a rather specialised debconf frontend itself
<Kamion> (oem-config, that is)
<sivang> Kamion: so it's yet another frotend, and uses debconf protocol , cool
<Kamion> yes, it intercepts the debconf protocol and pops up widgets of its own when it spots questions it's been told to recognise
<Kamion> the interface is a bit ropey still; I think it should probably all be in a single window rather than popping up a dialog for each step, for instance
<sivang> Kamion: have you given thought to to do the same to produce a debconf graphical front end, to be possibly used in install time ?
<sivang> Kamion: (I agree with having it in one window and being able to change stuff in an "event" mode rather then incrementally)
<Kamion> sivang: yes, of course; it may be possible to use some similar techniques, although in the installer I think cdebconf's custom widget support might prove to be a better bet
<Kamion> programming in the oem-config debconffilter framework is interesting; I think it might prove to be too complex and hard to get right for general installer programming
<Kamion> instant-apply dialogs are also liable to prove pretty tricky to do this way
<Kamion> although it can be done, theoretically
<Kamion> there were really two reasons I chose the filter approach: (1) it involved a startlingly small amount of code duplication; (2) perl debconf doesn't have custom widget support yet
<sivang> Kamion: did you code it in perl as well? (like most of debconf , I presume)
<sivang> Kamion: ah it's in python ofcourse :)
<pitti> yay, my at derooting patch was accepted in Debian
<sivang> pitti: cool for you , Martin :)
<sivang> Kamion: how can I see the Gtk frontend for oem-config?
<ogra> sivang, run it ?
<\sh> hmmm...I just ordered a free ticket for LinuxWorldExpo in November for FFM
<sivang> ogra: tried. Getting an error in pythoo
<ogra> sivang, did you run it with sudo ?
<sivang> ogra: yes
<Kamion> sivang: I'd like debugging info
<ogra> \sh, look that it doesnt clash with the ubuntu conference ;)
<sivang> \sh: free ticker?
<sivang> \sh: how so?
<sivang> Kamion: I'm making sure it's not something stupid that I do that causes this
<Kamion> sivang: I need to see at minimum the error in order to be able to help you at all ...
<sivang> Kamion: ofcourse, what is the command to invoke the oem-config against a gtk frontned? (I amanged to invoke the text UI)
<Kamion> er, that should not be possible - I need debug logs
<Kamion> please
<ogra> there is a text gui ??
<Kamion> it's supposed to be always hidden
<Kamion> that is why I need debugging information from sivang
<Kamion> because if he's seeing a text interface, the debconf filtering failed
<ogra> yep... here it worked in wizard mode
<ogra> (gui wise)
<Kamion> sivang: OEM_CONFIG_DEBUG=1 DEBCONF_DEBUG='.*' in the environment
<sivang> Kamion: btw, I'm using a breezy dchroot,  would that cause problems to oem-config ?
<Kamion> I don't know. It shouldn't. I need to see the logs.
<sivang> Kamion: ok, I now manage to get the first "choose your location" gtk dialog , but can't go any further
<sivang> Kamion: (I didn't change anything in the environment)
<Riddell> Kamion, mdz: am I ok to upload a k3b-i18n package to match the current k3b
<Kamion> of course, within a chroot you will need to ensure that you have a working DISPLAY and can run other X clients etc.
<sivang> Kamion: I do, I do all of my launchpad integration testing there
<sivang> Kamion: (I successfuly fired gedit/file-roller/epiphany etc)
<sivang> Kamion: emailing you a log for that invocation where it fails after the first dialog
<Kamion> Riddell: yes, go ahead
<Kamion> thank you
<sivang> Kamion: I wonder why I got the text UI in the first place, and not the Gtk one..sorry for not providing more info re this invocation :-/
<sivang> Kamion: actually, I put it online at http://muse.19inch.net/~sivan/oem-config.log
<Kamion> sivang: I really wanted debug information for that
<Kamion> debconf (developer): <-- GET console-keymaps-at/keymap
<Kamion> debconf (developer): --> 0 
<Kamion> hmm
<sivang> Kamion: sorry :-( I recall now that it happend right after the packages were isntalled, as if this was part of a regular package post configuration
<sivang> Kamion: so I didn't have to acutally run oem-config myself (apt did it for me)
<Kamion> ah, that was perhaps not copied over from d-i
<Kamion> sivang: do you remember which questions were asked in the text interface? any information at all is useful
<sivang> Kamion: one of them was about my keyboard layout (qwery, azerty or...etc) that's why I mentioend to you smurfix's kbd detection code
<Kamion> none of the oem-config* packages do any debconf interaction in their postinst
<Kamion> oem-config.postinst sources the confmodule, but that's just to get templates loaded; it doesn't do db_input
<Kamion> sivang: ah, it was probably console-data's postinst, then
<Kamion> sivang: that wouldn't happen normally; nothing to worry about
<ogra> http://www.grawert.net/funny_ncb_error.png
<sivang> Kamion: is it a bug or not?
<ogra> seb128, pitti ^^^
<Kamion> sivang: how did you create the chroot?
<ogra> seb128, how the hell does n-c-b compute tis duration ?
<ogra> this even
<sivang> Kamion: as outlined in https://wiki.ubuntu.com/DebootstrapChroot?highlight=%28debootstrap%29
<Kamion> sivang: I was wondering about the version of the debootstrap package you used
<sivang> Kamion: ah, the same one that is aviailable for downlaod on the wiki page
<sivang> Kamion: (for breezy, that is)
<Kamion> sivang: the crash in http://muse.19inch.net/~sivan/oem-config.log should be fixed in oem-config-keyboard 1.17ubuntu2, when it's built and mirrored
<Kamion> thanks for the report
<Kamion> sivang: ok, I'm not absolutely sure whether that's a bug or not, so I'll have a go at reproducing it myself later; could you file a bug on console-data, assigned to me, so that I remember?
<Kamion> it's orthogonal to oem-config as such, though
<bddebian> Howdy
<sivang> Kamion: yes ofoucrse, ah you mean they use the same code ? (console-data && oem-config)
<Kamion> sivang: no, bits of oem-config just depend on console-data for some data files it ships, that's all
<Kamion> d'oh, I broke debconf
<Kamion> that might not be helping matters
<sivang> hehe
<Kamion> fuck, I broke it in the version uploaded to Debian and all
<sivang> gush
* Kamion goes to fix before a million bug reports arrive
<koke> hi all!
<sivang> Kamion: I can't assign the bug to you, or to any others in bugzilla
<Kamion> ah
<Kamion> don't worry, I'll pick it up from ubuntu-bugs
<sivang> Kamion: it recall it was once possible to assign bugs to people, was this removed?
<Kamion> sivang: yes, see the topic
<sivang> Kamion: ok, I'll ping ogra when he's back online
<Kamion> sivang: can you just check for me, which version of debconf do you have installed in the chroot?
<sivang> Kamion: sure, I'll add it to the bug report ?
<sivang> Kamion: 1.4.54ubuntu1
<Kamion> sivang: that's the hosed version. I've just uploaded 1.4.55ubuntu1.
<Kamion> showdialog's return value was broken so the dialog frontend was completely confused about life in general
<sivang> Kamion: how can I bring it back to the state before the first invocation via apt-get ? (I wasn't able to get the text ui anymore)
<sivang> Kamion: (thinking of testing the fix)
<Kamion> you can't really, that's why I said I'd try to reproduce it here
<Kamion> you'd probably need to build a fresh chroot
<Kamion> I tested the fix with a simple 'dpkg-reconfigure debconf', which also previously manifested the bg
<Kamion> bug
<Kamion> of course if you *can* reproduce it with a fresh chroot, that'd be good too ...
<sivang> Kamion: but I will now get the fixed debconf package, can you put the bad one somewhere online?
<sivang> Kamion: (since a fresh chroot will be updated from the archive now)
<Kamion> sivang: you can grab a copy from the archive now
<Kamion> and the old one should stay around for a bit, anyway
<sivang> Kamion: k, I will try to reproduce on a fresh chroot now then
<sivang> Kamion: do we have packages.u.c now?
<Kamion> we always have
<Kamion> for some values of always
<sivang> Kamion: heh, ok, is it ok to get the pkg from there? (if I find it in all those catagories)
<Kamion> http://archive.ubuntu.com/ubuntu/pool/main/d/debconf/ would seem rather easier
<sivang> Kamion: yes, thanks, got the packag, now to fresh up a chroot :)
<thierry> where is the man page in a package?
<thierry> like for ubuntu bug 12445
<sivang> Kamion: sudo debootstrap --variant=buildd breezy /var/chroot2/ http://archive.ubuntu.com/ubuntu/
<sivang> Kamion: that's waht I use
<sivang> bah, need to start with hoary first and then upgrade
<sivang> E: No such script: /usr/lib/debootstrap/scripts/breezy.buildd
<Kamion> er, no, you need to use the breezy debootstrap if using the breezy script
<Kamion> /usr/lib/debootstrap/scripts/breezy requires features that were not in hoary's debootstrap package
<sivang> Kamion: ah right, darn. Well, nevermind, I guess this will better reproduce steps to create the chroot in question
<Kamion> thierry: depends totally on the package, you'll have to look
<Kamion> thierry: it's not hard to find
<sivang> Kamion: since I don't have the package installed here, I probably upgraded the chroot from haory to breezy after the inital deboostrapping
<thierry> Kamion : is searched man and manpage in the package and I can't find it... what is the usual name of the file?
<Kamion> thierry: the extension is usually a number, such as *.1 for a section 1 man page
<thierry> Kamion : got it! thanks!
<Kamion> np
<janimo> \who ogra
<Keybuk> daniels: about?
<mvo> ping seb128 
<seb128> mvo: pong
<mdz> elmo: what would be involved in getting Tag: into Ubuntu Packages files?
<mvo> good morning mdz 
<elmo> mdz: pfft
<mdz> morning
<mdz> elmo: how did I know you were going to say that?
<ogra> elmo, did you get my baobab sync request around noon ?
* mvo would like to have translated package descriptions too ...
<elmo> ogra: yes, I did it, it's in new, I'll get to it in a while
<ogra> elmo, thanks :)
<vontrapp> i noticed the middle click content load url behaviour doesn't work in the latest firefox package, saw in the forums that the default behaviour was changed
<vontrapp> however, i am unable to enable it again
<vontrapp> set middlemouse.contentLoadURL to true, but no diec
<vontrapp> s/diec/dice/
<vontrapp> is this possibly related to the default change?
<crimsun> mdz: There's a slight dilemma with compiling vlc (universe) for Breezy. It requires libpostproc-dev (multiverse) to build. I sidestepped this for Hoary by using vlc's distributed ffmpeg, but Debian removed that in the next package revision. It looks like either vlc should be demoted to multiverse or libpostproc* should be promoted to universe.
<mdz> elmo: are you going to follow that with a real answer though?
<sebest> hello, how can we change the keymap using xkb driver , i'd like to use a macintosh fr keyboard (using setxkbmap?)
<mdz> crimsun: vlc should move to multiverse
<ogra> mdz, huh ? since when is it nonfree ?
<crimsun> mdz: ok, that sounds great.
<elmo> mdz: I've no idea, I'll have to look
<bob2> vontrapp: that behaviour changed a year or so ago
<mdz> elmo: oh, who did it for Debian?  I'll ask them
<crimsun> ogra: no, one of its build-deps is in multiverse.
<elmo> mdz: aj
<mdz> elmo: thanks
<ogra> crimsun, yup, i just got that :)
<Nafallo> crimsun: what about ffmpeg's libpostproc-dev? pool/main/f/ffmpeg
<crimsun> Nafallo: that's in multiverse.
* ogra curses his broken X
* Treenaks gives ogra the toasted remains of daniels
<crimsun> Nafallo: (being the precise issue I mentioned :)
<ogra> Treenaks, gah, you toasted him ? who is fixing it now ?
<Treenaks> ogra: you are :)
<bddebian> heh
<ogra> Treenaks, unlikely, heh
<Nafallo> crimsun: hmm, oki. I just noticed the things in the source are everywhere :-).
<jdub> seb128: new gamin! :)
<seb128> jdub: cool, as I was pointing to pitti it should fixes the issues we have for ages
<seb128> jdub: not thanks to DV
<seb128> somebody had to debug and send a patch on the list, he never commented on the bugzilla bug
<jdub> seb128: yeah, john mccutchan has been doing some rocking patches
<Treenaks> gamin will be fixed now? :)
* Treenaks hugs everyone who is responsible for that
<sivang> Kamion: is it ok to just change the sources.list on the hoary chroot to upgrade it to a breezy one?
<sivang> Kamion: (preparing the reproduction environment still)
<jdub> seb128: hrm, lack of url field for web calendars in evo kinda sucks
<jdub> hrm, lack of wrapping in calendar blobls kinda sucks
<Kamion> sivang: yes
<seb128> jdub: don't ask to much, I'm already quite happy to have all my imap boxes correctly listed atm :p
<seb128> s/to much/too much/
* ogra kicks X 
<sivang> Kamion: ok, upgrade is done. What can I do to verify I'm in breezy from debconf's / oem-config point of view?
<Kamion> they do not have a point of view that cares
<Kamion> if you can install oem-config, that's all that matters
<seb128> elmo: intltool (incoming) sync please
<sivang> Kamion: ok, how would I log stuff for you while installing oem-config ?
<Kamion> sivang: I already told you earlier ...
<sivang> Kamion: (thinking of logging the first time install, when apt invokes the text ui dialogs)
<Kamion> 14:22 < Kamion> sivang: OEM_CONFIG_DEBUG=1 DEBCONF_DEBUG='.*' in the environment
<sivang> Kamion: ah cool, I thought there was a difference int he modes
<Kamion> oh, the first-time install has nothing to do with oem-config, so just DEBCONF_DEBUG=developer while running apt
<sivang> Kamion: k
<Kamion> although the more complete set above would do too, it just outputs even more junk :)
<Kamion> you might want to run inside 'script' to get a typescript of the installation
<Kamion> mdz: is libhsqldb-java ok for main, or still pending? it's making my base-config tests difficult
<jdub> Kamion: what are the remaining b0rkages in the way of colony CDs?
<Kamion> jdub: X
<jdub> bogor
<Kamion> also to be honest I just haven't tried daily CD builds for the last few days, 'cos I've been buried in OEMInstaller and InstallerStage2Progress
<jdub> stage2 progress! rad :)
<jdub> how's oem going?
<Kamion> oem-config's in the archive, needs UI love
<jdub> will test when i get home :-)
<Kamion> primarily needs to have the multiple dialogs turned into a single window really
<jdub> how's express going?
<Kamion> oh, and various bugfixes of course
<Kamion> dunno, I haven't really touched it
<Kamion> stage2 progress is tantalisingly close
<jdub> that's going to be rad
<Kamion> mdz had an ubuntu-express prototype; last I heard juanje was poking at it
<jdub> how much do we care about express working on arbitrary casper based cds (for breezy)?
<Kamion> well, it needs to be derivable vaguely sanely
<jdub> i think we'll be able to get some testing love out of the gnome livecd for that sort of stuff
<jdub> i imagine we'll be pretty solidly concentrating on ubuntu only at this stage
<Kamion> I don't think it would be much of a problem to make it generic, although it will probably be GNOME only unless some kind of sensible framework settles down Really Soon Now
<Kamion> but all too much of it is vapourware as yet ...
<sivang> mdz: what do I need to do to get editbugs priviliges again?
<Kamion> oh, hmm, mvo's apt progress branch doesn't send download progress to the status fd :(
<Kamion> so the base-config progress bar sits at 0% for ages ...
<sivang> Kamion: k, got the same behavior. I'm redirecting stderro to a file, hopefully that would include the DEBCONF_DEBUG=developer logs
<sivang> Kamion: now, first dialog question is about 'console-data'
<Kamion> I'll get all this from DEBCONF_DEBUG=developer logs, I just need that
* Kamion -> dinner
<mdz> jdub: ubuntu express may or may not happening; we're at juan's mercy at this point because I don't have the bandwidth for it
<mdz> sivang: /topic
<sivang> Kamion: using apt's log is http://muse.19inch.net/~sivan/oem-config_apt.log, and oem-config which new fails to start at all is here : http://muse.19inch.net/~sivan/oem-config_local_error.log
<sivang> Kamion: bon appetite, I will catch you later or tommorow - going home, laterz
<mdz> sivang: read and acknowledge https://wiki.ubuntu.com/HelpingWithBugs
<mdke> who knows about the linode servers?
<ogra> mdke, henrik or elmo
<mdke> elmo, around?
<mdke> thanks ogra
<mdke> i've rebooted the docteam one and its disappeared
<mdke> surely its not on a dynamic ip
<jdub> mdz: hrm, bummer
<mdz> s/happening/be &/
<maswan> mdz: bandwidth? anything I can help with? :)
<Amaranth> niran: Still haven't decided on the best place to put those checkboxes in gnome-app-install? :)
* sivang -> back
<tseng> hi sivang 
<sivang> mdke: what are the linode servers used for ? 
<sivang> hey tseng , how's it going?
<tseng> good, you
<sivang> mdz: acknowledged
<sivang> tseng: just came back from work, going to try hack an helper function for bonnobu ui apps that need be launchpadized
<tseng> buh, bonnobo
<tseng> have fun.
<sivang> tseng: yeah. Luckily I have some skeleton code in gedit, and pbor was very kind to point me to the important bits
<OddAbe19> any idea when glx will be uploaded to breezy?
<niran> Amaranth, i want them where they are now, i just think it makes the categories look ugly when it pushes them to the side
<niran> i wonder if there's a way to get the cellrenderertoggle to not toggle when anywhere in the column is clicked, just on the check box itself
<niran> but i don't think so
<OddAbe19> any idea when glx will be uploaded to breezy? (so GL stuff will work... ie glxgears, etc...)
<\sh> X
<\sh>           is a lot less broken - it works (well - kubuntu does - for mez)!
<\sh> OddAbe19: when daniels is finished with his work
<Kamion> sivang: ok, the first log definitely exhibits symptoms of debconf breakage; upgrading to 1.4.55ubuntu1 should sort that out
<sivang> Kamion: at least I am happy to know my recreation of debootstrapping work helped
<sivang> Kamion: are you sure I wasn't glancing at the font-config configuration at the first log ?
<sivang> Kamion: (it oocurd to me that I was seing it instead of the actual oem-config)
<Kamion> sivang: oem-config is not relevant to the issue in the first log in any way whatsoever at all
<CarlFK> Kamion - are you cjw? - duh.
<Kamion> CarlFK: yes
<Kamion> CarlFK: (I think we've talked on IRC before ...)
<sivang> Kamion: anyway, I have to leave now - soemone tries to sleep in this room , so good to know that helped you and se you tommorow.
<Kamion> sivang: still investigating the second log, it's kind of weird
<CarlFK> Kamion -  yes - I lost track of who was who
<Kamion> sivang: is oem-config-locale properly installed and configured? if it is, 'dpkg -l oem-config-locale' should have 'ii' at the beginning of the line
<Kamion> sivang: 'dpkg --configure -a' would probably be a good plan
<sivang> Kamion: can I undertake all those tommorow and report ?
<Kamion> sivang: sure, no rush
<Kamion> thanks for the help
<sivang> Kamion: be sure to ping me with furhter instructions should you have those
<Kamion> sivang: oh, the second log with additional OEM_CONFIG_DEBUG=1 would be good, too
<Kamion> CarlFK: I fixed the i386 CD image build issue you reported, by the way; it was a typo in one of the build scripts
<sivang> Kamion: good night then :)
<Kamion> CarlFK: Ubuntu install CD images are built from a cron job that runs at 08:21 London time daily
<CarlFK> Kamion - thanks.  is the rsync server get much trafic, or is it ok if I rsync it each morning?
<Kamion> CarlFK: there's a maximum-number-of-users limit on the rsync server, but if you can get on then it's fine
<CarlFK> Kamion - thanks.  nother thing - if you want a better bug report no probm but here is a quick pic of todays problem: http://pictures.foxshare.net/gallery2/main.php?g2_view=core.ShowItem&g2_itemId=372
<CarlFK> ill be back in 20 min or so...
<luis_> mako: http://www.mit.edu/~mherdeg/pushpoll/
<Kamion> CarlFK: humph, looks like the menu-mapping's screwed up somehow; I'll have a look, thanks
<CarlFK> Kamion - bit more on that menu thing: "exit the base system config" throws the same messages and also loops back to the menu
<Kamion> CarlFK: this is an install in English, right?
<CarlFK> yes
<Kamion> CarlFK: if you could look for a menu-mapping file in /tmp/base-config.* and mail that to me, that'd be good ...
<herve> hello
<herve> seb128, ping
<seb128> pong
<bddebian> wb herve
<herve> I just experienced dia is broken when exporting files to eps using the pango engine
<herve> I'm looking for a patch
<seb128> cool
<herve> not really :-
<herve> (
<herve> ok, dia CVS depends on cairo 0.6 for 2 days now
<herve> I put an option on a CVS checkout
<herve> like in debian experimental
<lifeless> did something break the install-old-version feature of aptitude ?
<lifeless> nm, it was cross dependency hell
<seb128> herve: we have cairo 0.6
<herve> my point :-)
<herve> but not Debian, strange Roland made that checkout
<herve> we are the ones to need it, not Debian :-)
<seb128> Debian got 0.6 today
<herve> ha ok
<seb128> and the dia maintainer uploaded a dia CVS tonight
<herve> hmm... I wonder if we take his package or if breezy can live with this bug
<linescann> jbailey: you got a minute ?
<jbailey> linescann: Sort of, my brains on something at the moment, so if you don't mind a slightly laggy answer.
<linescann> jbailey:np I will run it past you but if it needs to wait tell me to shut up :)
<linescann> jbailey:I was trying to test ltsp for ogra today but could not get ubuntu installed on a IBM HS20 blade
<linescann> 428 dev/console issue after rebooting
<jbailey> linescann: Is that one of their powerpc blades?
<linescann> no twin Xeon
<jbailey> Where does that 428 come from?  The kernels themselves provide /dev/console automatically.
<linescann> pivot_root no such file or directory then 428 dev/console and kernel panic
<Mez> linescann, you using SATA drives?
<Mez> or a USB scsi drive?
<Mez> or a normal SCSI drive
<linescann> Mez: SCSI
<seb128> elmo: can you sync gdesklets-data (0.35.2-2) gnome-build (experimental) intltool (0.34.1-1) ?
<Mez> linescann, for some reason, it tries to pivot_root before the SCSI drive is ready, which causes the problems
<linescann> Mez: The solution is......?
<Mez> linescan there isn't one at the mo
<Mez> but I do remember someone is working on it
<linescann> Mez: rats, I was really hoping to get some good feedback to ogra and mdz
<Mez> linescann, ??
<linescann> I got 6 classrooms of thin clients sitting idle and was going to do some testing for them
<mdz> linescann: that would indicate that your SCSI driver isn't getting loaded in the initrd
<mdz> linescann: you can force load it by editing /etc/mkinitrd/modules and regenerating the initrd, or you can try jbailey's initramfs stuff
<jbailey> linescann: If that does solve the problem, please let me know which module wasn't detected right.
<Riddell> Mez: with respect to backports how is g++ transition done?
<linescann> jbailey: I will try in the morning.  What values am I look for ?     MODULES=
<jbailey> linescann: Do you know which driver that you're missing?
<Mez> Riddell, normally it'll just depend on g++ not a certain version
<Mez> so when rebuilt, then it's rebuilt
<jbailey> linescann: I'm not familiar with the ltsp install, so I don't know if you have a working system on the machine already, or...
<Mez> or built with hory version of 4.0
<Riddell> Mez: but the library names have changed
<linescann> jbailey:  Clean attempt at installing Ubuntu
<Mez> Riddell, some of them have
<jbailey> linescann: Hoary?
<Mez> and then it's just a libbla | blalib
<mdz> jbailey: he's just attemptnig a hoary install at this point; ltsp has not entered the equation
<linescann> Yep
<jbailey> mdz: Cool, thanks.
<herve> seb128, dia 0.94.0+CVS20050731-1 doesn't contain the changes for cairo 0.6.0
<jbailey> linescann: So before the installer reboots, we need to figure out which scsi module you need, and add it to the the initrd.
<jbailey> linescann: Or we can boot the instller and mount the partition
<linescann> jbailey:  Not at the servers now.  You around tomorrow ?
<jbailey> linescann: Yup.  In what timezone are you?
<Kamion> jbailey: that's what rescue mode's for
<linescann> In the UK so about 7 infront
<linescann> I think
<Riddell> Mez: but if you have a hoary KDE package depending on kdelibs4c2 that'll break up all the upgrading preferences (and any KDE applications not recompiled for it)
<jbailey> linescann: I'm in Eastern Canada, so 5 in front.
<linescann> cool.  I will catch you sometime tomorrow
<jbailey> linescann: Cool.  See you!
<Mez> Riddell, it wont break though ... cause it'll be in $shlibs:Depends... wont it
<linescann> just going to try and find out what SCSI controller is on the Blades
<Mez> so it wont depoend on 4c2
<Mez> just 4
<jbailey> Kamion: But.. But..   It's not a REAL os unless you need to reinstall it from time to time!
<jbailey> linescann: We'll be able to tell from the rescue mode.  If you installed it succesfully, the installer had to have detected it. 
<Riddell> Mez: since the kdelibs4 package uses c2 then it will depend on c2
<linescann> jbailey: sure....The real servers run SuSE 9.2 and are using mptscsih
<Mez> hmmles
<Mez> will think bout that
<Mez> Riddell, thats an issue I dodnt think of, couldnt the control be changed dependdent on the auto * ?
<jbailey> Hmm, it ought to pull in mptbase and mptscsih.  I wonder why it doesn't work.
<dholbach> hi
<seb128> hey dholbach :)
<linescann> Over to you on that one Sir :)
<ogra> heh
<Riddell> Mez: sounds like a very ugly hack.  what's changed with auto*?
<Mez> Riddell, the version - so check for hoary/breezy versions
<Mez> speak to mdz
<niktaris> hi, anyone got some expirience with build the ubuntu live cd?
<linescann> jbailey:  Thanks for your time.  I will catch you tomorrow
<linescann> mdz,ogra:  Hopefully we can get you some testing time tomorrow :)
<ogra> linescann, YAY !!
<linescann> ogra: Have a damn fine evening and I will catch you tomorrow
<ogra> linescann, you too :)
<daniels> Keybuk: no
<Keybuk> daniels: oh
<Keybuk> I had a cute bunch of xkb problems for you to look at
<bddebian> daniels: Hey I have been meaning to ask you.  Anything a relative n00b can help you with at all or is it all pretty high-level stuff?
<Keybuk> errors on stdout, and lots of "no keycode for blah" stuff
<Keybuk> but it can wait
<daniels> Keybuk: spam it to me in /msg, or email me
<daniels> Keybuk: i've just woken up, and won't be around 'till later
<Keybuk> ok, I'll hang on til later
<bddebian> Hmm, I'll take that as a no. :-)
<daniels> whoops, didn't even see bddebian's question.  oh well.
<Lathiat> heh
<dholbach> daniels: <bddebian> Bah, daniels hates me too
<ogra> yes, he is very sensitive... :=)
<doko> elmo, mdz, Kamion: libatomic-ops needs a sync from unstable. it's a new upstream, which doesn't FTBFS with gcc-4.0. strictly speeking, it's only necessary for a no-release arch (ia64), so it doesn't effect our primary archs
<niktaris> is matt zimmerman in the house?
<doko> elmo: please sync sdl-mixer1.2 smpeg speech-tools festival gtkmm2.0 from unstable (after the dinstall run from Aug 2)
<doko> elmo: please sync wtfk from incoming
#ubuntu-devel 2006-07-31
<gnomefreak> ty slomo_ i was getting ready to do that ;)
* desrt hits a wtf
<desrt> taking a cpu offline using cpu-hotplug causes my laptop's power consumption to -increase-
<HrdwrBoB> likely because the cpu then clocks itself to fullspeed
<desrt> i think the two cpu's have their speeds locked together
<desrt> (dualcore)
<desrt> ok
<desrt> i think the problem is more like when the CPU goes offline it runs a busyloop
<Amaranth> is ubuntu-minimal supposed to be autoremoved?
<jdub> Amaranth: use upgrade, not dist-upgrade :-)
<Amaranth> jdub: No, ubuntu-base got dropped and it was the only thing depending on ubuntu-minimal.
<jdub> Amaranth: ah, using aptitude?
<Amaranth> jdub: No, was reading changelog, saw ubuntu-base didn't exist anymore, removed it. :)
<Amaranth> synaptic then shows ubuntu-minimal and all it's dependencies as autoremovable, nothing seems to pull them in.
<Amaranth> I'm thinking if I were to do a fresh install it would be one of those marked as manually installed so this wouldn't be a problem, I just marked it to be reinstalled so it would be in manually.
<zul> mdz: should i send the announcement to -devel or -devel-announce?
<jdub> zul: hey, i saw you upload xen love yesterday or so - rad!
<zul> jdub: yep...working version was uploaded today/yesterday ;)
<Hobbsee> zul: yay!
<jdub> did it build?
<zul> yep..
<zul> both userland and xen-kernel
<jdub> rad
<jdub> onya!
<zul> amd64 is next
<ajmitch> good work
<zul> thanks..
<zul> just have to make it better now..
<jdub> is it in a works-but-not-Just-Works state atm?
<zul> jdub: i was using it this afternoon
<zul> works but needs some tweaking of course and testing other than me
<jdub> hrm, i can't see the xen-image
* ajmitch should test on the laptop :)
<zul> hmm...must not be in the archive yet
<jdub> zul: is xen-utils-3.0 supposed to conflict with xen-utils or xen-tools?
<jdub> Setting up xen-utils-3.0 (3.0.2+hg11127-2) ...
<jdub> ldconfig: /usr/lib/libblktap.so.3.0 is not a symbolic link
<jdub> 
<jdub> heh
<zul> xen-tools creates the images...xen-utils is the userspace stuff
<zul> eh?
<jdub> $ ls /usr/lib/libblktap.so*
<jdub> -rw-r--r-- 1 root root 11K 2006-07-29 20:57 /usr/lib/libblktap.so.3.0
<jdub> -rw-r--r-- 1 root root 11K 2006-07-29 20:57 /usr/lib/libblktap.so.3.0.0
<jdub> 
<zul> grrr..
<jdub> oh, that's an unfortunate package name weirdness
<zul> im going to go shoot myself ;)
<jdub> nono! don't do that!
<zul> jdub: works for me...i dont get that message
<zul> https://wiki.ubuntu.com/XenOnEdgy
<zul> of course when..xen-image gets in the archive
<jdub> zul: do you have two files, or a file and a link?
<zul> two files
<jdub> yeah, that's still b0rk
<zul> jdub: what if you run xm?
<jdub> zul: i don't have xen-image yet :)
<zul> just to see if it runs :)
<jdub> zul: things using that lib will run fine, it's just an unnecessary duplicate file
<jdub> it runs and b0rks:
<zul> ah ok
<jdub> ERROR: Could not obtain handle on privileged command interface (2 = No such file or directory)
<zul> ok ill look into it thanks jdub
* infinity quietly processes xen-source from the NEW queue while this conversation's going on...
<jdub> heh
<infinity> zul: And yes, please fix the duplicae lib.  That's not only bad form, it's also wrong.
<zul> ok ill do that
<jdub> infinity: btw, are there old things in the NEW queue atm?
<infinity> jdub: Define "old"... (are you looking for anything specific?)
<jdub> infinity: last-exit?
<jdub> there were some grumblings about that a few days ago
<infinity> jdub: Oldest thing is 2 weeks old, so not really all that old.  last-exit is 12 days old, yes.
<infinity> jdub: I only do source NEW processing when I'm in the right frame of mind, cause it requires license checking, etc.
<infinity> jdub: And I suspect Kamion and Keybuk are in the same boat.
<jdub> yeah
<bddebian> Hi infinity
<Hobbsee> infinity: which is never? :P
<infinity> Hobbsee: No, I do it occasionally.  I know Keybuk's done some recently..
* Hobbsee wonders about the status of dapper's kdenetwork - is that sitting in a queue somewhere, forgotten about?  do you know, infinity?
* Hobbsee hasnt checked today
<infinity> The NEW queue is very short right now, and nothing's older than 2 weeks, so I'm not sure that "never" is fair.
<Hobbsee> infinity: i'm kidding, cant you see the :P?
<infinity> Hobbsee: Ahh, that's in dapper's unapproved queue.  Did it have approval from mdz to be uploaded?  Can you forward that approval to the ubuntu-archive mailing list?
<Hobbsee> infinity: it did, i'd have to look up the logs for it.
<Hobbsee> infinity: mdz eyeballed the patch, talked to the upstream maintainer, then ack'd it
<infinity> Hobbsee: Right, well please either dig up said approval, or just get mdz himself to do the queue manipulation for it.
<jdub> DIG UP THE APPROVAL!
<jdub> i want to see some h0t dead approval action
<Hobbsee> infinity: yay!  found the log :)
<infinity> Hobbsee: Hot stuff.  Mail away, and I'll accept the upload.
<Hobbsee> infinity: gah. /me looks up where the ubuntu archive mailing list is too.
<infinity> ubuntu-archive@l.u.c, I believe.
<infinity> Yup.
<infinity> Wow, we get a lot of asian span to that list.
<infinity> spam, too.
* infinity never really noticed until he checked the archives.
<Burgundavia> infinity: all of ubuntu tends to get lots of asian spam, including various people like myself
<jdub> anyone use nullmailer?
<infinity> jdub: Have in the past.  Not much to "use" about it, really.
* Hobbsee wonders why it refuses to work
<jdub> infinity: did you use tls or smtp auth with it?
<infinity> jdub: I tend to prefer ssmtp, if the goal is just to have a /usr/sbin/sendmail that gets stuff off the host ASAP.
<jdub> i need something that queues and can do tls
<infinity> jdub: Oh, you're actually running nullmailer on port 25?  Yeah, don't recall ever bothring to do that.
<jdub> ssmtp doesn't seem to queue
<jdub> infinity: client auth, i mean
* jdub tries nullmailer
<jdub> long time since i've usedi t
<infinity> Anytime I actually need an MTA that queues and does useful things, I just use a full-featured on, like exim4 or postfix.
<jdub> yeah
<Hobbsee> infinity: sorry to be a pain, but the email is screwing up for some reason.  pastebin of the email is at http://pastebin.ca/107657
<TheMuso> I don't think nullmailer supports TLS. I am happy to be proven wrong however.
<jdub> i'm hoping to remove postfix to ramp up laptop battery life
<Hobbsee> yay - longer battery laptop life is good!
<jdub> TheMuso: yeah, doesn't seem to
<jdub> bummer
* jdub considers whether he should soften the tls requirement on his server
<Amaranth> anyone know what i can do to debug suspend problems?
<Amaranth> nm, suse wiki has interesting things
<infinity> Hobbsee: Okay, that's good enough for me, I guess.
* infinity accepts the upload.
<Hobbsee> infinity: thanks.  there is a longer log, but it took a while - you're free to delve into fabbio*ne's logs for it though
<bddebian> Anyone know what is up with lamont these days?  I haven't "seen" him for ages?
<infinity> bddebian: Busy working, mostly.
<Hobbsee> infinity: thanks
<Hobbsee> yay!  found a powerpoint
* Hobbsee hides in a corner of  the room
<bddebian> infinity: Do you think he'd care if I did his Universe merges?
<Hobbsee> bddebian: no, i've already done some, and yet to be killed for it
<bddebian> :-)
<bddebian> Actually Kamion and Keybuk are probably going to kill me for all the sync requests :-)
<Hobbsee> bddebian: no they wont.
* Hobbsee wonders if the ralink drivers will ever make it into l-r-m
<bddebian> Probably too early for mdz yet eh?
<Burgundavia> bddebian: it is 8pm here, assuming he as home
<Burgundavia> s/he as/he is at/
<bddebian> Oh, hmm
<bddebian> Hi Burgundavia btw :-)
<Burgundavia> hey
<bluefoxicy> HOBBSEE I STILL OWE YOU A SMITE >:|
<Hobbsee> bluefoxicy: whatever for?
* Hobbsee smites bluefoxicy 
<bluefoxicy> But I am not really that angry now and really don't fele like it, so you get off easy.
<bluefoxicy> >:| for going psycho on me this morning
<bddebian> Hobbsee: Hence why he brought it up :-)
<Hobbsee> heh
<purserj> good afternoon/evening/morning all
* Hobbsee would never put herself into a position where bluefoxicy had the opportunity to give her a smite.
<purserj> I have a question regarding the breezy livecd installer, I need to preseed the xconfig stage however I can't seem to find where I can do that
<Burgundavia> bluefoxicy: all I remember was you being less than respectful
<Burgundavia> purserj: in general, this is not a support channel. there also was no breezy livecd installer. Do you mean the text installer, or the dapper livecd one?
<purserj> Sorry, I meant the bootstrap process that the livecd goes through.
<bluefoxicy> Burgundavia:  I fail to see in what way; the line of thinking was the same line this girl was following http://linux.slashdot.org/comments.pl?sid=192551&cid=15806787
<bluefoxicy> at any rate enough
<purserj> Sorry I realise that this is not a support channel, however the documentation covering this particular aspect of Ubuntu seem s to be sparse at best so I thought I would ask the question here. I had asked a couple of ubuntu devs and they recommended I come here and ask the question
<Burgundavia> purserj: hmm, I know nothing of how that works, sorry
<purserj> thanks anyway
<Burgundavia> good luck
<purserj> thanks, I had been told either Kamion or daniels might know something about it
<Burgundavia> daniels no longer works for canonical, but Kamion is a good bet
<purserj> ta
<Burgundavia> if you are playing with the livecd, Mithrandir is a good choice
<ajmitch> but he won't be around for at least a couple of weeks
<Burgundavia> ah, true, lucky bastard just got married
<ajmitch> s/just got/is getting/
<ajmitch> next weekend, iirc
<bluefoxicy> heh.
<bluefoxicy> I'm not gonna get married
<bluefoxicy> Apparently it pushes you into the next tax bracket when you both have jobs, so your taxes go up.
<purserj> I'll wait around if thats okay, see if I can catch Kamion 
<bluefoxicy> Plus I don't think it's legal in thiss tate.
<purserj> bluefoxicy, thats easily taken care of, have kids, watch the tax brackets fall away
<bluefoxicy> purserj:  1)  I hate kids; 2)  I'm running every possible scenario in my head right now but I don't see any of them resulting in small derived copies of my DNA
<ajmitch> all this is suitable for -offtopic
<bluefoxicy> I think I'm still banned from there
* bddebian can't imagine why
<Hobbsee> bluefoxicy: did you ask to be unbanned?
<bluefoxicy> Hobbsee:  no; I assumed it would fall off eventually, or that my hostmask etc would eventually change like with #grsecurity
<purserj> Hobbsee, so's my sister
<Hobbsee> bluefoxicy: doesnt appen.
<bluefoxicy> Oh.  Well then yes somebody probably needs to unban me before I can get back in.
<Hobbsee> quite likely.
<Hobbsee> anyway...
<desrt> oh man
* desrt cries
<Burgundavia> desrt: good evening?
<desrt> edgy just ate my laptop.
<ajmitch> desrt: your macbook?
<desrt> ya
<desrt> it's in pain.  bad.
<desrt> no l-r-m yet, i guess
<tritium> bluefoxicy: I'm not seeing the ban that's keeping you out
<bddebian> Heya tritium
<tritium> hi bddebian 
<bluefoxicy> tritium:  oh, seems gone.  Wasn't gone when I started my client
<tritium> bluefoxicy: okay, I had just opped up to unban you :)
<jdub> bluefoxicy: i find your latest blog post extraordinarily offensive
<bddebian> bluefoxicy: You have a blog?
<Hobbsee> bddebian: http://bluefox.kicks-ass.org/blog/
<bluefoxicy> jdub:  it is not meant to be friendly, it's meant to make a point.  Opinions you don't agree with are naturally offensive.
<bluefoxicy> besides, this isn't the place to discuss such things.
<bddebian> And on that note, guess it's time to go to bed.  Gnight folks
<jdub> bluefoxicy: that is not true. there are many things i don't agree with that are not offensive to me.
<HrdwrBoB> in any case it's not even remotely an open source problem
<HrdwrBoB> it's a common theme across most technical fields
* Hobbsee notes that the comments to that blog post are off.  probably a good idea.
<jdub> HrdwrBoB: (apart from us having 1.5% females vs. 25% in proprietary software industry)
<Burgundavia> HrdwrBoB: it appears to be a worse problem in the oss world
<jdub> HrdwrBoB: (that indicates a localised problem)
<HrdwrBoB> true
<HrdwrBoB> though I would wager that's because women will do it for money, but not because they love it (in general)
<Burgundavia> I think more women is a great thing, because they appear to be interested in different things. I hate stereotypes, but I think it is true
<HrdwrBoB> jdub: 'industry'
<HrdwrBoB> does that include non-technical people?
<Burgundavia> HrdwrBoB: if it does, it shows us something
<Burgundavia> OSS is bad at keeping non-geeks and non-technical people
<Burgundavia> oh, and attracting them as well
<HrdwrBoB> private industry has 'sales'
<HrdwrBoB> 'marketing'
<HrdwrBoB> much deeper levels of management
<jdub> HrdwrBoB: read the flosspols report
<Burgundavia> thus with a smaller absolute "market" of women to attract, we are doing very badly attracting the "soft" side
<HrdwrBoB> jdub: thanks
* Hobbsee wonders who "the other girl" is
<jdub> HrdwrBoB: has lots more information about the context of the research
<jdub> and recommendations for things to do to improve the situation
<jdub> (a direct inspiration for GNOME's WSOP)
* Amaranth wonders if Hobbsee is one of the ones talked about
<Hobbsee> jdub: most likely due to the fact that a lot of girls wont put up with high levels of shit and sexual harassment.  that's why your women numbers are down.  and the fact that if the person gets harrassed here, nothing gets done, and they can do it ove rand over - whereas in propriatary software, the guy loses his job, and finds it incredibly hard to get another one
<jdub> Hobbsee: actual research results in flosspols :-)
<Hobbsee> Amaranth: ah, yeah, i would be - based on the fact that there arent that many women in here anyway :P  process of elimination
<Hobbsee> jdub: true.  that's my take on it, anyway
<Amaranth> Hobbsee: you're the only one i know of, actually
<Hobbsee> jdub: i did see those research results
<Hobbsee> Amaranth: yeah, exactly.  simira wasnt there
<Hobbsee> well, wasnt talking
<Burgundavia> Hobbsee: given what passes for discourse in other oss communities, if even a small percentage of that comes out as sexist, I am not surprised if a woman would just up and leave
<jdub> Hobbsee: possibly getting married at the time
<Hobbsee> jdub: yeah, that's what i thought
<Hobbsee> Burgundavia: quite likely
<Hobbsee> hi BenC 
<HrdwrBoB> possibly not sexist
<HrdwrBoB> but there are high levels of abuse just in general
<HrdwrBoB> very ..er.. vocal. arguemnts
<jdub> HrdwrBoB: a lot of the sexism is unintentional, but it's there
<HrdwrBoB> and there's no checks and balances
<jdub> or cheques
<imbrandon> moins ladies and gents , hows the -devel world this great day ?
<HrdwrBoB> isn't it a 'check' as in 'to check' not a cheque as in money?
<jdub> HrdwrBoB: no :-)
<HrdwrBoB> my research disagrees
<HrdwrBoB> but no matter
<ajmitch> doko: good news, ironpython compiles with a patched copy of the mono packages we have, and I have a (very basic) package working
<imbrandon> ajmitch or crimsun either of you guys arround ?
<imbrandon> err wrong chan
<Hobbsee> hi again all
<desrt> Hobbsee; goodday
<Hobbsee> desrt: :)
* desrt just took the edgy plunge
<ajmitch> desrt: got anywhere with the laptop?
<desrt> ajmitch; things are much better now
<dholbach> good morning
<ajmitch> that's good 
<desrt> ajmitch; l-r-m missing was my fault
<Hobbsee> desrt: yay
<ajmitch> ah, that can cause issues if you need it
<desrt> ajmitch; and i managed to repair ooo by stracing it to find out what file it was missing and copied it over from my other box
<ajmitch> what was missing?
* ajmitch hasn't seen it die on his machines here
<desrt> /etc/openoffice/sofficerc
<desrt> oh - btw.  there is a symbol conflict in the madwifi drivers... so madwifi-ng users get pwned
<ajmitch> there's probably a bug open about OOo
<ajmitch> that info could be added there
<crimsun> yep, bug 54590
<Ubugtu> Malone bug 54590 in openoffice.org "openoffice.org-* doesnt launch (edgy)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54590
<ajmitch> thanks crimsun 
<desrt> wlan and new_wlan both have a symbol ether_sprintf
<desrt> i think i'll confirm that bug?
<sivang> morning
<Hobbsee> hi sivang!
* sivang hugs Hobbsee 
* Hobbsee hugs sivang in return.  how are you doing?
<sivang> Hobbsee: going to PM
<desrt> Stefan Potyra <daemon@poleboy.de>
<desrt> does anyone know who this is?
<ajmitch> sistpoty, one of the MOTUs
<ajmitch> why?
<desrt> he said on revu that he uploaded a package of mine on july 20 but it doesn't appear to have hit universe yet
<ajmitch> might be stuck in NEW
<desrt> i checked soyuz build logs -- no hits for it
<pitti> Good morning
<Hobbsee> hi pitti 
<desrt> pitti; word up.
<ajmitch> desrt: check on https://launchpad.net/distros/ubuntu/edgy/+queue
<ThunderStruck> morning
<desrt> ajmitch; ah.  there it is.
<desrt> what is this NEW queue?
<pitti> hi Hobbsee, moin desrt 
<desrt> moin moin
<desrt> what is moin, anyway?
<ajmitch> desrt: packages that have to be checked by the ftp masters for licensing, sanity, etc
<imbrandon> desrt: packages that are new to ubuntu that havent been approved^Wlooked over yet
<ajmitch> everything new into ubuntu (and debian) goes through this process
<desrt> i see.
<desrt> sounds like a generally good idea
<desrt> the more i learn about all of this insane infrastructure the more convinced i become that things are done in a good way
<desrt> which is pretty much the opposite from what you'd expect, given how everything else on earth works :)
<imbrandon> lol
<desrt> it's like working at a fast food place
<desrt> the more you learn about it the less you want to eat the food
<desrt> :)
<Hobbsee> desrt: gives you an idea of how hard it is to stick bad software in the repos, etc
<Hobbsee> and of quality control
<desrt> sort of reassuring that it takes more than one person to get a package into the distro
<ajmitch> desrt: yeah, I have to see what the ftpmasters say about ironpython
<desrt> python seems slightly pwned in edgy atm.
<desrt> everything with 'py' anywhere in the name seems held back
<ajmitch> only because of the transition to the new policy
<ajmitch> where pythonX.Y-foo gets dropped in favour of python-foo
<ajmitch> desrt: it should all be installable
<dholbach> can somebody of the archive team *please* get jokosher out of binary new
<desrt> crikey.  still stuck in purgatory?
<Amaranth> dholbach: ouch, it's been in there for weeks hasn't it?
<dholbach> Amaranth: some days, yes, but I really don't envy the archive administrator's job
<Amaranth> I've got an idea for the GNOME and KDE (and XFCE menus).
<sivang> oh my god the ZeroConf thread..
<Amaranth> Merge the contents of all 3 into one .menu file and in the .directory files for the KDE/GNOME/XFCE specific things put in OnlyShowIn or NotShowIn lines
<Amaranth> oh, and put these .menu and .directory files into a separate package that all 3 desktops depend on
<Amaranth> Of course I'm not sure how any menu editor that currently exists would handle this. :)
<ajmitch> sivang: is it dead yet?
<sivang> ajmitch: Seveas requested it's death, or relocation to sounder, not sure what the outcome is :)
<Seveas> sivang, it's been replaced with the mono thread :/
<ajmitch> Seveas: as long as that thread doesn't go on for a month as well
<sivang> Seveas: I've seen :-/
<YokoZar> Is there a security channel?
<pitti> YokoZar: not an ubuntu specific one
<YokoZar> There were recent updates to libfreetype, I assume security ones.  Do I need to recompile my packages (Wine) that depend on libfreetype?
<YokoZar> The update manager didn't display the changes in the package
<pitti> YokoZar: no, if a package depends on a library package, then it does not have a code copy and thus does not need a separate update
<pitti> YokoZar: that's the main point about shared libs :)
* desrt contributes a few drops to the firehose
<YokoZar> pitti: what bothers me is that the -dev package got updated too
<pitti> YokoZar: that's unavoidable
<Warbo> Hi, I have tried to file a bug for nvidia-glx but it isn't in Launchpad. Am I in the right place?
<YokoZar> pitti: I think I understand why
<pitti> YokoZar: we can only update a complete source package (it gets a new version), and thus all the binary packages produced from it get a new version
<YokoZar> Yeah, I guess I know that firsthand from my packages, heh
<pitti> Warbo: you should be at https://launchpad.net/distros/ubuntu/+source/nvidia-glx/+bugs
<YokoZar> Still, shouldn't something be displayed when I click the changes tab in the update notifyer?
<pitti> YokoZar: changelogs seem to be broken ATM, that needs a fix by mvo
<YokoZar> ahh
<Warbo> pitti: Ah thanks, it didn't come up in a search. I even went through the list of packages page by page :)
<pitti> YokoZar: read the USN emails in the meantime, or the USN RSS feed or so
<YokoZar> Thanks dude
<ajmitch> pitti: I think it's l-r-m, not nvidia-glx
<ajmitch> but it's too late to tell warbo, oh well
<pitti> ajmitch: well, above URL has a fair number of bug reports
<desrt> heh.
<pitti> ajmitch: but you are right, l-r-m is the source now
<ajmitch> and no source package in ubuntu
* desrt went through this _exact_ through process in his head a few minutse ago :)
<ajmitch> we'll check with the l-r-m overlords as to whether they should be reassigned 
<desrt> seb128; right click on your desktop.  "create new folder"
<seb128> desrt: hi
<desrt> hi :)
<ajmitch> desrt: yes, it doesn't show ,hit f5
<desrt> ajmitch; or ^R
<desrt> ajmitch; known bug?
* ajmitch had fun with nautilus not showing new stuff earlier
<ajmitch> I haven't filed it, would be worth looking for it
<desrt> k.  i'm searching now
<desrt> i'll file it if i don't find anything
<seb128> desrt: http://bugzilla.gnome.org/show_bug.cgi?id=348097
<Ubugtu> Gnome bug 348097 in File and Folder Operations "need to refresh the view to get a new directory listed" [Normal,Unconfirmed]  
<desrt> ah.  great.  i won't bother you with an ubuntu bug then :)
<seb128> ;)
<desrt> there comes a time in every boy's life where he has to go to sleep.  in fact, there are many such times.  now is one of those times for me.
<desrt> night night, h4x0rs
<pitti> desrt: sleep well
<seb128> 'night desrt
<ajmitch> night desrt 
<pitti> seb128: btw, I did some cleanup to the apport-gtk dialog layout in bzr head
<pitti> hey sabdfl
<sabdfl> moin moin pitti
<seb128> pitti: ah, nice, I'll try that later :)
<purserj> In case Kamion gets my ping from earlier, I'd liike to withdraw it, found what I was looking for
<pitti> mvo: do you think you can clean up the confusing icon/tooltips for u-n soon? (both the 'new packages' and 'crash reports' icons have 'crashreport detected' as tooltip)
<mvo> pitti: oh? I have not noticed that
<Kamion> purserj: have a look at the kickseed source, handlers/xconfig.sh; it should give you an idea of which debconf questions you need to preseed
<Kamion> dholbach: jokosher done, sorry for the delay
<Kamion> purserj: oh, ok, fair enough :) (was reading in scrollback order ...)
* dholbach hugs Kamion
<dholbach> Kamion: thanks a lot
<heno> can anyone tell me aprox which versions of xorg and compiz are going into edgy? (I need that for the compiz-mag project)
<purserj> Kamion, thanks, I actually found what I was looking for in the casper-udeb
<dholbach> does anybody know how I can get netstat to display full hostnames?
<infinity> dholbach: Go numeric, and post-process the output. :)
<dholbach> infinity: thanks, but I just found the defaulthost in the source of that applet :)
<Kamion> dholbach: re infinity's postprocessing suggestion: a useful generic way to do that sort of thing is to install libadns1-bin and pipe stuff through adnsresfilter
* dholbach installs and tries
<dholbach> thanks Kamion for the advice
<Kamion> infinity: did you get round to the dapper livefs builds?
* Kamion wants to start beating on that today
<infinity> Kamion: If I say yes, and then do so right now, will you notice the timestamps?
<Kamion> infinity: maybe ;-)
<Kamion> (but I won't care much)
<Kamion> evand: I'll have a look at that libxml2-udeb patch now
<Kamion> evand: (revu isn't so useful for main packages)
<infinity> Kamion: Also, neat trick with adnsresfilter.  Where'd you stumble on that one?
<Kamion> infinity: Ian probably mentioned it ages ago (he's upstream)
<infinity> Ahh, so I can complain to him directly about the lack of manpage. :P
<Kamion> :-)
* infinity goes to poke at the dapper livefs thing.
<infinity> Kamion: Are we bothering to do point-releases on the non-release arches (at least, for the desktop CD)?
<Kamion> infinity: probably not
<Kamion> IIRC we didn't really release those first time round anyway ...
<infinity> Not so much, no.
<infinity> They were on cdimage, I think, but definitely not on releases.
<infinity> I could be wrong, they may not have been built at all.
<Kamion> http://cdimage.ubuntu.com/ports/releases/dapper/release/
<Kamion> infinity: but I'm not convinced they were ever actually tested
<infinity> yeah, just got there.
<infinity> I doubt they were.
<Kamion> oh, hey, and that has no desktop CD.
<Kamion> perfect.
<infinity> I just got a CD-ROM for my hppa in the mail today.
<infinity> And I'm pretty sure I'm the one who's supposed to care about the hppa livecd.
<infinity> So, yeah.  I'll just fiddle with the other 3 arches. :)
<infinity> Uhm, yeah.  the suite is hardcoded right now.  Woo.
<infinity> That's easy enough to fix.
<infinity> Then to make -updates and -security get pulled in for testing, and we're golden.
<pitti> infinity: if I changed pkg-create-dbgsym to not put the .ddebs into the .changes file, do you think it would hurt us to install it into the buildds already? with that, I have time to fix resulting FTBFSes
<infinity> pitti: Yeah, that seems fine to me.
<pitti> infinity: after we have that, we might even discuss some cowboying (moving the .ddebs to people.u.c, or so)
<infinity> Yeah, I can cowboy something at some point. <nod>
<pitti> infinity: ok, then I do this modification, upload it, and ask Colin for promotion to main
<infinity> It'd just be duplication of the existing translation cowboy.
* infinity ponders for a moment.
<infinity> Kamion: Snag.
<infinity> Kamion: To make this test run work, I'll actually have to make the livefs build script do an update and upgrade. :/
<infinity> Kamion: Since you can't debootstrap from multiple sources.
<infinity> Kamion: (Well, unless nothing in base has changed)
<Kamion> infinity: good point :-/
<infinity> Kamion: Oh well.  I'll be ready to test that scariness in a few.
<pitti> Kamion: can you please promote pkg-create-dbgsym to main? It's one of our edgy specs, and a native Ubuntu package written by me, so there's not much point in a MIR, at least if that was written by me
<pitti> Kamion: if you want someone else to review the package, I'll ask someone
<pitti> Kamion: (once you agree, I'll seed the package to supported)
<Kamion> pitti: ok, after this publisher run; please go ahead and seed it
<pitti> Kamion: thanks, doing now
<Keybuk> doko: openoffice.org-draw missing replaces for openoffice.org-core
<doko> Keybuk: which version?
<Keybuk> current
<doko> edgy?
<Keybuk> yes
<infinity> Kamion: Well, whattayaknow, I'm not an idiot.
<infinity> Kamion: Looks like it works.  Just going to wait for it to actuall finish and roll it out to the other buildds for you.
<Kamion> cool, thanks
<pitti> Kamion: seeded in all 4 derivatives
<Kamion> thank
<Kamion> s
<infinity> doko: Of course, if that's true of edgy, it's probably also true of dapper-updates.
<infinity> s/updates/proposed/
<jono> hi all
<doko> infinity: I don't think so: openoffice.org-draw does have a conflict with -core (<< 2.0.3-3). 
<doko> Keybuk: from which version did you upgrade?
<Keybuk> whatever was in edgy before
<Keybuk> *checks*
<Keybuk> I had 2.0.2-2ubuntu12
<Keybuk> and installed 2.0.3-3ubuntu4
<Keybuk> (of draw)
<Keybuk> installing same version of -core
<Keybuk> replaced same version also
<shenki> Keybuk: for me atleast, the conflict was because -core and -draw both contain /usr/lib/openoffice/program/libflash680li.so
<Keybuk> shenki: me also
<Keybuk> doko: lies
<Keybuk> doko: openoffice.org-draw does not contain a conflict with -core
<Keybuk> it conflicts with -draw (which is entirely useless :p)
<Keybuk> thinko?
<doko> ohh, I see: Conflicts: openoffice.org-debian-files, openoffice.org2-draw (<< ${Source-Version}) openoffice.org-core (<< 2.0.3-3)
<doko> missing comma ...
<mjr> 39
<infinity> Whoops.
* infinity prepares for another day of the buildds being hammered in both dapper and edgy.
<doko> I love the control file parser ...
<doko> infinity: no, I'll disable the import of the language data, nothing did change, so it should be faster.
<infinity> doko: Erm, how's that work?
<doko> infinity: I don't build them
<infinity> ... but the resulting binaries don't end up different?
* infinity wonders if there's a serious failure to communicate on this one.
<infinity> doko: Or are you just talking about the -l10n source?
<infinity> doko: I guess what I'm confused about is that if a binary package is directly built from a source package (as we, y'know, tend to do), how can you need to build something on one upload, and not the next? :)
<doko> infinity: no; the openoffice.org package creates .po files in debian/l0n, which pkgstripstranslation saves. they don't touch the binary packages. if pkgstriptranslations doesn't find them, the packages are not touched
<infinity> doko: Ahh, I see what you mean.  Of course, that means a security update would also not build those, unless someone remember to turn it back on.
<infinity> (Not that I can imagine a security update touching those strings, but... It's happened in the past, oddly enough)
<janimo> infinity: are the livefs builds good now?
<janimo> xubuntu is still oversized
<infinity> janimo: For which dist/release?
<infinity> janimo: I'm fiddling with dapper.1 testing right now.
<janimo> edgy daily-live
<infinity> janimo: Ahh, no idea what the deal is with edgy right now.
<infinity> janimo: Oh, it's uninstallable.
<infinity>   xubuntu-desktop: Depends: gnome-accessibility-themes but it is not going to be installed
<infinity> Hence, no new livefs for you.
<janimo> infinity: I see
<infinity> janimo: Oh, actually, today's daily succeeded.  So the next cdimage daily should fix you up.
<infinity> janimo: That paste was from yesterday's log.
<janimo> ok, since I thought I fixed xubuntu-desktop yesterday
<janimo> thanks
<doko> infinity: Agreed, but does a security update touch the language data?
<infinity> doko: Very rarely, but like I said, I've seen it happen.
<infinity> doko: It's pretty rare for a security update to require a documentation change, though.
<infinity> (Or a string change of any sort)
<infinity> dpkg: error processing /var/cache/apt/archives/ia32-libs-gtk_17_amd64.deb (--unpack):
<infinity>  trying to overwrite `/etc/bonobo-activation/bonobo-activation-config.xml', which is also in package libbonobo2-common
<infinity> And a "woo-hoo" to that.
<dholbach> Kamion, mdz: ok for me to upload a tango-icon-theme cvs checkout? upstream seems reluctant to make a new release, but they fixed a couple of issues and the art team requested a package (because of changed shadows in the svg icons) - do you want me to file a bug for that?
<janimo> infinity: anything in particular that I need to help with for xubuntu dapper.1?
<Kamion> doko: surely file-moved-to-a-different-package should be Replaces not Conflicts
<doko> infinity: I hate apes :-/
<infinity> janimo: Testing images when we publish them, obviously.  Other than that, unless you've made major changes to your stuff, you should be alright.
<pygi> mdke, poke
<Kamion> dholbach: yeah, that's ok to upload
<dholbach> Kamion: Gracias!
<mdke> pygi: hello
<pygi> mdke, hey hey
<infinity> Kamion: Alright, amd64 build made it all the way to the end and seems happy.  Propagating my hacks all over now.
<mdke> pygi: hi. What can I do for you?
<pygi> mdke, nothing much, wanted to discuss that firefox thingy if you have time :)
<mdke> pygi: are you sure you have the right person?
<mdke> I don't know much about firefox
<Gloubiboulga> Kamion, hi! could you promote python-exo binary to main? the source package (exo) is already in main
<pygi> mdke, the thing about helper applications? :)
<mdke> pygi: ah, right. go ahead
<Kamion> pitti: pkg-create-dbgsym promoted
<pitti> Kamion: thanks
<Kamion> er, no it's not, WTF
<Kamion> 10:07:09 INFO    Override Component to: 'main'
<Kamion> 10:07:09 ERROR   u'Source package pkg-create-dbgsym not published in edgy'
<Kamion> 10:07:09 INFO    Commiting transaction, changes will be visible after next publisher run.
<pitti> infinity: can you please install pkg-create-dbgsym into the buildds?
<pygi> mdke, so, I kinda doubt I'll be able to work on this for edgy (especially when looked at huge firefox codebase), but edgy+1 might be doable 
<pitti> Kamion: hm, is that ERROR something to worry about?
<pygi> mdke, altought I know that's another postponing
<Kamion> yes
<Keybuk> Kamion: no such package in the archive
<Kamion> Gloubiboulga: done
<Kamion> Keybuk: pkg-create-dbgsym |        0.3 | edgy/universe | source, all
<Keybuk> hmm, madison sees it
<Gloubiboulga> Kamion, thanks
<Keybuk> ahh
<Keybuk> there's an 0.4 pending
<Kamion> https://launchpad.net/distros/ubuntu/+source/pkg-create-dbgsym
<mdke> pygi: I'm thrilled that you could work on it. I thought, in my uneducated way, that it would be very simple, because there must be some code that gets called by nautilus when doing the same operation, that can just be transplanted. but I don't know anything about that
<Keybuk> this is the safety to stop change-override breaking publisher runs
<Keybuk> pitti: did you just upload a new version?
<Kamion> oh, I see
<Kamion> bizarre way to do it
<infinity> Kamion: Okay, I'm building you a matching powerpc and i386 image too, so we can roll ISOs for kicks.
<Keybuk> Kamion: it's because publisher can't tell the difference between a new version and a change of overrides
<pygi> mdke, probably, but firefox codebase is huge, and I already have a lot of stuff to do for edgy, and outside ubuntu world
<Kamion> Keybuk: yeah, but the error message sucks
<Keybuk> Kamion: *shock*
<infinity> Kamion: To trigger builds yourself, just do "BuildLiveCD -d dapper ubuntu kubuntu ..."
<Keybuk> the error message is entirely accurate, if misleading
<Kamion> infinity: cool, thanks
<Keybuk> not _published_ in edgy
<infinity> Kamion: The argument placement is positional, cause I'm lazy.
<Keybuk> (it's pending :p)
<Kamion> Keybuk: pkg-create-dbgsym 0.3 is published in edgy, so no, it's not accurate
<mdke> pygi: well anything you can do with be appreciated I'm sure. If you get a patch, just attach it to the bug report, I guess, and Ian can take a look
<Keybuk> Kamion: it's still an improvement on "la la la, I just fucked the archive" :p
<pygi> mdke, ok, iwj =P
* Kamion files bug 54638 about that
<Ubugtu> Malone bug 54638 in soyuz "change-override.py message when new source is pending is very confusing" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54638
<Kamion> Keybuk: true
<Kamion> Keybuk: (do you happen to know what form its archive-breakage took?)
<Keybuk> Kamion: either one of
<Keybuk> a) upload being ignored and never published
<Keybuk> b) override being ignored and never done
<Keybuk> c) both being taken, and failing later sanity checks resulting in an "ignoring both upload and override" error
<Keybuk> depending on the exact point in the publisher run you did the override
<Kamion> fun
<Kamion> maswan: could you trigger a releases.ubuntu.com mirror pull? the auto-trigger doesn't seem to be working (at least not at any kind of reasonable speed), and we have a text change to releases.ubuntu.com/dapper/ that we need to get published within the next two hours or so
* Fujitsu pokes his head into the channel, and wonders what the version number will be for the point release.
<infinity> 6.06.1
<infinity> I look forward to 6.06.6
<ivoks> :)
<pitti> Keybuk, Kamion: yep, sorry, I recently uploaded 0.4
<ivoks> hi pitti 
<pitti> hi ivoks, enjoyed your vac?
<ivoks> i'm still on vacation :)
<ivoks> but i'm working on a cups-configure-everythin gui
<pitti> ivoks: happy with current edgy's cupsys? :)
<ivoks> :)
<ivoks> pitti: since i'm on GPRS, i don't upgrade too often :/
<Fujitsu> And what timeframe is expected? Hours, days?
<ivoks> pitti: as soon as it gets usable, i'll contact you to comment it
<pitti> infinity: right, please do not install pkg-create-dbgsym before 0.4
<infinity> pitti: Yes, massa.
<pitti> infinity: (sorry for not mentioning that earlier)
<infinity> pitti: S'ok, I'm too busy being Kamion's bitch to be yours anyway. ;)
* ivoks leaves before his a$$ gets some love :)
<Keybuk> siretart: ping-a-lingy-ling
<tseng> Keybuk: inspired email on f-spot
<Keybuk> tseng: I wanted to make a bold statement
<siretart> Keybuk: yes?
<Keybuk> siretart: so, I've been debugging why NetworkManager fails to work with Atheros at the moment
<Keybuk> it's not just that it fals to work, it actually leaves the card/driver seriously jammed
<Keybuk> and it's not NetworkManager
<Keybuk> it's wpa_supplicant
<siretart> oha
<siretart> you're talking about the new world order madwifi, no?
<Keybuk> old madwifi, afaik
<siretart> hm
<siretart> so edgy will still ship with madwifi-old, despite upstream refusing to give any support for it?
<Keybuk> edgy has both, just like dapper
<infinity> No, my next LRM upload will drop madwifi-old, unless my decision there is overridden.
<siretart> Keybuk: anyway, the wpa_supplicant in edgy doesn't support madwifi-old at all. I was told that the new madwifi was the way for edgy
<infinity> That was meant to happen when edgy opened, but "suff came up".
<Keybuk> siretart: this explains things
<Keybuk> it doesn't just "not support" it
<Keybuk> it fucks it with a chainsaw
<siretart> Keybuk: the source package however contains 2 patches. by default the new world order headers are enabled. it is trivial to comment that out and take the old headers
<siretart> Keybuk: but you need to recompile that manually
<lfittl> infinity: will the next l-r-m upload include fglrx 8.27.10?
<infinity> lfittl: Yes.
<Keybuk> siretart: tbh, it's probably easier to switch to -ng for testing purposes
<infinity> lfittl: That's pretty much required, since we're updating to Xorg 7.1
<siretart> Keybuk: right
<siretart> Keybuk: btw, you rejected the sync of config-manager. whats the point of it? I mean, the version we currently have hasn't got any testing at all, obviously
<lfittl> infinity: I know, have created my local l-r-m build as soon as fglrx with 7.1 support was released :)
<siretart> the version to be synced has been tested at least in sid and etch, after all
<Keybuk> siretart: because you wanted a sync to dapper-updates of a 15,000 line change
<Keybuk> this, to me, is not an "update
<siretart> yes. the old package is pretty fucked
<siretart> Keybuk: alternatively, we could put it into -backports. which leads me to the question, does this work in the meantime?
<Keybuk> siretart: does what work?
<siretart> 'syncing' of package to dapper-backports
<Kamion> siretart: no
<Kamion> we haven't ported the tools yet
<siretart> hrmpf
<siretart> ok
<Keybuk> heh
<Kamion> it was never a sync, it was a rebuild with a lower version number
<Keybuk> yeah, I like those accumulating backport requests
<Kamion> I've been meaning to poke at it for a while
<siretart> Keybuk: anyway. I still think that the 15k line diff is appropriate for config-manager in -updates. if this doesn't meet policy for -updates, then let's get it to -backports
<infinity> Kamion: Okay, whenever you want to attempt to spin dapper ISOs, there are livefs builds waiting for you.
<Kamion> I'm just going through Fabio's sparc stuff first
<Kamion> thanks!
<gnomefreak> are the points gonna be download only?
<Kamion> gnomefreak: we expect to be updating shipit
<gnomefreak> ok
<Kamion> though the current stock will go out first
<lfittl> mako: ping
<Keybuk> pitti: ping
<pitti> Keybuk: pong
<Keybuk> pitti: belocs-locales-data
<Keybuk> could you check that to see whether it's ok to sync from Debian and drop your patch to it?
* pitti does
<pitti> Keybuk: hm, did Debian adopt our scripts?
* pitti checks
<Keybuk> Debian appear to have changed a lot of the way locales are installed
<dholbach> whiprush, jdub: do you know who approved the 'ust' post on the fridge?
<pitti> Keybuk: well, our changes are not adopted (wouldn't make too much sense for Debian), but we do not really *need* this change
<pitti> Keybuk: instead, I should synchronize the new locales data to our locales package
<pitti> Keybuk: we needed this patch for breezy and older, but now that we actually use the belocs locales, there is little reason to install b-locales-data
<Keybuk> right
<Keybuk> why do we have separate packages in the archive?
<pitti> Keybuk: originally we split out the locales to the langpacks
<pitti> Keybuk: but we reverted this for a couple of reasons
<pitti> Keybuk: since then, jbailey wanted me to keep them separate from the other locale-related data to be able to update them post-release
<pitti> Keybuk: we could as well do that with b-l-d, though
<Keybuk> so, in summary, should I reject the sync request for this or not?
<pitti> Keybuk: ok for me to ditch the change
<pitti> Keybuk: I add it to my todo to clean this up 
<StevenK> Keybuk: Do you have time to look over my n-m 0.6.4 changes?
<Keybuk> StevenK: in a few minutes, sure
<Keybuk> can you isolate your changes from the upstream ones though?
<Keybuk> provide me two patches, one the upstream diff from 0.6.3 -> 0.6.4
<Keybuk> and the other your changes
<StevenK> Sure. Gimme a few ticks.
<shawarma> Keybuk: I just saw you and siretart talking about madwifi-old vs. madwifi-ng support in wpasupplicant. I have a patch lying around that lets it support both, if you want it?
<Keybuk> StevenK: also make sure the changes are from the current n-m
<Keybuk> I uploaded a new one within the last 24 hours :)
<siretart> shawarma: there was a debian bug about this
<siretart> shawarma: we were offered a patch for this in the past, but we rejected it. rationale in that bug
<shawarma> siretart: link?
<StevenK> Ewwwwww, the upstream diff is 680K
<sabdfl> StevenK: coffee?
* StevenK gets called away for din-dins.
<shawarma> siretart: I attached the wpasupplicant patch (and a networkmanager patch to match it) to bug 37773.
<Ubugtu> Malone bug 37773 in linux-restricted-modules-2.6.15 "[madwifi]  Semi-random system lockups in Dapper" [Critical,Confirmed]  http://launchpad.net/bugs/37773
<siretart> shawarma: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354388
<Ubugtu> Debian bug 354388 in wpasupplicant "Subject: wpasupplicant: please recompile with madwifi-dev" [Wishlist,Closed]  
<siretart> maybe there was an other bug about this as well
<shawarma> siretart: That sure is a long bug report.. :-)
<siretart> shawarma: short: madwifi-old is dead code. nobody is working on it, upstream refuses to support it, let it die
<siretart> shawarma: the next generation of the driver is released regularily, gets support, is shiny. 
<shawarma> siretart: right. My patch was meant for the dapper packages, since dapper uses madwifi-old where at all possible, and the madwifi-ng modules in dapper does not work with the wpasupplicant in dapper. :-(
<siretart> shawarma: there will be an updated wpasupplicant package for use with madwifi-ng in dapper-backports. it was requested some time ago
<shawarma> siretart: But it's good news that they support the wext backend now. Yay.
<shawarma> siretart: Yeah, I talked to infinity about it at UDS. I dont know what the status is.
<shawarma> siretart: Will that be accompanied by an updated network-manager package that can detect if you're using madwifi-ng and if so pass the proper option to wpasupplicant?
<shawarma> siretart: Do you know who is doing it? I'll bug him instead. :-)
<siretart> shawarma: I don't know about network-manager, nor do I use it personally
<siretart> shawarma: up to now, I was focusing on wpasupplicant, which gives me enough headaches about roaming ;)
<shawarma> siretart: You are making the wpasupp package for -updates?
<tepsipakki> is the wget in busybox broken atm? The installer can't load a preseed file with wget ("unknown server error")
<tepsipakki> network is up
<siretart> shawarma: I don't know about a wapsupp package for dapper-updates. I told you before about a wpasupplicant package for -backports
<shawarma> siretart: Ah, my mistake.
<lifeless> Keybuk: that would rock
<Keybuk> lifeless: what would?
<lifeless> login screen during initramfs :)
<Keybuk> ah
<mjg59> Keybuk: It shouldn't actually be /too/ hard to port usplash to svgalib
<mdke> who knows when the next community council meeting is? there wasn't one last week, right?
<Keybuk> mjg59: aye, isn't svgalib considered scary though?
<Keybuk> mdke: checked the fridge calendar?
<mjg59> Keybuk: It's scary because applications need to be suid root to make the bios call
<mdke> Keybuk: yes
<mjg59> Keybuk: So in our case, I don't think that's an issue. We'd just run it as root rather than making it suid.
<Keybuk> ah, that's true
<mjg59> It looks like vgagl is a reasonable replacement for bogl
<mjg59> It would just be another backend
* ^ohoel splashes fuel to the mono thread
* ^ohoel is sorry
* HiddenWolf gives ohoel a lighter and walks away innocently
<mjg59> Keybuk: Only problem then would be hardwiring the vesa mode
<mjg59> We could drop vga16fb at that stage, which might improve life for a small number of people
<mjg59> I'll take a look at it in my copious spare time? (Unless you want to)
<Kamion> in case anyone's wondering, yes, it is deliberate that cdimage/daily-live/ currently has dapper-desktop-*
<Keybuk> mjg59: I may also look at it in my CST
<Keybuk> at some point I need to do the theming changes I have planned, probably not until Wiesbaden though
<rodarvus> pitti, when you have some time, I'd like to ask you to take a look at https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54290
<Ubugtu> Malone bug 54290 in xserver-xorg-input-synaptics "synaptics driver fails to load (dlopen error)" [Untriaged,Confirmed]  
<pitti> rodarvus: sweet!
<rodarvus> what is your opinion - should we try to maintain stack protection enabled? (i.e., do you think his approach is correct?)
<pitti> rodarvus: LD=gcc sounds a bit like a hack, but I don't see anything too bad about it
<azeem> 2
<azeem> eh, sorry
<infinity> Oh, FFS...
<Keybuk> mdz: I'd left #6367 open simply because of the screaming children if I'd closed it while the bug was in dapper
<Keybuk> it's been fixed in edgy since ages
<infinity> pitti: chroots updated for you with your fancy new thingamajig.
* infinity decides that 10pm is as good a time as any to quit work, and tucks into a bottle of wine.
<StevenK> Keybuk: Right, two patches ready.
<StevenK> Keybuk: If you have time now, that is.
<Keybuk> yup
<StevenK> Keybuk: http://wedontsleep.org/~steven/nm/patches/
<StevenK> Keybuk: The 0.6.3 -> 0.6.4 diff is scary.
<Keybuk> StevenK: the debugging patch should go to Debian
<Keybuk> please add it to the BTS
<StevenK> Sure.
<StevenK> That's just debian/control, from memory.
<dholbach> Is Matthew Revell in here?
<StevenK> Keybuk: Hobbsee saw a SEGV, so I added them back in self defense. :-)
<Keybuk> StevenK: and debian/rules, surely?
<tseng> dholbach: jono would know him
<Treenaks> dholbach: he's on #lugradio
<StevenK> Keybuk: cdbs seemed to just cope.
<dholbach> tseng, Treenaks: thanks
<Treenaks> dholbach: uhr, if he's online, that is
<jono> dholbach, I know matt
<Keybuk> StevenK: oh, maybe
<Keybuk> StevenK: the patch jiggle I assume is due to 0.6.4 changes?  that patch applied fine to 0.6.3
<dholbach> jono, Treenaks, tseng: i wanted to talk to him as he seems to have become a fridge editor
<jono> dholbach, he matthewrevell
<StevenK> Keybuk: Correct.
<jono> dholbach, well I think he is editing with a bunch of other guys
<Treenaks> dholbach: oh no! the lugradio people are infiltrating the world! ;)
<Keybuk> StevenK: which Ubuntu bugs are fixed by the upstream changes?
<StevenK> Keybuk: It was the only one that needed jiggling, the others were fine.
<jono> Treenaks, :P
* StevenK looks for that list.
<Keybuk> StevenK: you just say "New upstream release" in the changelog without saying what it actually changes
<Kamion> doko: do your OOo uploads to dapper-proposed include pitti's security fixes from dapper-security?
<Kamion> (it's so hard to tell ...)
<doko> Kamion: yes, it's fixed upstream in 2.0.3
<Kamion> ok, thanks
<StevenK> Keybuk: The upstream release is a bug-fix release. I can correlate between the upstream changelog and bugs in Malone.
<Keybuk> StevenK: right, but it doesn't seem to fix any bugs from what I can tell
<Keybuk> at least, none that have affected us
<Keybuk> without further detail, I can't see anything in that patch worth a UVF exception
<doko> Kamion: could we have http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html for dapper as well (one for dapper-updates and one for dapper-proposed) ?
<Keybuk> attach the patch for the -dbg stuff to the Debian BTS, and we can pick that up that way
<StevenK> Keybuk: I already managed to get a UVF exception, mdz granted it.
<Keybuk> StevenK: I'm ungranting it then <g>
<StevenK> Kay.
<Keybuk> there's no reason for us to move ahead of Debian here
<Keybuk> it doesn't fix any problems we've got with NM fwict
* StevenK goes to mangle a patch.
<Keybuk> I really don't want to spend much energy on NM for edgy
<Keybuk> it's not ready upstream, and a minor release or two won't make it significantly better
* StevenK nods.
<Keybuk> it's in a "merge from Debian if there's useful bug fixes" holding pattern
<Kamion> doko: I saw your earlier comment, just haven't got to checking whether it's feasible yet
<Keybuk> it works for maybe ~20% of people at the moment
<StevenK> Keybuk: I'm happy to be in that 20%. It's good when it works.
<doko> Kamion: ok, thanks
<Keybuk> StevenK: file a wishlist in Debian, and detail the upstream changes for them -- if they update it, we can merge from them cheaply
<Hobbsee> hi all
<StevenK> Keybuk: Geez, two bugs? :-P
<Keybuk> sure, why not?
<StevenK> Keybuk: I'm bitching for the sake of bitching. :-)
<Keybuk> hehe
<Hobbsee> ooh yay, can i join in?
* Hobbsee even has the nickname to go with it!
<StevenK> Hah
<StevenK> Drat, someone already beat me to the 0.6.4 new upstream bug.
<Hobbsee> the wpa bugs are marked as fix released?
* Keybuk goes for lunch
<StevenK> Hobbsee: Every second bug mentions WPA.
<Hobbsee> StevenK: true
<StevenK> Well, 5 bugs out of 62 in the subject...
* StevenK grins shiftly.
<Hobbsee> hehe, right
<Kamion> doko: I'm trying to do it; dunno if britney can easily handle multiple suites though
<Kamion> may need to come up with some evil way to deduplicate the Packages file if I'm unlucky
<seb128> if I understand correctly, there is a dapper point version planned?
<seb128> does it includes fixes from dapper-updates? when is it planned?
<Kamion> seb128: dapper-updates> yes
<Kamion> seb128: this week, as I noted in last week's meeting
<Kamion> see the meeting logs
<seb128> k, that's what I understood, just making sure
<seb128> I'm slightly disapointed than nobody did some sort of announce
<seb128> we have a stock on desktop fixes pending
<seb128> I would have scheduled them before other things if I had knew before
<seb128> s#stock#stack
<Kamion> I've announced it in two consecutive distro team meetings
<Kamion> I'm sorry you didn't see that but I tried
<seb128> you mentionned working for the point version
<Kamion> I do expect members of all major teams to be paying attention to the distro team meetings
<seb128> but it was not clear that was such notice and I was expecting we would get a "now is time to get fixes uploaded for it" mail or something on time
<Kamion> http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2006-07-28.html around 01:28
<Kamion> 01:28	Kamion	  dapper-point-release-process: Do the first Dapper point release. Most of the pieces are in place now; if you know of something that needs to go in, please tell me as soon as possible! (If I can squeeze in some required SPARC fixes, I will.)
<Kamion> 01:28	mdz	Kamion: do you have an approximate timeline for the point release?
<Kamion> 01:29	Kamion	mdz: I'd like it to end by the middle of next week; if infinity could start on livefs builds tomorrow, that would be lovely
<Kamion> well, now is the time. go forth and upload.
<seb128> yeah, I've read that one, but that's a bit late
<Kamion> you still have a couple of days, I expect
<seb128> I prefer doing uploads some time before in case something goes not alright
<Kamion> look, I'm sorry, but it would be better now to get on with it rather than complaining at me
<seb128> yeah, but I'm not that comfortable pushing point version of GNOME a week before
<Kamion> we all have a lot to do
<seb128> sure
<Kamion> and DapperPointReleaseProcess has been there since Paris
<seb128> ok, let's take that as "next time it would be nice to send a mail some weeks ago as a reminder"
<infinity> Oh, did we not get the GNOME port release rescheduled, as we'd hoped?
* infinity looks at jdub.
<infinity> s/port/point/
<seb128> Kamion: ok, sorry, I should have looked at that, too many lists, wiki, etc to follow, easy to loose track of something
<Kamion> also http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-2006-07-20.html
<Kamion> 05:45Kamionwith regard to dapper updates, I think we're still reasonably on-target for an early-August dapper point release, although I need to poke the Soyuz team about status of some of the things we were planning to rely on there
<seb128> dholbach: would be nice to have point releases on the fridge wiki :)
<dholbach> seb128: i'm not a fridge editor :)
<Kamion> seb128: it's possible that it will drag out until the end of this week or so; I'm working Saturday and Sunday due to a couple of swapped days
<seb128> Kamion: right, I've read them mentioned on the meetings, I was just somewhere expecting we would get an announce mail pointing it was time to get things done for it when it would be time (like we got mail for UVF, freezes, meetings, etc)
<Kamion> ok, sorry I forgot about that
<seb128> Kamion: no big deal anyway, sorry for the noise
<seb128> I will try to push the fixes I'm confidents about today or tomorrow
<Kamion> thanks
<seb128> np
<bddebian> Morning
<bddebian> Thanks Keybuk
<trafiq> hi. any idea why when compiling 2.6.17.7 ( edgy eft ) i have error http://wklej.org/id/3d7a494223 : and cant finish compile ... 
<infinity> trafiq: -fno-stack-protector
<infinity> trafiq: Add that to CFLAGS in the upstream makefile.
<keNzi> http://rafb.net/paste/results/A41fyi77.html
<keNzi> anyone got an idea ?
<zul> yeah do what infinity said
<infinity> keNzi: Same answer.
<keNzi> thanx
<trafiq> infinity, make-kpkg -initrd -fno-stack-protector --revision=386 kernel_image kernel_headers modules_image ? : >
<infinity> trafiq: No, edit the Makefile.
<trafiq> mhm ok i must read about it im newbie but thx
<jsgotangco> last-exit nice!
<pitti> BenC: do you think we can meet this week to discuss the crash handling approach
<BenC> pitti: yeah, when's a good time for you (I'm open to almost any time)
<pitti> BenC: for me, too
<pitti> right now if you want
<jono> it has to be said, dholbach rocks good and hard
* dholbach hugs jono
* infinity kicks jono.
<infinity> BACK OFF, HE'S MINE.
<dholbach> hahahaha
* dholbach huhs infinity too
<infinity> dholbach: Slut.
<dholbach> ts ts ts ts
* infinity hugs dholbach anyway.
<dholbach> language, mr. conrad
<doko> Kamion: more ia32-libs* stuff for d-u: ia32-libs: updated libfreetype6 and libtiff4, ia32-libs-openoffice.org: libnss3, libnspr4, libneon25
<infinity> Oh, right.  Uhm.  What's the polite way to say that? :)
<doko> pitti: ^^^ missed these for -security?
<infinity> dholbach: Promiscuous tart!
<dholbach> infinity: LOL! I should have a T-Shirt with that on.
<pitti> doko: argh, yes
<jono> heh
* infinity decides he's had too much wine, is clearly off-topic, and minimises IRC.
<pitti> doko: I keep forgetting that not all packages build their own 32/64 bit mix
<BenC> pitti: I've got a lot of email to catch up on, so how about later today, or tomorrow morning
* dholbach hugs infinity
<pitti> BenC: sure
<jono> is Troy James Sobotka here?
<doko> pitti: if you prepare these for -security, please name them not .1 (already using that), maybe .0?
<Kamion> doko: yes
<pitti> doko: 0.1?
<doko> pitti: as you like it
<mdke> jono: he is troy_s 
<jono> ahhh thanks mdke 
<doko> pitti: I didn't check -gtk and -kde for security fixes
<mdke> troy_s: you should have some contact details on your personal wiki page so that people like jono can find you easily and grab you. Or link to your launchpad details
<keNzi> 1 question
<keNzi> why aptitude is loading cache so long - like 2 minutes
<keNzi> ?
<keNzi> http://rafb.net/paste/results/WXwMmF32.html
<keNzi> its my sources.list
<tseng> read the topic, this is not a support channel
<trafiq> infinity,  thx for helpworking
<trafiq> :)
<siretart> the ubuntu team is planning a new install tool called ust?
<siretart> did I miss something?
<siretart> http://www.pro-linux.de/news/2006/10025.html (sorry, german, but you get the idea)
<mdke> I don't think that "the ubuntu team" is quite accurate
<azeem> siretart: it's s/install tool/config tool/ in the body
<siretart> azeem: that doesn't make it much better, imo
<mdke> it's a private initiative, I thought
<siretart> the news sounds like it was something from the ubuntu devs. looks like a cli tool like yast.. hm
<mdz> Kamion: how are things looking for the point release?
<mdke> siretart: the project was posted to the fridge, and probably got taken seriously because of that. I have removed it
<azeem> mdke: yeah, they say their source was the fridge
<mdke> right
<azeem> I'm mailing the author
<mdz> siretart: sounds like it's referring to the gst-to-umbrella spec
<mdke> azeem: thanks, and apologies for that confusion
<siretart> mdz: has http://sourceforge.net/projects/ust/ something to do with gst-to-umbrella?
<siretart> azeem: ah, ok, then I can close my mutt now :P
<mdz> siretart: dunno, I was just intuiting without being able to read much German ;-)
<siretart> ;)
<azeem> done
<siretart> thanks azeem 
<dholbach> siretart: i left a message in their forum
<dholbach> siretart: and wrote a mail to the fridge editors
<dholbach> siretart: golem.de also took the ust article on the fridge serious
<mdke> dholbach: we removed the article from the fridge
<azeem> is anybody allowed to post to the fridge?
<mdke> azeem: you can mail fridge-devel@lists with ideas for articles
<dholbach> wiki.ubuntu.com/Fridge
<lamont> bddebian: I've been around, but yeah, kinda busy
<vodka-monk> hello my ubuntu friends
<Hobbsee> hi lamont.  so we can pinch (more) of your merges without a problem?
<bddebian> Hi lamont.  No worries, I just wanted to make sure I wouldn't offend if I did some of your merges.
<lamont> in universe?  have at it
<Hobbsee> bddebian: all merges are fair game by now :P
<lamont> think of /me in universe as just a MOTU gone crazy...
<vodka-monk> nick dubuntu
<bddebian> lamont: :-)
<bddebian> mdz: Do you know of anyone else working on mythtv stuff?
<Hobbsee> bddebian: there was someone, i think
<Hobbsee> lamont: you mean you're not all the time?  ;P
<bddebian> Hobbsee: Says you :-) (merges)
<vodka-monk> is possible to take output from my laptop to external lcd ?
<Hobbsee> bddebian: hehhe
<bddebian> Hobbsee: Yeah, I thought someone mentioned FunnyLookinHat or FliesLikeABrick
<pitti> BenC: did anyone else complain about PC speaker beeping being broken since edgy?
<mdz> bddebian: I think christian marillat was working on it at one time
<mdz> pitti: mine is working OK
<madduck> mh, so simon law gives a talk at UW, but the talk can only be downloaded in proprietary formats...
<madduck> :(
<mdz> pitti: I seem to have pcspkr in /etc/modules though
<madduck> i would have really liked to see it, but i only have amd64, which can't play any...
<mdz> madduck: that's surely UW's fault, and not Simon's
<mdz> or #ubuntu-devel's
<madduck> mdz: i wasn't accusing...
<pitti> mdz: the module is loaded, too, but it doesn't beep; it's the source of many missed IRC pings for me :/
<BenC> pitti: not that I'm aware of
<pitti> BenC: ok, thanks
<sfllaw> madduck: I'll see if I can get that fixed.
* Hobbsee yawns.  bedtime.
<Hobbsee> sfllaw: or anyone else.  how's the best way to get in touch with upstream, and send them a patch?
<saispo> anyone use evolution ?
<Hobbsee> like, what do you actually send them?
<sfllaw> Hobbsee: E-mails to the developer mailing list.
<sfllaw> Or an e-mail to the developer, if there's no list.
<sfllaw> Be nice and offer a fix for a known problem.
<Hobbsee> sfllaw: send them a debdiff, or a diff, or what though?
<Hobbsee> sfllaw: right, yep
<sfllaw> It depends what kind of developer.
* Hobbsee should do that for libdvdread
<sfllaw> But a diff is pretty normal for upstream stuff.
<Hobbsee> sfllaw: oh, and you're welcome w.r.t the wvdial merge, btw.
<Hobbsee> right, okay
<sfllaw> Thanks muchly for that.
<sfllaw> I was so ill.
<sfllaw> :(
* Hobbsee will email them when she's more coherant
<Hobbsee> sfllaw: :( so i heard.  i was going to do both, but thought it a bit risky
<sfllaw> madduck: There appears to be an XviD version.
<sfllaw> Or is that too patent-encumbered?
<madduck> sfllaw: i just can't play it. w32codecs seems to be needed, and there is no amd64 version.
<madduck> sfllaw: i've written to webmaster.
<gnomefreak> madduck: iirc you have to run 32bit chroot to use the w32codecs
<madduck> sfllaw: i don't claim to have any understanding about this sort of stuff though. just wanted to hear you talk again. :)
<sfllaw> madduck: Ah.
<madduck> gnomefreak: mh. and configure it to allow X connections... way too much trouble.
<sfllaw> I think ffmpeg is supposed to be able to handle MPEG-4.
<gnomefreak> madduck: true
<madduck> sfllaw: well, we'll see what webmaster says. otherwise you'll have to do the whole thing again over videoconf just for me. :)
<bddebian> heh
* Hobbsee notes that she killed off 2/3 of the bugs of libdvdread yesterday.  yay!
<bddebian> Hobbsee: Nice
<Hobbsee> wish i could do that for amarok.  or kdebase.  or something with a lot more bugs.
<gnomefreak> the new package freeze is past isnt it?
<sfllaw> sivang: How's the HomeUserBackup project coming along?
<Hobbsee> gnomefreak: err....no?
<Hobbsee> gnomefreak: that'd be at the same time uni freeze is, i think
<gnomefreak> ah
<bddebian> Keybuk: aboot?
<mjg59> Keybuk: Almost done
<mjg59> Just need to sort actually, y'know, drawing pixmaps
<Keybuk> bddebian: I'm a little busy this afternoon, sorry
<bddebian> Keybuk: No worries.  If you get a free sec, I just wondered about the acroread sync request.
<Keybuk> bddebian: it wasn't from Debian, so I ignored it (along with the others)
<Keybuk> syncs from unknown archives (to me) require MUCH manual review
<bddebian> Keybuk: Fair enough, thanks
<Keybuk> one of the other archive admins may know that archive better
<mjg59> Keybuk: I win
<mjg59> Keybuk: Well, other than text drawing, but still
<bddebian> Keybuk: Those are all from Marillat btw, in case you didn't know that
* pitti sends a looong zeroconf reply to the list
<LaserJock> \o/
<gnomefreak> that is still going on :(
<ogra> pitti, one that will kill the thread and everyone following up ?
<HiddenWolf> ogra if he manages that everyone here should owe him a beer or two. ;)
<ogra> ugh ... i havent read mails since yesterday afternoon ... the mono thread seems to replace the zeroconf one now ...
<pitti> ogra: well, I tried to find a balanced compromise
<LaserJock> ogra: yep, -devel just moves on to a different topic  once the last one is squished
<pitti> ogra: it's not my intend to kill anyone, and although the discussion was lengthy and redundant, I feel it was necessary
<ogra> i thought we had a balanced compromise a week ago already
<pitti> ogra: yep, turning that de-facto solution ^ into some retroactive reasoning :)
<ogra> well it was very redundant, over and over
<hunger> What is that balanced compromise? Oh, I guess I should just read pitti's mail.
<ogra> yeah
<Yagisan> I can't find anything in that thread. It seems to be self-replicating
<bddebian> heh
<sfllaw> Kamion: Ping?
<LaserJock> sfllaw: no, btw to your blog question
<bluefoxicy> wait whoa
<bluefoxicy> that thing I just killed was the crash reporter pitti's been working on wasn't it
* bluefoxicy triggers it again... by, of course, canceling the GPG dialog Seahorse puts up when he tries to send mail.
<bluefoxicy> (makes evolution crash horribly
<slomo_> bluefoxicy: known bug
<slomo_> bluefoxicy: http://bugzilla.gnome.org/show_bug.cgi?id=346526
<bluefoxicy> Cool it worked.
<bluefoxicy> slomo_:  I am still amazed I have to tell this machine twice to do something.  Literally.
<sabdfl> bluefoxicy: might be worth filing on ubuntu, with upstream gnome task linked to that bugzilla entry
<sabdfl> that way you'll be alerted when it's fixed upstream
<bluefoxicy> anything that uses gksu will not pop up the authorization dialog the first time; you need to do it a second time to get a dialog.
<pitti> doko: releasing ia32-libs-* to dapper-security onw
<bluefoxicy> It's like Ubuntu is now a red-hedaded stepchild.
<pitti> s/onw/now/
<bluefoxicy> pitti:  nice work on the crash reporter, does it retrieve the symbols from the backtrace on the server yet?
<pitti> bluefoxicy: no, bt generation is broken ATM, I'm working with BenC to fix that
<pitti> bluefoxicy: and it will not retrieve symbols from the server by default
<pitti> bluefoxicy: we might add that functionality for the developer's convenience, but not now
<pitti> bluefoxicy: right now we don't even have all the symbols yet :)
<bluefoxicy> no I mean it sends the crash data to the server; the server can take the addresses and turn them into symbols
<bluefoxicy> You saw the suggestion I made for relocating the collected addresses right?
<pitti> yep, I saw it
<Keybuk> mjg59: heh, shiny
<pitti> bluefoxicy: the principle is clear, but it requires some work (and code) to implement it
<bluefoxicy> yeah
<bluefoxicy> It won't get you a program back in the state of the crasher, but it'll get you proper addresses at least.
<doko> pitti: thanks
<mjg59> Keybuk: If you could grab the patch and give it a go, that would be great
<mjg59> Potentially means we can do >16 colours, too
<mjg59> But that's a tiny bit more awkward
<Keybuk> mjg59: sweet, can you e-mail it me?
<mjg59> Keybuk: http://www.codon.org.uk/~mjg59/tmp/usplash.diff
<mjg59> Keybuk: do make BACKEND=svga
<mjg59> Oh man
<BenC> who handles the scripts that generate the daily/live/whatever ISO's?
<Keybuk> can't test right now (in a bad hardware situation) but will test this evening
<doko> mdz: libwpd: kword and abiword-plugins are in main, using libwpd as well; they use it for the same functionality. checked that kword can load a WP document, will check that for abiword-plugins as well.
<mjg59> Minor build failure caused by gratuitous and unnecessary maths
<mdz> doko: ok; if those are verified, then go ahead
<mdz> BenC: Kamion maintains those
<mdz> BenC: and ubuntu-cdimage drives them
<BenC> Kamion: ping
<BenC> mdz: thanks
<doko> mdz, Kamion: can we sync from unstable to dapper-proposed?
<tseng> doko: they arent good to answer that, I think
<tseng> doko: Keybuk does most syncing
<doko> Keybuk: ^^^
<Kamion> mdz: stuff's progressing but the CDs are rather oversized - I need langpack changes
<Kamion> sfllaw: hi
<Kamion> BenC: yes?
<sfllaw> Kamion: You wanted to talk today?
<sfllaw> About revive-tasksel?
<Kamion> sfllaw: oh, hmm, right now is approaching dinner-time and not a good time
<sfllaw> Fair enough.
<sfllaw> Ping me when you want to talk.
<sfllaw> Tomorrow is also good.
<Kamion> sfllaw: if I'm around later in the evening, I'll get in touch, otherwise I fear it may have to be Wednesday, sorry
<Kamion> still off work tomorrow :-)
<sfllaw> That's cool.
<sfllaw> Ah.  Have fun.
<bddebian> Lamer ;-)
<BenC> Kamion: I need something changed in yaboot.conf for ppc cd's
<BenC> Kamion: the line that goes "device=cd:", remove it completely
<BenC> Kamion: thing is, yaboot doesn't need it..it's smart enough to know which device it booted from by asking open firmware (does this by default of no device= line is present)
<Yagisan> doko, you here ?
<BenC> Kamion: not only that but it breaks systems where the cd devalias points to a device that isn't the boot device, and also breaks things like pSeries where cd isn't defined at all
<doko> Yagisan: no
<Yagisan> doko, good, because building gcc-4.1 in pbuilder also has a not here moment with
<Yagisan> In function `translate_name':../../src/libgnatprj/../gcc/prefix.c:187: undefined reference to `__stack_chk_guard'
<doko> Yagisan: get the recent sources
<BenC> Kamion: we also may need to reintroduce the powerpc64 lines in yaboot.conf as a fallback for pSeries machines which have no sane "compatible" to match against. The one I have now uses "IBM-9128-710" as the only thing to match against, and that's the model number, which there are dozens of
<Yagisan> doko, that was from the edgy sources.
<doko> ohh, right, not yet updated.
<BenC> Kamion: I might look into adding a "64-bit" detection patch into yaboot, but for now, these changes will help dapper/edgy boot cd's
<Kamion> hmm, I thought there were some systems where yaboot didn't manage to figure out that it was booted from CD
<Kamion> (brb)
<Yagisan> doko, ok. np. I'll wait for a newer one then. Thanks for your time
<BenC> Kamion: it's not so much that it needs to know it was booted from CD, just that it needs to be able to figure out the boot device...I'm not aware of any place where that's a problem, but I could be wrong
<BenC> I just know that cd: keeps us from being able to boot on pSeries without the user adding an nvalias manually
<BenC> Kamion: for what it's worth, machines that have a problem with that, also cannot be net booted, since yaboot depends on this "feature" of detecting the boot device in order to download yaboot.conf from the same net device
<Kamion> BenC: mind you, looking at yaboot.c it does seem to bail out if it can't parse boot-device
<Kamion> BenC: should I do this for dapper too?
<BenC> Kamion: yes, please
<BenC> Kamion: basically kill device=, and dupe the macrisc4 stanzas without the [macrisc4]  part using -powerpc64 for the suffixes as a fallback
<BenC> folks will have to manually type "live-powerpc64" and what not, but that's better than not booting at all, which is what we get now
<Kamion> BenC: done the former, the latter is fiddly because I already have aliases for the -powerpc64 business in [macrisc4]  stanzas
<Kamion> BenC: I suppose I can delete those aliases on the grounds that there'll now be real label
<Kamion> s
<BenC> those aliases don't show up when you hit <tab>
<BenC> probably because of the macrisc4 match
<BenC> yeah, I think killing the alias should be ok
<BenC> I wish IBM had done something like power5 in their compatible list :/
<BenC> Kamion: thanks
<BenC> it's weird, until I got this machine I had no idea that IBM had a line of POWER5 server's made specifically for Linux
<mdz> dholbach: ping
<dholbach> mdz: pong
<mdz> dholbach: after upgrading tango-icon-theme (I think?) my panel logo has changed
<mdz> to blue feet
<dholbach> mdz: the next update should fix it
<mdz> and my panel launcher icons are suddenly larger
<mdz> ok, thanks
<dholbach> 0ubuntu2
<dholbach> mdz: do you use tango as icon theme?
<mdz> dholbach: I didn't think so
<mdz> checking
<tseng> human and tangerine fall back on tango
<mdz> dholbach: yes, apparently I was
<ogra> dholbach, i noticed that the panel doesnt forcably scale down icons anymore if they have the wrong size
<mdz> changing to Human fixes both issues
<dholbach> mdz: but slomo notified me of the tango breakage - it should be fixed :)
<dholbach> ogra: hum, what do you mean? how can i reproduce?
<ogra> i.e. if an icon exists in a theme in the 48x48 dir only, the panel is resized to 48px
<ogra> edubuntu-artwork has the distributor logo in gartoon and tango brown ... the gartoon one was 48x48 only because that was scaled down automatically in dapper and also covered 48px panels then ...
<dholbach> ogra: ah i understood, yeah
<ogra> in edgy the panel is scaled up 
<seb128> ogra: ping vuntz about it maybe ,)
<seb128> ;)
<ogra> oki
<seb128> ogra: feel free to open a bug about it too
<ogra> should that be a bug or is it intentional ?
<ogra> ah, k, i'll file a gnome bug :)
<seb128> not sure, that's why pinging vuntz can be useful ;)
<seb128> but that's likely to be a bug
<seb128> the panel should respect the settings used
<ogra> well, might be some change in the icon theme policy ... who knows (apart from vuntz ;) )
<seb128> that's either the panel or GTK
<Kamion> BenC: ok, done
<yosch> mdz: ping
<Petaris> ajmitch: ping
<mdz> yosch: yes?
<doko> Kamion, infinity: could you approve libwpd for dapper-proposed (still wanting to update ia32-libs-openoffice.org tonight as well)
<Petaris> ajmitch: Have you been sucessful in getting ltsp clients to authenticate via Acitve Directory?
<yosch> mdz: just wondering about your decision on bug 50802
<Ubugtu> Malone bug 50802 in ttf-gentium "Please backport ttf-gentium to dapper-backports from edgy (fixes broken defoma hints)" [Low,Confirmed]  http://launchpad.net/bugs/50802
<mdz> yosch: I have your emails in my inbox; I've sent some inquiries to make but haven't received any response from him
<BenC> Kamion: thanks!
<wasabi_> Hey... so... Would anybody be interested in fixing bug buddy so that it sends to launchpad, and also includes a core file.
<yosch> mdz: yes, he's been very busy recently apparently, no answers to a few mails from me neither
<wasabi_> (requiring the generating of a core file, of course)
<wasabi_> The bug reports generated by it are useless by default, basically.
<mdz> yosch: your update looks to me like a complete repackaging from scratch
<mdz> that's not something that we do in a stable release, so preliminarily, I'd say it's not for dapper
<yosch> mdz: the actual ttf do not change
<yosch> mdz: we've been trying to fix the broken upstream debian package for ages
<mdz> yosch: yes, but we only make very conservative changes to the stable release.
<yosch> mdz: I described the situation to mako in Paris
<yosch> mdz: he said such changes were OK
<yosch> mdz: I understand the need to keep Dapper stable but having a package stuck in a bad state for so long...
<ivoks> mdz: is there any chance to setup postgrey on fiordland?
<yosch> IIRC the plan was to prepare a point release for Dapper?
<mdz> yosch: I'm sorry if he gave you the wrong impression, but it isn't his decision and he knows the policy
<yosch> mdz: a key thing is the move to co-maintainership via Alioth and the LP font team for this package
<mdz> yosch: this is unrelated to the point release; that just rolls up all of the updates we have made since the release
<yosch> mdz: I understand
<mdz> yosch: https://wiki.ubuntu.com/TimeBasedReleases explains a bit
<mdz> yosch: also, the diff you sent looks like it is intended for Debian, not Ubuntu
<mdz> e.g., it targets "unstable"
<Kamion> doko: done
<yosch> mdz: yes, I followed the logic of similar font packages packaged similarly for both Debian and Ubuntu
<yosch> like http://changelogs.ubuntu.com/changelogs/pool/main/t/ttf-indic-fonts/ttf-indic-fonts_0.4.7/changelog
<yosch> but I can of course change that if needed
<Kamion> yosch: you'll see "unstable" at the top of package changelogs in cases where we synced them verbatim from Debian
<Kamion> but not if they were uploaded directly to Ubuntu
<bluefoxicy> point release?
<yosch> Kamion: OK got it
<bluefoxicy> "Ubuntu Dapper 6.06 SP1"
<Kamion> 6.06.1, actually
<bluefoxicy> Kamion:  Mocking Windows is more fun.  :P
<bluefoxicy> Although I question, would it defeat the purpose to do a .1 or whatever warranting point release on a stable distribution?
<yosch> my goal was to do this via the Alioth project, upload to Debian and then sync to Ubuntu
<Kamion> no.
<Kamion> bluefoxicy: ^--
<bluefoxicy> I'd think that if the changes were invasive enough to warrant actually stepping aside and saying, 'Hey guys, this is different,' then it might fall into the same category re risk as "Just upgrade to the new version of ubuntu"
<Kamion> bluefoxicy: no.
<Kamion> bluefoxicy: if nothing else we need to fix the installer a bit or else I'm going to be deluged in mail for the next three years. I can just forward it all to you if you like.
<bluefoxicy> Kamion:  Ah, right.  I forgot the installer is horribly broken for 1/2 - 2/3 of the population.  I guess that'll do it :)
<Kamion> I wouldn't go that far
<Kamion> but there are plenty of fixes that it's sensible to make without saying "this is a totally different distribution now".
<mdz> the installer is a special case because it requires a new CD release
<Kamion> it's also useful to roll up the large updates so that folks don't have to download them all on fresh installation
<HiddenWolf> Kamion, amen!
<tseng> esp on desktop
<tseng> gnome and ooo are huge
<Kamion> (might not be enough impetus in itself, since point releases are a lot of work)
<LaserJock> hmm, point release + rsync would be very nice
<mdz> Kamion: exactly
<yosch> mdz: what about updating the gentium package for Edgy? what can I try to get that into shape?
<mdz> yosch: the best thing would be to get a review from someone who knows fonts well
<mdz> yosch: which is why I tried to get in touch with mako
<yosch> mdz: OK, so we're both waiting for mako then
<mdz> yosch: i've looked over the packaging changes, and the non-font-specific stuff looks fine
<yosch> I've pinged mako about this sync bug 53787
<Ubugtu> Malone bug 53787 in Ubuntu "Please sync ttf-sil-abyssinica 1.0-1 from Debian Sid" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53787
<mdz> yosch: did you make any changes to the defoma hints?
<mdz> yosch: it's hard to tell since you renamed the file
<yosch> mdz: yes, the defoma hints needed some fixing
<yosch> can rename and rediff if you need
<mdz> yosch: is that going to cause the font to be preferred over other fonts in the desktop? if so, that needs to be discussed in advance
<mdz> if so, I'm not really qualified to judge whether the changes are correct
<vuntz> seb128, ogra: nothing changed in the panel wrt icon sizes
<ogra> so it must be gtk then ? 
<seb128> probably
<vuntz> let me add: AFAIK :-)
<ogra> heh
<yosch> mdz: the plan was to move freesans for Latin down the stack this way
<yosch> mdz: will do more analysis of this
<vuntz> I thought we forced the size in the panel (by checking the size of the pixbuf we get from gtk)
<vuntz> but maybe this check was removed at some time
<ogra> it looks suspicious like it 
<doko> pitti: http://librarian.launchpad.net/3677680/buildlog_ubuntu-edgy-amd64.openoffice.org_2.0.3-4ubuntu1_FAILEDTOBUILD.txt.gz
<yosch> mdz: a team of font experts are reviewing this whole priority issue with fontconfig via freedesktop: http://wiki.freedesktop.org/wiki/Software/Fonts/fonts.conf
<doko> pkgstriptranslations: processing control file: ./debian/openoffice.org-core-experimental-dbgsym/DEBIAN/control, package openoffice.org-core-experimental-dbgsym, directory ./debian/openoffice.org-core-experimental-dbgsym
<doko> pkgstriptranslations: openoffice.org-core-experimental-dbgsym does not contain translations, skipping
<doko> pkgstriptranslations: preparing translation tarball openoffice.org_2.0.3-4ubuntu1_amd64_translations.tar.gz...done (74 files)
<doko> dpkg-deb: parse error, in file `/build/buildd/openoffice.org-2.0.3/debian/openoffice.org-core-experimental-dbgsym/DEBIAN/control' near line 7 package `openoffice.org-core-experimental-dbgsym':
<doko>  `Conflicts' field, reference to `openoffice.org-help-de': error in version: version string is empty
<mjg59> mdz: Ok, I've got a perfectly compatible usplash that's able to do high-res stuff
<pitti> doko: looking into the log now
<mjg59> mdz: i386-only at the moment - do you want me to upload it so we can find out if it breaks anyone?
<gnomefreak> doko: you working on OOo?
<doko> gnomefreak: no, going to diner now
<gnomefreak> its failing to create a file needed to launch (whoever is gonna be working on it)
<Kamion> doko: your ia32-libs-kde change removes dapper-security from its sources.list
<Kamion> doko: this seems like an error - for instance it reverts kdelibs
<doko> Kamion: which version?
<Kamion> doko: ia32-libs-kde 7.1
<pitti> doko: ugh, thanks; will fix that in pkg-create-dbgsym
<Kamion> reverts kdelibs from 3.5.2-0ubuntu18.1 to 3.5.2-0ubuntu18
<Kamion> if present, dapper-updates should generally supersede dapper-security
<doko> Kamion: in all the ia32-libs* packages, I added these, maybe I missed it in one ...
<Kamion> doko: ok, I'm rejecting this one, please check and reupload
<mdz> mjg59: you are my hero
<mdz> mjg59: go for it; this is edgy after all
<Kamion> -deb http://archive.ubuntu.com/ubuntu dapper-security main
<Kamion> -deb-src http://archive.ubuntu.com/ubuntu dapper-security main
<Kamion> +deb http://archive.ubuntu.com/ubuntu dapper-updates main
<Kamion> +deb-src http://archive.ubuntu.com/ubuntu dapper-updates main
<mdz> mjg59: will amd64 just lose usplash entirely, or gracefully degrade?
<Kamion> ^-- diff from 7.0.1 to 7.1, pretty clear :-)
<mjg59> mdz: Behave as it currently does
<mdz> perfect
<ogra> ppc ?
<Kamion> woo, dapper/unapproved empty. /me -> dinner
<mdz> need to install some ram, brb
<desrt> mjg59; edgy wakes up somewhat faster already
<tseng> hello desrt 
<desrt> good morning, sir
<doko> gnomefreak: fixed in in 2.0.3-4ubuntu1, will take a while, until pkg-create-dbgsym is fixed
<gnomefreak> ok ty
<mjg59> ogra: Same as it currently is for now
<ogra> ah, cool !
<Burgwork> jdub, the canaries just got a little louder --> http://www.americanmcgee.com/wordpress/?p=171
<tseng> Burgwork: time to evacuate the mine?
<Burgwork> tseng, I think we already have
<tseng> no, everyone else :)
<tseng> automatix is distressing, howeverr
<Burgwork> indeed
<Burgwork> but it does show the value of the commoncustomizations spec
<lemsto> hi ! 
<tseng> there is not alot of writing about what automatix is
<lemsto> could one of you give flags used to compil ubuntu packges?
<tseng> just how to start letting it do horrible things to my system
<lemsto> give me*
<tseng> -mcpu=pentium4 -mcpu=i486 -O2, basically
<doko> gnomefreak: is you real name John Vivirito?
<gnomefreak> yes 
<tseng> -fstack-protector more recently.
<lemsto> noneof those: -funroll-loops -ffast-math -fomit-frame-pointer -fno-exceptions?
<Burgwork> tseng, I was referring to what it is trying to do (make stuff easier to install), not the mangling it does while trying to do that
<tseng> lemsto: absolutely not.
<doko> gnomefreak: thanks for looking over the OOo bug reports
<lemsto> tseng ok thank you
<tseng> no problem
<gnomefreak> doko: no problem i enjoy bugs ;)
<Burgwork> I assume those flags would be probably filed under "gentoo crack"?
<lemsto> tseng, are those flags "dangerous" for usual apps?
<tseng> lemsto: some of them can cause ocassional bugs
<zul> Burgwork: oh yes
<mjg59> Right, uploaded
<LaserJock> Burgwork: hehe, I think my CFLAGS were like 3 lines long once in Gentoo, ... I've since recovered ;-)
<tseng> lemsto: but the merits of various flags was pretty well covered at the begining of ubuntu and we havent changed much since
<zul> Burgwork: you have to go through a 12 step recovery
<doko> Kamion: ia32-libs-kde 7.2
<doko> uploaded ...
<lemsto> tseng, as firefox is said to be faster when locally build i wanted to try.. but with good flags...
<tseng> you are certainly free to experiment
<lemsto> tseng, hehe yeah but i first try to know what those flags are for ;)
<tseng> rebuilding firefox with a random set of flags isnt very scientific, though
<Treenaks> tseng: Use _all_ compiler flags! it must make it faster!
<bddebian> heh
<lemsto> Treenaks, hehe
<Treenaks> tseng: </stereotype>
<tseng> I was *trying* to be serious in the face of all this
<tseng> oh well :)
<Treenaks> tseng: it's your history.. it keeps following you :P
<zul> like your fan club
<Burgwork> LaserJock, there are just so many things I could say about that... ;)
<LaserJock> Burgwork: hehe
<Burgwork> "Brandon concluded our interview by saying that he would "like to thank the entire community for making my experience with Gentoo a positive one."" <-- digging up dirt on tseng 
<zul>  Burgwork: where is that from?
<Burgwork> http://www.gentoo.org/news/en/gwn/20040119-newsletter.xml?style=printable
<kylem> people are allowed to have lapses of judgement.
<tseng> Burgwork: hah
<tseng> Burgwork: you cant really tell people you think they are all tools
<Burgwork> better quote: "Brandon claims he is afflicted with "an odd fascination with things that go way too fast" - which would explain his taste for hard-core metal music, as well as Gentoo."
<tseng> yeah i was not happy with that, either.
<zul> heh...
<tseng> its kind of annoying to do a Q&A interview only to paraphrase the entire thing and add fluff
<tseng> Burgwork: is there a date on that?
<tseng> Burgwork: maybe 3 years ago?
<Burgwork> tseng, it came from the above url
<Burgwork> so 2 1/2 years
<tseng> ah right.
<Burgwork> welcome to the fishbowl
<tseng> I found a post of myself on redhat list in 2002 the other day
<pitti> doko: pkg-create-dbgsym fix uploaded
<lemsto> i have one last question about flags ;)
<lemsto> is setting CFLAGS and CXXFLAGS in /etc/environment suficient for apt-get -b source?
<mirak> hi
<mirak> I asked for support everywhere, I installed last pammount version for tarball, and now I can't login, I can't find what's wrong or how to fix it
<bluefoxicy> tseng:  Were you blatantly retarded?
<tseng> bluefoxicy: im sorry?
<bluefoxicy> <tseng> I found a post of myself on redhat list in 2002 the other day
<tseng> oh
<tseng> I wasnt brilliant.
<bluefoxicy> tseng:  I keep finding posts I made several years ago and I'm like "OH JESUS WHY!"
<tseng> hahah
<HiddenWolf> bluefoxicy, you can't go asking if people are retarded, it isn't polite! ;)
<tseng> do most of them have a reply from me reminding you?
<bluefoxicy> no
<tseng> "hey john, please shut up"
<tseng> oh, you went too far back then.
<tseng> :P
<slomo_> infinity, Keybuk: please give-back pitivi... it builds fine now with gnonlin 0.10.5-1ubuntu1 in the archive
<bddebian> Who wrote the merges.ubuntu.com pages?
<slomo_> bddebian: Keybuk
<bddebian> Who's off today, Keybuk or Kamion
<bddebian> ?
<jono> hey
<Petaris> ajmitch: Have you been sucessful in getting ltsp clients to authenticate via Acitve Directory?
<ajmitch> no, since I haven't been working with ltsp at all
<Petaris> ajmitch: What about in general with ubuntu?
<ajmitch> yes
<Petaris> cool
<Petaris> Any how to?
<Petaris> or notes on how its done?
<ajmitch> I haven't written anything up yet, no
<Petaris> hrm
<gnomefreak> bddebian: i think kamrion is off tomorrow and i havent seen keybuk all day today
<Petaris> ajmitch: did you do this strictly with config options or are you writing a software to automate it?
<gnomefreak> -r
<ajmitch> automating
* ajmitch is currently in a meeting about some upstream stuff, can't talk much
<Petaris> ajmitch: Ok
<bddebian> gnomefreak: OK, thx
<Petaris> ajmitch: Is there a better time to catch you?
<gnomefreak> :)
* ajmitch usually isn't online at this time - usually later in the day, or earlier
<Petaris> ajmitch: Ahh thats why I keep missing you,
<ajmitch> yes, I don't often stay up till 4 or 6 AM
<Petaris> ajmitch: something to look at sometime (as its close to what you are doing): http://sadms.sourceforge.net/
<Petaris> I need to be able to logon to AD for an ltsp lab, so any help I can render I will.  You can find me in #edubuntu usually.
<Petaris> Thanks
<ajmitch> another app that would have been nice to see at the start of this project..
<Petaris> right
<Petaris> these things usually pop-up half way through
* ajmitch will hopefully upload to edgy in a day or two
<ajmitch> of course
<ajmitch> no matter how much research is done beforehand
* Petaris agrees and can't wait to try ajmitch's AD auth tool
<Petaris> you have a name for it?
<ajmitch> currently just authtool
<ajmitch> since I have no imagination
<Petaris> ok, I'll keep my eyes open for it
<Petaris> like I said, I need this functionality so if there is anything I can do to help debug it let me know
<ajmitch> ok
* Petaris notes he is not a programmer
<Petaris> thanks
<Burgwork> ajmitch, is your stuff using pam/
<Burgwork> ?
<ajmitch> there's not really any other sane way to do authentication 
<Burgwork> ajmitch, true. How ubuntu specific it is?
<ajmitch> it's not
<ajmitch> there's no Ubuntu branding anywhere
<Burgwork> ajmitch, will it run on FC?
<ajmitch> some files will be in different locations on other distros
<ajmitch> I can't say
<Burgwork> hmm, ok
<ajmitch> since I don't have a current FC to test with
* Burgwork grumbles about work using FC
<ajmitch> I'm doing a bit of config file handling, so it's dependant on what other distros do
<LaserJock> Burgwork: want me to "have a talk" with Tim? ;-)
<Burgwork> LaserJock, don't I wish. Just after he pays for my ticket to linuxworld sf
* ajmitch needs to start job hunting asap
<Burgwork> ajmitch, you could move to montreal, as canonical hiring
<Burgwork> not hard to get a canadian work visa
<ajmitch> heh
<ajmitch> if they'd take me
* Burgwork wonders about ajmitch's sanity, with a statement like that
<Kamion> infinity: shouldn't dapper-updates builds build against dapper+dapper-security+dapper-updates, not just dapper+dapper-updates?
<Kamion> infinity: http://librarian.launchpad.net/3681129/buildlog_ubuntu-dapper-i386.debian-installer_20051026ubuntu36.3_FAILEDTOBUILD.txt.gz
<LaserJock> Burgwork: don't worry, he's just been hanging out with bddebian too long
* ajmitch is currently watching the f-spot meeting.. hopefully we get another 0.1.x release
<ajmitch> LaserJock: the montreal office does different work to what we do in MOTU
<Burgwork> the montreal office is all support
<Burgwork> ajmitch, you could do qa, ubuntu needs another one of those
<ajmitch> & the job description says excellent english & french
<ajmitch> my french is anything but excellent :)
<LaserJock> newzealeadese counts, right?
<Burgwork> they don't speak french in quebec, so you are all good
<LaserJock> hehe
* ajmitch will probably look for work closer to home
<Burgwork> ajmitch, what happened to your last job?
<ajmitch> was only a short one
<mdz> rodarvus: have you received any reports of a system freeze using the ati driver?
<TMM> rodarvus: hey! I'm having some trouble with my X server in edgy, I was told to talk to you! :) 
<TMM> rodarvus: err. back in a second. need to restart X
<TMM> re
<TMM> " yes X in edgy is broken atm"
<TMM> ah
<TMM> sorry :)
<TMM> so... anything I can do to help? or are the packages just not done yet?
<mdz> that depends on what you're talking about
<TMM> well, GLX seems very hosed, also, the entire X experience feels very sluggish now. AIGLX seems to initialize, but there is something wrong. I used the packages from xgl.compiz.info on dapper, and, I removed very trace of them when I updated to edgy, but, things don't look as good :)
<TMM> also, the 'applications' menu 'flashes' and is generally unuseable 
<gnomefreak> TMM: killall gnome-panel to fix the flashing
<TMM> gnomefreak: afraid not :(
<mdz> TMM: if you're experimenting with xgl or aiglx; you're on your own.  the current breakage has nothing to do with that.
<gnomefreak> TMM: sometimes 2 times is needed or you didnt get rid of compiz and xgl as you thought
<mdz> TMM: the flashing is a known, reported bug
<TMM> mdz: no, it enables it by default
<TMM> gnomefreak: aiglx :)
<mdz> no problems here
<TMM> mdz: strange... perhaps there's some traces left... but I can't imagine
<TMM> no, I reinstalled all the x server stuff... and I removed the aiglx repository before upgrading
<TMM> mdz: if you are on edgy, does it mention AIGLX anywhere in your /var/log/Xorg.0.log file?
<mdz> yes
<TMM> mdz: do you still have direct rendering? or only indirect rendering?
<mdz> hmm, I don't
<mdz> but of course that only affects 3D
<mdz> I don't have any 2D slowdown as you describe
<TMM> it is not 'slow' as such, it just 'feels' like it drags a bit
<Petaris> later
<TMM> well, I guess I'll just wait a bit then, or reinstall dapper again :)
<mdz> if there is a genuine problem, neither of those strategies is likely to help get it fixed
<TMM> I am just generally not sure what to do about it, the Xorg.0.log looks fine, and it all 'works' as such
<TMM> *genuinely 
<mdz> the problem with the applications menu is bug #52405
<Ubugtu> Malone bug 52405 in gnome-panel "gnome-panel eats 50% cpu for half an hour and flickers" [High,Confirmed]  http://launchpad.net/bugs/52405
<mjg59> BenC: Does PAGE_MASK ring any bells?
<TMM> mdz: well, that worked :) still, the sluggishness... also, how did you find that bug? I WAS already looking for edgy bugs, but there were 0 according to malone ?
<mjg59> mdz: Oh, hrm. The build-dependency on libsvga1 is a problem - it's in universe
<TMM> mdz: for instance, the new cairo-drawn calendar for evolution, the 'block' that hovers with your mouse cursor when you move over an appointment, that lags and it tears 
* mvo goes to bed
#ubuntu-devel 2006-08-01
<mdz> TMM: I looked at the bug list for gnome-panel
<mdz> TMM: where did you see 'edgy bugs'?  wherever that is, it's a red herring and doesn't mean what it says
<HiddenWolf> mdz, it's the list of bugs targetted at edgy
<mdz> TMM: that's not quite the same as "the entire X experience feels very sluggish"
<HiddenWolf> distros/ubuntu/edgy/+bugs
<mdz> HiddenWolf: which is not edgy bugs
<HiddenWolf> mdz, easy to make the mistake. ;)
<mdz> HiddenWolf: yes, but where in the UI links to that and calls it edgy bugs?
<TMM> mdz: https://launchpad.net/distros/ubuntu/edgy/+bugs
<HiddenWolf> mdz, it doesn't, but the url seems to suggest "list of bugs in edgy"
<HiddenWolf> mdz, But I guess people will figure out that edgy has more than 0 bugs.
<mdz> HiddenWolf: and given that launchpad doesn't keep track of which bugs are in which release, how do you figure that would work? :-)
<TMM> mdz: that is just an extreme example, the rest just 'feels' a bit sluggish
<TMM> mdz: like, text scrolling up in xchat-gnome takes just a little too long, opening a menu is just a fraction 'off' 
<HiddenWolf> mdz, I was just explaining where the confusion came from, since I end up at that page instead of ubuntu/+bugs regularly myself. :)
<TMM> mdz: right then, I just arrived at that page, and, didn't know what to do. I'm not a big malone user (yet)
<mdz> TMM: I'd like to know how you got there; nothing should link to that (because there's no mechanism to make it do what it should)
<HiddenWolf> mdz, it's linked to allright
<HiddenWolf> https://launchpad.net/distros/ubuntu/edgy has a bugs link
<TMM> mdz: well, I was being a stupid 'user' so I dod : https://launchpad.net/ > The Ubuntu distribution > Ubuntu milestones:/ ubuntu-6.10 > For:  Ubuntu  Edgy  
<HiddenWolf> and the /edgy page is easily gotten to from any link that lists the edgy release
<TMM> that gets you
<TMM> https://launchpad.net/distros/ubuntu/edgy
<TMM> then I clicked on 'bugs'
<TMM> perhaps I am stupid, but that SEEMED logical at the time
<Kamion> https://launchpad.net/distros/ubuntu/+bugs links there too
<Kamion> under "Release bugs"
<Kamion> googling for link:https://launchpad.net/distros/ubuntu/edgy/+bugs also lists https://launchpad.net/distros/ubuntu/dapper/+bugs, for the same reason
<TMM> mdz: anyway, I'm still not sure what I should do about the whole sluggishness thing :) just file a bug against xserver-xorg or something?
<mdz> TMM: I think you may be imagining the sluggishness after noticing that direct rendering was disabled ;-)
<mdz> I've lost direct rendering as well but have not noticed any difference
<bddebian> heh
* HiddenWolf always suspected TMM was on something ;0
<bddebian> mdz: Can't do mythtv until libiec61883 gets out of NEW :-(
<wasabi_> Do we have any centralized system that deals with debian/watch files?
<TMM> mdz: err... no :) I know what 'direct rendering' is for :) 
<wasabi_> Launchpad could!
<bddebian> wasabi_: Deals with them in what way?
<mdz> wasabi_: https://launchpad.net/products/launchpad-bazaar/+spec/tracking-versions
<wasabi_> Notifies the author, marks the package.
<mdz> tada
<wasabi_> Neato.
<bddebian> Ah
<mdz> retroactive feature specifications
<wasabi_> Haha
<wasabi_> "should be rolled out"
<mdz> meaning it was already partially implemented before that was written
<TMM> mdz: like, if I overlap xchat-gnome with a fullscreen terminal, and I minimize it again, I can see the chat-portion being redrawn from a dull-gray. I am very sure that I didn't see anything like that on dapper.
<wasabi_> Neat. The Wiki page is private though. =(
<wasabi_> That is a wee bit annoying.
<wasabi_> And offends my sensibilities. ;)
<mjg59> Oh argh
* mjg59 beats svgalib
<mjg59> It doesn't even approximately build with gcc 4
<mdz> wasabi_: there is nothing I can do about that
<TMM> mjg59: fun, fun fun! :)
<mjg59> Or, indeed, gcc-3.3
<mjg59> Maybe I'm doing something wrong
<wasabi_> I suspected as much.
<mdz> mjg59: and you want it in main? :-P
<mjg59> Ah, yes, it's just a crack-addled build system
<mjg59> mdz: You want high-res bootsplash?
<mdz> mjg59: depends on the price
<mjg59> mdz: It's actually fine with gcc 4
<TMM> mdz: so... I just ignore this then? :)
* Kamion scratches his head over bug 45200, and decides to hackily work around it and sing LALALA until ubiquity-advanced-partitioner is done
<Ubugtu> Malone bug 45200 in ubiquity "[Flight 7]  installer crashed trying to select partition for mount point" [Medium,Confirmed]  http://launchpad.net/bugs/45200
<mjg59> Oh nngh symbol mangling
<gnomefreak> Kamion: sorry about the bug that i rejected. the part i have no more info is what got me on that
<Kamion> gnomefreak: it was on the edge, but it made some degree of sense to me
<Kamion> for you guys it's a matter of trying to guess whether the responsible developer will have enough information
<mdz> TMM: I'm more concerned about the fact that starting gdm hangs the entire system requiring a power cycle on my laptop
<mdz> (bug 54650)
<Ubugtu> Malone bug 54650 in xserver-xorg-video-ati "[Edgy]  System freezes when loading gdm" [High,Confirmed]  http://launchpad.net/bugs/54650
<mdz> you're getting off easy
<Kamion> severity: breaks-mdz-hardware
<TMM> mdz: ghe :) 
<bddebian> hehe
<mdz> I think I just managed to blame SSP for that though
<imbrandon> heh
<TMM> mdz: still, I'd like to try and fix it, but, it seems that xorg 7.1 fixes it for me anyway... so, I'll just hope that's what goes into edgy
<gnomefreak> TMM: its in edgy atm (not fully i dont think)
<TMM> edgy has 7.0.0 with aiglx enabled by default... straaange 
<TMM> gnomefreak: the version for xserver-xorg is labeled as 7.0.22
<mdz> hmm, false alarm
<gnomefreak> hmmm i thought 7.1 started in
<mdz> yes, it's 7.1
<TMM> imbrandon: hey, you 'why don't you have a nice cup of' guy? :)
<gnomefreak> thought so
<mdz> TMM: no
<imbrandon> TMM: huh ?
<TMM> mdz: not here it isn't :) (well, not according to the version info anyway) 
<TMM> imbrandon: sorry then :)
<TMM> mdz: perhaps I have an outdated mirror
<gnomefreak> TMM: no
<mdz> TMM: either you're not up to date, or you're looking in the wrong place.  I'm curious to know how you confirmed it was fixed with xorg 7.1 then
* ..[topic/#ubuntu-devel:mdz] : "Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs" | yes X in edgy is a mess atm
<gnomefreak> mdz: everyone has 7.0.22 maybe pre 7.1 base?
<mdz> gnomefreak: the current packages in edgy come from xorg 7.1
<gnomefreak> mdz: than not sure why version numbers are off
<Kamion> 7.0.22 identifies a package containing some base scripts
<Kamion> it is not a useful description of the upstream xorg version present on the system
<mdz> correct
<gnomefreak> ok
<TMM> mdz: well, X -version says now "X Window System Version 7.1.1". and, it worked 'fine' with the xorg-air server from dapper, and that was just a 7.1 ... perhaps it got broken in 7.1.1 sorry about that
<mdz> you looked at the version number of the 'xorg' package or such
<mdz> TMM: dapper didn't have 7.1
<TMM> mdz: backport from aiglx.compiz.info
<gnomefreak> xorg and xserver-xorg show same
<imbrandon> both show 7.0.22ubuntu7  but X -version shows 7.1.1
<imbrandon> ( in edgy )
<gnomefreak> correct
<TMM> well, my cdrom drive's broken as well :P
<TMM> I need to do some digging it seems :) nice :)
<gnomefreak> TMM: cdrom 15 USD ;)
<Kamion> gnomefreak: xorg and xserver-xorg both come from the same source package; neither actually provides the server binary, as 'dpkg -L' on each will show you
<mdz> can you even buy CD-ROM drives anymore?
<TMM> gnomefreak: no, the cdrom drive ITSELF works fine :) edgy just doesn't recognise mine anymore
<gnomefreak> Kamion: ah ok
<gnomefreak> mdz: i have 10 or so laying around
<gnomefreak> lol
<imbrandon> mdz: heh dont think so, most all dvd read and or dvd read / cdrw 
<gnomefreak> imbrandon: you wouldnt happen to have the kubuntu logo in you K menu would you?>
<TMM> hal doesn't recognises it anymore
<gnomefreak> TMM: did you do todays updates? i think hal was updated this morning
<TMM> gnomefreak: yes, I did
<TMM> gnomefreak: I just upgraded from dapper today
<gnomefreak> ah
<gnomefreak> so the question was it working before the hal update is usless
<TMM> I have only been running edgy for 4 hours or something now :)
<gnomefreak> edgy has been fairly good so far been runnning it from day 1 and only had to reformat 2 times once was new harddrive 
<wasabi_> I've been running the same install since... warty.
<wasabi_> Heh. Can't say I've ever reformatted any Linux machines, except the ones I screw the fs up on.
<HiddenWolf> wasabi, a reinstall fixed a bunch of bugs for me last week, but I had changed my hardware a bit.
<HiddenWolf> wasabi, going from pci to onboard sound was less than stellar. :)
<wasabi_> Shoulda fixed it, and bugged what you fixed. ;)
<HiddenWolf> wasabi, I had no clue. It worked after a bit of tinkering, but the quality was aweful.
<HiddenWolf> I thought I'd have to live with it till I got a new card, reformatted to get rid of an old disk I used, and on reinstall got a perfect quality audio.
<Kamion> -rw-r--r--  1 root root 5 1999-06-09 21:11 /etc/hostname
<Kamion> I guess that install is about that old
<Kamion> iwj is going to win any dick-size wars of this kind, though
<TMM> I'll just reinstall with fedora core 5 ;)
* HiddenWolf hits TMM with something
<TMM> joke :)
<HiddenWolf> Kamion, and your system is cruft-free? :)
<LaserJock> Kamion: wow, they had Linux back then? ;-)
<TMM> anyway, off to bed, I'll investigate this some more later 
<TMM> bye!
<Kamion> 1999 was only Debian slink or so
<imbrandon> gnomefreak: you mean the side logo ? or the distributor-logo 
<HiddenWolf> Kamion, and you've just copied your install along from pc to pc?
<gnomefreak> imbrandon: the logo on the side runs vertictly
<imbrandon> gnomefreak: yea i have that , afaik its on all kubuntu installs by default 
<BenC> mjg59: Re: PAGE_MASK, no
<Kamion> HiddenWolf: same computer, though it's had a few hard disk replacements; but there's been some kind of hardware continuity throughout
<Kamion> still quite adequate for handling mail and IRC and stuff
<gnomefreak> imbrandon: theres a bug with it in 3.5.4 dapper i cant duplicate it and i know you are on edgy i wanted to see if same for you
<doko> infinity, Kamion: please approve openoffice.org_2.0.3-4dapper1 for dapper-proposed
<HiddenWolf> Kamion, ah, cheers
<imbrandon> gnomefreak: sure lets goto k-devel to not clog up in here
<gnomefreak> ok
<Kamion> doko: accepted
<robertj> Kamion: do you have any thought on pitti's zero-conf uber-post?
<mdz> mjg59: usplash 0.4-1 seems to work well on my T42 during shutdown, but upon reboot it doesn't start (no error output)
<Kamion> robertj: no, I haven't caught up on ubuntu-devel in ages
<robertj> https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019680.html
<bluefoxicy> is there a list of all the officially approved release goals for ubuntu
<bluefoxicy> like GccSsp and automated-problem-reports and the like, things that definitely are going in?
<robertj> bluefoxicy: at this point I think everything thats going in should theoretically have an approved spec in launchpad
<Kamion> robertj: do I have to get involved in it? the core developers who've already spent time on it are competent; I don't see why I need to spend the time to bring myself up to speed as well
<doko> cprov-dinner, infinity: please kill the sparc build of openoffice.org 2.0.3-4ubuntu1 in ubuntu edgy (it will fail due to a buggy pkg-create-dbgsym
<bluefoxicy> robertj:  Eyeballing it there's somewhere in the neighborhood of 100-200 approved specs.
<Kamion> (given my already high workload)
<robertj> Kamion: no, I was just under the impression that you were interested, that's all, you certainly don't need to be involved in everything
<Kamion> I think I commented on things going past, but TBH I'm not interested enough to take a side :-)
<robertj> bluefoxicy: there are lots of priorities as well
<robertj> bluefoxicy: so lots of the low stuff are approved if someone does them...
<mdz> doko: you might be interested in bug 54650
<Ubugtu> Malone bug 54650 in xserver-xorg-video-ati "[Edgy]  System freezes when loading gdm" [High,Confirmed]  http://launchpad.net/bugs/54650
<mdz> doko: seems to be toolchain related
<doko> mdz: ohh, nice, pitti will be happy as well :-/
<imbrandon> who was wanting the edgy usplash pictures if they dident look right ? ( edgy of course )  my poor iBook seems to not want to fill the screen with the test patern like my x86 boxes
<mdz> doko: my X was broken for 2 weeks due to this ;-)
<Kamion> could it be a gdm child process crashing due to an SSP check and then gdm hanging waiting for it, or something?
<bluefoxicy> damn, looks like Xen won't fit in Edgy though.  Oh well.
<doko> mdz: you know, I'm still working on dapper-updates on my T42 ;-)
<robertj> imbrandon: iBook intel or ibook g3/g4?
<imbrandon> iBook g3 800mhz
<imbrandon> ppc
<mdz> doko: do you think it's possible to track it down or should we just build the server with -fno-stack-protector?
<imbrandon> there is no iBook intel afaik , only mac book pro == intel 
<robertj> imbrandon: now that my wifes' new laptop is here I can upgrade my g3 to edgy, track me down a week or so from now ;)
<bluefoxicy> iwj:  "We should consider whether we can have the default Edgy kernels support Xen out of the box (ie, provide xen-enabled kernels) now that recent Xen allows kernels to target both i386 and Xen/i386. -iwj"  <-- what, you mean I could boot a Xen kernel on straight i386 without Xen?
<robertj> imbrandon: ibook was renamed macbook, macbook pro is the new powermac
<robertj> but if it looks like a toilet, its an ibook
<imbrandon> robertj: ahh ok no this is an orig iBook, but anyhow yea no biggie just wanted someone to know ;)
<mdz> doko: I'm not even sure what part of it is breaking
<robertj> err new powerbook
<robertj> imbrandon: #ubuntu+1 might be a good spot too
<robertj> and bugzilla
<robertj> err launchpad
<bluefoxicy> robertj:  I have been wanting a PPC arch for a while, to test Ubuntu PPC on... qemu on Ubuntu doesn't like PPC >:|  Fix qemu!  :D
* robertj smashes toes in door as pentinence
<imbrandon> robertj: yea i just rember from the ML that someone wanted actual picktures but i have no digi cam atm
* bluefoxicy actually did try numerous times to get Breezy and Dapper to install in qemu-system-ppc.. :/
<imbrandon> bluefoxicy: yea it dosent like 2.6 kernels its a qemu-system-ppc thing
<LaserJock> I finally got Dapper on my intel iMac the other day, it was nice to see the brown ;-)
<imbrandon> LaserJock: nice
<bluefoxicy> imbrandon:  I can't even get video up properly, much less reach grub
<bluefoxicy> imbrandon:  or isolinux as it may be.
<imbrandon> bluefoxicy: tried dist upgrading from the debian pre install that can be downloaded ?
<bluefoxicy> nope
<imbrandon> bluefoxicy: ok dont waste the time ( it dosent work lol ) but yea its a qemu / pearpc thing not ubuntu , no modern distros work on it
<imbrandon> the debian thats preloaded is VERY old
<imbrandon> ( as far as the ppc qemu of course )
<doko> mdz: I'll have a look at it tomorrow, added it to https://wiki.ubuntu.com/GccSsp
<imbrandon> one thing is the altecv stuff is very experimental etc
<bluefoxicy> imbrandon:  I don't feel like trying again anyway, I had to go and manually download a video bios image from somewhere I found on google... I think Ubuntu has openhackware now so I don't need to go looking for a system bios... and after it all it still didn't work.
<imbrandon> bluefoxicy: you can get it all from debian unstable ( if ou try in the future just FYI )
<bluefoxicy> imbrandon: nods.
<imbrandon> afaik the sparc cd's dont load in qemu-system-sparc either , havent looked into that much either but i'd assume its the same problem
<bluefoxicy> imbrandon: I don't have money for a sparc either; why is ubuntu building for sparc again?
<imbrandon> business servers , heh
<Kamion> because we like to taunt you
<bluefoxicy> Scalable Processor ARChitecture or something
<mdz> doko: thanks
<bluefoxicy> Kamion:  I don't think Sun will support you if you rm -rf solaris ;)
<wasabi_> Wow. new root=UUID= thing.
<wasabi_> Completely failed on my setup at work. Don't klnow why yet. EVMS.
<mjg59> Magic, isn't it?
<mjg59> Yes, there may still be a couple of issues
<wasabi_> It's attempted magic. ;)
<wasabi_> I like it. I'd like to see UUIDs used in more places though, obviously.
<wasabi_> LIke fstab.
<mdz> mjg59: mailed -devel with further usplash 0.4 experience
<wasabi_> Even though it confuses the hell out of people reading fstab. ;)
<mjg59> mdz: Ta
<cprov-dinner> doko: build aborted and another bug discovered ... marked it manually as failed, should be enough for now.
<wasabi_> Hmm. Also, any way /var/lock can be rebound during boot, instead of mounted over?   /var/lock/.hidden or something
<mjg59> mdz: Works on amd64 as well now
<doko> cprov-dinner: another soyuz bug?
<wasabi_> Hiding it sort of makes it a pain for me to clean it up to stop the annoying message on boot.
<cprov-dinner> doko: what a surprise :(
<mdz> mjg59: sabdfl is going to kiss you
<mjg59> mdz: I'll accept booze
<mjg59> mdz: Autodetecting the correct resolution is going to be a pain
<mjg59> And it's possible that this will fuck up horribly on some machines
<mjg59> But I think it's got a better chance than vesafb, so it's worth a go
<wasabi_> Attempt to get a high res usplash?
<mjg59> wasabi_: Oh, it works
<wasabi_> Nifty. If only I could make my BIOS stfu.
<HiddenWolf> wasabi, not without killing it, I'm afraid.
<mjg59> mdz: There's bloat of about 250K as a result of this
<mjg59> Plus any extra bloat caused by increased artwork size
<mjg59> Someone could probably trim that down
<mdz> mjg59: uncompressed?
<mjg59> Oh, it's probably only about an extra 100K once gzipped
<mdz> ha
<mdz> ah
<mjg59> So I guess it could be worse
* mjg59 checks the svgalib build on amd64 as well
<mdz> mjg59: it's statically linking svgalib I assume/
<mdz> ?
<mjg59> Getting svgalib to use x86emu was the only really painful part of this
<mjg59> mdz: Yeah
<Kamion> wasabi_: um - fstab is converted to UUIDs on upgrade to edgy
<Kamion> (libvolumeid0)
<wasabi_> Oh looky there. You are correct.
<mdz> wasabi_: you can mount --move it and then clean it out
<mdz> at least intuitively that should work
<mdz> that message is pointless, we should just disable it
<wasabi_> Agreed.
<mdz> it uglifies usplash too
<wasabi_> It's pretty typical for programs not to clear /var/lock on shutdown.
<wasabi_> So, most ugprades to edgy will end up with it.
<wasabi_> Actually, I guess dapper has it too.
<wasabi_> So they have it now. :)
<mdz> wasabi_:  there are directories in /var/run managed by the packaging system; there will always be something there
<mdz> and nothing has a  chance to clear them out at shutdown anyway; they stay mounted until quite late
<wasabi_> Wonder how long it will take the unix diehards to complain about the disaster fstab just became.
<Kamion> it took about ten minutes
<Kamion> the comments do help though
<Kamion> and they'll see the point as soon as /dev/hd* becomes /dev/sd* ;-)
<wasabi_> Heh.
<Seveas> it should be possible to mount disk id's instead of /dev/foo
<wasabi_> Yeah. 'mount' needs love.
<Seveas> mount -t ricer UUID:31312329381231 /var 
<mjg59> Oh oops
<crimsun> it's possible for a few fs types already
<mjg59> mdz: is usplash maintained in bzr?
<HrdwrBoB>  I use LVM for that reason
<Seveas> mjg59, lp.net/products/usplash/+branches
<mjg59> Right
<wasabi_> Wonder how network block devices deal with UUIDs
<mjg59> I need something that bitches at me when I do things like modify packages that should be kept there
<wasabi_> Do the UUIDs come from the file systems? or the device?
<mjg59> wasabi_: The fs
<wasabi_> And then, what about dm devices?
<Seveas> mjg59, it's called "keybuk"
<mdz> mjg59: yes
<wasabi_> It's reasonable for /dev/hd* and /dev/md* and /dev/lvm* and /dev/evms/* to all point to the same fs.
<wasabi_> Hence, have the same UUID.
<mdz> mjg59: I have a script which checks the wiki and bitches at me
<wasabi_> That might actually be my issue. ;)
* mjg59 sorts out bzr
<mdz> at least, it's meant to.  I don't think I've tested it
<mdz> hmm, it doesn't
<mdz> because the wiki gives it a 403 for some reason
<mdz> apparently, wget isn't allowed to do ?action=raw
<mdz> that's pretty lame
<wasabi_> \?
<mjg59> How long does it take between adding a public key and it hitting the hosts?
<mjg59> Oh, approximately no time at all
<bluefoxicy> anyone know how I could find out all the optimizations (LDFLAGS and CFLAGS) that stuff is built with on Ubuntu's build servers?
<bluefoxicy> preferably without logging into the build servers, since you know, I don't have an account and don't belong there :>
<Kamion> bluefoxicy: apt-get source $package
<Kamion> and the gcc default
<Kamion> s
<Kamion> there's no buildd magic
<bluefoxicy> Kamion:  it's built with i486 instrs and i686 scheduling, with -Wl,-O1, etc... so that's all in gcc defaults?
<Kamion> yes
<Kamion> well, not -Wl,-O1, that's only done in certain packages
<Kamion> contrary to rumour it is not done globally
<bluefoxicy> I thought it was system-wide on the buildd
<Kamion> it's not
<Kamion> (to my knowledge)
<bluefoxicy> wow.  I asked months ago and numerous people said it was done globally.
<Kamion> even when we used gcc-opt to override gcc flags on the buildds - which we don't any more as of edgy - I'm pretty certain that it never knew how to override linker flags
<Kamion> all it did was force compiler flags to be within certain optimisation ranges
<bluefoxicy> heh
<Kamion> oh, and set -mtune=pentium4 -march=i486, but those are the gcc defaults now
<bluefoxicy> Kamion: Maybe you should start thinking about optimizing linker flags after Edgy is out, it'd make for good discussion, re http://lwn.net/Articles/192624/
<Kamion> not me personally
<bluefoxicy> no, not you personally :P
<mjg59> mdz: Right. I haven't fixed the init script, but nobody will actually be getting their hands on it until svgalib is in main /anyway/
<mjg59> mdz: Can we take individual binary packages from a source without pulling them all in? I'm not necessarily happy with the svgalib demo binaries, since they're probably all suid root. The library itself is fine.
<Kamion> mjg59: yes
<Kamion> please note that in the main inclusion report though
<Kamion> so that we have a fighting chance of not accidentally promoting the demo binaries in future
<gnomefreak> xgl/compiz are in official repos?
<mjg59> gnomefreak: Yes, but currently old versions
<gnomefreak> hmmm
<mdz> mjg59: the primary reason we keep it out of main is to prevent nasty suid binaries from creeping in through other packages
<gnomefreak> mdz: i say kick it out all together
<mdz> gnomefreak: I was talking about svgalib
<gnomefreak> oh
<mjg59> mdz: Right
<mdz> mjg59: though the main inclusion process should prevent that just as well nowadays
<mdz> except where Debian introduces something without our knowledge
<mjg59> mdz: To be honest, I'd be quite tempted to say that we can't support all of its code
<mjg59> But the chances of anyone actually having hardware old enough that svgalib claims to support it (other than through vesa) is, well, small
<mdz> mjg59: would it be feasible to copy the bits you need into usplash, as with bogl?
<mjg59> mdz: Not in any remotely trivial manner
<mjg59> The build system is a nightmare
<mdz> I'd like to find a way to let it into main for usplash without exposing us to any potential evils
<mjg59> Sure
<mdz> maybe I'm paranoid; it's probably unlikely that new suid programs are popping up due to svgalib
<mdz> in this day and age
<mdz> one would hope
<mjg59> It wouldn't be /too/ difficult to add a new source package that just builds the vesa support
<mjg59> There's a pile of defines to enable and disable individual drivers
<mdz> mjg59: perhaps we could fix it to blow up if it detects  it's running suid
<Kamion> mdz: could you have a look through ubiquity 1.0.14 in dapper-updates? it's mostly translation updates and just a couple of small bug fixes; I changed the progress bar like you asked too
<Kamion> (it's uploading at the moment)
<mdz> Kamion: I assume it's suitable for upgrading a dapper live CD and testing?
<Kamion> mdz: if you could accept it at some point over the next day if it's OK, that would be good
<Kamion> mdz: yes; make sure you upgrade ubiquity, ubiquity-frontend-gtk, and ubiquity-ubuntu-artwork, and probably gparted as well
<Kamion> one of these days I should tighten the dependencies there
<mdz> Kamion: is it finished uploading?
<Kamion> yes, just
<mjg59> mdz: Sure
<mjg59> mdz: Though that might break other apps
<mjg59> mdz: ISTR quake using it for mode setting and needing to be suid as a result...
<Kamion>    78120 | S- | ubiquity             | 1.0.14               | 5 seconds
<Kamion>          | * ubiquity/1.0.14 Component: main Section: admin
<mdz> just made the queue run it looks like
<mdz> Kamion: is it safe to build it on edgy and for installation on dapper, for testing purposes?
<mdz> s/and /
<Kamion> mdz: I wouldn't recommend it
<Kamion> I'm not sure what the current python toolchain will do
<Kamion> and it build-depends: libparted1.6-dev which is dead in edgy
<Kamion> you can build it on the live CD; if you want to avoid too many build-deps, skip installing python-kde3-dev and build with UBIQUITY_NO_KDE=1 set in the environment
<Kamion> I do that all the time
<mdz> ok
<mdz> do you have a cut-and-waste handy for the list of packages I need on top of the live CD?
<Kamion> afraid not - I do build-essential devscripts fakeroot, then cut-and-paste from dpkg-checkbuilddeps output
<Kamion> unfortunately its output is not in the most convenient format
<mdz> apt-cache showsrc "$1" | grep-dctrl -nsBuild-Depends '' |head -1 | \
<mdz>         sed -e 's/ ([^)] *)//g' -e 's/,//g'
<Kamion> build-essential devscripts fakeroot apt bison debhelper dpkg-dev flex grep-dctrl intltool-debian iso-codes libart-2.0-dev libdebconfclient0-dev libdebian-installer4-dev libglib2.0-dev libgtk2.0-dev libparted1.6-dev libxml-parser-perl locales po-debconf python python-gtk2-dev python-xml python2.4-dev wget
<Kamion> I guess that would do
<Kamion> (didn't bother trimming, as you can tell)
<Amaranth> what's the magic to build a package without stripping it?
<Kamion> Amaranth: DEB_BUILD_OPTIONS=nostrip; see the dh_strip(1) man page
<Amaranth> ah, thanks
<mdz> Kamion: eek, 206MB
<mdz> (with kde)
<mdz> still 90M without
<mdz> this machine has plenty of RAM though, fortunately
<Kamion> that's why I did the UBIQUITY_NO_(GTK|KDE) thing ...
<mdz> Kamion: has riddell tested this version on Kubuntu?
<Kamion> mdz: I don't believe so
<mdz> Kamion: please ask him to do so before we roll kubuntu for the point release
<mdz> sort-countries certainly takes a long time
<Kamion> it's running localedef a lot
<mdz> Kamion: I just noticed that dapper-updates isn't in sources.list on the dapper live CD
<mdz> we ought to fix that in the point release, if it isn't automagically fixed in the process
<Kamion> I believe it is; the livefs build process for dapper involves an update/upgrade to dapper-{security,updates}
<mdz> test install is in progress
<mdz> Kamion: the more I look at the time remaining indicator in ubiquity, the more I feel that (in edgy) we should change it to display "about N minutes" and forget seconds
<Kamion> mm, quite possibly
<mdz> that's what both macos and windows did the last I saw, and it's a smoother experience
<Kamion> need to check what they do once it gets below a minute
<Kamion> (since I'll probably need separate debconf templates to make both situations translatable)
<mdz> Kamion: I think it's "less than 1 minute remaining" or even still "about 1 minute"
<mdz> Kamion: 1.0.14 accepted
<Kamion> thanks
<robertj> mdz: will install stages have artwork in the point?
<robertj> or at least have all the stuff leff justfied
<mdz> robertj: point releases are bug fixes only
<mdz> not eye candy
<robertj> mdz: I know, but I thought you might have received the artwork anyway and its about as low-risk as you can get
<mdz> besides which, nobody has implemented such a feature
<robertj> mdz: I thought it was contracted out
<mdz> there is neither artwork nor a place in the UI for it, in dapper or edgy
<imbrandon> mdz yea on OSX its "less than 1 minute remaining" for > 60sec and "about 1 minute remaining" for > 2min but < 1min everything else is in minutes
<mdz> imbrandon: I think your <> were backwards but I understand :-)
<imbrandon> err yea LOL just noticed that hehe
<imbrandon> without getting killed , can i ask the status of -backports / soyuz for edgy --> dapper ?
* imbrandon ducks
<rodarvus> mdz, thanks for tracking #54650
<rodarvus> I don't have this problem locally, and was having a hard time debugging it
<rodarvus> it was apparently happening for via and (possibly) sis
<mdz> rodarvus: as well as ati? eek
<rodarvus> yup, but its not for all cases, very few ones, actually
<LaserJock> imbrandon: what do you want to know?
<imbrandon> LaserJock: ?
<LaserJock> imbrandon: without getting killed , can i ask the status of -backports / soyuz for edgy --> dapper ?
<imbrandon> ohh when soyuz was going to be able to let the bckports team start to process them 
<imbrandon> afaik thats all that was lacking
<LaserJock> I thought it already did
<LaserJock> could be wrong
<imbrandon> nope -backports still looks mighty empty 
<imbrandon> and still lots waiting on LP to be backported , crimsun said it was becoue of lack of soyuz support a week or so ago
<LaserJock> hmm
<imbrandon> http://archive.ubuntu.com/ubuntu/dists/dapper-backports/main/source/Release
<imbrandon> s/main/universe same thing
<bluefoxicy> I uh.  Yeah I'll take that to the mailing list.
<bluefoxicy> Er.  Is now not the best time to get on about Edgy+1 toolchain details on -devel?
* bluefoxicy is aware that the toolchain needs to be ready by the time the distro opens; just isn't sure how early discussion should be gotten at.
<crimsun> My kde-guidance (0.6.7-3ubuntu2) upload (fixing bug 54742) 92 minutes ago seems to have been eaten by a grue.
<Ubugtu> Malone bug 54742 in kde-guidance "Broken symlinks in kde-guidance-0.6.7-3ubuntu1" [Medium,Fix released]  http://launchpad.net/bugs/54742
<bddebian> A grue? Haha, I haven't heard that in forever
<robertj> bddebian: grues have been almost hunted to extinction by their natural predator, the wumpus
<bddebian> :-)
<bddebian> And cats hunt wumpus, hence catty wumpus?
* robertj makes a note to put a grue in his game
<bddebian> OK, that was really bad.. :-)
<bluefoxicy> what the fuck
<bluefoxicy> I am going to assume everyone here is on edgy
<bluefoxicy> On that note I strongly advise examining your swap layout
<bluefoxicy> bluefox@icebox:/tmp/x$ swapon -s
<bluefoxicy> Filename                                Type            Size    Used    Priority
<bluefoxicy> /dev/sda5                               partition       2104472 408120  -1
<bluefoxicy> /dev/evms/sda5                          partition       2104472 0       -2
<bluefoxicy> because my kernel thinks I have 4 gigs of swap and I'm not sure what happens once I fault through the first swap file.
<bluefoxicy> # /dev/sda5 -- converted during upgrade to edgy
<bluefoxicy> UUID=c3e782d2-8f84-4ac9-b7da-1b2bb89c5b1d none swap sw 0 0
<bluefoxicy> this MAY be the culprit
<jcsmith> hi all: is there an overview of whats planned for edgy out there anywhere thats somewhat up to date?
<TheMuso> bluefoxicy: I seem to be showing twice the amount of swap I should have.
<bluefoxicy> TheMuso:  swapon -s plz.
<TheMuso> luke@linden:~$ swapon -s
<TheMuso> Filename                                Type            Size    Used    Priority/dev/sda2                               partition       1052248 0       -1
<TheMuso> /dev/evms/sda2                          partition       1052248 0       -2
<TheMuso> SOrry bout the formatting
<bluefoxicy> TheMuso:  yeah..... that would be it.
<bluefoxicy> I'm going to mark this bug critical.  Just a guess.
<bluefoxicy> oh nm.  I can't mark importance apparently so https://launchpad.net/distros/ubuntu/+bug/54753  Have fun.
<Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Unconfirmed]  
<TheMuso> I'll add a comment to that.
<TheMuso> Hey Hobbsee 
<TheMuso> You in edgy atm?
<Hobbsee> hi TheMuso. yep
<TheMuso> Could you please paste the output of swapon -s command please?
<TheMuso> Seems there is something funny going on with swap and the newly created UUIDs in fstab.
<Hobbsee> sarah@sarah:~$ swapon -s
<Hobbsee> Filename                                Type            Size    Used    Priority
<Hobbsee> /dev/hda6                               partition       546168  0       -1
<Hobbsee> /dev/evms/hda6                          partition       546168  0       -2
<Hobbsee> TheMuso: ^
<TheMuso> Ok you have it to.
<bluefoxicy> TheMuso:  I think it's safe to confirm this one ;)
<TheMuso> Yeah.
<Hobbsee> uh oh, i've got the "kopete is too old" bug again
<TheMuso> bluefoxicy: I am going to try without evms installed and see what happens.
<TheMuso> brb
<TheMuso> That is better, at least for the moment.
<TheMuso> It is kinda easy when you don't use evms.
<bluefoxicy> I would be thoroughly amused if someone had a couple hundred megs in the first swap device and decided to shut it off
* Hobbsee hasnt explicitly set up EVMS
<bluefoxicy> and it wrote it all into the evms copy
<TheMuso> evms gets installed by default and loads anyway
<bluefoxicy> and went WHAT THE HELL HELP *panic()*!
<Hobbsee> true
<TheMuso> hmmm
<TheMuso> Evms doesn't exist in the edgy archive.
<Hobbsee> bluefoxicy: TheMuso any idea what that package should be?
<bluefoxicy> what package?
<TheMuso> Hobbsee: sudo apt-get --purge remove evms should be alright
<TheMuso> evms
<bluefoxicy> oh, no clue.  bug #54753
<Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54753
<TheMuso> Seems like it no longer exists in edgy
<Hobbsee> bluefoxicy: yeah, i just saw it in -bugs and confirmed it
<bluefoxicy> but I don't think it's evms' fault, maybe.  More ljke the init scripts.
<bluefoxicy> or the kernel
<bluefoxicy> the kernel should probably refuse to do it.
<TheMuso> hmmm
<TheMuso> Hobbsee: You also need to re-configure your initramfs to get rid of evms from it.
<Hobbsee> TheMuso: eek?
<TheMuso> Well it does have initramfs hooks.
<TheMuso> s/reconfigure/rebuild/
<TheMuso> for initramfs
<pitti> Good morning
<ajmitch> morning pitti 
<Hobbsee> hi pitti 
<Hobbsee> oh yay, two uploaders to main
<pitti> hi ajmitch, moin Hobbsee 
<pitti> infinity: once pkg-create-dbgsym 0.5 is in the buildd chroots, can you please give-back openoffice.org?
<pitti> infinity: ^ nevermind, doko uploaded a new version anyway
<bluefoxicy> so does anyone know when a good time would be to discuss edgy+1 toolchain things?
<jsgotangco> the development summits are a good time to discuss it with an appropriate spec i guess
<Hobbsee> bluefoxicy: were you planning to go to the edgy+1 dev summit?
<bluefoxicy> Hobbsee:  Not unless it's in Baltimore.
* imbrandon votes for kansas city
* bluefoxicy is poor.  Simple as that, he can't afford air fair.
<imbrandon> anyone else having truble connecting to archive.u.c or gb.archive.u.c ?
<Hobbsee> ah ok
<Hobbsee> imbrandon: no
* Hobbsee wonders what has created excessive piles of stuff on her desktop
<tritium> Hobbsee: the chupacabra did it
<imbrandon> lol
<Hobbsee> tritium: hehe.  i believe it was bits of compiling.
<tritium> Hobbsee: :)
<bluefoxicy> jsgotangco:  there's already stuff at https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap and I appended a few things to it but there are some interesting thoughts I've had along the way.  Plus I'm still itching to get pax-utils into universe and the 'janitors team' gives me an excuse ;)
<Amaranth> pitti: slam dunk
<Amaranth> (avahi)
<Burgundavia> Amaranth: ?
<Amaranth> Burgundavia: his mail to u-d about avahi, it was the perfect response
<ajmitch> now we just need one to shut up the mono thread
<Amaranth> ajmitch: Go right ahead. :)
<pitti> Amaranth: ?
<Hobbsee> bleh.  debian added two versions, but didnt actually fix what they botched.
<pitti> Amaranth: oh, avahi is on topic for today's TB meeting :)
<Amaranth> today's?
<Burgundavia> pitti: great email, lays out an exact course
<Amaranth> oh, i guess i did just flip over to tuesday
<Burgundavia> Amaranth: where in the real world are you?
<Amaranth> iowa
<Amaranth> middle of the US
<Amaranth> it's actually 0126 here
<Burgundavia> you are near nuzum then
<Amaranth> so by 'just' i mean 'wow, that's the first time i noticed it was tuesday'
<Hobbsee> heh
<Hobbsee> @time sydney
<Ubugtu> Current time in Australia/Sydney: August 01 2006, 16:27:12
<Hobbsee> stop living in the past, you :P
<Amaranth> where is nuzum?
<neuralis> ff/win 1
<neuralis> er.
<Hobbsee> any core devs feel like uploading a couple of things for me?
<Burgundavia> neuralis: uh?
<Burgundavia> Hobbsee: why don't you apply for yourself?
<Hobbsee> Burgundavia: you're as bad as crimsun.  do you think i'd get it?
<Hobbsee> Burgundavia: but then again, there *is* a meeting tomorrow....
<Burgundavia> Hobbsee: despite a little kde brain damage ;), I see lots of uploading into main recently
* Hobbsee wonders if she could be at the meeting, and get to uni tomorrow
<Burgundavia> plus a good track record
<Hobbsee> Burgundavia: hehe yeah, it's getting pretty hard to find uploaders.  
<crimsun> Hobbsee: I can try
<crimsun> Hobbsee: my key issue might bite again, we can see.
<pitti> Hobbsee: toss me a debdiff and I'll check/upload it
<Hobbsee> pitti: okay.  debdiff is at http://buntudot.org/people/~hobbsee/kopete.debdiff  - to go on kopete in edgy :)
* pitti hugs dholbach 
<Hobbsee> hi dholbach!
* Hobbsee hugs dholbach too
<Hobbsee> crimsun: dont feel left out, i have another one, i'm just double checking that debian's changes semi-work.
<dholbach> hey Hobbsee, hey pitti! howare you?
<dholbach> good morning everybody
* dholbach hugs crimsun
<Hobbsee> dholbach: i'm fixing things :D  in main :D
<crimsun> Hobbsee: heh, uploading for me is a 50/50 thing. Either it works brilliantly, or I get no feedback at all.
<dholbach> Hobbsee: ROCK ON
<Hobbsee> crimsun: heh
<pitti> dholbach: a little tired, I woke up too early; but good enough :)
<Hobbsee> dholbach: now i should go for core, i'm told :P
<dholbach> pitti: when did you wake up?
<pitti> dholbach: at 6, my hayfever struck again
<dholbach> urg :/
* dholbach hugs pitti
<pitti> Hobbsee: kopete_3.5.4+kopete0.12.1 ???
<pitti> yay for version number sanity
<Hobbsee> pitti: that's the one.  yeah, i know.
<Hobbsee> pitti: it's not nice.  and i was the one to version it that way.  there is a reason behind it
<pitti> Hobbsee: uploaded
<Hobbsee> pitti: thankyou :)
<pitti> Hobbsee: well, it should be 3.5.4+0.12.1
<Hobbsee> pitti: wish icq wouldnt change their protocols so often :P
<Hobbsee> pitti: i think i tried that....and it wasnt updating.  we had trouble, anyway
<pitti> heh, IRC is like X, 'twenty years and still binary compatible' :)
<pitti> Hobbsee: no, nevermind, 3.5.4+0.12.1 << 3.5.4+kopete0.12.1
<Hobbsee> pitti: yeah, that's what i think we found
<pitti> Hobbsee: just a small morning rant, that's all :)
<Hobbsee> pitti: hehe, that's okay :)
<bluefoxicy> copy and paste is being shit and it's really really REALLY starting to piss me off but I cannot determine EXACTLY what the problem is and "C&P is being shitty" is not a good bug report!  >:|
<bluefoxicy> it seems to only affect certain applications
<bluefoxicy> except those applications can destroy the clipboard for other applications and I'm not sure which is which
<bluefoxicy> but one of them is definitely xchat-gnome
<Hobbsee> hehe.  i thought that about my "keyboard randomly stops working" error - how on earth do you go about debugging that???
<bluefoxicy> Hobbsee:  can of raid and a screw driver.
<Hobbsee> bluefoxicy: hehe
<Hobbsee> bluefoxicy: it works when you log out of kde
<Hobbsee> (cue reports of "dont use kde, problem solved)
<bluefoxicy> don't-- damnit Hobbsee don't do that.
<Hobbsee> hahaha
<bluefoxicy> Hobbsee:  no joke, in my security class there were these two high school kids (yes this is at a college), one used KDE on Fedora and the other used GNOME on Ubuntu
<bluefoxicy> and they started talking about DE's so I gave a simple technical explanation why KDE sucks, like 2 minutes.
<bluefoxicy> For the rest of the class, every time they brought up linux
* Hobbsee likes KDE.
<Burgundavia> Hobbsee: we hadn't noticed ;)
<Hobbsee> Burgundavia: :P at you.
<jsgotangco> let's not resurrect an age old war
<bluefoxicy> "You use that stupid ubuntu thing when fedora is so much better, and what is with GNOME it's a pile of crap"
<Hobbsee> jsgotangco: had no intention of it :P
<Burgundavia> bluefoxicy: seriously, not here, try -offtopic
<bluefoxicy>   "No way that ugly bloated desktop you use doesn't work half teh time and fedora breaks" blahblahblah on and on he couldn't say "KDE" it was funny.
<bluefoxicy> Burgundavia:  hahaok :P
<dholbach> bluefoxicy: admirable sentiments, but it's enough
<bluefoxicy> haha
<bluefoxicy> dholbach:  keybuk has ascii art of you
<dholbach> bluefoxicy: i know
<Kamion> crimsun: http://librarian.launchpad.net/3685578/vSLlaYID2s9avqQulVSjHfIUNSB.txt - may be transient, if that key is definitely good then my best advice is to try reuploading :-/
<crimsun> ok, I'll try reuploading; it's the same key I've been using during Edgy thus far
<Kamion> I've noticed similar weirdness before - need to make sure there's a Soyuz bug filed about it
<Hobbsee> Kamion: when are you building the dapper point release?  which day this week?  i've got a fix that i want in.
<Burgundavia> Hobbsee: all demand and no ask I see ;)
<Hobbsee> Burgundavia: of course, of course :P  nah.  i will ask, when i ask him to upload it for me :)
<crimsun> (oh, LP is down for maint.)
<Kamion> Hobbsee: dunn
<Kamion> o
<Hobbsee> Kamion: in the next few hours?  /me is test building still.
<Kamion> upload sooner rather than later if you want something in; I don't have an exact day
<Kamion> I'm off work today (wife's birthday), so not in the next few hours
<Hobbsee> Kamion: i'll be bugging you soon about it - but i will check that nothing has blown up first :P
<Hobbsee> Kamion: ah, okay
<Kamion> and not today, for that matter
<Hobbsee> cool :)
<Hobbsee> Kamion: enjoy your wife's birthday
<Kamion> will do, we're off to the safari park
<dholbach> Kamion: enjoy it!
<Hobbsee> Kamion: ooh!  fun!  post pictures, or face my long pointy stick :P
<dholbach> ogra: gnome-screensaver update for dapper? 2.14.3?
<ogra> hmm, i have to look at the changes ...
* Hobbsee waves to ogra 
<mvo> jdub: is your apt-get problem with the latest edgy apt version solved (that it failed to download .bz2 files)?
<Hobbsee> mvo: he's possibly still on a plane
* ogra waves back to Hobbsee :)
<mvo> Hobbsee: ah, thanks
<Hobbsee> ogra: it's being suggested that i go for core tomorrow :)
<Hobbsee> mvo: on his way from portland to sydney - not sure when he gets in though
<\sh> moins
<Hobbsee> hi \sh!
<\sh> hey hobbsee....
<ogra> Hobbsee, yay ... i'll cheer for you :)
<ajmitch> mvo: was it downloading partial files & then failing?
<Hobbsee> ogra: hehe!  thanks :)
<Hobbsee> ogra: depends if i'm awake
<mvo> ajmitch: no, not downloading .bz2 files at all, just .gz files
<ogra> (it's today for me btw ;) )
<Hobbsee> any ETA on when launchpad is back up?
<Hobbsee> ogra: true.  that's because you like living in the past :P
<ogra> haha
<ajmitch> mvo: ok, I was having a different problem (and blamed my proxy)
<mvo> ajmitch: proxies are evil!
<mdke> Hobbsee: any time now, downtime was estimated to be 10 minutes
<pygi> sivang, poke
<Hobbsee> mdke: okay
<mvo> infinity: what was your complain about gksu again? I'm currently looking into it
<ajmitch> mvo: yes, it was not being happy with my local squid
<mvo> ajmitch: oh? I have a local squid that works pretty good in my local net, no problems with apt. I usually blame proxies that are configured in a way that they are too agressive
<Hobbsee> oh yay, LP is back
<ajmitch> mvo: I'll try & reproduce it
<mvo> ajmitch: ok, thanks
<jdub> mvo: i'll have a poke now
<Hobbsee> ah, jdub does exist!
* Hobbsee waves to jdub 
* pitti hugs jdub 
<mvo> jdub: thanks
<jdub> morning
<seb128_> hey jdub
<Hobbsee> hi seb128_ 
<seb128_> Hi
<doko_> pitti: http://librarian.launchpad.net/3692782/buildlog_ubuntu-edgy-i386.openoffice.org_2.0.3-4ubuntu2_FAILEDTOBUILD.txt.gz :-(
* pitti looks
<infinity> mvo: The fact that it's now offering to save passwords (and appears to do so by default), which kinda defeats the whole "using sudo helps you know that you're doing stuff as root" thing.
<infinity> Kamion: The pockets are traditionally meant to be self-contained.  Last time we did a d-i upload, I hacked up the chroots just for d-i to allow security.
<mvo> infinity: right, I will disable the whole "default" thing at least
<seb128_> I find it handy
<pitti> mvo++
<pitti> doko_: *boggle*
<Hobbsee> infinity: you going to be around for a while? 
<pitti> doko_: argh, indeed I did recoomends, suggests, conflicts, provides, breaks, depends, but I forgot about replaces; damn me :/
<infinity> Hobbsee: Should be here all night.
<Hobbsee> infinity: cool.  can you ack stuff to dapper-updates?
<pitti> doko_: I'm terribly sorry, I fix it now, upload, and ask infinity to give-back once 0.6 is in the archive
<infinity> Hobbsee: Depends.  Does it have approval from Kamion or mdz?
<Hobbsee> infinity: nope
<Hobbsee> infinity: kamion isnt working today, and it's too ealry for mdz
<infinity> Hobbsee: I believe that, technically, I'm a member of the group allowed to give such approval, but I've not been oficially delegated this task, so I'm wary.
* Hobbsee still has to go and test the fix.  but i'll do that after i get an answer
<infinity> Hobbsee: If it's small and obvious, I'll look it over and take the heat for it, though.
<Hobbsee> infinity: 1 line patch :P
<Hobbsee> infinity: let me reboot and check that it works first though
<infinity> Hobbsee: Excellent, then test away, and give me a debdiff before you upload.
<Hobbsee> infinity: debdiff is at http://buntudot.org/people/~hobbsee/kdenetwork.debdiff - i'll be back in a few mins.
<infinity> Hobbsee: Oh, yeah, if that is tested to work, I'm cool with that.
<infinity> Hobbsee: Is the fix pulled from a new upstream or CVS or something?
<Hobbsee> infinity: it's not yet, mainly cos i'm lazy :P
<Hobbsee> infinity: from kde, yeah.
* Hobbsee patched and got pitti to upload the edgy version of the fix earlier
<infinity> Hobbsee: Kay, then yeah.  Test it and get back to me, and I'm fine with it if it works.
<pitti> Hobbsee: oh, is it that kopete fix?
<Hobbsee> pitti: yes
<pitti> infinity: it just changes the ICQ protocol magic number
<Hobbsee> infinity: fortunately it's an easy test :P  "does icq connect?  yes/no"
<pitti> looks fine for me
* infinity nods.
<infinity> pitti: Yeah, I still want it tested. :)
<pitti> absolutely
* pitti uploads pkg-create-dbgsym 0.6 to make doko_ and OO.o happy and fetches the brown paper bag
<doko_> infinity: please kill sparc build of openoffice.org 2.0.3-4ubuntu2 in ubuntu edgy
<doko_> infinity: please kill powerpc build of openoffice.org 2.0.3-4ubuntu2 in ubuntu edgy
<pitti> mvo: hm, I thought edgy's apt-get would automatically remove dependencies now?
<mvo> pitti: only if you tell it: "apt-get remove --auto-remove"
<infinity> doko_: Will do.
<pitti> mvo: ah; that shouldn't be the default?
<pitti> mvo: right, now it works; purging f-spot removes the whole mono stack, too :)
<Hobbsee> infinity: awww....crap.  i have kde 3.5.3 on here, and i'ts not easily going to let me install kdenetwork 3.5.2 without dependancy hell.
<pitti> ajmitch: still here?
<mvo> pitti: we could make it default, yeah. I was a bit worried initially that it might have problems and is too over-enthusiastic
<Lathiat> i could see it causing problems wher eyou using something that was pulled in as a dependancy and it magically disappears, i guess
<pitti> mvo: hm, ok, principle of least surprise
<Lathiat> (like, from a non-packaged program, or whatever)
<pitti> mvo: a shorter option (-a?) would work, too :)
<infinity> Hobbsee: Run it in a dapper chroot?
<Hobbsee> infinity: ahh.  works a charm, feel free to upload it :)
<pitti> mvo: ... and --auto-purge ;)
<infinity> Hobbsee: Ahh, kay.  Cool.
<Hobbsee> infinity: coulda done that.  i fiddled with my system a bit
<infinity> Hobbsee: I take it that it's in main, and you're not in core-dev?
<Hobbsee> infinity: i hit join team about 5 mins ago, but yeah
<infinity> Hobbsee: I'll sponsor it then, sure.
<Hobbsee> infinity: :)
<Hobbsee> infinity: you can cheer for me tomorrow too if you like :)
<infinity> I only attend such meetings to prevent people from getting into core-dev, not to recommend. :)
<infinity> And since I don't intend to prevent you, I'll just not show up.
<Hobbsee> infinity: ah.  
<Hobbsee> infinity: i guess that's a convenient excuse not to come to meetings :P
<infinity> It works for me.
<mvo> pitti: I guess someone should blog about it, that will spread the word (this seems to be the best way nowdays to get any message out) :)
<mvo> pitti: you are right, a shorter options is needed
* Hobbsee reboots back into nice edgy
* mvo adds it to his todo list
* pitti hugs mvo
* mvo hugs pitti 
<Hobbsee> mmm...nice edgy :)
<mdke> sabdfl: got a minute?
<Hobbsee> hi sabdfl 
<Hobbsee> ack, my touchpad is on steroids.
* pygi pokes sivang ;)
<iwj> bluefoxicy: booting a xen kernel on bare i386> Yes, in principle it's supposed to be possible to get that to work.  However I wouldn't count on the xen kernel we have in edgy supporting that properly.
<mdke> sabdfl: unping, thanks
* pitti sees the svgalib MIR and sighs
<ogra> argh
<pitti> is a hi-res boot splash really important enough to pull in such crack? </whine>
<ogra> pitti, that means we have to revert the svgalib dropping we did in hoary as well, right ? 
<Lathiat> of course
<pitti> ogra: no, why?
<ogra> (dependency dropping)
<Lathiat> "shiny"
<ogra> pitti, because if we have svgalib in main it would be pointless to cut functionallity of packages ?
<pitti> ogra: TBH I would strictly confine svgalib-ness in main
<ogra> but if we'd get it we shoud revert the packges /me thinks
<Lathiat> whats so bad about svgalib?
<pitti> Lathiat: dead upstream, bad package maintenance, suid root programs, reportedly lots of hardware incompatibilities
<Lathiat> ah, awesome
<pitti> and security history
<Lathiat> are there no nicer alternatives for the splash stuff?
* pygi wonders why people think bringing such a distaster could justify nicer boot splash :-/
<pitti> pygi: I certainly don't
<HiddenWolf> pygi, you know what they say about first impressions.
<HiddenWolf> pygi, I don't agree personally, but people see pictures, not vulnerabilities.
* pitti doubts that it is a good first impression if your screen remains black at boot
<pitti> HiddenWolf: I'd rather prefer a VGA that works everywhere than SVGA that doesn't work on half of today's machines
<HiddenWolf> pitti, that'd be the less is more school of thinking, went out of style in the 70's ;)
<pygi> HiddenWolf, do we want to become "preety pictures" distro?
<HiddenWolf> pygi, I don't think so, but I guess you'd get a different responce from an osx crowd.
<pygi> Not that I have any right to vote on this matter, but it's still bad
<pitti> doko_: why shall I merge blender again?
<pitti> doko_: (it's a new upstream version)
<doko_> pitti: this version is already converted to the new python policy
<ogra> pitti, its on my list to look at it ... the new version adds ffmped deos
<pitti> ah
<ogra> *deps
<pitti> deos?
<ogra> heh
<pitti> ah
* pitti happily leaves this to ogra then
<pitti> ogra: did the earlier version have a static copy, or no ffmpeg at all?
<ogra> well, actually lfittl is looking at it and if it still works if we drop the dep
<ogra> no ffmpeg at all
<ogra> its a new feature ... 
<pitti> ok, then let's hope that configure tests for it :)
<ogra> the movie industry discovered blender recently ... there were many features added
<ogra> there is no configure :/
<ogra> blender is a weird package ...
<ogra> scons based ...
<pitti> doko_: you know the dapper-proposed process, as it seems - can we just upload to there and later ask mdz/Kamion to approve and sync to dapper-updates?
* pitti would like to stuff cups 1.2.2 to dapper-proposed
<pitti> mdz half-accepted it, but I don't have his final ack
<pitti> s/accepted/approved/
<doko_> pitti: no, AFAIK mdz and Kamion want explicit approval.
<pitti> ok
<seb128> pitti: what is the difference between dapper-proposed and dapper-updates?
<pitti> seb128: -proposed is not enabled by default
<seb128> ah, yet another source to use
<pitti> seb128: so it's a nice place to be autobuilt and ask people to test packages from it
<seb128> I didn't know about it :)
<ogra> seb128, -proposed is for users willing to test 
<pitti> seb128: it's relatively new
<seb128> so I could upload the new evolution stack to it before dapper-updates then
<ogra> yup
<seb128> has dapper-proposed be announced somewhere?
<ogra> i dont think so ... at least i didnt see an announcement
<mdke> yet another undocumented source which isn't in software-properties :(
<pitti> mdke: that might be because it was introduced after the dapper release :)
<pitti> (at least I think so)
<pitti> we just wanted a staging area for -updates
<mdke> yes, it is. That's the problem with introducing this stuff after release
<mdke> you get a distribution that starts to feel like it has been put together in bits
<ogra> i dont think it should be announced prominently ...
<ogra> software in there is for testing, nothing else ...
<imbrandon> and afaik its been arrounf since pre breezy just not used
<mdke> it's more -commercial that I whinge about
<imbrandon> heh yea i dident / dont see that, why isnt it just in multiverse ?
<seb128_> bah, the dsl connection is not happy today
<ogra> -commercial is exposed very prominently in g-a-i
<mdke> ogra: I'm afraid that isn't good enough. You are still left with a situation where it is undocumented, not in the most prominent sources management tool (software-properties), and only available from one package manager
<mdke> we should probably add it to software-properties and push some documentation updates
<HiddenWolf> mdke, isn't that exactly the point? We don't want people using it unless they know about testing it.
<mdke> HiddenWolf: no, we moved onto -commercial
<HiddenWolf> mdke, if people enable it as a matter of course, it turns into a second -updates
<HiddenWolf> mdke, ah, excuse me
<infinity> mdke: IMO, -proposed shouldn't be exposed in software-properties at all, or people who think they're "power users" will install all our broken crap from there.
<infinity> mdke: Think of it as a staging area for -updates.  It's intended to be broken, and almost always will be.
<mdke> yeah, I understand that
<infinity> And most people who think they're power users don't know how to back out of a failed dpkg run, etc.
<mdke> it's like a second  unstable distribution. I was on about -commercial
<infinity> (Note all the people on lists who claim that dpkg --force-random-option will someone magically make a broken postinst start working, for instance)
* dholbach hugs infinity :)
<infinity> s/someone/somehow/
<mdke> btw who takes care of the -commercial packages?
<infinity> Why do my fingers always autocomplete that one wrong?
<mdke> the vendor themselves?
<mdke> seems there is a bug about realplayer showing up in the wrong place in the menu, maybe we can pass that along
<infinity> The vendors are meant to provide us source packages, but we (Canonical) will also obviously "help", and make sure they're somewhat sane.
<mdke> infinity: so bug reports on launchpad are ok
<mdke> +?
<infinity> It's still a package in the archive, so sure.
<infinity> Do we even have stuff in -commercial yet?
<mdke> thanks
<infinity> I don't even remember setting up -commercial buildds.
<imbrandon> realplaer and opera
<mdke> infinity: realplayer and opera are in there
<mdke> and realplayer is in the "graphics" menu, apparently :)
* infinity wonders if he lost a week somewhere.
<mdke> delusions of grandeur maybe from someone at realplayer
<imbrandon> heh infinity they have been there since the -commercial announcement
<imbrandon> mdke: no it is, leaste in KDE
<imbrandon> ( the realplayer thing )
<mdke> it is what?
<imbrandon> in the graphics menu
<imbrandon> by default
<mdke> ah, ouch
<ajmitch> hi doko 
<infinity> No, seriously, I must have lost a week.  Maybe to VAC.
<mdke> imbrandon: you can confirm bug 52484 then
<Ubugtu> Malone bug 52484 in realplayer "Realplayer is in Graphics submenu, not Sound & Video." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52484
<infinity> imbrandon: Where was this announce?
<imbrandon> umm one of the ML and various news sites arround the web
<imbrandon> mdke: sure one sec
<mdke> infinity: it was announced on sounder, I think :)
<ogra> doko, 
<ogra> Unpacking replacement openoffice.org-draw ...
<ogra> dpkg: error processing /var/cache/apt/archives/openoffice.org-draw_2.0.3-3ubuntu4_i386.deb (--unpack):
<ogra>  trying to overwrite `/usr/lib/openoffice/program/libflash680li.so', which is also in package openoffice.org-core
<ogra> known ?
<Hobbsee> ogra: i believe so
<ajmitch> ogra: current is -4ubuntu2, should be fixed from what the changelog says
<doko> ogra: ask pitti why the fix is not yet in the archive ;)
<ogra> hmm, no -4ubuntu2 for me here ...
<gnomefreak> yes known bug
<ogra> ah, ftbfs :)
<dholbach> ogra: 2.0.3-3ubuntu4-1 is current on edgy (amd64)
<ogra> i'm running i386 on my amd64 laptop currently ... :)
<dholbach> ok
<geser> it's bug 54288
<Ubugtu> Malone bug 54288 in openoffice.org "[Edgy]  openoffice.org-draw 2.0.3-3ubuntu3 fails to unpack due to attempt to overwrite file in openoffice.org-core" [High,Confirmed]  http://launchpad.net/bugs/54288
<jono> hi all
<dholbach> heya jono
<jono> hey dholbach 
* ogra sees debian bug 380859 and cries :(
<Ubugtu> Debian bug 380859 in ltsp "Subject: Python transition (#2): you are building a private python module !" [Important,Open]  http://bugs.debian.org/380859
<ajmitch> ogra: yes, I just got a few of them on packages I have to touch
<ogra> meh ...
<ogra> i dont build any modules though ... the report is wrong ...
<jdub> fabbione: ping
<pitti> doko: I don't know why 0.6 is taking so long :(
<doko> pitti: just built
<doko> infinity, pitti: why is pkgstriptranslations taking so long on rothera?
<pitti> doko: you mean taking long to generate the translation tarball?
<doko> pitti: IIRC, it's now about 45 minutes
<pitti> whoa...
<infinity> That's because it does very retarded things.
<infinity> On every invocation.
<infinity> On huge source trees, it's pretty crap. :/
<infinity> pitti: What was the rationale for searching for translations outside the binary package build directories again?
<ogra> jdub, i guess he's bus breast-feeding ;)
<ogra> *busy
<infinity> pitti: Cause that's the thing that kills it.
<pitti> infinity: because interesting translations are anywhere *except* in the binary package build dirs
<pitti> infinity: I know that it is horribly inefficient, because it's stateless
<infinity> pitti: Right, then.  I suppose there's not much we can do to speed it up, then, unless we teach it to save state.
<infinity> pitti: Hah, jinx.
<pitti> infinity: well, we could make some assumptions if a translation tarball already exists, though
* infinity nods.
<Fjodor> Is there something wrong in the latest edgy kernel wrt sata or xfs? I noticed it took a long time rm -rf'ing a kernel build dir, and are about to time it. Copying it over took 10 minutes(!). That's way too long, and longer than I ever saw on 5.16
<Fjodor> *514
<Fjodor> *5.14
<Fjodor> Deletion time 2m46s. Also way too long
<ogra> dholbach, if at some point jokosher will be stable enough for main inclusion, please ping me, it looks like a really good addition to edubuntu-desktop ;)
<dholbach> ogra: it ROCKs hard :)
<dholbach> jono: ^ words of praise :)
<plaes> any Rosetta guys here?
<HiddenWolf> Do we really need a sound editor in the default desktop?
<phanatic> plaes: #launchpad
<plaes> thx :)
<ogra> dholbach, i know that it rocks :) but 0.1 seems a bit young to consider it for main ;)
<dholbach> ogra: i'm quite sure, jono would say the same :)
<ogra> HiddenWolf, in edubuntu 
<dholbach> HiddenWolf: yeah and drop gnome-sound-recorder :)
<ogra> HiddenWolf, we already ship denemo in edubuntu for notesetting
<jono> ogra, thanks :)
<jono> ogra, 0.1 is too young, but I think 0.2 will be suitable for inclusion
<seb128> ok, I didn't wait enough to dist-upgrade my edgy apparently :p
<seb128> I didn't touch xorg for a week because of the transition but looks like the ati driver still need to be upgraded :/
<Amaranth> fglrx?
<seb128> no, ati
<Amaranth> oh
<Amaranth> i thought ati was fine
<seb128> it's still 7.0 apparently
<Amaranth> it's at least been recompiled for 7.1, i remember that night :P
<ogra> jono, wow, cool !
<geser> I'm also using the ati driver for xorg and I've already installed the version for Xorg 7.1
<ogra> seb128, ati is fine here
<ogra> fglrx isnt though ...
<ogra> seb128, which version of xserver-xorg-video-ati do you have installed ? 
<desrt> holy crap it's tuesday!
<jono> ogra, 0.2 will have all kinds of cool stuff in there :)
<pitti> desrt: you don't like Tuesdays?
<desrt> i've a meeting today
<ogra> jono, do you target cubase ? ;)
<desrt> and i think i didn't go to work yesterday because i didn't realise it was monday
<jono> ogra, pretty much :)
<ogra> hehe, cool !
<ogra> thats long awaited :)
<seb128_> k
<ogra> seb128_, xserver-xorg-video-ati works fine here
<seb128_> that was -driver-ati installed about -video-ati
<ogra> ah :)
<seb128_> s/about/instead of
<seb128_> something should conflict and force to upgrade
<seb128_> and no, I don't have ubuntu-desktop :p
<ogra> i thought they conflict ...
<desrt> score.  the xen stuff finally hit the wall.
<ogra> i know it was replaced automatically here ...
<ogra> but then i have edubuntu-desktop installed  :)
<desrt> let the testing begin...
<geser> video-ati conflicts driver-ati but you need to install it manually or through a meta-package
<seb128_> that's what I complain about :p
<seb128_> xserver-xorg should Breaks or Conflicts with the -driver-*
<ogra> hmm ...
<geser> it's xserver-xorg-driver-all
<geser> and xserver-xorg depends on  xserver-xorg-video-all | xserver-xorg-video
<ogra> well, the xorg metapackage should care for everything ... 
<ogra> seb128, do you have that ?
<seb128_> ogra: no
<doko> infinity, cprov: new pkg-create-dbgsym is in the archive, please requeue  openoffice.org 2.0.3-4ubuntu2 on powerpc, sparc, i386 (wondering why it did succeed on amd64 ...)
<cprov> doko: done
<cprov> and it also breaks the UI :(
<doko> pitti: ^^^ if the build fails, I'll phone you when the build finishes ... at 3am ;-P
<doko> cprov: the OOo UI?
<pitti> doko: right, thanks for reminding me to pull the telephone cable
* pitti hugs doko
<cprov> doko: the soyuz UI 
<doko> :)
<rodarvus> seb128, ati should be fixed by now
<rodarvus> the last (known) bug was nailed by mdz last night
<seb128> rodarvus: I had driver-ati installed instead of video-ati and nothing complained
<rodarvus> (the driver itself was uploaded for 7.1 a few days ago)
<rodarvus> oh
<seb128> I had to apt-get install video-ati
<rodarvus> seb128, you just have to update xorg (actually xserver-xorg-video-all)
<rodarvus> it will automatically update your drivers
<seb128> right
<rodarvus> seb128, this change was finally commited last Thursday, I think
<seb128> but I don't have video-all and I don't want it
<seb128> I don't want a zillion of drivers I don't use
<doko> seb128: what is the status of the gnome libs for dapper-updates?
<rodarvus> (so, before, it was common for people to still use xserver-xorg-driver-*)
<rodarvus> seb128, no problem, the requirements are xserver-xorg-video-all | xserver-xorg-video
<rodarvus> the second is provided by -video-ati (and all other video drivers)
<seb128> doko: we have done most of GNOME 2.14.3 but still not GTK, it's on my list for this afternoon
<seb128> rodarvus: not sure of what is required but the server should conflict with -driver-* or something
<doko> ok
<seb128> at the moment you can be in a situation with everything to 7.1
<seb128> but ati driver still to 7.0
<ogra> not if you have the xorg metapackage installed
<rodarvus> that should be addressed, strange.
<rodarvus> seb128, do you have 'xorg' installed?
<seb128> ogra: I don't, again
<seb128> rodarvus: no
<ogra> seb128, but why ? 
<rodarvus> why?
<rodarvus> :)
<seb128> dunno
<seb128> because it works without it?
<seb128> and I don't feel the need to go and install packages I don't have when everything works fine?
<seb128> I've upgraded that box since hoary or something like that
<seb128> dunno if it was installed or when it got removed
<rodarvus> seb128, it is a metapackage (as I'm sure you know), so you risk missing updates, if you don't have it installed
<seb128> but until my dist-upgrade this week that was working fine
<rodarvus> it was probably uninstalled automatically, when you first updated to Edgy
<seb128> right
<rodarvus> (in the first week fonts were quite broken, and triggered an uninstall of xorg)
<seb128> my point is that something else should have the Conflicts then
<seb128> obviously it's possible to be in a broken situation, my desktop was in that case
<seb128> and that should not be possible :p
<rodarvus> seb128, xorg-server 1:1.1.1-0ubuntu4 (which will be uploaded in a few hours) will have something like this
<ogra> well, i guess it was never instaled because he has no -desktop package istalled (which would have changed deps from x-window-system-core to xorg)
<seb128> maybe the server should Conflicts and not xorg
<rodarvus> actually, Breaks: <all old drivers>
<doko> Kamion, infinity: please approve openoffice.org-amd64 2.0.3-4dapper1 for dapper-proposed
<seb128> rodarvus: ok, that was what I was asking for, thank you ;)
<infinity> doko: Will do.
<rodarvus> seb128, no thank YOU :)
<infinity> doko: On both counts.
<Hobbsee> doko: Kamion has the day off today.
<doko> infinity: which counts?
<infinity> doko: Err, give-backs, and ooo-amd64 approvals.
<doko> infinity: give-backs already done by cprov
<infinity> doko: I see that.
<infinity> doko: Well, I see that on all but powerpc, which I've just remedied.
<wasabi> Yeah. Must be evms. I have two device nodes that return the same vol_id
* infinity frowns at the 500+ langpacks in queue/unapproved, and decides that 30 minutes to midnight isn't the time to care about them.
<infinity> pitti: Kamion requested those langpack updates from you, right?
<fruwak> !topic
<infinity> fruwak: I think you meant /topic
<infinity> fruwak: There are no bots in this channel.
<fruwak> yes thx :D
<pitti> infinity: right
<fruwak> i fixed that :D
<infinity> pitti: Okay, then I'll just leave them for him to deal with when he gets back. :P
<fruwak> im no bot :D i can be robot :D
<pitti> infinity: I'll bother him about NEWing and such tomorrow
<pitti> infinity: that should be fine
<bddebian> Heya
<Fjodor_> BenC: Is there something wrong in the latest edgy kernel wrt sata or xfs? I noticed it took a long time rm -rf'ing a kernel build dir, and timed it 2 2m46s. Copying it over took 10 minutes(!). That's way too long, and longer than I ever saw on 5.14 or earlier
<Fjodor_> Brb
<ogra> 5.14 ? that would be 6.02 then ?
<ogra> :)
<Hobbsee> ogra: and who did a secret release of 6.02 anyway?
<zul> it was me..sorry...its my deriative
<gnomefreak> looks like they need a say off
<gnomefreak> s/say/day
<Hobbsee> zul: heh
<ogra> zul, xenubuntu prerelease ?
<zul> ogra: eventaully yeah :)
<ogra> :)
<zul> its apart of the plan for world domination
<giftnudel> 1. release in 5.14 2. ????? 3. prof... eh world domination?
<Hobbsee> zul: but i was going to take over the world!  that's my job!
<zul> Hobbsee: you have to wait in line..
<Hobbsee> zul: we cant have two people taking over the world!
* Hobbsee sidesteps in front of zul, and crosses her arms.
<zul> narf
<giftnudel> you can split at the equator
<Hobbsee> as long as i get the northern half :P
<zul> yeah i dont want australia...its full of dingos
<Hobbsee> heh
* Hobbsee rarely sees dingos.
<ogra> they dont show up on the internet ;)
<infinity> I've never seen a dingo outside of a zoo...
<Hobbsee> ogra: hehe
<ogra> you have to go *outside*, you know 
* Hobbsee throws a dingo at ogra.  you sure?
<Hobbsee> ogra: outside?  what's that?
<thom> infinity: you've been outside?!?
<infinity> thom: About 3 times since I took this job, yes. :P
* ogra catches the dingo ... (i always wanted one)
<Hobbsee> hehehe
<Hobbsee> infinity: wow, which were they?  going to and from conferences?
<ogra> infinity, you mean while driving to the airport ?
<infinity> Yeah, pretty much.
<Hobbsee> that must mean that you're still at a conference.   must be pretty quiet there now.
<zul> isnt it the koala that gets stoned off eucalpytus?
<Hobbsee> if you never actually left the second conference.
<Hobbsee> ah crap!
* Hobbsee notes that her leg is NOT supposed to collapse under her, making her fall onto the floor.
<ogra> zul, yes they drop on you ...
<ogra> zul, but you can prevent that by sticking forks in your hat a heard ;)
<Hobbsee> ogra: you're confusing the koalas and the dropbears.  the koalas go across busy roads.
<ogra> s/a/i/
<ogra> Hobbsee, ah, right ...
<zul> ogra: or a large spike a la kriaser willem?
<Hobbsee> ogra: so do the echidnas, for that matter.
* Hobbsee has had to stop because an echidna was crossing the road before, actually.
<zul> heh...we have canadian geese crossing the road
<ogra> zul, could wor as well :)
<Hobbsee> oh yeah, forgot the ducks wandering around on the street too - and they do not move for cards!
<Hobbsee> s/cards/cars
<giftnudel> they probably won't move if you give them cards either
<Hobbsee> hehe, yeah
* Hobbsee sends giftnudel to go fix bugs.
<zul> Hobbsee: canadian geese has a tendency to get upset and attack me
<Hobbsee> zul: ahhh...nasty
<ogra> zul, you really shouldnt go out in that gander costume ;)
<zul> ogra: i try not to
<bddebian> Is hamlib stuck in NEW?
<bddebian> Oh, NM, I can check myself sorry
<bddebian> Yep, sure is.
<heno> seb128: are you importing gnome-orca as part of the normal gnome 2.16 imports or should I do a separate main inclusion report? 
<heno> seb128: it will be the default screen reader for gnome 2.16 AFAIU, but other people like FC6 are not going to use it yet
<seb128> heno: better to ask pitti if it needs one
<heno> (we would like to though)
<heno> ok, pitti ^ ?
<bddebian> Whomever is working on syncs, THANK YOU :-)
<seb128> heno: I'm fine with using for edgy, dholbach might have better idea on it though, he's packaging the a11y stack usually
<HiddenWolf> seb128, what's the relation between orca and the simple-onscreen-keyboard soc?
<heno> HiddenWolf: nothing
<seb128> no idea, I use or know neither of those
<heno> separate things completely
<heno> both are cutting edge assistive technology
<heno> :)
<heno> Orca will be the default reader for gnome 2.16 and we are working to make SOK default by 2.18
<heno> replacing GOK
<dholbach> heno: i updated it every time there was a new release and i'll subscribe the accessibility team to the bugs of it
<heno> dholbach: do we need to do anything special to get it into main and onto the CD? (I'm familiar with the main inclusion report and seed change request, but I was wondering if there is more automation to it when it is a default part of gnome?)
<heno> If not, I'm happy to just follow the normal steps for inclusion
<dholbach> heno: maininclusionreport, then seed change
<dholbach> heno: what automation are you thinking of?
<heno> dholbach: I didn't know if the standard gnome desktop got accepted as a whole unit or not
<heno> I guess not
<heno> i'll follow the normal steps, thx
<dholbach> heno: that was historical - all new components since warty (or hoary or something) went through that process
<heno> ok, cool
* bddebian hugs dholbach "just because"
* dholbach hugs bddebian back
<janimo> heno, hi xubuntu-at-mag and xubuntu-at-speak are in NEW now
<heno> janimo: cool! What do they use? Gnopernicus/Orca? gnome-mag, gnome-speech?
<janimo> heno, the packages you listed in the wiki :)
* heno looks it up :)
<janimo> just added them to the depends field
<janimo> orca, espeak, speech-dispatcher, gnome-mag
<janimo> and orca, yes
<heno> looks good
<janimo> I did not upload one for the keyboards as the package is not yet in the archive
<heno> right, we'll get that in soon
<heno> janimo: thanks!
<janimo> heno, np :)
<Amaranth> pitti: i've got an initscript in /etc/dbus-1/event.d/, my /etc/dbus-1/system.d/willowng.conf is almost identical to the one you have for hal, but i can't seem to get mine to own it's dbus interface. it does if i run as root or if i su into the willowng user but when it starts as root, drops to willowng user, then tries it fails. any ideas?
<ogra> pitti, willowng is Amaranths SoC project he does for us
<pitti> sorry, was at the phone
<pitti> re (sorry, was at the phone)
<Amaranth> that reminds me, what does 're' mean?
<azeem> "I am back"
<ogra> returned ?
<Amaranth> ah
<Amaranth> people leave for bed, come back in the morning, and say that so i didn't think it was that
<Amaranth> http://rafb.net/paste/results/7rs4ts10.html is my dbus conf file
<iwj> Hmm, my X is still completely hosed in edgy.  Should I report it as a bug ?
<bddebian> OK, gtkgl2 in Debian still has two .la files, do I need to strip those out?
<seb128> bddebian: don't create a diff only for that
<cypher1> i am trying to understand the files under /proc/acpi/battery/*.. has anyone has any URLs ?
<BenC> is there an installer option to keep it from automatically running each next step of the install process?
<BenC> IOW, let me select things manually
<bddebian> seb128: OK, just sync it?
<seb128> bddebian: I've not looked to the package, but if there is no Ubuntu change we need to create a diff just to drop them, ask a sync rather
<bddebian> OK, thanks
<Riddell> Kamion: could you move some packages to main?
<Riddell> http://kubuntu.org/~jriddell/tmp/main
<mdke> Riddell: he mentioned earlier that he is off work today
<mdke> (just fyi, in case you didn't know that already)
<Riddell> mdke: I didn't, thanks
<Riddell> maybe mdz is awake instead?
<infinity> Riddell: Are all those source packages in main?
<infinity> Riddell: If not, are there MIR for each one?
<Riddell> infinity: none are in main, they all have successful main inclusion reports
<janimo> infinity: are edgy CD builds off until dapper.1 is out ?
<pitti> Riddell: did you get my mail wrt. hal re-sanitizing?
<infinity> janimo: Not sure, you'd have to ask Kamion when he gets back.  I'm not touching the cdimage host without his approval while he's working on dapper.1
<Riddell> pitti: yes, sorry should have got back to you on that
<pitti> Riddell: if you cannot revert to the pmount behavior and depend on these scripts, I need to schedule some time to make them safe
<janimo> infinity: ok. I just saw no dailies today to check wether xubuntu is still oversized
<pitti> Riddell: but I'm not aware of the KDE situation, a short briefing would be appreciated
<Riddell> pitti: it's a new need in KDE 3.5.4, I don't know how easy it would be to remove, I suspect not very
<wasabi_> Heh nice.
<wasabi_> Everybody updated initramfs to use UUIDs, but nobody fixed local-top/evms at all.
<Riddell> pitti: I need to check which scripts it needs exactly, it doesn't need the eject one for example
<pitti> Riddell: how did KDE mount removable stuff before?
<infinity> Riddell: Grr, the page title should be MainInclusionReportPackage not MainInclusionReviewPackage... You completely messed up my wiki searching mojo. :)
<Riddell> pitti: pmount
<pitti> Riddell: i. e. before hal offered the mount API through the scripts you added?
<Riddell> infinity: humble appologies
<infinity> MartinPitt: needs soname fix or library package renaming to match soname, ok otherwise
<pitti> Riddell: pmount through a kioslave or something like ivman?
<infinity> Riddell: Are we doing something about that?
<pitti> wasn't that fixed?
<infinity> Well, if it was, the MIR page wasn't updated.
<Riddell> infinity: that's been fixed
<infinity> Ahh, the binary is libpth20, so I suppose it was fixed.
<infinity> Riddell: Excellent.  Will promote nowish.
<Riddell> infinity: I updated the UbuntuMainInclusionQueue page but I'll mind and update the actual report page in future
<Riddell> thanks infinity 
<Riddell> pitti: I'll need to wait until the KDE HAL dude is around to ask him how easy it would be to revert back to using just pmount, the pmount code seems to still be there from a grep
<pitti> Riddell: gnome-volume-manager looks for gnome-mount (which uses hal) and falls back to pmount-hal if it's not found
<infinity> Riddell: All done.  Should make this publisher run, so should be visible in ~40 mins.
<ogra> iwj, run mkfontdir in the misc directory
<iwj> ogra: I don't need the X to work, so I can leave the install hosed for the moment :-).
<iwj> Until a proper fix is released at which point I can verify whether it's fixeds.
<iwj> s/xeds/xed/
<iwj> This also makes it easier to reproduce at least one of my other two bugs, too.
<ogra> iwj, yup, then wait for rodarvus to return i told it to him when he was done with the X 7.0 sync ... but he said it would be fixed in 7.1 anyway
<iwj> Sure.  (FYI, the others are bug 54812 and bug 54813.)
<Ubugtu> Malone bug 54812 in xserver-xorg "X server garbled display" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54812
<Ubugtu> Malone bug 54813 in xserver-xorg "X server failure dialogue garbled (UTF-8 problem)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54813
<ogra> i think 54813 exists since breezy
<ogra> daniels never really cared and whe he left there were bigger probs than frames around error dialogs :)
<BenC> Kamion: ping
<dholbach> BenC: he's out for today.
<BenC> dholbach: thanks
<iwj> ogra: Sure.  But I thought if I was going to report two bugs based on the same set of facts I might as well throw in the third as it was hardly any effort :-).
<ogra> hehe
<ogra> i'm sure rodarvus will fix tem once he's done with 7.1 packaging
<ogra> *them
<bluefoxicy> iwj:  I'm not worried about your kernel working properly; I'm worried about the future situation where it may be possible to ship straight Xen kernels, especially if Linus takes Xen in mainline
<zul> bluefoxicy: when it comes to that we will include it in ubuntu-kernel
<bluefoxicy> zul:  nods.  Which means all kernels will be able to run native, Xen dom0, or Xen domU  :)
<zul> well native and dom0 now
<bluefoxicy> I thought dom0 kernels could also run domU
<zul> they can,we dont ship domU kernels
<bluefoxicy> :>
<Treenaks> pitti: Cups doesn't seem to detect the default paper size on printers it finds automatically (by 'browsing'); is that a bug in cups or in gnome-cups-manager?
<iwj> bluefoxicy: Yes, that's what we would like to do, of course.  But atm there is big politics with Xen and mainline kernels :-/.
<bluefoxicy> iwj:  as much as I hate to say it, Arjan will probably get it in mainline if anything.  That guy can talk Linus into putting just about anything in there.
<iwj> Well, it would be nice.  Last I saw (a few months ago) Linus was still telling the Xen guys and the vmware guys to come back when they could agree on a single interface, which seemed doomed and stupid to me.
<zul> Name                              ID Mem(MiB) VCPUs State  Time(s)
<zul> Domain-0                           0      362     1 r-----  2749.0
<zul> ramdisk                            7       64     1 -b----     9.6
<zul> oops...sorry..
<bluefoxicy> iwj:  they do not even work the same way, that's retarded.
<bluefoxicy> That kind of thing should go to vmware/kqemu, not vmware/xen
<iwj> vmware want to do paravirt stuff too apparently.
<zul> ahem...http://70.29.57.2/ubuntu/Screenshot.png
<Lathiat> I have to excuse myself from the avahi/tb discussion this morning unfortunately, hopefully somebody else knowledgable will be there.
<ogra> oh, there is a tb meeting today, right ... and Hobbsee going for main ! 
<LaserJock> doko: ping?
<Zdra_> I have a question to developers: how do you do to test patch in a lib (like gnomevfs) ? Apply the patch in the package's source, build it and then install it ? or apply the patch in upstream source and compile it with prefix=/usr ?
<LaserJock> Zdra_: I would guess mostly in the source package, but it would probably depend on the situation
<Zdra_> LaserJock: so you rebuild the package and install it with dpkg -i ?
<LaserJock> yeah
<LaserJock> for me, I have to reproduce as nearly as I can what the user is going to see
<LaserJock> and that means rebuilding the source, .deb, and installing, etc.
<Zdra_> the problem I have with this solution is when I build the package ubuntu's patch are applied and I don't know how to reverse them so if I rebuild the package again it make errors
<Zdra_> I guess there is some debian doc to explain how to clean up the source code before build it
<Zdra_> and another problem: It compile the whole package everytime I change one line...
<LaserJock> Zdra_: why don't you hop on over to #ubuntu-motu
<Zdra_> didn't know that's the right chan to discuss that kind of things, thanks.
<gabaug> I want to create a bzr branch for f-spot that can be committed to by other f-spot devs...do I need to create a f-spot team to do that?
<tseng> hi gabaug 
<gabaug> hi tseng
<tseng> there is a #bzr
<gabaug> thanks
<tseng> that might have more relevant people, not sure
<tseng> not sure if it falls into bzr or launchpad team
<tseng> #launchpad or #bzr knows best.
<janimo> Gloubiboulga: hi, did not forget :)
<Gloubiboulga> hi janimo, ok, I haven't checked if you were online :)
<bluefoxicy> hi tseng
<Gloubiboulga> janimo, someone on #xubuntu told us he's writing a gui to add/remove printers for xubuntu
<janimo> ivoks or someone else?
<Gloubiboulga> someone else
<janimo> since he is working on a pygtk configurator
<janimo> and I am just looking a gnome-cups-manager right now
<Gloubiboulga> ok, he'll probably mail the xubuntu list
<Gloubiboulga> janimo, val314159 is our man :)
<val314159> hello
<janimo> val314159: hello
<ogra> rodarvus, btw, any idea about bug 54809 ? seems it still looks in the wrong dir
<Ubugtu> Malone bug 54809 in xserver-xorg "X server cannot find default font `fixed'" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54809
<val314159> im finshing up a pygtk add/remove printer add for xubuntu
<janimo> val314159: nice, please post to the list when ready for testing :)
<janimo> val314159: btw someone else is doing the same thing for ubuntu, not sure if edgy is the target though
<val314159> oh, man, and i thought i was all unique
<janimo> anyway with so many options I hope we'll get print config one way or another in xubuntu
<rodarvus> ogra, I supposed this was due to you and iwj having used a broken version of xfonts-utils
<janimo> val314159: there's much demand for such an app you cannot be unique ;)
<ogra> rodarvus, iwj updatesd today 
<ogra> so it was the most recent binary
<rodarvus> right, indeed
<janimo> val314159: don't let that discourage you, but try to see if you guys can cooperate (the other's nick is ivoks)
<rodarvus> ogra, I'll have a look at it today, thanks!
<ogra> rodarvus, there should also be a versioned dependency on xfont-utils
<ogra> so that this cant happen with 7.x
<rodarvus> you mean of xorg on xfonts-utils?
<val314159> ok, got it.  time to upload
<ogra> rodarvus, yep
<rodarvus> ogra, yes, good sugestion - I'll do it
<rodarvus> thanks again :)
* rodarvus takes notes
<Commander-Crowe> oh wow
<Commander-Crowe> so what are you guys developing?
<ogra> SuSE linux 11.1 
<HiddenWolf> ogra lmao
<zul> world domination
<ogra> Commander-Crowe, no in fact we're developing the OS of the future :)
<Commander-Crowe> lol
<Commander-Crowe> 11.1?
<Commander-Crowe> have 11 come out yet?
<Commander-Crowe> has 10.2 come out yet?
<HiddenWolf> Commander-Crowe, ubuntu.com
<ogra> and as you might guess from the channel name thats not SuSE
<Commander-Crowe> yeah
<ogra> :)
<Commander-Crowe> I was gonna do crowe linux
<Commander-Crowe> all it was gonna be was a load of drivers
<Commander-Crowe> compatible with eveything out there
<tritium> !enter > Commander-Crowe 
<tritium> oops, sorry, wrong channel :)
<bddebian> Heya tritium
<tritium> hi bddebian 
<val314159> ok, i uploaded garp (gtk add/remove printer)
<janimo> val314159: if you want testers you could mail the xubuntu-list
<Commander-Crowe> garp?
<val314159> d'oh!  i just mailed xubuntu-devel
<Commander-Crowe> for printing?
<janimo> val314159: ok :)
<val314159> the world according to your printer?
<Commander-Crowe> so the next version of UBuntu is 6.10?
<Commander-Crowe> when does it come out/
<ogra> 06/10 indeed ;)
<janimo> val314159: it should be more than just a gtk wrapper around lpadmin :)
<janimo> should do at least as much as gnome-cups-manager does not
<janimo> s/not/now/
<val314159> :hms
<janimo> there's a redhat printer config tool written in python, pretty complex, and cannot easily be adapted to ubuntu, hence someone is writing one from scratch
<val314159> i guess i misunderstod the problem.  i thought it was just to get printers going on xubuntu without grabbing all of gnome
<janimo> val314159: yes, that is the goal. But I am sure it cannot be done by just using lpadmin
<val314159> i used lpinfo and lpstat too (:
<janimo> val314159: well, if those can do what can otherwise be done by using cups libraries, great.
<val314159> so, it could be a wrapper, it just needs more functionality?
<val314159> altho python bindings would be much sweeter
<janimo> val314159: if it does all that gnome-cups-manager does it's enough
<janimo> so detect/add/remove local and networked printers at least
<val314159> ok, im instaling gnome-cups-manager to see what i'm missing
<LaserJock> mdz: ping?
<val314159> it looks like my script does the same thing, but thier interface is way nicer
<val314159> except they have a way to turn on network printer detect
<crimsun> janimo: RE: gxine, I'll work with Darren on stripping out the js dependency.
<janimo> crimsun: great, thanks
<zul> ill apply the patch
<zul> doh..
<desrt> there is no dana.  only zul.
<zul> hey desrt 
<desrt> 'sup
<zul> not much you?
<desrt> i see your packages landed in edgy.
<zul> yep doing another one tonight
<desrt> l33t.
<desrt> i got edgy on my laptop
<desrt> it's only got 1gig, so probably not the ideal test machine
<zul> better than mine
<desrt> i may edgify my desktop tonight -- it's a bit beefier
<tseng> desrt: please do
<tseng> desrt: then you can fix muine
<desrt> did you take dbus out?
<tseng> no
<desrt> good.
<tseng> I tried a few things regarding vfs
<desrt> i'd have had to fuck you up
<desrt> i can always fix muine on my laptop
<desrt> what is the problem?
<tseng> it segfaults on startup
<desrt> did you upload that?
<tseng> specifically starting the dbus service
<tseng> upload what?
<desrt> the segfaulting muine :)
<tseng> no
<tseng> i uploaded a working muine
<seb128> desrt: hi
<tseng> gnome 2.15 upgrade hosed it.
<desrt> is it just the old package linked against new dbus starts failing?
<desrt> ah :(
<desrt> seb128; hey.
<desrt> seb128; what's up?
<tseng> rebuild is obviously no help
<desrt> tseng; maybe not true
<tseng> we can talk about it later, other things ive already tried
<seb128> desrt: https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/54261 is no go
<Ubugtu> Malone bug 54261 in gtk+2.0 "every single gtk app wakes up on button or modifier key press" [Medium,Fix committed]  
<tseng> desrt: well, I've tried it
<desrt> seb128; ah.  why?
<tseng> so its true in my experience
<desrt> tseng; k.  was thinking maybe ABI break without corresponding API break
<seb128> desrt: GTK 2.8.20 has no mention of XkbSelectEventDetails function to its source code
<desrt> eh
<desrt> that doesn't sound right
<seb128> and I don't know about the issue to know if it applies at all to 2.8
<desrt> goddamn why don't we have a dbus-sharp?
<crimsun> meaning libdbus-1-cil?
<desrt> seriously.
<Zdra_> seb128: I think you should consider including this upstream patch to ubuntu's package: http://bugzilla.gnome.org/show_bug.cgi?id=340938 --> still not commited to gnome-2-14 branch but is in head. May be useful before dapper point release. (sorry if you are already aware of this bug)
<seb128> desrt: http://cvs.gnome.org/viewcvs/gtk%2B/gdk/x11/gdkdisplay-x11.c?rev=1.60&only_with_tag=gtk-2-8&view=markup
<seb128> desrt: it has a 
<seb128>             XkbSelectEvents (display_x11->xdisplay,
<seb128>                              XkbUseCoreKbd,
<seb128>                              XkbNewKeyboardNotifyMask | XkbMapNotifyMask | XkbStateNotifyMask,
<seb128>                              XkbNewKeyboardNotifyMask | XkbMapNotifyMask | XkbStateNotifyMask);
<seb128> desrt: do you know if that's the part that need to be changed and how?
<desrt> ya.  that's what i see now.
<desrt> that's almost definitely the part that needs to change
<desrt> look how they both come before the XkbSetDetectableAutoRepeat
<seb128> Zdra_: from the bug you pointed, click on the ubuntu bug pointed, you will notice it has been fixed before dapper :)
<desrt> seb128; i bet you could replace the XkbSelectEvents with the new XkbSelectEventDetails outright with no ill effects
<desrt> seb128; but i'd ask mclasen
<Zdra_> seb128: oops, sorry !
<seb128> desrt: thank you, I've no real knowledge of xkb code and I don't want to break GTK to dapper ;)
<seb128> Zdra_: no need to be sorry, thank you for pointing things you think that should be fixed ;)
<desrt> seb128; ask matthias to be really sure :)
<seb128> desrt: will do
<desrt> tseng; eat me.  you broke my muine.
<tseng> desrt: no
<tseng> desrt: seb did
<desrt> no.  seb didn't.
<desrt> i didn't _realise_ that it was broken until you asked me to start it
<tseng> sigh.
<tseng> I told you it was broken the other day
<tseng> fair warning
<desrt> muine uses libdbus-1-cil
<seb128> what broke it?
<desrt> so the bug is probably that the dbus library abi changed in such a way that libdbus-1-cil doesn't quite fit anymore
<tseng> seb128: iain took a 2.14 gnome system
<tseng> upgraded just gnomevfs to 2.15
<tseng> this started the breakage there
<tseng> now, muine 0.8.3 works
<seb128> ABI breakage on gnome-vfs? not good
<tseng> and removing the gnomevfs related diff doesnt fix it
<desrt> gnomevfs 2.15 would probably pull in a new dbus?
<tseng> desrt: yes.
<desrt> seb128; hah!
<tseng> but downgrading dbus doesnt fix it
<tseng> i am still fuzzy on the cause
<desrt> seb128; welcome to the world post-bug 348100
<tseng> i only have iains word to go by
<seb128> is mono likely to be confused by bonobo function being moved around?
<tseng> to point us at vfs
<tseng> seb128: very doubtful
<tseng> i dont know of any bonobo using mono apps
<tseng> unless gnomevfs-sharp is?
<desrt> i think you're wrong about gnome-vfs
<seb128> macOS is confused by it :p
<seb128> and it broke gnome-python too
<desrt> i _hope_ you're wrong about gnome-vfs
<tseng> desrt: I think I am too
<tseng> desrt: but iain didnt make up what he saw
<tseng> so its where I started
<tseng> if you have a better idea..
<tseng> I'll investigate it
<desrt> i'm testing some ideas out
<seb128> I'm not sure of how bindings react that functions move
<seb128> but the python ones were broken by it
<tseng> seb128: there are other things using dbus-sharp in a similar way
<tseng> they aren't dying
<desrt> oh.  there goes that idea
<desrt> >:|
<seb128> is the issue dbus-shard or gnomevfs-sharp?
<tseng> seb128: not sure
<tseng> the stacktrace clearly points to dbus
<desrt> i thought maybe libdbus-1-cil didn't get updated when dbus was upgraded
<tseng> iain says downgrading vfs is the fix
<desrt> i guess that's impossible
<tseng> desrt: yeah.
<seb128> k, so not likely to be the bonobo changes to gnomevfs then
<tseng> desrt: did you see that i said muine 0.8.3 works
<tseng> if you fix one tiny compiler bug
<desrt> dude
<desrt> downgrading gnome-vfs uninstalls half the system
<tseng> he was working from sources
<tseng> which is why i havent confirmed this
<desrt> including muine :)
<tseng> yes :)
<tseng> he had dapper and build gnomevfs from source
<tseng> i believe.
<tseng> then installed pkg back over top
<crimsun> this is off the current discussion, but are there plans to replace esound with pulseaudio in edgy? If so I should start fixing the alsa plugin bits.
<desrt> k
<desrt> crash occurs in pthread_mutex_lock
<tseng> (really?)
<tseng> gross
<desrt> gdb may be lying
<ogra> crimsun, i wanted to have it in ltsp at some point, but wasnt planning to work on it in edgy yet (rather +1)
<desrt> maybe new/old gnome-vfs uses/stops-using pthreads and this somehow ends up indirectly affecting dbus?
<tseng> that would be pretty sick
<tseng> latexer suggested initializing gnomevfs by hand
<tseng> which i put in the FileUtils singleton
<tseng> Init()
<tseng> this didnt help.
<desrt> heck
<desrt> maybe bonobo itself is responsible for the pthread thing
<tseng> I would think we would have noticed somewhere else
<crimsun> ogra: ok. Well, I'll start getting the bottom of the stack (from alsa side) ready in case you miraculously find time to poke it with a stick.
<tseng> i took the dllimport of gnomevfs out as well
<tseng> so its all through gnomevfs-sharp
<desrt> the dbus glib bindings use threads
* desrt starts instrumenting
<ogra> crimsun, it looks like pulse is/will be capable of remote mixer stuff and the like ... its very very intresting for ltsp
<janimo> seb128: gdm via gksu :)
<janimo> I mean gconf via gksu via gdm
<tseng> desrt: driving home, be back in 20
<seb128> janimo: ah, that's not from the gdm code but just because of the menu item, we could use a Recommends for it
<desrt> tseng; i won't be here, most probably
<desrt> tseng; cheers
<janimo> seb128: but still needed if you want to launch gdmsetup from the menu
<seb128> janimo: right
<seb128> you use gksu for xubuntu anyway, no?
<janimo> yes, so that;s why gconf is not an issue
<janimo> it is needed by too many thiings
<desrt> oh my
<desrt> dbus_gmutex_lock (0xabcdef)
<desrt> that doesn't look like a very likely address for a mutex.....
<desrt> hmmmm
<desrt> #define _DBUS_DUMMY_MUTEX ((DBusMutex*)0xABCDEF)
<desrt> tseng; this is for your benefit.  i hope you have a good scrollback :)
<desrt> tseng; problem appears to be that someone calls dbus_new_lock (or whatever) then initialises the thread functions then calls lock()
<desrt> tseng; lock(), if the thread functions are not initted, ignores its argument
<desrt> tseng; so 0xabcdef would be fine.   but if you use a pre-initialised lock value with a post-initialised lock then the lock function expects a legit value
<desrt> wow.  god really _does_ kill a kitten every time you output to stdout from a library
* desrt gets bitten
<desrt> tseng; k.  problem is thus:
<desrt> gnome-vfs calls dbus_g_thread_init ().  it didn't use to do this.
<desrt> on muine start, dbus-glib acquires a lock for itself (which is 0xabcdef because locking isn't initialised)
<desrt> then gnome-vfs calls dbus_g_thread_init(), switching the locking stuff on
<desrt> then when dbus-glib goes to use its lock shit explodes
<desrt> this is sort of a big not-easily-solveable problem
<viper550> I've noticed the acclomplishments you've made on Usplash
<viper550> hello?
<viper550> Is anyone here?
<Hobbsee> viper550: there's a tech board meeting on at the moment
<viper550> ubuntu-meeting? I'm there!
<tseng> desrt: wow
<tseng> desrt: good catch.
<pitti> hi keescook 
<keescook> hiya!  :)
<keescook> wasn't sure if you were still awake.  :)
<pitti> keescook: we have a meeting right now
<keescook> ah-ha, very cool.
<pitti> keescook: btw, you don't happen to have experience with avahi?
<pitti> keescook: this topic will be discussed in the current tech board meeting once the new members have been discussed
<keescook> not specifically with the codebase, but I've toyed very briefly with other mDNS implementations.
<keescook> I've been eyeing it from an "information leakage" angle.  :P
<keescook> what in particular about it was going to be of interest?
<geser> gnupg 1.4.5 (released today) contains two security fixes. should someone special be noticed about it?
<pitti> keescook: whether we can enable it by default or not mainly
<pitti> keescook: there was a huge thread on ubuntu-devel, maybe you can just take a look at https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019680.html
<keescook> pitti: Ah, yeah, to that I can't say, but my kneejerk without having looked through the codebase would be "no".  It's relatively young code.
<pitti> keescook: (but only if you are interested, of course)
<pitti> keescook: heh, mine too :)
<keescook> pitti: I'll take a read, but it probably won't be for a few hours.
<pitti> keescook: don't worry then
* keescook nods
<lucas> how can I get in touch with a powerpc buildd admin ?
<pitti> lucas: mail/ping infinity 
<lucas> ok, thks
<pitti> lucas: sure you want a buildd admin?
<pitti> s/^/are you/
<lucas> well, there's a very strange build failure on powerpc
<lucas> actually, two of them
<lucas> it's difficult to understand them without getting access on the system itself
<pitti> do you have the log URL?
<pitti> hm
<lucas> http://librarian.launchpad.net/3642591/buildlog_ubuntu-edgy-powerpc.revolution_0.5-3ubuntu1_FAILEDTOBUILD.txt.gz
<Hobbsee> pitti: sigh.  :P  they're into questions today, but i can understand why.
<pitti> lucas: if the chroot/buildd is broken, then you need infinity
<lucas> search for [BUG]  Segmentation fault
<lucas> ruby looks broken
<pitti> Hobbsee: well, once you are in ubuntu-core-dev, you can do a lot of trouble potentially :)
<Hobbsee> pitti: oh of course.  i really dont blame them.  most annoying that mdz didnt see the last logs though
<gnomefreak> Hobbsee: you are handling being hammered good ;)
<Hobbsee> gnomefreak: yeah, surprisingly.  i'm still mostly asleep
<gnomefreak> its what like 4am there?
<Hobbsee> gnomefreak: meeting started at 6
<Hobbsee> it's 7.40am now
<gnomefreak> damn thats still early
<Hobbsee> gnomefreak: yeah, and i'm not a morning person
<pitti> Hobbsee: I think creating a  'sponsoring team' and filing bugs with this team in CC should work
<pitti> Hobbsee: and with a little script it should be as easy as 'request_sponsor foo.debdiff'
<Hobbsee> pitti: yeah, if it got done.
<crimsun> pitti: I'm happy to be on said sponsoring team as need be.
<pitti> Hobbsee: yep, I will do some python fu tomorrow
#ubuntu-devel 2006-08-02
<Hobbsee> pitti: cool
<dholbach> good night guys
<Hobbsee> night dholbach 
<Hobbsee> Keybuk: w.r.t. email, it is possible, if the person actually sees it. and its' easier to keep track of pacakages if you're only uploading a few at a time.
<Hobbsee> Keybuk: not trying to keep track of many.
<gnomefreak> night dholbach 
<gnomefreak> Hobbsee: i will help out as much as i can with kubuntu (just let me know)
<Hobbsee> gnomefreak: your bugwork stuff is great :)
<Hobbsee> means i dont have to do it
<gnomefreak> ;)
<gnomefreak> Hobbsee: i have a few you can take if you want them (me and backtraces are not friends today)
<Hobbsee> gnomefreak: eh. me neither.
* gnomefreak really needs to figure out a workaround with ff in kde
<gnomefreak> and thunderbird
<Riddell> gnomefreak: workaround?
<gnomefreak> fonts 
<gnomefreak> it only shows first few letters of a row
<lucas> I've a package which just needs a rebuild because of an ABI change. should I mail infinity ? upload a -XXXbuild1 package ? file a bug ?
<Hobbsee> *shit*
* Hobbsee is now really really late!
<gnomefreak> for some reason i can only duplicate it in mozilla engines
<tritium> get your butt to class, Hobbsee ;)
* gnomefreak doesnt code hence the workaround comment
<Hobbsee> heh
* Hobbsee wonders what class is even on.
<gnomefreak> math
<gnomefreak> lol
<gnomefreak> ok brb let me boot kde and see if i cant find out more info on this before bed
<Keybuk> pitti: got a brief question about dhclient, if you have a few moments
<pitti> Keybuk: as long as it's not too difficult, sure :)
<Keybuk> the dhclient hooks are run as root, even though the daemon is de-rooted to run as dhcp, yes?
<pitti> right, they have to
<Keybuk> and there's an apparent, but unconfirmed/debugged bug where sometimes this doesn't happen?
<pitti> Keybuk: yep, ISTR reading about some 'permission denied' bug
<pitti> Keybuk: most of them were killed with a fix in dapper
<pitti> Keybuk: but it's entirely possible that some corner case is still present
<Keybuk> okies
<Keybuk> then dhcdbd doesn't need permission for the dhcp user to talk to it
<pitti> 'it' being the daemon or the script?
<LaserJock> mdz: I think perhaps doko uploaded a broken matplolib to -updates universe, is it better to leave it for him or upload a fixed package?
<Keybuk> pitti: dhcdbd dcaemon
<pitti> ah
<pitti> Keybuk: no, I do not see a reason why dhclient should talk to dhcdbd
<gnomefreak> LaserJock: someone in #ubuntu is asking about that package
<LaserJock> gnomefreak: oh really?
<gnomefreak> yeah
<gnomefreak> tell him its being worked on?
<Riddell> is there a vari
<Riddell> is there a variable with the name of the source package I can use in debian/rules?
<doko> Laser_away: don't ping and start talking about the topic 4h later ... :-( if you do have a fix for a problem, please file a bug report (if there isn't one already) and attach a patch
<LaserJock> doko: sorry
<LaserJock> doko: debdiff at malone bug #54821, thanks
<Ubugtu> Malone bug 54821 in matplotlib "python-matplotlib won't install" [Untriaged,Confirmed]  http://launchpad.net/bugs/54821
<Riddell> infinity: libassuan-dev doesn't seem to have been moved to main
<Riddell> although the source package has
<Keybuk> Riddell: doesn't look as though anyone has explicitly promoted it
<Keybuk> the source is probably "wrong"
<Keybuk> fixed
<gnomefreak> did anything take the place of pd-externals?
<TheMuso> gnomefreak: No.
<bddebian> Howdy
<TheMuso> gnomefreak: Did you read the bug?
<floam> is openoffice all borken for anyone else?
<floam> (I've got some dependency hell going on in edgy)
<gnomefreak> TheMuso: yes and i would like to close it
<gnomefreak> TheMuso: thats why im asking
<TheMuso> Right.
<gnomefreak> floam: it will be fixed soon
<gnomefreak> soon = not today give it a few days
<floam> gnomefreak: I don't mind it being broke, I just worry when I think I could be the only one
<gnomefreak> floam: everyone had it broke you have to remove every OOo package and reinstall openoffice.org (iirc)
<gnomefreak> TheMuso: i went ahead and closed it due to you gave him all info he wanted (i miss read the last line about the CVS)
<TheMuso> Ok.
<floam> gnomefreak: ah removing it all at the same time did seem to cure it
<bddebian> Thanks Keybuk
<Keybuk> :)
<Keybuk> you can tell I'm avoiding work
<bddebian> I can?
* Keybuk finishes doing a little anastacia tidying
<Keybuk> that's the best thing about being on the ubuntu-archive team; you have hours of entirely legitimate work that can be done instead of whatever it was you were supposed to be doing and are procrastinating about
<zul> oh hey Keybuk 
<bddebian> Ah, I see.  And here I was feeling bad about all the sync requests
<Keybuk> bddebian: *shrug* provided they're in alphabetical order, I don't mind ;)
<bddebian> Heh
<Keybuk> (makes it easier to cut and paste the output into the bug report)
<zul> Keybuk: xen adds a udev rule is it ok to call it 92-xen-backend.rules?
<crimsun> I'd choose 95- if it loads modules.
<bluefoxicy> has anyone figured out who's mess the double-swap thing is or what happens if you enter that second swap device?
<Keybuk> zul: what does the rule do?
<zul> it loads the bridges needed for networking and the block devices needed
<Keybuk> bluefoxicy: "double swap thing" ?
<Keybuk> zul: loads modules?  then 95
<bluefoxicy> Keybuk:  swapon -a
<bluefoxicy> Keybuk:  err, sorry.  swapon -s
<zul> Keybuk: ok
<Keybuk> bluefoxicy: ?
<Keybuk> bluefoxicy: bug#?
<bluefoxicy> Keybuk:  whatever your swap device is, i'ts /dev/<whatever> and /dev/evms/<whatever> that get loaded now due to the UUID thing in fstab bug #54753
<Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Confirmed]  http://launchpad.net/bugs/54753
<Keybuk> bluefoxicy: oh yeah
<Hobbsee> bluefoxicy: what was the fix for that?  or just wait?
<Hobbsee> hey Keybuk 
<Keybuk> evms is the sux0r
<bluefoxicy> Keybuk:  as far as I know, nobody has yet been brave enough to get Linux to start writing into the second swap device; I would imagine it'd be about the computer equivalent of sliding a lit M80 up your rectum
<Keybuk> bluefoxicy: with or without lubricant?
<zul> mmm...bottom
* jdub wonders if bug #1 is special cased in launchpad ;)
<Ubugtu> Malone bug 1 in ubuntu-desktop "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<bluefoxicy> Keybuk:  mmm... I don't think it makes much of a difference when the fuse burns down.
<zul> jdub: FYI http://70.29.57.2/ubuntu/xen.png
<Keybuk> bluefoxicy: it's obvious who broke it
<Keybuk> just not obvious who has the skillz to fix it
* bddebian gives Keybuk some more "non-work"
<bluefoxicy> Keybuk:  well, there are multiple theories over here.
<bluefoxicy> Keybuk:  1)  whoever converted fstab should have tested this first
<Keybuk> there are?  who?
<bluefoxicy> Keybuk: 2)  Removing evms fixes it, maybe this is a mount problem.
<tseng> sigh
<Keybuk> person who did the fstab conversion explicitly didn't test evms, lvm, raid, etc. and said as much
<bluefoxicy> Keybuk: 3)  the KERNEL should probably figure out that these are the same device and not let us doi t.
<jdub> zul: oh, btw, i booted the xen kernel this morning
<zul> and?
* bddebian pokes tseng
<Keybuk> because person who did the fstab conversion knows fuck all about them and doesn't care for them either
* tseng pokes bluefoxicy 
<tseng> er.. bddebian 
<Keybuk> #2 is true, evms is not installed in new edgy installs anyway
<bluefoxicy> Keybuk:  nods.  they were in Breezy or Dapper, so upgrades are likely to see this.
<jdub> zul: is there an ubuntu-xen channel to chat aobut it in? or ubuntu-kernel?
<Keybuk> but as you say, the upgrade path needs to cope here
<zul> ubuntu-kernel works
<Keybuk> this will probably be fixed at the dev summit
<Keybuk> when the person who cares about the fabbione filesystems can sit next to the person who did the uuid mounting
<zul> jdub: however i was just about to run to the store
<bddebian> Hey if I'm too useless to be a core-dev, can I at least get op in here? ;-)
<bluefoxicy> Keybuk:  yeah.  My thinking is somewhere along the line either mount or the kernel needs to say "uh uh no screw that" when you double-add a swap dev.
<Keybuk> bluefoxicy: *nods*  the migration needs to special-case evms and lvm I suspect
<Keybuk>                                   ^also
<jdub> zul: ok, ping me when you're around - i was about to grab lunch, too :)
<bluefoxicy> Hobbsee:  btw, uninstall evms (and reboot) or swapoff the second swap device (each time you boot), or both.  That'll get rid of it.
<Keybuk> we've got an open task to patch mount to use libvolume_id instead of libblkid
<Keybuk> no idea whether that fixes it or not
<Hobbsee> bluefoxicy: oh nice.   want to tell me why it's being installed on my system anyway?
<Keybuk> Hobbsee: was installed by default in dapper, no longer in edgy
<bluefoxicy> Hobbsee:  evms?  it was in breezy and/or dapper
<Hobbsee> Keybuk: ah good.  i dist-upgraded
<bluefoxicy> will somebody get itunes working in Ubuntu JESUS
<bluefoxicy> my mom is screaming about crap on windows again, I just want to stick Linux on there so she can go away ><
<Hobbsee> bluefoxicy: i thought people were doing stuff with that.  amarok handles it better
<bluefoxicy> back in a few minutes.
<bddebian> thanks for the warning
<Hobbsee> Keybuk: mdz if now-ish is a suitable time to discuss what happens with uploads to main, etc, that's cool here.
* Hobbsee wont be going home till she's feeling insane.  it's not worth it.
<zul> jdub: ping im back
<bluefoxicy> tseng:  stop poking meeeeeeeeee  </warcraft>
<infinity> Riddell: Sorry about that.  I did a source+binary promotion, and soyuz appears to not believe that that binary belongs to that source...
<Keybuk> infinity: you forgot to move it on the queue page too then <g>
* Hobbsee wonders what that was about.
<infinity> Keybuk: It was 3am, give me a break. :)
<infinity> Keybuk: At any rate, the soyuz bug is clearly still there.  Bah.
<Hobbsee> infinity: fix it.  even at 3am :P
<robertj> Can we get edgy+1 as a spec target on launchpad?
<Hobbsee> robertj: probably ask that in #launchpad
<robertj> I thought about that, just though it was probably more a policy question
<robertj> but if noone feels strongly, I'll file a bug
<robertj> Bug #54869
<Ubugtu> Malone bug 54869 in Ubuntu "edgy+1 needed as a release target for spec drafting" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54869
<Hobbsee> robertj: package effected for that should be launchpad
* Hobbsee fixes is
<Hobbsee> *it
<infinity> s/launchpad/blueprint/
<Hobbsee> oh.  wait.  i assigned it wrong.  i thought you could assign things to launchpad
<Hobbsee> ahhh...
<Hobbsee> infinity: who renamed that so unintuitively?  :P
<infinity> blueprint is the name of the spec tracker.
<Hobbsee> right
<infinity> "launchpad" isn't a product at all, just a service that ties them all together.
<Hobbsee> news to me.
<Hobbsee> yep, true
<infinity> blueprint, soyuz, malone, etc.
<Keybuk> robertj: that would be an incorrect bug ... we don't use the spec targets until they have been approved
<Hobbsee> infinity: one problem anyway.  there's no way to assign anything to blueprint
<Keybuk> and specs for edgy+1 wont be approved until the edgy+1 development summit
<Keybuk> which happens after edgy+1 has opened
<robertj> ah
<infinity> Hobbsee: Because it's not an ubuntu package.  You need to add a new task for the product.
<Hobbsee> ah
<infinity> Hobbsee: Of course, as Keybuk mentions, it's probably pointless anyway.
<Hobbsee> well, yeah, but it's useful to know.
<Keybuk> I think the blueprint targets are also just the list of releases for the distro
<infinity> Reassigning a bug from a package to a product is less than intuitive, yes.
<Keybuk> and there's no way to open a edgy+1 release without closing edgy
<infinity> Add new task, reject original task.
<infinity> Keybuk: That's not true, we can have multiple open dists at the same time.  Of course, we don't WANT that.
<Keybuk> infinity: right
<jdub> zul: pong
<zul> jdub: i was just about to head to bed but i can stay for a bit longer
<jdub> :)
<jdub> won't keep you long
<zul> ok
<ajmitch> afternoon jdub 
<jdub> you konw about the TLS-related 5s delay message?
<zul> yep..
<zul> im working jeff to fix it
* ajmitch has complained about that one already 
<zul> its glibc and xen thingy
<zul> next..:)
<ajmitch> next to be fixed is my wireless with that kernel :)
<jdub> zul: we're definitely not going to have a single linux/xen for edgy?
<ajmitch> zul: got a git tree of that kernel that you're working from?
<zul> correct..
<zul> ajmitch: working on it this weekend hopefully
<ajmitch> ok
<jdub> zul: which is the scarier side of the fence - patching a kernel so it'll run on xen (domU), or patching a kernel so it can be a dom0?
<ajmitch> then I can try & ram ipw2200 in
<zul> jdub: its a config option, dom0 kernels can do both but i was thinking of supplying a domU kernel as well
<jdub> zul: right, but it requires scary patching to make our linux-image dom0 capable?
<zul> jdub: yes, edgy kernel uses a different alt-smp than that of the xen-kernel
<zul> and upstream is based off of 2.6.16.13
<jdub> ahr
<jdub> scary
<zul> very...and very masochistic
<jdub> i was about to say ;)
<jdub> uh, now i've forgotten the other things
<jdub> i'll play with it again and ping you when you're up :)
<zul> and there was a modificaton to kernel-package to get the naming correct
<zul> jdub: ok i just uploaded a -3 xen-utils and in the process of upload a -4 kernel 
<zul> my isp is going to love me this month ;)
<zul> jdub: oh yes if you were going to ask for grub, debian has a patch for update-grub already
<ajmitch> mine already loves me lots..
<jdub> rad
<ajmitch> zul: does the -4 kernel create the initramfs?
* ajmitch uploads new xgl crack
<zul> no it doesnt...debian doesnt as well
<ajmitch> ok
<zul> afaik
<zul> there should be really a #ubuntu-xen meh...anyways im going to bed...night
<ajmitch> yeah
<ajmitch> night
<jdub> zul: planning to do lrm packages for xen-image?
<zul> uh...good question..to get nvidia working with xen is kind of hackish from what i read
<ajmitch> jdub: proprietary drivers like nvidia tend not to play nicely with xen
* jdub was mostly worried about wifi ;)
<ajmitch> heh
<ajmitch> should be possible, I guess
* ajmitch should take a look at it
<ajmitch> my poor laptop is tethered again by ethernet
<jdub> it's a pity there are so many infrastructural changes that  need to be made
<jdub> making it hard to backport for dapper
<zul> right this time im going to bed..
<infinity> There's been a VERY LOUD fire alarm going off down the street for the last half hur.
<infinity> s/hur/hour/
<infinity> I'm nearly ready to kill.
<imbrandon> infinity: bb gun --> speaker
<imbrandon> heh
<zul> jdub: if you have any questions feel free to email me
<Keybuk> infinity: you would have gone nuts here at the weekend
<Keybuk> some kids burned down the local sub station
<bddebian> bb gun? pfft, 20 Gauge
<Keybuk> and for the first few hours of the power outage every single house alarm for miles was going off
<bluefoxicy> heh
<bluefoxicy> with no power
<Keybuk> assumedly they get their power from elsewhere
<bluefoxicy> speaking of power, my computer is on a UPS.  It's required.
<jdub> ajmitch: whoa, xgl update
<bluefoxicy> When my AC kicks in it can knock the power out because I have more power drain up here (FROM ONE SOCKET MIND YOU) than the breaker allows.  (a wall -> 6 way splitter; a UPS; a power strip; another power strip)
<bluefoxicy> so my UPS goes down and relieves the load for about 3 seconds :P
<ajmitch> jdub: correct
<ajmitch> I thought I may as well get it out there & get the bugreports flooding in
<ajmitch> jdub: f-spot also added to desktop seed in the bzr branch, just need to get ubuntu-meta updating properly
<jdub> ajmitch: cool
<Keybuk> *sigh*
<Keybuk> now my hardphone is deciding it doesn't like the network every few minutes
<whiprush> hi Keybuk 
<bddebian> Why are there buildX versions that didn't get synced automagically?
<bddebian> Heya whiprush
<whiprush> hi bddebian, others ...
<ajmitch> bddebian: debian may have updated after the autosync was turned off
<ajmitch> hey whiprush 
<Keybuk> hmm, there's half a dozen firmware updates for my hardphone
<Keybuk> maybe one of those helps ...
* Keybuk reads the release noets
<whiprush> Keybuk: man dude, I bet 20 bucks you get hosed on network-manager syncage again this cycle.
<Keybuk> whiprush: how do you mean?
<bddebian> ajmitch: Fair enough, thx
<whiprush> major release at the most crappy times.
<Keybuk> I'm largely ignoring network-manager this cycle
<whiprush> wotcha working on?
<Keybuk> upstart
<whiprush> heh
<whiprush> I just remembered the dash thing
<Hobbsee> Keybuk: make StevenK do it :P
<Kaleo> Hello guys 
<bddebian> Hello Kaleo
<Kaleo> Hi bddebian 
<Kaleo> bddebian, do you know who usually hacks on ubiquity ?
<bddebian> Not really, sorry
<jdub> Kaleo: Kamion 
<Kaleo> okay
<Kaleo> jdub, thanks
<micahcowan> I'm upgrading to edgy, so I can help squash bugs... is updating sources.list and doing apt-get dist-upgrade sufficient (actually, it's already underway...)?
<Hobbsee> micahcowan: yes
<micahcowan> great. Next question: it's halting because it wants /usr/X11R6/bin to be a symlink, so it wants me to move it out of the way. I figure it might be easier if the contents of that dir are already where they're going to be, perhaps... what is /usr/X11R6/bin going to point at (it didn't seem to say)?
<Hobbsee> micahcowan: --> #ubuntu+1
<micahcowan> oh, great. Thanks!
<jdub> hrm
<jdub> genius is not in ubuntu
<Hobbsee> jdub: should it be?
<jdub> yeah, totally
<LaserJock> we have no genius?
* jdub packages it as a birthday present for maia
* sivang wonders if upgrading today will break X.
<Lathiat> probably :)
* raphink wonders if security.u.c is down again
<crimsun> reachable for me.
<Lathiat> works for me too
<raphink> yes that works now :)
<raphink> it just took quite a long tim
<raphink> time
<dholbach> ogra: hellas! you might want to look into http://download.gnome.org/sources/genius/0.7/
<dholbach> might be something for the edubuntu world
<crimsun> you just missed   00:58 < jdub> genius is not in ubuntu   01:00  * jdub packages it as a birthday present for maia
<dholbach> WOW
<dholbach> jdub:  WAY TO GO !!!
<jdub> dholbach: ha ha
<mvo> ah ah ?
* dholbach hugs jdub
<dholbach> ogra: how did gnome-screensaver 2.14.3 look?
<pitti> Good morning
<Burgundavia> morning pitti
<Hobbsee> hi pitti!
<Burgundavia> pitti: mpt and myself had a discussion about the crashingreporting UI in -desktop
<pitti> hey Hobbsee 
<pitti> Burgundavia: don't tell me you redesigned it once again :)
<Burgundavia> pitti: not the edgy stuff. We were talking about the edgy+1 stuff
<pitti> Burgundavia: yesterday I almost finished implementing his design
<pitti> ah
<dholbach> somebody please add #ubuntu-bugs to the topic
<jdub> mvo: the apt update didn't fix the Packages.bz2 issue i was seeing
<jdub> Failed to fetch http://people.ubuntu.com/~jdub/edgy/Packages.gz  404 Not Found
<mvo> jdub: oh, crap. thanks for testing
<pitti> AAAARRRRGH @ f-spot
* ..[topic/#ubuntu-devel:Hobbsee] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs" | yes X in edgy is a mess atm
<Hobbsee> dholbach: like that?
<pitti> ajmitch: nnnnnnggg, I explicitly unticked 'do not copy photos' during import and still it created a 5 GB ~/Photos folder and copied them
<pitti> ajmitch: this just DoSed my backup system
<dholbach> Hobbsee: super
<ajmitch> pitti: interesting
<jdub> infinity: around?
<pitti> ajmitch: this should so much default to 'off'...
<pitti> ajmitch: (sorry for the rant)
* pitti hugs ajmitch and knows that this is not Andrew's fault
<ajmitch> file a bug, I'll look for a patch in the stable branch upstream
<pitti> ajmitch: will do
<pitti> ajmitch: ooh, new xserver-xgl? COTD? :)
<ajmitch> pitti: of course
<jdub> i would test it if fglrx worked - gar! quebecistani craptop!
<jdub> also, no xorg 7.1 means no aiglx love :(
<jdub> aiglx > xgl :(
* ajmitch loves the aiglx on the laptop
<dholbach> jdub: you uploaded genius already? :)
<jdub> dholbach: no
<jdub> i have to fix up pbuilder before i feel comfortable uploading it
<dholbach> ok
<dholbach> in dapper it should suffice to install it
<Hobbsee> jdub: you broke pbuilder?
<jdub> it hasn't been working on my machine for a long time
<Hobbsee> jdub: ahhh.  great
<dholbach> create --override-config --distribution=<something>?
<infinity> jdub: Yes, thought obviously less than attentive on IRC.
<jdub> infinity: fuck, i should remember to add payloads to my pings
<infinity> jdub: Yes.  Yes you should.
<jdub> infinity: ah, that's right
<jdub> infinity: i would like to make xnest an alternative, so we can switch between xnest and xephyr - are there any standardisation problems with that, and things we need to sort out with debian, or is it "propose a patch and go" type stuff?
<infinity> Well, in the interest of sane sidegrades, you may want to make sure it happens in time for both etch and edgy.
<infinity> But otherwise, it's just a matter of making the packaging changes correctly so it doesn't explode, and you're good to go.
<pitti> Kamion: can you please accept/new all the new dapper langpacks?
<Kamion> pitti: done
<pitti> thanks
<Kamion> infinity: hmm, I see my cheesy attempt at hacking around the pockets thing in d-i didn't work quite right
<Kamion> infinity: should I fix the cheesy hack, or remove it and coordinate an upload with you?
<Kamion> happy to do either (though it seems that fixing the cheesy hack might involve less messy coordination time in the future)
<pitti> doko: yay, OO.o built everywhere *phew* :)
<dholbach> pitti: that sounds as you were in doubt :)
* Kamion decides to just fix the cheesy d-i pockets hack
<Hobbsee> hehe
<infinity> Kamion: I think the cheesy hack is probably the best way to go, actually.
<infinity> Kamion: Oh, which you decided to do without prompting anyway.  Yay, response time.
<tepsipakki> congrats, there's an article on Helsingin Sanomat (biggest newspaper in Finland) about installing Ubuntu. It's takes nearly the whole front page of part D :)
<pitti> dholbach: not any more, because doko did not phone me at 3 am :)
<Kamion> infinity: :-)
<dholbach> pitti: hehe
<doko> pitti: lucky guy :)
<pitti> doko: so, if pkg-create-dbgsym works with OO.o, it just has to work with just about any other package, too :-P
<doko> pitti: does it take as long as pkg-stripstranslations does? ;-P
<pitti> doko: I don't know, but at least it has no redundancy (as striptranslations has)
<dholbach> gutenprint 5.0 is there
<pitti> oh, great
<ajmitch> hunger: wireshark sync was already requested, just spotted it in -bugs :)
* pitti makes cdbs-edit-patch work properly with tarball.mk
<ajmitch> pitti: that's useful - I still have a package using tarball.mk & simple-patchsys
<pitti> ajmitch: until now I had a separate script, but it used dbs-edit-patch, and it doesn't work very well
* pitti also makes cdbs-edit-patch capable of editing patches with rejections while he is at it
<ajmitch> it's a package I never touched much, I adjusted the patch with vim each time
<pitti> ajmitch: hal and g-v-m use tarball.mk, as well as postgresql, so I have a certain interest in a good patch edit script :)
<janimo> pitti, while at it can you make it to accept debian/patches/xx_name as well, so only use basename of argument?
<pitti> janimo: right, that was already on my list
<janimo> as it's easier to use completion  than remember the names
<janimo> ok:)
<hunger> ajmitch: Thanks for the info wrt. wireshark!
<ogra> seb128, dholbach ...
<ogra> ogra@edubuntu:~/packages/gnome-screensaver-2.14.3$ debdiff ../gnome-screensaver_2.14.1-0ubuntu5.dsc ../gnome-screensaver_2.14.3-0ubuntu1.dsc|wc -l
<ogra> 34295
<ogra> that doesnt make me feel we should have it in -updates
<ajmitch> hunger: I've fixed xserver-xgl, too, just have to upload
<Chipzz> is there somewhere I can ask about ltsp on ubuntu?
<ogra> Chipzz, yes
<hunger> ajmitch: This is getting spooky!
<Chipzz> ogra: where?
<ogra> Chipzz, here or in #edubuntu ... ot in #ltsp .... 
<hunger> ajmitch: so many of my bugs are vanishing today!
<Chipzz> ogra: well, since this isn't a support channel... :P
<ogra> in any case you'll likely talk to me ;)
<dholbach> ogra: that depends on where the changes are - most of it is buildsystem for sure and translations
<ajmitch> hunger: well I did upload xserver-xgl the first time - I just missed that conflict
<seb128> ogra: 30000 lines of .po changes and 4000 of autogenerated Makefile and 400 of code? :p
<dholbach> ogra: pipe it through diffstat
<ogra> Chipzz, then #ltsp or #edubuntu
<ogra> seb128, argh, i didnt think about the .po files :)
<seb128> ogra: for other tarballs 90% of the changes where help translation and .po
<hunger> ajmitch: No problem:-) It is just that this is the 4 or 5th of my bugs that got squashed today;-)
<ajmitch> hunger: you should be happy about that :)
<hunger> ajmitch: I definitly am!
<ogra> seb128, yep ... i just didnt think about that ... and i'm convinced autotools wont produce 30000 line diffs ;)
<ogra> oh, well, diffstat disagrees even here :) aclocal.m4                          |12821 ++++++++++++++++++------------------
<seb128> :p
<hunger> Riddell: Any news on the edgy/artsd crashes?
<Riddell> hunger: looks like kdemultimedia decided to go with the wrong akode even though I gave it a versioned build-dep
<Hobbsee> Riddell: darn.  eta on the fix?
<Riddell> I'll throw it up for another build now
<doko> interesting, 2.0.3-4ubuntu2 < 2.0.3-3ubuntu2-1 ... didn't know that
<infinity> doko: Well, 2.0.3-3ubuntu2 is the upstream version in the second case.
<infinity> doko: There's only one Debian Revision, and it's the one after the last "-".
<infinity> doko: (Policy strongly advises against, or perhaps even forbids, having more than 1 "-" in the version, for this very reason)
<StevenK> I don't think they forbid it.
<doko> ohh, I missed the -1 ...
<infinity> The upstream_version may contain only alphanumerics[33]  and the characters . + - : (full stop, plus, hyphen, colon) and should start with a digit. If there is no debian_revision then hyphens are not allowed.
<infinity> That doesn't read very clearly, since it seems to imply that if there's a debian_revision, multiple hyphens are allowed, but that's not really what it means. :)
<infinity> And earlier:
<infinity> The format is: [epoch:] upstream_version[-debian_revision] 
<pitti> infinity: why, it's pretty clear, isn't it?
<pitti> infinity: this essentially means that 'native packges must not have hyphens'
<infinity> pitti: No, it's not quite clear.  If there's no debian_revision, hyphens aren't allowed (ie: for native packages), but it doesn't really specify how many you should have if there is (which is, ideally, 1)
<pitti> and for non-native packages, the last hyphen separates the debian revision
<infinity> Anyhow, just leads to this sort of accidental confusion.
<infinity> No big deal.
<pitti> infinity: I think it wanted to avoid specifying the number of hyphens
<pitti> right
<micah_c> What's the process for bugs that are assigned to MOTU-Reviewers? ...I'm interested in 45930, which is for the "joystick" package (jstest and similar). It's a /very/ inessential package; however, I've submitted a patch that fixes the issue, and am just curious when I might expect to see the package updated? I'm not impatient or anything...
<micah_c> Actually, disregard that: #ubuntu-motu should be a much better place to ask this (I just realized...)
<seb128> doko: I'm done with libs uploads to dapper-updates, now they have to be accepted and build
<doko> seb128: ok, I have to find out these I need ...
<dholbach> pitti: you rock!
<seb128> dholbach: what did he do?
<pitti> dholbach: do I? :) (thanks)
<dholbach> seb128: cdbs hacking :)
<pitti> ah, that :)
<pitti> yep, that was a long-standing item on my todo
<dholbach> and new gvm
<seb128> doko: probably gtk-engins gtk+2.0 
<seb128> gtk-engines
<seb128> and maybe at-spi, dholbach would know
<dholbach> update for gtk32-libssomething?
<seb128> dholbach: for dapper-updates yep
<dholbach> no, didn't do at-spi changes for dapper
<doko> pango is already built
<seb128> pango had no new version
<seb128> ah, nice
* seb128 hugs pitti
<seb128> better cdbs-edit-patch ;)
<pitti> dholbach: FYI, I also updated the MOTU school patch page
<pitti> seb128: enjoy!
* dholbach hugs pitti
* dholbach hugs pitti
* dholbach hugs pitti
<pitti> seb128: it saved me a lot of time with the new g-v-m
<dholbach> it's the HUG DAY :)
<pitti> right!
* pitti hugs dholbach and seb128 ecstatically
<seb128> pitti: I got used to mv the patch to the src dir, cdbs-edit, patch -p1 etc
<Spads> Hmmm, I'm not seeing xen-image in edgy.  Am I missing something?
<seb128> pitti: really nice that I can drop the extra steps now ;)
<pitti> seb128: oh, you didn't use my cdbstpatch script? 
<pitti> well, it's obsolete now anyway (and quite broken, too)
<seb128> pitti: what script? I use cdbs-edit-patch
<tseng> dholbach: python beagle bits have changed again, btw
<dholbach> tseng: mh, what does that mean for me?
<tseng> dholbach: its back to being called python-beagle (again)
<dholbach> ahhhh
<dholbach> is it in the archive again?
<tseng> its in unstable
<dholbach> ah ok
<dholbach> once it hits the archive, i'll change the suggests from deskbar-applet
* ogra wonders what subscribed him to bug 37603
<tseng> i think its in NEW for us
<Ubugtu> Malone bug 37603 in ubuntulooks "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits" [Medium,Unconfirmed]  http://launchpad.net/bugs/37603
* tseng hugs dholbach 
<dholbach> right-o
<Spads> I can see packages for the guest Xen kernel, but not the host.  Has xen-image made it into edgy proper yet?
<ajmitch> iirc the kernel can be used for both
<Spads> hmmmm
<imbrandon> ajmitch: i thought domU and dom0 kerns were diffrent
<Spads> That's my experience
<ogra> Spads, ask zul if he's arund
<Spads> zul: ping
<ogra> he packaged it
* Spads nods
<ajmitch> I'm sure zul mentioned that this one has them as either
<ajmitch> as I've seen in debian
<imbrandon> right, it might contain both
* imbrandon looks for zul's wiki
<ajmitch> 14:46 < zul> jdub: its a config option, dom0 kernels can do both but i was thinking of supplying a domU kernel as well
<imbrandon> ahh
<ogra> iirc he said somethig about domU not being included
<Spads> yeah
<ogra> we only have dom0
<Spads> the source package can be used to generate both
<Spads> I saw chatter about a xen-image package for the host kernel
<Spads> and I thought that was what the cheering was about earlier
<ogra> the cheering was about seeing soething with xen in the name hitting the archive :P
<Spads> 18:06 <bluefoxicy> I thought dom0 kernels could also run domU
<Spads> 18:06 <zul> they can,we dont ship domU kernels
<ogra> we're so easy to please :)
<Spads> Huh.
<Spads> Okay, this is a Xen 3.0 thing
<Spads> color me impressed
<ajmitch> ogra: you mean the cheering wasn't just about xgl, and the groan as new bugs come in?
* ogra covers from that xgl pollution 
<imbrandon> heh
<jdub> Spads: it works okay, but needs a bit of love
<Spads> jdub: I notice no hypervisor package either
<jdub> Spads: unfortunately it requires a bunch of infrastructure changes
<jdub> Spads: xen-hypervisor-3.0-i386
<Spads> oh
<Spads> this is amd64
<Spads> maybe that's why I'm not seeing it all
<jdub> xen-hypervisor-3.0-amd64
<Spads> W: Unable to locate package xen-hypervisor-3.0-amd64
<jdub> hrm, maybe it hasn't built
<Spads> ahhh
<Spads> there are sources
<Spads> good enough for me
<Spads> jdub: thanks for the hints
<ogra> https://launchpad.net/+builds/+build/233537
<ogra> Spads, ^^
<Spads> Gar.
<Kamion> infinity: '-d dapper' doesn't seem to work via the ssh trigger; I get "bad project: -d"
<infinity> Kamion: Lies.
* infinity looks.
<infinity> Kamion: How do you invoke the trigger?
<infinity> Kamion: Give me a full command-line.
<doko> Kamion: dapper-proposed did build the native amd64 packages once, the resulting binary packages should be removed. do you want a bug report? openoffice.org-evolution, openoffice.org-dev
<infinity> Kamion: Oh, I see the problem, I think.
<infinity> Kamion: Try triggering on king...
<doko> pitti: new firefox security upload for dapper?
<pitti> doko: yet another one???
<ogra> dholbach, does genius have a homepage ? 
<dholbach> ogra: dunno
<dholbach> ogra: jdub stepped up to package it
<ogra> http://www.jirka.org/genius.html
<ogra> found it :)
<doko> pitti: no, I'm just confused, about our ia32-libs* packages for -security, -updates, and -proposed ...
<ogra> jdub, slacker ! :)
<Kamion> infinity: + ssh -o ControlPath none -n buildd@terranova.buildd /home/buildd/bin/BuildLiveCD -d dapper ubuntu
<Kamion> infinity: yep, king seems happier now ...
<Kamion> doko: yes please
<mhb> hello everyone
<mhb> I have a little devel-related question ... Are there plans to get the console (ALT+F1...) localised (displaying fine local characters, respect the keyboard setting etc.)?
<infinity> Kamion: Okay, I'll update the others.  Thanks for testing.
<infinity> Kamion: terranova and royal fixed too now.
<pitti> doko: ah, now I know what you mean; no, ia32-libs* update is not required, the latest USN only fixed a regression in the browser itself (not in the libs)
<mjg59> pitti: the suidness can't be removed from svgalib, hence my suggestion that we not include the binaries
<mjg59> The library itself is safe
<ldarnis> join #ubuntu-motu
<ldarnis> oops
<mjg59> Hm.
<Hobbsee> hm?
* mjg59 looks at just copying the svgalib code into usplash
* Fujitsu hits mjg59.
<Hobbsee> mjg59: i rather like keybuk's idea - if we've got an X server, give people a login window.
<mjg59> Fujitsu: Minimises the amount of code that needs to be maintained
<Hobbsee> mjg59: then show them the rest of the bootup, depending on hwo long they take to login.
<sabdfl> Kamion: for the moment, we want to build foobuntu iso's but not publish them in the usual place
<sabdfl> pass them on fsf europe for testing etc
<mjg59> Hobbsee: Yeah, but we're not going to have an X server :)
<Hobbsee> mjg59: pity....
<Hobbsee> :P
<pitti> mjg59: although I'm not generally a friend of code copies, if you only need a safe fragment of the code, then this could make sense
* Hobbsee waves to the sabdfl 
<StevenK> mjg59: Why not just statically link? Even those that has an ick factor.
<pitti> hey sabdfl 
<Hobbsee> Kami*on will hate me, i think.  requesting more syncs :P
<StevenK> s/those/though/
<sabdfl> hey folks
<mjg59> StevenK: Can't have build-depends in universe for packages in main
<Fujitsu> Hi sabdfl!
* StevenK wishes to know why he can't type tonight.
<StevenK> mjg59: Point.
* mjg59 hacks out chunks of code
<mjg59> Ok, maybe this is doable
<doko> seb128: gtk-engines will be updated as well for dapper-updates?
<Kamion> sabdfl: how do we go about passing them on without publishing them on cdimage? I can't really mail ISO images around :)
<Hobbsee> Kamion: well, you can try.  could be amusing to see the results too :P
<Kamion> infinity: thanks
<sabdfl> Kamion: they can be published, just not in the usual place
<sabdfl> call them gnubuntu, please
<sabdfl> it's unofficial until it's not, iyswim
<Chipzz> sabdfl: what's rms going to say about that? :)
<Kamion> ok, any ideas as to where to publish them though?
<sabdfl> YES!
<Kamion> people.ubuntu.com or something?
<sabdfl> that would be fine
<Chipzz> sabdfl: or are you referring to what rms actually wanted?
<Kamion> so is it foobuntu or gnubuntu internally? getting mixed messages here :)
<sabdfl> gnubuntu
<Kamion> I'd just written "foobuntu" into a load of files
<Kamion> d'oh
<sabdfl> sorry
<Kamion> oh well, shouldn't take long to sed
<Kamion> I'm doing a test build now
<doko> seb128: orbit2 stays at v 2.14.0 ?
<doko> dholbach: or do you know about plans for orbit2 and gtk-engines ?
<jsgotangco> \o/ gnubuntu \o/
<dholbach> doko: for dapper?
<doko> dapper-updates
<Kamion> doko: do you mean gtk2-engines?
<Kamion> gtk2-engines is already in the dapper-updates unapproved queue
<dholbach> doko: there were not tarballs for orbit, but for gtk-engines
<doko> sure, gtk2-engines
<doko> dholbach: I don't see anything in launchpad for gtk-engines and gtk2-engines
<dholbach> then it must be in the unapproved queue
<Kamion> sabdfl: would the title-case name be Gnubuntu or GNUbuntu?
<Kamion> dholbach: it is, as I said
<Kamion> I did a lot of unapproved this morning, just lost the will to live part-way through - I'll regain it in a bit
* dholbach hugs Kamion
<sabdfl> Kamion: i've no idea which is more appropriate, would you take a squizz at gnu.org and see what they tend to prefer?
* Hobbsee thought there was already a gnubuntu.  there was certainly talk of one.
<jsgotangco> GNU
<doko> Kamion: is there still some stuff in the unapproved queue for dapper-updates?
<Kamion> oh, if it's what they prefer then GNUbuntu seems likely - c.f. GNUtls, GNUstep. there are counterexamples of course
<Kamion> doko: yes
* dholbach -> lunch
<Kamion> (e.g. Gnumeric, GnuPG)
* Hobbsee "borrows" dholbach's lunch, and runs away with it
<Kamion> Hobbsee: not really; it's been talked about for a long time, as you say
<Hobbsee> Kamion: okay, cool
<mdke> GNU/buntu surely
<Kamion> :-P
<jsgotangco> ekkk
<imbrandon> lol @ mdke;)
<mjg59> pitti: Ok, looks like I should be able to munge it directly into usplash
<mjg59> sabdfl: You ought to have high-res usplash at some point this evening
<sabdfl> mjg59: awesome - without compromising suspend / resume?
<mjg59> I believe so
<sabdfl> very cool. i thought i would have to take mind-enhancing substances to ever see that :-)
<jsgotangco> lol
<imbrandon> lol
<doko> Kamion: but no gtk2* and orbit2 stuff?
<sabdfl> mjg59: how did you solve the "wake up the video card" problem?
<thom> mjg59: also, any news on hotpluggable x60s ultra bay justice?
<Kamion> doko: 12:53 < Kamion> gtk2-engines is already in the dapper-updates unapproved queue
<mjg59> sabdfl: We don't use the framebuffer
<mjg59> Just jump to vesa directly
<mjg59> thom: Wurgh. I'll try to hit that over the weekend?
<thom> yay :-)
<ajmitch> mjg59: do you still want to take the blame & be marked as maintainer of xserver-xgl, or shall I change that? :)
<mjg59> ajmitch: Heh
<thom> my hack doesn't work anymore in edgy since /proc/acpi/ibm/dock has gone away
<mjg59> ajmitch: If you're going to actively look after it, would you mind adopting it for now?
<ajmitch> I can
<mjg59> Cool
<mjg59> Thanks for the upload
<ajmitch> also got libcm, and possibly spiftacity
<dholbach> create an xgl team in launchpad and subscribe it to the bugs
<ajmitch> sounds sane
<dholbach> i'm sure you'll get followers
* ajmitch can't be sane this week though
<jsgotangco> he'll be treated like a god
<ajmitch> hah
<janimo> which of the gnome daemons or apps listens to key presses via HAL?
<Lure> janimo: I think gnome-settings-daemon from control-center package 
<Lure> janimo: at least this is what I used to understand Ubuntu behaviour for KubuntuLaptopButtons...
<mjg59> Nothing listens to the HAL events yet
<Riddell> Lure: which reminds me, mjg59 said he could supply us with a list of supported keys
<janimo> Lure, thanks. I know g-v-m and g-p-m are candidates as well, but was wondering if it got put somewhere common in latest gnome
<mjg59> gnome-settings-daemon gets them straight from X
<janimo> mjg59: so no gnome app does the equivalent of lshal -m for keys?
<mjg59> janimo: Not via hal, no
<Lure> true, g-s-d just does X events
<mjg59> Should probably port that some time
<mjg59> And also add code to let people set new keymaps
<janimo> mjg59: so classical grab the keyboard then, thanks
<Lure> mjg59: so using hal directly is preffered over X events?
<mjg59> Lure: Yeah
<Lure> mjg59: ok, will rething Kubuntu implementation then...
<Lure> s/rething/rethink/
<Lure> mjg59: can you supply us with the list of all supported keys as mentioned by Riddell?
<Hobbsee> Lure: i got a few more people adding their keys to your list, btw
<mjg59> Sure, hang on a moment
<Lure> Hobbsee: seen that - thanks!
<mjg59> Lure: As far as the hal ones go, just check hald/linux2/addons/keyboard.c
<zul> heylo
<Hobbsee> hi zul 
<Lure> mjg59: ok, thanks - will do this evening...
<setuid> I'm trying to figure out the magic to build the ATI driver packages for Edgy. Any hints here? 
<setuid> The BinaryDriverHowto/ATI document didn't seem to help 
<setuid> https://help.ubuntu.com/community/BinaryDriverHowto/ATI
<pygi> sivang, poke
<mdke> dholbach: ping?
<janimo> mjg59: hmm in g-p-m 2.14.3 at least, in src/gpm-hal-monitor.c there is code for handling button pressed events from HAL.
<mjg59> janimo: Only sleep, power and lid
<janimo> well, that's something
<mjg59> That's because they can come from multiple sources
<janimo> I only need sleep for xfce anyway
<janimo> for now that is
<pitti> dmg: hello
<dmg> howdy
<Hobbsee> mdke: i think he went to lunch
<doko> Kamion: I got a reject for ia32-libs-openoffice.org_11.1 ?
<mdke> Hobbsee: yep thanks, he can respond when he gets back
<Hobbsee> mdke: true
<Kamion> doko: yes, you uploaded it twice and I rejected the first one since the second was obviously newer
<doko> Kamion: thanks
<ogra> mvo, if u-m pops up a conffile prompt, wouldnt it be better to show the user the full patch instead of only the filename ? 
<ogra> *path
<mvo> ogra: probably, yes. what conffile is it?
<ogra> /etc/exports ...
<ogra> i had a prompt asking me about exports so i was confused and had to look into the vte win to find out its /etc/exports
<ogra> especially since i didnt look which packages were upgraded ...
<seb128> nice, gdb segfault :/
<mvo> seb128: haha, generate a bt :)
<mvo> ogra: right, I will look at it
<seb128> Program received signal SIGSEGV, Segmentation fault.
<seb128> 0x0808ff32 in _initialize_thread_db ()
<seb128> (gdb) bt
<seb128> #0  0x0808ff32 in _initialize_thread_db ()
<seb128> #1  0x08090309 in _initialize_thread_db ()
<seb128> #2  0x081075b9 in normal_stop ()
<seb128> #3  0x0807f6c9 in discard_cleanups ()
<seb128> #4  0x081122d9 in throw_exception ()
<seb128> #5  0x0811238c in throw_exception ()
<seb128> #6  0x081123e2 in throw_verror ()
<seb128> #7  0x080821ea in error ()
<seb128> #8  0x080824ca in perror_with_name ()
<seb128> #9  0x0808ed08 in supply_gregset ()
<seb128> mvo: here you go :p
* mvo smiles
<seb128> mvo: want to debug it? :)
<seb128> doko: around?
<doko> seb128: yes
<seb128> doko: http://librarian.launchpad.net/3709638/buildlog_ubuntu-edgy-i386.ctypes_0.9.9.6-1_FAILEDTOBUILD.txt.gz
<seb128> doko: does it look like something that just need a retry?
<seb128> "pycentral: pycentral rtinstall: installed runtime python2.3 not found"
<doko> seb128: maybe sync that from unstable. the package explicitely depends on python2.3, not python-all-dev. in edgy, we don't support 2.3 anymore.
<seb128> doko: that's the package from Debian unstable
<doko> seb128: then it should depend on python-all-dev
<doko> b-depend
<seb128> doko: "Build-Depends: python2.3-dev (>= 2.3.5-10), python2.4-dev, python-central (>= 0.4.17), debhelper (>= 5.0.37.1)"
<seb128> doko: python2.3-dev (>= 2.3.5-10), python2.4-dev has to be remplaced by python-all-dev ?
<doko> python-all-dev (>= 2.3.5-11)
<seb128> ok,t hank you
<bddebian> Morning
<seb128> I'll open a Debian bug and fix the Ubuntu package
* StevenK kicks python-support and python-central.
<doko> seb128: right, but look in the rules file, if python2.3 is called explicitely ...
<StevenK> Both seem to ignore subdirectories underneath /usr/share/py{central,thon-support}.
<seb128> doko: 
<StevenK> Which means /usr/share/pycentral/linda/__init__.py gets linked as __init__.py, and then I wonder why import linda fails.
<seb128> build-python%:
<seb128> 	dh_testdir
<seb128> 	python$* setup.py build
<seb128> and they do that for "PYVERS	:= $(shell pyversions -vr debian/control)"
<seb128> so it should be fine
<doko> StevenK: it must be /usr/share/pycentral/linda/linda/__init__.py
<bddebian> Aye, you need debian/pycompat
<doko> do you move things around yourself?
<StevenK> doko: Ewwww
<seb128> hum, I should read the new policy
<seb128> for now I'll just drop the python2.3 Build-Depends for the Ubuntu package
<StevenK> I was ignoring until someone filed a bug on Linda.
<bddebian> http://wiki.debian.org/DebianPythonFAQ
<bddebian> http://wiki.debian.org/DebianPython/NewPolicy
<doko> seb128: looks fine. and something special about ctypes (because it's part of python2.5), the package should not depend on python (<< 2.5) (but you would have to remove that yourself at the moemnt
<seb128> bddebian: I know where they are, I've just been lazy trying to understand it and to decide what tool to use
<imbrandon> nice, fink is on LP now /me dances
<bddebian> Ah
<doko> bddebian: no, just the latter
<Riddell> pitti: it seems like KDE HAL dude doesn't want to stop using the HAL mounting scripts
<Riddell> pitti: since they implement functionality that would otherwise have to be duplicated in KDE
<Riddell> pitti: and it's hard to argue against using HAL since it's ment to be where all the problems are taken care of
<pitti> Riddell: why duplicated? the scripts do exactly the same as pmount-hal
<Riddell> pitti: in this case it was creating nice names in /media
<pitti> Riddell: ok
<pitti> Riddell: well, then we need to sanitize the backend scripts
<Riddell> pitti: could we not just make the scripts run pmount?
<pitti> Riddell: maybe we can cowboy it, but the scripts are run as root, not as the target user
<Riddell> right
<dholbach> mdke: pong
<mdke> dholbach: I've made an ubuntu-docs package for edgy, it's at https://docteam.ubuntu.com/repos/trunk if you fancy uploading
<mdke> i hope it works :)
<dholbach> ahhhh nice
<mdke> I've tested it on dapper, but not edgy
<dholbach> i'll let you know - checking out
<viper550> Hello
<seb128> hi viper550
<dholbach> mdke: it's building - i made some tiny changes to it - will send you the diff
<dholbach> (after it built)
<mdke> dholbach: thanks
<dholbach> anytime
<mjg59> Wow. Are the buildds busier these days?
<mjg59> I had got far too used to uploading stuff and it hitting the archive half an hour later
<mjg59> pitti: I've removed the need for including svgalib
<zul> mjg59: i could be one to blame for the buildds being busier :)
<mjg59> zul: Oh, they're doing a kernel?
<bddebian> I'm sure all the sync requests don't help either :-)
<kbyrd> zul: you have a chance to look at that email I sent about vmware-player-kernel?
<zul> mjg59: yesterday i think and the new xen crack probably doesnt help
<zul> kbyrd: i will tonight, i been busy with real life stuff
<zul> i will most difnently upload it during my lunch break
<kbyrd> zul: "real life?" what is this thing?
<zul> kbyrd: as in personal family matter
<kbyrd> zul: I was kidding. Of course I understand real life, many of us don't seem to make enough time for it.
<dholbach> mdke: Installed-Size: [-32468-]  {+2120+}
<doko> Kamion: ia32-libs-gtk is the last one for dapper-updates
<dholbach> mdke: and the source package .tar.gz is about twice as big - anything we can add to the "remove it" list?
<mdke> dholbach: don't think so, the package is bigger than the dapper package?
<dholbach> mdke: the source tarball, the package is WAY smaller
<dholbach> -rw-r--r-- 1 daniel daniel 5999074 2006-05-29 15:09 ubuntu-docs_6.06.1_all.deb
<dholbach> -rw-r--r-- 1 daniel daniel  313432 2006-08-02 17:19 /var/cache/pbuilder/result/ubuntu-docs_6.08.1_all.deb
<G0SUB> nags: I don't see hno here
<nags> G0SUB: heno ?
<dholbach> -rw-r--r-- 1 daniel daniel  6728888 2006-05-29 14:08 ubuntu-docs_6.06.1.tar.gz
<dholbach> -rw-r--r-- 1 daniel daniel 15653321 2006-08-02 17:15 ubuntu-docs_6.08.1.tar.gz
<G0SUB> heno: ping
<G0SUB> nags: ah
<G0SUB> dholbach: hello :)
<nags> G0SUB: :D
<dholbach> hello G0SUB
<heno> nags, G0SUB: pong
<mdke> dholbach: ok, a few things.
<nags> hi heno 
<G0SUB> heno, dholbach: meet nags, he is the lead developer of Linux Desktop Testing Project
<mdke> dholbach: shall I add them to the repo or do you want me to tell you them?
<G0SUB> ldtp.freedesktop.org
<nags> heno: I sent you a mail few days back, cc G0SUB 
<nags> hi dholbach :)
<dholbach> hi nags! :)
<Kamion> doko: ok
<dholbach> mdke: you can tell me in a query and i'll add them and send it to you in a diff
<mdke> ok
<heno> nags: looks cool
<nags> dholbach / heno : Few info about LDTP...
<nags> LDTP is used by Sun China team in their solaris platform
<nags> also by Palm Source in their embedded hardware based on GTK+ application
<nags> Recently LDTP getting integrated with Jhbuild and GNOME Tinderbox
<doko> dholbach, seb128: totem-xine is currently uninstallable in dapper-updates (amd64)
<nags> http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi
<dholbach> doko: what does apt-get say?
<doko> dholbach: I'm updating OOo first ...
<dholbach> ok
<nags> http://www.0d.be/2006/07/25/integrating-ldtp-into-jhbuild/
<nags> http://tieguy.org/blog/2006/07/26/little-bits-of-awesomeness/
<nags> also we have automation scripts for Evolution and Gedit
<heno> nags: have you spoken with sfllaw, our testing guru?
<nags> heno: no, let me ping him
<sfllaw> Hi.
<nags> sfllaw: Hi
<nags> sfllaw: kindly go through my above messages :)
<nags> heno: Thanks, guiding me :)
<sfllaw> That's pretty neat.
<sfllaw> cr3 has been looking into Autotest as of late.
<sfllaw> Using the accessibility libraries to do automatic testing is an interesting idea.
<nags> sfllaw: ya :)
<sfllaw> You'll certainly find out whenever the accessibility stuff breaks!
<nags> sfllaw: yes you are right
<nags> sfllaw: we have filed some important bugs in bgo
<nags> sfllaw: we would like to collaborate with Ubuntu team :)
<sfllaw> That would be excellent!
<nags> sfllaw: Kindly guide me, how to proceed in this regard...
<sfllaw> Let me get you in touch with cr3 (Marc) who is doing lots of this automated testing stuff.
<nags> sfllaw: okay
<nags> sfllaw: Sure, thanks :)
<sfllaw> Uhm.  He's out to lunch.
<sfllaw> Speaking of which, I should be doing that too.
<sfllaw> :)
<sfllaw> Will you be online for a while?
<nags> sfllaw: sure :)
<sfllaw> If not, e-mail marc.tardif@ubuntu.com
<sfllaw> Ah, OK.
<nags> sfllaw: I will wait :)
<sfllaw> I've sent him a message.
<sfllaw> He should join #ubuntu-devel when he gets back.
<dholbach> which reminds me, i wanted to update dogtail again
<sfllaw> Then we can talk.
<sfllaw> Meanwhile, I have parcels to retrieve and groceries to buy.
<nags> sfllaw: its just 9:25 PM here, I will go to sleep after 11:30 PM
<sfllaw> Ah.
<sfllaw> 12:07 here.
<nags> sfllaw: sure, will wait...
<nags> sfllaw: okay
<dholbach> can somebody of the buildd admins tell me why the totem 1.4.3-0ubuntu1 (dapper-updates) builds on sparc, amd64, powerpc, hppa broke because of libnautilus-extension-dev not being installable?
<Lathiat> is libnautilus-extension-dev installable on hppa?
<dholbach> doko: i think that's what you meant. ^
<dholbach> Lathiat: on amd64: http://librarian.launchpad.net/3718725/buildlog_ubuntu-dapper-amd64.totem_1.4.3-0ubuntu1_FAILEDTOBUILD.txt.gz
<Lathiat> dholbach: then what you said was confusing
<Lathiat> ;p
<dholbach> Lathiat: it's the same problem in all the cases - for some weird reason, it just worked on ia64 and i386
<dholbach> Lathiat: really?
<Lathiat> oh i see
<Lathiat> its ambiguous if you sortof skim read it
<Lathiat> nvm :)
<dholbach> ok
<dholbach> :-)
<Lathiat> i was reading "builds" as the act of building not the sortof "objects" of building
<Lathiat> anyway.. ;)
<dholbach> similar breakage of gnome-panel 2.14.3-0ubuntu1 on sparc
<bddebian> Sparc?  Who cares about Sparc? ;-P
<zul> sparc users and fabbione for one..
<dholbach> the problem is, that it's dapper stable, not wonky edgy
<pitti> Riddell: can you please bzr the latest hal version?
<pitti> Riddell: I'll try to sanitize the scripts in the near future
<Riddell> pitti: oh yes, forgot about that
<infinity> dholbach: Just looks like the uploads were poorly-timed.  A retry of all of them seems to be working fine.
* dholbach hugs infinity ecstatically
<dholbach> THANKS :)
* mvo hugs infinity too (just in case)
<LaserJock> hmm, good idea. Maybe we just need to be hugging the archive admins every time a build goes through :-)
<bddebian> :-)
<nags> cr3: Hi
<cr3> nags: hi
<cr3> sfllaw: did I miss everything?
<nags> cr3: was chatting with sfllaw 
<nags> cr3: and I was telling him about LDTP and also would like to collaborate with Ubuntu team...
<nags> brb
<cr3> nags: I am somewhat familiar with LDTP, only enough to have tried it to test firefox and gedit. I like how it works with accessibility to test applications programmatically, very cool project.
<infinity> dholbach: All better now.  Thanks for the heads-up.  (That was breaking the livefs builds on powerpc too, I just noticed, so yay for fixing that)
* dholbach hugs infinity :)
<dholbach> it's the HUG DAY
<nags> cr3: Thanks :)
<infinity> Laser_away: I'm not sure I could handle that many hugs.
<infinity> Laser_away: And, really, I only have eyes for dholbach and mvo.
<nags> cr3: Casanova did Tinderbox integration as part of GNOME + Google SoC. He has also completed basic sanity tests for Evolution
<dholbach> hihi :)
<cr3> nags: nice!
<nags> Casanova: ping
<seb128> doko, dholbach: totem ftbfsed on some archs because of instability of nautilus (eel, nautilus have been updated to dapper-updates too and need to build first)
<dholbach> seb128: infinity gave back and we're (soon) all good again.
<doko> ok
<dholbach> in the meantime we have to live with bugs like bug 54957
<Ubugtu> Malone bug 54957 in totem "update totem (1.4.3-0ubuntu1) has broken totem-xine-firefox-plugin" [Medium,Needs info]  http://launchpad.net/bugs/54957
<Chipzz> seb128: how can totem ftbfsed because of instability of a GUI program?
<seb128> dholbach: ok, looks like I'm of no use nowadays around :p
<LaserJock> dholbach: and perhaps emails on -devel
<Chipzz> how is a GUI program involved in building other programs?
<thom> Chipzz: libnautilus
<seb128> Chipzz: nautilus has a libnautilus-extension
<Chipzz> yes, but you should *link* to that, not run it...
<doko> Kamion: please process ia32-libs-gtk for dapper-updates. sorry, I'm nagging, so I can announce the OOo 2.0.3 packages for testing ...
<dholbach> seb128: what do you mean?
<seb128> Chipzz: I was speaking to people who understand what I say without have to type a 15 chars lib name long
<seb128> dholbach: every time sombody ask me I question you have replied before I read my IRC :p
<seb128> s/have/having
<Chipzz> seb128: are you calling me stupid?
<Chipzz> seb128: I have been building gnome from cvs since pre 2.0
<seb128> Chipzz: "<Chipzz> how is a GUI program involved in building other programs?", obviously you didn't what I was saying
<Chipzz> I *know* what libnautilus-extension is
<Chipzz> seb128: that's because nautilus doesn't run during the build of totem
<Chipzz> seb128: and because you *link* against libnautilus-extension, but you do not actually *run* the resulting program in the build
<thom> Chipzz: you're aware that library api/abi can be unstable, right?
<seb128> Chipzz: as I said, I wrote nautilus because it's short than libnautilus-extension1 and people I was talking too understand what I mean by it
<mjg59> Let's try that upload one more time
<Chipzz> seb128: what you said was wrong; you should have said *api* instability
<seb128> Chipzz: k, so make it clear for you "libnautilus-extension-dev needs to be installable to build totem because totem uses it for the audio,video properties page"
<Kamion> seb128: nautilus is still in unapproved; do I need to process it urgently?
<Chipzz> and when I ask clarification because *you* said something *wrong*, I prefer not to be called stupid
<Chipzz> thank you very much
<Chipzz> sjeesh
<seb128> Kamion: no, it should run fine with the eel2 which has been accepted
<seb128> Kamion: I've not looked into details yet, just came back and dholbach told it's alright now, I think it was just eel which built on i386 but not amd64 yet
<seb128> Chipzz: again, I was speaking to people who understand what I mean
<Kamion> doko: libpixman1 was removed (though no changelog); was it moved to another ia32-libs-* package? if so, does that package need a Replaces?
<doko> Kamion: no, it vanished to or came from universe. it shouldn't have been in the package in the first place.
<Kamion> doko: fair enough - accepted
<doko> the edgy package does have the changelog; forgot it here.
<Chipzz> seb128: I normally DO understand; but what you said did not make much sense; ergo I ask for clarification
<dholbach> rodarvus, fabbione, infinity: bug 54648 and bug 52657 would require your genius and X knowledge :-)
<Ubugtu> Malone bug 54648 in glade "glade-2 won't start, gives X BadValue error (edgy)" [Medium,Needs info]  http://launchpad.net/bugs/54648
<Ubugtu> Malone bug 52657 in evolution "X Windows error when running 2.7.4" [Medium,Needs info]  http://launchpad.net/bugs/52657
<doko> Kamion: what the best approach to compare package sizes between dapper-proposed and dapper-updates (if we decide to include it)
<seb128> Chipzz: alright, no problem :)
<rodarvus> dholbach, I've seen them
<rodarvus> both bugs look quite strange :)
<doko> Kamion, Keybuk, mdz: approval of ia32-libs-scim in NEW for edgy would be nice as well for OOo testing
<pitti> does anyone feel responsible for the vmware-player-kernel-2.6.15 dapper-security upload?
<pitti> Changed-By: VMware Build Team <vmware-build@vmware.com>
* seb128 points mvo and dholbach
* dholbach points to mvo and BenC
<mvo> pitti: I can do this
<seb128> see, mvo is the master
* seb128 hugs mvo
<pitti> mvo: this team is not really a team in launchpad
<pitti> mvo: do these guys really have upload privs to jackass, or did you sponsor this?
<mvo> pitti: I just sponsor it
<pitti> ok
<pitti> mvo: it was a regression from the last kernel security update?
<zul> pitti: yes me
<zul> pitti: i uploaded it
<pitti> ok
<zul> it contains a fix for people who want to use module-assitant
* pitti releases it
<mvo> zul: did you got it from vmware? is this the fix for #49924,
<zul> mvo: yes i got it from vmware
<mvo> zul: ah, nice! so this is there version -9?
<zul> i believe so, i was talking to kbyrd about it
<kbyrd> yes, it is.
<mvo> nice, thanks zul, kbyrd
<zul> no probs
<kbyrd> Should I not put us in the changelog since we don't upload?
<kbyrd> If someone could verify (besides me) and close that bug, I'd appreciate it.
<rubikcube> dunno if I'm right here, but is there a reason why in the LaTeX docs lshort is delivered only as pdf, not as dvi?
<pitti> rubikcube: there's not much reason to ship the documentation in ten different formats IMHO
<pitti> PDF should be fine as a default, and since the source is available, you can easily generate other formats if you wish
<rubikcube> yes, but I thought that dvi should be the canonical format
<rubikcube> ok, I see, the dvi version seems to have font problems *hmpf*  
<Riddell> how do I setup a locale in a chroot?
<Riddell> dpkg-reconfigure locales  doesn't seem to do very much
<Kamion> Riddell: locale-gen <locale identifier>
<bddebian> locale-gen..
<bddebian> Oh whoops
<bddebian> Shit I can't tell where I'm at on the merges list anymore.. :-(
<Riddell> thanks Kamion 
<Kamion> doko: the copyright file for ia32-libs-scim is completely wrong; could you correct it?
<doko> Kamion: ouch ... yes, copied from another package ...
<doko> we should generate the copyright file ...
<rodarvus> who usually sends the ubuntu-core-devel meeting announcements?
<rodarvus> next one is 12 hours from now and there is no sign of it on ubuntu-devel-announce@ yet
<ogra_thin> rodarvus, sfllaw iirc
<sfllaw> I do.
<sfllaw> I just got back from the post office.
<sfllaw> And it's about time to.
<rodarvus> nice, thanks!
<bluefoxicy> so 1) wtf bootloader is on the Dapper CDs; 2) Why doesn't Grub look that freaking leet
<Kamion> 1) syslinux+gfxboot 2) because we haven't ported the grub/gfxboot patches from suse yet
<Kamion> and would require some care not to conflict with quieten-grub anyway
<bluefoxicy> Kamion:  ah.
<ogra> Kamion, if you dont mind, i just uploaded a new willowng to the NEW queue, would you take a look ?
<ogra_thin> hmm, why can i exec update-manager as unprivileged user ? and why is it even in the menu ?
<rubikcube> ogra_thin: can you also actually update something?
<ogra_thin> i'm up to date, but i can hit refresh and it works ...
<ogra_thin> it doesnt from the commandline though
<ogra_thin> but well, i'll wait until mvo returns
<msikma> Hey guys. I'm a participant of the Ubuntu Artwork team and would like to edit a metacity theme to propose changes to the default Human style for Edgy. But I've never done it before. Anybody know any good documentation on it?
<dholbach> msikma: you could check some of the existing themes
<dholbach> about documentation, i don't know, sorry
<ogra_thin> i think havoc pennington had a nice howto, but i dont know how recent it is
<msikma> Yeah, I downloaded a nice theme called Chiro which I would like to fool around with. It's just a window border. It appears to be an XML file, but it's still not quite straightforward.
<ogra_thin> http://developer.gnome.org/doc/tutorials/metacity/metacity-themes.html
<msikma> Thanks!
<ogra_thin> but beware that might be very old
<mikearthur> 2.6.17-5.16 = kernel source 2.6.17.16 or 2.6.17.5?
<msikma> This is _very_ nice. Even if it's old, it will come in handy.
<msikma> Ah, copyright 2002.
<gnomefreak> mikearthur: first you asked in 3 channels each channel is the wrong place to ask. 2nd this is not a support channel. Please join #ubuntu+1 and ask
<mikearthur> gnomefreak: sorry, thanks
<dholbach> have a nice evening
<zul> c ya dholbach 
<dholbach> bye zul
<pitti> Kamion: ping
<Kamion> ogra: willowng done
<Kamion> pitti: yes?
* ogra_thin hugs Kamion 
<pitti> Kamion: the new langpacks for dapper are finally in the archive
<pitti> Kamion: and I did a size comparison chart
<pitti> http://people.ubuntu.com/~pitti/tmp/langpacksize-dapper.txt <= original CDs
<pitti> http://people.ubuntu.com/~pitti/tmp/langpacksize-dapper-newbase-20060801.txt <= current langpacks
<pitti> Kamion: so, luckily they didn't grow too much
<Kamion> about 3MB up on the set we use for the CDs :-/
<pitti> Kamion: the top 11 languages grew by 2.5 MB
<pitti> yep, we probably have to drop one
<Kamion> yeah, silbs didn't seem happy with that possibility
<mjg59> Could people test the latest usplash?
<pitti> Kamion: however, it is difficult to know in advance since I don't know the size diff of the other packages
<Kamion> I did a build this morning, IIRC after I accepted those langpacks
<pitti> Kamion: will we roll a test CD before the official one?
<pitti> Kamion: oh, the packs didn't enter the archive until some hours ago
<pitti> building them took some time
<pitti> Kamion: test CD so that we can precisely calculate how many to drop
<crimsun> mjg59: as in suspend-to-{disk,ram} -> resume? I can try in a bit.
<mjg59> crimsun: Well, whether it works at all to begin with :)
<Kamion> hmm, no, I caught it in the middle
<Kamion> pitti: kicking off livefs builds now
<pitti> Kamion: ok, then I'll adjust the seeds accordingly tomorrow morning?
<Kamion> mdz: could I get a judgement call from you? we may have to drop German language packs from the powerpc desktop CD for the dapper point release
<Kamion> mdz: silbs didn't seem massively happy about it, but I can't think what else to do
<mdz> Kamion: what grew?
<pitti> mdz: mainly the langpacks themselves
<pitti> by 2.5 MB for en to de (top 11)
<mdz> ah, hmm
<Kamion> I already dropped xh
<Kamion> but that wasn't all that big
<mdz> Kamion: it doesn't bother me if we need to drop it
<mdz> only powerpc, right?
<pitti> not that we had much choice :)
<Kamion> i386 can be rescued easily (it has lots of langpacks); xh de are next in line for amd64
<Kamion> mdz: I'm not sure
<Kamion> mdz: apparently powerpc had problems burning for some people even in dapper; it was below what I understood the real size limit to be, but above 700MB, and I've had reports of some software/media (unsure which) not liking that
<mjg59> mdz: I stuffed the necessary svgalib stuff in usplash, so we can drop the main inclusion
<pitti> mjg59: *hug*
<mdz> mjg59: I saw, thank you
<mdz> mjg59: did you and/or Keybuk sort out the device node issue?
<Kamion> but if you check http://cdimage.ubuntu.com/daily-live/20060802/, they're all a bit over
<mjg59> mdz: Oh, good point
<mjg59> mdz: No, I had a locally hacked script here
<mjg59> I'll fix that for the next upload
<Kamion> that's with old l-p-*-base and new l-p-* though due to an accident of timing, which is pretty much pessimal
<pitti> Kamion: oh, btw, will we do new alternate images, too?
<Kamion> pitti: yes, already started building those
<Kamion> http://cdimage.ubuntu.com/daily/20060802/
<Kamion> no size problems there for Ubuntu at least
<pitti> they look good
<pitti> Kamion: ok, I'll look at the latest ones tomorrow morning and adjust
<Kamion> I might need to try to engineer a different build directory for dapper - it would really be preferable to keep building edgy at the moment
<Kamion> anyway, I need to go offline for a short while to test why my phone line is non-functional; if I don't come back, then it's more hosed than I'm hoping ...
<Kamion> oh, whoops, can't do that while the livefses are building, so postponed ...
<pitti> Kamion: no screen? :)
<lamont> Kamion: will the new dapper ppc iso be one that I can burn onto 700MB media using dapper?
<gnomefreak> who updated the usplash?
<HiddenWolf> that'd be mjg59
<gnomefreak> it died
* HiddenWolf puts on a requiem for the unlucky program
<Kamion> lamont: that's the plan ...
<Kamion> pitti: more relevantly I didn't ssh somewhere ex-ADSL before kicking off the six subsidiary ssh connections
<Kamion> bddebian: FWIW you don't need to mention that Ubuntu changes can be dropped if the current Ubuntu version doesn't contain "ubuntu"; the sync script ignores buildN
<Kamion> Ubuntu changes <=> version contains "ubuntu"
<bddebian> Kamion: OK, sorry
<Kamion> no need to be sorry, as it doesn't cause us extra work if you do say that; I just wanted to save you the effort of saying it in future :-)
<bddebian> Well I actually ran across one where someone changed a build dep but still called it buildX :-(
<Kamion> bddebian: lovely
<Kamion> that can be ok if you're absolutely certain that it can be synced next time, I guess, but it's not very good form
<cjb> Hi.  Is there any chance of getting -mtune=generic support in edgy's gcc?
<bddebian> Aye
<icecrash> hi
<bddebian> Hello icecrash
<icecrash> i'm currently working on a customized server image
<icecrash> having problems with cdimage
<icecrash> anyone with deeper experience in that?
<icecrash> two problems exists
<icecrash> during the anonymous ftp sync, the rsync process will not sync the dists part of the ubuntu archive, so the debian-installer part that follows fails
<icecrash> do I have a chance to work with this suite with a partly mirror only containing i386 debs?
<Kamion> icecrash: what do you mean "will not sync"?
<Kamion> it syncs the entire archive in the first pass
<icecrash> so I thought
<icecrash> I setupped a partly mirror with 
<Kamion> it may well make sense to do it with debmirror or something plus a few custom rsyncs - anonftpsync in there is just what we use inside the datacentre where bandwidth isn't a huge issue
<Kamion> debmirror and manually sync in dists/blah/main/installer-*
<icecrash> debmirror ${LOCAL_ARCHIVE} --progress --host=${REMOTE_SERVER}  \
<icecrash>  --root=${REMOTE_ROOT} --dist=${DISTS} --section=${SECTIONS} \
<icecrash> --method=rsync --arch=${ARCHES} -v --nomd5sums
<icecrash> syncing against fr.archive.ubuntu.com
<Kamion> you might need a few --ignore options as well - debian-cd will probably want you to rsync in doc, indices, tools
<Kamion> been a while (> 2 years) since I did this using my local mirror though :-)
<icecrash> ok, but I have no probs to sync more than I need
<icecrash> :)
<Kamion> right, but it's nice not to clobber the datacentre with excess load during a week where we're pushing out a lot of dapper updates
<icecrash> syncing for dists=dapper,dapper-updates,dapper-security
<Kamion> though you could always pull from a mirror
<Kamion> (and probably should, if possible)
<icecrash> ok
<pygi> anyone could poke for me do we get shared libs with libburn package?
<mjg59> So, what should I do about resolution setting in the NEW! IMPROVED! usplash?
<Chipzz> new, improved, AND invisible!
<Chipzz> s/invisible/broken/ :P
<mjg59> Well, currently
<mjg59> But that's not the point
<Chipzz> so what /is/ the point? ;)
<mjg59> < mjg59> So, what should I do about resolution setting in the NEW!  IMPROVED! usplash?
<gnomefreak> it looked small on shutdown and not there on boot
<mc44> keep it at 640x400 just for kicks
<Chipzz> well if I'ld know what you meant... ;)
<Chipzz> gnomefreak: exactly ;)
<mjg59> The resolutions it can use on x86 and amd64 are limited to the ones in the vesa bios
<pygi> gnomefreak, any chance you  could look for me? my upstream build system fails to build shared libs and seems like debian packages does
* gnomefreak has very limited res
<pygi> bleh =P
<mjg59> So should we (a) stick to something fairly safe like 800x600, or (b) grab the closest to the X configuration?
<pygi> mjg59, a :)
<gnomefreak> b
<^ohoel> I see there's a new sled-menu-ish project going on the forums
<gnomefreak> b = safest way that way as long as they have X they should beable to view it
<gnomefreak> pygi: what did you want me to do?
<bluefoxicy> mjg59:  stick to something 800x600 and make it use a million colors :D
<pygi> gnomefreak, check if we get shared libs with libburn package :)
<mjg59> Colour depth is an uninteresting problem
<bluefoxicy> mjg59:  actually I've been admiring Gentoo's 2006.0 install CD.  It switches into a graphical boot-up with icons like MacOS used to show
<bluefoxicy> and the graphic is ... well, eye candy :P
<mjg59> This is also an uninteresting issue right now
<bluefoxicy> MASSIVE eye candy
<mjg59> I provide mechanism, not policy
<bluefoxicy> ah
<mc44> mjg59: cant you just steal the resolution from whatever is in xorg conf?
<bluefoxicy> why not provide mechanism for (b) with a mechanism to override
<gnomefreak> you get nothing with it pygi 
<mjg59> mc44: I can 
<Chipzz> but why use X? X can take several seconds to start...
<mjg59> Chipzz: What?
<pygi> gnomefreak, bleh, oki :P
<crimsun> mjg59: I think it's early enough that stealing the resolution is worth trying.
<Chipzz> mjg59: you read what I said
<mjg59> Chipzz: We're not using X
<Chipzz> mjg59: I thought that was under consideration?
<mjg59> Chipzz: No
<Chipzz> apologies then
<Amaranth> mjg59: I would think using a resolution from xorg.conf would be good
<bluefoxicy> heh, I suggested on -devel@ using Kdrive's VESA server for graphical boot-up
<Chipzz> mjg59: btw, what you said about vesa is incorrect btw
<Amaranth> mjg59: you know the monitor can show those resolutions
<mjg59> Chipzz: Which bit?
<bluefoxicy> and someone was like" If I get X I'm drawing a log-in screen"
<dabear> hi, just on question, does edgy's metacity have composite enabled?
<Amaranth> dabear: no, it's buggy
<Chipzz> svgalib can use modelines in the same format as X uses them, to get arbitrary resolutions
<mjg59> Chipzz: Not through vesa
<mjg59> Or, at least, not on most vesa systems
<mjg59> Very little implements GTF
<Chipzz> mjg59: vesa is also a mostly a non-issue
<mjg59> Chipzz: WTF are you talking about?
<Chipzz> what you are referring to is actually vesa 2.0
<mjg59> Yes
<gnomefreak> vesa is the most widely used
<Chipzz> vesa 1.2 (which a lot of older cards use) is not at all usable
<mjg59> Which is pretty much all that's widely implemented
<mjg59> Chipzz: Practically any piece of hardware that can run Ubuntu has VBE 2.0
<mjg59> (or greater)
<Chipzz> mjg59: all 1MB and 2MB trident and trio etc cards implement vesa 1.2
<mjg59> I'm utterly failing to care
<mjg59> Especially since svgalib can cope with segmented framebuffers /anyway/
<Chipzz> and on the cards that do support vesa, you have framebuffer drivers too (so can use directfb or such)
<mjg59> Chipzz: No, we /don't/
<mjg59> Because then suspend/resume stops working
<Chipzz> ugh :/
<mjg59> Since almost none of them know how to reprogram the framebuffer from scratch
<mjg59> So doing this without a framebuffer is massively preferable right now
<mc44> mjg59: will you need to have lots of artwork at different resolutions if you nick the value from X?
<dabear> is there any written standard on what has to be done on a product to increment the main/second version number?
<mjg59> mc44: We'll see
<doko> Kamion: uploaded ia32-libs-scim_2 again with the updated copyright. seems, that *nobody* did update *any* of the ia32-libs* packages that after the initial creation of the package :-/
<Kamion> ok, thanks
<Kamion> will look tonight
* Kamion is trying to get the ubiquity-advanced-partitioner backend going before the meeting ...
<mdeslaur> +
#ubuntu-devel 2006-08-03
<icecrash> are there so much md5 problems on the different mirrors?
<icecrash> working with the same debmirror setup, parts fail on the first mirror, parts fail on the next
<icecrash> ???
<Chipzz> hrrrrm
<Chipzz> chipzz    5299  0.0  0.0   4476   732 ?        Ss   Aug02   0:00 /usr/bin/ssh-agent /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
<mjg59> Kamion: I want a configuration file with two values in it. What's the sanest format to parse?
<Kamion> mjg59: from C?
<mjg59> Kamion: Yeah
<mjg59> Kamion: I want to put x and y values for usplash resolution in initramfs
<Kamion> mjg59: avoid foo=bar, people will think it's shell syntax (see pam_env)
<mjg59> Indeed
<Kamion> mjg59: I'd go for 'xresolution FOO\nyresolution BAR\n' personally
<mjg59> Ok
<Kamion> and # at start of lines to introduce comments
<mjg59> This isn't going to be doable in four lines, is it?
<Kamion> probably not
<Kamion> should be doable in a couple of dozen though
<mjg59> The alternative would be to use read to grab the values and then pass them to usplash on the command line
<Kamion> if you're doing that in shell, you could 
<Kamion> just use a sourced file
<Kamion> (ignore spurious newline there)
<mjg59> Oh, true
<mjg59> Yeah, I'll do that
<mjg59> So
<mjg59> I want to populate the config file with information from the X autoconfiguration stuff
<mjg59> Which ought to be in debconf
<Kamion> please don't read debconf for that - reading xorg.conf is preferable
<Kamion> I know it's a bit harder, but
<mjg59> Seriously?
<mjg59> Ouch
<Kamion> the information in debconf isn't canonical - people are entitled to modify xorg.conf by hand
<mjg59> Actually, I don't believe that it's possible to do that
<mjg59> The default resolution in xorg.conf might be outside the limits of the hardware
<mjg59> That is, after user modification
<Kamion> won't X break too then?
<mjg59> But it should be in limits at the point where X is autoconfigured
<mjg59> No
<mjg59> X will drop modes it doesn't think it can display and fall back
<Kamion> what will X do?
<Kamion> can usplash do the same?
<mjg59> No
<Kamion> X's autoconfiguration does get it annoyingly wrong sometimes
<Kamion> also, usplash needs to not fuck up if the debconf database disappears
<mjg59> Ngh.
<Kamion> or if the debconf db is on /var which isn't mounted yet, for example
<mjg59> Yes.
<mjg59> I was planning on using the debconf data to write the default config file
<Kamion> I suppose you could fetch it from debconf iff you did it in usplash.postinst
<Kamion> yeah
<mjg59> Which would then be user modifiable
<Kamion> that would be less bad, provided you had a fallback in case X isn't tere
<Kamion> there
<Kamion> or in case those debconf questions have disappeared
<Kamion> usplash can be installed without X, so ...
<mjg59> Yeah
<mjg59> In that case, just fall back to 640x480
<Kamion> mjg59: or 640x400 maybe?
<icecrash> Kamion: one questions if it's ok
<icecrash> how much space is necessary to rebuild a complete set of cds?
<mjg59> Kamion: Not a vesa mode
<icecrash> as the cdimage runs a complete rsync, more than 150 seems to be clear
<Kamion> mjg59: ah, plain VGA support is gone?
<Kamion> icecrash: mirror size plus about 2GB for amd64/i386/powerpc alternate install CD
<Kamion> oh, no
<Kamion> sorry, more like 4GB
<Kamion> unpacked ISO size plus packed ISO size
<Kamion> I can't easily give mirror figures for just one release
<icecrash> 150gb  is the size that the mirrors print out as ubuntu repos size
<mjg59> Kamion: For now - we'll see if it's needed for a fallback
<Kamion> a full main+restricted mirror is 69GB at present
<icecrash> and universe is not delivered :)
<icecrash> perfect
<Kamion> the entire archive is about 200GB
<icecrash> if there are any plans to move over to a python implementation of cdimage, after my session, I offer help :)
<icecrash> its a really huge process
<nictuku> hi, just FYI, /usr/share/fonts/X11/misc does not have "fonts.dir". mkfontdir is enough to fix it
<desrt> heh. cute usplash screen.
<dabear> has it changed again?
<desrt> it looks like a test pattern
<dabear> could you take a screenie w/ a camera or something?
<icecrash> good night
<desrt> dabear; http://desrt.mcmaster.ca/random/test-pattern.jpeg
<desrt> looks like we have some nice high-res usplash business
<jdub> looks like the old one; is it in the centre of your screen without stretching (now that it's using svgalib)?
<desrt> i expect so
<desrt> let me reboot again and take a better look
<desrt> i only get it at the very end of the shutdown, though
<desrt> not at startup and not during the initial part of the shutdown
<desrt> the 1:1 square seems square....
<tseng> hi desrt 
<tseng> I am fixing muine now
<desrt> tseng; upstream?
<tseng> no, your upload failed to build
<tseng> missing build-dep, not your fault
<desrt> seriously?
<desrt> ah.
<desrt> i wonder how we got away with that in dapper
<tseng> because dapper has cli-common
<tseng> edgy has cli-common, cli-common-dev
<tseng> split.
<desrt> make: dh_makeclilibs: Command not found
<tseng> you got it.
<desrt> tsk tsk tsk
<desrt> oh my.  looks like it will rain tonight
<desrt> edgy's grub works with macbook
<desrt> love.
* desrt kicks lilo out
<desrt> somehow lilo takes about 10x (seriously) as long to load the kernel off the disk as grub does
<desrt> jdub; is that normal or should i be concerned?
<tseng> desrt: neat.
<jdub> desrt: you probably don't have 'compact' in your lilo config
<desrt> jdub; actually, i did
<tseng> desrt: word, thunderstorm
<tseng> just hit me
<desrt> :)
<desrt> it's windy as all hell here
<tseng> we are going between 100 degree heat and thunderstorms
<desrt> jdub; i mean the usplash thing... is it normal for it to only show for a few seconds just before reboot and not any other time
<sladen> desrt: no, it should show on bootup and on shutdown
<desrt> yay.  something else to look into :D
<jdub> desrt: oh; no, but it is a pretty new version (multiple uploads, finally built) and it has been a bit rough in edgy already, so...
<desrt> yay.  something less to look into :D
<desrt> *** stack smashing detected ***: /usr/bin/whiptail terminated
* desrt eyebrow raise
<tseng> send that bug to pitti, i think
<desrt> more like a whiptail bug, i think
<tseng> well, its a whiptail bug discovered by ssp most likely
<tseng> muine uploaded
<desrt> definitely.
<tseng> I got sidetracked
<desrt> cool
<tseng> it should build now
<bddebian> Howdy
<tseng> hello
<bddebian> Heya tseng
<Kamion> BenC: any luck on the dapper kernel upload?
<Kamion> ogra: please try to avoid deleting old dapper-updates changelog entries in future (gnome-screensaver 2.14.3-0ubuntu1 lost the changelog from gnome-screensaver 2.14.2-0ubuntu1)
<bddebian> Kamion: Hush up and get syncing.. ;-P
<jdub>    * Make svgalib shut up
<jdub>    * Create necessary device nodes in initramfs startup
<jdub>    * Autoconfigure the resolution where possible
<jdub> ^ usplash upload from mjg59 
<jdub> AUTOCONFIGURE THE RESOLUTION WHERE POSSIBLE
<tseng> woo
<mjg59> It might even work
<mjg59> (does here)
<Kamion> bddebian: it's 2:30 am, sod off :P
<Amaranth> i guess i don't get to enjoy the new bootup bling :/
<bddebian> Ah, it's early then
<Amaranth> ah well, i don't restart that much
<mjg59> Amaranth: Mm?
<Amaranth> mjg59: i get no usplash love
<mjg59> Amaranth: Why not?
<Amaranth> mjg59: I dunno, I get a blinking underscore then text boot
<jdub> $ pbuilder build --basetgz /var/cache/pbuilder/dapper.tgz mugshot_1.1.13-0ubuntu1.dsc
<jdub> E: File /var/cache/pbuilder/hoary.tgz does not exist
<jdub> ^ ?!
<LaserJock> hehe
<crimsun> pass --configfile foo to it
<crimsun> (presuming you used one)
<ajmitch> hoary? that's awhile ago now
<LaserJock> last time jdub build a package, apparently ;-)
<LaserJock> *built
<jdub> no, i've been trying to fix pbuilder on my machine
<jdub> so i killed everything
<crimsun> too bad, I miss the "naked people."
<jdub> and built a dapper pbuilder basetgz
<jdub> which was called hoary.tgz for some reason
<jdub> i renamed it
<jdub> and now it's b0rk
<BenC> Kamion: uploading in about 10 minutes
<jdub> no pbuilder config file refers to hoary
* jdub greps /var/cache/pbuilder
<crimsun> jdub: gotta use --override-config, then
<jdub> no config refers to hoary
<jdub> and it fails in the same way if i hadd that
<jdub> s/hadd/add/
<jdub> $ grep -rl hoary /etc/pbuilder* | wc -l
<jdub> 0
<crimsun> well, the hacky way is to change BASETGZ in /etc/pbuilderrc
<jdub> BASETGZ=/var/cache/pbuilder/base.tgz
<jdub> doesn't even refer to that :)
<jdub> (also now there's an /etc/pbuilder/pbuilderrc too)
<jdub> oh
<jdub> which is just a link
<desrt> bah.  usplash makes sleep/wake unstable
<desrt> lame.
<jdub> even changing that doesn't work
<jdub> oh
<jdub> ha ha ha
<jdub> ~/bin/pbuilder -> GAR!
<Kamion> BenC: thanks
<Kamion> BenC: I'll stay up then :)
<crimsun> heh, my next question.
* jdub fixes, builds
<BenC> grr...this box is so stupid
<BenC> it crashes if I don't have a head on it, and boots perfect if I do
<BenC> how the hell am I supposed to see how it's crashing if it does that
<BenC> it boots even if I connect a serial console
<desrt> BenC; do you know of any other bugs in the kernel where it can't properly calculate the number of bogomips?  i'm sort of stuck on where to go next on this bug i'm hunting
<BenC> do you really need bogomips to me accurate, considering it's not really accurate by nature?
<BenC> s/to me/to be/
<desrt> yes
<desrt> bogomips is used to calibrate delay loops
<desrt> which are used by usleep() msleep() etc
<BenC> bogomips changes whether you run 2.2, 2.4 or 2.6 kernels and even sometimes changes in between
<desrt> and at bootup the kernel does a test to make sure the timer IRQ is working
<desrt> it msleep()s for a bit and makes sure the right number of timer IRQs were delivered
<desrt> if your bogomips count is wrong then the kernel panics because it assumes your timer hardware is borked
<BenC> what does that have to do with bogomips though?
<desrt> it does something like this:
<BenC> haven't heard anything regarding that
<desrt> c = jiffies;
<desrt> msleep(a while);
<desrt> c = c - jiffies;
<desrt> or jiffies -c, even.
<desrt> then makes sure c is within the expected range
<desrt> so if msleep is inaccurate the kernel gets very unhappy
<desrt> see https://launchpad.net/bugs/54621
<Ubugtu> Malone bug 54621 in linux-source-2.6.17 "Kernel panic - not syncing: IO-APIC + timer doesn't work!" [Untriaged,Unconfirmed]  
<BenC> Kamion: kernel upload away
<BenC> sounds like it isn't related to bogomips
<BenC> I've seen a similar bug and it's related to something else
<desrt> it's definitely related to bogomips
<BenC> desrt: brb
<desrt> giving lpj= on the commandline fixes it
<desrt> (loops per jiffy -- manual delay loop calibration, ie: you tell it how many BogoMIPS you have because it can't detect it for itself)
<desrt> tseng; rain starting here just now
<bddebian> tseng: Warm enough for ya today? ;-P
* desrt falls back to the best debugging technique ever -- copypasting chunks of dmesg into google
* bddebian always thought printf() was the be all end all of debugging tools? :-)
<desrt> well... liberal use of printk brought me this far :)
<bddebian> Ah :-)
<bddebian> No wonder I'm not cool enough for core-devs :-)
<mjg59> desrt: Code change around 2.6.17 changed the default timer
<desrt> mjg59; this happened both before and after
<mjg59> desrt: Ok
<BenC> desrt: is your system using calibrate_delay_direct() or the manual way to calibrate lpj?
<mjg59> desrt: Also, it says "Boot with apic=debug" and then you say "acpi=debug gives no extra output"
<mjg59> apic != acpi
<desrt> BenC; it's using the manual for now.... when it uses the calibrate_delay_loop() it sometimes fails
<mjg59> Typo?
<desrt> mjg59; ya..... :)
<desrt> mjg59; definitely typo
<BenC> desrt: so manual works?
<desrt> mjg59; i just don't know if i made the typo into lilo or not :)
<desrt> BenC; ya.  i add the lpj= commandline option and all is well
<mjg59> So it's the "8254 timer not connected to apic" bit that's exploding
<desrt> ya.... it uses a bogomips-calibrated delay loop to wait for some timer IRQs to come in
<desrt> and if the wrong number comes in it assumes the timer IRQ is miswired
<mjg59> Right
<desrt> of course, if the delay loop is miscalibrated this will also cause the wrong number
<mjg59> Yes
<mjg59> I think this is an lkml job
<BenC> desrt: by manual I mean the part in calibrate_delay(), the last if
<mjg59> desrt: I wonder why other people don't seem to be getting bitten by this...
<BenC> desrt: if you hardcode the calibrate_delay_loop() bit to be skipped, and let it fall through, does it work?
<mjg59> desrt: It's always possible that your hardware is fucked in some bizarre subtle way
<desrt> mjg59; some #gnome-hackers guy is
<BenC> that's what I was thinking
<desrt> mjg59; a fellow macbook owner
<mjg59> Oh, fun
<BenC> macbook
<mjg59> Ok
<desrt> mjg59; in fact, he gets bitten by it more frequently than i do
<BenC> that's what I was thinking
<mjg59> Maybe a run of bad ones :p
<BenC> desrt: is this dapper or edgy?
<desrt> both
<mjg59> desrt: Have you tried booting with different timer= values?
<desrt> no...
<desrt> like, instead of HPET?
<mjg59> Yeah
<mjg59> Try tsc or pmtimer
<desrt> i never understood why tsc wasn't used more often....
<BenC> desrt: test one of these: http://people.ubuntu.com/~bcollins/kernels/mvo-dazuko/
<mjg59> There's something weird about HPET and Linux in the DSDT
<BenC> there's a timer fix in there for macbook
<desrt> The requested URL /~bcollins/kernels/mvo-dazuko was not found on this server.
<mjg59> desrt: Because it's a bastard to keep in sync on multiple-CPU machines
<zul> hey
<BenC> drop one subdir and see what's in kernels/
<desrt> -test
<mjg59> BenC: Have you got the patch somewhere?
<desrt> oh.  i no longer have dapper on the box.
<desrt> but it happened in dapper too
<BenC> desrt: you'll have to wait for an edgy kernel with that fix
<BenC> try the dapper one, it should still boot fine
<BenC> atleast tell you if things work correctly
<BenC> http://people.ubuntu.com/~bcollins/kernels/mvo-dazuko-test/
<desrt> k.
<BenC> that's exactly the kernel I just uploaded to dapper-security
<desrt> lemme take it for a spin :)
<Kamion> BenC: oh, dapper-security - it'll need pitti to publish it then
<Kamion> drat, that's slower :)
<Kamion> oh well, will nudge him tomorrow morning
<desrt> failing that, i'll try mjg59's ideas
<mdz> mjg59: should we switch to using the ondemand governor instead of powernowd?
<desrt> YES YES YES
<mjg59> mdz: On machines where it works, yes
<BenC> mjg59: it was cherry picked from upstream
<mdz> mjg59: what's hardware-specific about it?
<mjg59> mdz: It needs to know latancy figures
<mjg59> Not all cpufreq modules provide that
<mjg59> I'm heading to bed - any feedback on usplash would be good
<mjg59> It works here now, anyway
<desrt> mjg59; it doesn't work for me
<mjg59> desrt: 0.4-5
<desrt> how new is this?
<mjg59> Uploaded, not built yet
<desrt> gotcha.
<desrt> fwiw, fbcon prevents sleep from working properly here
<mjg59> Which fbcon?
<mjg59> Just any framebuffer at all?
<desrt> intel?
<desrt> it's my dumb macbook acting out again :)
<mjg59> Oh
<mjg59> We don't use that by default, right?
<desrt> oh.  btw
<desrt> vbestate and acpid are still inverted in rc2.d
<desrt> plz fix
<mjg59> Oh, bleah, yes.
<mjg59> It's only a problem because laptop-detect doesn't work for you
<desrt> BenC; no love
<desrt> BenC; booted fine a couple of times and then on the 3rd try failed
<BenC> desrt: was the bogo's the same each time?
<BenC> desrt: how far off is the value it's giving you?
<desrt> BenC; uhm...
<desrt> 4519.06 is the sum
<BenC> what are you passing?
<desrt> and CPU1 is always detected correctly at 3994.7
<desrt> so it just detected 524 bogomips
<mjg59> desrt: Can you give the other timer options a go?
<desrt> mjg59; sure will
<mjg59> Rock
<BenC> yeah, sounds like it's just not using the right timer source or something
<desrt> i  have decided that edgy will run perfectly on the macbook
<BenC> desrt: so when it boots ok, is the bogo's right, or it just happens not to affect it?
<desrt> BenFrom a successful boot:
<desrt> [17179570.588000]  Total of 2 processors activated (6485.23 BogoMIPS).
<desrt> this should be more like 7[something] 
<desrt> so no... they're not perfect
<desrt> just close enough that it's not enough to cause the timer-irq code to break
<BenC> desrt: it's odd that the bogo's are different from boot-to-boot on the same kernel
<desrt> BenC; it's because of the "calibrate_delay_direct() failed to get a good estimate for loops_per_jiffy.  Probably due to long platform interrupts."
<desrt> the kernel knows that it got a bad bogomips count
<BenC> ah, so it falls through to the crappy estimate code
<desrt> i guess?
* desrt isn't very familiar with the exact technique used
<BenC> you're the one with the printk's :)
<desrt> i didn't printk that part :)
<BenC> for shame :)
<desrt> lemme try mjg59's ideas
<desrt> you know that bit about "seeing if WP bit is honoured in supervisor mode"
<desrt> the HPET stuff comes just after that
<desrt> and sometimes (seems unrelated to if bogomips is accurate or not, actually) it pauses for a _very_ long time there
<desrt> like 5-10 seconds
<desrt> eep.  using tsc is no help.
<bluefoxicy> https://wiki.ubuntu.com/QuietenGrub disturbs me; the idea behind it seems to be, "The user may be curious about a message that appears for all of 1 second and means nothing just as the computer turns on; so we should hide this"
<bluefoxicy> the machine displays a lot of words and numbers when it's first turned on; worrying that the user may get confused by the few Grub and the Linux kernel spit out seems silly.
<BenC> bluefoxicy: it's about a polished look
<bluefoxicy> The only way the user is going to get confused is if they suddenly decide that they care what's going on, even though it's blatantly obvious that it's of no concern to them.
<BenC> for the same reason we default the kernel to "quiet"
<desrt> the grub quiet stuff is _really_ dumb
<zul> i think it looks cool
<bluefoxicy> It doesn't seem to matter from my point of view
<desrt> it replaces "Uncompressing Linux... OK, booting the kernel." with "Booting the operating system now."
<zul> uh...it does more than that
<desrt> and it hardcodes that "Booting" message into grub
<desrt> (can't be turned off)
<bluefoxicy> the user is either going to go "OK words are appearing on the screen it's loading" or go get a can of soda
<desrt> if you want to get rid of messages then get rid of them... by all means
<bluefoxicy> I don't see an actual problem, aside from the user getting nervous that the screen is blank for 5 seconds and thinking "huh the system just sits doing nothing for 5 seconds, I wonder why they never fixed that" (since during that time the hard drive is accessed all of twice)
<bluefoxicy> besides that it just seems like a waste of developer time
<bddebian> So is your bloviating :-)
<bluefoxicy> bloviating, that's a new one for me.
<Burgundavia> 'ello Hobbsee
<zul> bluefoxicy: it was not that hard to implement in the first place 
<Hobbsee> hi all, hi Burgundavia :)
<Hobbsee> hi zul 
<zul> hey hobssee
<bluefoxicy> zul:  shrug
* desrt prefers messages that are meaningful and with well-defined meaning
* bluefoxicy never particularly cared what the messages were, as long as they kept moving; when they stopped he started to worry.
<bddebian> Heya Hobbsee
<Hobbsee> hi bddebian 
<bluefoxicy> particularly when the Linux kernel used to barf half a screen of text, then sit quiet for about 20 seconds on hardware it wasn't quite sure what to do with yet; then finish booting :P
<desrt> anyway.  i have work to be doing :)
<bluefoxicy> Remember, the text on the bootsplash screen is mainly meaningless too.  EVMS?  Mounting disks?  Whassat?  :>
<desrt> about that.... why is evms/raid/lvm/etc/etc initialised on desktops?
<Kamion> desrt: it isn't on fresh edgy installs
<desrt> oh.  sweet.
<desrt> +1
<bluefoxicy> no, it was removed.  Although it's going to cause a problem for upgrades if someone doesn't fix a certain bug.
<Kamion> that'll get fixed, I'm quite certain
<bddebian> Kamion: Damn man, you still haven't gone to sleep?
<Kamion> still beating against the big ubiquity wall, though fading fast
<bluefoxicy> Kamion likes his work :)
* Hobbsee hands Kamion some explosives.
<Hobbsee> Kamion is very good at what he does.
<Hobbsee> the explosives are to aid you in blowing up the big ubitquity wall, not for any other purpose!
<bluefoxicy> Kamion is very good at complaining about needing sleep every night and staying up for hours longer working :)
<Hobbsee> bluefoxicy: arent we all?
<bddebian> Hobbsee: Darn, and here I thought it was for blowing up bluefoxicy ;-)
<zul> not me...i got to bed at a sensible time when i can
<bluefoxicy> zul:  heathen!
<Hobbsee> bddebian: hah.  well....
<Hobbsee> bddebian: now that you mention it...
<zul> bluefoxicy: then i can be crabby in the morning..
<Hobbsee> zul: and very asleep in meetings, yes.
<bluefoxicy> haha, poor Hobbsee :)
<Hobbsee> bluefoxicy: you dont want to know how asleep i was in yesterday's meeting.  and they're asking me complicated questions
<Hobbsee> and i'm thinking "hey now, i could answer you when i'm awake...but while i'm still waking up?  not a chance"
<bluefoxicy> Hobbsee:  Unless a job is at stake I tend to just spurt crap back when that happens
<Hobbsee> bluefoxicy: not a good idea to do to the TB.
<bluefoxicy> if you catch me when I'm asleep I'll be like, "..... wut?  I dunno, go ask stiffler's mom or something there's a crash in the dog processor chupathingy..."
<bluefoxicy> just because I figure if I say something you'll go away
<TheMuso> c
<bluefoxicy> Hobbsee:  I actually can think when my body is out of it; my mind never really sleeps.
<bluefoxicy> now, whether I want to put the energy into controlling my jaw is another story.
<Hobbsee> heh
<Keybuk> Kamion: uh, dude, get out of my time zone ;)
<jsgotangco> thou shalt not malloc another byte
<jsgotangco> lol
<jsgotangco> :D
<Hobbsee> hi Keybuk.  i've got a question about your MoM at some point.
<bluefoxicy> .................... wtf does that stand for
<bddebian> Keybuk!!!
<jsgotangco> bluefoxicy: i was just quoting Keybuk from his email heh
<bluefoxicy> jsgotangco: no I meant Hobbsee asking about urMoM
<jsgotangco> ahhh sorry
<Keybuk> Hobbsee: shoot
<Hobbsee> bluefoxicy: MoM is the merge-o-matic.  see merges.ubuntu.com and then do some of them
<jsgotangco> Merge-o-Matic
<bluefoxicy> ah
<Hobbsee> Keybuk: the merge-buildpackage script - why are we not running that with -rfakeroot anyway?  you either need to do that, or run it as root
<Keybuk> (totally-not-funny-story ... the reason it's called "mom" is because it's a very very very CPU & I/O-using process and I didn't tell elmo about it ...
<Keybuk> so it's argv[0]  was "hi mom!"
<Keybuk> and I backronymed that into "hoary intelligent merge-o-matic"
<Keybuk> for obvious reasons, when breezy was released, it was shortened)
<Keybuk> Hobbsee: you can merge-buildpackage -rfakeroot
<Hobbsee> heh
<Hobbsee> Keybuk: that's what i do.  i'm wondering why it isnt set to do that by default though
<Keybuk> Hobbsee: for the same reason it's not the default for dpkg-buildpackage either ... not everyone uses fakeroot
<Keybuk> I test merges in a chroot, where I'm root, for example
* bddebian doesn't user -rfakeroot usually
<Hobbsee> Keybuk: true.  wonder what happens if you put it in anyway, while running as root.  i keep forgetting the rotten thing.
<Keybuk> Hobbsee: not much
<Keybuk> still works
<Hobbsee> Keybuk: right.
<Keybuk> some people use -rsudo
* Hobbsee looks at this mailing list thread about reviewing...glad something came out of yesterday's meeting :P
<Keybuk> Hobbsee: which mailing list is that on?
<Hobbsee> Keybuk: looks to be MOTU
<ajmitch> which quickly went onto what new packages we should accept into universe, if any
<Hobbsee> ajmitch: true, i'm getting to that.
<bddebian> Heh
<Hobbsee> yay.  Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/edgy/universe/binary-i386/Packages.gz  MD5Sum mismatch
<desrt> Hobbsee; give it 12 seconds and try again :)
<Hobbsee> desrt: heh.  i did.  this uni connection is a bit slow
<sid> From the home page... "Ubuntu is a complete Linux-based operating system, freely available with both community and professional support." Why doesn't it say GNU+Linux or GNU/Linux.
<jdub> sid: we tend to avoid that turf war
<Kamion> in this case we haven't managed to avoid it though, we've picked one side ;)
<Kamion> as jdub said we historically tried to avoid saying either Linux or GNU/Linux
<Kamion> (unless necessary/pertinent)
<Kamion> it's kind of slipped in places though
<bluefoxicy> unlike Gentoo which has Gentoo/Darwin Gentoo/Linux Gentoo/FreeBSD etc etc etc
<jdub> Kamion: hrm, i guess; though this is more a statement of fact than a branding issue ;-)
<sid> eh, Seems important to mention GNU. This project and Debian could be dead by companies like SCO, if it weren't for things like the GPL which has been the MVP in stopping SCO. Someone(*cough*) had to foresight in 1991 to structure the license in a certain way that helps us all.
<sid> Plus we all know how evil the DMCA / Software idea patents are. Seems silly not to mention GNU
<desrt> sid; is this a troll?  why are you using tor?
<sid> I'm not a troll.
<sid> MSG nickserv info sid; my nickserv account wouldn't be this old if I was a troll.
<crimsun> I'm thinking this pedantry is increasingly off-topic.
<sid> I'm just trying to figure out the reasoning for not mentioning GNU. I feel it's important. I thought this is where the web master would be.
<desrt> sid; it's probably not as important as not confusing new users is.  "linux-based", for 98% of the population (who know what linux, gnu/linux or whatever you prefer is at all), means exactly what that page is trying to convey.
<desrt> there is a very large group of people (ubuntu's intended target audience, basically) who grok "linux-based" but would "eh?" at "gnu/linux based"
<Lathiat> ah but rms will hunt you down
<desrt> it may be unfair that "linux" means what it means in the public consciousness... but that's what it means.  in any case, by any definition of the world "linux", it's no lie to say that ubuntu is linux-based.
<desrt> *word
<Burgundavia> Lathiat: smoothered by that beard of his
<Lathiat> ;)
* bluefoxicy switches some fonts in OpenOffice.org from Albany to Arial.  Notices the fonts are pixel-per-pixel identical.
<sid> Well there reference to it in all the install docs --> http://doc.ubuntu.com/ubuntu/install/i386/ch01s03.html
<sid> But a large portion of people never read those. Some one a new user becomes intermediate with Ubuntu. They never learn what GNU is, or the idea of free software.
<sid> s/Some one/So Once/
<bddebian> sid: Well asking RMS wouldn't get you to Debian or Ubuntu either since they allow the evil non-free software
<sid> right
<desrt> sid; ubuntu isn't about lecturing users; by overt means or otherwise.
<sid> Well he would say something like "I use Debian GNU/Linux, but I can't recommend it to others because they have non-free software on their servers"
<sid> heh
<desrt> ya.  it's called BIOS. :p
<sid> desrt: I don't want Ubuntu to be able lecturing users.
<sid> I just wish there was an issues page, that could help users understand better.
<desrt> sounds like a lecture to me :)
<bluefoxicy> Stallman is weird
<desrt> i <3 stallman
<sid> ie, why ffmpeg isn't in Ubuntu. Because there are so many patents surrounding it. And why they can't play drm'd music from their iPod etc.
<bluefoxicy> rather than allow people to control stuff they created; he wants to allow people to control things others create.
<desrt> we want him to come talk at cusec
<desrt> ffmpeg _is_ in ubuntu and i _can_ play drm'd music from my (hypothetical non-existant) ipod :)
<bluefoxicy> If you picked up a copy of gedit and wrote in a modification; then the GNOME team is now able to claim your modification must be released under their licensing terms, or else you are not allowed to distribute it.
<bluefoxicy> Stallman says to not get yourself "trapped" by proprietary software that wants to "take away your rights" and "control you"
<bluefoxicy> It's ironic that the GPL is a trap that aims to take away your rights and control you.
<bluefoxicy> and that's all I'll say on that.
<desrt> nobody ever said that it's public domain.  copyleft is just as evil as copyright
<desrt> it just points in the opposite direction :)
<bluefoxicy> yeah.  Copyright == you controlling your work; copyleft == you controlling others' work.  :)
<sid> desrt: You can play music downloaded from the itunes store that was on your ipod?
<sid> With Ubuntu
<desrt> bluefoxicy; with traditional copyrighted software you wouldn't even be able to modify gedit in the first place
<desrt> sid; ya
<sid> desrt: how?
<desrt> sid; there's some program called harmony or something
<sid> desrt: That would violate the DMCA. And it would be illegal if you're an American.
<desrt> it's broken a few times and they've fixed it again
<desrt> i'm not an american
<desrt> what's the DMCA?
<bluefoxicy> desrt: this is true; but it's not evil of the creator of said software to do that
<sid> Just like playing a DVD in GNU / Linux with libdvdcss is illegal in America.
<desrt> well god bless america.  good thing i don't live there.
<Burgundavia> we are straying off topic for -devel here
<desrt> Burgundavia; very strongly.
<sid> desrt: If there wasn an issues page you would know. ;)
<Burgundavia> then I suggest we take it elsewhere
<sid> Digital Millennium Copyright Act
<Burgundavia> bluefoxicy: as for what you believe about the gpl, this is not the appropriate place to raise them
<desrt> sid; i know.  i don't care.
<sid> It's a act that makes it illegal to circumvent copyright protections schemes. ie DRM
<Burgundavia> sid: thanks for your inquiry as to the gnu/linux vs linux debate. If you want to talk about the DMCA, please take it elsewhere
<bluefoxicy> on closer examination, I simply don't have the "albany" font and OOo is substituting arial
* desrt never understood the problem with wildly off-topic discussions in an otherwise completely dead channel
<bluefoxicy> this is a default font in an OOo template
<bluefoxicy> desrt:  the devs come back to see wtf we're talking about and waste time reading the screen.
<desrt> fair
<bluefoxicy> desrt:  in non-dev channels, yes, it's completely retarded :)
<bluefoxicy> at any rate why don't I have Albany and how do I rectify; and more importantly, should fonts that OOo expects to have around be installed by default?
<bddebian> Gnight folks
<tritium> night, bddebian 
<bddebian> Night tritium
<Kaleo> hello girls and boys
<desrt> good eve
<bluefoxicy> hi pitti
<desrt> pitti; stacksmashing detected in whiptail.  do you want to hear about it?
<pitti> Good morning
<bluefoxicy> desrt:  do you know what function?
<desrt> nope.  i was hoping for some help, if anything
<bluefoxicy> meh.  ProPolice used to blurt out the vulnerable function name, RHAT removed that when they pushed it into gcc mainline
<bluefoxicy> (this is why pitti's crash reporter is going to be awesome)
<jdub> elmo, Znarl, Spads: ping
<jdub> oh man, i can't log into any of the machines now
<jdub> heh
<jdub> the canonical kthxbye ;)
<jdub> if ever there was one
<pitti> desrt: sure, if you can find out anything about it
<desrt> jdub; what was your last day?
<pitti> desrt: too bad that apport currently cannot extract stack traces :(
<desrt> pitti; do you know of some switch i can throw to get some more info?
<jdub> friday
<dholbach> good morning
<jdub> i'm just going to mail rt
<desrt> dholbach; word.
<pitti> hey dholbach 
<dholbach> hey desrt, hey pitti
<dholbach> jdub: heya - how's genius looking? :)
<desrt> you germans wake up early
<jdub> dholbach: genius is looking like i can't upload it to my usual spot :)
<dholbach> jdub: hu? where?
<jdub> dholbach: people.ubuntu.com; no access atm ;)
<dholbach> upload it to the archive!
<dholbach>  !!!
<jdub> well, there is that
<jdub> can i pass it to your or ogra for ongoing maintenance?
<dholbach> yeah
<dholbach> i'm answering for ogra here ;)
<jdub> haha
<jdub> building it in pbuilder atm, will upload after that
<dholbach> rock and roll
* dholbach hugs jdub
<ajmitch> lucky ogra inherits another package
<dholbach> he'll be delighted to add some more good educational software to his CDs
<bluefoxicy> by the way, Tuesday is 8/08/6
<jdub> dholbach: i'm glad you picked up on it for edubuntu, it didn't even occur to me that it would be useul there
<desrt> pitti; newtCheckboxTreeAddItem() calls __stack_chk_fail()
<dholbach> i'd need to play with it a bit, but to me it totally looked like being at the right place :)
<bluefoxicy> desrt:   :)  Bingo.
<bluefoxicy> desrt:  reproduced?
<desrt> bluefoxicy; 100%
<desrt> i get it when running module-assistant on vmware-player
<bluefoxicy> desrt:  now the fun part, screw with it in gdb or elfsh and see if you can find a way to feed it a file and get it to give you a shell ;)
<desrt> or i could just fix the bug
<bluefoxicy> or that yes.  :)
<bluefoxicy> pitti:  do you have a place for automated problem reports to go?
<desrt> found the problem
<pitti> bluefoxicy: right now, it's a manual user decision/task to create a bug  and attach the report
<desrt> if you feed whiptail a string starting with a negative number then that number gets cast to unsigned
<desrt> and becomes very very very large
<bluefoxicy> pitti:  If you want to let the user set it to automatically send reports, you should probably com up with a separate back-end instead of creating a Launchpad bug
<bluefoxicy> pitti:  I would suspect that such a thing would create a MASSIVE influx of bug reports (and duplicates-- every time something breaks), and it would be bad to dilute the bug tracker that way.
<pitti> bluefoxicy: right, we need a separate db for automatic reports
* Hobbsee waves
<pitti> bluefoxicy: that's something for edgy+n, though
<Hobbsee> has anyone tried the new usplash yet?  says /dev/svgasomething not found.
<pitti> bluefoxicy: the intent of the current system is to make the communication easier for people who already send us bugs about crashes
<pitti> Hobbsee: I'm up to date and get the same old 640 by 400 as always
<pitti> bluefoxicy: right, later we need to automatically find duplicates and such
<Hobbsee> pitti: hmmm...okay
<bluefoxicy> pitti:  Yes; I'd think a new Launchpad module would be best, which would indeed be a lot of work and not ready by Edgy.  I have some ides for that, which I've been working on for a while; I'm currently writing up a slide show presentation on that.
<bluefoxicy> pitti:   Yes, duplicates and such are not easy; but I've come up with a technique that I believe will help a lot if you can't fully-auto it.
<Hobbsee> pitti: ah, they released a new version between when i updated an hour and a half ago, to now
* pitti dist-upgrades
<Hobbsee> pitti: from what to what?
<pitti> Hobbsee: to latest edgy
* imbrandon hugs edgy
<Hobbsee> pitti: ahh :)
<Hobbsee> 30.7kB/s download speed.  yay.
<imbrandon> 30kB hehe i would cry
<imbrandon> ;)
<pitti> 355kB/s - hehe :)
<imbrandon> pitti: yea thats about what i get from archive.u.c , 350 to 400
<imbrandon> ;)
<Hobbsee> pitti: it's the uni connection, i cant complain too much.
* Hobbsee was getting about 500 kB/s at home last night.
<desrt> does someone have a few minutes to review and possibly upload a package for me?
* desrt frowns
<Hobbsee> desrt: which package?
<desrt> newt
* Hobbsee isnt saying yes.  as such.
<desrt> do you have upload to main?
<bluefoxicy> desrt:  if you just fixed a security hole make sure it gets back to upstream.
<desrt> bluefoxicy; this isn't a security problem
<desrt> just a plain old crashes
<desrt> *crasher
<Hobbsee> desrt: no.  according to my apt-cache, it isnt in ubuntu at all yet
<desrt> Hobbsee; newt is the source package name
<desrt> binary packages include libnewt0.52 and whiptail
<Hobbsee> desrt: ahh.  i thought apt-cache search found source packages too, for some reason.
<bluefoxicy> desrt:  What triggered the overflow; how far did it overflow; and where did the data come from?
<desrt> ya.  so did i.  i just found out that that's not true :)
<Hobbsee> i think my brain is being dulled by vaguelly listening to the current prac in here.
<desrt> bluefoxicy; you pass an int to a function.  it then puts that many (constant) characters into a fixed-size buffer
<desrt> bluefoxicy; that int can be very very large in some cases
<bluefoxicy> desrt: hole was in libnewt; could any programs using libnewt possibly pass a string they got from a file or such?  i.e. in theory could someone trick a user into loading a file that would write some data from it into that buffer and go off the edge
<desrt> the problem only happens when you ask a gauge to draw a negative percentage
<desrt> if someone is calling that function they ought to verify that the value they pass it is sane
<desrt> even still, i fixed the crash in two places to be extra safe
<bluefoxicy> mm.
<bluefoxicy> whatever. :p
<bluefoxicy> I don't feel like arguing theory and gorey non-existent details.  It's fixed, it's fixed.
<bluefoxicy> (come to think of it, I didn't ask the source of the characters; if they're internal to libnewt then yeah not a vulnerability for sure)
<desrt> arf
* desrt files a bug and hopes someone eventually looks at it
<bluefoxicy> narf ^o.o^
<Lathiat> .look. at bugs.?
<Hobbsee> Lathiat: no.  looking at bugs is illegal.  actually fixing bugs is a criminal offense.
<Lathiat> thats why everyone does it right? RIGHT!?
<Lathiat> its illegal must be fun woooooooooooo ;)
<Hobbsee> Lathiat: what gives you the idea that people fix bugs?  :P
<Lathiat> good intentions? ;p
<desrt> https://launchpad.net/distros/ubuntu/+source/newt/+bug/55017
<Ubugtu> Malone bug 55017 in newt "whiptail --gauge crashes when given negative numbers" [Untriaged,Unconfirmed]  
<desrt> if anyone cares to look :p
<Lathiat> desrt: easy fix
<Lathiat> desrt: dont give it negative numbers ;)
<desrt> Lathiat; the problem is taht programs pipe their output to it
<bluefoxicy> Hobbsee: "But when a long Train of Abuses and Usurpations, pursuing invariably the same Object, evinces a Design to reduce them under absolute Despotism, it is their Right, it is their Duty, to throw off such Government, and to provide new Guards for their future Security."
<Lathiat> see im fixing bugs already :)
<Lathiat> desrt: ;p
<bluefoxicy> Hobbsee:  ^^^ Why people fix bugs
<desrt> and one of the outputs was a big line that ended with a kernel version
<desrt> and the -686 wrapped to the next line
<Lathiat> heh
<Hobbsee> Lathiat: haha
<Lathiat> awesome
<Hobbsee> bluefoxicy: scary.
<bluefoxicy> Hobbsee:  US declaration of independence
<bluefoxicy> it means that people who have the power to correct a wrongful situation also have the responsibility to correct said wrongful situation
<Hobbsee> bluefoxicy: ah, right.
* Hobbsee doesnt follow US politics.
* dholbach collects some crack pipes in here :)
* Hobbsee doesnt even follow her own country's politics
<Hobbsee> hi dholbach!
<desrt> dholbach could upload for me!
<dholbach> hey Hobbsee
<Hobbsee> hehe
<desrt> hi dholbach :)
<dholbach> desrt: what is it? :)
<desrt> https://launchpad.net/distros/ubuntu/+source/newt/+bug/55017
<TheMuso> Hobbsee: Neither do I.
<Ubugtu> Malone bug 55017 in newt "whiptail --gauge crashes when given negative numbers" [Untriaged,Unconfirmed]  
<dholbach> desrt: i don't upload no kernel :)
<bluefoxicy> your diff scares me
<bluefoxicy> it has ++ lines
<bluefoxicy> like a diff of a diff
<desrt> it's a debdiff
<desrt> and it contains a patch
<bluefoxicy> ah
<bluefoxicy> oh right.  that confuses me.
<Hobbsee> bluefoxicy: debdiff's are good.
<Hobbsee> bluefoxicy: learn to like them
<desrt> bluefoxicy; they're the de facto way to get someone to do an upload for you
<Hobbsee> desrt: better than source.
<bluefoxicy> yes I fed one to mdz and pitti
<desrt> source is so big :)
* Hobbsee takes debdiff's over sources any day of the week, for reviewing.
<desrt> man.  le tigre.
<desrt> who took the bomp?
<StevenK> The only thing I dislike over debdiffs is the diff of a diff.
<desrt> StevenK; imagine, then, diffing the two .diff.gz files
<StevenK> Done that.
<desrt> +++
<ajmitch> desrt: interdiff is a great tool, really
<desrt> it's enough to make your modem hang up
<desrt> ajmitch; first time i tried to use debdiff i didn't have interdiff installed.  that was lame :)
<Hobbsee> hehe
* Hobbsee still found something more evil than that.
<StevenK> desrt: Only if its a crappy one that doesn't understand escapes sequences.
<desrt> StevenK; joke, k plz thx
<StevenK> desrt: I have seen some that will see '+++' in an input stream and disconnect.
<desrt> my friend has the modern-day equivalent problem with his ISP-provided router
<desrt> if you /msg him a DCC SEND someverylongstringlikethis on irc he disconnects
<StevenK> Heh
<dholbach> hahahaha, I didn't have  dbs  installed - my machine was sane :)
<Hobbsee> desrt: gah.  dont joke about that.
<HrdwrBoB> desrt: you don't have to msg it
<HrdwrBoB> you just say it
<desrt> well, at the start of a line
<desrt> that's still a privmsg
<tritium> desrt: ask ubotu about dcc
<Hobbsee> desrt: actually, i'm suprised you didnt disconnect anyone doing that.
<desrt> dholbach; eh?
<desrt> Hobbsee; fairly sure it has to be at the start of the line
<dholbach> desrt: the dbs package
* Hobbsee considers testing.
<desrt> Hobbsee; i don't think that's necessary
<StevenK> Muahaha
<Hobbsee> desrt: could be interesting.  /me tests in -ops
<desrt> asshat :p
<Hobbsee> [15:49]  <Hobbsee> desrt: they're just clones - they got redirected here from #ubuntu the last time someone ran the exploit
<Hobbsee> heh
<desrt> ah
<Hobbsee> okay, that works anywhere in the line.
<desrt> didn't work for me, tho
<TheMuso> Hobbsee: What was the result?
<Hobbsee> desrt: means there's no people with the dodgy router brands then
<Hobbsee> TheMuso: see -bugs
<Hobbsee> desrt: in here, anyway
<desrt> nice
<desrt> my router is vuln to that bug, but i don't use it as a router
<desrt> wifi access point only
<dholbach> desrt: uploaded - do you care enough to send it upstream?
<desrt> dholbach; it looks vaguely orphaned in debian
<desrt> dholbach; but i'll drop a mail to the guy who did the last NMU
<desrt> dholbach; thanks
<dholbach> oh, i was more referring to fedora (seems to be a project of them) - but to send it to debian is a good thing too
* dholbach hugs desrt
<desrt> :)
<desrt> dholbach; will you close the bug or should i?
<dholbach> desrt: go ahead :)
<desrt> crikey thunder!
<desrt> bah.  the email address of the redhat guy bounces
<desrt> bed time.  cheers.
<dholbach> good night desrt and thanks for the fix
<desrt> thanks for the rapid upload :)
<dholbach> anytime - if i hear any complaints, i'll wake you up ;)
<desrt> unlikely.
<dholbach> :)
<desrt> in any case i'll be awake again in almost exactly 8 hours :)
<dholbach> enjoy
<desrt> cha.
<dholbach> ogra*: jdub will upload genius soonish and asked us to take over maintenance
<ogra> yup, saw it in my backlog :) thanks ! :)
<ogra> /var/lib/dpkg/info/usplash.postinst: line 40: /dev/fd/62: No such file or directory
<ogra> Keybuk, whats supposed to create that fd ?
<dholbach> ogra: i think mjg59's newest upload takes care of that
<dholbach> ogra: cf edgy-changes
<ogra> ah, k so my udev isnt missing something, thanks :)
* ogra has no /dev/fd/ at all in his ltsp chroot ...
<Keybuk> ogra: /dev/fd should be a symlink to /proc/self/fd
<ogra> Keybuk, there is no proc in a non booted ltsp chroot
<Keybuk> ogra: then lots of things will be broken
<ogra> its mounted on boot on the client
<Keybuk> right, but you need /proc to upgrade it
<ogra> and temporary during chroot creation
<ogra> hmm ... cant it have just some error catching ? 
<ogra> i dont think its needed by the package during package install time ... only at runtime, no ?
<ogra> mjg59, ^^ ?
<Keybuk> ogra: I doubt that's the only thing that will break because /proc isn't mounted
<Keybuk> little things stop working
<Keybuk> like ps, pidof, shells, etc.
<ogra> Keybuk, th ethin client mounts proc 
<Keybuk> yes, but package postinsts are entirely permitted to need /proc, because they expect a POSIX system
<ogra> but if i upgrade the client chroot there is no proc ....
<Keybuk> then that's a bug, you need to mount /proc while you upgrade the client chroot
<ogra> hmm ... then i need a wrapper :/
<Keybuk> /proc/$PID (and thus /dev/fd -> /proc/self/fd) is used in a few places
<Keybuk> and many things use pidof/ps
<ogra> yes, i know why we use it in the build script ... i just havent had probs yet when upgrading 
<ogra> its the first package i see requirig it
<Keybuk> openssh-server does
<ogra> i dont use the server in th echroot :)
<bluefoxicy> hmm.  I wonder if my presentation needs polish.  Probably.
<bluefoxicy> Not that it matters, I'm not nutty enough to try to sneak into the next developer's summit; and there's no friggin' way I'd ever actually present.  You know.  In front of a group of like, real, live people.
<sivang> morning
<bluefoxicy> hi... Mr. *
<Hobbsee> hi all
<pitti> desrt: thanks for the newt patch
<pitti> desrt: was this an upstream or Debian-inherited bug?
<caleb-> seb128: About edgy bug #54956. Most GTK immodules can not be fixed by rebuild only. Default installation is /usr/lib/gtk-2.0/immodules/, but debian packages used to change to /usr/lib/gtk-2.0/2.4.0/immodules/. So every GTK immodule package will need a new *.diff.gz for the 2.4.0 -> 2.10.0 transition.
<Ubugtu> Malone bug 54956 in gtk+2.0 "Wrong path name 2.10.0, should be 2.4.0 for back-compatibility" [Untriaged,Rejected]  http://launchpad.net/bugs/54956
<seb128> caleb-: and?
<pitti> Kamion: ok, so we need to get off 6 MB from powerpc and 3 from amd64/i386; that'll kill pt and ru for powerpc (pt is a bit unfortunate, but we can't help it)
<Kamion> de and ja are further down the list for powerpc
<bluefoxicy> I'm gonna sleep, night all.
<caleb-> seb128: and maintainer have to do more work for backporting.
<pitti> Kamion: but they aren't in the current seeds
<Kamion> seems like they should be first to go ...
<pitti> Kamion: right, but powerpc has zh es bn hi ar xh pt ru ATM
<pitti> Kamion: did you already took some away since yesterday?
<pitti> s/took/take/
<seb128> caleb-: I don't get your issue, I fixed those packages when updating them, no?
<Kamion> I'm updating to check
* pitti cannot see commits
<seb128> caleb-: I've you looked at the uploads or that's just random comment?
<Kamion> pitti: read the live seed again
<pitti> Kamion: argh, my bad
<Kamion> there's a stanza which affects only some architectures, which I think you missed
* pitti engages his brain
* Hobbsee stole it.
<pitti> Kamion: right, that'll give us exactly 6 MB; I hope it'll be just enough
<caleb-> seb128: OK. I recheck them again.
<bluefoxicy> hobbsee@hobbsee:~$ ./exploit pitti --steal-brain
<pitti> !
<Hobbsee> hehe
<Kamion> pitti: ok, thans
<Kamion> +k
<pitti> Kamion: if this will still overflow by a few KB, would it hurt much to do yet another image?
<Kamion> pitti: not a problem
<Kamion> pitti: have you approved the new kernel already?
<pitti> Kamion: I hoped to get hoary and breezy, too
<pitti> Kamion: but if we need it now, I'll split the USN
<Kamion> well, it's either now or it's not in the point release
<Kamion> I don't actually mind which
<pitti> ok, then let's do it now
* pitti releases
<pitti> Kamion: what do you think about cups 1.2.2? something for the CD, or rather not? (it's in the dapper queue, mdz approved the upload)
<Kamion> printing has been a major bugbear with dapper.0; if this stands a chance of fixing several high-profile issues then I'm all for it
<pitti> yes, it does
<Kamion> need to make sure it's tested before release though
<caleb-> seb128: They will work well in edgy, but will fail when backporting to dapper.
<pitti> Kamion: well, we only tested it in edgy so far
<caleb-> seb128: dapper can not recognize those GTK immodules in 2.10.0
<pitti> Kamion: (well, of course I tested it in dapper, too, but only me)
<seb128> caleb-: those are edgy uploads, so everything is fine
<seb128> caleb-: no need to backport that on dapper
<seb128> caleb-: packages are made for current versions, if backport doesn't work that's something for the backport-team
<pitti> Kamion: dapper live seed updated
<pitti> Kamion: with a potentially new OOo it'll be a moving target anyway
<ogra> you change the daper seeds ????
<ogra> *dapper
<pitti> ogra: removed langpacks to fix overflow
<caleb-> seb128: OK, I wll discuss with backport-team. Thank you. :-)
<ogra> you know that could make edubuntu explode ?
<seb128> caleb-: np
<pitti> ogra: sure, we might have to remove some langpacks from edubutun, too
<ogra> erm
<ogra> the install CD only has en
<ogra> if that grew we're screwed
<pitti> ogra: ubuntu installs are okay
<pitti> ogra: they didn't seem to have grown significantly
<ogra> i'm talking abour edubuntu with 699MB 
<ogra> *about
<Kamion> ogra: stop panicking, Edubuntu dapper still has different seeds from Ubuntu dapper
<Kamion> pitti changing Ubuntu dapper seeds (which is FINE, stop PANICKING :-)) doesn't affect Edubuntu
<ogra> Kamion, but the same package contents ...
<Kamion> yes, Edubuntu dapper may have to be changed somehow
<ogra> if the packages grew it will explode
<Kamion> it had very few language packs though
<ogra> exactly
<Kamion> and it's mostly language packs that have grown
<Kamion> ogra: welcome to life
<pitti> Kamion: you have both gnome and KDE -en, right?
<Hobbsee> Kamion: if you're dealing with removing packages from the archive/cds/whatever, feel free to remove kdelibs-bin and amarok-arts from the repositories.
<ogra> heh, we never had a pointrelease before :)
<Kamion> Hobbsee: please file a bug with ubuntu-archive subscribed if there isn't one already
<pitti> ogra: gnome+kde+rest -en grew by 2085918 bytes
<Hobbsee> Kamion: right.  one bug for two packages, or one bug for each package?
<ogra> pitti, might aready be to much ... i'll ave to check
<Kamion> pitti: edubuntu? yes
<Kamion> pitti: only en on alternate, but loads on desktop
<pitti> Kamion: sorry, that question should have gone to ogra
<Kamion> edubuntu desktop will be dead easy to shrink
<ogra> yes ...
<ogra> but install will get tricky
<ogra> i wouldnt want to drop any app in a pointrelease
<Kamion> it seems to me that language-pack-kde-en could be removed without much badness
<ogra> contents shouldnt differ etc ...
<Kamion> it's not affecting the desktop, only a few apps; we're probably carrying a lot of KDE desktop translations in there that aren't used in Edubuntu
<ogra> i'm not sure kdeedu will like that
<pitti> ^ this would buy you 3 MB
<Kamion> it's -en for goodness' sake!
<Kamion> surely it will just fall back to C and all will be well ...
<ogra> we can try ...
<Riddell> it will yes
* pitti wonders why the -en packs are so big in the first place
<Kamion> and even if a few translations are a bit wonky, that seems ok if it's just kdeedu
<Kamion> pitti: freaks translating to en_EVERYTHING I guess :-/
<pitti> C -> en_US translation should be 95% identical, and those few en_GB strings shouln't be so big...
<Kamion> losing en_GB from kdeedu on edubuntu is not a big deal
<jdub> pitti: en_ZA is pretty big, with all that "off" -> "orf" and so on.
<Kamion> mvo: how does language-selector decide which sets of language packs to install?
<pitti> jdub: right, and 'Welcome' -> 'Yo dude!'
<pitti> ^ for en_AU
<pitti> hey kagou 
<kagou> hey pitti !
<kagou> pitti: what's up ?
<mvo> Kamion: you mean if it should install "-kde", "-gnome"- packs? that is detected via the installed packages
<Kamion> mvo: so if language-pack-kde-en isn't installed on Edubuntu any more, then it won't know to install any language-pack-kde-*?
<nags> G0SUB, as part of Google SoC - Prashanth Mohan has done these two work...Evolution calendar automation - http://people.freedesktop.org/~prashmohan/evolution-calendar-low.avi and http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi - Jhbuild / Tinderbox - LDTP integration
<pitti> mvo: it should detect that it's missing and offer to complete language support, right?
<Kamion> pitti: wouldn't want to offer to install language-pack-kde-* on Ubuntu
<Kamion> or -gnome-* on Kubuntu
<pitti> well, if you have the 'other' apps installed, it will AFAIK
<mvo> Kamion: it will detect missing langpacks by checking if key-dependencies are installed and offer to install them
<Riddell> presumably it test for kdelibs/some gnome lib being installed, mvo?
<Kamion> mvo: aha, I should go look at the source then
<mvo> Riddell: yes
<ogra> then its fine
<mvo> Kamion: it stopped working for you?
<Kamion> mvo: no, just checking that the change discussed above won't make language-selector go wonky
<ogra> mvo, no, but i'll likely hve to drop the kde-en packs from edubuntu
<mvo> ogra: that should be fine, on the next start of language-selector it should come up with a dialog offering to install them
<ogra> (in the dapper pointrelease)
<mvo> we did that with firefox locales too
<ogra> fine :)
<mvo> but obviously it should be tested :)
<mvo> but I'm pretty confident
<Kamion> mvo: apart from the minor detail that kdelibs4c2 does not exist in dapper
<Kamion> which appears to be your key package for language-pack-kde-*
<mvo> *gar*
<Hobbsee> Kamion: use kdelibs4c2a instead
* mvo prepares a updtaed upload
<Kamion> can we use a binary package whose name won't change as often?
<Kamion> kdelibs-bin?
<ogra> cant we put a wildcard in ? 
<ogra> kdelibs*
<Kamion> oh, no, not kdelibs-bin
<Hobbsee> Kamion: kdelibs-bin is going to die.
<Kamion> ogra: smallest change possible for -updates, can be fixed better for edgy
<Hobbsee> Kamion: dont depend anything on it, or i'll have to change it again.
<ogra> yep
<pitti> kdelibs-data ?
<Kamion> kdelibs-data looks good
<Hobbsee> oh, wait, not sure on dapper.
<pitti> ^ dependency of kdelibs4c*
<mvo> pitti: sounds good
<Kamion> Hobbsee: yeah, was just reading the package list a bit too quickly
<pitti> Hobbsee: in dapper, too
<Hobbsee> pitti: my statement was more i wasnt sure if we were killing off kdelibs-bin in dapper too - we certainly did in edgy.
<Kamion> Hobbsee: we're not killing off any packages in dapper
<Kamion> short of being sued
<Hobbsee> Kamion: heh
<pitti> Hobbsee: ah, right; indeed in dapper kdelibs4c2a depens on -bin
<pitti> but let's use -data for edgy/dapper consistency
<Hobbsee> pitti: yeah.  it's dying. lovely circular dependancy. i just havent filed a bug report getting it out of the archive yet :P
<mvo> Kamion: I will do a upload with that fix to dapper-updates now
<Hobbsee> pitti: the circular dependancy is still in dapper.  guess we'd better keep it in then
<Kamion> mvo: while you're at it, in edgy s/libgnome2-0/libgnome2-common/g would be good too, for similar reasons
<Kamion> don't need to change that in dapper though
<mvo> Kamion: ok
<pitti> zul: ping
* Kamion hacks cdimage to start putting dapper builds in cdimage.u.c/dapper/ cdimage.u.c/kubuntu/dapper/ etc.
<Kamion> then I can turn edgy builds back on
<Kamion> mvo: don't you need to change LanguageSelector/gtk/GtkLanguageSelector.py too?
<Kamion> ./LanguageSelector/LangCache.py:        ("kdelibs-data", "language-pack-kde-"),
<Kamion> ./LanguageSelector/gtk/GtkLanguageSelector.py:        ("kdelibs4c2", "language-pack-kde-"),
<Hobbsee> Kamion: filed those two removal bugs.  thanks :)
<Kamion> mdz: -DISTRIB_DESCRIPTION="Ubuntu 6.06 LTS"
<Kamion> +DISTRIB_DESCRIPTION="Ubuntu 6.06.1 LTS"
<Kamion> mdz: this is ok, right?
<mvo> Kamion: *cry* right
<mvo> Kamion: please reject the last upload
<mdz> Kamion: yes
<mdz> Kamion: do you need anything from me before I sleep?
<Hobbsee> mdz: fixes for all the bugs in the archive.  :P have a good sleep :)
<Kamion> mdz: no, I don't think so - sleep well
<Kamion> mvo: done
* mvo cheers bloody-stupid duplication
<Kamion> I did wonder about that one :)
<mvo> Kamion: it was a left-over from the late addition of the Qt frontend and not properly cleaned up
* mvo grabs a brown paperbag and goes to bed again
<caleb-> seb128: tamil-gtk2im also needs rebuild for 2.4.0 -> 2.10.0. Those rebuilded immodules all work fine in edgy. Thank you. :-)
<seb128> caleb-: I've updated it yesterday but it had a build issue, it's on my "to fix" list
<seb128> caleb-: np ;)
<nags> heno, http://people.freedesktop.org/~prashmohan/evolution-calendar-low.avi
<nags> heno, http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi
<nags> heno,  Aspart of Google SoC - Evolution calendar automation and Jhbuild / Tinderbox - LDTP integration
<nags> heno, will ping you on Monday, going out of town...
<heno> nags: ok, I'll look at those in the meantime, thanks
<nags> heno, sure :)
<mvo> Kamion: uploaded again, this time (hopefully) correct
<mdke> pitti: 
<mdke> RicardoPerez has reported a problem with langpacks
<mdke> 9:58:22 < RicardoPerez> mdke: I think the langpacks generation procedure is using obsolete Rosetta's templates
<mdke> can you help with that?
<RicardoPerez> mdke: thanks a lot. I didn't ask him yet because he appears away ;)
<mdke> oh yeah, my bad
<pitti> mdz: hm, that rather sounds like problem for carlos
<pitti> erm, mdz: ^ please ignore
<pitti> RicardoPerez, mdz: hm, that rather sounds like problem for carlos
<pitti> RicardoPerez: so Rosetta doesn't use dapper's current template?
<pitti> +s
<RicardoPerez> pitti: hi, I don't know if the problem is in the Rosetta or in the langpack generation...
<RicardoPerez> pitti: ok, that's right
<pitti> RicardoPerez: Rosetta does the msgmerge between .po data and pot files
<RicardoPerez> pitti: mmmm, better said, the langpack generation isn't use the latest Rosetta's templates
<RicardoPerez> pitti: for example, the gnome-panel-2.0 template is empty in Rosetta, but has full of translated strings in the .mo file installed in my system
<pitti> RicardoPerez: but you are sure you looked at dapper's templates, not at edgy's?
<RicardoPerez> pitti: absolutely. I'm looking at the dapper's templates
<pitti> hm, let's wait until carlos arrives
<RicardoPerez> pitti: https://launchpad.net/distros/ubuntu/dapper/+source/gnome-panel/+pots/gnome-panel-2.0/es_ES/+translate
<RicardoPerez> pitti: I'm writing now a post for ubuntu-translators with all the details
<RicardoPerez> pitti: The post is in the mailing list now: https://lists.ubuntu.com/archives/ubuntu-translators/2006-August/000745.html
<pitti> thanks
<RicardoPerez> pitti: thanks to you, hope this helps
<pitti> so, the very latest (yesterday's) dapper langpacks are wrong?
<RicardoPerez> pitti: exactly. the problem appears with the lastest langpack updates
<RicardoPerez> pitti: until yesterday, there was no problem
<seb128_> pitti: carlos in on VAC this week
<Kamion> try danilos
<RicardoPerez> pitti: can you rebuild the es_* langpacks again to ensure that you are using the latest templates from Rosetta?
<pitti> RicardoPerez: can you please check out today's daily langpacks from my people.u.c. page, around 1300 UTC?
<RicardoPerez> pitti: ok, sure... are your daily langpacks working now? I remember there was an issue with that...
<pitti> RicardoPerez: yes, the apt-ftparchive bug has been worked around
<pitti> RicardoPerez: and I just re-enabled dapper langpack building
<pitti> RicardoPerez: (I stopped dapper until we got the rebased packages into the archive)
<RicardoPerez> pitti: ok, superb. is this the correct apt line? deb http://people.ubuntu.com/~pitti/langpacks/daily/dapper-updates ./
<pitti> yep
<RicardoPerez> pitti: ok, I'll wait the updates, I'll try it at 1300 UTC and I'll tell you
<RicardoPerez> pitti: thanks a lot
<hanswerner> Hey there :)  Is there a way to get fonts working in Edgy-X?
<hanswerner> I just updated because I needed a new QT4 for developing - Fonts a screwed but I think it's a known problem. Can I help fixing it or is there a way to get `em running again?
<hanswerner> no way?
<mvo> infinity: can you kick the python-apt build once the new apt (0.6.45ubuntu1) has build please? 
<thom> is anyone else having problems connecting to security. or is it just me?
<pitti> thom: hm, doesn't seem to work for me either
<tepsipakki> thom: it's been sluggish for a couple of days..
<elmo> security's currently running into bandwidth limits, it'll be slow, but should work
<doko> Kamion: OOo ping
<Kamion> doko: hi
<Kamion> doko: have you got much in the way of test reports from your dapper-proposed binaries?
<doko> Kamion: no feedback yet
<Kamion> that's awkward
<Kamion> how about I build alternate install CDs with -proposed for a bit?
<Kamion> can't fudge desktop CDs so easily, but that would get us some testing at least
<doko> Kamion: that would be very nice
<doko> is there a way to determine the delta in size for the new CD's? before building them?
<Kamion> there is, but it's probably less effort just to build the alternate install CD and find out
<Kamion> which I'm doing now
<Kamion> I mean you can sum all the Size fields by hand and do arithmetic
<doko> hmm, ok, I'll wait :)
<Kamion> in fact, not necessarily too evil to do in shell ...
<pitti> doko: I have such a script for the language packs, should be trivial to adapt for other packages
<doko> ohh, nice, please email
<pitti> doko: http://people.ubuntu.com/~pitti/bzr/langpack-o-matic/langpacksize
<Kamion> well, the difference in the total size of all the packages in dapper-proposed versus their corresponding packages in dapper-updates/dapper is < 2MB
<Kamion> we'll see in a moment what that maps to in terms of CD size
<doko> which is acceptable?
<Kamion> we'll see ...
<Kamion> depends where the bulk of the size increase is, really
<Kamion> 2MB would be a bit much
<Kamion> (for edubuntu)
<doko> pitti: well, I'd need to compare the latest of dapper{,-security,-updates} with -proposed
<pitti> doko: you can specify a Packages.gz file
<pitti> doko: still, the script is very langpack specific
<doko> pitti: yes, but OOo is in -security, ia32-* are in -security and -updates, so I have to know where to look.
<doko> not everything is as easy as language packs ;-)
<Kamion> oh, meh, I was running the wrong image build
<Kamion> you'll have to wait a bit longer :-/
<Kamion> anyone know of a quick tool to deduplicate a Packages file (i.e. take only the highest version of each)
<mjg59> Hm.
<mjg59> Systems /should/ have a /dev/fd, right?
<StevenK> mjg59: Its a symlink to /proc/self/fd here at least.
<Nafallo> looks like it. atleast my systems has.
<mjg59> But some people seem to be lacking it
<ogra> mjg59, i'm lacking it in the ltsp chroots on upgrades ...
<ogra> there is no proc mounted at that point
<Nafallo> mv ogre some\ people
<Nafallo> ;-)
<Nafallo> baah, ogra even. ogre is my server.
<ogra> is it really needed in the postinst ? 
<ogra> Nafallo, ltsp has plenty of users
<Kamion> yes, /proc is needed in postinsts, in general
<Kamion> as Scott explained earlier
<Kamion> you might have been lucky before, but now you have to deal. :-)
<ogra> thats very sad ... because it takes the ease of "sudo chroot /opt/ltsp/i386/ apt-get dist-upgrade" away ... :/
<pitti> ogra: I have /proc mounted in all my chroots automatically (in fstab)
<pitti> that works pretty well
<ogra> pitti, its not needed, /proc will be mounted during the client boot
<pitti> ogra: yeah, but I don't boot my chroots :)
<ogra> and its mounted/unmounted by the script that creates it ...
<ogra> my prob is that i will have to write a ltsp-update script, which has to be documented and which users need to be aware of ...
<heno> doko: there were some reports of serious accessibility problems with the OOo in edgy: https://lists.ubuntu.com/archives/ubuntu-accessibility/2006-July/000667.html but that could be a more general Gnome problem. We are trying to work that out
<ogra> the last two releases this worked with just apt-get 
<doko> heno: I didn't look at accessability problems yet. is this i386?
<heno> doko: yes
<heno> and bleeding edge edgy
<heno> OOo in dapper seems less bad (though I personally get crashes when AT-SPI is on)
<doko> heno: dapper, or dapper + dapper-proposed?
<Kamion> doko: preliminary figures suggest that amd64 shrinks by 1.7MB, i386 grows by 250KB, and powerpc grows by 1.9MB on adding dapper-proposed
<heno> doko: haven't tested -proposed
<Kamion> doko: I suspect there's some noise in those figures though
<Kamion> definitely noise, various packages seem to have randomly gone missing from the .list
<doko> amd64 shrinks? strange
<mjg59> ogra: Ngh.
<mjg59> ogra: Yes, it's needed.
<mjg59> Bits of shell just don't work unless it's there.
<Kamion> doko: I suspect it's got more to do with:
<Kamion> -/pool/main/s/samba/samba_3.0.22-1ubuntu3.1_amd64.deb
<Kamion> and stuff like that
<Kamion> ah, there's oversizing, damn
<heno> doko: was the 2.0.2 that was in Edgy until recently the same as that in dapper or did it have lots of patches from 2.0.3?
<doko> heno: we had no 2.0.2 uploads in edgy
<heno> doko: I could have sworn the 'About OOo' screen said 2.0.2 a few days ago, but I could be wrong :)
<ogra> mjg59, ok, then  cant do anything ...
<Kamion> heno: dapper package carried over
<mjg59> ogra: Mm?
<heno> Kamion: right, that's what I figured
<ogra> mjg59, if its needed by the postinst i cant do anything against it ... i just wondered why ... i'd expect the fd to be used at runtime but not at installation time
<mjg59> ogra: The postinst uses subshells
<ogra> ah, k
<mjg59> Ok
<heno> So that points to some AT-SPI problems in Gnome 2.15 because that dapper OOo packages works fine on dapper, while both the old and new fail on edgy
<Kamion> pitti: ok, turns out the alternate install CDs are rather oversized too. I'm turning off debian-cd's own oversizing protection in order that we can easily se by how much
<Kamion> see
<doko> heno: did you check 2.0.3 from dapper-proposed as well?
<pitti> Kamion: the report doesn't help for that? (CD 2 will only be filled with n bytes)
<Kamion> pitti: it does, but it's tedious
<heno> doko: no, do I just add -proposed to the sources list? are there any instruction on-line?
<Kamion> much easier to see the results from a single number in one place
<pitti> right
<heno> sorry, I've been away ...
<doko> heno: see my recent mail to -users, and -devel: that will work: deb http://archive.ubuntu.com/ubuntu dapper-proposed main
<heno> thx
<heno> doko: the -proposed version speaks loud and clear :)
<doko> so it looks like a at-spi problem
<heno> yep
<heno> any advice on how to dig further in that?
<heno> I can poke around with at-poke for a start I guess
<gnomefreak> what did i miss :( i thought usplash was gonna read Xorg.conf?
<mjg59> No
<gnomefreak> how do i change it so i can boot?
<gnomefreak> its telling me wrong res. black screen with flashing monitor thing
<gnomefreak> after usplash is finished
<mjg59> Does usplash itself work fine?
<gnomefreak> mjg59: yes right at the end where it would give me login it dies
<mjg59> Right
<mjg59> What drivers are you using for X?
<gnomefreak> nv
<mjg59> Not nvidia?
<gnomefreak> cant this card wont use any of the nvidia drivers :(
<mjg59> Right
<mjg59> For now, you can just remove the "splash" argument from the kernel command line
<mjg59> Please file a bug
<gnomefreak> you got it
<Zdra> gnomefreak: I've the same problem here. I use the free nv X driver
<gnomefreak> yep
<gnomefreak> i will report a bug in a few im looking for something atm
<ogra> BenC, ping
<pitti> seb128: wow, gtk has a cupsys backend now?
<seb128> pitti: yep
<seb128> pitti: since 2.10.1
<pitti> seb128: I still miss gtk-mail-server :)
<seb128> "* The printing framework now supports a subset
<seb128>   of the Cups 1.2 custom PPD option spec"
<pitti> ^ cool
<seb128> gtk-mail-server? a MTA backend for GTK? :p
<pitti> sure, and gtk-kitchen-sink
<seb128> :)
<seb128> gtk-make-coffee
<pitti> and -clean-my-room
<seb128> patches are welcome :p
<Nafallo> s/om/oms/ :-)
<gnomefreak> Zdra: comment on bug 55048 about usplash
<Ubugtu> Malone bug 55048 in usplash "usplash ends and doesnt boot (edgy)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55048
<Zdra> gnomefreak: I'll comment when I'm back at home to attach logs ;-) thanks
<gnomefreak> ok
<seb128> pitti: I'm not sure I like everything about the new apport-gtk
<seb128> pitti: like the default being the bug discarded 
<pitti> seb128: as opposed to just being kept in /var/crash/?
<seb128> and having the browser being spawned like that is sort of weird
<seb128> pitti: as opposed to send the bug by default :)
<pitti> we have to use the browser for edgy, we don't have a bug reporting tool yet :(
<seb128> right
<pitti> seb128: ah, you mean the default button?
<seb128> yep
<pitti> let's ask mpt again, but that's certainly negotiable
<pitti> -> #u-desktop?
<seb128> pitti: sure
<hs_125> I installed ntop when i tried to run it says **ERROR** RRD: Disabled - unable to create base directory 
<hs_125> and gets freezes
<hs_125> any idea ?
<pygi> sivang, poke :)
<Kamion> doko: ok, these figures look better - growth of 1.5-2MB across the board
<doko> Kamion: hmm, that looks like it's too much
<doko> Kamion: can I get these oversized CD's nevertheless?
<Kamion> doko: the only differences are openoffice.org; also python-uno no longer seems to be on the CD
<Kamion> doko: which is because openoffice.org-writer no longer depends on it in -proposed
<pitti> Kamion: total CD growth, or OO.o growth?
<Kamion> doko: http://cdimage.ubuntu.com/dapper/daily/
<Kamion> pitti: total CD growth due to adding -proposed, entirely composed of OO.o changes
<pitti> so we need to reduce powerpc, the rest should be fine?
<Kamion> pitti: yes, powerpc alternate needs to drop by at least half a megabyte
<Kamion> doko: if you can see low-hanging fruit to reduce the size, go for it, but otherwise I'm inclined to say "good try, but not this time"
<Riddell> el: ping
<doko> Kamion: I'll have a look
<pitti> Kamion: hm, not two, to make them burnable for all people again?
<Riddell> Kamion: should I be testing kubuntu/dapper/daily/20060803/ ?
<Kamion> pitti: half a megabyte from 20060803.4 brings it under 700MB
<Kamion> pitti: 20060803.5 was the one built against -proposed
<Kamion> Riddell: hmm
<Kamion> Riddell: yes, I guess so, although it was relatively early this morning
<Kamion> ogra: could you have a look at http://cdimage.ubuntu.com/edubuntu/dapper/daily/current/ ?
<Kamion> doko: doing one desktop CD build with -proposed, for your comfort and convenience :)
<doko> Kamion: is openoffice.org-gcj on the CD? I didn't look yet at the package list
<ogra> Kamion, looks good on first sight :)
<gnomefreak> Hobbsee: thank you for fixing the depedns on that app so fast
<Kamion> doko: no
<Hobbsee> gnomefreak: which one?  oh, the yada one?  *grumble grumble mutter mutter*
<gnomefreak> the mascma one
<gnomefreak> (sp)
<gnomefreak> mascyma
<mjg59> gnomefreak: If you boot without splash, then log in, switch to a text console, do sudo usplash and then press ctrl+alt+f7, does it work or do you get corrupted graphics?
<gnomefreak> didnt try ill try now
<Hobbsee> gnomefreak: yeah.  uses yada.  ought to be shot.
<Hobbsee> gnomefreak: actually, the upstream maintainers ought to be shot.  and their corpses burned.
<gnomefreak> lol ;)
<StevenK> Hobbsee: And drawn, quartered and then *really* hurt.
<Hobbsee> StevenK: yeah, that's the one.
<Hobbsee> and then taugth about using decent build system.s
<gnomefreak> ok sudo usplash showed it now should i change my boot back to with splash?
<gnomefreak> mjg59: ^^
<mjg59> gnomefreak: No
<gnomefreak> ok brb reboot
<mjg59> gnomefreak: ?
<gnomefreak> oh nvm you didnt need me to reboot
<mjg59> gnomefreak: Nope
<gnomefreak> k
<mjg59> gnomefreak: So it works if you switch from usplash to X?
<gnomefreak> mjg59: it worked in usplash X came right back to this
<gnomefreak> tty
<mjg59> gnomefreak: Ok
<mjg59> gnomefreak: Then it's probably the fact that vga16fb gets loaded
<mjg59> I'll look into it
<gnomefreak> shoo
<gnomefreak> mjg59: i went back into tty2 and it has that flashing error
<mjg59> Oh
<mjg59> Interesting
<gnomefreak> mjg59: i went back again it dropped me into tty2 again
<gnomefreak> mjg59: ok sudo usplash runs the usplash for a few secs maybe 30 than drops me back to the black screen with the monitor error
<gnomefreak> i tried getting a screenshot of it but cant
<mjg59> Right
<mjg59> I'll look into it
<jdub> hrm, is security.u.c down / inaccessible?
<Kamion> slow
<jdub> ah
<jdub> thanks
<mjg59> jdub: Tried the new usplash?
<jdub> mjg59: not yet
<jdub> mjg59: i'll have to reboot when pipka's not using my laptop :)
<Hobbsee> mjg59: what did you want to know about it?
<doko> Kamion: found the first 100k to save :)
* Hobbsee has tried it - assuming it's the standard version in edgy repos.
<mjg59> Whether it works
<mjg59> In terms of appearing at a higher resolution than the old one
<gnomefreak> Hobbsee: yes it was updated lastnght
<mjg59> And if X still works afterwards
<gnomefreak> maybe 10 hours ago or so
<Hobbsee> mjg59: ah.  right.  X seems to start much more slowly, and it's at a slower resolution (680x400 or whatever the standard one is) instead of 800x600/1024x768/whatever mine usually is
<mjg59> That's nothing to do with usplash
<mjg59> So not sure what's going on there
<Hobbsee> mjg59: sorry - the usplash is at the lesser resolution
<mjg59> I don't really understand
<Hobbsee> my bad.  i was unclear.
<mjg59> usplash has never usually been at anything other than 640x400 in dapper
<mjg59> Do you have a /etc/usplash.conf ?
<Hobbsee> # Usplash configuration file
<Hobbsee> xres=1024
<Hobbsee> yres=768
<Hobbsee> mjg59: yes.  ^
<mjg59> Ok
<mjg59> And you've rebooted since that was written?
<Hobbsee> i've rebooted since i got the last update for usplash, so yes.
<mjg59> Assuming your initramfs was regenerated, it's impossible for usplash to run at any resolution other than 1024x768 in that case
<mjg59> The picture will still be 640x400, but it'll be centred in the screen
<Hobbsee> mjg59: that's true.
<mjg59> ?
<gnomefreak> yep here too
<Hobbsee> mjg59: sorry, that's true @ the 640x400, but centred in the screen.
<mjg59> Oh
* Hobbsee thinks she's being really unclear and confusing here  tonight
<mjg59> So it works?
<Hobbsee> well, yes.  but it's gotten a lot smaller!
<mjg59> Given that the artwork is only 640x400, that's sort of inevitable...
<gnomefreak> ok brb i have to boot kde 
<mdke> elmo: possibly you've been bugged about this already, but have you been poked about the forums being v slow? are you the right person to poke?
<elmo> mdke: we don't run the forums software - if they're down entirely, sure, poke us, but performance isn't something we really deal with, you need to speak to ubuntugeek.  but he's aware, and wer're discussing ways of potentially speeding them up
<mdke> elmo: ah, I see. Thanks, I wondered if it was related to the bandwidth thing you mentioned earlier wrt security.u.c, cheers for explaining
<elmo> mdke: the bandwidth limitations are specific to security.u.c, shouldn't affect ubuntuforums right now
<mdz> mjg59: will it be possible to know at update-initramfs time what mode will be used, so that we can select appropriate artwork in advance?
<mdke> elmo: gotcha.
<ogra_thin> but then ldm will also depend on lsb?relese
<ogra_thin> argh
<ogra_thin> lsb-release
<ogra_thin> damned, i need an lts.conf with the right keymap
<doko> Kamion: plus another 1.8MB
<ogra_thin> whoops, ECHAN
<Kamion> doko: ooh, where did that come from?
<doko> Kamion: .wav files in /usr/lib/openoffice/share/gallery/sounds -> sound doesn't work anyway
<doko> (at least in 2.0.3)
<bddebian> Heya
<Kamion> doko: that should be basically all the size increase clawed back, then, which is great
<Kamion> mdz: do we want to update stuff like the firefox home page for 6.06.1?
<Kamion> if I can get away with just leaving them alone, that would be a bonus :-)
<mdz> Kamion: I don't think it's necessary
<doko> Kamion: there seems to be much more (i.e. if we move the default icon themes for -gome and -kde) out of -common into some -common-kde and -common-gnome packages, but I would like to delay that, seems to have some impact
<Kamion> doko: sounds like something to do for edgy
<Kamion> although if it's *lots* more then we might want it for the next point release, if there is one
<Kamion> I'm a bit reluctant to require dist-upgrade within a stable release though
<doko> 4 icon themes with 4.5MB zip files each 
<Kamion> whew
<Kamion> -rw-r--r-- root/root   4622082 2006-08-02 00:41:36 ./usr/lib/openoffice/share/config/images_hicontrast.zip
<Kamion> -rw-r--r-- root/root   5458441 2006-08-02 00:41:30 ./usr/lib/openoffice/share/config/images_industrial.zip
<Kamion> -rw-r--r-- root/root   5870914 2006-08-02 00:41:33 ./usr/lib/openoffice/share/config/images_crystal.zip
<Kamion> -rw-r--r-- root/root   4901170 2006-08-02 00:41:28 ./usr/lib/openoffice/share/config/images.zip
<Kamion> which of those are needed for GNOME and which for KDE?
<Riddell> crystal kde, industrial gnome I guess, hicolontrast accessibility, images non-themed?
<QuestionMarkCoun> Hello *
<Kamion> doko: if we wanted to do that for dapper, I'd suggest moving them to openoffice.org-{gnome,kde}; I know those are architecture-dependent but the bloat there is probably better than a new package in dapper
<QuestionMarkCoun> Kamion: I'm working with cdimage and I have a problem with the Makefile in debian-cd
<Kamion> QuestionMarkCoun: oh?
<sabdfl> mjg59: ping
<doko> Kamion: ok, but not now. the missing python-uno is a mistake. adds +250k; so now we have saving of unused bitmaps: 110k + 1.8mb .wav files - 250k python-uno. -> total savings 1.65mb on all archs
<QuestionMarkCoun> Kamion: The part after "Generating the source CD labels and their volume ids ..."
<QuestionMarkCoun> Kamion: in the logfile I find "ls: /tmp/scratch/ubuntu-server/daily/tmp/dapper-src/??.sources: No such file or directory"
<Kamion> doko: that makes it +/- 200-300KB; I'm happy enough with that
<Kamion> doko: thanks for that
<Kamion> QuestionMarkCoun: that's normal
<doko> Kamion: ok, needs another upload, which will likely be built tomorrow morning
<el> Riddell, late pong
<Hobbsee> hah.  late pong.
* Hobbsee hasnt heard that before
<QuestionMarkCoun> Kamion: ok... thank u
<Kamion> QuestionMarkCoun: it's just because there's some dodgy shell that looks for ?.sources and ??.sources in order to cope with more than 9 CDs in a set
<Riddell> el: could you change the assignee in kubuntu-system-settings-usability to simon-simonzone
<Riddell> el: https://launchpad.net/distros/ubuntu/+spec/kubuntu-system-settings-usability/+people
<Kamion> QuestionMarkCoun: personally I'd advise not trying to track down every warning - track down ones that seem to be associated with build problems, but don't go looking for trouble in debian-cd, because you'll find it ;)
<Kamion> QuestionMarkCoun: you could compare against our build logs in http://people.ubuntu.com/~cjwatson/cd-build-logs/ if you like
<el> Riddell, done
<Kamion> doko: will you upload that to dapper-updates? you'll need to also upload stuff like libwpd then
<doko> Kamion: can't that be mapped?
<QuestionMarkCoun> Kamion: ok... but somehow, I have to find out, what is important and what is not ;)
<Kamion> doko: not sure, I can ask the Soyuz team
<Riddell> el: thanks, I'll let you know when I have some pacakges of simon's changes
<Kamion> QuestionMarkCoun: comparing against our logs can be good for that
<el> Riddell, great, thanks
<doko> Kamion: that way, we could easily fall back to the packages from -security / -updates
<Kamion> doko: actually, I know the answer - if we want to copy prebuilt binaries over, we need manual SQL munging at present
<Kamion> ?
<Kamion> ok, step back, what do you mean by "mapped"?
<doko> Kamion: add the packages to -updates without uploading again? (or building the CD's from -proposed, if OOo is the only thing uploaded there)
<mjg59> sabdfl: Hi
<Kamion> doko: adding the packages to -updates is irreversible - once we do that, we can't/won't "easily fall back to the [old]  packages"
<Kamion> doko: we can build from -proposed though
<Kamion> doko: the plan is to create a dapper.0 suite which is a copy of dapper, and then sync all sources/binaries from dapper-{security,updates,proposed?} into it
<Kamion> doko: I'd like to do that right at the end, though, as it needs malcc to sit down with ten pints of coke and a DB pickaxe
<Kamion> infinity then wants to rebuild CDs and livefses from the new dapper just as a sanity-check
<doko> -proposed currently just has the OOo related uploads. do what you think is less work for you. if users install 2.0.3, they can't go back that easily anyway. for me, it's not a big deal to upload to -proposed now and to -updates this weekend
<Kamion> an upload this weekend cannot get into the point release, because as of Monday I'm on holiday for two weeks
<Kamion> so I'd say just upload to -proposed now
<Kamion> as you say, there's just OOo in there so it's easy enough to build from it
<doko> ok
* Kamion manages to crash ubiquity in dapper-updates. hmm
<Kamion> right, that's it, I hereby declare that going back to gparted/qtparted in ubiquity will forget any mountpoints you've set. The alternative is too complicated to actually get right.
<seb128> doko: do you know about gdb? like is that you I should ping if gdb segfault? :p
<doko> seb128: it starts with g*, iz a gtk bug
* seb128 slaps doko
<doko> no, no problem reported yet
<Nafallo> lol
<Nafallo> doko: http://www.magicalforest.se/~nafallo/update-manager_crash.txt :-)
<doko> Nafallo: please install python-dbg and try again
<Nafallo> oh, it segfaults because of that? odd.
* Nafallo apt-get installs
* Hobbsee waves to doko 
<doko> Nafallo: I don't know ...
<desrt> pitti
<desrt> mer
<seb128> doko: no, gdb is crashing, http://paste.ubuntu-nl.org/19599
<seb128> doko: I'm building a debug gdb atm
<Nafallo> yea, still crashing...
<Spads> zul: ping
<Nafallo> hehe, debug debugger :-)
<desrt> a self-hosting trace?  cool.
<doko> seb128: or build it with -fno-stack-protector
<seb128> doko: what does it do?
<doko> seb128: disabling pitti's pet
<doko> (ssp)
<seb128> ah
<seb128> will try that
<doko> if that doesn't work, I'll need to look at it tomorrow ...
<seb128> doko: adding -fno-stack-protector to the CFLAGS should work?
<doko> seb128: yes
<seb128> doko: ok, thank you
<zul> Spads: pong
<Spads> zul: oh hey
<QuestionMarkCoun> Kamion: I made some progress... now mkisofs crashes: /usr/bin/mkisofs: Argument list too long. cannot parse MD5 file '$CDIMAGE_ROOT/scratch/ubuntu-server/daily/tmp/dapper-src/md5-check'
<Kamion> $CDIMAGE_ROOT shouldn't be in there unexpanded; investigate that
<QuestionMarkCoun> Kamion: sry... log entry has the real path... I shortened it...
<Kamion> so what mkisofs command is it running? it should have logged that
<QuestionMarkCoun> Kamion: Is a special mkisofs version needed? I just use the standard one...
<Kamion> the one in Ubuntu dapper should work fine
<Kamion> don't use the upstream version - it doesn't have the jigdo patches
<QuestionMarkCoun> man mkisofs knows something about jido... so I think this is ok
<mhb> hey everyone
<icecrash> hi
<Hobbsee> heya
<mhb> here am I lobbying again :o) Does anyone know if there are plans for internationalization of the basic console? (/dev/tty1,2...)
<QuestionMarkCoun> + /usr/bin/mkisofs -r -V 'Ubuntu 6.06 Src-1' -o /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.raw -jigdo-jigdo /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.jigdo -jigdo-template /tmp/independent/scratch/ubuntu-server/daily/debian-cd/src/dapper-src-1.template -jigdo-map Debian=/tmp/independent/ftp/ -md5-list /tmp/independent/scratch/ubuntu-server/daily/tmp/dapper-src/md5-check -jigdo-min-fi
<QuestionMarkCoun> le-size 0 -jigdo-exclude 'README*' -jigdo-exclude /doc/ -jigdo-exclude /md5sum.txt -jigdo-exclude /.disk/ -jigdo-exclude /pics/ -jigdo-exclude 'Release*' -jigdo-exclude 'Packages*' -jigdo-exclude 'Sources*' -jigdo-exclude 'Contents*' -jigdo-force-md5 /pool/ -J -joliet-long CD1
<mhb> I find it a bit silly that I have my local keyboard in X but when I switch with CTRL+ALT+F1 to the consoles, I have english keyboard and no support for local characters ... :o( 
<mhb> I think it should be configured at install time
<Kamion> mhb: it is, for most people
<Kamion> please file a bug on debian-installer with full information about your setup
<Kamion> (or ubiquity, depending on which you used) and attach /var/log/installer/syslog
<mhb> Kamion: dapper or edgy?
<Kamion> mhb: it's supposed to have worked since forever, but there's always the possibility of bugs with regard to certain keymaps
<Kamion> QuestionMarkCoun: looks ok to me, so I'm afraid I don't know
<Kamion> QuestionMarkCoun: FWIW the string "list too long" doesn't appear anywhere in the mkisofs source I have here - I'd suggest double-checking your installation
<QuestionMarkCoun> Kamion: is ok to just drop md5 things here... for testing...
<Kamion> QuestionMarkCoun: I suppose it could be that "Argument list too long" is a red herring and it 
<Kamion> just doesn't like the md5-check file
<Kamion> QuestionMarkCoun: up to you
<mhb> Kamion: so I should do a clean install and then report the /var/log/installer/syslog, right?
<Kamion> mhb: feel free to report from your current installationn
<Kamion> QuestionMarkCoun: things that come to mind are to make sure that your setting of MIRROR is correct and to make sure that you've mirrored dists/$DIST/main/installer-$ARCHES
<QuestionMarkCoun> my mkisofs is 4:2.01+01a01-4ubuntu6
<mhb> Kamion: well, I'll do some more research ... I have to find out if both ubiquity and the Kubuntu installer fails to set the console font+keymap
<Kamion> they do it using different code at present (sane-installer-keyboard aims to fix that, in part), so it's possible that one fails but not the other
<mhb> Kamion: I'll do some more research and then I'll report the bug
<Kaleo> Hello
<mhb> Kamion: thanks for the pointers :o)
<QuestionMarkCoun> Kamion: we are syncing against de.archive.ubuntu.com with SECTIONS="main,restricted,universe,main/debian-installer"
<QuestionMarkCoun> and dists are: dapper,dapper-updates,dapper-security
<Kamion> QuestionMarkCoun: debmirror doesn't pull down the installer-* trees itself - you have to do that by hand with rsync or whatever
<QuestionMarkCoun> ok... thank you so far... I will rsync it and try again
<Kamion> no problem, good luck
<seb128> doko: crash with gdb built with -fno-stack-protector too
<Kamion> oops! let's pretend that ubiquity actually works in dapper-updates shall we *cough*
<mhb> Kamion: Any chance you might know if (or when) we (the translators) will be able to translate the .deb package information (details about the package) ?
<mhb> some of my debian translator friends informed me they are starting to translate their own, so I thought it will soon be possible in Ubuntu, too.
<Kaleo> Kamion: sorry to annoy you again but did you get my private messages or would it be better to send you an e-mail ?
<Kamion> Kaleo: yes, I got them, and I'm familiar with the bug
<Kamion> thank you for the patch, I'll review it when I have time
<Kamion> I could not respond to your private messages because every time I saw them you were offline
<Hobbsee> Kamion: /msg memoserv help :P
<Hobbsee> although whether people actually read their memos is a good question
<Kaleo> Kamion: that's right (56k modem), thank you for your time
<Kamion> Hobbsee: I tend to think that people who aren't connected most of the time should use e-mail or memos themselves rather than sending /msgs to which it's hard to respond
<Kamion> I tend not to remember about memoserv when replying to people
<Hobbsee> Kamion: that is true.  i'm more telling you another way you could use :)
<Hobbsee> heh
* Hobbsee uses email.  or just wait a few hours till i'm online again
<Kamion> Kaleo: also, AFAIK the problem only affects users on systems that drop traffic they don't want rather than properly rejecting it
<Kaleo> thanks to screen+irssi Ill be online now :)
<Kamion> s/on systems/behind firewalls/
<Kamion> if your firewall actually says "no" rather than "la la la I can't hear you", then apt will give up in a reasonable time rather than waiting ages to timeout
<Kamion> I'm also not really sure that just checking the http_proxy environment variable (while useful) is something that most people affected by this would discover
<Kaleo> Kamion: I understand
<Kaleo> in the Uni here everybody is behind that kind of firewall
<Kaleo> and there is no way to complete the installation right now
<Kamion> I'll throw in your workaround for the moment, but it doesn't really close the bug
<Kaleo> I agree
<Kaleo> actually what I would like is something like
<Kaleo> do you want to use your internet connection or not
<Kamion> hang on, doesn't apt honour http_proxy?
<Kamion> yes, it does
<Kamion> so I don't understand why your suggested change is necessary
<Kaleo> give me a minute to remind me the circumstances
<Kamion> if http_proxy is set in the environment, apt will prefer it over Acquire::http::Proxy anyway
<Kaleo> because in my experience setting up the http_proxy variable did not solve the bug
<Kaleo> I have now to remember why
<Kamion> ok, sorry but I want to know why before installing workarounds
<Kaleo> no problem
<Kaleo> oh I think I remember
<Kaleo> because of gksu
<Kaleo> if I remember correctly ubiquity is launched by gksu
<Kamion> gksu is outside apt-setup (the code you patched); if apt doesn't see http_proxy due to gksu, then apt-setup won't see it either
<Kaleo> "This is thanks to the correction of bug #13661 where gksu has been given the ability to set $http_proxy according to System/Preferences/Proxies."
<Ubugtu> Malone bug 13661 in synaptic "get proxy via gconf" [Medium,Fix released]  http://launchpad.net/bugs/13661
<Kaleo> that's why it works
<Kamion> but gksu -> ubiquity -> (apt-setup, apt_)
<Kamion> anything in gksu will affect apt-setup and apt equally
<Kamion> making apt-setup look at http_proxy should be pointless because apt already does it
<Kaleo> I see
<Kamion> I'm running through an installation with a configured proxy now
<Kaleo> ok
<Kaleo> I have to look at the code to be able to remember the process
<Kamion> it's possible that something's clobbering the environment; if so, that's the bit to fix
<Kamion> and yes, ubiquity's launched via gksudo
<Kaleo> from what I understand of my patch apt-setup was not honouring $http_proxy
<Kamion> apt-setup doesn't need to
<Kamion> it doesn't download anything itself - it calls out to things that do honour http_proxy
<Kaleo> well
<Kamion> i.e. apt-get and wget
<Kaleo> I guess than apt-get or wget was not honouring it
<Kaleo> -than+that
<Kamion> honestly, I don't believe that
<Kaleo> that seems weird
<Kaleo> must be something else then
<Kaleo> how is going your installation ?
<Kamion> I've confirmed that http_proxy is definitely being passed through to apt
<Kaleo> ok
<Kamion> it's being pretty slow, but that's because archive.ubuntu.com is being pretty slow
<Kaleo> yes
<Kamion> the environment is definitely correct though
<Kaleo> how did you set up the proxy ?
<Kamion> system -> preferences -> network proxy
<Kaleo> directly the $http_proxy ?
<Kaleo> ok
<Kaleo> are you sure that its going through it ?
<Kaleo> does your firewall prevent the direct connection ?
<Kamion> I'm stracing squid, I can see stuff going through it
<Kamion> read(14, "GET http://gb.archive.ubuntu.com"..., 4095) = 211
<Kamion> is pretty conclusive
<Toadstool> hi here
<Toadstool> doko: around?
<Kamion> netstat on the client also says that it's talking to the proxy
<Toadstool> doko: anyway, got to go, that was about bug 55047, python-mysqldb just need a rebuilt and as you're listed as the last uploader, I thought I should talk to you first
<Ubugtu> Malone bug 55047 in python-mysqldb "python-mysqldb doesn't actually install any python" [Medium,Confirmed]  http://launchpad.net/bugs/55047
<Kaleo> Kamion: pretty strange but the facts are as you say conclusive
<Kamion> Kaleo: my feeling is that a good approach would be to make apt-setup chatter more to debconf about what it's doing
<Kamion> Kaleo: it probably wouldn't be too difficult to pass through the apt progress bar, now that we have stuff like debconf-apt-progress
<Kamion> I suspect many experiences of "hangs" with a configured proxy are in fact just slowness and lack of progress reporting
<Kaleo> hmmm
<heno> seb128: do you know why gnome grabs focus when you press Alt? Does it need to do that?
<heno> It complicates things like the on-screen keyboard
<Kaleo> Kamion: I will try again from the same place to see if the problem vanished
<Kamion> Kaleo: check with netstat to see what hosts processes are talking to
<Kaleo> yes
<Kaleo> question: would it not be better to ask the user if he wants his connection to be used or if he thinks that it's correctly configured ?
<Kamion> sure, just more work that's all
<Kamion> I have no fundamental objection to it, but I doubt I'll have time to do it before Edgy because I'm also trying to rewrite the partitioner, which is more urgent
<Kaleo> Kamion: okay
<Kaleo> I agree
<Kaleo> I would like to try
<Kamion> care would need to be taken to ensure that it's not on the critical path for installation
<Kamion> i.e. that it's off in a "Connection Settings..." box
<Kaleo> what do you mean ?
<Kamion> it is important not to make the installation longer by adding extra pages full of questions that the user has to read
<Kaleo> yes
<Kamion> at this point, most extra questions should be in places where the user isn't obliged to acknowledge them, and can just bypass them to use the defaults
<Kaleo> like an extra option in a page with a sensitive default option ?
<Kamion> I was thinking of a button on some appropriate page that popped up some extra stuff when pressed
<Kamion> but whatever
<Kaleo> I see
<Kamion> I'm no UI design genius
<Kaleo> me neither
* gnomefreak liked what you did with the ui for live installer
<Kamion> well, that was the work of a number of people
<gnomefreak> ah i thought that was you only :)
<Kamion> hell no
<Kamion> I spent at least 20 hours of face-to-face time with other people to thrash out the ubiquity UI
<gnomefreak> ah
<Kaleo> Kamion: do you think that the question is important enough to be visible in one ubiquity's screen ?
<Kamion> Kaleo: I think it should be easy to see how to get to it, but I'm not convinced the question itself should be visible
<seb128> heno: no idea, what do you mean by "grab focus when you press Alt"? like window going to first plan?
<Kamion> seems like a reasonable case for just having the title/heading be visible
<heno> seb128: when you press and hold the Alt key the mouse clicks are diverted to metacity it seems
<heno> seb128: so you cannot click on anything else until it is released
<heno> that makes Alt+key combinations difficult on the virtual keyboard
<mdke> it's used for dragging windows
<Kaleo> Kamion: I cannot see any screen in ubiquity relevant to the network
<heno> mdke: ah, thanks. Is there a gconf key to turn it off?
<Kamion> Kaleo: indeed, there isn't one
<Kamion> Kaleo: the timezone screen is closest, I suppose, since it deals with where you are
<Kaleo> Kamion: yes
<Kamion> although it's a little crowded at present
<Kaleo> I agree
<Kaleo> indeed
<Kaleo> it brings me another question
<mdke> heno: I can't see one. seb128 will know
<Kamion> Riddell: I'd appreciate testing of ubiquity 1.0.15 on Kubuntu when it builds; suggested test is to create some partitions in qtparted, go forward to the mountpoints screen, go back, delete those partitions and create some other ones, go forward to the mountpoint screen, see if it behaves sensibly
<Kaleo> we have three possibilities : 1) internet connection set up properly, 2) no network interfaces configured, 3) interface configured but no access to internet
<Kaleo> in case 1) everything is fine
<Riddell> Kamion: sure
<Kamion> Riddell: prior to 1.0.15/1.1.7 it would fail to offer some of the partitions (especially if you create more partitions the second time round than you did the first time round), probably get the sizes wrong, and if you selected a partition that you didn't create in the first time round then it would crash
<Kamion> I solved this by just deciding not to bother trying to preserve mountpoint selections if you go back
<Kamion> Kaleo: the other obvious option is to put stuff on the final summary screen
<Kaleo> in case 2) the installation goes ok I think but you have to configure manually the mirrors if you planned to use an internet connection
<Kamion> Kaleo: so it says "Network: use existing Internet connection" and there's a button beside it letting you change it, or something
<Kaleo> Kamion: absolutely the best place at the moment, I agree
<Kaleo> Kamion: yep
<Kamion> that would go for bootloader configuration as well
<Kaleo> Kamion: really interesting the bootloader option but maybe a bit too technical ?
<Kamion> I have a horde of osnews people baying for my blood that ubiquity doesn't let you configure where grub is installed
<Kamion> again, it absolutely shouldn't be asked by default, but if the final summary said "GRUB: installed in Master Boot Record of /dev/sda" or whatever and there was a button to change it, that wouldn't be too scary
<Kaleo> oh I see, the same summary but with small buttons for options
<Kamion> right. now at the moment there are some technical problems with asking much in the way of questions on the final summary page (because the partitioner is still running in the background and monopolising debconf), but I'm sure there are ways around that
<Kamion> anyway, I have to go for the evening - see you
<Kaleo> ok Kamion , see you later
<Kaleo> thanks for the chat
<Kamion> np
<bluefoxicy> Ubugtu: bug 6761
<Ubugtu> Malone bug 6761 in openssl "openssl: Expired certificates and recertification" [Unknown,Confirmed]  http://launchpad.net/bugs/6761
<bluefoxicy> ok /bugs/ *starts poking through bugs*
<bluefoxicy> (launchpad is such a pain)
<doko> Toadstool: on my list
<bddebian> Wow you are actually going to do something instead of bitch and moan?
<bluefoxicy> bddebian:  Nah, I'm trying to graph the rate of bug submissions for a presentation
<bddebian> Ah yes of course
<Riddell> el: rocking new system settings http://kubuntu.org/~jriddell/tmp/kde-systemsettings_0.0svn20060803-0ubuntu1_i386.deb
<Nafallo> what's up with a.u.c? it's /real/ slow now.
<bluefoxicy> bddebian:  you don't know of a way to get per-day or per-month counts on launchpad besides counting each bug do you?
<bluefoxicy> (using the bug numbers doesn't seem to help; or the reporter is not reporting most of the bugs to me)
<Nafallo> bluefoxicy: ask the launchpad-devs to integrate that somewhere? :-)
<bddebian> bluefoxicy: no clue,sorry
<seb128> heno: gnome-window-properties, on the bottom of the dialog
<heno> seb128: thanks, that helps a bit. No option for 'none' unfortunately
<seb128> heno: people usually want to be able to move their window :p
<seb128> heno: the gconf key is /apps/metacity/general/mouse_button_modifier you can try to set it to nothing maybe, dunno if that's supported
<heno> seb128: right, but for people who cannot use a mouse it may be more important to be able to access the file menu with Alt-F
<heno> thanks
<heno> The Meta options should help
<seb128> heno: right, but do they need the win key by example?
<heno> no not really
<heno> that's good enough for now I think
<seb128> k
<seb128> other way it's probably easy to change the metacity code for understand no value for it if it doesn't at the moment
<heno> actually it's not a problem with the Win key ATM either, because we don't treat it as a sticky key, so it can still be used for single presses
<heno> though I guess it is used as a modifier in some cases
* heno -> food
<dos000> anyone can suggest a good ide/debugger in ubuntu ?
<dos000> for c/c++ 
<bddebian> gdb?
<pygi> sivang, poke
<dos000> bddebian, anything that has integrated editors .. like gvim 
<pygi> dos000, #ubuntu pls :)
<pygi> your mind is best debugger :)
<dos000> pygi, most people in #uybuntu are not necessarily developpers ... i also already asked there
<dos000> i am donloading kdevelop3 now. i am on breezy
<lfittl> madduck: ping
<bddebian> lfittl!!  I just sent you an e-mail
<lfittl> bddebian: saw it, and already replied ;)
<bddebian> lfittl: Aye, just got that, sorry
<bddebian> lfittl: Have you talked to Raphael at all?
<lfittl> bddebian: no, didn't thought of it in february, but will do now before taking over his package
<bddebian> lfittl: Well he has been fairly unresponsive for me :-(
<madduck> lfittl: yes?
<lfittl> bddebian: hmm, will see, worst case if I can't take it over in debian I just upload it to ubuntu..
<bddebian> lfittl: Aye
<pygi> doko, bleh, why not upgrade to dapper?
<bluefoxicy> Nafallo:  will do
<jdub> (holy crap, an imlib upload...!)
<Gloubiboulga> jdub, is this that bad?
<bddebian> Didn't I ask for a sync of imlib?
<Gloubiboulga> bddebian, you did? I just merged it
<bddebian> I saw that :-)
<Gloubiboulga> ah yes, there's a sync request
<zul> jdub: any problems with xen so far?
<bddebian> Gloubiboulga: Can you reject that for me while you are in there?
<Gloubiboulga> bddebian, sure
<msw> jdub: like, good 'ole imlib?
<msw> jdub: not imlib2?
<jdub> msw: seriously.
<jdub> Gloubiboulga: that anything depends on or requires updates of imlib is scary. :-)
* msw checks the temperature in hell
<jdub> zul: haven't been running it on the laptop
<zul> jdub: ah ok
<Gloubiboulga> jdub, you seem to know imlib very well, it'll be easy for you to fix everything is broken then ;)
<QuestionMarkCoun> Kamion: We did it :) the first iso fell out... thank you
<bddebian> Gloubiboulga: :-)
<jdub> Gloubiboulga: noooooooo--*choke*!
<pygi> sivang, poke again :)
<HiddenWolf> jdub: that image you just blogged, is that real or gimped?
<sivang>  /msg pygi pong
<sivang> pygi: pong
<thom> jdub: fixing imlib is very easy... ssh container, rm -rf /cvs/gnome/imlib
<tseng> thom: hah!
<tseng> thom: i've sent your patch to iain but he has already skipped town i think
<tseng> thom: if i get frustrated enough ill host a bzr branch
<thom> garn.
<pygi> sivang, pm :)
<Chipzz> any reason why security.ubuntu.com is slow today?
<pygi> Chipzz, servers are reaching bandwith limits
<Nafallo> why btw? :-)
<tseng> Nafallo: more users?
<Nafallo> but why haven't I seen this problem before?
<Chipzz> pygi: it's not bandwidth, it's response time
<Chipzz> takes 10sec or more to get a connection
<pitti> Hello
<pygi> Chipzz, poke elmo if you don't trust me, it's bandwith :)
<pygi> hey pitti, I was looking for you before
<Nafallo> we can't have THAT many new users, can we?
* Nafallo visions ntp eating all bandwidth ;-)
<pygi> pitti, you have O_EXCL patch for cdrecord? I need to do same thing to upstream source of libburn
<pygi> (apply patch)
<pitti> pygi: yes, we have it for ages
<pygi> pitti, asking because of this: http://libburn.pykix.org/ticket/18
<pygi> if it's just a stream that needs to be opened with O_EXCL, then it's 30 seconds patch :)
<pitti> pygi: oh, you meant I shall give you the patch?
<pygi> pitti, right, just to see if I am thinking about the correct thingy :)
<pitti> pygi: http://people.ubuntu.com/~pitti/patches/cdrecord.O_EXCL.patch
<pygi> thanks pitti :)
<pitti> pygi: I'm not sure whether the timeout is the right thing to do in the library
<pitti> pygi: maybe the library should just fail with a particular 'busy' error and the timeout should be in the app
<pitti> pygi: if you take this timeout stuff away, it's indeed just adding O_EXCL to the open() call
<pygi> right, busy error it might be then or something more verbose :)
<pygi> so this patch replaced open() with sg_open_excl()
<pygi> ah, right
<pygi> thanks once again pitti :)
<pitti> pygi: yes, because sg_open_excl() implements the timeout
<pitti> pygi: but as I said, that's a bit evil in a library, since the app would be blocked during that time
<pygi> pitti, yes, but  in my case it could implement error message
<pitti> pygi: you should just pass the EBUSY to the app IMHO
<pitti> pygi: how is libburn coming along, btw?
<pygi> pitti, quite good I would say
<pitti> it's something that has been necessary for a looong time :)
<pitti> cool
<pygi> I an working on complete libisofs rewrite right now
<pygi> we aim for -tao like writing for 0.3, and for dvd and multi-session I am not yet sure
<pygi> 0.2.1 should be out in a month
<pitti> pygi: so, something non-crackful GPL with a sane consistent interface?
<pitti> pygi: will it handle DVDs, too?
<pygi> pitti, it should, but not just yet :)
<pitti> sure, I mean if it's plannec
<pitti> s/c$/d/
<pygi> ofcourse :)
<pitti> the API should be designed accordingly, I mean
<pitti> yay
<pygi> I think I'll have most issues with multi-session stuff
<pygi> I'll need to do some serious thinking about that
<pitti> pygi: I found the 'write down all use cases and check whether the API has a straightforward way of implementing them' a good approach
<pygi> pitti, indeed :)
<pygi> I just had talk with "someone" offering me to implement conversion of most proptietarity image formats to iso into libisofs :)
<pygi> which I'll most probably decline :)
<pitti> 'proprietary image formats' -- like the ones from Nero etc.?
* pitti has never seen a non-iso image
<pitti> well, I haven't seen a non-Linux box in a long time
<pygi> pitti, hehe :)
<pygi> right, alcholol 120%, nero, bla, bla :)
<pygi> alcohol*
<HiddenWolf> where is the catch?
* pitti had expected them to be iso with some metadata wrapped around
<pitti> pygi: what's the problem with that conversion? the knowledge about the format is NDAed?
<HiddenWolf> pitti: of course not, that'd be sane, wouldn't it?
<pygi> pitti, indeed, he obtained knowledge by doing reverse engeenering :)
<pygi> or whatever the spelling is :p
<pitti> HiddenWolf: erm, you mean NDA'ing file formats would be sane?
<pitti> pygi: but reverse engineering is fine - where's the problem then?
<pygi> pitti, how can it be fine? :P
<HiddenWolf> pitti: I mean that wrapping some metadata around iso would've been sane, which is why they didn't do that for $bunchofotherformats
<pitti> pygi: fine legally, not from the point of efficiency, of course :)
<pitti> HiddenWolf: ah, heh
<pygi> pitti, hm, right, but...ah anyway, care to discuss this later? I am kinda in a hurry :)
<pitti> oh, I didn't mean to stall you
<pygi> no, no, ofcourse you didn't, don't worry :)
<pitti> pygi: have a good day!
<pygi> pitti, or night :) thanks :)
<pitti> pygi: right, you're approx. my time zone, too :)
<crimsun> pitti: hi, if you have a sec, is there plans for pulseaudio in edgy?
<crimsun> s/is/are/
<pitti> crimsun: not from my side
<crimsun> ok
<pitti> if someone wants to package it, sure
<pitti> but I don't intend to reintroduce a mixing daemon by default
<icecrash> hi
<crimsun> pitti: oh, so esd is out completely?
<pitti> crimsun: not yet, due to libgnome
<pitti> it's still used for sound events
<crimsun> right. Ok, thanks.
<bluefoxicy> btw I'm pseudo-banned from offtopic again
<bluefoxicy> nailoth got mad that I !ops'd when someone was looking for ops
<tseng> you aren't going to appeal his decision here
<tseng> sorry.
<bluefoxicy> well I can't do it in there, I can't talk :P
<tseng> nailoth is not here
<bluefoxicy> He's not there anymore either.
<tseng> I think you'll live.
<Seveas> bluefoxicy, -devel is not an escalation channel
<Seveas> try -ops
<bluefoxicy> ah
<desrt> is the archive down?
<Seveas> bw problems in london
<desrt> i see
<Seveas> <Znarl> Security is in London hosted by us.  It's slow because we're presently having bandwidth issues.
<Seveas> <Znarl> We hope to have our bandwidth issues resolved in about a weeks time.
<desrt> ow.
<Toadstool> doko: ok, thanks
<pitti> does anyone have a minute to help me testing something? (requirements: removable USB device)
<crimsun> pitti: sure.
<pitti> like an USB stick, hard drive, or so
<Kamion> QuestionMarkCoun: glad to hear it
<Toadstool> pitti: I can but it depends on whether an up-to-date edgy box is required or not, my laptop is kinda broken :/
<pitti> Toadstool: no, dapper will do fine, too
<Toadstool> ok
<Nafallo> pitti: I can :-)
<pitti> Toadstool, crimsun: if you have this device mounted, and do 'eject /dev/sda1' (or whatever the device is), does /dev/sda1 still exist after eject?
<pitti> Nafallo: great, see ^
<pitti> I need someone where the device doesn't exist any more
<pitti> for me it still exists, and I tested this case
<pitti> but the other case is more interesting
<crimsun> yes, it does still exist.
<pitti> crimsun: hm, same like here then; thanks anyway!
<Nafallo> still exist...
<Toadstool> still exits too
<Nafallo> until I remove the card from the slot...
<Toadstool> *exists even
<pitti> I got some bug reports where users confirmed that ejecting a device will remove the /dev node
<pitti> hm, ok, thanks, guys
<Nafallo> maybe they "ejected" by removing? :-)
<pitti> Nafallo: no, I'm pretty sure they did it right (I checked that with several different users)
<pitti> too bad, now I need such a case to verify my auto-unmount-notifications spec approach :/
<Toadstool> now, /me away, I really need to find a place to live in San Diego for the beginning of September and when you live in France it's not that easy :/
<bddebian> OK, who the hell is Patrick McFarland?
<crimsun> bddebian: 'diablo3d' or some variant on oftc
<bddebian> Hmm, OK
<Seveas> diablod3, one of lilos worst enemies 
<LaserJock> really?
<Spads> What did he do to earn this position?
<LaserJock> he's annoying for sure
<Surak> There's a bug which happens on dapper only if you have a intel chipset (with a intel integrated graphics) IF, and only if there's a nvidia video card inserted into the agp slot. What would be the correct component to file a bug against? The kernel, the module-init-tools (as the module intel_agp is not blacklisted in this case) or perhaps the linux-restricted-modules?
<Surak> Oh, this is amd64
<Kamion> mjg59: please make setup_usplash_config have a fallback if 'db_get xserver-xorg/config/display/modes' fails
<Kamion> mjg59: the current code is breaking all fresh installs of edgy
<Kamion> hm, I should file a bug instead. done.
<gnomefreak> Kamion: already did
<gnomefreak> if you mean the wont boot with usplash type bug
<Kamion> no, I don't
<gnomefreak> oh ok
<mjg59> Kamion: Ah.
<mjg59> Kamion: What's the precise failure mechanism?
<mjg59> Kamion: If it's hitting all of them, then presumably we need some mechanism to enforce configuration occuring after X
<mjg59> (iff X is being installed)
<LaserJock> is there any person in particular that takes care of -updates or is just like any other of the repos?
#ubuntu-devel 2006-08-04
<mjg59> Kamion: Ah, got it - I hadn't realised db_get errored on that
<mjg59> Kamion: Thanks, fixed
<zul> hey
<ajmitch> hello zul 
<bddebian> Heya
<Keybuk> not for the first time, I wish C had a two-dimensional switch
<bddebian> Heya Keybuk
<bddebian> A two dimensional switch?
<Keybuk> yeah
<Keybuk> so I can do switch (old_state, new_state) :p
<bddebian> Ah
<Keybuk> and each case statement lists the transitions
<Keybuk> rather than
<Keybuk> switch (old_state) {
<Keybuk> case STATE_A:
<Keybuk>     switch (new_state) {
<Keybuk>         case STATE_A:
<Keybuk> etc.
<Keybuk> switch (old_state, new_state) {
<bddebian> So create one.. ;-P
<Keybuk> case STATE_A, STATE_A:
<Keybuk> so much easier
<Keybuk> I don't think it's possible to create, sadly
<Keybuk> one can just play silly buggers with <<
<zul> ugh..
<lifeless> Keybuk: create a combined state value ?
<lifeless> Keybuk: (is that what you mean by << tricks ?)
<Keybuk> right
<Keybuk> #define STATE_CHANGE(old, new) (((old) << 16) | (new))
<Keybuk> switch (STATE_CHANGE (old_state, new_state)) {
<lifeless> yeah
<Keybuk> case STATE_CHANGE (STATE_A, STATE_A):
<lifeless> reasonable for C
<lifeless> I had a similar issue in python in bzr - not a state change mapping, but doing operations between two separate things
<lifeless> created a lookup object, and put methods on its instances, works sweetly ;)
* bddebian gives Keybuk more work to do...
<bluefoxicy>  2155 root      15   0  296m 217m 201m S  0.0 22.9   2:05.70 synaptic   <-- Amusing.
<desrt> the archive makes me sad.
<zul> anyone have spads' email address?
<bluefoxicy> wow.  usplash now draws a tiny box in the center of my screen; and then the screen blacks with a _ sitting there solid as if the machine locked out for like 30 seconds.  I guess that's some kind of progress.
<desrt> in what locations does ubuntu have actual offices?
<bluefoxicy> desrt:  looking for corporate training?
<desrt> making some vaguely pie-in-the-sky future plans :)
<bluefoxicy> (dad says ubuntu can't reach the business desktop because businesses want to hire out for training....)
<Lathiat> desrt: i think its london?
<Lathiat> dont quote me on that ;)
<bluefoxicy> Lathiat:  One convenient location.  In Africa.  </Aqua Teen Hunger Force>
<zul> desrt: montreal is one i think
<desrt> i know of this one
<Lathiat> http://www.ubuntu.com/employment
<Lathiat> lists london & montreal
<bddebian> Damn, I think they need an office in Philadelphia! :-)
<jsgotangco> there's an office in london
<bddebian> No, no, USA man :-)
<jsgotangco> you can always move to montreal heh
<bddebian> No, they don't let people like me into foreign countries ;-P
<mjg59> bluefoxicy: There's some sort of race in the svgalib vt switching code
<sladen> desrt: London, Montreal, sort-of Durbanville.  Oh and Canonical One, which is normally at Stansted, except during times of emergency when it is airbourne, providing backup desk and communications facilities for vital personel.
<desrt> durbanville near capetown?
<desrt> what about the theoretical isle of man office? :)
<zul> i thought it was just durban i didnt know there was a durbanville
<sladen> zul: https://launchpad.net/people/nick-zork
<zul> sladen: yep already sent him an email...thanks
<bluefoxicy> mjg59:  ah.  But Falcon's Eye is svgalib so in the interim we could play nethack :)
<bluefoxicy> sladen:  Canonical has air support?
<bluefoxicy> when the friggin' hell did Linux get its own army?
<Keybuk> sladen: Mark's still not managed to get an Internet connection for it though
<Keybuk> and you forget So Carlos
<Keybuk> desrt: the offices (aside from Sao Carlos) are all ops team though
<Keybuk> or support
<Keybuk> developers work from home
<desrt> nod
<desrt> how do you get paid?
<desrt> direct deposit to your local bank account in your own currency?
<Keybuk> usual UK PAYE arrangements
<Keybuk> it varies from country to country
<desrt> maybe better to ask one of the french or germans :)
<Keybuk> UK employees, for example, aren't employed by Canonical Ltd but by Fieldwave Ltd which is contracted by Canonical to do work for it
<desrt> that's an interesting factoid of which i was not aware
<Hobbsee> hi all
<Keybuk> this is pretty unique though, to do with law between the UK and IoM
<desrt> Hobbsee; hello.
<Hobbsee> wow really?
<desrt> Hobbsee; ya.  i'm seriously saying hello.  i'll say it again: hello :)
<Hobbsee> heh
<Keybuk> I believe there is a similar arrangement in .ca due to local contractor law, but don't quote me on that ... I don't really keep up
<desrt> is fieldwave a shell or do they actually do other stuff?
<Keybuk> but yes, in general, you're paid via whatever normal mechanism you'd expect
<Keybuk> it's an anthropomorphic companification
<bddebian> Heya Hobbsee
<desrt> ah.  i see.
<desrt> clear as mud :)
<Keybuk> vaguely standard company arrangement, aiui
<Keybuk> sladen dug out all the paperwork at one point
<Keybuk> he used to have it on the web, dunno if he still does
<whiprush> keyyyyyyyybuk!
<mjg59>     if (__svgalib_go_to_background)
<mjg59>         (__svgalib_go_to_background) ();
<mjg59>     __svgalib_flipaway();
<mjg59>         if((__svgalib_textprog&3)==3){
<mjg59>            pid_t child;
<bddebian> Heya whiprush
<mjg59>            if((child=fork())==0){
<mjg59>            execv(__svgalib_TextProg,__svgalib_TextProg_argv);
<mjg59>            } else {
<mjg59>            waitpid(child,NULL,0);
<whiprush> hi guys.
<mjg59>            };
<mjg59>         };
<mjg59> Clearest. Code. EVER.
* sladen has it somewhere.  But according to the terms under which I accquired it I'm not allowed to give it to anyone else...
<Keybuk> it could be worse
<Keybuk> I used to have an employment contract with Demon Internet Ltd, which has a wholly owned subsidary of Thus Plc
<Keybuk> but I used to get paid by ScottishPower Plc
<whiprush> Keybuk: so, network-manager, you still want to kill people or do their .7 plans make you happy?
<Keybuk> and all our equipment was owned by Thus Group Plc
<Keybuk> etc.
<Keybuk> whiprush: .7 plans?
<whiprush> http://live.gnome.org/NetworkManagerToDo
<Keybuk> oh, you mean 0.7 ?
<whiprush> yeah
<Ignite_> are there gtk+ 2.8 packages in the repos?
<Hobbsee> whiprush: do we have an eta on 0.7?
<whiprush> no idea, that's why i was asking
<whiprush> although, if past history is to be a gauge it'll probably be out a few weeks into ubuntu's freeze. :-/
<Hobbsee> whiprush: ah right
<Hobbsee> heh
<Hobbsee> whiprush: which freeze was that?  oh, feature freeze?
<whiprush> yeah.
<whiprush> iirc they always release things when ubuntu is frozen.
<whiprush> and that makes scott angry. :)
<LaserJock> whiprush: hehe, I sort of read that as "when hell freezes over" :)
<mjg59> Oh god they've implemented locking through insanity
<bddebian> heh
<Ignite_> nvm
<desrt> oh man.  i saw a textbook once that used ints for locking
<mjg59>     forbidvtrelease = 1;
<mjg59>     if (forbidvtacquire) {
<mjg59>         forbidvtrelease = 0;
<mjg59>         return;
<mjg59>     }
<mjg59> Yeah, that's never going to be a problem in a signal handler
<desrt> their lock function, i swear, looked like this:
<desrt> lock(int l)
<desrt> {
<desrt>   while (l);
<desrt>   l = 1;
<desrt> }
<desrt> now boys and girls... tell me at least 4 things wrong with this function
<crimsun> that's nearly as awesome as if (true && false)
<desrt> crikey.
<Hobbsee> heh
<bddebian> Hey, is that MY code? ;-)
<Keybuk> whiprush: *shrug* I'm not really bothered by n-m this cycle
<Keybuk> if Debian update their packages, and the changes are useful, we can merge them
<whiprush> Keybuk: heh
<Hobbsee> whiprush: i think that's an invitation for you to take it over :P
<Hobbsee> or someone else to
<Keybuk> we're "a few weeks into freeze" already, after all
<whiprush> that ^J guy still around?
<zul> Hobbsee: be my guest
<Hobbsee> zul: i know StevenK was looking at it.  i was just the tester.
<ajmitch> Hobbsee: don't tempt me
<Hobbsee> ajmitch: heh
<Keybuk> Hobbsee: at the moment, I don't see why we need to diverge much from Debian
* Hobbsee notes that wpa with madwifi actually works now :P
<Hobbsee> Keybuk: true
<zul> Hobbsee: but you are looking for things to do arent you :)
<Keybuk> the kind of help that n-m needs is actually kernel people fixing wireless drivers
<zul> Keybuk: there is no kernel bugs
<Hobbsee> zul: heh.  yes and no.  i have to fix whatever fubar'd here first.  and i didnt fubar it.
<Keybuk> Hobbsee: yeah, I fixed that
<Keybuk> it bugged me that my laptop didn't work
<Hobbsee> Keybuk: yay :)
<Keybuk> it was siretart's fault
<Hobbsee> Keybuk: hehe.  thanks :)
<Hobbsee> Keybuk: haha.  isnt everything his fault?  *g*
* Hobbsee sees the new target as siretart, instead of ajmitch 
<Keybuk> whiprush: tbh, I can't see 0.7 being released much before edgy, if at all
<ajmitch> Hobbsee: thanks
<zul> night
<Hobbsee> ajmitch: :P
<whiprush> Keybuk: agreed
<Ignite_> anyone know where i can find the file tag_c.h? (from taglib seems to be missing from the package, is this a bug?)
<crimsun> libtagc0-dev.
<infinity> Ignite_: Please take support questions to #ubuntu
<Ignite_> thanks, i tried searching with apt-file but nothing came of it so assumed it wasn't in a package
<Ignite_> infinity, ok no worries
<bddebian> Heya infinity
<mjg59> Holy christ this code makes me sad
<bddebian> Keybuk: Still about?
<Keybuk> yeah
<bddebian> Keybuk: Are we stil using squashfs for the installer?
<Keybuk> we're using it for the LiveCD, if that's what you mean
<bddebian> Keybuk: I don't see any actual changes in your changelog entry? :-)
<Keybuk> which?
<Hobbsee> is someone around to upload kde-systemsettings to main for me, please?
<bddebian> http://changelogs.ubuntu.com/changelogs/pool/universe/s/squashfs/squashfs_2.2r2-2ubuntu2/changelog
<Keybuk> did you read the diff?
<bddebian> No not yet, just found that entry interesting :-)
<Keybuk> heh
<Keybuk>  -- Scott James Remnant <scott@ubuntu.com>  Fri, 26 May 2006 03:43:09 +0100
<Keybuk> note time/date
<Keybuk> that was Release Candidate day after 18 hours of debugging that
<Keybuk> I had gone slightly crazy
<bddebian> :-)
<Hobbsee> heh
<Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368969
<Ubugtu> Debian bug 368969 in squashfs-tools "Subject: rounding error causes generation of invalid filesystems" [Critical,Closed]  
<bddebian> That one I wasn't too worried about it's more the status indicator that Tolleg added?
<Hobbsee> Keybuk: who do i assign things to, to get main stuff uploaded via LP?
* Hobbsee has forgotten, having never done it this way before.
<Keybuk> "to get main stuff uploaded" ?
<Hobbsee> Keybuk: to get a patch into a package in main.
<sladen> Hobbsee: what patch, what package?
<Keybuk> there isn't a formal sponsorship/mentor procedure yet
<Hobbsee> sladen: bug 55135
<Ubugtu> Malone bug 55135 in kde-systemsettings "kde-systemsettings trying to overwrite /usr/share/desktop-directories/kde-settings-accessibility.directory" [Untriaged,Fix committed]  http://launchpad.net/bugs/55135
<Hobbsee> sladen: ^
<Hobbsee> Keybuk: right.  that's a bit useless then :P
<Keybuk> Hobbsee: e-mail one of the ubuntu-core-dev Kubuntu team members with the patch?
<Keybuk> or attach it to the bug?
<Hobbsee> no idea if they're around. might try that
<Keybuk> Riddell appears to be subscribed
<Keybuk> *shrug* it doesn't matter if they're around or not
<Hobbsee> Keybuk: it does depend on whether they read their email though :P
<LaserJock> surely they have a filter that send "Hobbsee" mail into a super special, high priority mail box ;-)
<Hobbsee> LaserJock: heh
<Hobbsee> LaserJock: no, not under "Hobbsee" - it's under "she who carries a big pointy stick and isnt afraid to use it on people"
<Hobbsee> LaserJock: get it right :P
* Hobbsee isnt that much of a bitch.  really.  :)
* bddebian is an idiot
<bddebian> Debian maintainer added progress and bugfix code to dpatch..
<Burgundavia> Hobbsee: didn't you go for main upload privs at the last tb?
<Hobbsee> Burg
<Hobbsee> Burgundavia: yeah.  didnt get them.
<Burgundavia> ah, too bad
<Hobbsee> Burgundavia: they were in a rotten mood, and it's only been two weeks since i got MOTU.  that was the main problem.
<Hobbsee> Burgundavia: seems longer than that though.
<bddebian> Would linux-headers-2.6.17-5 replace linux-headers-2.6.17-1-all ?
<crimsun> only if there's an explicit entry in debian/control
<bddebian> crimsun: squashfs build-deps linux-headers-2.6.17-1-all
<jdub> o/~ welcome to hotel motufornia, such a lovely place o/~
<ajmitch> interesting..
<Hobbsee> um, okay?
<LaserJock> jdub: hehe, awesome
<TheMuso> hehe
<jdub> maybe you guys could do the lyrics :)
<LaserJock> jdub: but we already have the HeMan theme song :/
<TheMuso> jdub: Well whered you get the idea from in the first place?
<bddebian> "By the power of Greyskull.."
<jsgotangco> on a dark deserted rack server...
<bddebian> Ubuntu disk in my haaand..
<bddebian> I reformatted Windows...
<jdub> TheMuso: hobbsee checking in but never leaving
<TheMuso> um ok
<Hobbsee> sfllaw: please dont point people at amarok bugs until 1.4.2 is released and in the archive :) - just saw your blog post on the planet
<Hobbsee> oops, i thought that was in -bugs
<pitti> Good morning
<Burgundavia> morning pitti
<pitti> Hey Burg
<pitti> Hey Burgundavia 
<Hobbsee> hi pitti, Burgundavia 
<Burgundavia> greetings encore, Hobbsee
* pitti gives Hobbsee a good morning hug
<pitti> . o O { gah, my panel is broken }
* Hobbsee hugs pitti in return :)  hi you :)
<Burgundavia> Kinnison: sad you have left us :(
<desrt> legs@
<desrt> erp
<desrt> hello, pitti
<Burgundavia> desrt: arms@ ?
<desrt> Burgundavia; lots of biking
<Burgundavia> ah
<desrt> actually.. not even that much.. only a few km, but high gears and fast
<pitti> hey desrt 
<desrt> pitti; we were wondering earlier
<desrt> pitti; does ubuntu put money directly into your bank account with direct deposit?
<Hobbsee> desrt: canonical, surely
<desrt> Hobbsee; not so surely.  see scott.
<Hobbsee> desrt: well, certainly not "ubuntu" anyway.  didnt think ubuntu was a company
<desrt> chill, -pedantic
<pitti> desrt: not ubuntu, of course, but canonical's bank does a bank transfer, yes
<desrt> cool.  thx.
* Hobbsee wonders why desrt wants to know
<desrt> evil plans.
<jdub> desrt: 'see scott'?
<desrt> i need to know if my distruption of the world's financial network will have a significantly negative impact on ubuntu
<desrt> jdub; scott is payed via some non-cononical company
<jdub> desrt: UK employees
<desrt> jdub; due to some weird arrangement required because cononical is isle of man
<desrt> jdub; right.  but it was enough to place a bit of doubt in my mind if the rest of europe had a similar setup
<jdub> desrt: even so, "ubuntu" is not correct in any case :-)
* desrt meant ubuntu as a sort of generic umbrella term for any ubuntu-involved companies
<HrdwrBoB> and any sort of linux
<HrdwrBoB> or indeed, software
<jdub> desrt: would that include the ubuntu marketplace and partners?
<desrt> i dualboot my laptop: ubuntu and ubuntu?
<jdub> desrt: these distinctions do matter :)
<desrt> jdub; i don't care.  whoever pays pitti's paycheques :p
<jdub> desrt: in which case "not ubuntu" is the important distinction
<desrt> chill, -pedantic :p
<jdub> it's not pedantry
<jdub> giving people the idea that ubuntu pays people really muddies things up
<desrt> right.  but everyone here knows what everyone else means
<Hobbsee> rotten thing.  konvi crashed.
<Burgundavia> desrt: it is very good distinction, remember it
<desrt> unless we have some onlookers
<Burgundavia> desrt: we work and live in a fishbowl
<jdub> desrt: i don't think that's true, which is why saying the right things is important
<desrt> two lost souls?
<desrt> jdub; to be totally honest with you, i'm always afraid that i don't know how to spell canonical
<ajmitch> desrt: at some point, if not now, there'll be fulltime developers employed by other companies to work on ubunt
<desrt> jdub; so i say 'ubuntu' instead to avoid the possible misspelling :)
<Burgundavia> ajmitch: doesn't HP pay lamont to do some work on ubuntu?
<desrt> ajmitch; how does that work, exactly?
<ajmitch> Burgundavia: not that I know of - it could be true
<jdub> desrt: (same way it does in gnome)
<jdub> Burgundavia: no
<desrt> jdub; not hardly
<Burgundavia> ajmitch: he was still doing sort of behind the scenes work when I was at UBZ
<desrt> jdub; the people who work on gnome are employed by redhat, novell, ...
<ajmitch> desrt: just as some debian developers are currently employed to do stuff
<jdub> desrt: ie. other companies.
<desrt> is this part of the idea of people subclassing ubuntu?
<jdub> desrt: the difference with ubuntu is that it's led by a company, but that doesn't preclude other companies working on it.
<desrt> then they will contribute stuff upstream too?
<jdub> either derivatives or directly on ubuntu itself
<jdub> just as companies contribute to all kinds of other projects
<jdub> commercially owned or not
<ajmitch> I noticed that some of the points in the partners programme is employing a core dev fulltiem
<desrt> redhat contributes to gnome because redhat sells gnome
* ajmitch needs to find a company like that to work for :)
<desrt> you can't really sell a (non-derivative) ubuntu
<jdub> of course you can
<jdub> look at the ubuntu marketplace list
<jdub> all those companies benefit from ubuntu itself
<jdub> and can contribute directly to it
<jsgotangco> they dont realize it
<jdub> (regardless of derivatives - the case for guadalinex is more obvious)
<desrt> aren't these support companise?
<jdub> yes
<desrt> hm
<jdub> and hardware companies
<jdub> and third party software companies
<ajmitch> it's often sold as a service rather than as a product - not really much difference
<desrt> ok
<jdub> why does imendio contribute to gnome?
<desrt> this makes some more sense now
<desrt> ubuntu as a platform
<jdub> (no one "sells" ubuntu btw)
<desrt> to do [insert your business idea here]  on
<jdub> (unless you count canonical selling ubuntu DVDs on amazon, but that's not in the same sense)
<jdub> that is definitely not where the value lies
<jamesh> jdub: and people reselling Ubuntu CDs on eBay :)
<desrt> k.  i sort of get it.
<jdub> jamesh: the forgotton value proposition
<jdub> 'forgotten'
<desrt> imendio contributing to gnome makes more sense than, for example, redhat
<desrt> (in terms of explaning the ubuntu thing)
<jdub> desrt: why? consider mepis.
<desrt> i don't know mepis
<jdub> desrt: it's just different companies seeing different value.
<jdub> mepis is a commercial derivative of ubuntu
<desrt> i see
<jdub> but you're confusing model with value
<jsgotangco> jdub: would linspire opening cnr to ubuntu a model or value?
<jdub> jsgotangco: er, that's not an either/or thing
<jdub> it's both and neither
<jdub> depending on whether you think it's sane or not
<jsgotangco> right
<jdub> though i wasn't really distinguishing between dumb and good models, and i don't think desrt was misunderstanding it on those terms either ;)
* desrt doesn't get model vs. value but now understands a few reasons why someone would pay for ubuntu devel work
* ajmitch is glad to see 1 NZ company as an ubuntu affiliate
<jdub> desrt: you confused distribution model with the value of ubuntu
<desrt> right.
<jdub> a random linux consultant doesn't need her own distribution to derive value from contributing to ubuntu
<pitti> Kamion: I'm a bit confused about the latest live images - they grew by a lot since yesterday, was this some experimental change which will be reverted, or do we need to kill more langpacks?
<siretart> Hobbsee: /me isn't guilty. for anything.
<Hobbsee> siretart: :)
<Hobbsee> siretart: okay then.  it's fun to blame random people anyway though :)
<ajmitch> Hobbsee: but not siretart. never siretart 
<Hobbsee> ajmitch: ah.  so i'l go back to blaming you
<Hobbsee> man totem is screwed.
<Hobbsee> ah.  totem-xine needs a dep on totem in dapper.  simple fix.
<Hobbsee> and edgy.
<Hobbsee> ajmitch: dont worry, you'll likely still get to upload stuff for me later anyway.
<Hobbsee> evening sabdfl 
<ajmitch> Hobbsee: lucky me
<pitti> hi sabdfl
<Hobbsee> ajmitch: hah.  this is the problem of being a core dev.  of course, i might ask pitti instead, if you prefer
<Hobbsee> it's not one of those evil kde things, either :P
<pitti> Hobbsee: erm, you want totem-xine to Depend: on totem? that would be wrong
<Hobbsee> pitti: why?
<pitti> Hobbsee: because totem is an empty metapackage which depends on -xine | -gstreamer
<pitti> Hobbsee: totem itself doesn't do anything
<Hobbsee> pitti: seeing as -gstreamer does.  and it all breaks if you try to actually install -xine
<Hobbsee> ah...didnt realise it was emtpy.
<Hobbsee> *empty
<Hobbsee> so it is :)
<pitti> Hobbsee: totem-gstreamer doesn't depend on totem either )
<Hobbsee> thanks.  ignore my idiocy.
* pitti hugs Hobbsee 
<pitti> hey dholbach 
<Hobbsee> hi dholbach!
<dholbach> good morning
<dholbach> hey pitti, Hobbsee!
<Hobbsee> pitti: aye.  i'm a first class moron tonight then.
<pitti> Hobbsee: it happens to all of us, don't worry
<sabdfl> hey Hobbsee, pitti
<dholbach> hey sabdfl
<sabdfl> some usplash loveliness, then.... blank screen for me
<Hobbsee> ah yes, so it's not my laptop just erroring at random?
<dholbach> sabdfl: same here (on my x40) - it takes ages for gdm to come up :/
* Hobbsee had a lot of trouble starting X when i booted up this afternoon.
<sabdfl> Hobbsee: what sort of laptop do you have?
<Hobbsee> dholbach: and kdm, then.
<Hobbsee> sabdfl: ah, toshiba a10 satellite?
<Hobbsee> Sysinfo for 'sarah': Linux 2.6.17-5-686 running KDE 3.5.4, CPU: Mobile Intel(R) Celeron(R) CPU 2.40GHz at 2394 MHz (4793 bogomips), HD: 9/22GB, RAM: 665/995MB, 101 proc's, 3.7h up
<dholbach> sabdfl: the harddisk is doing something, but i have no idea
<dholbach> on amd64 it doesn't happen to me
<Hobbsee> sabdfl: what information did you actually *want* from that question?
<sabdfl> Hobbsee: tosh
<Hobbsee> pitti: you didnt eat my brain, did you?  i'm seriously starting to wonder here...
<imbrandon> sabdfl: yea i'm fighting that same exact problem on one of my desktops and this laptop as we speak
<imbrandon> the usplash goodness and then a blank X screen
<pitti> Hobbsee: heh, that was just in return for you stealing mine yesterday :-P
<dholbach> maybe it'd help to install bootchart and inspect it afterwards :)
<Hobbsee> pitti: :(...but...but...
<pitti> heh, for me usplash doesn't work for me at all any more
<pitti> svgalib goodness, I suspect
<sabdfl> i'm sure mjg59 will nail it, i saw a late upload to usplash last night so he's on a roll
<imbrandon> pitty looks awefull strange compared to my x86 on this iBook
<Hobbsee> what, three in 2 days or something?
<imbrandon> pitti: even 
<imbrandon> heh
<pitti> Riddell: \o/ I just converted /usr/share/hal/scripts/hal-system-storage-mount to use pmount
<imbrandon> pitti: yay 
<pitti> so KDE can now mount through hal and I can still sleep :)
<imbrandon> yup yup 
<imbrandon> dholbach: you said gdm took forever to come up, how long is forever , i get a black screen for ~30 then i just kill kdm and use console
<imbrandon> s/~30/~30 min
<dholbach> 30 MIN?
<dholbach> holy cow - no... maybe a minute or two
<imbrandon> yea x seems borked for my x86 at the moment , like sabdfl i get uspalsh goodies then a black screen , swap to vt1/2 and no x server errors
<imbrandon> i'm scared to upgrade my ppc till i fugure out what it is
<imbrandon> s/fugure/figure
<imbrandon> complains about a few fonts missing but thats normal
<sabdfl> i can start in recover mode, then init 2 and it all comes up fine
<imbrandon> hrm lemme try that, dident think to do that
* imbrandon headdesks
<sivang> hmm, that's cool - http://ubuntu.wordpress.com/2006/08/03/first-ubuntu-billboard-spotted/
<imbrandon> sivang: yea , we should have some more goodies like that on theFridge soon too ( soon == ~24hrs )
<imbrandon> heh
<Nafallo> morning
<hunger> imbrandon: Yeap, usplash is not really working well at the moment. It turned keyboard echo of my passphrases on:-)
<kagou> hi
<pitti> hi kagou 
<doko> Kamion, infinity: please approve openoffice.org-amd64 for dapper-proposed
<imbrandon> ahh yea , dident even have to goto single user mode , just disable "splash" ( read usplash ) on kernel parms
<imbrandon> then kdm is happy
<Kamion> mjg59: thanks for that
<pitti> Kamion: good morning!
<Kamion> mjg59: for the record it would be really very tedious to arrange for usplash to be installed after X; I'd have to rip it completely out of the part of the installer where it's done at the moment (using custom code because we make sure it's installed just before the kernel) and put it somewhere completely different
<Kamion> mjg59: so if I can avoid doing that it will make me happy. :)
<Kamion> pitti: you mean the dapper live images, or edgy?
<pitti> Kamion: dapper
<RicardoPerez> pitti: hi. i'm waiting for the daily langpacks updates from yesterday. any news about that? thanks
<Kamion> pitti: I'll have a look in a bit, try to figure out what's up
<Kamion> doko: done
<doko_> seb128, dholbach: what happened to /etc/pango/pango.modules in edgy?
<pitti> RicardoPerez: the packs were built yesterday
<seb128> doko_: same as in dapper?
<pitti> RicardoPerez: but there are only new -en, -es, -fi, -fr, -fa, pt, -ru, and -zh packages, the rest of languages didn't see any updates since the recent -base update
<seb128> doko_: 
<seb128> pango1.0 (1.12.2-0ubuntu2) dapper; urgency=low
<seb128>   * move /etc/pango/pango.modules to /var/lib/pango/pango.modules
<seb128>     and ship a default version in the package. This fixes a bad
<seb128>     race during the upgrade of pango (ubuntu: #41297).
<seb128>     update-pango-modules uses the new path too
<seb128>  -- Michael Vogt <michael.vogt@ubuntu.com>  Wed,  3 May 2006 18:02:28 +0200
<doko_> seb128: at least I don't have the conffile in my edgy chroot
<seb128> doko_: cf changelog I just copied
<mvo> doko_: that changed during the dapper cycle
<pitti> hey seb128, bonjour
<seb128> hi pitti
<seb128> pitti: how are you?
<pitti> RicardoPerez: hm, apparently Rosetta didn't build a new tarball since July 25
<pitti> seb128: after hacking hal/gvm this morning and yesterday, I feel great :)
<RicardoPerez> pitti: mmmmmm
<doko_> seb128, mvo: you know that I love these things not fixed or mentioned for ia32-libs-gtk?
<pitti> RicardoPerez: I'm afraid I need carlos for that
<RicardoPerez> pitti: after apt-get update && apt-get dist-upgrade, there's nothing to reinstall
<pitti> RicardoPerez: yep, as I said, I didn't get any new data for over a week
<seb128> doko_: I don't know what about ia32-libs-gtk enough to figure it doesn't respect the pango config 
<RicardoPerez> pitti: oh, ok. can you get the actual .po files from Rosetta and rebuild newer langpacks?
<mvo> doko_: me neither, sorry
<pitti> RicardoPerez: no, as I said, I need carlos for that; I don't have the necessary access
<RicardoPerez> pitti: it's strange to have an empty template in Rosetta and a not-empty .mo file in langpacks...
<doko_> seb128, mvo: but if a default version is shipped now, why can't I find it in my chroots?
<seb128> doko_: in /var/lob/pango ?
<RicardoPerez> pitti: oh, bad
<seb128> doko_: in /var/lib/pango ?
<seb128> doko_: if it's not I probably broke it with the merge from Debian, I'll have a look later (I'm on dapper atm)
<doko_> seb128: but it's not copied into /etc/pango?
<seb128> doko_: no, pango look to /var/lib/pango
<seb128> "<seb128>     update-pango-modules uses the new path too"
<doko_> seb128: for dapper as well?
<seb128> yep
<RicardoPerez> pitti: but I can download the .po files directly from Rosetta, and then I can convert it into a .mo file to replace the actual one...
<doko_> ohh, nice :-/
<seb128> doko_: cf the changelog I copied, "Michael Vogt <michael.vogt@ubuntu.com>  Wed,  3 May 2006 18:02:28 +0200"
<seb128> doko_: since may
<doko_> seb128: did you adapt the ia32hack for pango?
<seb128> probably not since I don't understand what this hack is about
<doko_> you would, if you start OOo on amd64 ;-)
<seb128> I though it was just to usr /usr/lib32
<seb128> s/usr/use
<doko_> we have to find the correct pango.modules.
<seb128> "result = SYSCONFDIR "/pango32";"
<doko_> and that's certainly not /var/lib/pango, because that file mentions /usr/lib
<seb128> looks like it's using the SYSCONFDIR from pango
<seb128> so no need to update anything?
<doko_> seb128: I'm looking at bug 55016
<Ubugtu> Malone bug 55016 in openoffice.org-amd64 "Filechhoser dialog shows strange symbols instead of text" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55016
<seb128> hum
<seb128> and copying to pango.modules to /etc/pango fixes the issue?
<seb128> that's weird it doesn't happen on dapper if that's due to that
<pitti> RicardoPerez: well, right, but you don't want to do that for the millions of .po files the language packs have...
<dholbach> ooo seems to look in /usr/lib/pango/1.5.0/modules instead of /usr/lib32/pango/1.5.0/modules instead
<pitti> RicardoPerez: also, what was the real problem again? are es_ES out of date, or is the problem that es_ES is present in the first place? (i. e. you actually want es and es_ES was removed)
<seb128> dholbach: does copying pango.modules to /etc/pango fixes the issue?
<doko_> I have to find out, but apparently /etc/pango32/pango.modules cannot be found anymore (although it's shipped in ia32-libs-gtk)
<doko_> and then apparently the default config file is used, referencing /usr/lib, and not /usr/lib32
<seb128> doko_: the patch from mvo does that:
<seb128> -    file_str = g_build_filename (pango_get_sysconf_subdirectory (),
<seb128> +    file_str = g_build_filename ("/var/lib/pango/",
<seb128>                                  "pango.modules",
<seb128>                                  NULL)
<seb128> so right, it's possible it break your hack :/
<dholbach> seb128: there's a pango.modules in /etc/pango already
<doko_> seb128: nice, that basically breaks the ia32 hack ...
<seb128> that's why I didn't want of that hack in the first place
<seb128> hacks are easy to break, etc
<mvo> doko_: so what can we do to fix it? pass a configure parameter ?
<RicardoPerez> pitti: the problem is that there's a bad translation in es_ES that was removed in Rosetta but isn't reflected in the new langpacks. Actually, the es_ES locale must not be used for translation; we must use "es" locale instead (and, if you look at the es_ES templates in Rosetta, you can see they are empty). So, the /usr/share/locale-langpack/es_ES/LC_MESSAGES/ directory must be empty (or near empty).
<seb128> anyway, I'll have a look later on it
<doko_> seb128: well, you can argue that hardcoded module paths are broken as well :/
<pitti> RicardoPerez: ah, ok, then I completely misunderstood you yesterday
<doko_> seb128: I'll do it know, we need it for the CD build.
<seb128> doko_: lot of application look for the config file at a known place
<seb128> ok
<seb128> doko_: it was broken on dapper then?
<seb128> weird than nobody noticed
<RicardoPerez> pitti: the es_ES templates in Rosetta was cleaned some time ago, and the old langpacks was ok, but it seems that the new langpacks are using old templates (before the "cleaning" process)
<RicardoPerez> pitti: the bad translation is very annoying in Spanish, because formats the clock applet incorrectly (say "vie ago de 4" instead of "vie 4 de ago")
<pitti> RicardoPerez: yep, now I understand the problem, that's easily fixable
<RicardoPerez> pitti: oh, great! what can I do to help you?
<pygi> pitti, whenever you have time and if you have time... ^_^
<pitti> RicardoPerez: oh, that should be fine
<pitti> pygi: what's the second part of that sentence? :)
<doko_> seb128: ia32-libs-gtk wasn't uploaded after May 3, but it will be broken on the new CD's ...
<pygi> pitti, the libburn discussion :P
<seb128> doko_: ah, ok
<RicardoPerez> pitti: of course, I'm at your orders :)
<doko_> seb128: ok, the fix is to just ignore the patch, when running the binaries on amd64.
<doko_> Kamion: ^^^ that's a showstopper for the CD's; preparing new pango1.0 and ia32-libs-gtk
<pitti> Kamion: can I upload new language-pack-[gnome-] es-base packages to dapper-updates to remove the erroneous es_ES po files?
<pitti> Kamion: see RicardoPerez 's problem above
<Kamion> doko_: which, dapper or edgy?
<Kamion> pitti: yes
<pitti> Kamion, RicardoPerez: ok, I uploaded new Spanish gnome/kde/rest -base packages to dapper-updates
<pitti> RicardoPerez: sorry for the confusion
<doko_> Kamion: dapper
<doko_> and edgy
<RicardoPerez> pitti: oh, sorry me for to be very confused.... I'm Spanish and my English is not very good :)
<RicardoPerez> pitti: and thanks again :)
<pitti> no problem
<pitti> RicardoPerez: the removal of po files is something I do not notice and will generally break
<pitti> RicardoPerez: I have to talk with carlos to find a better process for that
<RicardoPerez> pitti: sometimes is not a totally removed po files... sometimes is only an almost empty po file (like gnome-panel-2.0 template in es_ES locale, which has only one string translated...)
<Kamion> doko_: hm, ok
<Kamion> doko_: please let me know when there's something in the updates queue to review
<pitti> RicardoPerez: empty PO files should DTRT, but nonempty es_ES files with wrong translations are the ones that hurt
<pitti> brb, door bell
<RicardoPerez> pitti: yes... there's a group of problems related one with another...
<RicardoPerez> pitti: when carlos arrives I'll try to talk with him in order to clarify the problem (he's Spanish so my very bad English will not be a problem per se) :)
<RicardoPerez> pitti: so, now, I will wait for the updates in dapper-updates, isn't it?
<pitti> RicardoPerez: yep, they should arrive soon after Kamion acks them
<doko_> seb128: mvo's "patch" should have been called hack as well ...
<RicardoPerez> pitti: ok, great... i'll wait for that and i'll tell you if all is ok :)
<RicardoPerez> pitti: thanks again
<pitti> great
<seb128> doko_: no doubt about that
<mvo> doko_: err, my "patch" did fix a spectacular upgrade failure that was there for ages. basicly a upgrade of pango made everything explode between unpack and configure because there just was no working pango anymore
<mvo> doko_: see #41297 for the rationale. I'm open for better solutions of course
<seb128> mvo: I don't think he discuss the fix, just the hardcoded path for the config file :)
<mvo> seb128: aha, ok. I could do a version that add "--with-pango-modules-path=" to configure but I guess that would be a bit intrusive for dapper
<seb128> mvo: please don't, I think doko it just going to fix it with an another simple and ugly hack :p
<doko_> mvo: doesn't help; it's pango, which hardcodes library pathes in config files.
<seb128> mvo: I don't want to start having to run autoconf and patching the configure.in etc
<Kamion> pitti: oh, we need to reupload ubuntu-meta for dapper if nothing else ...
<Kamion> removing packages from the live seed requires that
<doko_> mvo, seb128: please see http://people.ubuntu.com/~doko/pango/, if you "like" the beautified hack
<mvo> doko: look good to me
<mjg59> Kamion: Only X can do the resolution probing
<doko> Kamion: pango1.0 uploaded to dapper-updates
<seb128> doko: there is already a 0ubuntu2 to dapper-updates
<seb128> doko: I've uploaded it yesterday
<Kamion> mjg59: does usplash do update-initramfs on installation?
<seb128> doko: change looks fine to me other way
<doko> Kamion: is seb128's pango1.0 upload processed?
<Kamion> yes
<sladen> Kamion: yes
<Kamion> Listing ubuntu/dapper (UNAPPROVED) 0/0
<Kamion> mjg59,sladen: I suppose usplash *could* be installed later, then. It'd be slower and possibly not very elegant, though - need to think about it
<Kamion> mjg59: and in any case you do still need a fallback for if X never gets installed at all
<sladen> Kamion: personally I side with you about not /depending/ on X configuration having taken place.  If the information is available, use it.  If it's not, carry on as normal
<Kamion> at the moment it never gets a chance to use information from X configuration on a fresh install, though, which isn't ideal
<doko> ahh, ok pango1.0 not yet in the archive ...
<sladen> Kamion: we could have a simple small usplash-xorg-resolution-something that depends on both usplash and xorg having been configured.  That way it can save and poke the values somewhere /if/ X ever does get configured
<Kamion> ick
<Kamion> messy having configuration spread out over multiple packages
<Kamion> having it all in usplash and arranging to install usplash after xorg would be better than that ...
<Kamion> doko: the source should definitely be there - the binaries are just being published now
<mjg59> Kamion: If X isn't installed, it just defaults to 640x480
<doko> Kamion: 0ubuntu3 uploaded
<gnomefreak> dappers kernel was compilied with gcc3.4?
<Kamion> mjg59: right, so that'll *work*, but isn't optimal
<mjg59> Kamion: Exactly
<Kamion> doko: I'm not sure I buy that. Won't we have exactly the same "debconf's GNOME frontend won't work during upgrades" problem while upgrading amd64 systems, which is what mvo fixed?
<doko> Kamion: he unconditionally changed the location to /var/lib/pango/pango.modules
<Kamion> doko: I'd have thought that we would always want to use /var/lib/pango/pango.modules, but maintain /var/lib/pango differently
<doko> when running the i386 binaries on amd64, you'll find there the amd64 modules, but OOo like the 32bit ones 
<Kamion> doko: yes, but will /etc/pango32/pango.modules or whatever it is be valid during upgrades?
<Kamion> grr, the pango packaging is awful, the .orig.tar.gz has a load of stuff in debian/
<doko> /etc/pango32/pango.modules is just a static config file, it's not handled by any debconf script
<doko> whole gnome packaging is awful ;-)
<Kamion> /etc/pango/pango.modules isn't handled by any debconf script either
<doko> mvo: maybe you could explain, what you did fix in the pango upgrade problem
<Kamion> the point is that debconf *uses* pango and explodes when /etc/pango/pango.modules refers to older pango modules
<Kamion> why would the same problem not happen with /etc/pango32/pango.modules?
<doko> Kamion: the patch isn't applied on amd64. see the #ifdef ...
<StevenK> Kamion: Have you got a sec?
<mvo> doko: the problem was that the pango.modules is generated in the postinst. a new pango can change the location of the modules. this means that between unpack and configure pango (and therefore all of gtk) is unsuable - pretty bad when e.g. debconf-gnome is used
<doko> Kamion: debconf doesn't use the 32bit version
<mvo> but it seems to me that if the patch changes only the behaviour in a 32 bit envoronment that should be safe
<mvo> because the native pango would still find the right modules
<Kamion> doko: hmm, ok, I suppose that's a bit better
<Kamion> StevenK: yea
<Kamion> yeah
<mvo> it is still the same race as before for any 32bit applications started between unpack/configure
<Kamion> right, it's wrong in principle but probably won't break
<mvo> yeah
<Kamion> and maybe not even wrong - after all it's unconfigured
<Kamion> it's just that everything debconf uses has to behave as if it's essential: yes to some extent
<Kamion> and work even when unconfigured
<dholbach> doko: pango packaging != gnome packaging :)
<StevenK> Kamion: I've done an upload of krecipes multiple times and it seems to disappear into the ether. Are you able to poke incoming and see where it's going?
<mvo> well, true. but it is not "really" unconfigured because it ships most of the modules it needs 
<mvo> so there is really no good reason (IMHO) to break like it used to be
<doko> Kamion: is there still space on the amd64 ubuntu/edubuntu CD's? thinking about adding the 32bit gnome accessibility libraries
<Kamion> doko: space on Edubuntu is unlikely
<Kamion> doko: Ubuntu, unsure yet
<Kamion> my inclination is not for dapper; I don't want to change desktop
<Kamion> feel free for edgy
<Kamion> StevenK: what weird mutant thing are you doing with your .changes files?
<Kamion> http://librarian.launchpad.net/3600297/dpVGqQ36OFwV1RAhLkWdzLbT064.txt
<Kamion> UploadError: Format out of acceptable range for changes file. Range 1.5 - 2.0, format 0.7
<StevenK> Ahhh.
<StevenK> That .changes file is special. Very special.
<Kamion> it's a known bug that you didn't get mailed - cprov is working on fixing that
<StevenK> So special it killed Soyuz, way cool.
<Kamion> linda testing or something?
<ajmitch> congratulatoins
<StevenK> Kamion: Not exactly.
<Kamion> it didn't kill Soyuz any more than any other malformed upload :)
<StevenK> Kamion: I was trying to get -4ubuntu1 into the archive, and the orig between Debian and Ubuntu is different.
<Hobbsee> oh, so *that's* why it keeps dying.
<Kamion> traditional approach would be to build normally with the Debian working tree (patched as necessary) and the Ubuntu .orig.tar.gz in ..
<StevenK> I did.
<StevenK> However, I can't then run genchanges since I build using pbuilder, since debian/files doesn't exist.
<Kamion> debian/files should only be needed for binary uploads
<Kamion> dpkg-genchanges -S shouldn't care
<StevenK> Now I'm trying to remember why the hell I couldn't get it to generate.
<Kamion> if (not $sourceonly) {
<Kamion>     $fileslistfile="./$fileslistfile" if $fileslistfile =~ m/^\s/;
<Kamion>     open(FL,"< $fileslistfile") || &syserr(_g("cannot read files list file"));
<StevenK> At least I haven't caused you to be cross with me.
* StevenK regenerates the .changes file after checking he has the right .orig
<StevenK> Oh, now I remember. I didn't want the orig to be uploaded.
<StevenK> Mainly because it's close to 8MB.
<Kamion> StevenK: if the orig is already in the archive, then just don't use -sa; dpkg-genchanges won't include it in a -4ubuntu1 upload anyway
<Kamion> (by default)
<Kamion> if the orig is not already in the archive, then you need to upload it either way
<StevenK> Duh.
<Kamion> doko: accepted; I'd like something less gross to be sorted out in edgy though ...
<Kamion> the duplicate sysconfdir munging is pretty horrible
<StevenK> I should read the dpkg-genchanges man page some more. :-/
<StevenK> Let's see if Soyuz chokes on this .changes file.
<StevenK> Kamion: Thanks for your help, by the way.
* Hobbsee watches as it curls up and dies.
<Hobbsee> oh dear, it's choking on the floor again.
<doko> Kamion: too late ;) no, I really do not want to spend much more time on the ia32-libs packages.
* gnomefreak wonders what shes killing
<Hobbsee> gnomefreak: nothing, nothing at all.  i dont kill things all the time, you know.
<gnomefreak> darn
<gnomefreak> :)
<Hobbsee> gnomefreak: would you like me?
<Hobbsee> to?
<gnomefreak> :)
<gnomefreak> the hot water heater guy if he doesnt get out here today please
<Kamion> doko: not needing ia32-libs any more because 64-bit OOo works would qualify as less gross :P
<StevenK> gnomefreak: The plumber?
<gnomefreak> StevenK: no the propane isnt getting to the tank for some reason
<dholbach> doko: how's 64bit ooo looking? is it too 'edgy' for edgy? :)
<StevenK> gnomefreak: Ahh, the "Gas man"
<doko> Kamion, dholbach: yeah, just install the openoffice.org-*-experimental packages, if you can live without java, the wizard and the binfilters.
<StevenK> "Gas man" always made my juvinile mind crack up.
<gnomefreak> lol
* gnomefreak lives without java:)
<dholbach> doko: oh, that's a good start for amd64 already
<zul> hey
<ajmitch> hi zul 
<sabdfl> \http://blogs.sun.com/roller/page/coldrick#ubuntu_filesystems_usb_drives_and
<sabdfl> do we do better in edgy?
<mjg59> sabdfl: You were looking for me yesterday?
<sabdfl> could someone post a reply on his blog?
<sabdfl> mjg59: yes, to ask about Compaq / HP tablets
<sabdfl> what mouse driver should I use? X is up fine
<mjg59> sabdfl: What model?
<sabdfl> TC1000
<sabdfl> old
<mjg59> Right
<mjg59> I think there's some mad custom driver for that one
<sabdfl> ok, not essential, i have a zillion other things to get working on the box first :-)
<sabdfl> anybody know much about matchbox?
<mjg59> Hm.
<mjg59> Is video reinit broken on edgy?
<mjg59> It would seem to be.
<mjg59> thom: Did you have a chance to check on your x60s?
<mjg59> My X40 just showed the symptoms of a failed vbestate restoration
<Kamion> sabdfl: see http://wiki.ubuntu.com/ReplacementInit for the USB-in-fstab thing; it's known breakage in dapper, but needs a big subsystem replacement to fix in edgy - Scott's working hard on it
<sabdfl> ok, cool - thanks!
<Kamion> I've posted a comment to that effect
<mjg59> sabdfl: Hrm, it claims to need some bizarro kernel driver
<mjg59> sabdfl: I'll take a look
<mjg59> sabdfl: Can you possibly stick the contents of all the files in /sys/bus/pnp somewhere?
<mjg59> Oh, this driver is gross
<mjg59> It bangs the PCI registers directly. I'm sure this can be done via ACPIPNP
<mjg59> rodarvus: Any chance of including the driver from http://linux-tablet-pc.dhs.org/tc1k_drv.html ?
<thom> mjg59: no, i didn't :(
* jdub hugs mjg59, thom
<jdub> morning
<jdub> pants off
<jdub> etc
<rodarvus> mjg59, sure, do you need it *really* urgently, or it can wait a few hours?
<thom> good morning jdub
<mjg59> rodarvus: Not urgently
<mjg59> rodarvus: It'll need some kernel loving anyway
<rodarvus> mjg59, btw, I've seen you were the last uploader of xserver-kdrive - do you mind if I upload a new upstream version based on a current cvs checkout? (the old version ftbfs due to X.Org 7.1, apparently)
<mjg59> rodarvus: Not in the slightest
<rodarvus> 'k, thanks!
<StevenK> rodarvus: That's also neatly listed on merges.u.c/universe-manual.html
<mjg59> rodarvus: I'm quite short on time for the moment, so feel free to do anything with anything I've touched
<rodarvus> StevenK, the debian changes basically say "stolen package from ubuntu", and changes the mantainer :)
<jdub> i hear mjg59 is going to finish his thesis today
<rodarvus> today!
<StevenK> rodarvus: Haha
* pitti arghs at xml.sax - damn, it can't be so hard to read an UTF-8 xml file without getting UnicodeEncodeErrors all over the place
<mjg59> Haha
<rodarvus> mjg59, just for reference, I'm uploading xserver-kdrive_6.6.1+cvs20060804-0ubuntu1
<mjg59> rodarvus: Cool
<pitti> GAR
<pitti> does anyone have experience with parsing xml in Python?
<dholbach> pitti: what do you need?
<jdub> pitti: use elementtree :-)
<Kamion> I did a bit of it in debian-installer a while back
<Robot101> elementtree ftw
<Kamion> build/util/help-to-gfxboot.py - I just used xml.dom.minidom
* dholbach would have suggested python-libxml
<Kamion> my documents were small enough for DOM not to be a problem
<pitti> I tried xml.dom.minidom and xml.sax now
<pitti> both just throw UnicodeEncodeError once there is a non-ascii char
<pitti> dholbach, Kamion: http://people.ubuntu.com/~pitti/tmp/update-maps
<pitti> writing to the console works, but as soon as I write into a file, or pipe through less, or something, it breaks
<mjg59> Anyone here having the problem with X not starting cleanly with the new usplash?
<pitti> I already googled, played around with various encoding tricks, but nothing helped
<pitti> mjg59: hm, I have the problem that usplash entirely disappeared, but X works fine
<mjg59> pitti: What resolution is your screen?
<pitti> mjg59: 1280x1024
<mjg59> pitti: Hm. Ought to work.
<mjg59> pitti: This on PPC or x86?
<pitti> mjg59: amd64
<mjg59> pitti: Right
<mjg59> pitti: Does it work from the console?
<pitti> mjg59: how do I check?
<mjg59> pitti: Change to the console, sudo usplash -x 1280 -y 1024
<pitti> mjg59: that just generates an unkillable usplash process
<pitti> mjg59: but no graphics output at all
<mjg59> pitti: That's fun
<mjg59> pitti: Can you strace it and try to figure out what it's doing?
<pitti> mjg59: d'oh, I get an EPERM when trying to attach to the current process
<pitti> maybe because it's in deep kernel sleep
<mjg59> pitti: Ha
<mjg59> pitti: Ok, that's going to be awkward
<mjg59> What state is it in?
<pitti> D+
<mjg59> Weird
<mjg59> Anything in dmesg?
<pitti> oh, wait
<pitti> I know why
<pitti> mjg59: it's my crash reporter, it tried to gdb it, but now gdb hangs forever, too
<mjg59> Oops
<Kamion> pitti: debian-installer/build/util/help-to-gfxboot.py definitely processes UTF-8 data correctly
<pitti> so apparently it crashed
* pitti cleans up
<pitti> Kamion: thanks, will look at that
<Kamion> pitti: I had to .encode("UTF-8") whenever writing to sys.stdout
<Kamion> which is annoying but AFAICS required
<pitti> Kamion: ah, that might do the trick indeed; I tried various codecs calls, but apparently not to the right place
<pitti> mjg59: ok, so running it under gdb immediately segfaults
<pitti> mjg59: bt is totally unusable, just one ?? line and the rest of memory can't be accessed
<mjg59> pitti: What version do you have?
<mjg59> And what graphics chipset is this?
<Spads> zul: ping
<zul> Spads: pong
<Spads> zul: So I see a tarball now in your Xen packages dir
<pitti> mjg59: usplash 0.4-6, nVidia Corporation NV34 [GeForce FX 5200]  
<Spads> That has all relevant patches applied?
<zul> Spads: you should download the tarball and the dsc file and do a dpkg-source -x *.dsc
<Spads> thanks
<pitti> mjg59: I'll build a debugging enabled version
<Spads> zul: but you wager the xen-image package ought to just install, right?  
<zul> it should in theory but i havent run the kernel on dapper
<mjg59> pitti: Ah, right
<zul> you might have dependency problems though
<mjg59> pitti: We have issues with x86emu and nvidia
<Spads> zul: with the kernel?
<mjg59> The vbesave call falls over entirely
<Spads> the build-deps seemed to satisfy cleanly last I tried, and I don't see anything new in that .dsc
<mjg59> pitti: I ought to be able to fix the segfault - hang on a sec
<mjg59> pitti: Can you grab the source for usplash and then edit svgalib/src/x86-common.c
<mjg59> And change REAL_MEM_BASE to 0x01000 and REAL_MEM_SIZE to 0xa0000
<mjg59> Then see if that fixes the segfault
<zul> Spads: yes because th kernel is made for edgy
<Spads> hmmm
<Spads> I'll have a look
<zul> Spads: you can probably get the .config and download the xen-source deb and install it
<pitti> mjg59: done, building
<mjg59> pitti: Ta
<jdub> whoa
<jdub> hula upload
<pitti> mjg59: still segfaults :(
<mjg59> pitti: Hm
<pitti> mjg59: ah, but now I have the -dbgsym.ddeb for free
<mjg59> pitti: In the same way?
<mjg59> Ah, cool
<Lathiat> is this UUID= stuff for root= not workign with raid devices known?
<Lathiat> its driving me nuts it keeps reverting :/
<pitti> mjg59: http://paste.ubuntu-nl.org/19685
<madduck> Lathiat: which mdadm version?
<Lathiat> 2.4.1-6ubuntu1
<mjg59> pitti: Jesus, what's it doing that low
<mjg59> pitti: Ok, erm. Your job (should you wish to accept it or not) is to find a way to get REAL_MEM_BASE low enough that that read can succeed
<pitti> mjg59: a 'way'? you mean experimenting with different values?
<mjg59> pitti: Last time I tried, anything below 0x1000 didn't seem happy
<mjg59> Oh, wait, hang on a moment
<mjg59> pitti: Are you sure that backtrace is good?
<pitti> mjg59: no, it's just what gdb's 'bt full' thinks is appropriate
<mjg59> Here, line 68 of usplash_svga.c is int i=0
<pitti> but it looks a bit like confusing ints with pointers
<mjg59> Yeah
<mjg59> I'm guessing that the x86emu code is confusing it
<jdub> zul: is there a COW solution for use with xen guest filesystems?
<zul> yeah i found a bunch of them yesterday let me dig it up for you
<zul> jdub: http://jailtime.org/
<zul> jdub: also if you want to use xen-tools http://www.debian-administration.org/articles/396
<Spads> zul: got some time to help me with a few build problems?
<zul> Spads: ill try..
<jdub> zul: hrm, that doesn't seem to mention anything about doing COW
<pitti> Kamion: works great now, thank you!
<Kamion> cool
<jdub> "It's hardly CoC."
<jdub> ^ whoa
<jdub> first time i've seen CoC used like that
<zul> jdub: like images of other distros?
<jdub> zul: having a base image and then COW files for multiple xen guests
* jdub wonders if it would work with some crazy loopback union dm foo
<zul> ah...
<zul> jdub: http://wiki.xensource.com/xenwiki/COWHowTo
<jdub> ahar!
<jdub> ooh, parallax sounds interesting
<pitti> Hobbsee: still here?
<Hobbsee> pitti: heya!
* Hobbsee wonders what she's screwed up now
<pitti> Hobbsee: sorry for the delay, I'm writing that 'requestsponsor' script now
<pitti> Hobbsee: heh, nothing :)
<Hobbsee> pitti: ahh...nice :)
<pitti> Hobbsee: unfortunately Malone doesn't allow email attachments, so we have to improvise a little
<Hobbsee> pitti: ahh.
<Hobbsee> pitti: your request merge script works relaly nicely, when the package is in debian.
<Hobbsee> well, when the changelogs.debian arent borked.
<Hobbsee> :P
<StevenK> Or when changelogs.debian.net isn't broken.
<pitti> Hobbsee: right, I take that script and transform it :)
<StevenK> Damn, missed.
<pitti> Hobbsee: changelogs.d.o is just lagging a bit
<Hobbsee> hehe
<StevenK> It's actually d.n
<pitti> right
<pitti> Hobbsee: something like 'debdiff oldversion.dsc newversion.dsc | requestsponsor' should be suitable, do you agree?
<pitti> Hobbsee: or 'requestsponsor debdiff' (I'm going to support both)
<Hobbsee> pitti: sounds good to me
<rodarvus> mjg59, pig
<rodarvus> oops
<rodarvus> ping :D
<rodarvus> damn keyboard
<pitti> rodarvus: *tsk* :)
<rodarvus> the url you passed to me is for a quite old driver (for X.Org 6.8)
<rodarvus> but I believe this driver has been imported into modular X (and we already have it) , as xserver-xorg-input-fpit
<mjg59> rodarvus: Hi
<mjg59> rodarvus: Oh, cool
<mjg59> Sorry for the confusion!
<rodarvus> mjg59, np
<rodarvus> btw, I've just checked. they're the same driver, renamed symbols everywhere (tc1k->fpit), slightly different licensing, and -fpit has support to one extra device.
<Hobbsee> rodarvus: did you break anything while you were at it?  some people seem to be expecting edgy to be usable, for some reason.  maybe they need to be taught a lesson?  :P
<rodarvus> nah, unfortunately the driver was already there - no chance to break it ;)
<Hobbsee> rodarvus: ah darn!
<rodarvus> but I'll upload an updated xorg-server in 1-2 hours, so stay tuned
<Hobbsee> rodarvus: heh.
<Hobbsee> great....
* Hobbsee gets out her long pointy stick, and polishes it up, for using.
* StevenK wipes the sarcasm off that "great".
<rodarvus> quite likely I'll upload ati and nvidia drivers later today too
<Hobbsee> bah.  go ahead and break them.  i dont use them :P
<rodarvus> Hobbsee, so theres a good chance you'll have your X broken by the end of the day :)
<rodarvus> oh
<Hobbsee> rodarvus: yay!
<rodarvus> what driver do you use?
<Hobbsee> hehe
<rodarvus> I can brea^Wfix that too
<Hobbsee> rodarvus: i've got an intel integrated card - which is great!
<Hobbsee> hah
* Hobbsee waves her long pointy stick threateningly at rodarvus 
<thom> echo "xserver-xorg-video-i810 hold"|sudo dpkg --set-selections #lalal
<thom> a
<thom> <-- coward, since he just got the thing to run in the right mode
* rodarvus waves the X sodomotron remote control
<rodarvus> thom, Breaks: xserver-xorg-video-i810 (<< <newversion>)
<thom> bah, that's cheating
<rodarvus> yeah
<Hobbsee> rodarvus: heh
* Hobbsee is glad that the X master has a source of humour :)
* Hobbsee cant deal without humour.
<rodarvus> I'm in a good mood today :)
<rodarvus> it's not like this all the time, though >:-)
<Hobbsee> rodarvus: well, yeah.  of course.  even i, hobbsee-who-takes-everything-possible-as-a-joke, gets pissed off about things
<seb128_> rodarvus: breaking xorg is running away until monday then? :p
<seb128_> nothing like breaking edgy on friday afternoon ;)
<rodarvus> seb128_, I was planning on take the day off monday :D
<seb128_> hehe
<jdub> Spads: http://perkypants.org/blog/2005/11/05/1131151921/
<seb128_> good idea :p
<Spads> jdub: http://crackmonkey.org/badpeople.jpg
<dholbach> rodarvus will love to see bug 54596 fixed
<Ubugtu> Malone bug 54596 in soyuz "karma for uploads" [Medium,Confirmed]  http://launchpad.net/bugs/54596
<Spads> jdub: them cameras got Mexican Magical Realism.
<jdub> ooh
* jdub notices that the wiki page is no longer locked... muhaha
* jdub fixes
<rodarvus> dholbach, yeah, this way I'd be able to have 1 third of the Karma you and seb128_ have :)
<jdub> Spads: dude, you are wearing a slashdot tshirt
<Spads> jdub: that's because it is 1997
<jdub> is that your excuse?!
<jdub> i suppose it's reasonable
<dholbach> rodarvus: we'll see ;)
<rodarvus> and actually, I don't think I uploaded more than any of you two
<rodarvus> you have done a *lot* of work on GNOME
<dholbach> rodarvus: i'm sure there'll be a tv show soon where you can select prizes for your karma points
<rodarvus> (about 250 uploads, since July 5th)
<rodarvus> yeah, that would be nice :)
<rodarvus> or they could give Playstation III to the top 5 karma
<seb128_> that would be cool ;)
* seb128_ goes to triage some bug to be sure to stay there
<rodarvus> seb128_, you're on top 5, and we're not counting uploads yet :)
* dholbach tries to get ahead of Kamion
* dholbach wonders if he's in the top10
<zul> dholbach: heh...that show was the old wheel of fortune in the states
<rodarvus> dholbach, kamion has 400k karma points than you
<rodarvus> quite likely you're on top 10
<dholbach> YAY :)
<doko> Kamion: ia32-libs-gtk_16.2 in dapper-proposed
<bddebian> Hello
<bddebian> Damn, the list of Universe merges is growing...
<bddebian> BenC: ping?
<rodarvus> siretart, ping
<rodarvus> siretart, do you plan to update qemu soon?
<rodarvus> our qemu package is currently outdated WRT to Debian, and broken, WRT booting OLPC qemu images
<zul> rodarvus: *ahem* xen..
<rodarvus> zul, yeah, that could be another option indeed
<zul> we have 3.0 in universe
<zul> for edgy that is
<rodarvus> but I need to use another kernel on the host, right?
<zul> well you need to use the dom0 kernel to start xen but you can use either dom0 or domU for the guest host
<rodarvus> oh
<rodarvus> OLPC kernels have no specific support on themselves :/
<zul> ah ok..
<bddebian> qemu is on the Merges list but I wasn't sure if I should touch it or not
<zul> rodarvus: then qemu might be better..
<rodarvus> I plan to ask for a UVF exception for qemu in 6 hours from now (~ 9:00 PM UTC) if I get no answer from sirestart until then
<madduck> Lathiat: what exactly is the problem with mdadm?
<Lathiat> madduck: well it just sits "Waiting for root filesystem" on boot
<Lathiat> if i cahnge root=UUID=xxx to root=/dev/md2 in grub
<Lathiat> it boots fine
<Lathiat> (i also changed my fstab)
<madduck> Lathiat: ah, that has nothing to do with mdadm then.
<Lathiat> right, tho my question wasnt about mdadm but "are we aware this is broken" :)
<madduck> that's a filesystem issue, not sure grub even supports UUID filesystem mounts.
<bddebian> rodarvus: If qemu is in Universe you don't need a UVF exception
<rodarvus> bddebian, a UVF exception from mdz is needed before merging the new qemu
<Lathiat> madduck: well its been intentionally changed by the edgy stuff, so
<madduck> Lathiat: but you mentioned raid, so my highlight got triggered. :)
<Lathiat> madduck: ah right
<Lathiat> i dont think its grub 
<Lathiat> it still has root(hd0,0)
<Lathiat> bu root= on the linux command line
<Lathiat> which i assume initramfs cares about
<rodarvus> bddebian, in theory you need - its just more lax
<Lathiat> madduck: what do you do with raid?
<Lathiat> madduck: involved with the raid tools project or something?
<tseng> rodarvus: universe has not had a UVF
<madduck> i am the mdadm maintainer
<tseng> rodarvus: so nothing to except
<Lathiat> madduck: ah :)
<bddebian> rodarvus: That would be news to me but I don't know shit apparently :-)
<tseng> rodarvus: universe freeze is much later.
<Lathiat> yeh im pretty sure this isnt mdadms fault :)
<rodarvus> oh, ok then
<rodarvus> I was mostly uploading stuff to main - thought UVF was enforced for universe already too
<hunger> Looks like only physical filesystems get a /dev/disk/by-id/entry... lvm, etc. does not.
<spike> hi thre
<spike> is there any known prob with security.ubuntu mirror?
<spike> it's timing out
<pitti> spike: yes, it's known; bandwidth issues in the DC
<elmo> spike: security.ubuntu.com shouldn't be - it'll be slow, but not timeing out
<spike> I see, tnx
<pitti> times out for me as well sometimes
<pitti> as well as archive.u.c
<spike> actually iy's not the only one timing out
<spike> yeah, was gonna say that
<spike> will wait, ta
<dholbach> ** sfllaw is giving a motu school session #ubuntu-motu-school about bug triage
<Riddell> Kamion: ubiquity kde frontend needs some fixes in dapper
<Riddell> Kamion: http://muse.19inch.net/~jr/tmp/kde-ubiquity.diff
<bddebian> rodarvus: qemu from Debian FTBFS :-)
<Riddell> Kamion: no bzr branch I'm afraid
<Riddell> Kamion: changelog "remove existing widgets when launching qtparted and mountpoints pages"
<rodarvus> bddebian, yeah, I plan to fix that.
<rodarvus> bddebian, you want to upload this package?
<bddebian> rodarvus: Go for it :-)  I was just trying to "help"
<siretart> rodarvus: it is on my list, I wanted to do it tonight
<rodarvus> if so, make sure it boots olpc images, please
<rodarvus> siretart, nice, I'll let you do it, then :)
* bddebian crawls back to his hole
<rodarvus> bddebian, help is always appreciated!
<bddebian> rodarvus: If you say so. :-)
<rodarvus> siretart, I'd like to test your updated qemu package when it is ready (can be after upload)
<siretart> rodarvus: ok. I'll ping you then
<mdz> rodarvus: qemu is in universe
<zul> hi mdz
<rodarvus> mdz, thanks, I know - I just thought UVF was already enforced for universe (just more easy to get around with)
<pitti> BenC: ping
<sfkhooper> hey is this the right channel to get tips on how to resolve a compiler problem in ubuntu?
<sfkhooper> is that a no then?
<rodarvus> sfkhooper, no, that would be #ubuntu-toolchain, but only if you're finding bugs in the compiler itself
<sfkhooper> no, setup problem
<rodarvus> sfkhooper, people do not watch irc 100% of their times
<rodarvus> then #ubuntu, quite likely
<rodarvus> (or #gcc, but *shrugs*)
<sfkhooper> ok, thanks
<rodarvus> np
<pitti> rodarvus: welcome to the sponsor team, and congrats for being the first member :)
<rodarvus> pitti, heh, my pleasure :)
<rodarvus> btw, LP is timing out on https://launchpad.net/people/pitti/+packages
<rodarvus> pitti, I was wondering how sponsored packages show up
<pitti> rodarvus: heh, I know
<pitti> rodarvus: don't use mine, I have millions of packages (due to the langpacks)
<rodarvus> (if the sponsored person appears as uploader, so we can track it in six months from now :) )
<rodarvus> ohh
<pitti> rodarvus: yes, it does
<rodarvus> nice
<pitti> rodarvus: Changed-By: should normally be the sponsoree
<pitti> rodarvus: the only bit from the sponsor is the .dsc signature
<rodarvus> *nods*
<pitti> rodarvus: i. e. debuild -S -k<yourkeyid>
<rodarvus> pitti, btw, just curious - do you plan to update thunderbird to 2.0RC in time for Edgy?
<rodarvus> (since the same is likely to happen for Firefox)
<icecrash> hi
<BenC> pitti: pong
<gnomefreak> it will be stable before release ( i dont see why not)
<Kamion> Riddell: thanks, looking
<Kamion> Riddell: hmm, I thought I found something in the qt documentation saying that del did .remove() under the covers. evidently not
<Kamion> maybe only if the python del gets turned into a C++ del expediently
<Kamion> Riddell: how are your tests going aside from that?
<Riddell> Kamion: otherwise the qtparted back/forward stuff all works
<Kamion> kewl
<gnomefreak> Riddell: found a problem with 3.5.4 in edgy adn konq/mouse gestures
<Riddell> gnomefreak: what's that?
<gnomefreak> without trying to open link konq mouse icon bounces and lags bad cant do anything uless i move mouse than locks back up than move mouse again to free it
<gnomefreak> s/uless/unless
<gnomefreak> id say about 2 days this has been going on
<Kamion> mdz: https://dogfood.ubuntu.com/distros/ubuntu/dapper.0 - does that look ok to you?
<mdz> Kamion: this is the dapper-before-point-release snapshot?
<Kamion> (^-- only accessible if you have the private launchpad client certificate, so most of you probably can't see that, but it'll be on production soon enough)
<Kamion> mdz: yes
<mdz> Kamion: I don't suppose I can login to the box and verify it properly
<Kamion> mdz: do you have an account on mawson?
<mdz> maybe
<mdz> I really can't tell if it's OK over http
<Kamion> mdz: I can give you the diff from dapper to dapper.0 though, it's pretty trivial
<Kamion> well, actually I was interested in making sure that the naming was OK too
<mdz> I do have an account
<Kamion> /srv/launchpad.net/ubuntu-archive/ubuntu/dists/dapper.0
<mdz> the naming is fine, and please do point me at the diff
<Kamion> or ~cjwatson/dapper.0.diff
<mdz> Kamion: no changes to restricted Packages files? that doesn't seem right
<mdz> don't we have a new kernel in there?
<LaserJock> mdz: could you apply the debdiff on Bug #54821 to matplotlib in dapper-updates?
<Ubugtu> Malone bug 54821 in matplotlib "python-matplotlib won't install" [Untriaged,Confirmed]  http://launchpad.net/bugs/54821
<mdz> or is it ABI-compatible?
<mdz> LaserJock: ->Kamion; it may be a bit late
<Kamion> mdz: dapper has not been updated yet
<Kamion> so no Packages files differ between dapper.0 and dapper
<LaserJock> mdz: grr, matplotlib in -updates now is broken
<mdz> Kamion: oh, this is meant to be basically unchanged
<Kamion> yes
<mdz> +Description: Ubuntu Dapper.0 6.06
<mdz> that's a little odd
<Kamion> mm, that's the displayname I guess
<Kamion> LaserJock: yes. I forget whether you're in -core-dev?
<mdz> Kamion: did you try running the archive comparator?  it's smarter about things like Packages.{gz,bz2}
<LaserJock> Kamion: I'm not, but it is a Universe package, does that make a difference?
<Kamion> mdz: no, there didn't seem any point when none of the Packages files had changed
<Kamion> LaserJock: please go ahead and upload then
<mdz> the uncompressed ones haven't anyway
<LaserJock> Kamion: k
<Kamion> mdz: nor have the md5sums of the compressed ones
<Kamion> or at least if they did then the Release file wasn't affected
<pitti> rodarvus: maybe, I don't know yet
* mdz squints harder
<Kamion> cjwatson@mawson:~$ grep -- '^-.*Packages' dapper.0.diff
<Kamion> cjwatson@mawson:~$
<mdz> Kamion: looks OK to me
<Kamion> yes, "Dapper.0" is the displayname
<Kamion> also shows up at the top of https://dogfood.ubuntu.com/distros/ubuntu/dapper.0
<Kamion> that's free-form, so I can make it be something else - perhaps just "Dapper"?
<Kamion> or "Dapper r0", although I'm wary of introducing rN notation when we're not using it elsewhere
<Kamion> I think "Dapper" would probably be best
<Kamion> (changed on dogfood)
<doko> Kamion: pitti found one more upgrade error in the dapper-proposed packages, plus 2.0.3 does seem to have at least some regressions (bug 55167, 55181), so maybe it's not yet ready for dapper-updates. I could fix the upgrade error now, but it won't be in the archive before tomorrow morning
<Ubugtu> Malone bug 55167 in openoffice.org "OOo Calc crashes when using Auto filter" [Untriaged,Confirmed]  http://launchpad.net/bugs/55167
<Ubugtu> Malone bug 55181 in openoffice.org "Cut does not work when Auto Filter applied" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55181
<Kamion> doko: ok, thanks. if there are regressions at this point, let's leave it out of the point release and consider it for a future update
<Kamion> doko: thanks for trying
<doko> Kamion: ia32-libs-gtk 16.2 still needs to be included
<Kamion> doko: oh yes, I'll review that now
<Kamion> doko: accepted
<Kamion> mvo: you should really put a newer app-install-data-commercial into edgy at some point; it won't get synced in automaticaly
<Kamion> +l
<mvo> Kamion: ok
<philipacamaniac> is seb128 the totem-gstreamer maintainer?
<Kamion> evand_: migration-assistant binaries accepted into universe, FYI
<RicardoPerez> pitti: hi! I'm just installed the updated langpacks and all works like a charm. thanks a lot :)
<thom> mjg59: oh, also, with new usplash the boot process doesn't change to the correct  vt when it needs to prompt me for my crypted volume password
<doko> dholbach: not the nicest day for the Biergarten ...
<Kamion> mdz: +Build-Depends: debhelper (>= 4), libcairo2-dev, graphviz-dev (> 2.8-2.1), libxml-parser-perl, pkg-config, gettext, libgnomeui-dev, libgtk2.0-dev
<dholbach> doko: if it's too harsh we can still go somewhere else
<Kamion> mdz: archaic dependency relationship syntax there in graphviz-cairo ;-)
<mdz> Kamion: heh, I'm surprised lintian didn't warn about that
<mdz> or dpkg-checkbuilddeps
<jdub> hey mdz 
<mjg59> thom: Yeah, there's a bug open about that
<mjg59> thom: Which version of usplash?
<mdz> jdub: hello
<thom> 0.4-6
<mjg59> thom: Can you try -7 or -8 and see if they behave the same way?
<gnomefreak> mjg59: did you release -7 or -8?
<thom> i can
<mjg59> Oh, no you can't
<thom> ok
* mjg59 stabs svgalib
<thom> i won't then. fine.
<doko> dholbach: but maybe we should meet there?
<mjg59> Hang on a minute
<dholbach> doko: of course
<dholbach> doko: everybody's going there
<dholbach> doko: i'll check how to get there and soon be off
<mjg59> thom: Ok. -9 when it hits the archives.
<siretart> rodarvus: now I remember about qemu: I already merged on on jul 30, but the package ftbfs in edgy on amd64
<jdub> how do we request for things to attempt a build again?
<rodarvus> siretart, but you didn't upload it, did you?
<siretart> rodarvus: no. I don't  like to upload broken packages
<Kamion> jdub: ask somebody in the launchpad-buildd-admins team to requeue it
<siretart> rodarvus: I can send you the buildlog if you like
<siretart> I fear the problem is with our linux-header package
<jdub> Kamion: ta
<jdub> 'course, none of them are around ;)
<dholbach> have a nice weekend everybody
<siretart> debian builds against linux-kernel-headers_2.6.13+0rc3-2.1, we build against linux-kernel-headers_2.6.17-5.16
<gnomefreak> you too dholbach 
<rodarvus> siretart, I'd really like to have this package ready soon (say, in the next two days) - I can try to fix this if you want.
<siretart> rodarvus: sure just go ahead. I fear you will have to adapt qemu for the new linux-headers
<bddebian> Same issue for squashfs :-(
<rodarvus> siretart, I'll take it this evening then, thanks!
<siretart> bye dholbach 
<bddebian> Enjoy dholbach
<dholbach> bye siretart, bddebian
<mdz> sfllaw: how goes the test plan for knot 2? we have a bunch of features in beta now
<bddebian> Is BenC about yet?
<Kamion> mdz: could you do https://launchpad.net/distros/ubuntu/+addrelease based on https://dogfood.ubuntu.com/distros/ubuntu/dapper.0, please?
<Kamion> mdz: +addrelease requires launchpad.Admin, so I can't do it myself
<Kamion> mdz: the Soyuz guys are ready, although they're unsure about spitting out dists/dapper.0 as yet; that may have to happen later - but it'll all be safely in the DB in the meantime
<mdz> Kamion: not sure what you mean by "based on ..."?
<mdz> I assume it should be based on the Dapper on prod
<mdz> and the new release called dapper.0
<Kamion> mdz: I mean filling in the same arguments as I did on dogfood
<Kamion> yes
<mdz> oh, I see
<Kamion> I've asked cprov if he can figure out some way to cowboy the creation of dists/dapper.0
<mdz> based on /+edit
<Kamion> apparently it requires a "careful" publisher run, which without cowboying will rewrite /dists/dapper
<Kamion> +edit and +admin
<cprov> Kamion: all old _dists_ files, in fact 
<Kamion> right
<Kinnison> Kamion: Umm, why do you have to careful the dapper distrorelease?
<mdz> Kamion,cprov: what should Version be for this?
<Kamion> mdz: 6.06
<mdz> that won't clash with the existing Dapper?
<Kamion> Kinnison: 16:29 < cprov> Kamion: I needed to run a *careful* publishing to get _apt-stuff_ (pkglist, overrides, etc) for dapper.0
<Kinnison> umm, odd
<Kamion> mdz: apparently it doesn't matter, and we'll be updating the existing dapper to 6.06.1 soon enough anyway
<mdz> ok
<Kamion> making the archival copy have the same version as the original seems prudent
<mdz> https://launchpad.net/distros/ubuntu/dapper.0
<Kamion> mdz: thanks. can you make that status supported in +admin too?
<mdz> done
<mdz> hmm, no it isn't
<mdz> it rejected my submit because I didn't fill in a changes list
<mdz> seems like a bug to me
<Kamion> yes, I got that too on dogfood
<Kamion> I just filled in dapper-changes@lists.ubuntu.com
<mdz> filling in dapper-changes for now
<mdz> did you file the bug?
<bddebian> Damn bashisms
<Kamion> mdz: no, forgot to
<Kamion> shall I?
<mdz> I will
<Kamion> ok
<Kamion> mdz: needs to be "pre-release freeze" not "supported" for the moment, so that the publisher works properly
<Kamion> we'll then set it to supported and publish again
<mdz> oh
<mdz> done
<jdub> mdz: is there a part of the release process that involves unsticking broken builds in a systematic way (like the merge process)?
<mdz> jdub: there's a general "make sure everything has built and is buildable" process
<mdz> it's mostly an ongoing thing handled by infinity, but we do a full round of test builds at a couple of points during the release process
<jdub> right
<jdub> coo
<jdub> l
<jdub> do we know # unbuilt packages for each release?
<mdz> LP should be able to tell you that
<Kamion> britney can too
<Kamion> jdub: it's also in MilestoneRhythm
<Kamion> we don't bother running britney for released suites, but we do for edgy - http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt
<jdub> Kamion: that shows difference between source and binary?
<Kamion> jdub: yes
<Kamion> when all builds are up to date, there are zero differences
<tseng> beagle 0.2.7-1ubuntu1 python2.4-beagle(i386) 0.2.7-0ubuntu2 from 0.2.7-0ubuntu2
<jdub> oh, and that's just main? does the followup mdz's talking about apply to universe (maybe less vigorously)?
<tseng> i guess this just means its in NEW as opposed to me doing something wrong
<jdub> tseng: i noticed beaglefs was accepted - want to take it over? :)
<tseng> jdub: nope.
<tseng> jdub: I thought ajmitch signed up, though
* jdub will have to convince ajmitch 
<tseng> he listed himself as maintainer when he uploaded it
<tseng> because he knew you wouldn't last long :)
<jdub> he said he'd do debian uploads, but not sure he was willing to maintain it
<tseng> he wouldnt upload something to Debian w/o expecting to take care of it
<jdub> beaglefs is surprisingly cool
<jdub> we need to figure out how to best make use of fuse though
<wasabi_> I'm working on a ... sort of test case project on a fuseish thing to replace gnomevfs.
<wasabi_> Nobody likes that idea though.
<wasabi_> cd /fs/cifs/servername/share   etc
<wasabi_> Memories of autofs.
<bddebian> OK, I have squashfs building with linux-headers-2.6.17-5 .  Would someone want to check it over before I upload it?
<siretart> bddebian: what did you do to fix it?
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/dapper-to-current-proposed.sizediff <- package size changes for the packages on the powerpc alternate install CD from dapper release to now, including dapper-proposed
<Kamion> ignore the kernel stuff, that's an artifact of package name changes
<Kamion> jdub: we don't run britney for universe - last time I tried, I got bored and killed it after six hours
* Kamion builds alternate install CDs minus dapper-proposed, so that he can check out the size diff there
<elmo> Kamion: on drescher or somewhere else?
<terre1> hi. What is "dapper.0" ? edgy  6.10  (DEVELOPMENT)   dapper.0   6.06  (FROZEN)  dapper  6.06    (CURRENT)
<elmo> Kamion: and is britney still doing the NP stuff even in "show me uninstallables" mode?
<Kamion> elmo: I think I tried both rookery and drescher
<Kamion> elmo: probably, yes
<Kamion> at least I assume so from the vastly increased runtime for universe
<elmo> ah, ok
<Kamion> hmm, the total there is 5MB, that doesn't explain the 10MB diff in CD size
<Kamion> what is going on
<iwj> I have a machine with a newly-acquired and -configured ethernet interface, which has been set up using ifconfig et al.  For some reason I don't understand it insists on faffing about with ICMPv6 router and neighbour solicitations before it will let me do IPv4 over it.
<iwj> DoeS aNyBody know how I can hit this stupid behaviour over the head ?
<bddebian> siretart: Just build-dep linux-headers-2.6.17-5 instead of 2.6.17-1-all.  And fixed some bashisms in debian/rules
<Kamion> ok, I've LOST 5/6MB, this is seriously not funny
<bluefoxicy> Can someone move tremulous from multiverse to universe?  Apparently it's 1) Hosted on sourceforge; 2) GPL code and "The media is licensed under the CREATIVE COMMONS ATTRIBUTION-SHAREALIKE 2.5 LICENSE."
<bluefoxicy> as I understand Multiverse == redistributable but not under a Free license?
<Kamion> bluefoxicy: tremulous depends on tremulous-data, which is not free
<mjg59> CC 2.5 isn't considered free
<Kamion> main+universe is closed under dependency
<bluefoxicy> mjg59:  CC2.5 isn't a free license?
<mjg59> No
<mjg59> 3.0 should be
<Kamion> but next time, file a bug on the package in question and subscribe ubuntu-archive to the bug
<bluefoxicy> huh.  Why not?
<bluefoxicy> Kamion:  yes, #-motu is slapping me with that too
* iwj answers his own question.
<iwj> ip -f inet6 addr delete dev ${vif} local fe80::fcff:ffff:feff:ffff/64
<iwj> WTF??
<iwj> There must be a better way!
<bddebian> do be do be dooo
<Riddell> pitti: your cdbs upload failed to build
<Riddell> pitti: I have some changes to make but I'm scared to upload since then it'll be my responsibility :-/
<pitti> Riddell: curious, I just changed the cdbs-edit-patch script
<pitti> Riddell: don't worry, if your upload fails, too, I'll care for it on Monday
<jdub> hrm
<jdub> can anyone think of a relatively small, C-only, no shlib depends package?
<tseng> no shlib depends..
<Robot101> no libc?
<Kamion> *no* shlibdeps? not even libc?
<jdub> ha ha
<tseng> yarrrrr
<Robot101> Package: hello
<Robot101> Depends: libc6 (>= 2.3.2.ds1-4)
<jdub> libc is okay :-)
<Robot101> thats quite minimal :)
* tseng passes jdub the pipe.
<jdub> Robot101: hrm, maybe something slightly more interesting ;)
<Robot101> the GNU hello world, of course, reads your mail too.
<jdub> gosh i'm glad that hello is in main
<robertj_> https://wiki.ubuntu.com/AlwaysEnableUniverseMultiverse needs a DumbestIdea award
<jdub> hrm, i guess i could use procmail
<tseng> robertj_: I am sure you can easily understand the motivation
<tseng> It just needs a slightly different fix
<robertj_> tseng: yes, but I also understand the motivation to hit your high-school teacher in the face, but you don't do it
<tseng> jeez.
<robertj_> (ok, maybe overstating the point a bit ;)
<tseng> it is hardly a dumb spec
<tseng> a better fix imo would be making it easier to find packages in universe and enable it for use
<jdub> one of my high school teachers got married right when i was in the middle of a crush
<tseng> in $graphical-apt-frontend
<tseng> which isnt nearly as easy given how apt is built
<tseng> before assuming an idea is idiotic, I look at "#
<tseng> before assuming an idea is idiotic, I look at "Created: 2006-06-20 by MichaelVogt
<tseng> sigh, irssi
<tseng> mvo is a pretty brilliant fellow if you ask me.
<tseng> and understands apt and graphical package management better than both of us
<tseng> jdub: rough!
* robertj_ repents
* tseng gives robertj_ a cookie
<tseng> :)
<robertj_> mv cookie /proc/irc/mvo
<bluefoxicy> jdub:  a crush on your teacher is... kinda eww... way too old.
<robertj_> bluefoxicy: teachers might only be 23, it's not that unusual
<jdub> ...
<jdub> o/` IT'S NOT UNUSUAL... o/`
<mjg59> 23?
<bluefoxicy> robertj_:  I'm 21 and I wouldn't go near anyone >23
<mjg59> bluefoxicy: Tch.
<mjg59> You're missing out.
<Spads> jdub: you exposed a hole in my triggers
<Spads> 20:07  3: -publics -regexp 'o/~' -replace ''
* Spads adds o/`
<bluefoxicy> mjg59:  not at all, age of consent here is 16.  ANYWAY.
<jdub> Spads: haha
<Spads> 20:07  2: -publics -regexp '<3' -replace ''
<Spads> I also have interrobang
<Spads> and this one:
<Spads> 20:07  7: -publics -regexp 'lol' -replace '*drooling noise*'
<jdub> what if i say lollypop?
<Spads> jdub: I need to fix that
<jdub> ha ha ha
<Spads> 20:09 <jdub> what if i say *drooling noise*lypop?
<jdub> Spads: pro. ;)
<jdub> meanwhile
<jdub> roflcopter
<Spads> I think the lesson is: DON'T SAY LOLLYPOP
<jdub> llvm built
<bluefoxicy> llvm?  o_o
<bluefoxicy> Wait are you trying to do 686 Ubuntu by llvm'ing the 486 code through a binary optimizer to spit out 686 code?
<jdub> ahr, bollocks, it failed
<poningru> sorry to disturb but quick question
<poningru> who does shipit?
<poningru> that I can bother on irc
<jdub> o/` one fine day, you're gonna want me for your girl o/`
<zul> later..
<bddebian> Heya
<robertj_> what do you guys think of a red, yellow, green light for update urgency?
<robertj_> for instance, remote root woud be "red" while "obscure driver fix" would be green
<jdub> Spads: ping
<robertj_> or something of the sort, I suppose no emblem, local security issue, and "uhoh, openssh has been owned"
<Kamion> ahh
* Kamion spots why the powerpc CD grew - damn HFS hybridisation
<Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-dapper$ bzr pull
<Kamion> Using saved location: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.dapper/
<Kamion> bzr: ERROR: These branches have diverged.  Try merge.
<Kamion> how did that happen ...
<Kamion> ouch, there are a big pile of changes missing from the edubuntu.dapper seeds on bazaar.launchpad.net
* Kamion tries to resurrect them with a merge
<Kamion> ogra: have you tested the current http://cdimage.ubuntu.com/edubuntu/dapper/ bits at all?
<Kamion> ogra: the install CD will probably be broken - I'm regenerating it shortly
<Kamion> hmm, no janimo around
* Kamion mails him
<Kamion> Riddell: we need to cut down Kubuntu live a bit, probably language packs
<Mirv> is the new ubuntu-desktop/ubuntu-meta meaning that Finnish is not going be included on live-i386 6.06.1 CD:s? it'd be unfortunate for it to change now, though I guess you have to drop some if you have to drop some :(
<Kamion> Riddell: subtract 4MB or so off the currently reported CD size for powerpc
<Mirv> the guides etc. are now assuming (in screenshots) that the translations are there
<Kamion> Mirv: I'm afraid so
<Kamion> we just ran out of room as the language packs grew
<Kamion> fi has never been on the priority list (which is indexed by number of speakers); it just snuck in by virtue of being relatively early in the alphabet
<Kamion> Mirv: note that it was only ever there for i386, not for amd64 or powerpc
<Kamion> those architectures never had room for it in the first place
<Mirv> Kamion: yes, I actually gathered as much during dapper that it was in there by luck mainly (there's only 5 million of us, though quite a lot of computer users of course)
<Mirv> well, it's a problem that will be there anyway for some languages, unless edgy/edgy+1 can get this resolved with 7-zip&co
<Kamion> at this rate, Kubuntu is going to have to lose more than that
<Mirv> thanks for the info, I was just getting a clarification
<bluefoxicy> has anyone actually tested p7zip or lzma compresesd debs yet?
<Kamion> IMHO it's a flaw in the language pack system (the language packs wouldn't need to be so big if they only had what's needed for desktop, although that is not a remotely trivial change to try to make and would probably involve ditching language packs entirely to do halfway sanely, so I doubt it'll ever happen)
<Kamion> but there, we have to make do
* bluefoxicy also notes that better compressed debs won't help the LiveCD much if any, for obvious reasons.
<Kamion> bluefoxicy: considering current dpkg doesn't support them, probably not
<bluefoxicy> Kamion:  well, I was making the assumption that the suggestion involves adding such support.
<bluefoxicy> Also I thought I saw a spec on it a long time ago
<Kamion> Scott was to look at some point, yes, but it was low-priority
<Kamion> mdz: I've been meaning to ask - can we de-prioritise ue-partitioning-tool a bit? I don't think the remaining UI changes really qualify as Essential
<Kamion> in fact I personally believe ubiquity-advanced-partitioner is more important, based on ratio of complaints about the two parts of the partitioner
<Kamion> but either High or Medium would seem to make more sense
<mdz> Kamion: didn't it just inherit that priority from the pre-edgy spec?
<mdz> at any rate, yes
<Kamion> it did, yes
<mdz> it's not terribly clear from the spec which bits still remain to be implemented
<Kamion> set to Medium
<Kamion> it's the autopartitioning UI changes
<Kamion> the part we did was all the integration, which was definitely Essential
<Kamion> but we never had time for the mpt-designed UI
<mdz> dists/dapper-updates is significantly bigger than I expected
<mdz> 754M
<Kamion> I've noted that in the spec
<mdz> thanks
<Kamion> (crudely, but hey)
<Kamion> grr @ +assignedbugs vs. +specs?role=assignee - I can never remember which is which
<Spads> jdub: pong
<bddebian> Hmm, I take it --verbose isn't an option for dash?
#ubuntu-devel 2006-08-05
<zul> hola
<Kamion> bddebian: no - use -v
<Spads> jdub: unpong
<bddebian> Kamion: Thx
<Hobbsee> morning all
<rodarvus> hi Hobbsee 
<Hobbsee> rodarvus: i'm looking at the upgrades.  sure you didnt breka anything?  :P
<rodarvus> anyone with an amd64 edgy installation willing to test-build qemu for me?
<rodarvus> Hobbsee, nah, not yet :)
<rodarvus> but I have a full weekend in front of me!
<Hobbsee> rodarvus: hehehe....
<Hobbsee> rodarvus: should i get my long pointy stick out?
<Hobbsee> rodarvus: and polish it up, all ready to use on the people who break things?
<bluefoxicy> Hobbsee:  it's more fun to bludgeon people repeatedly with a blunt stick than it is to drive a pointy stick into them
<Hobbsee> bluefoxicy: well....if that's your preference, yes
<bluefoxicy> they don't stop moving as fast
<bluefoxicy> (in fact people are much more useful when they're still breathing and not full of holes)
<Hobbsee> hah
<ajmitch> rodarvus: I can build qemu if you like
<ajmitch> you have an updated source package available?
<rodarvus> yup
<rodarvus> just finished building it on i386
<rodarvus> didn't tested it yet, though :D
<ajmitch> it builds, ship it :)
<rodarvus> yeah!
<rodarvus> let me just dogfood it a little while before uploading
<ajmitch> ok
<ajmitch> still want me to do a test amd64 build before you subject the archives to it?
<rodarvus> amazing, it works.
<rodarvus> ajmitch, I'm uploading it now, will hand you the url in a second
<rodarvus> ajmitch, yes, please do
<ajmitch> ok
<rodarvus> (uploading to people.ubuntu.com, I mean :) )
<rodarvus> ajmitch, http://people.ubuntu.com/~rodarvus/packages/qemu/
<jdub> mdz: ping
<ajmitch> yep, got it
<rodarvus> thanks!
<ajmitch> jdub: what did you need to convince me of for beaglefs?
<jdub> ajmitch: wasn't sure if you wanted to maintain it long term
<ajmitch> fine by me
<jdub> sweet, thanks
<jdub> mdz, doko: ping (rrdtool)
<ajmitch> rodarvus: qemu built fine
<rodarvus> ajmitch, nice, I'll upload it - thanks a lot for the test-build!
<rodarvus> qemu uploaded
<rodarvus> I call it a day
<rodarvus> good night all
* Fujitsu kicks the silly GL{,U} dependency changes.
<rodarvus> ?
<rodarvus> anyhow
<Fujitsu> trackballs in Debian has `xlibmesa-gl-dev | libgl-dev, libglu1-xorg-dev | libglu-dev', while Ubuntu has `libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev'
<Fujitsu> Which is correct?
<Fujitsu> I haven't seen this libglu1-xorg-dev dependency before...
<crimsun> Debian is.
<crimsun> we now have a libglu1-xorg-dev that depends on libglu1-mesa-dev
<Fujitsu> OK, thanks.
<Hobbsee> Fujitsu: you're doing trackballs?
<Fujitsu> Hobbsee, yes, like I did a couple of weeks ago.
<Hobbsee> Fujitsu: cool, okay
<jdub> tseng: ping
<mournahan> need help, dapper hard freezes 2-3 times daily and cant find any solution
<Hobbsee> mournahan: --> #ubuntu
<Hobbsee> mournahan: read the /topic
<mournahan> no help there, thought try here
<mournahan> sorry
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | yes X in edgy is a mess atm
<tseng> jdub: hello
<Flowking> And here i thought everyone was  useless for a while... until someone cool or i step aside sessie james will be ontop (Naah:)
<Flowking> Cheers all .. each and everyone of you could potentially be just as cool as i am!!!
<Flowking> I love you all
<Flowking> Ill be coding for you even though crap stinks.. WE DO NOT CARE
<Flowking> :=)
<Flowking> 10 meters of snow... wont hinder me
<Flowking> Ill be the breast coder :=)
<Flowking> PCB.. find any coder better atm ?.. we need a trackrecord
<Flowking> linus.. yeah.. but he is just GOOD
<Flowking> :)
<Flowking> So "Machine head- A thousand lies" ?
<Flowking> Awesome
<Flowking> Its all about rebooting the brain until the next time CRAZY BRAIN!!!
<Flowking> :)
<Flowking> I could be at a thing called "Hedesunda sommar party" or something....
<Flowking> Sexxi
<Flowking> :)
<Flowking> Sorry Awesome hogs.... want me to lead.. no thats illegal nowdays too "Infringement or some shit!"
<neuralis> Flowking: you're trolling and flooding; please leave.
<Flowking> So, No i cant even teach you how to COMPUTE
<tseng> neuralis: good luck with that.
<Flowking> ssh
<Flowking> neuralis: you see how HHHG will affect the gilted aswell ?
<Flowking> neuralis: "The rage to Overcome" "Machine Head"
<Flowking> Keep an open mind and youll be Be
<Flowking> neuralis: download some of that man.. really good to be coding to
<Flowking> Relaxing
<Flowking> neuralis: is it sexxi or do you have a slow pipe (Zap Brannagan:)
<neuralis> -- Ignoring ALL from Flowking/*
<Flowking> Alternatively youve been swallowed by a small dog
<tseng> lilo: ah thank goodness
<lilo> orientation?
<Flowking> MORON
<lilo> tseng: flowking?
<Flowking> You dont rock
<tseng> lilo: yes.
* mode/#ubuntu-devel [+b %Flowking!*@*]  by lilo
<neuralis> lilo: i just paged you.
<neuralis> lilo: thanks.
<lilo> neuralis: *nod* got it
<tseng> lilo: *hugs*
* mode/#ubuntu-devel [-b %flowking!*@*]  by lilo
<lilo> tseng: np
<LaserJock> sweet
<LaserJock> thanks lilo 
<Kamion> thanks, that was quick
<lilo> my job
<lilo> glad to help
* poningru hugs \sh_away hope you are feeling ok
<kagou> hi
<kagou> who or where can i discuss about fridge.ubuntu ?
<jdub> kagou: you can mail fridge-devel@lists
<jdub> kagou: or see #ubuntu-fridge (if there's anyone still in it)
<kagou> jdub: :p ok thanks
<Nafallo> jdub: hi! did you get me e-mail about changed feed for the planet? :-)
<Nafallo> (months ago *I think*
<jdub> Nafallo: hrm, i just went through a bunch - can you send again?
* jdub doesn't have access to update it now, but will hopefully be getting that back soon enough
<Nafallo> okidoki.
<kagou> mattw: around ?
<HrdwrBoB> erm
<Nafallo> sent :-)
<HrdwrBoB> is there any way to bootstrap a 64bit install form a 32bit install easily?
<jdub> Nafallo: got it
<jdub> thanks
<Nafallo> no, thank you! :-)
<jdub> NO THANK YOU!
* jdub quickly escapes to the shops!
<Nafallo> hihi :-)
<infinity> HrdwrBoB: If you're running a 64-bit kernel, you should be able to build a 64-bit chroot from 32-bit userland.
<infinity> HrdwrBoB: If it's a 32-bit kernel, then you have no way of running 64-bit binaries, so it gets tougher.
<HrdwrBoB> infinity: yeah, I'm not, so I just copied a 64 bit kernel on it
<HrdwrBoB> and It'll be easy from there
<Hobbsee> evening all
<Kamion> BenC: you don't appear to be subscribed to linux-source-2.6.17 bugmail
<Kamion> drat, need one more upload before dapper.1
<janimo> Kamion: hi, I did not teste dapper releases so far because they were oversized
<janimo> the 08.04 is the first testable one
<Kamion> nod
<janimo> it's only oversized on the PPC I have to check that too
<janimo> besides rosetta updates and other base system changes there were only two extremely small package fixes in xubuntu
<janimo> so in theory all should go well
<Kamion> yeah, noticed when going through the changes last night
<janimo> but will need  testing anyway
<Kamion> would be nice to test ubiquity in the context of xubuntu, though
<janimo> right
<Kamion> powerpc should probably be fixed by removing language packs
<Kamion> language packs have grown a bit since dapper
<janimo> right, although I am not sure what changed since dapper. did some components get added?
<janimo> ah ok.
<Kamion> the size increase of the xubuntu desktop CD is about what I'd expect
<Kamion> want me to take care of it? I have the figures to hand
<janimo> oh, I confused things. the edgy dailies were oversized on all archs, and this is the first daily for dapper.1 
<Kamion> aaaaactually
<janimo> sure if it's not much trouble, thanks
<Kamion> no need to remove bits - that build was hit by a sort of a debian-cd bug
<Kamion> which allocated ~5MB too much space for the HFS hybrid metadata on powerpc
<Kamion> I'll do full rebuilds of everything soon, which should clear that up. Do you have a tester ready to go now? If so I can do you first.
<janimo> I need to check
<janimo> as it's 3h download from here I may find someone with better bandwidth
<janimo> and inclination to test
<Kamion> nod, 2/3h per image for me too
<doko> Kamion, pitti: Is there still time for a dapper-security upload for the CD images?
<janimo> Kamion: but yes if you rebuild I can start downloading and test today
<Kamion> doko: something that goes on the live CD? I'd hoped I was done with the live filesystem builds
<Kamion> doko: details (in /msg if need be)
<janimo> is the 386 image changing as well since yesterdays or just the PPC?
<Kamion> janimo: I need to update gfxboot-theme-ubuntu's translations, so all CD images will be rebuilt
<janimo> as I may start the dl now otherwise
<janimo> ok
<janimo> Gloubiboulga: hi
<Kamion> but you can rsync, it won't be a huge change
<Kamion> you know the rsync runes?
<janimo> right
<janimo> I hope  I have themin bash history :)
<janimo> unless the URLs changed since dapper
<janimo> it should be ok
<janimo> btw uploads to edgy are stil ok at this point no?
<Kamion> stick dapper/ in before daily or daily-live
<Kamion> I needed to be able to build dapper and edgy in parallel so that's changed a bit
<Kamion> edgy> sure
<Kamion> doko: after the point release, please
<Kamion> doko: (sorry, but the cut has to come somewhere, and after I've spent three hours doing livefs builds seems like a plausible place)
<doko> Kamion: sure
<Kamion> I'll let you know if we'll need a rebuild for other reasons
<Gloubiboulga> hi janimo 
<Gloubiboulga> hi all :)
<ajmitch> hello Gloubiboulga 
<janimo> Gloubiboulga: seems we'll have 6.06.1 candidates in a few hours
<janimo> I am downloading yesterdays image now
<Kamion>  msgid "Start Ubuntu in safe ^graphics mode"
<Kamion> +msgstr "Paleisti Ubuntu VESA ^grafiniu reimu"
<Kamion> interesting telepathy from the Lithuanian translator there :)
<Gloubiboulga> janimo, ok, I have to leave now, but I'll test images tonight
<Nafallo> hehe
<Kamion> scheisse, I do need a livefs rebuild due to the publisher crash
<Kamion> going to make it as fast as possible though - the relevant source is publishing now
<StevenK> Ahhh, that'd be why my new upload is not being published.
<StevenK> Hopefully my upload didn't kill it.
<Kamion> no, not any upload's fault
<StevenK> Kay.
<Kamion> long story related to the point release, but it's being sorted now
<StevenK> Right.
<Kamion> what was your upload? I'll check for it
<StevenK> libapache-mod-jk 1:1.2.18-1ubuntu1
<StevenK> Kamion: Thanks
<Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18-1ubuntu1.diff.gz from library
<Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18-1ubuntu1.dsc from library
<Kamion> 10:51:12 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/liba/libapache-mod-jk/libapache-mod-jk_1.2.18.orig.tar.gz from library
<Kamion> yep, being published now
<StevenK> Cool, thanks.
<pygi> sivang, poke
<Riddell> Kamion: I'm uploading a new kubuntu-meta to dapper-updates with a langpack removed from powerpc, could you approve when it arrives
<Kamion> Riddell: yes, but hang on
<Kamion> Riddell: are you looking at the powerpc live CD?
<Riddell> Kamion: yes
<Kamion> Riddell: that's affected by a debian-cd bug - please wait until the build I just did arrives on the mirrors and base numbers on that
<Riddell> ok
<Kamion> Riddell: also I believe that all architectures are slightly too big at the moment
<Kamion> I realise there's no .OVERSIZED file
<Riddell> http://cdimage.ubuntu.com/kubuntu/dapper/daily-live/20060805/  ?
<Kamion> but recent information suggests that some software gets unhappy if the image is over 700 MB
<Riddell> powerpc has .OVERSIZED
<Kamion> i.e. 734003200
<Kamion> bytes
<Kamion> yes, powerpc is clearly over, although less far over than in 20060804
<Riddell> but i386 is also over for some software?
<Kamion> my figures are 440320 bytes for amd64, 1208320 bytes for i386, 4100096 bytes for powerpc
<Kamion> I think so
<Riddell> ok, I'll trim some more
<doko> Riddell, Kamion: OOo will shrink by 1.6 mb for the next upload to edgy, but maybe too late for knot-2
<Kamion> ok, thanks
<Kamion> not sure when I'm doing knot-2, may not squeeze it in before I go on holiday
<Kamion> sfllaw: it would be good if you could check over DebuggingUbiquity for the usual patterns when splitting off misfiled bugs
<Riddell> Kamion: kubuntu-meta uploaded
<ogra> Kamion, do you build edubuntu as well, or do i need to ?
<Kamion> I'm just sorting out Edubuntu now - powerpc was a bit oversized
<Kamion> I took out KDE language packs for pt de fr
<ogra> thanks
<Kamion> so at least they'll still get the desktop translations
<ogra> hmm, i only saw oversizedness on the liveCD
<Kamion> yes, I meant the live CD
<ogra> and according to your comment on kubuntu ppc live i thought i'd wait for the next build to see if its really to big
<ogra> but if you already removed them , then its fine :)
<Kamion> I did a rebuild just before fiddling with the seeds, to test that
<ogra> ok
<Kamion> I knew it wouldn't quite rescue all the space though
<ogra> hmm, why doesnt dash know my environment ? $UID is empty :/
<Kamion> ogra: edubuntu-meta update will probably fail in edgy; I'm working on fixing it in germinate
<Kamion> ogra: let me know if it becomes urgent
<ogra> depends how near knot-2 is :)
<pygi> bye all
<Kamion> should definitely have it sorted before then
<Kamion> fixing the corresponding dapper breakage now
<ogra> ok
<Kamion> and shuffling the publisher byhand again
<Kamion> ogra: actually, no, edgy works fine, and the dapper breakage is probably my bad due to a seed merge
<ogra> is it the server seed ?
<ogra> the edubuntu one is still trivially small and doesnt change usually
<Kamion> kind of, it's broken inheritance in STRUCTURE
<bddebian> Howdy
<Kamion> right, kubuntu-meta accepted, edubuntu seeds fixed, edubuntu-meta uploaded/accepted, publisher running
<Kamion> ogra: sorry for the spurious edubuntu-meta upload attempt to edgy and consequent reject
<ogra> dont worry :)
<pitti> Hobbsee: hi
<Hobbsee> heya pitti!
<pitti> Hobbsee: did you see the u-d mail about sponsoring?
<Hobbsee> pitti: not yet.  i'm on the digest
<TheMuso> pitti: I was actually working with crimsun today. I used the script to upload a debdiff, and he found it teedious to have to extract, save, and apply the debdiff by hand. He can probably tell you more about it/
<pitti> TheMuso: yes, we can also write a script which does the gpg, apt-get source, patch, debuild -S -k automatically
<TheMuso> Right.
<janimo> pitti, congrats for leading the security charts :)
<pitti> hey janimo, thanks :)
<Kamion> kubuntu/edubuntu livefses building
<Kamion> xubuntu will follow too
<mdz> Kamion: are these candidates for testing?
<Kamion> mdz: yes
<Kamion> Ubuntu alternate and desktop built, ready for testing
<mdz> ok
<mdz> Kamion: 20060805?
<Kamion> yes
<Kamion> (for both)
<Kamion> derivatives may have different build numbers
<Kamion> (for anyone else watching)
<Kamion> kubuntu alternate and desktop building
<mdz> Kamion: do you have a list of what has changed and so most needs testing?
<Kamion> mdz: http://wiki.ubuntu.com/DapperPointOneAnnouncement has most of the changes
<mdz> which installer cases, which apps
<Kamion> although in the case of the desktop it's kind of "well, most of GNOME changed"
<mdz> Kamion: s/including a large memory leak/including a fix for.../ I think ;-)
<Kamion> I caught most of the significant installer changes there, though
<Kamion> hah, yes
<Kamion> (fixed)
<Kamion> mdz: is the style of that announcement ok? I chose the changelog style because I thought it would be useful to reassure certifiers about what we're messing with
<Kamion> but the detailed list of changes could be split off if you want
<mdz> I think we can remove the paragraph which says that 6.06.1 is the first long-term release
<mdz> the first sentence anyway
<mdz> or change it to refer back to 6.06 LTS
<Kamion> makes sense
<Lure> any reason that we have both ruby and ruby1.8 packages in edgy (both 1.8.x)?
<Treenaks> (universe totem-{xine,gstreamer}-firefox-plugin broke because of the totem upgrade)
<Kamion> mdz: changed
<Kamion> Lure: apt-cache show ruby
<mdz> I'll tweak a bit while I wait for downloads
<mdz> oh, you still have it locked
<Kamion> it's saving slothfully
<Kamion> should be unlocked now
<Lure> Kamion: thanks (metapackage or so...)
<mdz> Kamion: do you have a quick statistic for the total number of package updates applied on the CD?
<mdz> source packages that is
<Kamion> not trivially - I can come up with one though
<mdz> gar, desktop is still vaguely unstable
<mdz> I think we can safely say "over 200"
<Kamion> now let's remember how join(1) works
<Kamion> unstable?
<Kamion> mdz: in terms of binaries, 516 on dapper-alternate-i386.iso are updated
<Kamion> sources, give me a minute
<mdz> Kamion: I'm comfortable with "over 200", honestly
<mdz> there have been more than that many uploads to dapper-changes since release
<Kamion> mdz: 21 sources from -security, 330 sources from -updates
<Kamion> (I was already mostly done)
<mdz> ok, over 300 then
<mdz> that includes langpacks I assume?
<mdz> those weren't on -changes
<Kamion> everything, that's comparing grep-dctrl -nsFilename with pool/*/*/*/*.*deb basically
<Kamion> 62 of those 330 are language-(pack|support)
* Riddell notices 20060805.1 and downloads
<Kamion> oh, yeah, kubuntu alternate and desktop ready for testing :)
<Kamion> edubuntu livefs still building, slow thing
<Kamion> mdz: unstable desktop -> dapper or edgy?
<mdz> Kamion: edgy
<Kamion> oh, good. well, not good, but YKWIM
<mdz> bug #54726
<Ubugtu> Malone bug 54726 in xserver-xorg-video-ati "Random freezes in X" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54726
<janimo> Kamion: should  the two xubuntu changes be mentioned as well in that announcement?
<Kamion> janimo: yes, I'll add them
<janimo> ok, thanks
<Kamion> janimo: I was doing the changelist before I decided it was reasonable to just have one announcement
<mdz> I'd need to swap in an identical video card to be sure about whether it's a hardware issue
<mdz> rsync is taking ages, only getting ~40kb/sec
<janimo> Gloubiboulga: I tested the image in qemu burning real CD now. Did it work for you?
<mdz> Kamion: ETA 3-4 hours here, you doing any better?
<Kamion> janimo: reload, see if that makes sense?
<Kamion> mdz: desktop i386 ETA 1:24 allegedly, but amd64 came down a lot faster than that
<Kamion> of course I'm *cough* rsyncing off lithium from pure habit
<Kamion> really must stop doing that
<bddebian> *cough* speaking of syncs *cough* ;-P
<Kamion> but every time I'm reminded of it it's when other people's rsyncs are slow, so ...
<bddebian> Heya Gloubiboulga
<Gloubiboulga> janimo: I'm using the live cd
<Gloubiboulga> and installing
* Kamion will only be doing syncs today if he runs out of other things to do
<bddebian> Kamion: No worries, I'm just not sure what's left at this point :-)
<janimo> Kamion: yes, looks good.
<Kamion> janimo: thanks
* bddebian notices still no responses about squashfs
<Kamion> I'll reorder that list at some point to be better-categorised rather than in rough date order of uploads
<mdz> bddebian: if you're concerned about whether it'll break the live CD, I believe that's built using the dapper version of squashfs-tools, and if you want to warn the person responsible for that, that's infinity
<Lure> if a package suggests/recomends (but not depends) on something from multiverse, can it still be in universe?
<mdz> bddebian: (PS: your post is <24 hours old and it's Saturday :-P)
<mdz> Lure: suggests, yes, recommends, not really
<Kamion> Lure: suggests yes, for recommends it'd probably be a judgement call
<Kamion> snap
<Kamion> (ish)
<Kamion> recommends should be increasingly like depends
<Lure> Kamion: I suspect due to aptitiude behaviour to install as depends?
<Lure> Kamion: any special procedure to move something from multiverse -> universe (when Depends are fixed)?
<Kamion> you have the causality the wrong way round, but yes
<Kamion> aptitude behaves that way because we want to be able to use recommends more effectively
<Kamion> Lure: file bug on package, subscribe (*don't assign*) ubuntu-archive team
<Lure> Kamion: ok, will get fixed package uploaded first by MOTU and then I will file request. Thanks!
<bddebian> mdz: Well as usual I started on IRC first but I see your point, sorry
* bddebian has no patience
<mdz> it's edgy, upload first and ask questions later
<bddebian> Well I don't want to get in "trouble" again :-)
<mdz> but I wonder what squashfs is doing in universe
<mdz> Kamion: do you still hope to get some bug references from the GNOME team for the announcement?
<mdz> I expect we'd have to call them up on Saturday
<Kamion> mdz: I think I might well just go through the uploads again; won't take that long
<Kamion> it was late last night and I was just doing a first pass
<Kamion> ogra: edubuntu alternate and desktop ready for testing
<janimo> Kamion: is running the 386 iso on amd64 considered a valid use case? Desktop works but ubiquity crashes
<Kamion> yes, that's valid
<Kamion> can I have a bug with the crash dump and the logs please?
<janimo> I'll file a report then
<janimo>  /var/log/installer/syslog right?
<Kamion> all those listed in the crash dialog
<Kamion> I'm assuming it crashed in such a way as to pop up a dialog with a traceback
<janimo> right
<Kamion> I'll probably only fix it now for the point release if it's a regression from dapper
<janimo> sure, it probably is not
<janimo> havent tried dapper on this box yet
<Kamion> it should be easy enough for me to tell
<janimo> going offline for a while since I only have one eth connection right now
<Kamion> ok, who made vim's completion facilities TRULY SCARY
<Kamion> janimo: ah, regression :(
<Kamion> janimo: so that we don't have to wait for a whole new build cycle, could you apply this to /usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py and try again?
<Kamion> -                if fstype is None:
<Kamion> janimo: on line 1034
<Kamion> +                if fstype is None and device in validate_filesystems:
<Kamion> Gloubiboulga: you too
<Gloubiboulga> Kamion: ok
<Kamion> thanks
<Gloubiboulga> it didn't crash with the change
<Kamion> does it complete successfully?
<Gloubiboulga> It's installing the system now
<Kamion> real-world testing > constructed test cases, yet again
<Kamion> backporting the change right now
<Kamion> janimo: did you get my earlier comments?
<janimo> only in LP not on IRC
<Kamion> 18:12 < Kamion> -                if fstype is None:
<Kamion> 18:12 < Kamion> +                if fstype is None and device in validate_filesystems:
<Kamion> could you apply that on line 1034 of /usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py ?
<Kamion> and try again
<janimo> ok
<Kamion> thanks
<Kamion> just don't want to have to wait for a whole new build cycle to see if there are any further bugs you encounter
<janimo> sure
<Kamion> make sure to do the same things in the partitioner as far as you can
<janimo> ok got further and is not installing
<janimo> now
<janimo> sorry :)
<janimo> s/not/now/
<Kamion> phew
<janimo> so hopefully I don;t need to dl and burn a new image either
<Kamion> xubuntu daily-live hadn't actually built yet - you were working off an older one
<Kamion> I mean in my most recent round of builds
<janimo> would be nice (but possibly hard) to have the partitioning steps automatable to run all kinds of random tests on it
<Kamion> but if your tests here work, I'm happy to take that as sufficient for the point release provided tests on the final images for other flavours are good
<Kamion> there are few enough changees
<Kamion> changes
<janimo> this was not xubuntu specific right?
<Kamion> no
<janimo> but the QT interface was not affected?
<Kamion> see my explanation in the bug - that's the exact set of circumstances
<Kamion> it was
<Kamion> I'm fixing both, the code's the same
<Kamion> (bit of duplication ...)
<janimo> ok, haven;t read all of LP comments yet
<Kamion> uploading to dapper-updates now
<Kamion> mdz: I'm out tonight - if you're around, could you rebuild all four livefses? otherwise don't worry, I'll do them when I get back and it'll be time enough
<Kamion> once ubiquity 1.0.17 binaries arrive
<Kamion> alternate install CDs won't need to change, nor will the server CDs that I'm building now, so you can safely continue testing those
<Gloubiboulga> Kamion: installation finished here (succesfully it seems)
<Kamion> great, thanks
<Gloubiboulga> have a nice evening :)
<Nafallo> anyone know if Keybuk is on vacation, and in that case for how long?
<mdz> Kamion: can do
<Nafallo> hmm
<Nafallo> cdbs should update the icon cache automatically, right?
<Nafallo> if the package has the gnome class, which network-manager doesn't...
<Kamion> mdz: thanks
<Kamion> ok, I'm off to iwj's for the evening; please do (get a Canonical employee to) phone me on my mobile if there's a point-release-related emergency - I'll obviously be able to get to a computer easily
<Nafallo> Kamion: have fun :-)
<Nafallo> Kamion: you deserve it :-D
<Nafallo> anyone willing to sponsor a trivial change to network-manager? :-)
<Nafallo> fixes malone #55334
<Ubugtu> Malone bug 55334 in network-manager "nm-applet doesn't start" [Medium,Fix committed]  http://launchpad.net/bugs/55334
<bluefoxicy> you know
<bluefoxicy> suddenly I don't have DMA on my drive, and I can't turn it on.
<Kaleo> Hello bluefoxicy 
<Kaleo> bugs should be reported on Malone https://launchpad.net/distros/ubuntu/+bugs
<Kaleo> and #ubuntu-bugs can help as well
<bluefoxicy> mdz:  does anyone use Ctrl+Alt+Backspace?
<bluefoxicy> er.  Why the heck did I point that at mdz
<Nafallo> pitti: ping
#ubuntu-devel 2006-08-06
<Riddell> Kamion: all 6 latest kubuntu CDs are good to go
<Riddell> dapper that is of course
<Burgundavia> fabbione: when you get a chance, you get a logging daemon in ubuntu-laptop?
<Nafallo> gnight
<Kamion> mdz: looks like your livefs builds did indeed die, so I've restarted them
<jbailey> Any edgy users here on ppc willing to risk completely ruining their system by testing glibc for me?
<jbailey> If you're not so brave as that, a chroot will work too ;)
<gnomefreak> :(
<gnomefreak> jbailey: no but if you need to ruin an i386 let me know ;)
<jbailey> Nah, I can do i386 here. =)
<gnomefreak> im lookinjg for things to break so i have a good excuse to reinstall
<jbailey> Started the build on i386 in the meantime.
<jbailey> But would really like a ppc user to test it.
* jbailey needs to get his machine fixed.
<zul> you broke it?
<jdub_> mjg59: http://people.redhat.com/krh/plymouth/
<jdub> mjg59: The changes to rhgb replaces all the X server
<jdub> startup/hand-holding code and the gtk+ progress screen and just paints
<jdub> on the fbdev using cairo.
<jdub> 
<mjg59> jdub: Pff. Primitive.
<jdub> mjg59: should i finally reboot to see how primitive it is compared to ours? :)
<mjg59> jdub: Yeah. It might fuck up, but then you can aid debugging
<jdub> mjg59: can we use pngs and cairo on ours yet? :)
<jdub> oh man
<jdub> i accept tseng's friend request on last.fm
<Hobbsee> morning all
<jdub> and the next song it plays for me is "we belong together" by mariah carey
<jdub> tseng: SABOTAGE!
* tseng holds jdub 
<jdub> ha ha
<tseng> that certainly isnt on my playlist.
<Burgundavia> hey Hobbsee
<tseng> hey Hobbsee, Burgundavia 
<tseng> jdub: Muse!
<tseng> rock on
<bddebian> Hi Burgundavia
<Burgundavia> hey bddebian
<stillflame> so i'm working on fixing oem-config stuff, with it silently ignoring invalid usernames, and i am wondering what the policy/proceedure is on having to translate "no underscores or capitol letters" into every language.  pointers?
<tseng> isnt that something the translation team would handle?
<stillflame> ooo, that sounds promising.
<Hobbsee> hi Burgundavia, tseng!
<stillflame> so then i submit a bug requesting translations?
<stillflame> there's the ubuntu-translators list - would sending requests there be appropriate?
<Hobbsee> stillflame: is that supposed to be done in rosetta?
<Hobbsee> stillflame: i've got no idea
<stillflame> hmm.  i'll submit a bug and hope that works :-/
<Kamion> stillflame: I'm currently in the middle of a total restructure of oem-config - http://people.ubuntu.com/~cjwatson/bzr/oem-config/mainline/
<Kamion> not quite working yet but it will be a lot easier to fix that bug there
<Burgundavia> mdz: ping (re: -news moderator password)
<Kamion> and the messages should just come from user-setup or (possibly) ubiquity - there should be no need to invent new ones for oem-config
<HrdwrBoB> oh. excellent.
<HrdwrBoB> looks like xfs 32bit->64bit change ate my filesystem
<jdub> HrdwrBoB: that's why it's called xfs
<HrdwrBoB> I have 670gb of data in lost and found
<HrdwrBoB> and another 700 or so gone
<jdub> HrdwrBoB: that is crazy
<HrdwrBoB> you're telling me
<stillflame> Kamion: excellent!  i'll happily look around in your code, beta test, and even submit a patch or two.
<HrdwrBoB> I take that back though, the data in lost+found is scrambled
<Amaranth> HrdwrBoB: Ouch!
<jdub> rodarvus: ping
<Burgundavia> Kamion: do we have a time frame on Knot 2? I have started work on https://wiki.ubuntu.com/EdgyKnot2
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | yes X in edgy is a mess atm | http://wiki.ubuntu.com/Testing/Current Test the 6.06.1 images! |
<Kamion> Testing/Current's all cleared out - have at it
<Kamion> Nobody at all willing to help me test the dapper point release?
<Kamion> help on amd64 and powerpc especially would be most appreciated
<Nafallo> my rabbit destroyed my powercord this morning, sorry :-/
<Kamion> see Testing/Current for the test matrix
<Chipzz> hrrrrm
<Chipzz> I'm reading https://wiki.ubuntu.com/Dpkg7Zip
<Chipzz> just some random thoughts, I may be talking out of my ass
<Chipzz> 1) I thought the compressed file system shared data with the compressed (gzipped) debs... am I correct in this?
<Kamion> you mean the live filesystem on the desktop CD?
<Chipzz> yes
<Kamion> you are entirely wrong, sorry
<fabbione> Kamion: i would love too... but i have my hands full of diapers to do proper testing :/
<Kamion> fabbione: you're excused :)
<Chipzz> 2) I do not know if this matters, but gzip supports random access, while bzip2 does not
<Chipzz> not sure about 7zip
<Kamion> Chipzz: various people have had random bluesky ideas about sharing space that way but nobody's ever come close to implementing it in a way we could use sanely
<fabbione> Chipzz: you don't need random access when unpacking a deb
<Chipzz> uhu
<Chipzz> that would only be relevant if the compressed fs was to share data with the debs
<Chipzz> which is not the case
<Chipzz> Kamion: ah, so that's where I got that silly idea from ;)
<Chipzz> adding 7zip support to dpkg may be something that may prove hard to get integrated upstream though, I guess
<azeem> #
<azeem> Created: 2005-11-05 by ScottJamesRemnant
* fabbione scratches his head
<Chipzz> I doubt the dpkg maintainer would be happy to introduce that dependency :/
<fabbione> Chipzz: what are you talking about???
<fabbione> Chipzz: the maintainer and upstream are the same person that wrote that specs
<fabbione> Chipzz: there is no dependecy. dpkg is statically linked for an amazing amount of good reasons
<Chipzz> fabbione: in that case I'm talking out of my ass I guess
<mc44> fabbione: congratulations :) got the baby hacking on X yet? :p
<azeem> fabbione: is that a ubuntuism? (statically linked dpkg)
<fabbione> mc44: yeps.. he already started working on multihead :)
<fabbione> azeem: i am pretty sure it's the same in debian too.
<fabbione> azeem: it's a just a matter of "whoops.. libbz2 did break the abi and i can't upgrade or fix anything anymore"
<fabbione> azeem: at least.. afaik
<azeem> right, stuff besides glibc is linked statically
<mc44> fabbione: ah thats why his middle name is Xinerama? :)
<fabbione> mc44: ehhee
<felixw> Hey.  I'd like to create a custom live CD of Dapper Drake with a different default language.
<felixw> I've loopback-mountet the ubuntu-6.06-desktop-i386.iso, but I can't find the point where English is defined as default langauge.
<felixw> Any ideas where the default language can be changed?
<Chipzz> fabbione: I was under the impression some people wanted to keep the base debian install very small; for example, if you look at some of the packages in the base install, some don't even use debconf (while actually they could)
<Chipzz> but I should have checked dpkg 's dependencies, indeed
<mdke> felixw: you can look on the help wiki, there is some details about customisation. otherwise best to ask in #ubuntu.
<fabbione> Chipzz: and how's that related with dpkg with 7zip compression?
<felixw> mdke: Thanks!
<mdke> felixw: https://help.ubuntu.com/community/LiveCDCustomization/6%2e06?highlight=%28live%29
<Chipzz> fabbione: not introducing a dependency (which argument indeed is void, since as you pointed out, dpkg is statically linked)
<fabbione> Chipzz: increasing dpkg of 10KB of code is nothing compared to how much the base system is bloated anyway. If you want to reduce the base system size, you start killing other stuff.
<fabbione> Chipzz: saving that space in dpkg is not what you are looking for.
<Chipzz> fabbione: I'm not against including 7zip support in dpkg ;)
<Chipzz> anyway I'll stop wasting your time ;)
<Chipzz> and come back when I have something usefull to say ;)
<lfittl> Does anybody have an idea why nvidia-cg-toolkit isn't included in our repositories, although it is in debian unstable since 2004?
<mdz> Kamion: morning, how goes it?
<Kamion> mdz: morning - working my way through i386 tests
<Kamion> all good so far
<gnomefreak> Kamion: is there a page on what the install cd installs?
<Kamion> ubuntu-standard + ubuntu-desktop + language packs
<Kamion> oh ubuntu-minimal as well obviously
<gnomefreak> is that same for x,k,ed(ubuntu)
<Kamion> obviously not, see their preseed files
<gnomefreak> xubuntu-standard ect
<gnomefreak> ohok
<Kamion> still the ubuntu-standard package
<Riddell> Kamion: new live CD builds?
<Kamion> (metapackage)
<Kamion> although there's a xubuntu-standard task for internal convenience reasons
<Kamion> Riddell: yes, ubiquity badness needed correcting
<Riddell> ok
* Riddell rsyncs
<Kamion> it's a one-liner in the gtk and kde frontends
<Riddell> bummer
<Kamion> manifests when you have existing partitions other than ext3, swap, vfat, ntfs, xfs
<Kamion> so create a reiserfs filesystem and then start ubiquity and don't touch the reiserfs filesystem but install alongside, and you should be able to duplicate it
<Kamion> mdz: the d-i partitioner hasn't changed, so I'm not going to worry too much about testing all the permutations there
<Kamion> and the only part of oem-config that's changed is localechooser, so I only need to test it on one architecture
* Nafallo is away: Jag r upptagen
<fabbione> is anybody aware of the refresh problems in edgy?
<fabbione> seems to be gtk/gnome specific..
* Nafallo is back (gone 00:47:38)
<zul> fabbione: i think there wassome pango problems recently with amd64
<fabbione> i am on i386
<Nafallo> WTF! is away-msg standard in xchat or something?
<fabbione> but i guess it's a similar problem?
<zul> i guess so
<fabbione> it's not libpango
<fabbione> i can't even read emails to check -changes
<gnomefreak> Kamion: you still here?
<kozz> was wondering if someone could help me with a sponsored upload for mkvmlinuz, fixes https://launchpad.net/distros/ubuntu/+source/mkvmlinuz/+bug/53460
<Ubugtu> Malone bug 53460 in mkvmlinuz "mkvmlinuz fails to create kernel" [Untriaged,Unconfirmed]  
<kozz> http://www.kozz.org/files/ubuntu/mkvmlinuz/
<Riddell> Kamion: all current kubuntu dapper desktop CDs good (and alternate CDs still good)
<Kamion> Riddell: thanks
<gnomefreak> Kamion: did you need the logs for bug 55214?
<Ubugtu> Malone bug 55214 in ubiquity "installer crash during "Creating user"" [Untriaged,Needs info]  http://launchpad.net/bugs/55214
<gnomefreak> i saw somehting that concered me in it wanted to check to make sure
<kozz> Kamion: would it be possible to also include a compressed kernel on the cd?
<kozz> like the one from breezy called vmlinuz-chrp.initrd
<Kamion> gnomefreak: /var/log/syslog would be useful, but even in its absence I don't want the bug closed
<Kamion> kozz: we had to remove that for space reasons, I'm afraid; sorry
<crimsun> Kamion: Please demote linuxsampler to multiverse. Its README lists an exception to the GPL: "This software is distributed under the GNU General Public License (see COPYING file), and may not be used in commercial applications without asking the authors for permission." The relevant BTS # is Debian 328121.
<Ubugtu> Debian bug 328121 in linuxsampler "Subject: linuxsampler: Inconsistent and non DFSG free license" [Grave,Closed]  http://bugs.debian.org/328121
<Kamion> crimsun: can you file a bug on the package and subscribe ubuntu-archive please?
<crimsun> Kamion: surely, thank you.
<Kamion> the above is actually non-distributable - it's not internally consistent with the GPL
<Kamion> (hm, not sure about that)
<Kamion> (it depends whether they're using any GPLed code not written by them - if it's all written by them then they can do what the like)
<Kamion> crimsun: reading that bug, it's been removed from Debian, so there's some argument that we should remove it too if we're not willing to support it ourselves
<kozz> Kamion: do even the alternative cd has space problems?
<Kamion> kozz: all our CDs have space problems of one kind or another - it's hard to cram an operating system, lots of applications, and lots of language support onto one CD these days
<kozz> Kamion: yeah, i'm sure they have... the thing is that for the pegasos it is only possible to boot a compressed kernel with the ramdisk in the same file. or teoretically use grub2 but that's still to much beta
<kozz> Kamion: but the dvd should have plenty of space, right?
<Kamion> right, I realise it's difficult for pegasos users, but there are just too many things competing for that space at the moment :(
<Kamion> I thought it was on the DVD, but apparently not - I think it's because the kernel just doesn't build that file at the moment
<Kamion> hmm, maybe not, it should be d-i's job
<Kamion> oh, that was it, our kernel images don't currently ship the files mkvmlinuz needs
<Kamion> which is not something I can fix - needs to be done by the kernel maintainers
<Kamion> you may be able to get updated firmware for the pegasos to let you run yaboot
<Kamion> which I think is a better solution long-term; having to munge the images into lots of different formats isn't really sustainable
<Kamion> anyway, the kernel issue is bug 34306
<Ubugtu> Malone bug 34306 in linux-source-2.6.15 "all powerpc kernel images should install additional utilities" [Medium,Unconfirmed]  http://launchpad.net/bugs/34306
<kozz> the new version of mkvmlinuz works
<kozz> after https://launchpad.net/distros/ubuntu/+source/mkvmlinuz/+bug/53460
<Ubugtu> Malone bug 53460 in mkvmlinuz "mkvmlinuz fails to create kernel" [Untriaged,Unconfirmed]  
<kozz> so bug 34306 is a bit old
<Ubugtu> Malone bug 34306 in linux-source-2.6.15 "all powerpc kernel images should install additional utilities" [Medium,Unconfirmed]  http://launchpad.net/bugs/34306
<Kamion> ah
<Kamion> ok, can you leave a comment correcting me in that bug?
<Kamion> I'll apply your mkvmlinuz patch shortly when I'm not in the middle of a dapper CD image test
<kozz> but I agree with you, not good to have different solutions for the kernel, the best solution imho is to use grub2 for all platforms
<kozz> but that will take a time until it is mature enough
<Kamion> Riddell: could you fill your test results into Testing/Current please?
<Kamion> just so that I have them
<Kamion> kozz: ok, thanks for the mkvmlinuz patch! uploading now
<Kamion> pretty sure that -fno-stack-protector is the way to go for now at least
#ubuntu-devel 2007-07-30
* lamont pauses to consider why debian has udev_0.113-2 and gutsy has udev_113-0ubuntu6
<lamont> sigh
<wasabi> heh. nice.
<wasabi> "oops"
<wasabi> Looks like scott did it. =)
<wasabi> 2 years ago heh
* calc finally was able to watch transformers, it was kewl! :)
<RAOF> Guest starring the Autobots!
<visik7> how can I browse code for a specific package in bzr ?
<visik7> I can't find it on launchpad
<visik7> I'm here https://launchpad.net/hal
<visik7> but I can't find something like svnweb or cvsweb or gitweb
<visik7> where is bzrweb ?
<visik7> without downloading it from packages.ubuntu.com
<visik7> ok I found it
<TheMuso> c
<TheMuso> ugh
<RAOF_> Doing that in new and different channels now :)
* ajmitch is sure he has it scripted
<StevenK> Heh
<StevenK> infinity: Ping, re: libnss-db again
<infinity> StevenK: I know I shouldn't pong unless I'm prepared to respond immediately, but I can't resist the little purple number in irssi.
<RAOF_> :)
<infinity> StevenK: I'm trying to make time to look at it today (it's even flagged in my mail client), but I'm also trying to get lpia to the point where it can be debootstrapped. :)
<StevenK> infinity: Ahh, but since I've uploaded libapache2-mod-auth-p{lain,am}, as soon as libnss-db is published, yada can be kicked back to universe.
<StevenK> infinity: Surely that's a good incentive? :-)
<infinity> StevenK: Yeah, I noticed that. :)
<StevenK> infinity: Do you have time to do two givebacks for me? :-)
<ajmitch> StevenK: best news I've heard for awhile (yada in universe)
<StevenK> ajmitch: Almost. :-)
<ajmitch> now what's needed to be able to drop it from the archive entirely?
<StevenK> The 24 odd packages in universe to stop using it.
<ajmitch> I'm sure noone will miss them
<Amaranth> err, the rdepends only show yada-doc
<Hobbsee> Amaranth: that'd be because packages build-dep on yada
<Hobbsee> Amaranth: apt-cache show yada
<StevenK> *Build-Depends* not Depends
<Amaranth> ah
<Amaranth> oh, that's evil
<StevenK> Just try using it, it's like .spec files for Debian
<StevenK> And the Maintainer of it is convinced that yada can do no wrong - mainly because he wrote it.
<ajmitch> describing it as .spec files, so true & so evil
<ajmitch> though I know they're popular & have their uses, I never grew to like them
<Amaranth> it'd be cooler if it actually worked with .spec files
<ajmitch> no, because then you'd just have alien, creating mutant .debs
* StevenK kicks Sunbird for being a PoS
<ajmitch> there are some important differences between RH-like & debian-like systems for packages
<infinity> StevenK: Of course.
<infinity> StevenK: Of course, I can't give anything back unless you tell me what. :P
<Hobbsee> infinity: the whole world will do
<StevenK> infinity: Sorry, I was afk. Can you please give-back gabber on all arches, and glade-3 on ia64 and sparc.
<infinity> Hobbsee: I'm not going to do any mass-give-backs until after lpia is bootstrapped.
<Hobbsee> infinity: awww.  no fun :)
<infinity> StevenK: What's the magic word?
<StevenK> infinity: I did say please. :-)
<infinity> StevenK: The magic word is "now", not I suppose I can cope with politenes..
<StevenK> EPARSE
<infinity> As in, "give these back, NOW"
<infinity> "slave" also works.
<StevenK> That strikes me as rude, not polite. :-)
<Hobbsee> StevenK: but infinity may like it, so...
<infinity> Oh, the parse error was s/not/but/
<infinity> My bad.
<infinity> I'm having some brain::finger disconnects today.
<StevenK> Today? :-P
<infinity> Shush.
<elkbuntu> StevenK, see how far you can go. oil the whip :)
<infinity> I've been checking every package in main for special-casing of i386, I'm going cross-eyed.
<StevenK> Heh, ouch
<infinity> Finished up all of Required, Important is next...
<infinity> Then Standard and Build-Essential.
<StevenK> Ohhh
<infinity> Then I beg someone else to do Optional while I go sob in the corner in the foetal position.
<StevenK> infinity: sejong is showing NOT OK : <socket.timeout instance at 0x2aaab2ba1710> (AUTO), too
<infinity> StevenK: sejong hates me.
<StevenK> I thought it hated everyone?
<infinity> No, it hates me specifically.
<infinity> It just takes it out on you guys.
<infinity> Crashed building glibc.  WHAT A SHOCK.
<infinity> BenC: I'll give you hookers and beer if you can provide me with a stable kernel for my sparc buildds.
<infinity> BenC: Unlimited supplies.
* infinity hits the remote power.
* StevenK waits for the buildds to trip over themselves building gabber
<infinity> Okay, I really am not awake...
<infinity> This confused me for a full 30 seconds:
<infinity> adconrad@drescher:~$ sudo su - buildd
<infinity> Password:
<infinity> (There's no buildd user on drescher)
<StevenK> Heh
<infinity> Hrm, I wonder if I can recruit MOTU manpower for https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap/
<Hobbsee> infinity: there's got to be a way you can automate that....?
<infinity> Hobbsee: Sort of, but not really.
<infinity> Hobbsee: The bits mentioned in the wiki could be checked for, but I give a once-over to debian/rules to make sure people aren't doing cute and clever things, etc.
<infinity> Hobbsee: It needs people who have A) a deep understanding of packaging software, and B) can read very quickly. :P
<Hobbsee> heh :)
<infinity> So far, the intersection of those two traits appears to be... Me.
<infinity> Which is less than ideal. :)
<infinity> Oh well, off to apt-get source all of Important.
<infinity> I'm offended that I now have to use "-y" with "apt-get source" thanks to the new "OMG, REVISION CONTROL, ARE YOU SURE?!" feature...
<StevenK> Morning pitti
<infinity> Guten Tag, pitti.
<Hobbsee> hiya pitti
<infinity> pitti: Up early, aren't you?
<StevenK> Bwahaha, gabber finally succeeded to build.
<infinity> StevenK: If that was in error, I can reject the binaries. :P
<StevenK> Hmph
<infinity> StevenK: I wouldn't want your worldview shattered.
<StevenK> infinity: It involved fixing 3 seperate Gnome 1.x packages to not use libdb3. I don't want to think that pain was for nothing. :-)
<pitti> Good morning everyone
<pitti> infinity: slightly, yes; hayfever didn't let me sleep any more
<infinity> pitti: :(
<pitti> but I went to bed early, so that's ok :)
<infinity> pitti: I feel your pain, though.  I slept about 2 hours last night before I decided to just get up and work at 6am.
<pitti> two hours? erk, that sucks
<sbalneav> Night all
<Hobbsee> oh darn.  i'm out of tuna.
<Hobbsee> no more tuna for hobbsee's :(
<TheMuso> Salmon is a good substitute.
<Hobbsee> dont have any of that either.
<Burgundavia> salmon has the issue of travelling an obscene distance to Aus
<StevenK> pitti: Do you mind ripping out the kernel stuff from NBS? :-)
<infinity> I have the technology to do that.
<StevenK> I'm unsure if the new kernels have passed NEW yet.
<infinity> I also have that technology. :P
<pitti> StevenK: I NEWed kernels yesterday
<pitti> StevenK: except for lrm which FTBFSed partially
<infinity> Oh, he's alive enough to respond.
<infinity> pitti: I'll let you play ftpmaster, then. :)
<infinity> (Ws just looking for an excuse to avoid lpia for a few minutes, to be honest)
<StevenK> infinity: I figured that. :-)
<StevenK> infinity: If you want to avoid lpia for a few minutes, look at libnss-db. :-P
<infinity> What I really need to do is hate on soyuz for a bit.
<infinity> Manually scheduling all these builds is driving me mad.
<infinity> The problem with hating on soyuz is that it leads to hacking on soyuz...
<Hobbsee> infinity: this is beneficial - makes you avoid lpia, of course
<infinity> On balance, I think I'm better off just getting all of lpia built.
<infinity> Then I can quietly slink off somewhere and strangle myself.
<pitti> StevenK: I won't NBS the kernel before lrm is sorted out and linux-meta points to -9.
<pitti> StevenK: no need to deliberately break the daily CDs
<StevenK> pitti: Fair enough.
* infinity glares at his lpia chroot...
<StevenK> pitti: libapache-mod-auth-radius and liberis-1.3-11-dbg can NBS'd at your leisure.
<pitti> StevenK: thanks, done
<StevenK> pitti: Thanks.
<StevenK> pitti: libgladeui-1-6 should also be able to be killed in a few hours.
<StevenK> pitti: But not yet. :-)
<pitti> StevenK: you really fell in love with cleaning the house, didn't you? :-)
* pitti hugs StevenK 
<StevenK> Cleaning the archive is much nicer. :-)
* pitti tries fully automatic printer detection and installation and is impressed
<Burgundavia> pitti: the only bit that sucks is that g-c-m has a much nicer UI
<Dessan> works decently well, however it thought my printer could only print post cards...
<Dessan> That I wasn't so happy about.
<pitti> Burgundavia: I agree
<pitti> Burgundavia: and that's my (only) major concern about s-c-p; it's UI is horribly complicated
<Burgundavia> Dessan: bugs.launchpad.net/ubuntu/+filebug
<Burgundavia> pitti: the UI hasn't changed since FC2
<pitti> hey mvo
<mvo> good morning pitti
<pitti> mvo: WDYT about SRU verification of bug 112803? I don't know how to reproduce the situation easily
<ubotu> Launchpad bug 112803 in dbus "MASTER [Feisty]  cupsd leaking file descriptors (was: Multiple jobs are not printed)" [High,Fix released]  https://launchpad.net/bugs/112803
<pitti> mvo: I reproduced it by hacking the dbus code only
<pitti> mvo: but there have been confirmations that it works now, and the patch is obvious
<mvo> pitti: checking now, but if you reproduced it earlier and can no longer with the new version I think it will be fine (but let me test if install/removal work) before moving to -updates
<pitti> mvo: yeah, I reproduced the fd leak in cupsd and verified that it was fixed with the new libdbus
<pitti> mvo: dbus has three fallback methods of acquiring a dbus connection, and calling dbus-launch is the third one
<pitti> mvo: so I disabled the first two (check for unix sockets and environment variables IIRC), so that dbus-launch was tried immediately
<pitti> mvo: but I don't know the setup on the reporter's machines well enough to reproduce it with the unmodified package
<pitti> mvo: it just happens for an awful lot of people apparently
<mvo> yeah, the bugreport has a lot of comments
<carlos> pitti: hi
<pitti> hey carlos, how are you?
* pitti hugs seb128
<carlos> pitti: fine, thanks, and you?
* seb128 hugs pitti
<seb128> hey carl
<seb128> hey carlos
<pitti> carlos: reasonably well
<carlos> pitti: how many days left? :-P
<carlos> seb128: hey!
<pitti> carlos: 18
<carlos> pitti: :-)
<carlos> pitti: I wonder whether you would have time this week to discuss .xpi translations move to language pack infrastructure
<pitti> carlos: sure; we can do it in ~ 10 minutes if you want (just want to finish my current code)
<carlos> pitti: sure
<carlos> pitti: please, ping me when you are ready
<pitti> will do
<pitti> ah, cool, tests pass now
* pitti commits apport gcc ICE helper to make doko a bit happier
<stgraber> morning
<Hobbsee> morning stgraber!
<Tonio_> morning :)
<pitti> hi stgraber
<StevenK> pitti: libgladeui-1-6 can be NBS'd at your leisure.
<pitti> StevenK: you rock, thanks
<pitti> killed
<mvo> pitti: if you are hapy with my comment on 112803, I will set it to verification-done
<seb128> bug #112803
<ubotu> Launchpad bug 112803 in dbus "MASTER [Feisty]  cupsd leaking file descriptors (was: Multiple jobs are not printed)" [High,Fix released]  https://launchpad.net/bugs/112803
<pitti> mvo: I am, thanks a lot
<pitti> mvo: I'll copy it on Thursday, to meet the seven day rule
<seb128> pitti: what would be the way to go to make nautilus-cd-burner build?
<pitti> infinity: is there an easy way to find out why hal doesn't start in the buildd chroots? it seems that avoiding the dependency is hard
<pitti> infinity: would it be reasonable to install a policy-rc.d which disables the startup of daemons? as build dependencies they are hardly useful, I figure?
<pitti> carlos: I'm ready
<carlos> pitti: ok
<carlos> pitti: Launchpad already has XPI import support (not available in production yet)
<carlos> pitti: and in this cycle, we should finish the XPI export support
<carlos> so I would like to start preparing Ubuntu Gutsy to be able to provide updates for Firefox, Thunderbird and others using current language packs
<carlos> right now, would be a matter of use the standard .xpi files, later, Launchpad will provide you with the updated .xpi just like we do for .po files
<carlos> later == end of August (if there is no problem with the code deployment)
<pitti> carlos: not sure whether we can directly put them into langpacks, though
<pitti> asac: AYT?
<pitti> carlos: right now, mozilla-firefox-locale-* needs the contents of the XPI in /usr/lib/firefox/extensions/ and a configuration snippet in /var/lib/mozilla-firefox/extensions.d/
<carlos> pitti: isn't that generated from the .xpi file itself?
<pitti> carlos: so, it's of course possible to do this unpacking and shipping in the langpack source itself, that would be no problem
<carlos> as far as I know the source package for them is just the .xpi file
<pitti> carlos: it's been a while since I touched m-firefox-locale-all source, but everything should be in the xpi, yes
<carlos> and those directories are filled based on the .xpi content
<pitti> carlos: I'll talk to asac
<pitti> door bell
<carlos> ok
<carlos> pitti: thanks
<pitti> carlos: so, where would you ship them?
<pitti> carlos: in a subdirectory 'firefox' in the tarball, or so?
<carlos> pitti: that's an option, yes. It's up to you to choose it
<pitti> carlos: or in the per-locale directories?
<pitti> carlos: let me take a look at my importer and see what's better
<carlos> pitti: whatever fits better for you to prepare the language pack
<carlos> pitti: take into account that it's not just firefox
<carlos> but any extension or other Mozilla application (thunderbird)
<pitti> carlos: it would be nice to have something like non-gettext/<application name>/<locale>.ext
<pitti> carlos: e. g. non-gettext/firefox/de.xpi or non-gettext/firefox/es_ES.xpi
<carlos> ok
<pitti> similarly with thunderbird, or OO.o's files
<pitti> carlos: would that work?
<carlos> yeah
<infinity> pitti: hal should probably be made more resilient in the face of systems it doesn't like...
<carlos> although OO.org will not be included there, we still will need manual work there
<pitti> infinity: I don't know why it fails ATM; could be missing /sys, or an already running hal
<pitti> infinity: or anything else; but making package installation not fail when startup fails is kind of violating policy
<pitti> carlos: OOo> right, I just want to consider it dir structure wise
<carlos> pitti: sure
<StevenK> Hmph. Just because something failed to build, doesn't mean you need to e-mail me about it twice, Launchpad.
<RAOF_> StevenK: Only twice?  Not once per arch?
<StevenK> Actually, both were for ia64, but one per buildd.
<infinity> pitti: I;m about to knock off for the day, shall we have a constructive argument about it tomorrow? :)
<infinity> pitti: (including me figuring out why it fails in the first place)
<StevenK> pitti: Oh yes, I forgot to mention - Debian bug #434704
<StevenK> infinity: You should look at libnss-db. :-)
<infinity> StevenK: No, I should upload coreutils, tar, and gzip. :P
<StevenK> Aww
<pitti> infinity: thanks
<infinity> (Or we could just drop them from the distribution, they're not important)
* StevenK scoffs
<StevenK> pitti: If we kill db3, it'll show in the NBS list, and if I recall correctly, there is a bunch of stuff that pulls in libdb3.
<tuxcrafter> hello guys
<tuxcrafter> how can i check the version of glib i am using
<pitti> StevenK: not sure what you mean?
<pitti> tuxcrafter: dpkg -l libglib2.0-0
<tuxcrafter> pitti: thanks i mean 368 468 or 686
<pitti> tuxcrafter: (#ubuntu, please)
<StevenK> pitti: That's okay, I just read it and couldn't make sense of it either. :-)
<pitti> tuxcrafter: we don't have packages for 486/686
<tuxcrafter> pitti: i am debugging a serious bug with the via c7 cpu and glibs
<tuxcrafter> i need to install and use glibc i386
<tuxcrafter> i installed the 368 kernel
<pitti> tuxcrafter: our _i386.deb packages are built with 486 instruction set and optimized command ordering for 686, AFAIR
<tuxcrafter> ow than i have to install my own kernel
<pitti> tuxcrafter: we do not have any other debs
<pitti> tuxcrafter: we do have a special -i386 kernel, just not other packages
<tuxcrafter> pitti: ok but do you know a way to check what glib there is uses 468 or 686
<pitti> tuxcrafter: as I said, if you use the Ubuntu packages, it's 486 instruction set
<infinity> (Not counting possible toolchain bugs that may slip in other instructions for fun)
<infinity> Is that the sort of bug you're hunting right now?
<tuxcrafter> pitti: ok, and can you tell me how to compile the glib with 368 instructions only
<Mithrandir> tuxcrafter: first, it's glibc, unless you are talking about glib which is another library.
<tuxcrafter> glibc
<Mithrandir> tuxcrafter: secondly, changing to i386 will change the c++ abi, something you probably don't want to do.
<asac> pitti: carlos: good to hear that we have xpi support now ... whats the next step?
<pitti> asac: preferably I'd make mozilla-firefox-locale-all obsolete and ship the xpis right in the language-pack-XX
<pitti> asac: WDYT?
<pitti> asac: is the rather complicated packaging structure of m-f-locale-XX still necessary, or is it enough nowadays to just drop an xpi somewhere?
<carlos> pitti: maybe that + a script to install the xpi files would be enough...
<tuxcrafter> there is a via c7 instruction used in the glibc i686/486 lib that makes the system freeze completely, so i want replace the glibc with an i368 version that uses i368 instructions
<asac> pitti: unfortunately its not possible to just drop xpi somewhere
<pitti> carlos: right
<carlos> asac: well, it's not fully implemented, still working on exports, but release date for that is end of August
<pitti> asac: ok, so let's do the mangling in langpack-o-matic then, to avoid spreading copies of that code
<asac> pitti: pitti what do yo mean with mangling in langpack-o-matic? langpack-o-matic producing debs instead of xpis?
<pitti> asac: I mean, disassembling the xpi and ship the right bits in langpack-o-matic deb
<pitti> erm
<pitti> s/langpack-o-matic deb/language-pack-XX deb/
<soren> tuxcrafter: Just remove libc6-i686?
<asac> carlos: do you need info to do that?
<carlos> asac: pitti is the one doing it
<carlos> I just provide the .xpi files
<asac> carlos: ah. fine.
<carlos> the script that prepares the .deb file is still in pitti's hands
<pitti> asac: don't worry, I'll pry it out of the m-f-l-a source
* carlos hopes at some point launchpad will do it too
<pitti> carlos: another question, what's the status of that full dapper export?
<carlos> pitti: being executed right now
<pitti> splendid, thanks
<carlos> s/executed/exported/
<tuxcrafter> soren: thanks
<tuxcrafter> i am going to reboot to a other kernel
<soren> pitti: About the eBox acl and schemas mangling madness: I've created a patch that creates /etc/ldap/acl.d/ and /etc/ldap/schemas-enabled/ and makes slapd read from those directories. That way I don't have to touch slapd.conf directly at all. The Debian dudes say it'll be included in the next openldap2.3 upload. \o/
<ogra> seb128, ping
<seb128> ogra: pong, new gnome-power-manager available
<ogra> thanks
<ogra> seb128, why cant i log in on my thi clients anymore ?
<ogra> *thin
<carlos> pitti: btw, you should also add .xpi extraction code from build packages
<seb128> ogra: because you don't remember your password? ;)
<ogra> seems it hangs during session startup since the last upgarde
<seb128> no idea
<carlos> pitti: so we get them also like any other .po and .pot files
<ogra> (i didnt upgrae since before ubuntulive though)_
<ogra> no traces in .xsessin-errors .... new user doesnt help either
<cjwatson> infinity: I'm taking care of openssh/lpia, btw, in case you'd already got to that
<carlos> pitti: oh, and, given there is no .xpi for en_US, I guess you should special case en_US.jar file and extract that one too so we get the English strings to be translated
<ogra> seb128, does consolekit expect any kind of variable to be set to let me in ?
<seb128> ogra: consolekit is not used yet
<ogra> oh, i only saw ian making changes to gnome screensaver wrt CK
<seb128> yes, it's using it a runtime if available
<asac> carlos: so you need a langpack as blueprint to get the "to translate" entities?
<seb128> consolekit has not been promoted nor seeded though
<seb128> and gdm doesn't build with it yet
<asac> carlos: usually it should be enough to give you an application .xpi
<pitti> soren: awesome!
<ogra> ok
<carlos> asac: yes, most of the time it's en_US
<ogra> hmm
<asac> carlos: well ... why that?
<carlos> asac: that's because Mozilla uses IDs instead of english strings as identifiers
<asac> and?
<pitti> carlos: can do; can you please file a bug against pkgbinarymangler and say where you want to get those XPIs shipped?
<carlos> so you have DIALOG_SOMETHING = 'SPANISH TRANSLATION'
<carlos> instead of 'ENGLISH TRANSLATION' = 'SPANISH TRANSLATION'
<carlos> and thus, without en_US translations, translators don't know what to translate exactly
<asac> hmm
<carlos> asac: but don't worry, you don't need to do anything there
<asac> carlos: but i mean ... usually an application/extension ships at least one translation on its own ... so does it just work?
<carlos> Launchpad + pitti's script will handle it automatically
<ogra> hrm
<carlos> asac: which is en_US, isn't it?
<carlos> at least it is for Firefox and I think Thunderbird
<ogra> seb128, creatig a ~/.xsession containing gnome-session seems to run fine :/ so its not gnome then
<asac> carlos: doesn't matter imo ... can be any
<carlos> asac: I guess, but we assume it's en_US. If it's not the case, we will need to do some extra work to see how to handle it (our main target was to handle Firefox)
<carlos> asac: the one used as the original English will not be exported in the language pack, if that's what worries you
<asac> carlos: no ... i am just worried that you created a special purpose thing that is only useful for the applications ubuntu ships
<cjwatson> infinity: I've also changed lintian in svn to recognise lpia as a valid architecture
<carlos> asac: how's that?
<asac> carlos: but if that is not the case and e.g. translating ubufox or any other extension just works, then i am fine
<mvo> pitti: should we do a special case for tzdata too in StableReleaseUpdates? Its cumbersome to try to find out how to reproduce the "bug". so I think we should we should let it through with just basic testing
<carlos> asac: it should work too
<carlos> but we didn't pay too much attention to it
<carlos> so maybe needs some code tweaks to be able to handle it
<carlos> which is fine, and easy to do
<asac> well .. so for every package we need to do manual tweaking?
<carlos> I don't think so
<cjwatson> mvo: tzdata has been special-cased in the past, since the change is typically enforced by external factors
<carlos> and even so, it's Launchpad which will get such changes to cope with all those packages
<asac> carlos: what concerned me a bit and makes me ask these questions is that nobody asked me for input ... and suddenly there is a solution ;)
<carlos> asac: well, I think you are confused...
<carlos> asac: we just add native .xpi import/export support to Launchpad
<mvo> cjwatson: right, we have not written it down yet in the StableReleaseUpdates page as a special case and I think we should (just like the kernel and app-install-data-commercial)
<carlos> completely unrelated with your packages
<carlos> now, we are seeing how to integrate it with Ubuntu
<asac> ah ok
<cjwatson> mvo: that would be OK with me if it's just talking about updates to new upstreams
<asac> carlos: so i can import an ubufox .xpi right now?
<mvo> cjwatson: thanks, I will add it to the wiki
<carlos> kind of, although the export is not on production, so we don't officially support it yet :-P
<asac> carlos: if it is really as simple as just uploading an extension .xpi to get things started then i am fine.
<carlos> asac: yeah, that's the inde
<carlos> s/inde/idea/
<carlos> asac: although you need two xpi files
<carlos> one with the English strings
<carlos> well, you just need the English lang pack to start translating
<asac> carlos: this is what i don't understand
<carlos> two if you want to import an existing translation
<pitti> mvo: I agree; it would be nice if you could describe the tests you do on the wiki page? (the tzdump thing)
<carlos> asac: have you ever translated a .xpi file?
<mvo> pitti: I will dig and write something up
<asac> carlos: first you have to tell what .xpi you are talking about
<asac> carlos: an extension .xpi ... or a langpack
<carlos> asac: any .xpi file that follows the Mozilla's spec for .xpi translations
<asac> carlos: in real world ... you usually have an extension xpi
<asac> and there are already translations included
<asac> why should authors need to manually extract an en_us langpack first?
<carlos> do you mean that extension xpi files include several translations in a single .xpi file?
* pitti hugs mvo
<asac> carlos: in real-life you usually have one-or-many translation in the extension xpi ... yes
<pitti> carlos: you need the en_US.xpi as 'C' translation?
<carlos> hmm, that's not in the spec from Mozilla
<pitti> asac: are you talking about translations of extensions or translations of ffox itself? (we do about the latter)
<carlos> pitti: yes, although it usually doesn't exist, so en_US.jar (which exists in Firefox) would be enough
<pitti> asac: extension translations won't be covered by that for now
<asac> pitti: well then its not worth anything
<carlos> asac: in that case, to support extension xpi we would need to do some changes in Launchpad to handle them
<asac> pitti: or at least not much
<pitti> asac: it's about automatically updating the translations from Rosetta without the need to touch m-f-l-a
<asac> pitti: our applications already have translations ... launchpad should provide means to collaborate in translating all those that are not yet translated
<carlos> asac: could you point me to an example of such .xpi file to take a look?
<pitti> asac: right now we cannot use LP to translate ffox/tbird/etc/
<carlos> asac: we will import existing translations
<carlos> as we do for .po files
<asac> pitti: we don't want to either ... translations are updated upstream
<asac> pitti: we want translation of those applications that are not yet translated
<asac> pitti: which are mostly extensions
<pitti> asac: but new languages, too
<asac> pitti: yeah ... i agree with that
<carlos> asac: dude, we need to do one step at a time
<pitti> asac: a lot of upstream xpi are missing translations of help, too
<asac> carlos: well ok
<asac> carlos: if its just the initial step then its ok
<carlos> asac: yeah, first native support for .xpi, then, cover any special case that use .xpi file format
<pitti> mvo: hm, these automatic package installation failure bugs are not that useful (see bug 129168)
<ubotu> Launchpad bug 129168 in apport "package apport 0.93 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New]  https://launchpad.net/bugs/129168
<pitti> mvo: any chance that apt could add some details?
<mvo> pitti: I was working recently on a dpkg-log patch for apt that will capture all of dpkgs output
<asac> carlos: fwif ... look at http://people.ubuntu.com/~asac/funkymonkey.xpi (its just greasemonkey)
<pitti> mvo: ah, good
<asac> s/fwif/fwiw/
<mvo> pitti: it seems to be working quite well for me, I will merge it soon I think. I need to explain the report generator to attach the log inside libapt too. you will have to explain what format is expected etc
<carlos> asac: cool, thanks
<carlos> asac: that should be enough to figure a way to support that specific layout
<ogra> ogra@laptop:~$ grep logintest /etc/passwd
<ogra> logintest:x:1004:1005:,,,:/home/logintest:/bin/bash
<ogra> ogra@laptop:~$ ps aux |grep -c logintest
<ogra> 5
<ogra> ogra@laptop:~$ ps aux |grep -c 1004
<ogra> 40
<ogra> can anyone explin why my system seem not to be able to resolve usernames anymore ?
<ogra> *explain
<pitti> ogra: logintest is longer than 8 characters
<pitti> ogra: ps usually displays numbers in that case
<asac> carlos: ... there is no standard layout of xpi's ...its all generic
<asac> carlos: you have to look at chrome.manifest file
<carlos> asac: I see
<asac> carlos: otherwise you will end up implementing zillions of special cases
<ogra> pitti, ah, thanks, i was hoping i had found the cause for my login problem :/
<carlos> hmm
<carlos> interesting...
<leftcase> Hi folks, I'm trying to get to the bottom of a problem with network manager and atheros WiFi cards. I think I've sussed out whats going on but just wondered if anyone could help me puzzle it through
<carlos> asac: so just to confirm it to you... our current code will only allow Firefox and Thunderbird translations, we will need more code changes in Launchpad to handle the kind of file you just gave me
<mvo> pitti: could you please check https://wiki.ubuntu.com/StableReleaseUpdates?action=diff ?
<iwj> soren: re Debian #421344> My initial reaction is `DDTT'.
<asac> carlos: i don't know your code :) so i can't tell
<carlos> I'm not asking but telling you it :-)
<carlos> asac: thanks for your input
<asac> carlos: as long as you cannot deal with arbitrary .xpi extensions
<asac> then its true
<iwj> <ubotu> Error: Could not parse data returned by Debian: <HTTPError 500 Internal Server Error>
<infinity> iwj: Congrats on confusing the bug bot.
<asac> carlos: remember that the only thing that is special case in regards to translations are firefox/thunderbirda applications on their own ... but even they have chrome.manifest files iirc
<iwj> infinity: :-)
<carlos> asac: yeah, I guess should be easy to change our code to be more generic so we don't assume things like we do right now
<asac> carlos: i am always on #ubuntu-mozillateam if you need more input
<carlos> asac: cool, thanks
<asac> carlos: i would be open to discuss the different approaches if you want
<asac> carlos: if not ... well :)
<carlos> asac: I will need to write another spec so I will ask you for more input
<carlos> don't worry
<pitti> mvo: looks ok to me
<soren> iwj: ddtt?
<jetscreamer> monitor autodetection could use some work eh
<mjg59> jetscreamer: Bug #?
<leftcase> sod it, I'll got for it anyway!
<infinity> soren: Don't Do That, Then.
* Fujitsu wonders when dogfood is likely to get enough buildds to overcome the lack of non-languagepack i386 builds.
<jetscreamer> i dunno... i just worked around it with xvrefresh= & xhrefresh
<soren> infinity: Doh...
<wolfe> mmmm dogfood
<mjg59> jetscreamer: The autoconfiguration is based on the values obtained from your monitor
<mjg59> If the monitor lies, things become harder
<soren> iwj: You don't find it reasonable to mark a symlink as a conffile?
<Mithrandir> soren: it's never worked and it's well-known that it doesn't.
<iwj> Marking a symlink as a conffile is not what conffiles are for; the conffileness is applied by dpkg to the target of the link and not to the link contents.
<leftcase> I noticed whilst checking out a bug report in network manager that a dev had suggested that teh bug was in madwifi - Checking over on madwifi, they have now fixed the bug (wext compliance)
<jetscreamer> i'm not trying to say anything but relay this data: it didn't like to kanotix, which is where i got the values to enter for the xv&xh :)
<iwj> This is so that if the sysadmin (or someone) moves a conffile and leaves a symlink behind, the right things happen.
<jetscreamer> err s/like/lie/
<mjg59> jetscreamer: Then please file a bug
<jetscreamer> but no idea, i just know what it did
<mjg59> That way we can work out what the problem is
<jetscreamer> damn my hd is clicking... just xp :)
<leftcase> But the bug is still happenening :-S so, could anyone point me towards which version of madwifi is supplied in gutsy in the restrictued modules ? :-S
* jetscreamer goes back into lurkmode
<soren> Mithrandir: That (in itself) doesn't mean it's not a bug and shouldn't be fixed.
<Mithrandir> soren: I think it should be fixed by policy saying "don't mark symlinks as conffiles, HTH, HAND"
<soren> This seems to be use-a-lot-of-acronyms-soren-doesn't-know day.
<soren> Mithrandir: HTH? HAND?
<infinity> soren: I don't honestly see how marking a symlink as a conffile makes sense, really.
<infinity> soren: Hope That Helps, Have A Nice Day.
<leftcase> So that I can create a proper bug report with enough information included to make it just mabey, possible bloomin' useful to someone!
* Fujitsu finds wtf useful for these odd acronyms.
<ogra> hmmm, weird, how could my /usr/bin/x-session-manager vanish ?
<soren> infinity: In this particular case I'm working on, there are symlinks from a dir in /etc/ldap/ that points to schema's that slapd should load.  If an admin for some reason don't want this, we should be able to just remove the symlink and not have it recreated on the next upgrade.
<soren> infinity: The fix - of course - is to provide a script that handles these symlinks, so that they're not part of the package..
<soren> infinity: But that's got "workaround" written all over it, IMO.
* leftcase wonders if he failed to observe some special ubuntu-devel etiquette upon entering the room which has rendered him as an object of contempt...
<infinity> soren: They can either be "managed", or only created on fresh installs.
<infinity> soren: It's not rocket science to not create them over and over on upgrade.
<soren> infinity: Of course not.
<soren> infinity: The same holds true for configuration files, but marking things as conffile just makes it easier.
<infinity> soren: The problem, of course, is that it fundamentally mucks with how dpkg thinks about these things.
<mjg59> leftcase: If nobody answers your question, it's likely that they either don't know or are currently busy
<infinity> soren: And allowing your case breaks the other case (moving a conffile, symlinking to it, and having dpkg follow the symlink)
<leftcase> mjg59, thankyou for your assistance
<pitti> leftcase: madwifi is currently at version 0.9.3.1
<pitti> oh
<infinity> soren: Given that the current behavior is well-known (though perhaps not documented), "fixing" it could opena can of worms in breaking other systems.
<soren> infinity: Well, yes, I can see that that is a) somewhat useful (I've never needed it myself, though), b) what people are used to and probably rely on in some cases.
<soren> infinity: Exactly.
<soren> Oh, well. Back to the drawing board.
<infinity> if [ -z "$2" ] ; then ln -s foo bar; fi ?
<infinity> (In postinst)
<infinity> Seems the simplest route.
<infinity> soren: ^^
<norsetto> pitti: Hi Martin, did you receive my email about mentoring?
<pitti> norsetto: not that I can see
<norsetto> pitti: ok, I'm resending now
<soren> infinity: Sure, sure.
<pitti> infinity: you probably want that on upgrades as well, though
<pitti> soren: ^ so you probably want dpkg --compare-versions "$2" le "versionthatintroducesthis"
<soren> pitti, infinity: Yeah, I'm doing it on upgrades from version older than the one where I'm introducing this, and on new installs.
<pitti> soren: "le" will do that ('empty version is later than any')
<norsetto> mvo: Hi Michael, you also have not received my email?
<pitti> soren: erk, wrong; that's le-nl
<pitti> soren: so, le-nl should DTRT then
<soren> pitti: Got it.
<mvo> norsetto: I got it, sorry for not answering yet
<norsetto> mvo: np, just checking, thanks
<pitti> (if only I could invent a good expansion for 'nl' to finally memorize it)
<cjwatson> pitti: "no-[version-is] -later
<cjwatson> "
<norsetto> pitti: nl=netherlands (they are your neighbours after all....)
<pitti> aah, thanks; so 'None is Later'
<cjwatson> or that, that's simpler
<asac> pitti: iceowl+iceowl-extension took an incouraging 2 hours to slip through debian NEW yesterday ... can we do something similar for sunbird+lightning :) ?
<asac> s/incou/encou/
<pitti> iceowl?
<geser> aka sunbird
<pitti> yet another copy...?
<bhale> pitti: for freedom!
<asac> pitti: right
<asac> pitti: should be the last copy for some time :)
<asac> pitti: then we would be complete ... just let me know if I should upload or not :) ... if you don't like the non-free files we can sync from debian as well :)
<geser> aren't there any mozilla projects left which Debian didn't "iced" yet?
<pitti> asac: well, today is Mithrandir's archive day, tomorrow Riddell's; so choose your blackmail target :)
<Kmos> :)
<pitti> asac: I'm not that concerned about the icons etc, just a little nervous about other-licenses/ (but we had that discussion already)
<asac> pitti: honesty, i don't want to swim against the tide
<asac> pitti: the icons that are non-free are in other-licenses :)
<asac> geser: xulrunner + nss + nspr
<alesan> hi, any info on how to prepare a different initram image?
<alesan> I mean, create a custom image from the current one
<zul> morning
<pitti> hey zul
<zul> hi pitti how are things?
<pitti> zul: pretty good! and for you?
<zul> pitti: son was sick this weekend but ok
<pedro_> morning
<realist> evening :-)
<norsetto> pitti: got the email?
<pitti> norsetto: ah, I got it now; weird, I didn't get the previous one
<norsetto> np, I think some spam filters don't like my ISP....
<pitti> Riddell:  kdepimlibs (3.92.0-0ubuntu1~ppa1) gutsy; urgency=low
<pitti> Riddell: was that actually meant to hit gutsy, or was it a mis-upload?
<norsetto> pitti: btw, when you have time let me know if what I did for bug 128697 can help.
<ubotu> Launchpad bug 128697 in restricted-manager "restricted-manager misses man page" [Undecided,Confirmed]  https://launchpad.net/bugs/128697
<Riddell> pitti: it was a mis-upload
<pitti> norsetto: oh, thank you!
<pitti> norsetto: right, no patch etc. necessary, I'll just put it into the bzr tree
<Riddell> pitti: it can sit there happily enough until 3.92 is actually released later this week
<pitti> Riddell: it's gutsy, so beta versions aren't that evil yet :)
* StevenK ponders what NBS housework is left to do.
* pitti indulges some lunch, bbl
<cjwatson> would somebody NEW partman-auto-loop, please? ideally review it for main at the same time ...
<cjwatson> (installer-for-windows spec)
<Mithrandir> doko: is it pycentral or pysupport we like?
<Mithrandir> cjwatson: looking
<doko> Mithrandir: the former
<geser> Hi Hobbsee
<Hobbsee> hey geser
<Mithrandir> cjwatson: looks mainable to me, but that's really pitti's domain.
<Mithrandir> pitti: any objection to letting partman-auto-loop just go directly to main?
<seb128> Hobbsee: can you archive accerciser gnome-keyring vte passepartout glade-3 gtkmm2.4 glibmm2.4 on REVU?
<Hobbsee> seb128: sure
<seb128> thanks
<Hobbsee> seb128: no problem.  consider it done
* seb128 hugs Hobbsee
<Mithrandir> pitti: I just accepted it; if you object, we'll change it later.
<Mithrandir> cjwatson: accepted
<Mithrandir> doko: thanks
<cjwatson> Mithrandir: thanks!
* Hobbsee hugs seb128.  all gone :)
<Hobbsee> seb128: you couldnt just request that i archive the rest, could you?  *g*
<seb128> no :p
<Hobbsee> darn.
<coNP> thanks Hobbsee :)
<Hobbsee> coNP: :)
<Hobbsee> because if you did, that'd cut our reviews needed a lot...
<alesan> re
<alesan> on https://help.ubuntu.com/community/USplashCustomizationHowto there is info on how to update the splash screen. it is updated up to edgy, I guess the same applies to feisty right?
<norsetto> /motd
<norsetto> doh :-O
<Hobbsee> alesan: sounds like a #ubuntu type question
<alesan> Hobbsee, well sorry I thought it was more appriopriate here. most people on #ubuntu don't know what a initram is :(
<alesan> I'm building my own ubuntu iso file.
<alesan> with customized stuff etc
<Hobbsee> oh, thought that was -motu
* Hobbsee cant read, it seems.
* norsetto lends his glasses to Hobbsee
* Hobbsee points to her own
<Hobbsee> REVU is sending me insane, it looks like
<StevenK> pitti: Ping me when you get back from lunch, please
<pitti> Mithrandir: fine for me
<pitti> StevenK: pong
<StevenK> pitti: Right, I'm trying to fix postgresql-pljava. Nothing of the Java stuff is broken, but the build fails because it Build-Depends on postgresql-server-dev-8.1, but pg_config returns "VERSION = PostgreSQL 8.2.4"
<pitti> StevenK: right, it should really use 8.2
<StevenK> pitti: Fair enough, it looks to be a s/8.1/8.2/ on the control file
<pitti> StevenK: I don't know if the current upstream version even works with 8.2, but Peter Eisentraut is usually catching up ASAP
<pitti> StevenK: isn't that fixed in Debian yet?
<StevenK> Nope.
<pitti> StevenK: hm, then upstream might not support 8.2 yet
<StevenK> pitti: I'm happy to fix0r it against 8.2 and then test it if you throw me some pointers.
<StevenK> And if you reply back with 0xdeadbeef, I *will* get you. :-P
<pitti> StevenK: hm, if you never touched a PL, then it might actually be faster if I try myself
<StevenK> http://xkcd.com/138/ for the pointers joke
<pitti> StevenK: Debian bug 419305 FYI
<pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419305, since ubotu cannot read it ATM
<StevenK> Yeah, I know BTS URLs. :-)
<pitti> I didn't doubt, just for clickability's sake :)
<StevenK> But no reply since 14th April doesn't fill me with confidence ...
<pitti> wow, I sent those bugs on my bday? shame on me
<StevenK> Haha
<pitti> yeah, that package didn't see action recently
<Hobbsee> bad pitti!
* Hobbsee notes that she also fixed adept on hers.
<StevenK> pitti: I'm happy to throw a 8.2 built package at you, if you like.
* pitti laughs at the webcomic
<pitti> StevenK: oh, sure; amd64?
<pitti> StevenK: if it builds, that's already a gooood sign
<StevenK> pitti: xkcd for the win. :-)
<pitti> yeah, 1.3.0 is the latest upstream version
<pitti> StevenK: source or debdiff should work fine, though
<StevenK> pitti: I don't mind, either works.
<StevenK> I'm just checking the thing builds first
<StevenK> /tmp/buildd/postgresql-pljava-1.3.0/src/C/pljava/XactListener.c:107: error: 'xactCB' undeclared (first use in this function)
<StevenK> Also implicit declaration of functions RegisterXactCallback and UnregisterXactCallback
<soren>  /win 5
<pitti> StevenK: don't bother, I'd say; that's something for upstream
<pitti> StevenK: other PLs like the ones for Ruby generally needed new upstream versions for new major postgresql versions
<StevenK> pitti: Actually, the error looks to be a code problem
<pitti> StevenK: but why not just leave it building the 8.1 plugin?
<StevenK> Well, then I need a pg_config that says it's version 8.1
<StevenK> And there doesn't seem to be a libpq-8.1-dev
<pitti> StevenK: it should be in postgresql-server-dev-8.1
<pitti> StevenK: /usr/lib/postgresql/8.1/bin/pg_config
<pitti> StevenK: /usr/bin/ just provides the version that client side packages should use (always the latest libpq)
<StevenK> Ahhhh
* StevenK tries to convince the upstream build system to call /usr/lib/postgresql/8.1/bin/pg_config
<StevenK> /usr/bin/ld: cannot find -lgcj
* StevenK kicks ... something. How ld decides it can't find something seems to be subtle
<pitti> StevenK: is it not in libgcj8-dev?
<StevenK> /usr/lib/gcc/x86_64-linux-gnu/4.2/libgcj.so is in libgcj8-dev
<StevenK> If ld can cope with that
<pitti> StevenK: hm, that's doko's realm, but I'd think it should be /usr/lib/libgcj.sdo
<pitti> .so even
<pitti> bah, my keyboard has just broken, producing 'd's all over the place
<StevenK> /usr/lib/libgcj.so.80 exists, but no plain libgcj.so
<Hobbsee> ...then stop hitting the d key?
<pitti> Hobbsee: it happens by pressdingd any other keys
* pitti grrs
* StevenK chuckles
<Mithrandir> dingding
<StevenK> Shouldn't that be 'grrddrrs'? :-P
<pitti> oh
* pitti begdins to suspect the spilt water
<Hobbsee> hehe :)
<StevenK> Haha
<pitti> brg
<pitti> brb even
<Hobbsee> the d's and the g keys are taking over!
<StevenK> Keyboard drawers are a good thing...
<StevenK> Considering I usually type without looking, with the drawer fully retracted.
<StevenK> Which causes my small cousins issues like, "How do you know where the keys are?" and then getting dirty looks when I say, "They're under my fingers of course."
<infinity> "I can tell where the keys are, based on the whitespace surrounding them.  If you were a Python freak like me, you'd understand."
<infinity> StevenK: Speaking of python freakiness, does linda still get love, or did you get bored with it?
<StevenK> The answer is somewhat complicated.
<StevenK> The incredibly simple answer is "No, since that equates to Debian work."
<StevenK> infinity: libnss-db! :-P
<doko> StevenK: yes, know issue (different gcc and gcj versions); maybe I should add this link in /usr/lib/jvm/java-gcj-compat/lib ...
<doko> StevenK: or use gcc-4.2 for linking
<jdstrand> are old security updated packages archived and if so where?  (eg, I am looking for bind9_9.3.2-2ubuntu1.2.diff.gz)
<cjwatson> jdstrand: as far back as dapper, yes
<geser> jdstrand: yes, on LP: http://launchpadlibrarian.net/6260265/bind9_9.3.2-2ubuntu1.2.diff.gz
<cjwatson> jdstrand: https://launchpad.net/ubuntu/+source/bind9 -> 9.3.2-2ubuntu1.2 -> dapper i386 (or whatever) -> Resulting binaries -> pick one
<cjwatson> or what geser said for the source
<jdstrand> cjwatson, geser: thanks
<pitti> one key dismounting - vacuum - clean - key remounting cycle later, /me sets no-more-errant-d-keystrokes to implemented
<Hobbsee> hurrah!
<StevenK> doko: Actually, debian/rules contains CPPFLAGS += -I/usr/lib/jvm/java-gcj/include/, should I change that?
<geser> pitti: luckily it wasn't a stuck 'y' key: "Are you sure to proceed?" :)
* StevenK was waiting for pitti to get an apt prompt. "Type, 'Yes, do as I say' to proceed" -> "Yes, dddo ads Id sday"
* realist hugs their mechanically switched keyboard :-)
<pitti> StevenK: you should rather be concerned about -L flags
* StevenK is trying to set CC=gcc-4.2 first
<StevenK> And fix the pg_config hack properly
<StevenK> Aww, it seems infinity is ignoring me.
<doko> StevenK: no, this is correct
<pitti> StevenK: the three magic letters 'nss' terminate his IRC link
<Hobbsee> a new exploit!
<StevenK> pitti: Or at least, cause his screen to detach automatically
<Fujitsu> Peril-sensitive screen sessions. I like it.
<StevenK> pitti: I'm so tempted to beg the archive admin to paste the command-line and result when I get yada demoted like the pox that it is.
<pitti> StevenK: it's not yet in anastacia
<pitti> StevenK: ah, right, the only remaining rdepends is ... *cough* libnss-db
<StevenK> Exactly ...
<StevenK> Which is why I keep hitting up infinity.
<pitti> sorry, infini*bzzzzt*
* StevenK chuckles
<Mithrandir> > pkg-config --variable pyexecdir pygtk-2.0
<Mithrandir> /usr/lib/python2.4/site-packages
<Mithrandir> hmm, that doesn't look right, does it?
<sladen> Mithrandir: I was trying just that the other day.  It didn't work
<sladen> (trying to get pyclutter to work)
<Mithrandir> pyclutter?  This is something else entirely
<sladen> it depended on testing `pkg-config pygtk-2.0`
<StevenK> GAH
<StevenK> You stupid build system! *WHO* came up with using $(COMPILER), I'll kill them myself.
<Mithrandir> StevenK: having fun with libnss-db?
<StevenK> Nope, postgresql-pljava
<StevenK> Mithrandir: I'm done with libnss-db, but infinity doesn't love me enough to sign off on it.
<thom> StevenK: kill dexter
<thom> on principle, relevancy is irrelevant
<StevenK> I'm sorely tempted.
<pitti> hi Keybuk
<Keybuk> \o/  finally emptied my INBOX
<Hobbsee> heya Keybuk!
<StevenK> Keybuk: Select everything ... delete, it shouldn't be ardous. :-P
* ogra applauds Keybuk 
<StevenK> arduous, even
<mvo> hey Keybuk
<Mithrandir> Keybuk: you've failed to answer my suggestion for call time tomorrow, it seems?
<alesan> anyway, can somebody explain me how to modify the usplash default logo? I want to create my own version of ubuntu with custom packages drivers etc
<pitti> Keybuk: what Mithrandir said, me2
<Keybuk> those are new mails :p
<Keybuk> actually, I just replied to them all
<pitti> ah, cool
<StevenK> I am so going to break postgresql-pljava's build system and its author into little pieces.
<StevenK> What's the point of using make vars if I can't export (and actually override them) in debian/rules
<Riddell> alesan: look at the source of any *-artwork-usplash packages
<cjwatson> Keybuk: any strong opinions on the best way to add support to initramfs for having the root filesystem be loop-mounted from an image on another filesystem?
<cjwatson> Keybuk: (for installer-for-windows, but I'd like it to be generic and controlled by a boot parameter)
<Keybuk> ROOT=LOOP= or something?
<Keybuk> though you would need to specify the filesystem with the loop on it, and the path to the loop
<cjwatson> mm, I was contemplating a different argument for the hosted filesystem so that they can both be UUID-style
<Keybuk> it might make more sense to still keep root= the same, but if loop= is set, mount that after mounting the root
<cjwatson> e.g. host=UUID=... ROOT=UUID=... and have it mount host= first
<Keybuk> root=UUID=...
<Keybuk> loop=/path/to/fs/on/root
<cjwatson> that might be more straightforward to implement, yes
<cjwatson> I guess UUIDs won't help for locating the image, thinking about it :)
<cjwatson> and mount -o move ${rootmnt} /host or something
<Keybuk> yeah
<Keybuk> if [ -n "$LOOP" ]  ...
<Keybuk> after mounting $ROOT to move it all out the way again and mount the image
<Keybuk> that way you can use the existing device-exists-and-vol_id-works loop
<cjwatson> yeah, that was the thing I was concerned about not duplicating
<cjwatson> should I use a local-bottom script, do you think, or just bang it all into scripts/local:mountroot?
<cjwatson> I guess the problem with a local-bottom script is that everything else would have to depend on it to ensure correct behaviour
<Keybuk> put it in mountroot if I were you
<cjwatson> I think I also need to expose /host in the real root filesystem so that /boot can be bind-mounted onto it
<cjwatson> little maze of twisty filesystems, all alike
<cjwatson> I wonder if I can mount /root; mount -o move /root /host; mount -o loop /host/blah /root; if [ -d /root/host ] ; then mount -o move /host /root/host; fi
<Keybuk> yes you can
<StevenK> pitti: Right, I finally convince postgresql-pljava to actually build.
<StevenK> convinced, too
<pitti> StevenK: wow
<StevenK> The build system in it sucks hard.
<StevenK>  4 files changed, 32 insertions(+), 1 deletion(-)
* StevenK uploads it before he changes his mind.
<asac> stgraber: yt?
<kylem> anyone running gutsy care to test a new intel driver release?
<kylem> deb http://people.ubuntu.com/~kyle/testing/xf86-video-intel-RC/ ./
<Tonio_> seb128: ping ?
<seb128> Tonio_: sort of pong, I was about to do a break ;)
<Tonio_> oki
<seb128> ask your question
<seb128> I'm not in a hurry ;)
<Tonio_> seb128: can you drop the kdebluetooth upload I just commited ?
<Tonio_> seb128: bad call in my bash-history, should have build and not upload....
<Tonio_> seb128: it is just a testing package, not intended to be publish right now....
<seb128> Tonio_: no such package in queue, is that a new package or a normal upload?
<Tonio_> seb128: normal upload
<Tonio_> seb128: I was wondering who can discard this
<seb128> Tonio_: dunno how to reject those and if that can be done
<Tonio_> seb128: argh...
<seb128> the best way is to do a new upload reverting the changes
<Tonio_> seb128: I'll do that then....
* seb128 does a work break, see you later
<Tonio_> bye
<ogra> seb128, enjoy
<iwj_> doko: Thanks for disposing of that silly bug 126994.
<ubotu> Launchpad bug 126994 in python-defaults "update-alternatives does not include python or gcc" [Undecided,Won't fix]  https://launchpad.net/bugs/126994
<allee> Tonio_: hi
<allee> Tonio_: were can I get the new debs (for testing and alioth merge)?
<cjwatson> mvo: why does command-not-found emit its messages to stdout?
<cjwatson> mvo: I think this is a bug and they should go to stderr; I have a somewhat screwed system at the moment that goes like this after a failed fsck:
<cjwatson> bash: groups: command not found
<cjwatson> bash: lesspipe: command not found:
<cjwatson> bash: The: command not found
<cjwatson> The program 'apt-get' is currently not installed. [...] 
<cjwatson> (I have no idea why it's calling apt-get there ...)
<Tonio_> allee: http://ubuntu.tonio.homelinux.org/
<allee> Tonio_: thx
<ogra> cjwatson, do you know if there is a non harmful way to replace a debconf note message in an udeb without turning it into an error ?
<ogra> i heard notes should go away
<cjwatson> ogra: replace it with what?
<Tonio_> allee: the only thing I changed in the debian packaging is a patch to hide a few desktop files, which don't need to be in the kmenu as they are all accessible via the systray
<cjwatson> ogra: oh, notes are still fine in udebs
<ogra> cjwatson, ah, ok, the debian bug i got for ltsp sounded like it would be cancelled there as well
<allee> Tonio_: makes sense.  I've check and ping upstream for 'commit okay'
<cjwatson> ogra: it's possible somebody said that notes are deprecated in udebs too, but they're mistaken :-)
<carlos> pedro_: hi
<Tonio_> allee: btw I don't know if such a patch should be merged upstream.... I'd say yes, but you decide
<cjwatson> mvo: ah, in fact apt-get is called because .bashrc evaluates the output of lesspipe which includes command-not-found suggesting an apt-get command to run
<allee> Tonio_: I'm not upstream :)
<pedro_> hello carlos!
<ogra> cjwatson, calming :) i wouldnt want a red background just to tell the user something :) they want to make it an error
<Tonio_> allee: hehe
<cjwatson> mvo: do you mind if I file a bug and just make the relevant changes on bazaar.launchpad.net directly?
<mvo> cjwatson: not at all, that is very welcome
<Tonio_> allee: fyi, just checked, it crashes here :)
<allee> Tonio_: :)
<allee> Tonio_: why this strange version and not 1.0~beta4 ?
<cjwatson> mvo: committed; would you upload it? it seems to have a weird source package build process I can't quite manage to reproduce accurately
<Tonio_> allee: can you remind me of the alioth url for kdebluetooth please ?
<asac> calc: do you have a minute testing a ipw3945 workaround?
<Tonio_> allee: this strange version because it is not the one that should have been uploaded, it was just for personal test :)
<mvo> cjwatson: sure, happy to do so (does bzr-buildpackage --native not work?)
<cjwatson> mvo: I normally use debuild -S
<cjwatson> mvo: it has a debian/arch-build target, and .bzrignore and a scan.data file were missing from the resulting source package when I built it
<mvo> cjwatson: I will check it, the missing scan.data  is quite possible  :/
<lamont> debuild -S with the right stuff in ~/.devscripts is love
<calc> asac: sure, i'll have to grab my laptop
<calc> asac: booting into gutsy cd now
<Riddell> cjwatson: I copied out the seed diagram from the sprint into a nicer format http://kubuntu.org/~jriddell/tmp/seeds.png
<Riddell> cjwatson: is there a seeds wiki page I can link to there from?  I can't seem to find one just now
<calc> asac: ping
<asac> calc: ok
<asac> calc: do you have a process ipw3945d* running?
<calc> asac: i had to reboot it failed to start X for some reason, grr
<asac> hmm
<calc> asac: i'll look for that as soon as it finishes booting
<calc> ok it worked this time, loading gnome now
<calc> grr now its hanging before the gnome splash comes up
* calc kicks this live cd
<asac> well ... i think we need to test when i return then :)
<asac> calc: http://ubuntuforums.org/showthread.php?t=492386&page=3
<asac> there is a potential workaround at the end
<asac> maybe test that
<calc> ok looking
<calc> maybe it will boot all the way this time :)
<asac> e.g. restart the " regulatory daemon"
<calc> asac: interesting ok i'll test that as soon as i get it up
* calc hopes the tribe3 cd is just really buggy, otherwise his laptop is dying
<kylem> didn't we have tribe3 troubles at the sprint?
<calc> kylem: not sure, i didn't try tribe3 at that time :\
<calc> i heard there might be some kind of issue with it
<calc> but not sure what
<asac> tribe3 livecd has fs issues iirc
<calc> asac: ah that might explain what I am seeing
<cjwatson> Riddell: SeedManagement
<calc> asac: restarting the daemon doesn't seem to help
<calc> asac: at least in getting NM to connect to a network
<cjwatson> Riddell: thanks!
<asac> calc: well i would like to see if time needed wpasupplicant alone is improving
<asac> e.g. just give wpasupplicant essid + driver ... in ap_scan mode 1
<asac> then see how long it takes until it associates
<calc> ok
<asac> it took stgraber about 2-3 minutes ... which is too long
<keescook> bryce: can you take a look at http://revu.tauware.de/details.py?upid=6210 ?
<bryce> ok
<asac> ok out ... bbl
<bryce> ah, openchrome's been on my todo list for some time
<bryce> keescook: the diff looks good and clean
<bryce> keescook: I'm curious what "svn357" means
<keescook> I imagine that's subversion snapshot from rev id 357
<calc> asac: its taking more than 3min on an open AP
<calc> asac: i'll try the wpa one
<calc> asac: the timeout times may be faster though from the looks of it
<bryce> ahh, good call
<calc> asac: i gave it 4.5min and it still didn't connect to the open AO
<bryce> keescook: yes I think it'd be good to upload
<AngryElf_> how would I get in touch with the team/person that packages FF?
<cjwatson> AngryElf_: #ubuntu-mozillateam; the lead maintainer just left for the evening though
<cjwatson> there's a corresponding mailing list too
<calc> asac: after playing around with associating with the open ap when i tried the wpa ap it did it immediately, so i'm rebooting now to see how long it takes on a fresh boot
<afflux> Is it safe/recommended to use the reboot script provided by upstart-compat-sysv or sysvinit from an application like that one: http://cs.unm.edu/~dmohr/grub.php (I'm working with upstream to get this packaged for ubuntu)
<calc> asac: ap_scan can't even find my wpa AP before trying to attach to the open ap from the look of it
<calc> asac: interesting... :)
<calc> asac: when i killed and restart daemon it could see both, doing further testing
<calc> asac: it saw it at first but checked later and it was no longer in the list
<superm1> Hi guys, when doing usplash artwork, how is the pallete limited on the progress bar?  Is it by the colors used in the full screen image?  I made both indexed images, but the color of the progress bar appears wrong during splash
<mjg59> superm1: The progress bar has to use the same palette as the rest of the image
<superm1> that would likely be the issue then
<superm1> k
<cjwatson> afflux: shouldn't that GUI just call grub-set-default?
<mr_pouit> could an archive-admin remove avifile-win32-plugin for amd64 from the buildds? It is not built anymore in gutsy (only for i386), and avifile FTBFS on amd64 because it still tries to build it :/ (cf. http://launchpadlibrarian.net/8598963/buildlog_ubuntu-gutsy-amd64.avifile_1%3A0.7.47.20070718-1ubuntu1_FAILEDTOBUILD.txt.gz)
<afflux> cjwatson: err, yes. I'll tell upstream, thank you :)
<geser> mr_pouit: I'd say you need to patch avifile to call dh_gencontrol in debian/rules with the right package set on amd64 (and similar archs)
<wereHamster> what's Ubuntu's policy on RPATH/RUNPATH?
<calc> wereHamster: i'm pretty sure its the same as debian's which is don't do it
<wereHamster> even RUNPATH is discouraged?
<calc> RPATH is, i'm not sure about runpath, never actually heard of it
<wereHamster> calc, do you have wine installed right now?
<calc> no
<wereHamster> marcel@Shuttle:~$ objdump -x `which wine` | grep PATH
<wereHamster>   RPATH       $ORIGIN/../lib
<wereHamster> argh.. why?
<calc> grr gateway released a really nice new laptop less than a month after i bought mine :\
* calc was trying to wait since he knew it was due soon, but couldn't any longer, oh well
<calc> 250gb hd, 2gb ram, n wireless, etc :\
<kopfgeldjaeger> hi
<wereHamster> what is needed to compile 32bit apps on ubuntu?
<kopfgeldjaeger> build-essential
<kopfgeldjaeger> if youre on a 32-bit ubuntu
<kopfgeldjaeger> if youre on a 64 bit one, try chroot
<kopfgeldjaeger> i have made a bash script, that downloads videos from video sharing sites (youtube, google video, etc.). it uses a webpage and filters the link... any chance to get such little things in universe? cause theres nothing about youtube and so...
<wereHamster> chroot? Don't you have special 32bit packages that [provide 32bit libc.so etc?
<calc> wereHamster: not for every 32 library, but for libc yes
<kopfgeldjaeger> hm.. im quite sure that this exists, but if this is easier than a chroot...
<superm1> well wouldn't it be possible to have a 32 bit pbuilder base to just use instead of maintaining a chroot?
<calc> superm1: yea probably so
* calc doesn't like pbuilder or at least the way it worked the last time he used it
<superm1> well i've yet to try sbuild, so pbuilder has done the trick for me normally
<Chipzz> kopfgeldjaeger: that already existed ;P
<mathiaz> superm1: The Pbuilder how-to explains to setup a 32bits pbuilder on a amd64.
<geser> kopfgeldjaeger: something like youtube-dl or clive?
<mathiaz> superm1: https://wiki.ubuntu.com/PbuilderHowto
<kopfgeldjaeger> yeah
<superm1> mathiaz, ah good, so i was right :)
<kopfgeldjaeger> but NOT in the repos and not for so many sites... well, im sure there is something for more than youtube, but i dont think that theres so much support as the download sites give
<geser> !info clive gutsy
<ubotu> clive: Video extraction utility for YouTube and Google Video. In component universe, is optional. Version 0.2.0-1 (gutsy), package size 30 kB, installed size 172 kB
<mathiaz> superm1: I had to modify my pbuilder script to support arch base files.
<geser> !info youtube-dl gutsy
<ubotu> youtube-dl: download videos from youtube.com. In component universe, is extra. Version 2007.06.22-1 (gutsy), package size 7 kB, installed size 64 kB
<wereHamster> calc, do you have any idea how the 32bit glibc pakcage is named?
<geser> !info ia32-libs
<ubotu> Package ia32-libs does not exist in feisty, feisty-seveas
<kopfgeldjaeger> well, apt-cache search sux :d
<calc> libc6-something
<calc> its only available on 64bit platforms though
<kopfgeldjaeger> ...
<geser> !info libc6-i386
<ubotu> Package libc6-i386 does not exist in feisty, feisty-seveas
<geser> !info libc6-i386 gutsy
<ubotu> Package libc6-i386 does not exist in gutsy
<calc> hmm not sure what it is named
<calc> search for libc6* in apt-cache if you are on amd64
<geser> gah, ubotu doesn't know about package on other archs
<calc> or apt-cache search 32
<geser> libc6-i386 - GNU C Library: 32bit shared libraries for AMD64
<kopfgeldjaeger> !info network-manager-gnome gutsy
<ubotu> network-manager-gnome: network management framework (GNOME frontend). In component main, is optional. Version 0.6.5-0ubuntu8 (gutsy), package size 138 kB, installed size 1752 kB
<calc> geser: ok
<superm1> http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=libc6&searchon=names&subword=1&version=gutsy&release=all will show them all
<wereHamster> what version of binutils does ubuntu use? I've heard that the nwer versions have --enable-new-dtags enabled by default, but ubuntu's binutils don't
<superm1> !info binutils gutsy
<ubotu> binutils: The GNU assembler, linker and binary utilities. In component main, is optional. Version 2.17.20070718cvs-0ubuntu2 (gutsy), package size 1414 kB, installed size 7376 kB
<cjwatson> wereHamster: IIRC RUNPATH is ok
<cjwatson> but not RPATH; use of it has burned us (well, Debian) in the past and is thus discouraged
<wereHamster> superm1, thanks (doesn't your nick have one letter too much? :P )
<wereHamster> cjwatson, ubuntu's wine uses RPATH but not RUNPATH which would override RPATH
<cjwatson> it probably gets a lintian warning for that then ...
<wereHamster> binutils-2.17 seems recent enough, I'm wondering why it doesn't use --enable-new-dtags by default
<cjwatson> I don't recall exactly though, it's been years
<wereHamster> because here on gentoo I don't have to pass anything extra to get the wine binary compiled with RUNPATH
<tarzeau> i have a bug in ubuntu, and i have a fix, can i get karma when i close it?
<asisak> tarzeau: you get some karma points, but if you are not familiar with all the details of bug triage, you should ask on #ubuntu-bugs
<cjwatson> you can only close it if you actually do the upload, in any case
<kopfgeldjaeger> I have a working ubuntu repository (test). How to create the Releases-file? Packages.gz and Packages.gpg already exist. i want to sign my packages
<cjwatson> contributed fixes would normally just be an attachment with the patch checkbox checked
<kopfgeldjaeger> or do i have to sign the packages themselves?
<cjwatson> kopfgeldjaeger: apt-ftparchive release /path/to/repository
<kopfgeldjaeger> thanx
<cjwatson> and then create a detached signature for the resulting Release file with gpg
<kopfgeldjaeger> ok. what does "unknown error while executing gpgv" mean? (translated from german)
<kopfgeldjaeger> that comes when apt-get-updating
<kopfgeldjaeger> apt-ftparchive release /home/andy/repo/ > Releases      was ok, or?
<cjwatson> it's Release not Releases, and the error probably means that the format of Release.gpg is wrong
<kopfgeldjaeger> i mean, instead of Releases "Release"
<kopfgeldjaeger> no ascii?
* cjwatson -> away
<kopfgeldjaeger> still same problem with non-ascii Release.gpg
<wereHamster> superm1, is your binutils version patches somehow? if yes, can I see the patches you're using?
<superm1> wereHamster, That is the binutils version in gutsy
<superm1> so not just the one i'm using
<superm1> the entire package is available here: http://packages.ubuntu.com/gutsy/devel/binutils
<wereHamster> superm1, I'm asking because for example gentoo patches binutils to enable the new dtags by default. Ubuntu doesn't do it AFAICS becuause packages are still compiled with only RPATH
<superm1> wereHamster, perhaps you will want to try a local build with adding --enable-new-dtags and see if that is the case
* wereHamster is not running ubuntu
<superm1> ah i see
<superm1> well if you set yourself up a gutsy chroot, you can at least experiment
<superm1> gentoo has an ebulid for debootsrap i believe
<wereHamster> http://www.winehq.org/pipermail/wine-patches/2007-July/042051.html
<wereHamster> I hope that will do the trick
<alesan> do you have an idea if it's possible to go back from the "lss" isolinux image format to the original image in png or similar formats?
<wereHamster> I finally found out why yukon/wine wouldn't work on ubuntu.. a least I hope I did :)
<alesan> I would really like to understand the isolinux bootlogo... what is the source image, how was it prepared?
<CydeWeys_> Can some Ubuntu person please check this URL and see why it isn't properly gzipped on the server?  http://us.archive.ubuntu.com/ubuntu/dists/feisty/main/binary-i386/Packages.gz
<CydeWeys_> It's causing apt-get update to fail.
<CydeWeys_> Because apt-get expects it to be gzipped, tries to gunzip a text file, and dies.
<elmo> CydeWeys_: works for me
<elmo> CydeWeys_: that file hasn't been modified in a long time, it's more likely you have a broken web cache between you and the server
<CydeWeys_> Hrmm, so what do I do?
<elmo> try 'apt-get -o Acquire::http::No-Cache=1 update'
<CydeWeys_> elmo: See PM
<elmo> CydeWeys_: I don't have any - are you registered with freenode?
<elmo> CydeWeys_: (if not, I suggest a pastebin)
<CydeWeys_> elmo: http://pastebin.ca/639777
<elmo> CydeWeys_: that's with the -o Acquire?
<CydeWeys_> elmo: Yes
<elmo> CydeWeys_: rm /var/lib/apt/lists/us.archive* and try again
<kopfgeldjaeger> wooooowo
<kopfgeldjaeger> i just made an apt repository, with gpg verification!
<kopfgeldjaeger> *g
<CydeWeys_> elmo: Still the same error.
<kopfgeldjaeger> only took 5 hours
<CydeWeys_> elmo: Although it does go through and re-download all of the other ones.
<elmo> CydeWeys_: ok, in that case, you definitely have a broken web cache between you and the intarwebs
<elmo> CydeWeys_: you could change from us.archive to pony.archive in your sources.list, that would work around it for now
<elmo> CydeWeys_: but I suggest you bug your ISP
<CydeWeys_> elmo: How many ISPs keep web caches?
<elmo> CydeWeys_: I don't know any that don't
<CydeWeys_> elmo: pony worked, thanks
<CydeWeys_> This ISP has been nothing but problems.
<CydeWeys_> It's some kind of business T1.
<CydeWeys_> elmo: Is there any harm in sticking with pony in the long run?
<Nafallo> lol, pony :-)
<CydeWeys_> Hey, don't make fun of me.  As far as I'm concerned, pony is the best server, because it's the only one that's working for me.
<elmo> CydeWeys_: right now, pony.archive == us.archive == archive.ubuntu.com.  in the future, us.archive might become an actual host in the US.  so while it won't cause you any problems, it may make things slower for you one day
<elmo> CydeWeys_: whether that matters is up to you
<CydeWeys_> Where is it all hosted now?
<elmo> the UK
<Nafallo> CydeWeys_: I didn't. I realised pony.archive was archive :-)
<CydeWeys_> It kind of sounds like one of the dev's daughters named the server.
<Nafallo> CydeWeys_: cydeweys.archive works as well...
<CydeWeys_> Oh, so any wildcard subdomain will work?
<Nafallo> except the ones pointing to other places. like se.archive, which I think would also have good speed to the US.
<CydeWeys_> So now where did the pony idea come from, elmo?
<Nafallo> but yea, I'll go back to dishes now ;-)
<Chipzz> CydeWeys_: never seen a presentation by Jeff Waugh?
<Chipzz> "No you can't have a pony!"
<Chipzz> http://www.hadess.net/blog/images/cant-have-a-pony.png
<superm1> Chipzz, i saw my first presentation by him at Ulive - quite something else.
#ubuntu-devel 2007-07-31
* mneptok bounces up and down on jono 
<lamont> BenC_: with luck, I'll have -9.20 abi and module files for you shortly
<lamont> as in, within an hour or 2
<lamont> :(
* lamont built -9.19 with -8.18 abi/module files present (which failed - hppa64 modules diffs), then dropped the -9.19 files into -9.20.  should be a case of "presto"
<lamont> then comes lots of figuring out with hppa64 kernels, following which I'll need  an ABI bump because we finally fixed that kernel (and can turn SMP on...)
* soren puts a curse on debconf... grrr...
<LaserJock> soren: I don't know that you want to do that. It might bite back ;-)
* superm1 hopes that soren used the cruciatus curse
<soren> LaserJock: It's been biting my ass for just about three hours now. I say the curse is well deserved.
<LaserJock> soren: working on ebox?
<soren> LaserJock: Sure am.
<soren> Going on holiday next week for a few week (honeymoon on Bali, no less), so I'm in a bit of a hurry to get it done by this week (ff is while I'm away).
<LaserJock> soren: I had a look at the screenshots at the ebox website,  very nice looking
<ajmitch> soren: honeymoon?
<soren> LaserJock: Yeah, it does look shiny, doesn't it? :)
<LaserJock> soren: honeymoon?!? congrats
<soren> ajmitch: Indeed.
<soren> Wedding on Saturday.
<ajmitch> I never knew, I presume congrats are in order
<soren> LaserJock: Thank you very much.
* LaserJock never knew soren had a *real* life ;-)
<ajmitch> soren: since you've travelling all the way to bali, you may as well visit NZ as well
<LaserJock> heh
<LaserJock> ajmitch: how far is it from you?
<ajmitch> probably 7-8 hours or so by plane, I guess :)
<LaserJock> hmm, that's not *too* bad
<ajmitch> not for this area of the world :)
<LaserJock> considering darn near everything is a long flight away from NZ
<ajmitch> ah, looks like it's closer to 10, since you have to stop in australia
<soren> LaserJock: Nah, I keep quiet about it, too. :)
<soren> ajmitch: When I've made it to Bali, I don't think I want to sit on a plane much more.
<soren> ajmitch: :p
<ajmitch> soren: 30+ hours isn't too much of a problem, is it?
<soren> ajmitch: AAAAAAAAAAAAAAARGH!
* ajmitch thinks too much perl has turned him crazy
<bhale> hi ajmitch
<ajmitch> hello bhale
<ajmitch> ah, another server team meeting at an insane time
<soren> ajmitch: Sorry dude, but I really hope there's not going to be another UDS in Australia or NZ anytime soon. I'd go sitting on a plane that long.
<soren> ajmitch: I've only got about 12 hours of battery power on my laptop. That's 18 hours of staring into the back of the chair in front of me.
<ajmitch> boston should be fairly close for you then
<LaserJock> I read a while ago about some Australian researchers working on quantum teleportation, now I know why ...
<soren> ajmitch: I don't really know how long it'll take to get there. 7-8 hours, I think.
<LaserJock> probably
<soren> LaserJock: Yeah. To get the fsck away from there, right now! :)
<LaserJock> it took me about 9-10 to get to Paris/Sevilla
* ajmitch wouldn't mind seeing boston, but most likely won't be going there this year
<LaserJock> me neither
<ajmitch> busy with the phd?
<LaserJock> yeah
<soren> LaserJock: That bad?
<LaserJock> if I can sneak off for a couple days from UES I might
<LaserJock> soren: umm... yeah
<soren> LaserJock: Oh, you are doing UES at least?
<LaserJock> I might
<LaserJock> if it's short
<LaserJock> in Sevilla it was just 2 days
<LaserJock> that wouldn't be bad
<soren> LaserJock: Well, if all the time you've put into Ubuntu was time you should have spent on your ph.d.... Yes, then I can definitely understand you've got some catching up to do. :)
<zul> hey
<ajmitch> soren: how's the server stuff looking now?
<ajmitch> hello zul
<zul> hey ajmitch
<LaserJock> soren: yes, plus UDS is where I get sucked into implementing all kinds of crazy fun things
<zul> heh evil
<soren> LaserJock: Good point, but I don't suspect UES is much better in that respect.
<LaserJock> soren: actually it is more corporate/marketing
<soren> ajmitch: We're trying to get everyone up to speed. For Gutsy we're mostly polishing the existing stuff, we've got and adding a few extra things (eBox and AppArmour), but gutsy+1 is going to rock, I think.
<soren> LaserJock: Oh, I thought it was a development thing, just for edubuntu. Go figure.
<LaserJock> soren: no, it's more about educators and "decision makers"
<LaserJock> we still do all the hardcore development stuff at UDS
<ajmitch> great, I haven't been following it closely
<soren> ajmitch: The server team meetings are all going to be at that time, by the way.
<ajmitch> soren: I was about to ask you if they could ever be shifted by 8 hours either way
<ajmitch> otherwise I'll never turn up
<ajmitch> 3AM just isn't possible when i've got to be at work at 8:30AM :)
<soren> ajmitch: We put it there as that was the only option it it were to be within mine, kees', mathiaz' and rick's core hours.
<soren> ajmitch: Noone has made a fuss over it yet.. (hint)
* ajmitch has only complained about it on irc a few times
<soren> ajmitch: Bah.. It's almost 2 am here, too, and I've got work at 8.
<zul> ajmitch: its all about priorities ;)
<zul> soren: yeah but you probably work from home right?
<soren> ajmitch: Although, getting to work in my case means rolling out of bed an wandering over to my laptop.
<ajmitch> zul: right, and the server team slips far down the list with meeting times like that :)
<soren> zul: Indeed.
<ajmitch> I'm not going to make much of a fuss, since I hardly do anything lately
<ajmitch> it's hardly fair on others to shift a meeting just because 1 person is semi-interested :)
<soren> ajmitch: There might be other geographically challenged people. :)
<zul> australians? ;)
<soren> Those are the ones.
<soren> And kiwis.
* ajmitch shuts up about various other challenges they may have
<soren> True. If only geography was their only issue. :)
* ajmitch knows a few people in #ubuntu-nz that use ubuntu & debian quite a bit on servers 
<keescook> ajmitch: I'll bring it up tomorrow.  there was brief discussion about meeting weekly (and having it shift around).
<ajmitch> keescook: ok, thanks
<mjg59> calc: Could you build the package from http://www.codon.org.uk/~mjg59/tmp/x86_debug , install it on your laptop and then do
<mjg59> vbetool post 2>output
<mjg59> and compress the output then stick it somewhere?
<mjg59> It may take a couple of minutes to fail
<mjg59> And you'll probably end up with a blank screen at the end of it
<mjg59> So just ctrl+alt+del
<calc> mjg59: i need to run that on amd64 right?
<mjg59> calc: Yes
<calc> mjg59: ok
<calc> mjg59: about to do the test, be back in a few minutes
<calc> mjg59: is there a way to force it to sync immediately to disk?
<calc> mjg59: the log ended up being 0 bytes
<calc> should i just mount the fs in sync mode?
<mjg59> calc: How did you reboot?
<calc> mjg59: back now
<calc> mjg59: hmm oh yea i probably did it wrong :\
<calc> mjg59: i did magic sysrq s u b
<calc> mjg59: i got a 1.6MB log using mount sync though
<calc> mjg59: i can retry using ctl-alt-del if that will sync out the disk properly without needing mount sync
<calc> mount sync seem to cause it to write very slowly
<calc> mjg59: http://cheney.ws/debug/vbetool.debug.output.bz2 <- what i have so far, i'll try ctrl-alt-del without sync mount
<calc> mjg59: brb
<calc> back
<calc> mjg59: ah by doing ctl-alt-del i got a much larger log file
<calc> -rw-r--r--   1 root root 678732584 2007-07-30 18:38 vbetool.debug.output
<calc> hopefully that log file will have what you need ;)
<calc> mjg59: ping
* calc wonders how well it will compress
<calc> ah 5.9MB
<calc> hmm its not actually done yet
<calc> 7z was faster than bzip2, weird
<calc> mjg59: i replaced the file on my server with the compressed 678MB one
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch!
<StevenK> Morning pitti
<pitti> hey StevenK
<StevenK> pitti: Both libgtkdatabox-0.7.0-0{,-dev} can be NBS'd out. Best of all, I didn't have to do anything.
<pitti> cool :)
<pitti> StevenK: done, merci
<StevenK> pitti: Thanks.
<StevenK> infinity: Ping! I bet you even know what about. :-P
<StevenK> pitti: It looks like most of non-kernel NBS stuff will be dealt with when sear actually gets fixed.
<mjg59> calc: Thanks!
<mjg59> I probably won't have time to look at it until later in the week
<calc> mjg59: ok no problem, there is quite a lot of logging there, heh
<pitti> StevenK: ah, cool, BenC fixed lrm, so it only takes a d-i rebuild now to get rid of the old kernel
<pitti> cjwatson_: -9 kernel is the default now (just NEWed); can we have a d-i rebuild against that?
<Hobbsee> morning pitti
<pitti> hey Hobbsee!
<Hobbsee> :)
<Burgundavia> hey pitti, Hobbsee
* pitti hugs Burgundavia 
<Hobbsee> hiya Burgundavia!
<LaserJock> pitti: do you think you might have time to look at the edubuntu-addon-meta MIR today or tomorrow?
<superm1> hi Hobbsee. sometime back we were chatting about building mythbuntu isos in the datacentre and the discussion moved over to about meta packages.  Do you think the mythbuntu meta packages should be destined directly to universe or to main?
<pitti> LaserJock: yeah, I think so; that should be trivial
<superm1> or do they have to enter into universe and then move to main?
<Hobbsee> superm1: well, any metapackages will need all it's deps in main too
<Hobbsee> exactly
<Hobbsee> with main inclusion reports, etc
<superm1> well there is no way that it can have all its deps moved into main
<superm1> that's for sure
<LaserJock> pitti: I'd really appreciate it if you have time. I know you're a busy man
<Hobbsee> superm1: then it goes to univeres.
<Hobbsee> superm1: but you can use recommends for tha tnow, and they get auto-installed
* infinity sobs quietly as he realises he has to go over all the sources in Required AGAIN...
<superm1> Hobbsee, would you have a few moments to look it over by chance?
<LaserJock> superm1: basically all apps start in Universe and get promoted to Main
<seb128_> re
<Hobbsee> infinity: why?
<Hobbsee> seb128_!
<seb128_> did anybody replied to my question about who uploaded gdm during the night? ;)
<Hobbsee> superm1: look which over, sorry?
<infinity> Hobbsee: https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap?action=diff
<pitti> LaserJock: np; please do keep pinging me about MIRs that block your work
<Hobbsee> seb128_: Changed-By: Mario Limonciello <superm1@ubuntu.com>
<superm1> Hobbsee, the meta package that i've got put together thus far: http://revu.tauware.de/details.py?upid=6251
<pitti> LaserJock: with the multitude of existing MIRs, with many of them being low priority or entirely forgotten about, this is sometimes necessary :)
<infinity> Hobbsee: Just realised that procps didn't include /bin/kill because of that. :(  (doesn't install kill on non-linux systems)
<Hobbsee> seb128_:
<Hobbsee>    * debian/gdm.templates:
<Hobbsee>      - Fix template to point to /usr/sbin/gdm not /usr/bin. (LP: #129017)
<seb128_> Hobbsee: that's I've noticed, but he doesn't have main upload right, does he?
<superm1> No i dont :)
<Hobbsee> seb128_: i'm presuming there was a sponsor involved.
<LaserJock> pitti: ok thanks.
<seb128_> Hobbsee: thanks, but I was able to read the changelog as well ;)
<Hobbsee> seb128_: well, i was wondering :P
<superm1> keescook uploaded it earlier today
<seb128_> Hobbsee: yeah, that's what I'm asking, who uploaded
<superm1> seb128_, was there something wrong with that being done?
<seb128_> superm1: yes, desktop updates should be coordinate with the desktop team
<seb128_> especially when the DesktopTeam TODO wiki page mention that somebody is working on the new version
<superm1> sorry seb128_ .  Was a small fix that appeared to be an oversight
<seb128_> yeah, there is a bunch of them
<seb128_> and I'm going to fix them with the new version upload
<seb128_> no problem, thanks for the work ;)
<superm1> i'll check with you in the future if i catch small things like that first :)
<seb128_> still, we need coordination for desktop uploads
<seb128_> do you know who sponsored your upload?
<seb128_> superm1: no need, the bug and patch were welcome ;)
<Hobbsee> superm1: http://revu.tauware.de/revu1-incoming/mythbuntu-meta-0707301215/mythbuntu-meta-0.1/update.cfg looks incorrect - does that give you ubuntu seeds, or mythbuntu seeds?
<superm1> Hobbsee, it gives mythbuntu seeds overlaid on ubuntu ones
<superm1> ( is my understanding at least )
<Hobbsee> ....er....
<superm1> that's why i ask someone who works with seeds to look :)
<pitti> LaserJock: approved and promoted, thanks
<seb128_> pitti: speaking about MIR, do you plan to look at tracker soon? ;)
<LaserJock> pitti: way cool, thank you very much
<Hobbsee> superm1: right.
<pitti> LaserJock: btw, for simple things like that we don't really need an MIR, but thanks for filing one
<pitti> seb128_: depends on the urgency; what's the plan for it?
<pitti> hi mvo
<seb128_> pitti: getting it on the desktop for next tribe
<LaserJock> pitti: ok, well I was just trying to do it properly ;-)
<infinity> G'morning, mvo.
<Hobbsee> superm1: okay, there are multiple errors in this.
<pitti> seb128: oh, I see
<superm1> Hobbsee, directly in that package, or within the mythbuntu.gutsy seed branch?
<pitti> seb128: will beagle be dropped?
<LaserJock> pitti: do package automatically get moved to Main or does it take a new upload?
<mdke> LaserJock: hi
<Hobbsee> superm1: in that package.  didnt look at the seed branch
<seb128> pitti: beagle has never been on the desktop ;)
<LaserJock> mdke: hi!
<pitti> LaserJock: not automatically, I do that with a soyuz command
<superm1> er Hobbsee do you want to carry this over to #ubuntu-mythtv or #ubuntu-motu to not clutter -devel
<pitti> LaserJock: it'll be in main after next publisher run (in 1:10 hours)
<mdke> LaserJock: digame
<pitti> seb128: right, I meant main
<mvo> hey pitti, infinity
<Hobbsee> superm1: yeah, i was about to say that.  figured i'd check exactly what was wrong first
<seb128> pitti: I don't plan to, no
<pitti> seb128: does tracker have some reasonable g-p-m integration, like stopping grinding the disk when you are on battery and such?
<seb128> pitti: yes
<pitti> goood
<pitti> seb128: *hug*
<seb128> ideally we should have installed it earlier in the cycle
<seb128> but upstream took some time to roll the new 0.6
<seb128> that's why I want to hurry now and get it for next tribe
<seb128> so it can get testing
<LaserJock> cjwatson_: pitti has approved/promoted edubuntu-addon-meta , in a few hours the debian-cd patch I sent should work
<pitti> seb128: ok, looking now
<seb128> pitti: thanks
<pitti> seb128: does tracker use the sqlite3 backend by default?
<pitti> seb128: it also supports qdbm, but I'd rather not have it in main, too
<seb128> pitti: yeah, I think it uses sqlite
<seb128> pitti: you want to build it without qdbm?
<seb128> should be fine
<pitti> seb128: as I said, qdbm is in universe, and I'd rather leave it there
<seb128> works for me
<pitti> seb128: I figure one backend is enough, and sqlite3 is nice and fast
<seb128> right
<pitti> seb128: so it requires a change before we can promote it
<pitti> "Dependencies: all in main"
* pitti hands out a penalty card for lying
<StevenK> pitti: Or worse, not checking ... ?
<seb128> pitti: I think the wiki page has been made before 0.6 which has been uploaded yesterday
<pitti> yeah, possible
<Hobbsee> ooh, penalty cards!
* Hobbsee muhahahaha's
<seb128> pitti: same for libunac1-dev
<Hobbsee> ('bad card, my rule!')
<pitti> seb128: I guess it boils down to removing the b-deps
<seb128> yes
<pitti> seb128: still doing some security review (I just verified all those nasty sprintf() with %s)
<seb128> ok
* StevenK kicks pdftk
* StevenK also kicks ia64 for being so far behind.
<pitti> StevenK: forget about ia64; it's hopelessly out of date
<pitti> StevenK: if there are only rdepends on ia64 I don't hesitate to remove NBS packages
<RAOF> M,tcm.M!
<pitti> seb128: the qdbm backend also has a lot of sprintfs and unchecked mallocs, but I didn't bother to look at them
<pitti> RAOF: bless you
<seb128> ok
<StevenK> pitti: In which case, [17:54]  < seb128> pitti: I think the wiki page has been made before 0.6 which
<StevenK> Blah.
<StevenK> pitti: In which case, you can kill libjasper-1.701-1.
<pitti> \o/
<pitti> StevenK: *flush*
<StevenK> pitti: Yay
* StevenK kicks pdftk harder
<Hobbsee> StevenK: er, why?
<Hobbsee> StevenK: wasnt that in main for a while, too?
<StevenK> Because it doesn't build and I hate it. :-)
<StevenK> And nope, pdftk has always been in universe.
<Hobbsee> no, the libjasper*
<StevenK> Ah
<RAOF> Aww, crap.
* RAOF curses the poor interaction of gnome-screensaver & compiz
<RAOF> Password changing time!
<StevenK> Hobbsee: Yeah. libjasper-1.701-1 is old, and no longer built by the jasper source package.
<Hobbsee> StevenK: ah right.  i thought that was the most recent, for some reason
<pitti> RAOF: ugh, poor you
<pitti> RAOF: file a critical bug
<RAOF> It's already there, I think
<RAOF> But I'll check, after the movie :)
<StevenK> Hobbsee: Ah. Nope, 1.900 is the most recent
<Hobbsee> cool
<Amaranth> RAOF: it's there
<Amaranth> gnome-screensaver doesn't lock the screen in the right way, iirc
<Amaranth> haven't really looked into it much yet
<pitti> seb128: https://wiki.ubuntu.com/MainInclusionReportTracker?action=diff
<seb128> pitti: thanks
* StevenK kicks gcjh
<Greg__> hi where can i get ubuntu keys
<soren> Greg__: Ubuntu keys?
<Greg__> for sources
<soren> I not with you... Keys?
<Greg__> i wanna switch drom debian to ubuntu by changing source list
<Hobbsee> gpg keys, probably
<Hobbsee> Greg__: any reputable keyserver will have the ubuntu ftpmaster public key on it...
<cjwatson_> pitti: sure, I'll do d-i nowish
<pitti> cjwatson_: good morning; thanks
<Greg__> Hobbsee, can you name one?
<Hobbsee> Greg__: keyserver.ubuntu.com, iirc
<cjwatson_> Greg__: it's in the ubuntu-keyring package on archive.ubuntu.com, or which you can extract from CD images
<Hobbsee> ah, neat.   now, if my brain was actually working, i probably would have realised that
<cjwatson_> hmm, I suppose I should sign the archive signing key, in order that an active archive admin has signed it
<cjwatson_> Greg__: (it's 437D05B5, although whether you trust a random person telling you that on IRC is up to you ;-))
<infinity> cjwatson: Have none of us signed it?
<cjwatson> infinity: elmo has
<infinity> Oh, well, that works for me.
<infinity> He may not be an ftpmaster, but he does have root on all the machines, which is good enough for me.
<cjwatson> indeed
<StevenK> infinity: Do you have time now ... ? :-)
<infinity> StevenK: I never have time, but sure, I'll look at it now.
<StevenK> infinity: Thanks
<infinity> It'll be a break from the pain of lpia. :
<infinity> :)
<cjwatson> infinity: well, I've pushed up a signature for it now
<infinity> cjwatson: The sources that you've checked for lpia happiness, have you been paying attention to the GNU_TYPE linux-gnu/linux-gnulp confusion?
<infinity> (I kinda misplaced /bin/kill due to that... *cough*)
<infinity> (procps doesn't install /bin/kill if GNU_TYPE != linux-gnu)
<cjwatson> infinity: I hadn't, but I've rechecked them and they're all good.
<infinity> cjwatson: Good, good.  Thanks.
<cjwatson> infinity: anything I've touched in the last couple of years has got rid of checks for linux-gnu in favour of DEB_*_ARCH_OS=linux anyway
<infinity> cjwatson: Sadly, that doesn't seem to be the case everywhere.
<infinity> (And procps and sysvinit aren't exactly "unused packages")
<alesan> re
<alesan> I am looking for info how to build the isolinux for the livecd
<cjwatson> infinity: a mere 2.5 years or so isn't anywhere near enough for everyone to migrate :P
<alesan> I intend to write out a different menu logo etc...
<cjwatson> alesan: it's been a while, but I generally build them using instructions similar to one of the *README files in debian-installer/build/boot/x86/pics/
<cjwatson> alesan: basically convert to 4-bit bmp then 'bmptoppm < foo.bmp | ppmtolss16 #FFFFFF=7 > foo.rle', although you'd have to look up the appropriate colour to use in place of #FFFFFF - generally the nearest one in the image to white
<alesan> cjwatson, yes I know the issue
<alesan> but do you have an idea how to start from the current splashscreen
<alesan> I do not want to rebuild everything, just modify a menu entry and add a detasil in the logo
<infinity> cjwatson: The problem seems to be that rather than migrating to ARCH_OS, people just worked around the GNU_TYPE changing, by doing icky things like [ "$GNU_TYPE" = "linux" ]  && GNU_TYPE=linux-gnu, and then testing for linux-gnu.
<alesan> where do I find "debian-installer" and so on?
<cjwatson> alesan: apt-get source debian-installer
<cjwatson> alesan: there's an lss16toppm program that should let you convert back to something you can edit
<alesan> cjwatson, I tried to find something like that yesterday night but I gave up
<alesan> I'll see if I'm luckier this morning :)
<cjwatson> infinity: yeah, we did that in Ubuntu for about ten minutes or so before Keybuk pointed out we were wrong, and I wrote a chunk of sample code which ended up in dpkg-architecture(1)
<StevenK> infinity: Any news?
<seb128> ogra: new gnome-screensaver available
<infinity> StevenK: Yes, "doko is distracting".
<StevenK> Heh
<alesan> where the hell can I find lss16toppm
<cjwatson> alesan: syslinux, and keep the frustration down please
<alesan> I'm no frustarted maybe as I am not a native english speaker I didn't measure the "weight" of such expression
<alesan> sorry for that :)
<cjwatson> ok, s/ the hell// then ;-)
<Riddell> pitti: do I remember you had a bash routine to upload to the correct dput location based on version number?
<pitti> Riddell: not on version number, on Distribution: target
<pitti> Riddell: http://people.ubuntu.com/~pitti/scripts/uup FYI
<pitti> Riddell: FTP doesn't work with my ISP, so the script scp's it to chinstrap and dputs it there
<pitti> Riddell: it's trivial to add a grep -v which sets $QUEUE to ppa if version has ~ppa in it, or so
<Riddell> I can adapt it, thanks.  am finding myself dangerously close to uploading ppa packages to ubuntu
<ogra> seb128, tx
<StevenK> pitti: Ewww, you need a better ISP.
<pitti> StevenK: I'd give much for such one
* Keybuk hates ISP shopping
<Keybuk> the quality of service has gone down *so much* since the old days
<pitti> without DSL being available here, my choice is quite limited anyway
<pitti> 'take that one with the crackful and unreliable WLAN and 5 km beam, or leave it'
<ogra> pitti, http://www.teles-skydsl.de/
<pitti> ogra: hm, maybe, yes
<ogra> needs a separate return channel though
<Keybuk> satellite latency is teh suck
<StevenK> Oh yes
<ogra> i was pondering it when we lived in the eifel
<pitti> and the separate return channel would be ISDN, which is both slow and amounts to quite a lot of costs, too
<StevenK> $WORK specialises in two way satellite - the latency is roughly on the order of 1 second.
<ogra> they offer a flatrate if you can proof they cant offer you DSL now
<pitti> StevenK: that sounds next to unusable for ssh...
<ogra> pitti, ^^^
<pitti> ogra: oh? cool
<StevenK> pitti: It takes some getting used to.
<pitti> ogra: (not that I'd actually want to use ISDN permanently...)
<ogra> pitti, well, i would prefer 10 trunced isdn lines over DSL if the price wouldnt matter ;)
<pitti> ogra: I think the better solution is: get fiancee to get a job somewhere, and move to a place with DSL :)
<StevenK> Heh
<StevenK> ogra: Ten D channels? At only 640kbit?
<StevenK> Hell, $WORK has 2Mbit SHDSL
<ogra> StevenK, but symmetric and incredibly reliable ;)
<ogra> i rarely use my 2MBit here
<StevenK> I'm the network admin, and I think that SHDSL service has dropped twice since it's been connected.
<Keybuk> I'm resigned to the fact that after moving I may not be able to find a decent broadband connection, and certainly won't be able to have static IP, etc.
* StevenK is still plotting ADSL2+. Mmmm, 24Mbit/1Mbit
<StevenK> However, like you get anything close to that in reality.
<StevenK> Keybuk: I didn't think the broadband situation in .uk was that bad?
<thom> StevenK: depends on location
<Kano> hi, i am still missing fuse 2.7.0 in ubuntu and none of my bug reports have been processed...
<Keybuk> StevenK: all DSL is BT, with an ISP supplying the IP connection over top
<StevenK> thom: Ah. Much like here, then. :-)
<Keybuk> StevenK: speeds vary depending where you are; and most ISPs have headed down the "download limit" path for their service
<Spads> Keybuk: even LLU?
<Keybuk> Spads: LLU is still BT lines, BT exchanges and BT equipment
<Keybuk> it was a BT engineer who came round last week to fix it
<thom> bt equipment for last mile, yeah
<Ng> it's a BT line, but the equipment it connects to at the exchange is owned by your ISP
<Spads> yeah, that was what I thought
<Spads> the way covad operated in the US
<Keybuk> and LLU is incredibly expensive
<seb128> Kano: hi, we receive load of bugs, it might take some time before somebody looks at yours
<Spads> eh, switching to BT was more expensive for me
<Keybuk> and entirely unavailable outside of major cities
<Spads> they wanted like 145 just to take us off whatever the previous tenants had
<StevenK> Spads: Nice! You didn't make the choice, but you get to reap the benefits.
<Spads> StevenK: yeah, so I stuck with the LLU they had, because it turned out to be a good service
<alesan> cjwatson, it seems the bootlogo in /isolinux in the latest livecd is not in lss16 format
<cjwatson> alesan: of course bootlogo isn't
<Keybuk> Spads: heh; sadly the old trick doesn't work
<cjwatson> alesan: that's not actually a logo (the name sucks a bit), it's an archive of stuff generated by gfxboot-theme-ubuntu
<Keybuk> you used to always be able to force the issue with BT by wiring a 9V battery into the phone socket
<Kano> seb128: updateing fuse cant be that hard... for a beginning
<infinity> StevenK: ADSL2+ reality can be pretty decent if you're close to the CO.  I get about 18/1
<cjwatson> alesan: I didn't know you were talking about /isolinux/bootlogo, or I'd have told you that from the start :)
<alesan> cjwatson, well I guess I'll have to read doc of gfxboot-theme-ubuntu to modify such things right?
<Spads> Keybuk: er, how did that help?
<cjwatson> read the source, anyway ...
<wereHamster> what do I have to choose as type if my package is both a library and has multiple binaries, too?
<Kopfgeldjaeeger> hey. do you have an idea how to delete the last line of a file? sure, i could wc -l ist, show the last line with awk's "if (NR==x)" and then delete it with sed, but that's too dirty
<infinity> StevenK: Of course, then we're connected to the rest of the planet via string and tin cans, so it doesn't really matter.
<alesan> cjwatson, what other logo is there around :) ?
<Keybuk> Spads: put the line on the fritz, so they had to send an engineer out - and since you didn't have a contract with them, they couldn't force you to remove it
<StevenK> infinity: Indeed.
<seb128> Kano: you are free to work on it, attach a debdiff and subscribe the sponsor team if you want to speed it
<pitti> Kopfgeldjaeeger: head -n -1 file > newfile
<Spads> Kopfgeldjaeeger: try head -n -1
<Spads> d'oh
<Spads> too slow
<Kano> why? debian has already fuse 2.7.0. just take it from there...
<seb128> Kano: there is thousand of packages, updating one is not hard but it takes time and people are busy actually
* pitti ^5s Spads 
<StevenK> infinity: Did libnss-db fall off your list again? :-)
<Kopfgeldjaeeger> thank you both.
<cjwatson> alesan: /isolinux/splash.rle (used by syslinux), /isolinux/splash.pcx (used by gfxboot)
<StevenK> Kano: Because we have Ubuntu modifications to fuse.
<seb128> Kano: there is Ubuntu changes to the current version, it needs to be merge or somebody needs to confirm changes can be dropped
<Keybuk> sed -i -e '$d' file
<Keybuk> ^ in-place last-line-delete :p
<pitti> ogra (CC: kano, seb128): do you have some time to give fuse 2.7 a test on your LTSP setup?
<ogra> pitti, later in the evening ... i'm doing some compilcated merges of the new ldm atm
<pitti> ogra: sure, no hurry; I just meant, would you consider updating at this time, or do you want to go with 2.6?
<Kano> ogra: do you have got a howto to transfer audio via network?
<infinity> StevenK: Yes. :(
<pitti> Kano: you want to look at pulseaudio
<infinity> StevenK: Blame doko.  He's a demanding mistress.
<ogra> Kano, no, but feel free to pick my brain :)
<StevenK> Heh
<alesan> cjwatson, let me check
<ogra> Kano, pittis suggestion is a good start :)
<Kano> does it work with kde apps too?
<StevenK> infinity: You know, it's becoming tempting to fly down to Melbourne and stand over you until you look. :-P
* doko whips infinity
<infinity> StevenK: I could use the company.
<StevenK> Heh
<infinity> StevenK: Bring burgers and Coke, kthx.
* StevenK could ask for a week in $WORK's Melbourne office ...
<StevenK> Which would be a proper bitch to get to from anywhere else in Melbourne, the office being in Tullamarine.
<infinity> Eww.
<infinity> Without a car, there's no reasonable way to get to Tulla.
<infinity> And with a car, it still sucks.
<alesan> cjwatson, ok now everything's much clearer
<StevenK> I've done it once, but it was a day trip, and getting from the airport to Tullamarine is trivial.
<alesan> cjwatson, I only have to change those images to use a new bootlogo right?
<StevenK> And then there was the 2.5 hour drive to Bendigo.
<infinity> Well, yes, the airport is *in* Tullamarine.
<cjwatson> alesan: please stop using the word "bootlogo" unless you mean that file
<infinity> You went.. To... Bendigo?
<cjwatson> alesan: it's very confusing
<thom> must be daniels' fault
<infinity> Was Daniel somehow involved?
<StevenK> Certainly not.
<StevenK> It was for $WORK
<infinity> Get a new job.
<cjwatson> alesan: yes, you should only need to change splash.rle and splash.pcx to change the splash screen image
<infinity> Seriously.
<alesan> cjwatson, let's define a term, then
<infinity> Being sent to Bendigo is a fate worse than death.
<cjwatson> alesan: "splash screen image"
<alesan> ok splash screen image
<alesan> agreed
* Fujitsu hasn't found Bendigo overly nasty.
<infinity> Fujitsu: And I suppose you also think "Goon of Fortune" is a perfectly sane and reasonable way to spend a Saturday evening?
<Fujitsu> ... Goon of Fortune?
<Fujitsu> Wow, it's rather more windy than normal here.
<infinity> Bag of goon, rotating clothes line, do the math.
<cjwatson> infinity: can I delete the python-apt lpia failure from my inbox (i.e. is somebody already dealing with it)?
<infinity> Not being from Bendi, I'v eonly ever had the game described to me.
<infinity> cjwatson: We're looking into it.
<Fujitsu> infinity: That sounds a little odd.
<cjwatson> ok
<infinity> cjwatson: Don't know if we're resolving it, but we're pretending to.
<Fujitsu> How much do you have to bootstrap manually before the rest of the world pulls itself together?
<Keybuk> woo, PCLinuxOS is no longer #1 on the DistroWatch 7 days chart
* Fujitsu wonders what's so good about it.
<infinity> Fujitsu: I wouldn't be doing any of it manually, except that we have to review the sources to make sure they won't do Very Strange Things based on our dpkg architecture and GNU triplet.
<Kopfgeldjaeeger> its sabayon... interesting
<infinity> Fujitsu: If it wasn't for that, we'd build a toolchain, throw it all on auto, close our eyes, and scream "LA LA LA, I CAN'T SEE YOU" until it was done.  Ish.
<Fujitsu> infinity: That's what I thought would have happened, so I was quite surprised it was taking so long.
<infinity> Fujitsu: Note the number of source uploads in the last 2 days by me, doko, and kamion.
<cjwatson> (vanishingly few by me)
<infinity> Fujitsu: The potential for breakage here has been... Annoyingly high. :)
<infinity> cjwatson: Enough to count. :)
<cjwatson> that reminds me, openssh sync
<doko> Fujitsu: care to help?
<cjwatson> oh, apparently I did it already
<infinity> cjwatson: Besides, I gave you an out by referring to you as "kamion", had you just kept quiet, no one would be the wiser.
<cjwatson> hah
<Fujitsu> infinity: Why so much breakage? Because it's completely new and not really been done before?
<infinity> Fujitsu: New dpkg arch, new gnu triplet, lots of debian/{rules,control,random-junk} doesn't know how to cope.
<infinity> Fujitsu: As a ferinstance, procps decided it didn't want to install /bin/kill... Which I was a bit nonplussed about, not because I care overly about killing things, but because half the world build-deps on procps specifically because Debian maintainers seem to be incapable of turning off autoconf's /bin/kill test.
<Fujitsu> Hah, rather odd breakage.
* cjwatson fails to find autoconf's /bin/kill test
<cjwatson> I take it it's been removed upstream since then or something
<lore_> hi all
* Fujitsu hides from doko.
<infinity> cjwatson: Oh, I imagine it's a stub test used only by packages looking for a path to the kill binary.  Which still seems to be a fair few.
<infinity> cjwatson: But telling maintainers that you can preseed autoconf variables and don't actually need to build-dep on every single one of your runtime deps doesn't seem to sink in.
<infinity> (tests for ping are another classic example)
<doko> ifeq (,$(DEB_BUILD_GNU_TYPE))
<doko>  include /usr/share/dbs/dpkg-arch.mk
<doko> endif
<lore_> i'm trying to statically link a program, but i get this error "sing 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking"
<doko> \o/
<lore_> and i didn't find any glibc-static package for ubuntu
<infinity> doko: Surely the dbs make snippet won't be too crackful, though...
<doko> infinity: no, look at dpkg-arch.mk ...
<infinity> (exercise to the reader to decide if that was ironic sarcasm)
<doko> ifeq ($(DEB_BUILD_ARCH_OS),)
<doko>   DEB_BUILD_ARCH_OS := $(subst -gnu,,$(DEB_BUILD_GNU_SYSTEM))
<doko>   ifeq ($(DEB_BUILD_ARCH_OS),gnu)
<doko>     DEB_BUILD_ARCH_OS := hurd
<doko>   endif
<doko> endif
<cjwatson> doko: what's wrong with that?
<cjwatson> oh, you'll get linuxlp
<cjwatson> argh
<doko> :-)
* infinity giggles.
<cjwatson> guess who wasn't expecting the existence of linux-gnulp when he wrote that code ...
<infinity> I blame that Kamion fellow.
<cjwatson> so copies of that are probably littered all over the place since they're in dpkg-architecture(1)
<infinity> Wherever's he's gone to.
<cjwatson> $(patsubst -gnu%,,$(DEB_BUILD_GNU_SYSTEM)) # ?
<cjwatson> or for that matter $(DEB_BUILD_GNU_SYSTEM:-gnu%=)
<cjwatson> (test that)
<Kopfgeldjaeeger> cool... pidgin 2.1.0  compiles under daooer :d
<doko> iwj: ^^^ please could you update dpkg-architecture(1) ?
<infinity> More pressingly, it needs updating in Debian, and -devel-announce might even need telling about it... If we can manage to do so without it being an "Ubuntu needs you to fix this bug for an architecture you don't ship" post. :)
<cjwatson> infinity: yeah
<cjwatson> it only actually *matters* if you then test the result against "linux"
<cjwatson> rather than just "not gnu"
<infinity> Which people will surely do.
<Keybuk> Backwards compatibility has so much to answer for
<Keybuk> why do you need that horrendous snippet anyway?
<Keybuk> can't you just test DEB_BUILD_ARCH_OS etc. directly?
* iwj reads scrool.
<infinity> Keybuk: Note that it starts with ifeq ($(DEB_BUILD_ARCH_OS),)
<Keybuk> yes, but why would that ever be "" ?
<infinity> Because it didn't used to exist, did it?
<infinity> So, rather than dealing with "I may or may not be able to query this variable", the above hack was born.
<iwj> Urgh.
<iwj> This is all a bit of a swamp, really.  Is it even written down anywhere ?  I'm sure it wasn't this bad last time I understood it.
<infinity> iwj: It's not so bad, really.
<infinity> iwj: The output of dpkg-architecture is sane and reasonably useful now.
<infinity> iwj: But maintainers use it in hideously evil and broken ways.
<Keybuk> infinity: build-essential depends on the version of dpkg-dev where it's always existed
<infinity> iwj: And our introduction of a triplet ending in "-gnulp" has made it all go south.
<infinity> Keybuk: Yes, but people like their packages to be backportable.
<Keybuk> like I said
<Keybuk> <Keybuk> Backwards compatibility has so much to answer for
<Fujitsu> What was wrong with -gnu?
<infinity> Fujitsu: Because "i686-linux-gnu" would imply a straight i686 rebuild of "i386-linux-gnu", which lpia isn't.
<infinity> Or, rather, it won't be.
<iwj> So err anyway, is someone on the case wrt doko's problem ?
<Fujitsu> Ah, so lpia is just x86 with some extra optimisations or some such?
<infinity> iwj: doko's problem is already solved on doko's laptop, I assume. :)
<infinity> iwj: The dpkg manpage needs updating to not break, though.
<infinity> iwj: And someone might want to politely inform Debianites that this code snippet being littered all over isn't actually quite right.
* iwj reads dpkg-architecture(1).  OMG WTF!
* infinity points at cjwatson.
<cjwatson> at the time, it was extremely common to want to be able to build source packages from unstable on stable where DEB_BUILD_ARCH_OS was not available.
<iwj> Dozen-line cargo cult crack in dpkg-dev!
<cjwatson> and that was about the best option available
<cjwatson> we can probably remove it now
<infinity> It's perhaps saner at this point to remove the backward compat thing completely, now that Debian's had a stable release with the new dpkg...
<cjwatson> indeed. it was better to have cargo cult crack in dpkg-dev than to have everyone get it wrong in subtly different ways
<infinity> I just got it wrong in the "I don't care at all about non-linux ports" way.
<iwj> Um.
<infinity> Which was fine by me.
<infinity> Cause I didn't.
<iwj> What is this, Extreme Programming ?
<iwj> Sorry, I should be less catty.
<infinity> Then you wouldn't be you.
<cjwatson> doko: surely none of this matters, anyway
<cjwatson> doko: on modern dpkg-dev, the variable will be set, and the backward-compatibility snippet won't be used
<doko> hmm, ok
<cjwatson> we should just be able to ignore that entirely and trust to DEB_*_ARCH_OS being set
<infinity> cjwatson: It's only set if someone sets it.
<infinity> cjwatson: If they only ever query GNU_TYPE, because they don't need ARCH_OS (due to the snippet taking care of that for them)....
<cjwatson> infinity: both /usr/share/dbs/dpkg-arch.mk and dpkg-architecture(1) do so
<infinity> Oh, fair point, I was only looking at the second half of the cargo cult in question.
<cjwatson> and if they only query GNU_TYPE, it doesn't matter
<Kopfgeldjaeeger> Could someone please test if this pidgin package works with edgy or feisty? it doesnt create a menu entry, so it must be started via alt+f2 or terminal: http://xeve.de/down/pidgin-2.1.0_i386.deb
<infinity> Err, GNU_SYSTEM, even.
<doko> mvo: any idea about http://launchpadlibrarian.net/8620520/buildlog_ubuntu-gutsy-lpia.python-apt_0.7.2ubuntu3_FAILEDTOBUILD.txt.gz
<cjwatson> if they only query GNU_SYSTEM, it doesn't matter either :)
<infinity> Wait, what was I driving at here?
<Amaranth> doko: odd, it installed python-distutils-extra
<infinity> Oh, right.  That someone could use the second half of that snippet to set DEB_HOST_ARCH_OS, without querying jack.
<mvo> doko: yes, the fix will go in after lunch
<infinity> And then test DEB_HOST_ARCH_OS
<doko> mvo: please before lunch (and before infinity goes to bed ...)
<cjwatson> infinity: I *guess*. Does anybody actually do that?
<infinity> cjwatson: I haven't seen that exact thing, no.  Not yet. :)
<pygi> hello everyone
<infinity> doko: My going to bed isn't the end of the world, I can build things tomorrow. :P
<mvo> doko: I'm sure that it can wait 30 min
<doko> mvo: I didn't know that you eat that quick ;-P
<pygi> mvo, wake up, wake up =)
<cjwatson> infinity: we want libc6-i686 on lpia, right?
<infinity> cjwatson: Why would we?
<cjwatson> infinity: I thought lpia was i686-optimised
<infinity> cjwatson: libc6 itself is i686 optimised.
<cjwatson> ah
<infinity> Which reminds me, we should drop the extra hwcap copies of libssl too.
<cjwatson> wow, I think that means the seeds don't need any changes
<pitti> if that is true, why do we need -686 then?
<infinity> That's just bloat.
<infinity> pitti: On lpia, libc6 is i686 optimised.  We need -686 on i386...
<pitti> infinity: aah
<infinity> Anyone feel like volunteering to hack all the libssl* packages to drop all the << i686 copies of the libraries on lpia?
<cjwatson> doko: any particular reason you put an arch specifier on g++-4.2-multilib in the seeds? it's only built on the listed architectures anyway
<cjwatson> hm, well, I guess it suppresses some germinate warnings
<doko> cjwatson: hmm, no thought that was needed ...
<StevenK> infinity: I'll look at it after I bend pdftk to my will, or give up in disgust.
<doko> cjwatson: I'd like to upload a preliminary ubuntu-meta package supporting lpia. ok?
<StevenK> infinity: Then I can bribe you with that until you look at libnss-db. :-P
<infinity> StevenK: Hah.
<cjwatson> doko: I'll leave the arch specifiers there, thinking about it it's reasonable to suppress the warnings even though it's not strictly needed
<cjwatson> doko: ubuntu-meta> sure
<infinity> StevenK: If you can recall off the top of your head any other libraries that do the hwcap trick, hack 'em all. :)
<StevenK> Not that I can recall.
<StevenK> infinity: Both openssl and openssl097 will need to be touched, or you don't care about openssl097?
<cjwatson> 097's universe, I doubt it matters for lpia
<infinity> StevenK: openssl097's universe, so likely don't care much.
<elmo> (mesa?)
<wereHamster> I have unpacked teh source and created the debian directory inside it. Let's suppose I can now create the deb package. What happens if upstream releases a new version? Do I have to recreate the debian directory again? I can't simply copy it because the files in there have teh version of the old release
<cjwatson> wereHamster: uupdate (in devscripts) is one common method, or just copy it and update any versions necessary
<cjwatson> you shouldn't generally have *lots* of files with hardcoded versions
<Hobbsee> assuming it doesnt fall over, of course.
<alesan> cjwatson, you help has been most welcome
<alesan> thank you very much cjwatson.
<cjwatson> alesan: you're welcome
<Kmos> yesterday someone forgot to do the syncs/backports :-)
<Kmos> Mithrandir: :-(
<mvo> infinity, doko: new python-apt uploaded
<infinity> mvo: Danke.
<doko> \o/
* StevenK waits for pdftk to fail to build again.
<pygi> StevenK, doesn't sound too good?
<StevenK> pygi: It's been failing to build all night - I'm working through the errors
<wereHamster> what's a 'files list file' ?
<mvo> cheers :)
<StevenK> It doesn't help that gcj want to throw a warning on nearly every line into encounters.
<cjwatson> wereHamster: debian/files, usually generated by dpkg-gencontrol (maybe via dh_gencontrol) called from debian/rules
<infinity> StevenK: That's gcj's way of letting you know it cares.   Like that girl you just met who SMSes you every 30 minutes for a week.
<Hobbsee> Kmos: forgot?  more likely were doing more important things.
<Hobbsee> Kmos: have you fixed all the ones of yours that were on crack yet?
<StevenK> infinity: In that case, how do I break up with gcj? :-P
<infinity> StevenK: I've been trying to do that for years...
<Kmos> Hobbsee: yes :)
<pygi> siretart, poke?
<Hobbsee> Kmos: did you subscribe u-u-s to all the unapproved ones?
<Kmos> Hobbsee: I don't touch in that part
<Hobbsee> Kmos: why not?  you're not a MOTU, so you need sponsorship.
<Kmos> Hobbsee: i can't remove ubuntu-archive
<Hobbsee> Kmos: even if they *had* gone and done syncs yesterday, they wouldnt have touched your bugs, as they hadnt fulfilled the requirements.  we discussed this days ago, i'm sure.
<Hobbsee> Kmos: indeed.  but have people gone to every one of your bugs and gone "yes, this is OK" or "no, this is on crack?"
<Kmos> Hobbsee: i think not for all
<Hobbsee> Kmos: the fact that you've gone and subscribed u-a to all of them does not suddenly negate you from needing someone to check all of your bugs, for crack.
<asac> Riddell: ... can you look at lightning-sunbird in source NEW?
<Hobbsee> especially with past history...
<Riddell> asac: yep, will be doing New processing a bit later today
* Hobbsee mvoes to -motu
* asac hugs Riddell 
<asac> Riddell: if you have questions ... ;)
<StevenK> infinity: Test building openssl
<infinity> iwj: Your latest dpkg merge broke dpkg on lpia... I didn't notice until just now because I have an older build on hold in the buildd chroots.
<infinity> iwj: during a debootstrap, I get:
<infinity> dpkg: error processing var/cache/apt/archives/base-files_4.0.0ubuntu3_lpia.deb (--install): package architecture (lpia) does not match system ()
<iwj> infinity: Hrm.
<iwj> I thought I'd caught all of those.
<iwj> What does  dpkg --print-architecture  say ?
<infinity> adconrad@cthulhu:~$ sudo chroot lpia/ dpkg --print-architecture
<infinity> adconrad@cthulhu:~$ sudo chroot lpia/ dpkg --print-installation-architecture
<iwj> Yers, lovely.
<infinity> (Those were blank lines following each)
<ogra> mvo, i see bug 122459 on my thin clients as well now
<ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Incomplete]  https://launchpad.net/bugs/122459
<iwj> Is there a way I can reproduce this to debug it ?  I don't currently have any lpia things.
<Amaranth> mvo: the wrapper doesn't check for LTSP_CLIENT?
<infinity> iwj: sudo debootstrap --variant=buildd --arch lpia gutsy lpia http://ports.ubuntu.com/ubuntu-ports
<ogra> Amaranth, i want compiz where available
<cjwatson> iwj: (you should be able to run that on i386)
<infinity> iwj: Where the second "lpia" in there is the directory.
<Amaranth> ogra: well, that's different
<infinity> iwj: Or just grab the lpia binary and run it on i386.
<ogra> Amaranth, and apparently there is a deeper cause for it ....
<Amaranth> in mountain view i was told we should not even try to start on thin clients
<ogra> Amaranth, in seville you tought us differently ;)
<Amaranth> hehe
<Amaranth> seen dave_largo's blog?
<ogra> so on intel based clients i indeed want compiz
<cjwatson> infinity: you shouldn't need to say ports.u.c explicitly
<ogra> (we dont ship restricted modules, so the others are fiddly anyway)
<cjwatson> new debootstrap works it out
<Amaranth> ogra: that reminds me, what ever happened to the classmate pc?
<mvo> Amaranth: no, currently not
<mvo> ogra: looking
<infinity> cjwatson: Habit.  I always specify the mirror, because it's usually a local one.
<ogra> Amaranth, sitting on my desk
<alesan> cjwatson, actually, the spalsh.rle is not being used in my experiments. still, it's there on the isolinux directory, why? maybe for compatibility with older systems?
<infinity> cjwatson: Well, either a local one, or ftpmaster.internal. :P
<mvo> ogra: can you append the output of lspci to the report please?
<cjwatson> alesan: it's used if gfxboot fails or is disabled (by holding down shift at boot time)
<alesan> I see
<ogra> mvo, trying ... need to get that off the client somehow :)
<alesan> thank you
<StevenK> infinity: The debdiff for openssl looks sane, and it builds fine on i386. Do you want to see the debdiff?
<alesan> cjwatson, what about the next stage of the boot process, when the kernel has been loaded. I guess the "splash screen image" is contained in the initrd.gz file on /casper
<cjwatson> alesan: yes, that's in usplash-theme-ubuntu and built into that initrd.gz
<cjwatson> the initrd's produced by installing all the usual initramfs-ish stuff (initramfs-tools, whatever else is in everything up to ubuntu-desktop) plus casper
<cjwatson> and running update-initramfs -u
<Kmos> latest notification-daemon (0.3.7-1ubuntu2) on gutsy is crashing
<pygi> Kmos, agreed =)
<Amaranth> Kmos: I blame gtk ;)
<Kmos> Amaranth: the debug report shows something about nvidia
<Amaranth> it says you're tainted. probably
<infinity> StevenK: email?  Too many thought processes at once right now.
<iwj> FFS.  I wish this DSL migration would actually happy.
<StevenK> infinity: Oh, and that worked so well for libnss-db. :-P
<iwj> infinity: I didn't see any answer to my last question, I'm afraid.
<iwj> s/happy/happen
<infinity> iwj: You can debootstrap an lpia chroot on i386 with --arch lpia, or you can just unpack the dpkg_lpia.deb and run it on i386.
<infinity> iwj: It's an i686 binary.
<iwj> Right.  But the bug is in the build process of the dpkg_lpia.deb so I need to rebuild it.
<iwj> I thought you said debootstrap didn't work ? :-)
<infinity> iwj: Oh, fair point.
<StevenK> infinity: E-mail sent for what's its worth
<infinity> iwj: chinstrap:~adconrad/chroot-ubuntu-gutsy-lpia.tar.bz2
<iwj> Fabulous.
<infinity> iwj: Should be able to grab that, install build-deps, and play to your heart's content.
<iwj> I'll look at that after lunch.
<iwj> Are you blocked on this ?
<infinity> iwj: Just need to change sources.list to point to ports.u.c/ubuntu-ports.
<infinity> iwj: I'm not blocked on it, the chroots have dpkg on hold.
<iwj> Right, good.
<ogra> mvo, both added
<mvo> ogra: thanks!
<ogra> do you maintain a blacklist ?
<ogra> pitti, ping
<pitti> hi ogra
<ogra> pitti, i heard you hinted mkelfimage into ubuntu ?
<pitti> ogra: yeah
<pitti> ogra: Q-FUNK was proposing that, after talking to you
<ogra> great, do you think there is a chance we can replace mknbi with it ?
<wereHamster> debian directory seems ok, dpkg-buildpackage built the *.deb package, what now? What/how shoudl I submit it?
<ogra> i still have to do some testing, but it seems desirable since it supports LiuxBIOS
<pitti> ogra: that I don't know; I don't have the slightest idea about what either of those programs are
<pitti> ogra: hm, was it FTBFS? it's not in binary NEW
<ogra> create etherboot capable kernel images to serve via tftp
<ogra> i havent looked yet, just got a mail from Q-Funk
<pitti> http://launchpadlibrarian.net/8629441/buildlog_ubuntu-gutsy-i386.mkelfimage_2.7-1_FAILEDTOBUILD.txt.gz
<pitti> ogra: ^ argh, needs --f-no-stack-protector
<pitti> s/--/-/
<ogra> mumble
<pitti> ogra: ltsp-client-core is the only package that needs mknbi (*at all* throughout universe)
<pitti> ogra: so the decision is fully your's
<ogra> yep
<ogra> ah, ok :)
<alesan> cjwatson, I don't find a way to create my own slpash.so image to be included in the initram image
<pitti> StevenK: ah, d-i got built everywhere, time for kernel NBS slaughtery :)
<StevenK> pitti: Yay!
<infinity> pitti: Might want to wait on linux-meta...
<alesan> I read somewhere I should be using a program called pngtobogl but... I'm not sure and it seems it only works with 16 colors images
<pitti> infinity: ? I NEWed it this morning
<infinity> pitti: Oh.  My feed reader is messing with me, I just saw it as new to -changes an hour ago.
<infinity> pitti: Quite right, though, it's been in for ages.  Liferea and I will have a chat later.
<cjwatson> alesan: the usplash-theme-ubuntu source package should help. See the Ubuntu wiki for further details on usplash customisation
<alesan> mh
<alesan> right now I'm testing with 4bit color
<alesan> let's see what happens
<alesan> :)
<cjwatson> usplash images don't need to be at such a constrained bit depth
<cjwatson> again, see the wiki which I think documents this
<cjwatson> search for usplash :)
<wereHamster> does anyone maintain a package for more than one distribution? What's the best way to do it? any suggestions?
<alesan> https://help.ubuntu.com/community/USplashCustomizationHowto
<infinity> wereHamster: Revision control, branches, and lots of merging.
<pitti> wereHamster: I try to keep mine in sync with Debian, and where this is not possible, I have two bzr branches
<alesan> it is updated to edgy, it says there are no such constraints but still, the pngtobogl won't work with such colorful images :)
<pitti> hey BenC
<wereHamster> since nobody wants to make a package for ubuntu, I'll have to do it myself, and a rpm package for redhat/suse would be nice, too (I'm a gentoo user)
<cjwatson> wereHamster: most of the experience people here have is Debian/Ubuntu, not a lot outside the Debianish world
<cjwatson> wereHamster: I think at that point the packaging is usually just completely independent for each distribution
<infinity> wereHamster: Ahh, maintaining a debian directory, a spec file, and an ebuild is a bit more challenging, but yeah, way off-topic here.
<Amaranth> wereHamster: what are you packaging?
<wereHamster> https://bugs.launchpad.net/ubuntu/+bug/117236
<ubotu> Launchpad bug 117236 in Ubuntu "[needs-packaging]  seom" [Wishlist,Confirmed] 
<Amaranth> i should have known :)
<wereHamster> why?
<Amaranth> because that's your project
<wereHamster> ubuntu users usually have less experience with compiling a package (compared to gentoo users) and it's also more complicated in most cases. I'm sich of all teh bug reports '.. it doesn't work on ubuntu' when it's only a configuration issue or missing packages
<wereHamster> also, cross-compiling on ubuntu seems complicated, and a big userbase I'm targetting are those running a 64bit OS and need 32bit versions of my software
<infinity> Building 32-bit binaries on amd64 is simple.
<infinity> (And vice-versa)
<wereHamster> for you, but explain that to someone who doesn't even know what a toolchain is
<BenC> pitti: hey
<Kmos> what's the new address of http://wiki.launchpad.canonical.com
<Kmos> ?
<Kmos> wiki.ubuntu.com ?
<Kmos> https://wiki.ubuntu.com/FeatureSpecifications
<Kmos> that's her
<Kmos> here
<pitti> Kmos: it's for LP-internal development, so you cannot access that anyway
<pitti> Kmos: it's not wiki.u.c.
<Kmos> but the address is wiki.canonical.com
<Kmos> not wiki.launchpad.canonical.com
<Hobbsee> Kmos: you cant address it anyway.
<Hobbsee> sorry, you cant get to it anyway
<Kmos> Hobbsee: i know, but it's on FeatureSpecifications
<Kmos> so fixed it address
<Kmos> :)
<Hobbsee> Kmos: stupid question alert - but how do you know the address you changed it to is correct?
<Kmos> wiki.launchpad.canonical.com resolves for you ?
<Kmos> ** server can't find wiki.launchpad.canonical.com: NXDOMAIN
<Hobbsee> http://www.wiki.launchpad.canonical.com/
<Hobbsee> server not found
<Kmos> pitti: can you clarify this ?
<Hobbsee> but i'm still unsure as to how you think it's appropriate to change something that you have *no* access to, and so therefore have no idea if the content is correct or not
<pitti> wiki.lp.c.c. does not exist any more, it has been renamed (I don't know what to)
<pitti> but it's not really important anyway
<pitti> the reference should just be removed from wiki.u.c.
<Hobbsee> Kmos: also, the people who *do* will not be looking at that page, so the point is moot - ie, it'll 403 whatever link you use
<Kmos> pitti: you've your answer from pitti
<Hobbsee> ...
<Hobbsee> reading before typing is a useful skill!
<Hobbsee> so is before hitting enter!
<Kmos> :)
<Kmos> and click on submit
<Kmos> pitti: so remove the "Write your specification in the wiki" ?
<Kmos> and have only "Register your specification in Launchpad" ?
* Hobbsee bites tongue, fearing that she'll otherwise violate the COC.
<pitti> Kmos: you currently have a wiki lock, so I cannot edit
<pitti> Kmos: please just remove the sentence "There are currently separate wikis for Launchpad [WWW]  here and Ubuntu (you are in it now :-))."
<Kmos> pitti: try it now
<Kmos> ah ok
<Kmos> pitti: done
<pitti> better
* norsetto wonders why in the COC there is nothing about physical abuse.....
<TheMuso> Because it isn't possible? :p
<StevenK> You give up your rights to a physical existance when you sign the CoC, didn't you know?
<Hobbsee> norsetto: for irc, you usually dont need it.  they havent invented stab-people-over-irc
<evand> ...someday
<Hobbsee> evand: yes.  may that day come soon!
* norsetto notices kmos is paleing....
<Hobbsee> norsetto: no, i wont stab kmos today.
<StevenK> ... today
<norsetto> today ....
<Hobbsee> norsetto: probably when he files the next huge lot of bugs which are almost all wrong, and therefore constitutes abuse of launchpad.
* StevenK grins and high fives norsetto 
* norsetto high fives back
<Hobbsee> bear in mind though...today only lasts for 3 more mins...
<Hobbsee> 2
<Kmos> I'm notice..
<Kmos> I will try not to abuse launchpad anymore
* Hobbsee ponders at what point one becomes called out for maliciously damaging, by deliberately not reading and taking in the documentation, not asking, and filing large amounts of bugs which others have to fix for them.  repeatedly.
<Kmos> Hobbsee: I know i'm not welcome
<ogra> Keybuk, bug 126437, what creates that udev entry and can i prevent it in a chroot ?
<ubotu> Launchpad bug 126437 in ltsp "[gutsy-tribe2]  ltsp chroot gets udev rules corresponding to the server's network card" [Undecided,New]  https://launchpad.net/bugs/126437
<Kmos> Hobbsee: don't see to say it every 5 minutes
<Kmos> *need
<Hobbsee> Kmos: on the contrary.  if the bugs are correct, you're very welcome :)
<Keybuk> ogra: the udev postinst
<Hobbsee> Kmos: i hope to see the day when they are
<Keybuk> ogra: (in tribe2 )
<Keybuk> ogra: it's since been fixed
<ogra> Keybuk, only there ?
<ogra> ah
<ogra> cool
<ogra> i'm to solw with my bugs :P
<Kmos> Hobbsee: I try to got better.. yesterday i reported an sync request and it's ok.. junior-games-net
<Hobbsee> Kmos: actually, my last comment was generic - seeing as there are multiple people doing that, just in different ways
<Kmos> Hobbsee: but it affects me, because I know I've done a lot of *shit*
<Kmos> Hobbsee: https://wiki.ubuntu.com/MemoryTest -> check if it's ok for you.. not changed since 2006
<Hobbsee> Kmos: looks fine
<Hobbsee> Kmos: some information on why memory tests are good might be useful, though
<Kmos> nice
<Kmos> Hobbsee: you can edit it :)
<Hobbsee> Kmos: of course i can.  just giving a suggestion
<Kmos> Hobbsee: yep =)
<Kmos> i really don't know what to put there, so I told you to edit
<iwj> infinity: Is this expected ?
<iwj> dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)
<alesan> cjwatson, I am finally able to build my own splash screen even for usplash.
<alesan> anyway, I have to ask: can I use the initrd.gz from a regular system for the livecd? it seems not...
<infinity> iwj: Yeah, we discussed that in London, remember?
<infinity> iwj: It's not fatal, just noisy.
<iwj> I don't remember the details but fine.  I've reproduced your bug btw.
<iwj> That is to say, my bug :-).
<alesan> what is the package that creates the initramfs for the livecd? casper maybe?
<Kmos> Hobbsee: "If your system crashes at random intervals, perform a MemoryTest first before filing any bug reports or support requests"
<Kmos> Hobbsee: how about that ?
<seb128> iwj: any news about consolekit to main? I would like to start building gdm with it
<soren> alesan: livecd-rootfs - construction script for the livecd rootfs
<soren> alesan: Sounds like what you're looking for.
<alesan> soren, well right now I'm stuck at the initramfs
<iwj> seb128: I'm just fixing up a couple of bugs (err, before I got distracted by lpia).
<alesan> I could change the splash image, but if I use my own initramfs from my system on the live cd it won't complete the boot
<iwj> I want to get it all more or less sane before turning it on by default.  Does that sound sensible ?
<alesan> the rootfs should come later
<seb128> iwj: are those bugs bad enough to delay using it?
<iwj> The one where gdm goes `plunkplunk plunkplunk plunkplunk plunkplunk' continuously is :-).
<seb128> iwj: your call, I don't know what the bugs are about, but there are not likely to make the user experience worst than the current one?
<seb128> ah, k
<iwj> Also, I think it will be an easier testing sell to say `it should all be fixed now' rather than `yes there is a bug where if you do X and Y and then X again and then Z then symptom P appears but Q is supposed to be fixed'.
<infinity> iwj: Does "reproduced" mean "found the cause of", or are we not quite there yet? :)
<seb128> no hurry anyway, would just be nice to have it for next tribe
<iwj> infinity: I'm homing in on it.  Fix RSN.
<seb128> right
<iwj> seb128: Oh, absolutely.
<infinity> iwj: Spiff.
<seb128> iwj: ok, thanks for the status update, good luck with it ;)
<iwj> seb128: NP.  I'll keep you posted.
<StevenK> infinity: Any news about openssl?
<iwj> buildd@anarres:~/build/dpkg-1.14.5ubuntu1$ build-tree/src/dpkg --print-architecture
<iwj> lpia
<iwj> Yay.
<cjwatson> alesan: like I said earlier - you can only use the initramfs from a regular system if you have the casper package installed there
<iwj> infinity: dpkg-1.14.5ubuntu2 should fix your bug; currently uploading.
<infinity> iwj: \o/
<infinity> iwj: That's the last piece of the puzzle for a debootstrappable lpia, I think.  We just built the last of required/important/standard, and cprov just fixed an arch:all publishing bug.
<infinity> cjwatson: ^^
<cjwatson> excellent
<Kmos> cjwatson: bug 129432
<ubotu> Launchpad bug 129432 in Ubuntu "warn on LiveCD/installer startup about low screen resolution" [Undecided,New]  https://launchpad.net/bugs/129432
<cjwatson> so after the next-but-one publisher run?
<Kmos> i told him to send a specification
<cjwatson> Kmos: specs are often overkill and don't replace wishlist bugs
<infinity> cjwatson: After "the one after I build dpkg", whenever that is. :)
<Kmos> cjwatson: hmm..
<cjwatson> Kmos: in any case, surely that will be superseded by the displayconfig-gtk work in progress in gutsy
<Kmos> so I can link the blueprint to this bug ? and set it as confirmed ?
<cjwatson> in any case, asking submitters to write specifications is a bad idea
<cjwatson> I wish whatever thing it was that asks bug triagers to do that would just die
<cjwatson> bdmurray: ^--
<Kmos> lol
<Kmos> :)
<Hobbsee> cjwatson: it's listed on !responses
<Hobbsee> !responses
<ubotu> response is https://wiki.ubuntu.com/Bugs/Responses
<cjwatson> Kmos: feel free, it's not an installer matter so it's nothing really to do with me ...
<Hobbsee> A non-trivial feature request
<Hobbsee> For work that needs planning:
<cjwatson> thanks, I'd prefer Brian's signoff before just changing it though
<Hobbsee> cjwatson: seems its' mroe being used incorrectly, rather than being wrong.
<Kmos> cjwatson: i can mark that bug a duplicate of bug 86262 ?
<ubotu> Launchpad bug 86262 in xorg "UI for changing X configuration is rather hidden" [Medium,Confirmed]  https://launchpad.net/bugs/86262
<cjwatson> Kmos: don't ask me
<Hobbsee> cjwatson: email to the bugsquad may be a better option
<Kmos> that has the blueprint of displayconfig-gtk
<cjwatson> Hobbsee: it's very difficult for the bugsquad (or any non-developer) to tell whether a feature request needs planning
<cjwatson> thus that is a foolish criterion to apply
<Hobbsee> cjwatson: good point.  at least an "err on the side of caution"
<Hobbsee> cjwatson: although, i'd imagine that's designed for bugs like "why dont you integrate portage in with dpkg?" or "why cant you make this act more like OSX" or something.
<Hobbsee> doesnt make it used correctly, of course
<cjwatson> Hobbsee: indeed, but in any case a feature specification written by an inexperienced person is unlikely to be a good start
<Hobbsee> this is true.
<Hobbsee> cjwatson: i dont suppose you've got any idea if we've got a spec-duper, or something?
<Hobbsee> cjwatson: the specs are getting almost as bad as bugs.
<cjwatson> spec-duper?
<Hobbsee> something that will let us mark spec A as a dupe of spec B.
<cjwatson> Hobbsee: yes, "superseded by other specification" or something like that
<Hobbsee> oh neat :)
<cjwatson> "Mark superseded", that's it
<Hobbsee> very neat
<Hobbsee> i'll look into that at around the same time i write up the now-implemented kubuntu council spec.
<Hobbsee> or just mark it as done
<bddebian> Heya folks
<Riddell> Hobbsee: kubuntu-council is informational, it doesn't need to be implemented
<Hobbsee> Riddell: even better.
<Hobbsee> Riddell: i thought it had to be marked as "this has been discussed, and does not need rediscussion" or something
<ScottK> pitti: Do you have a moment to discuss your backport of the Gutsy HAL to feisty?
<Hobbsee> night all
<pygi> good night Hobbsee
<mvo> ogra: re bug #122459, what driver is used there (from the clients X)?
<ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Incomplete]  https://launchpad.net/bugs/122459
<ogra> mvo, via and sis
<mvo> ogra: and both explode?
<ogra> mvo, yes, apparently
<mvo> ogra: do you have clients where one of them works?
<mvo> ogra: or does it explode for any client that uses via or sis drivers?
<ogra> on the one i have wih trident card it works
<ogra> no idea
<ogra> i only have one of each
<ogra> i have another via but that doesnt work with the via driver (vesa only)
<mvo> ogra: what driver does the trident card use?
<ogra> i know elkbuntu had probs with her via card during tribe testing
<ogra> trident
<mvo> ogra: yeah, I know that too - we may just blacklist them, especially when they do not survive a glxinfo call
<ogra> let me boot it ... 30 sec
<ogra> right
<ogra> i tested with a bare xterm, glxinfo killed them all
<ogra> but i think the cause lies deeper in X somewhere
<ogra> it didnt crash before
<mvo> ogra: I talk with bryce earlier about a similar problem, the crash happens when vesa is used and glxinfo is run. but I do not think we have a solution yet, so blacklisting may be the only choice
<ogra> that will be a huge blacklist then :/
<kylem> mozilla locked up under vesa for me :/
<ogra> the trident is a CyberBlade/i1 and uses the trident driver
<ogra> and it works properly ... even if i click on desktop-effects it properly shows the note that it cant enable
<doko> StevenK: bad guy, did you see the empty python-sip4-dbg package?
<seb128> doko: $ python-dbg -c 'import gnome-applet'
<seb128> ...
<seb128> ImportError: /usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so: undefined symbol: Py_InitModule4
<seb128> 
<seb128> doko: do you think you could have a look at some point on what is creating that?
<doko> seb128: is python-xml-dbg installed?
<seb128> gnome-applet is shipped with python-gnome-desktop
<seb128> doko: no, thanks
<seb128> ImportError: /usr/lib/python2.5/site-packages/apt_pkg.so: undefined symbol: Py_InitModule4
<seb128> now
<seb128> lacks of Depends
<seb128> doko: thanks ;)
<doko> seb128: np
<doko> seb128: but maybe in another package, which python-gnome-desktop-dbg should depend on?
<seb128> doko: I'm not sure, I doubt python-gnome2-desktop uses apt for example, looking at it
<seb128> Error in sys.excepthook:
<seb128> Traceback (most recent call last):
<seb128>   File "/var/lib/python-support/python2.5/apport_python_hook.py", line 38, in apport_excepthook
<seb128> python-dbg -c 'import gnome' -> "ImportError: /var/lib/python-support/python2.5/gtk-2.0/gnome/_gnome_d.so: undefined symbol: Py_InitModule4"
<seb128> bah, I don't get those python-dbg bugs :/
<infinity> 01:03 < cjwatson> Hobbsee: indeed, but in any case a feature specification written by an  inexperienced person is unlikely to be a good start
<infinity> cjwatson: I read that as "written by an innebriated person"...
<infinity> cjwatson: Which doesn't drastically alter the truth of the statement, I suppose.
<seb128> doko: when you have some time could you have a look at why "python-dbg -c 'import gnome" breaks? dbg packages breakages are blocking some desktop updates and I've no clue of to fix it :/
<doko> seb128: ok, but please remind me tomorrow
<seb128> doko: will do, thanks
<Kmos> there is any possibilitie to backport devscripts from gutsy to feisty ?
<cjwatson> hmm, I've been meaning to update the debootstrap backport
<Kmos> i like to have new requestsync on feisty =)
<Riddell> asac: presumably lightning-sunbird just uses much the same tar as the other mozilla apps?
<siretart> pygi: huh?
<pygi> siretart, you have a tiny minute?
<siretart> what's up?
<pygi> siretart, http://mailman-mail1.python-hosting.com/pipermail/libburn-announcements/2007-July/000018.html
<siretart> pygi: congrats!
<pygi> siretart, thanks!!!
<asac> Riddell: yes
<asac> Riddell: its closest to thunderbird ... all it has more is the calendar/ directory
<pygi> siretart, anyway, sorry for bugging
<siretart> no problem
<pygi> do what you were doing
<siretart> I just came home, I'm reading my mail and will look for something to dinner ;)
<pygi> coming home is good :p
<pygi> I'm tired and sick
<pygi> made three libburnia releases today, and working on preparing fama for release
<pygi> not good =)
<siretart> Get well soon!
<pygi> I will ... I hope :p
<Riddell> asac: there's no mention of anything in other-licences in debian/copyright
<keescook> bryce: I'm making a list of things that I want to force a rebuild of (to make sure they have stack-protector enabled).  I noticed a bunch are older x client apps.  Are there any sync or updates planned for these: http://people.ubuntu.com/~kees/needs-stackprotector-build.txt
* bryce looks
<asac> Riddell: hmm
<Riddell> asac: could you upload a version that documents the licenses which apply to other-licences?
<bryce> iceauth and ico are due for a sync, but all of the others have already received their updates
<asac> Riddell: well ... look at other-licenses/branding/firefox/LICENSE
<asac> Riddell: do you want that in copyright?
<bryce> keescook: I could knock out ico and iceauth today if you'd like to get them uploaded?
<keescook> bryce: ah, cool; they have updates pending?
<bryce> no, but they're just basic x apps that I think shouldn't take more than half an hour to review and process
<Riddell> asac: yep
<Riddell> asac: you don't need every copyright holder in debian/copyright, but in my opinion it should have every licence
<asac> Riddell: ok ... i can do that tomorrow or later tonight ... I will ping you when its ready
<keescook> bryce: er, I guess I meant, "cool, those need version updates?"  Excellent; that makes things easy.  :)
<bryce> yup, that's correct
<Riddell> asac: is the file other-licenses/7zstub/firefox/7zSD.sfx derived from the sources in other-licenses/7zstub/src ?
<asac> most likely
<bryce> both got new releases within the last week and a half, after I'd already passed through that section of the alphabet
<asac> Riddell: i cannot guarantee that they are in sync ... but I think thats the idea
<asac> Riddell: but we have a tracking bug for binary files for all mozilla applications open
<Riddell> asac: that's fine then
<Riddell> asac: yep, all looks fine, just the other-licences stuff needs documented
<wolfe> :)
<wolfe> can't wait for a release with CFS
<wolfe> =] 
<keescook> Mithrandir: FYI, lpia apxs seems broken (and is causing apparmor builds to fail)
<infinity> keescook: I'll fix it when I wake up.
<infinity> keescook: It's already on my TODO.
<keescook> infinity: okay, cool, thanks.
<siretart> Mithrandir: can you please give back gxine on all archs? (all but lpia, where it is in needs build)
<Riddell> siretart: in xine-plugins, is there any source for test.ogg, or is that the preferred modifyable form?
<cjwatson> I wouldn't consider small test files to be a problem
<siretart> xine-plugins? do you mean xine-lib?
<Riddell> siretart: xine-plugin
<siretart> if it has been recorded with e.g. audacity, what would you accept as preferred modifyable form? the uncompressed wav file?
<Riddell> siretart: for which you're the uploader?
<pitti> siretart: given back
<siretart> pitti: thanks
<siretart> Riddell: ah right
<Riddell> siretart: it's a theora video, it could be the preferred modifyable form if you have something that can edit ogg theora files
<siretart> yes, I remember now
* Riddell tsks at his own spelling
<Riddell> siretart: remember which?
<siretart> about the package
* pedro is back (gone 00:53:11)
<Riddell> that's a relief :)
<siretart> I'm checking the upstream VCS, but I don't see any other sources
<siretart> so I'd say it is already in the preferred modifyable form
<Riddell> ok, good with me (especially since it's already gone through Debian)
<siretart> it is just a small testvideo for, well, testing purposes
<geser> is it normal that the mail for NEWly accepted packages mentions 'main' as component instead of universe?
<pitti> geser: no, it's not; maybe Riddell forgot to override it?
<Riddell> geser: yes, that'll be my mistake, I later overrode it while in the accepted queue for xine-plugin and centerim
<geser> ok and thanks
<Kopfgeldjaeeger> using sed, awk or grep/egrep, how to show each line that contains x AND y anywhere? sed -n '/x.*y/p;/y.*x/p' works but is dirty
<pitti> Kopfgeldjaeeger: egrep '(x.*y|y.*x)'  is the shortest thing I can think of, and probably even reasonably efficient
<pitti> Kopfgeldjaeeger: you can drop the (), of course
<Kopfgeldjaeeger> pitti, yeah.. OK. really seems like you can't make it shorter :/... thanks
<stdin> Kopfgeldjaeeger: umm, "grep x | grep y" ?
<pitti> Kopfgeldjaeeger: my initial idea was egrep '(x|y){2}', but that doesn't work
<stdin> not as nice, but works :)
<pitti> stdin: I doubt that this is more efficient, though (two processes and state machines and such)
<Kopfgeldjaeeger> stdin, hehe.. sure. this is used in a script (not mine), but because it is not that nice, im looking for something else :d
<stdin> anyone else realise firefox 2.0.0.6 is out?
<ScottK> Yes.
<stdin> hmm, I only just realised :p
<cjwatson> Kopfgeldjaeeger: sed -n '/x/ { /y/p }' is another option
<keescook> hm, is there a tech board meeting in 40 min?  fridge says yes, wiki doesn't really say...
<tkamppeter> pitti, ping
<Skiessi> Why SDL 1.2.12 hasn't been packaged?
<Kopfgeldjaeeger> and what do you think you should use if you have more keywords? for instance, 5? the pitti-command(tm) would look a bit... strange ;).  cjwatson, could you tell me the syntax of this command?
<pitti> hi tkamppeter
<tkamppeter> pitti, I have uploaded new hal-cups-utils and new s-c-p now. With these ones Plug'n'Print works really well now: HP printers with PostScript PPDs, fax queues, and ...
<tkamppeter> ... Samsung ML-1610 with SpliX.
<pitti> \o/
<pitti> tkamppeter: what determines the priority of printer drivers?
<pitti> tkamppeter: i. e. what makes splix to become the default when it is installed?
<tkamppeter> pitti, /usr/share/system-config-printer/ppds.py
<tkamppeter> pitti, this file contains all the algorithms and rules.
<agoliveira> tkamppeter: tkamppeter, I don't know if this is relevant but my Samsung ML-2010 is no longer recognized on Gutsy. In Feisty works perfectly.
<pitti> oh, erk
<tkamppeter> I have prioritized SpliX now. Se my e-mail with the ChangeLogs.
<tkamppeter> agoliveira, check whether the printer appears in lsusb and in /proc/bus/usb/devices. If it is not there -> kernel
<tkamppeter> pitti, seb128, what is missing now is some GUI improvement: When hal_lpadmin creates a queue, it sends two notifications into the DBUS, one before creating the new queue and one after, the one after with make, model, ... as attributes.
<agoliveira> tkamppeter: Hmmm... something very weird happens. At the first moment, it does show up but one second later the usblp0 module is removed
<tkamppeter> pitti, seb128: Currently, there appears only a magnifying glass on the gnome-cups-icon during the auto-setup. It would be nice to have some bubble at the tray telling "Printer found" in the beginning and "Samsung ML-1610 set up and ready to use" in the end.
<tkamppeter> agoliveira, can you retry after "sudo /etc/init.d/hplip stop; sudo rmmod usblp; sudo modprobe usblp"?
<pitti> tkamppeter: notification-daemon was broken until today, mvo's new upload made it work again today, so maybe it's already working again
<tkamppeter> pitti, running auto-update an that box ...
<agoliveira> tkamppeter: all the same
<tkamppeter> agoliveira, can you look for messages in /var/log/syslog and /var/log/messages? For me it is a problem in kernel, UDEV, and/or HAL (but not hal-cups-utils).
<Riddell> gpocentek: in kitsune, do you know which files make kitsune.icns ?
<tkamppeter> pitti, I had some crashers when playing around with hal_lpadmin ...
<tkamppeter> Any kernel, UDEV, and/or HAL Guru here?
<agoliveira> tkamppeter: I know next to nothing abotu hal but it does show some weird messages after a plug the printer.
<tkamppeter> You should get messages from NetworkManager and from hal_lpadmin. hal_lpadmin DOES NOT load or unload any kernel modules. It only talks with CUPS.
<gpocentek> Riddell: the .pro file on mac I guess
<agoliveira> NetworkManager indeed show some messages like:
<agoliveira> Jul 31 15:38:19 cartman kernel: [22604.652000]  usb 1-1: new full speed USB device using uhci_hcd and address 3
<agoliveira> Jul 31 15:38:19 cartman kernel: [22604.880000]  usb 1-1: configuration #1 chosen from 1 choice
<agoliveira> Jul 31 15:38:19 cartman kernel: [22604.888000]  /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/class/usblp.c:
<agoliveira> usblp0: USB Bidirectional printer dev 3 if 0 alt 0 proto 2 vid 0x04E8 pid 0x326C
<agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.530071]  nm_hal_device_added(): New device added (hal ud
<agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_4e8_326c_3A99BKCL509345N_').
<agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.605333]  nm_hal_device_added(): New device added (hal ud
<agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial').
<agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.626718]  nm_hal_device_added(): New device added (hal ud
<agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_printer_noserial').
<agoliveira> Jul 31 15:38:19 cartman NetworkManager: <debug> [1185907099.632468]  nm_hal_device_added(): New device added (hal ud
<agoliveira> i is '/org/freedesktop/Hal/devices/usb_device_4e8_326c_3A99BKCL509345N__usbraw').
<agoliveira> Jul 31 15:38:57 cartman kernel: [22642.492000]  usb 1-1: USB disconnect, address 3
<agoliveira> Jul 31 15:38:57 cartman kernel: [22642.492000]  /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/class/usblp.c:
<agoliveira> usblp0: removed
<tkamppeter> Seems that you do not have hal-cups-utils installed (installing the package will not fix your problem).
<tkamppeter> Did you unplug or turn off your printer? Both HAL (NetworkManager) and the kernel show messages typical for disconnecting the device.
<tkamppeter> Looks like kernel bug, kernel does disconnecting procedure while device still connected.
<tkamppeter> Or your USB cable is broken.
<agoliveira> tkamppeter: The same setup works perfectly on my macbook running feisty. Looks like a kernel bug indeed.
<tkamppeter> agoliveira, can you report it on Launchpad? Thanks.
<agoliveira> tkamppeter: Sure do.
<tkamppeter> On the Launchpad upstream Ghostscript nug tracker is called gs-afpl-bugzilla (see bug 129389). Can it get renamed into gs-bugzilla, now after the Ghostscript merger?
<ubotu> Launchpad bug 129389 in gs-gpl "[apport]  gs-gpl crashed with SIGSEGV in _IO_vfscanf()" [Medium,Incomplete]  https://launchpad.net/bugs/129389
<geser> doko: is it ok for a package which build-depends on libgcj-dev to set CC=gcc-4.2 in debian/rules to let configure find jni.h?
<doko> geser: sure
<geser> thanks
<tkamppeter> pitti, I have done a second auto-update now and this has pulled the new notification daemon now. I have logged out and looged in again, removed the print queue and replugged the printer. Nothing more than the magnifyier on the screen ...
<pitti> tkamppeter: hm, so it doesn't seem to actually generate notifications
<tkamppeter> pitti, and what does
<tkamppeter>             bus = dbus.SystemBus()
<tkamppeter>             try:
<tkamppeter>                 syslog (LOG_DEBUG, "Calling GetReady")
<tkamppeter>                 obj = bus.get_object("com.redhat.NewPrinterNotification",
<tkamppeter>                                      "/com/redhat/NewPrinterNotification")
<tkamppeter>                 notification = dbus.Interface(obj,
<tkamppeter>                                               "com.redhat.NewPrinterNotification")
<tkamppeter>                 notification.GetReady ()
<tkamppeter> do?
<tkamppeter> and
<tkamppeter>                    notification.NewPrinter (status, self.name,
<tkamppeter>                                              self.make, self.model,
<tkamppeter>                                              self.description,
<tkamppeter>                                              reduce(lambda x, y: x + ',' + y,
<tkamppeter>                                                     self.commandsets))
<tkamppeter> 
<tkamppeter> code is from /usr/lib/hal/scripts/hal_lpadmin, before and after setting up a new print queue.
<pitti> tkamppeter: this seems to be something RedHat specific; I doubt that we have something listening on that
<pitti> tkamppeter: unless it's the default printer status icon
<pitti> ogra: FYI, Martin-Eric fixed mkelfimage FTBFS, I currently sponsor it to Debian now; we can sync it tomorrow
<Kopfgeldjaeeger> how do i check if i have a broadcom 43xx card,? with ndiswrapper drivers installed on feisty it shows: "hardware present", but because that damn card does not work (even after installing firmware with gutsy, on harddisk!) im not sure anymore....
<Windkracht8> Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) from the title
<pitti> Kopfgeldjaeeger: NB that there is a LInux driver for bcm43xx, and gutsy's restricted manager even offers you a three-click firmware installation
<Kopfgeldjaeeger> pitty, youre right. but it doesnt work with this three-click installation (firmware installed, but cannot scan for networks and so, cant set it ip with "ifconfig interface up" (KSICOsomething error)...
<Kopfgeldjaeeger> s/it ip/it up/g
<pitti> hm
<pitti> Kopfgeldjaeeger: it does for me for my Airport Extreme card
<Chipzz> Kopfgeldjaeeger: how do i check if i have a broadcom 43xx card,? >> lspci ?
<pitti> Chipzz: that'd work
<tkamppeter> pitti, the magnifying glass is showing up exactly when the stup of the new queue begins and it disappears when the new queue is ready. No magnifier if now queue is needed and only enabling and disabling of queues is done. So it seems the code shown above triggers the magnifier.
<Kopfgeldjaeeger> lspci shows "Dell 13somewhat Broadcom somewhat card"
<Kopfgeldjaeeger> and its not a dell ;)
<Kopfgeldjaeeger> Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01), a suse wiki entry says
<pitti> finally! this damn apport thing works again, now better than ever
* pitti uploads and calls it a day, cu tomorrow
<Kopfgeldjaeeger> lets say, i have a new gutsy (no driver with restricted mngr) and installed ndiswrapper, installed the bcmwl5 driver into ndiswrapper, executed "ndiswrapper -m" - and a open wlan network. what to do now? 2 seconds ago i did "ndiswrapper -m". no reboot at the moment.
* norsetto waves pitti goodvye
<pygi> laters pitti, good work =)
<Kopfgeldjaeeger> how can i set a link from a device to the other? like "ln -s" does with files.. is this possible? typing "wlan0" and "speaking" with interface eth3 for instance?
<keescook> Keybuk: seems the fixes we worked on in london don't fix my lvm-on-md boot issues.  :(  lvm is started, but nothing seems to notice.
<sivang> does anyone know if jbailey is at a conference or afk lately ?
<pygi> hey sivang
<sivang> hey dude
<pygi> sivang, pm
<munckfish> asac: got a minute?
<asac> well :/
<asac> munckfish: whats up?
<munckfish> Regarding ...
<munckfish> LP bug ... sorry one sec
<munckfish> LP #125662
<ubotu> Launchpad bug 125662 in network-manager "Loss of DNS shortly after startup because /etc/init.d/networks isn't ignoring interfaces marked as roaming" [Medium,Triaged]  https://launchpad.net/bugs/125662
<munckfish> I have managed to recreate the problem on Gutsy herd 3
* asac reading
<munckfish> are you aware if a lot has changed in nm / ifupdown since then?
<munckfish> ok np
<munckfish> take your time
<asac> munckfish: can you please summarize?
<munckfish> sure
<munckfish> long bug desc - I know
<munckfish> DNS gets lost when
<munckfish> a dhclient process that has been run for the IF I'm not using
<munckfish> finally times out
<munckfish> it then picks up on an old but not yet invalid lease
<munckfish> but this lease is for a network I'm not on
<munckfish> so it pulls in the DNS server entries
<munckfish> and splats them into
<munckfish> resolv.conf
<munckfish> causing me to lose DNS
<munckfish> you up to speed or shall on cont.?
<ion_> It wasnt that long, only one or two lines worth. Of course, splitting something arbitrarily to ten lines makes it long. :-)
<asac> munckfish: so what is the real problem?
<asac> munckfish: why is that network-manager fault?
<munckfish> well,
<munckfish> I'm not sure it's nm's fault now
<munckfish> I was advised to stick on NM because this was something that affected desktop operation rather than server
<munckfish> anyway I'm beginning to think it's a problem with ifupdown
<munckfish> I'm just not sure how development is coordinated
<munckfish> between all these interrelated packages
<munckfish> should I reassign it under ifupdown?
<asac> so why does dhclient time out in the first place?
<munckfish> not sure
<munckfish> I looked up the docs and found the dhclient-script page desc best
<munckfish> TIMEOUT occurs when it can't reach a dhcp server
<munckfish> but an existing lease is available
<munckfish> because the interface is not being used of course it can't reach dhcp
<asac> munckfish: is that a regression?
<asac> munckfish: nevermind ... reporter says that its been since feisty
<munckfish> well, I moved from Dapper to Feisty
<munckfish> wasn't in Dapper
<asac> munckfish: ok ... for me it sounds like this issue is fixed in gutsy
<munckfish> really?
<munckfish> ok
<asac> now network-manager will not restart interfaces upped by ifup
<munckfish> what in particular has changed?
<asac> i am not 100% if it fixes this issue ... but sounds like it might help
<munckfish> hmmm, well, I managed to get the same behaviour today with herd 3
<munckfish> but because I can't install to my hd
<munckfish> I have to fake things a little
<asac> herd?
<munckfish> sorry
<munckfish> tribe :S
<asac> i still don't understand what the bug is
<asac> i mean ... when dhclient times out ... what should be done instead?
<munckfish> ok
<munckfish> well it seems to me that dhclient (started by ifupdown / networks init script)
<munckfish> should not be run on that interface
<munckfish> because it is supposed to be marked as
<munckfish> roaming
<munckfish> and therefore only NM should be looking after that
<johanbr> The new nm/ifupdown changes seem pretty buggy generally to me. Hopefully there's still time to iron out the bugs.
<munckfish> is there a slim chance this is a bug in the config parsing code in ifupdown?
<munckfish> should ifupdown really be considering interfaces if they are marked as roaming?
<munckfish> well anyway, I'm happy to keep picking at this until I understand it, and I'd love to be able to submit a patch to fix it
<johanbr> It used to be that it (ifupdown) didn't. I'm not sure if this new behaviour is intentional.
<munckfish> I guess the most useful thing for me would be to know what is driving the integration of these components right now, e.g. a particular blueprint
<johanbr> munckfish: Have you looked at the changelog for network-manager 0.6.5-0ubuntu7 ? There are some comments there that look relevant.
<munckfish> ok I'll take a look
<munckfish> btw, if I'm on feisty, what's the quickest way to get a source package for gutys? at the moment I'm looking for the .dsc on archive.ubuntu.com and dget-ing it from there
<ScottK> munckfish: I just set my deb-src lines to gutsy since I almost never want Feisty source anymore.
<munckfish> ScottK: ok I'll try that
<munckfish> thx
<ScottK> Don't for get apt-get update after you change it.
<asac> munckfish: how exactly are they marked for roaming?
#ubuntu-devel 2007-08-01
<munckfish> asac: I don't know in terms of /etc/networks/interfaces but that's what they're marked as in  the gnome network tool
<munckfish> by being marked as 'auto' I guess
<munckfish> I'm trying to look at the ifupdown source
<munckfish> noweb is blocking me at the moment ...
<asac> munckfish: its still intended
<munckfish> asac: what do you mean?
<asac> personally i would prefer to not use network manager for all auto marked interface entry
<asac> e.g. the other way around
<asac> munckfish: try to comment every interface you want to use with network manager out in /etc/network/interfaces
<asac> munckfish: let me know if that brings you a more "as-expected" behaviour
<munckfish> asac: I've already done that
<munckfish> doing that makes the problem go away
<munckfish> cause then ifupdown is not run on it by the networking init script
<asac> please ensure that you really see the problem
<asac> in gutsy
<asac> I still think that it should be fixed
<munckfish> ok, I'll repeat my test
<munckfish> although I'm limited by not being in a position to install gutsy on the hd yet
<munckfish> ok asac (and others) thx for you time
<munckfish> your time
<Keybuk> keescook: ok, interesting, we'll debug further tomorrow if you like
<keescook> tepsipakki: say, can you take a look at xscreensaver?  Looks like debian went to version 5 just recently.
<shaya> anyone know if the gtk2.0 issue in openoffice, acroread... was fixed?
<keescook> shaya: which issue do you mean?
<shaya> that they crash on startup :)
<ScottK> I'm still having the problem.
<ScottK> IIRC it turned out not to be gtk2.0
<ScottK> calc is getting close to uploading OOO 2.3 and it's fixed there.
<calc> ScottK: yea, working as fast as i can :\
<calc> ScottK: it appears gcj is still broken on using all available memory which is slowing me down a bit
<J-Unit> it's not supposed to do that?
* ScottK waits and stares and calc to see if it'll make him work faster.
<J-Unit> must not be using it right then :)
<calc> J-Unit: heh no its not supposed to use all ram, heh
<J-Unit> funny... I've always been under that impression
<J-Unit> and it trips PaX too
<J-Unit> grr
<calc> i'm not talking about openoffice here, gcj while compiling uses up all ram and dies
<calc> i think its normal for openoffice to use huge amounts of ram :(
<Skiessi> can someone put a bookmarks or favourites -menu to x-chat?
<Skiessi> *make
<coNP> Skiessi: what kind of bookmarks do you mean? For channels?
<Skiessi> yeah
<cheeseboy> any of you ever install ubuntu from pendrive?
<ScottK> cheeseboy: I think you want #ubuntu
<cheeseboy> ScottK no one has figured u guys might know more
<ScottK> It's OT for this channel.  Google is your friend.
<cheeseboy> i have googled
<cheeseboy> :(
<ScottK> Hang on, I'll point you.
<ScottK> cheeseboy: http://forums.hardwareguys.com/ikonboard.cgi?act=ST;f=12;t=5353
<ScottK> The people there are very nice if you have questions too.
<bryce> keescook: btw, you were asking about iceauth and ico earlier today - I've just posted them to http://people.ubuntu.com/~bryce/Uploads/.  Would you like to push uploads of them?
<keescook> bryce: sure thing, thanks.
<keescook> bryce: which ico do i want?
<bryce> keescook: btw, fyi, going forward (maybe Gutsy, but definitely Gutsy+1) pretty much all the x apps are going to get dropped in favor of using Debian-X's x11-apps and x11-utils combo packages.  So if there are things to be patched in these packages, we'll also want to push them into those packages
<keescook> bryce: noted. I just wanted them rebuilt, is all.  :)
<bryce> oops, should be clarified now
<bryce> (1.0.2-0ubuntu1 is what we want)
<StevenK> doko: Hrm. I missed that, sorry.
<StevenK> doko: Do you need me to fix it?
<keescook> bryce: rockin'.  they're uploaded now; thanks!
<bryce> kewl, thanks :-)
<doko> StevenK: no, updated. but that's a bad miss.
<StevenK> doko: Indeed. :-(
<StevenK> doko: Consider me suitably chastised.
<Chipzz> bryce: too bad :S
<Chipzz> I actually liked the split X apps
<bryce> Chipzz: yeah me too, but the added overhead of maintaining them separately doesn't seem to be worth it
<Chipzz> bryce: added overhead? they're seperate modules in X cvs... putting them together, *that* is overhead...
<bryce> no, the ubuntu overhead over debian
<Chipzz> or do you mean seperate from debian?
<bryce> going with the debian combos will let us mostly auto-sync from Debian, whereas the split out packages would require me to continually to personally download and merge them
<bryce> I don't mind, and they go pretty quick, but it is time I could put to better use working on bugs or something
<Chipzz> looks like trivial packaging to me?
<bryce> yup
<bryce> but even at 15 min each, when you add it up for all of the apps, it makes for a non-trivial amount of time
<Chipzz> and you're pulling in a dependency on libxaw just because some of them still use it, and you want some other util that doesn't
<Chipzz> what's with that toolkit anyway? :P
<bryce> luv athena mmm
<Chipzz> ? :)
<Chipzz> the thing is so ugly ven its own mother couldn't possibly love it :P
<bryce> the point that sold me is that apparently fedora uses this same packaging model
<bryce> so how can one argue against consistency?  ;-)
<ScottK> bryce: http://www.brainyquote.com/quotes/quotes/r/ralphwaldo136909.html
<bryce> ScottK, but I like hobgoblins.  :-)
<ScottK> OK, well you asked who.  That's one person.
<bryce> very true.  Of course he ended up in jail, though.
<ScottK> You say that like it's bad or something.
<jono> http://www.jonobacon.org/?p=1008
<calc> yuck
<calc> i have 963 line diff to merge still
<pitti> Good morning
<pitwalker> Good morning from Hungary.
<Mithrandir> keescook: apparmor needs apxs to build?
<Tonio_> pitti: hey
<pitti> hi Tonio_
<Tonio_> pitti: I was thinking about hidd support in bluez
<Tonio_> pitti: is there any reason it isn't enabled by default ?
<Tonio_> pitti: that makes it very complicated to connect a bluetooth mouse for example
* pitti makes a clueless face
<Hobbsee> gutten morgen Tonio_, pitti
<pitti> Hobbsee! Wie gehts?
<Hobbsee> pitti: but you're supposed to know everything!
<StevenK> Oh, I love where NBS stuff leads me.
<Tonio_> bonjour demoiselle Hobbsee
<Hobbsee> pitti: gut, danke :)
<pitti> Tonio_: "ma"demoiselle?
<Tonio_> pitti: you can say both
<Tonio_> you even can say dAmoiselle
<pitti> Je ne parlez pas francais :(
<Tonio_> pitti: hehe
<pitti> StevenK: trouble?
<Tonio_> pitti: so to make it clear, enabling hidd support doesn't change anything for the initial connection, but makes it possible to autoreconnect the device automatically
<Tonio_> pitti: so that you just have to connect it once and it'll work forever
<Tonio_> pitti: I think that should be enabled by default
<pitti> Tonio_: sure
<StevenK> sdcc build deps on two old lyx packages, but the new lyx SEGVs when building the docs for sdcc.
<pitti> Tonio_: is that a new system daemon?
<Tonio_> pitti: oki, I'll fix the bluez-utils packaging then
<Tonio_> pitti: no it is there for years :)
<Tonio_> pitti: hidd is to manage connection of bluetooth control periphericals, like mice and keyboards
<pitti> Tonio_: I mean, will this change cause a new systme daemon to run? or is it only in the user's session?
<Tonio_> pitti: hum, lemme check
<Tonio_> pitti: yep, hidd will then run
<StevenK> pitti: Not sure, at this point I'm trying to figure out if upstream has fixed it.
<Mithrandir> Tonio_: if you're touching bluez-utils, please also merge with Debian and put in the new upstream version, or wait until I've done so.
* Hobbsee stomps on Mithrandir's feet in greeting
* Hobbsee looks around innocently
* Mithrandir tickles Hobbsee and throws her in the pool
<Hobbsee> hey!
<Mithrandir> :-D
* Hobbsee drowns
<Tonio_> Mithrandir: I've packaged latest upstream release yesterday
<Tonio_> Mithrandir: I was waiting for dholbach to let him give his opinion
<Mithrandir> did you merge with Debian too?
<Tonio_> Mithrandir: I also wanted to sync with debian as there are significant changes required for the new kdebluetooth to work
<Tonio_> Mithrandir: not yet, but I expect to
<Hobbsee> oh wait.  it's summer there.  i wouldnt drown.
* Hobbsee pulls Mithrandir in as well, then.
<Mithrandir> Hobbsee: "summer".
<Hobbsee> Mithrandir: yeah, well.  nothing like au summer
<Tonio_> Mithrandir: btw lots of things need to be changed in the debian packaging to work against dbus bluetooth interface....
<Tonio_> Mithrandir: that's why I first packaged on my own to make it to work
<Tonio_> Mithrandir: is dholbach in vacation ?
<Mithrandir> yes, he's on vacation
<Hobbsee> Tonio_: yes
<Mithrandir> what are you suggesting needs changing?
<Mithrandir> most of it just worked fine for me.
<Tonio_> Mithrandir: enabling input and serial build options
<Tonio_> Mithrandir: otherwise you will not output the .service files required by kdebluetooth
<Tonio_> Mithrandir: also the horrible patching to make it to work with the current kdebluetooth is now gone, which is a good point
<Mithrandir> the pin mangling, you mean?
<Mithrandir> that's good
<Tonio_> Mithrandir: yep
<Tonio_> Mithrandir: http://paste.tonio.homelinux.org/375
<Tonio_> Mithrandir: here is the changelog
<Mithrandir> I wouldn't call adding two flags to configure "a lot of changes". :-P
<Tonio_> hum, true, that's not a "that big" change :)
<Tonio_> Mithrandir: consider I just woke up ;)
* Tonio_ goes taking a coffee
<Mithrandir> sure, so did I. ;-)
<Tonio_> Mithrandir: would you agree on rationale ?
<Mithrandir> anyway, if you don't mind, I'll just grab what you have into my not-yet-uploaded merge and upload that
<Tonio_> Mithrandir: I'm unsure concerning the hidd enabled by default, but I think that's important for a friendly desktop approach
<Mithrandir> sure, making kbluetooth work is a worthy goal.  I don't use kde myself, so you'll have to make sure the K end of the world looks right.
<Tonio_> Mithrandir: sure
<Tonio_> Mithrandir: you can get the source packages there : http://ubuntu.tonio.homelinux.org
<Mithrandir> what's the reason for not enabling hidd by default?
<Tonio_> Mithrandir: dunno, that's why I changed that in the config file :)
<Tonio_> Mithrandir: the only difference is that an already manually connected device will auto-reconnect.....
<Tonio_> Mithrandir: the reason can be that is causes another daemon to run...
<Tonio_> Mithrandir: source dir (might be easier for you) http://ubuntu.tonio.homelinux.org/dists/gutsy/main/source/
<Tonio_> except bluez-utils, other packages don't have any change in it, I just sync with upstream version and that's it
<Mithrandir> the joy of doing four-way merges without revision control. :-/
<Mithrandir> (base, ubuntu, your, mine, debian).  Five-way.
<Tonio_> Mithrandir: yeah I know that's what we try to avoid for kde packages at least.....
<pitti> jamesh: thanks for your 'bzr bundles' intro on planet; this is amazing
<jamesh> pitti: Bazaar has all kinds of cool features
<infinity> jamesh: The biggest revelation there to me was the "lp:project" shorthand.  I didn't know about that.
<jamesh> infinity: there are a number of useful features in Bazaar's launchpad plugin (hopefully we'll get more in future)
<infinity> jamesh: I'm going to assume that lp:foo uses http...?  Is there a shorthand for bzr+ssh or sftp, so I can actually co and ci? :)
<jamesh> infinity: not at present.
<infinity> jamesh: Ahh, then it just became useless to me again.  Still, cool feature. :)
<jamesh> infinity: it basically just converts lp:foo to "https://launchpad.net/foo", which pretends to be a Bazaar branch reference
<infinity> (Easy come, easy go)
<jamesh> see e.g. https://launchpad.net/upstart/.bzr/branch/location
<jamesh> we could probably change that in the future
<infinity> jamesh: Hey, speaking of URL shortcutting, who should I whine to about "bugs.lp.net/12345" no longer redirecting to bug numbers (I'm sure it used to, way back when...)
<jamesh> since you can use bzr+ssh://bazaar.launchpad.net/... to access all branches now -- not just ones you can write to
<pitti> jamesh: same for me, lp:foo was new; however, how does that select a particular branch?
<infinity> Oh, wait, it's lp.net/bugs/12345 that redirects, and it still does.  It just never got implemented at the root level of the shiny new subdomain.
<jamesh> infinity: I don't think it ever did that.  maybe you were thinking of lp.net/bugs/NNNN?
<pitti> jamesh: I tried lp:apport, and that seems to select the 'ubuntu' branch; how to select e. g. the 'feisty' one?
<jamesh> pitti: each project has a "development focus" release series, and each series can have a branch associated with it
<infinity> jamesh: Yeah.  When the subdomain happened, I think my brain just assumed the redirect-fu would keep working intuitively.  I was obviously wrong. :)
<jamesh> pitti: so the "project's branch" is the "project's development focus's branch"
<pitti> jamesh: aha; that's the first branch ever created? or can that be configured somehow?
<jamesh> pitti: you can pick which release series is the development focus on the project's "change details" form, and you can change the series' branch on the series' "change details" form./
<jamesh> pitti: by default release series don't have a branch set
<pitti> ah, thanks a lot
<Gasten> If there is a problem with planet.ubuntu.com, who should I talk too?
<pitti> Mithrandir, infinity: any idea why apache2 does that:         dh_strip -a --dbg-package=apache2-dbg -Napache2-mpm-worker -Napache2-mpm-event -Napache2-mpm-prefork -Napache2-dbg
<Mithrandir> pitti: unsure.
<infinity> pitti: It strips the MPM packages elsewhere.
<infinity> pitti: It's a bit special, because it installs three sets of symbols for /usr/sbin/apache2 to apache2-dbg, which requires some sketchy trickery.
<pitti> ah; I just spotted it while debugging the current FTBFS with pkg-create-dbgsym
<infinity> pitti: (Note: I had nothing to do with this, I just knew it was being done and I'm looking at it in SVN right now and marvelling at the bizarre implementation thereof)
<infinity> pitti: Given that we have the whole dbgsym thing, it might just be less effort to change the Ubuntu build to not do the apache2-dbg thing...
<infinity> pitti: If it's causing you serious grief.
<pitti> infinity: depends; I actually want to make pkg-create-dbgsym more robust against such things
<infinity> pitti: debian/rules already special-cases "`lsb_release -i -s`" = "Ubuntu" elsewheere anyway.
<pitti> we had similar problems with that in the past, so I have an idea how to fix that once and for all
<infinity> pitti: Well, if you're viewing it as a challenge, by all means, fix your scripts. :)
<pitti> oooh, I see
<pitti> infinity: so it manually calls objcopy --add-gnu-debuglink after calling dh_strip
<pitti> now, that's doomed to fail
<pitti> there's no way how p-c-d can anticipate that and not already do it on its own
<infinity> Heh.
<infinity> I'll just drop the debug package on Ubuntu then. :)
<infinity> Seems like less headache.
<pitti> infinity: yeah
<pitti> infinity: if only debian/control would support #if lsb_release... :-)
<infinity> I'd do it with a Distribution: header.
<pitti> infinity: so I guess we actually have to keep an Ubuntu modification
<infinity> (I should file a bug about that)
<pitti> wow, that works?
<infinity> No, I mean, "if I were writing the feature".
<pitti> ah
<infinity> But, there's no law against having stuff in debian/control and not building the packages. :P
<infinity> I'll make it work.
<pitti> so, shall I change apache2 here? or do you insist doing it yourself?
<pitti> infinity: dh_* -a will copy stuff to it, such as the changelog, right?
<infinity> You can mangle it if you like, but I do insist on having it upstream eventually, because I've put enough effort into making Debian and Ubuntu not fork apache2 at this point, I don't want that to go to waste. :)
<pitti> infinity: oh, sure; muchly appreciated :)
<infinity> Yeah, dh_* will create a package directory.  Not hard to undo that.  Ugly, but not hard.
<infinity> Pretty much just rm -rf debian/apache2-dbg right before the dh_builddeb call should do it. :P
<infinity> (Yay, hammer)
<infinity> (And, of course, case out all the hackery above that, and case the dh_strip call to actually strip stuff on Ubuntu)
<infinity> So... 4 or 5 line diff, tops.
<pitti> ok, I'll try to come up with something
<infinity> After having explaied it, I can do it in about 20 seconds.
<infinity> Shall I?
<infinity> (IRC: The Ultimate Software Specification Tool)
* pitti tests his change
<pitti> infinity: sure, let's race :)
<infinity> Hye, no fair, I was waiting for you to say "go". :P
* pitti fetches a new glass of water then
<infinity> pitti: The shortest debdiff (obviously it should be cleaner and not run lsb_release 30 times in the build) that illustrates the point is: http://cerberus.0c3.net/~adconrad/apache2-mangle.diff
<infinity> pitti: It may even work. :P
<pitti> infinity: with s/if if/if/, it might :-)
<infinity> Close enough. :P
<pitti> infinity: yep, my current version looks much similar
<infinity> dh_builddeb may also need a -napache2-dbg
<infinity> Hard to say without testing.
<pitti> currently building the third time
<infinity> -N even.
<pitti> my previous attempt complained about the missing dir, so I guess -N is necessary
<infinity> Right, well if the general theory works and it seems to produce correct binaries (and fix your issues), I'll commit it to the Debian SVN so it doesn't get lost.
<pitti> dpkg-deb: Konnte Paket-Infodatei debian/apache2-dbg/DEBIAN/control nicht zum Lesen ffnen: No such file or directory
<pitti> bah
<pitti> ok, -N this time
<infinity> Serves you right for being German.
<StevenK> infinity: libnss-db. Or openssl. Take your pick. :-P
<pitti> infinity: your favourite bitching Steve is back :-P
<StevenK> Awww
<pitti> infinity: it ... built!
<infinity> pitti: That's a start.
<pitti> infinity: http://people.ubuntu.com/~pitti/tmp/apache2.FTBFS.debdiff
<infinity> pitti: That looks awfully familiar. ;)
<infinity> pitti: I'm going to turn the lsb_release call into a variable assignment in debian/rules to make that less ugly, but I'll commit pretty much exactly that change upstream.
<infinity> pitti: Feel free to upload that to Ubuntu, though.  Looks sane.
<infinity> Well, "sane".
<pitti> infinity: thanks
<pitti> well, looks hackish, but makes it build at last
<infinity> That entire rules file looks hackish, what's one more?
<pitti> infinity: ok, if you don't want to upload that to Debian soonish, I'll do the Maintainer: stuff and upload
<infinity> pitti: Well, an upload to Debian just for an Ubuntu change is a bit sketchy, and I don't have the time to fix any other bugs right now to justify an upload. :)
<pitti> right
<infinity> pitti: Given that it's a "backport" from Debian SVN, though, I don't know if the Maintainer change is justified. :)
<infinity> pitti: (I'm a bit fuzzy on that, really)
<Fujitsu> Can't you convince Debian that picking up lpia would be a Good Thing?
<pitti> infinity: we'll sync it again on next opportunity anyway *shrug*
<infinity> Fujitsu: What motivation would they have to build lpia?
<Fujitsu> They seem to build a lot of other obscure architectures.
<infinity> Fujitsu: It's not so much an arch as a platform.
<infinity> Fujitsu: We'll be hacking source packages to do different things on lpia, etc.
<infinity> Fujitsu: Our version of that platform will actually get used (hence the motivation), them mirroring those changes and that platform would likely be pointless.
<Fujitsu> True, true.
<infinity> Building for as many CPU arches as possible is wickedly cool (and something I hope Debian never stops doing), but building 15 versions of x86 is kinda pointless unless you have a target audience for it.
<infinity> pitti: Hrm, actually, there is a pending upload with one change...
<Mithrandir> their motivation would be "less delta to Ubuntu"
<Fujitsu> Isn't that just motivation to complain about us, rather than merge from us?
* cjwatson views it as an excuse to merge the relevant patches in Debian where he has commit access
<cjwatson> (hey, Debian dpkg supports it ...)
<oni_> re
<asac> Riddell: look in NEW please :)
<Riddell> asac: looking
<asac> Riddell:    * debian/copyright: add info about other-licenses/branding
<Riddell> asac: meh, it still misses the other parts of other-licences
<asac> he?
<Riddell> the 7zstub   bsdiff  libart_lgpl directories all come under other licences which I don't think are mentioned in the debian/copyright
<Riddell> especially that "BSD Protection License" is weird and non standard
<Riddell> asac: could I ask you to upload again with debian/copyright pointing to the (L)GPL used for those directories and a full copy of that "BSD Protection License"
<pitti> mvo_: the current notification bubbles look very dark gray and ugly...
<stgraber> indeed :)
<asac> Riddell: sure
<asac> Riddell: its currently breeding
<stgraber> asac: Any progress on that weird wpa_supplicant thing ?
<asac> stgraber: i have been waiting for you to return :)
<asac> stgraber: can you get back to the state where wpa_supplicant takes ages to connect?
<asac> but succeeds?
<asac> stgraber: and try the workaround in http://ubuntuforums.org/showthread.php?t=492386&page=3
<asac> e.g. where he restarts the ipwXXXd
<stgraber> sure
<asac> cool
<stgraber> asac: well, I'm not at home till Saturday but I can test some stuff here anyway
<pitti> infinity: argh, argh
<infinity> pitti: ...?
<pitti> infinity: apache2 ftbfs'es on dpkg-genchanges; I only did debian/rules binary before
<pitti> infinity: rm'ing debian/apache2-dbg is no good, it seems
<stgraber> asac: I doubt it'd change anything to reload ipw3945d as that's what I did before each test with wpa_supplicant (kill ipw3945d, reload the driver, check that ipw3945d is correctly running)
<Mithrandir> you need to make it not part of the files list too, I suspect
<pitti> yeah
<Mithrandir> just make it build-depend on moreutils and do grep -v apache2-dbg debian/files | sponge debian/files
<infinity> Indeed.
<asac> anyone can approve enigmail SRU for dapper/edgy/feisty -proposed?
<pitti> Mithrandir: oh, I had used sed -i
<infinity> Somehow, I don't think sponge is needed there. :)
<mvo_> pitti: that must be a side-effect of the new gtk, I have a look
<infinity> (Though it's cool)
<cjwatson> moreutils++
<Mithrandir> pitti: that doesn't delete blank lines, does it?  But maybe dpkg-genchanges doesn't care about those?
<Mithrandir> I still need to submit my addtimings thing upstream.
<pitti> sed '/apache2-dbg/d' debian/files
<cjwatson> Mithrandir: sed -i '/apache2-dbg/d' would
<infinity> Alternately, figure out which dh_* is adding it, and call it with -Nfoo...
<infinity> _gencontrol?
<cjwatson> s'what DH_VERBOSE=1 is forr
<cjwatson> for
<infinity> (I would have thought _builddeb, but clearly not)
<stgraber> asac: this guy should also better do : "ipw3945d-`uname -r` --kill" which would do both the "ps aux | kill" and the rm at the same time
<asac> stgraber: well ... try what happens if you kill it while connecting
<asac> stgraber: the next thing i would try is to give wpasupplicant all the needed hints (like what you set in wpa_supplicant.conf) and use ap_scan 2 instead
<asac> if that boosts things we should try forcefully use ap_scan 2 when ipw3xxx driver
<stgraber> asac: ok, I put everything in my todolist and test that once my WiFi internet time is over, IIRC I tried with ap_scan 2 and it was even longer, but I'll give it another try
<infinity> cjwatson: I love you.  I learn something new about sed so infrequently these days...
<pitti> meh, bzr constantly crashing on broken pipes with 'bzr log|less' is annoying; it didn't do that in the past, did it?
<asac> stgraber: well ap_scan 2 needs all infos ... iirc it didn't connect at all when we tried last time
<stgraber> asac: can you just give me the three wpa_supplicant and wpa_cli commands again ?
<asac> hehe
<asac> well ... it all starts with hmmm
<stgraber> btw, I can still get them from the chan logs :)
<asac> sudo wpa_supplicant -dd -g /var/run/wpa_supplicant.global
<asac> stgraber: really ... can you add those command to some wpa_supplicant manual wiki page?
<cjwatson> infinity: actually learning awk properly will be my next challenge, I think
<cjwatson> I never really have - skipped straight from sed to perl
<infinity> cjwatson: That was on my TODO for a long time until I started feeling it was just wasted effort.
<asac> Riddell: i think it should be up now
<soren> Grrr....
<pitti> infinity: fixed for good now (sorry), http://people.ubuntu.com/~pitti/tmp/apache2.FTBFS.debdiff is the updated diff
<Mithrandir> Tonio_: any reason to just enable --enable-serial and --enable-inputand not, say, --enable-audio ?
<infinity> pitti: The only change being "+sed -i '/apache2-dbg/d' debian/files; \", I assume?
<pitti> infinity: yep
<infinity> pitti: (I'd already committed my previous changes)
<Tonio_> Mithrandir: cause I didn't want to change to many things, and kdebluetooth doesn't need audio to be enabled :)
<Tonio_> Mithrandir: btw I don't see any technical reason not to enable it too ;)
<Tonio_> Riddell, pitti: wrote a mir for obexftp, needed by new kdebluetooth. https://wiki.ubuntu.com/MainInclusionReportObexftp
<infinity> pitti: Thanks for that.
<Tonio_> Mithrandir: better enable audio too, more functionnalities are never bad
<Mithrandir> Tonio_: ok; I'm asking on #bluez now.
<Tonio_> Mithrandir: oki
<Tonio_> Mithrandir: I suspect this is to connect to bluetooth headphones.... might be possible graphically with kdebluetooth in the future
<Mithrandir> Tonio_: yeah, that's what I figured.
<doko> StevenK: ping
<Mithrandir> (I'm not interested in kdebluetooth, but rather the gnomy bits.)
<Tonio_> Mithrandir: I didn't package the latest bluez-gnome btw, so if you don't I may ping dholbach when back
<Mithrandir> Tonio_: I uploaded that yesterday
<Tonio_> Mithrandir: great
<stgraber> asac: Do you know how the wpa_supplicant ssid is generated from the MAC ?
<asac> just hex?
<Mithrandir> pitti: do you prefer us to turn on pie support if available?
<asac> stgraber: why?
<pitti> Mithrandir: yes, oh yes!
<stgraber> asac: nope, NM send 6772616265722d77696669 for 00:14:D1:C0:39:80
<asac> thats bssid?
<pitti> Mithrandir: still remember that (arguably short) discussion on u-devel@ how to enaable such things globally?
<asac> stgraber: anyway ... try to use plain text for testing
<asac> stgraber: i doubt that this converesion is the problem for us
<Mithrandir> pitti: bluez-utils has an --enable-pie flag to configure.
<Riddell> asac: does the file in bsdiff get linked into GPL/MPL code?
<pitti> Mithrandir: since the current gutsy kernel now has proper randomization and /proc/pid/maps protection, PIE makes sense and is a helpful stopgap measure against standard exploits
<stgraber> asac: Is the ESSID supposed to work with "ap_scan 2" ? (According to the doc it simply connects to the given SSID without any scanning)
<asac> stgraber: set essid + bssid
<asac> you need all set afaik
<stgraber> ok
<asac> in wpasupplicant, essid == ssid iirc
<asac> stgraber: you need to set keymgmt et al as well
<asac> stgraber: i guess those that you see in /usr/share/doc/wpasupplicant/examples/wpa-psk-tkip.conf
<stgraber> ok, I'll simulate a WPA network this afternoon with a laptop and try connecting to it with the other one :), I'll ping you with the result tomorrow
<asac> stgraber: great
<norsetto> pitti: sorry about the r-m page, I should have known better it belonged to the system-utility section :-(
<pitti> norsetto: no problem at all :)
<Riddell> asac: so hmm, #soyuz is somewhat unsure about the bsdiff.c licence and I don't want to let it through if it links to anything with a different licence
<Riddell> asac: if it make a standaline binary that's fine but otherwise you probably need to remove it or find an archive admin who is more sure that it's compatible with the other licences
<asac> most likely its not used
<asac> you can argue its binary garbage?
<asac> Riddell: ^^
<Riddell> it's what?
<infinity> Hahaha.  It's totally firmware. :)
<Riddell> hmm
<asac> Riddell: its not used
<infinity> Problem solved.
<asac> Riddell: its just in source package
<asac> Riddell: we have a bug open to discuss what todo with mozilla source tree before gutsy
<Riddell> ok, that saves some bother then :)
<asac> bug 121734
<ubotu> Launchpad bug 121734 in thunderbird "orig.tar.gz has binary-only files" [High,Confirmed]  https://launchpad.net/bugs/121734
<asac> please let it in and we add sunbird to that bug
<asac> we have to figure out because there are even binaries without source ... though not used nor shipped for us
<asac> read: its a mess ... but we have to find a line for all mozillas imo
<asac> Riddell: maybe its good to add comments you have to that bug so we can present mozilla with a list of things that should be improved
<infinity> asac: If it wouldn't be asking too much of them, a pure MPL/GPL tarball, with a "random other crap" tarball that could be used as an overlay to distribute the other bits might be nice.
<infinity> asac: But that would take finding all the offending files, and mangling their release engineering to produce the two tarballs. :/
<Riddell> asac: accepted, it's seb128's archive day so you may want to poke him once it has compiled to let it through binary new
<asac> infinity: we have a rather complete list of binary only files in ice* applications for debian
<asac> infinity: as we try to clean that tree completely before releasing
<asac> infinity: however ... upstream will most likely not like that idea, because those files exist for the sole purpose of making mac/win developers life easier
<infinity> asac: That could prove helpful, then, if upstream was willing to listen to the "pretty please, can we have free tarballs?" pleas.
<asac> infinity: the idea is to at least ship all sources
<asac> infinity: next to binaries ... they have the sources in cvs ... so its just a matter of tarball plumbering
<infinity> asac: Hrm, and the "overlay" thing is a bit more of a pain on Windows, since it's slightly less intuitive to unpack two archives over each other with most windows archive tools.
<asac> most likely
<asac> first step will be to ship all sources i guess
<asac> then go for higher means :)
<asac> after all they are redoing their build system
<asac> so maybe its not worth to tackle it now
<asac> Riddell: thanks
<infinity> I'm not keen on shafting Windows developers either, TBH.  I suspect a very large portion of firefox users (and bug sumitters) are on Windows, atfter all. :)
<asac> well ... i am currently more concerned about whether linux matters at all
<infinity> (Yes?)
<asac> we have to entangle with other distributors and push in one direction ... otherwise mozilla 2.0 will be messy
<asac> (at least i fear that it will become a pita)
<infinity> Well, pushing for consistent licensing is something you can usually get all the distributions to agree on, even if they do view Debian as "idealistic".
<asac> yeah right :)
<infinity> I know I've never had problems pushing license disambiguation and such upstream to RedHat and SuSE projects.
<asac> welll suse might be a bit different now :)
<StevenK> doko: Pong
* StevenK sighs, since the bug in LyX is still present in current SVN.
<doko> StevenK: your curl merge ... in the changelog you say that you did revert your patches, but they are still laying around and are applied?
<StevenK> They are?
* StevenK checks.
<doko> +       quilt push curl4_syms
<StevenK> Yes, I see that.
<StevenK> However, the patch basically has no affect whatsoever.
<StevenK> effect, damn it all
<doko> StevenK: ok, I'll remove that stuff
<StevenK> doko: Cool.
<Mithrandir> Tonio_: btw, --enable-inputmakes hidd obsolete, I'm told.
<Tonio_> Mithrandir: make it obsolete for the binary, yes
<Tonio_> Mithrandir: I'm unsure concerning the autoreconnection
<Tonio_> Mithrandir: but I may be wrong on that point
<Tonio_> Mithrandir: let's not enable it and test
<Mithrandir> Tonio_: Marcel Holtmann told me hidd was obsolete if you use --enable-input.  I tend to trust him on bluetooth matters.
<Tonio_> I'll do tests with hidd enabled locally and will give you or daniel feedback
<Tonio_> Mithrandir: of course we have to trust him :)
<seb128> Tonio_: Daniel is on holidays for 3 weeks
<Tonio_> seb128: yep I've been told this morning
<Tonio_> Mithrandir: let's just not enable hidd and that's it ;)
<Tonio_> seems to work here btw
<Mithrandir> Tonio_: ok, coolie. :-)
<Mithrandir> Tonio_: I was just planning on testing, uploading and then going on VAC. :-P
<zul> Mithrandir: but you cant go on vacation ;)
<Mithrandir> sure I can
<zul> sure you can
<Tonio_> Mithrandir: hehe :)
<Tonio_> Mithrandir: I'll have to wait a bit to upload kdebluetooth as a MIR approval is required before that
<StevenK> pitti: Ping
<pitti> hey StevenK
<ogra> :q
<Amaranth> ogra: you can't quit IRC
<ogra> oops, wrong win, sorry
<ogra> :)
<StevenK> pitti: If and when I fix pdftk to love life, it should the last rdepends for libgcj7, but openoffice.org-officebean is in there on powerpc - since the powerpc built of openoffice.org on the buildds spun idly for 10 hours and was killed by sbuild.
<pitti> ogra: :s/focus_xchat/focus_gnome_terminal/g :)
<ogra> yeah *g*
<bhale> pitti: :%s
<StevenK> But what if your IRC is in a Gnome Terminal? :-P
<bhale> ooh
<pitti> StevenK: right, known; OO.o has never built on ppc so far
* StevenK hugs irssi close.
<pitti> StevenK: let's hope that calc's latest creation of 2.3 packages will again...
<bhale> my irssi is in a putty :<
<StevenK> bhale: One of my workmates does that, it's very disturbing.
<StevenK> They have a Linux workstation, but instead of opening a terminal, they open putty and ssh to localhost.
<bhale> StevenK: unfortunately i need a xp pc at my desk, our exchange is currently too old to work with evolution
<broonie> StevenK: pterm?
<bhale> we are migrating now, very exciting
<StevenK> bhale: My condolences.
<StevenK> broonie: Hrm?
<bhale> StevenK: its a sad day when I pin my hopes and dreams on Evolution
<StevenK> Heh
<broonie> StevenK: Someone (possibly the PuTTY authors) pulled the terminal emulator out of PuTTY.
<StevenK> Oooh, right.
<bhale> I think a rather distinguished ubuntu hacker uses pterm, iirc
<bhale> I want to say Tollef
<Mithrandir> I do, as does cjwatson
<StevenK> Yeah, I think said workmates issue for using PuTTy is the terminal emulation.
<Mithrandir> my only gripe with it is it doesn't do dead keys.
<StevenK> I wonder if pterm uses less RAM than gnome terminal ...
<pygi> hey Hobbsee
<Hobbsee> hi pygi
<desrt> bhale; we have a hero working on tnymail :)
<Hobbsee> hiya desrt
<desrt> hello hobbsee
<desrt> what do you use for mail?
* pitti hugs desrt 
<Hobbsee> desrt: thunderbird
<Hobbsee> hiya pitti
<pitti> desrt: oh, is there something else than mutt? :-P
<desrt> Hobbsee; you know that mozilla is dropping thunderbird, right?
<desrt> pitti; ya.  there's less.
<Hobbsee> desrt: i heard that, yes.  no idea what that actually means for thunderbird development though
* desrt really really wants to see tinymail-based mailers come of age
<Ng> yeah that's looking very interesting
<Hobbsee> desrt: basically, i'm looking for a mail client that lets me run multiple identities, and that doesnt suck.
<Ng> Hobbsee: all email clients suck
<Hobbsee> Ng: this is true, but some suck more than others.
* desrt looks at Hobbsee with shifty eyes . o O ( ...secret second life as a spy? )
<StevenK> s/some/most/
<Riddell> seb128: are you able to review capseo and libcaptury in New sometime soon? I just uploaded them and they're needed for kde 4 beta out today
<desrt> Hobbsee; i've always been more of the forward-everything-to-one-account type :)
<pitti> Hobbsee: http://www.mutt.org/, see the quote at the top :)
<pitti> Hobbsee: (nevermind me)
<desrt> pitti; nice :)
<zul> Hobbsee: you could use outlook :)
<Hobbsee> pitti: haha :)
<desrt> pitti; reminds me of X :)
<bhale> hi desrt
<Hobbsee> desrt: of course.  one of the identities is She Who Must Be Obeyed.
<Hobbsee> zul: go and wash your mouth out with soap!
<pitti> Hobbsee: you are *not* a wife yet
<Hobbsee> even when i used windows exclusively, i hated outlook
<Hobbsee> pitti: how do you know?  *g*
<Hobbsee> pitti: but apart from that, what relevance does that have?
* StevenK has never used Outlook for mail.
<pitti> you told me
<Hobbsee> oh, point
<desrt> hahahah
<desrt> that's... blunt.
* StevenK would like to bind and gag gcj so it speeds up and more importantly, *shuts up*
<Hobbsee> StevenK: it's got some quirky "feature" that it doesnt actually automatically send mail.  it stores it in the outbox, and you have to hit the button manually.  it also doesn tsend on exit.
<cjwatson> bhale: apt-cache show pterm | grep Maintainer ;-)
<cjwatson> broonie: yes, it was the PuTTY authors, specifically Simon
<cjwatson> he largely did the Unix port so that he could run valgrind on PuTTY, but hey, spin-offs ...
<desrt> Hobbsee; sounds like there would be an option for that somewhere
<Hobbsee> desrt: there may well be.  there should be.  i just never found it, when playing with it.
<cjwatson> StevenK: pterm should certainly have the same terminal emulation as PuTTY; that's kind of the point
<Hobbsee> then again, they mostly didnt have outlook in win95, so... :P
<desrt> my body is quite confused.  i keep going to bed at 11:something and waking up, tired, at 8am
<desrt> i'm sleeping fantastically well... but this being awake early thing is throwing me for a loop :/
<ion_> pterm Depends: libgtk1.2 :-(
<bhale> desrt: 8am? early?
<desrt> bhale; for someone who normally rolls over around noon, yes :p
<Hobbsee> bhale: 8am is very early
<bhale> desrt: never leave McMasters
<desrt> McMaster
<desrt> say it like that and it sounds just a little bit too much like meccas :p
<desrt> i think i'll make some tea or something.  any takers?
<Hobbsee> desrt: give me coke, keep me awake :)
<seb128> Riddell: yes, I'll have a look
<cjwatson> ion_: yes, there's a gtk2 branch upstream but it isn't quite stable yet (issues with the font selection dialog, that sort of thing)
<cjwatson> svn://ixion.tartarus.org/main/putty-gtk2
<cjwatson> and see unix/GTK2.TODO
<ion_> cjwatson: Ok, nice.
<cjwatson> I have a patch for one further bit of that; must dust it off and send it upstream
<cjwatson> (the list/tree stuff)
<Hobbsee> jono: are you around, by any chance?
<jono> Hobbsee, briefly
<encompass> doko: I am looking at the restricted python module here... http://pypi.python.org/pypi/RestrictedPython/3.4.2 and finding that there is no specific package to handle this module... infact there is some duplicate code found here... http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=RestrictedPython&searchmode=searchfilesanddirs&case=insensitive&version=feisty&arch=i386 is it possible to pull restricted python out and 
<encompass> sorry :P
<Hobbsee> jono: right.  it looks like we could use some help in resolving a developer issue.
<jono> Hobbsee, right, I am not going to be able to solve it this week - I am on holiday
<jono> Hobbsee, what is the problem though?
<Hobbsee> jono: Kmos.
<ivoks> cjwatson: any toughts on bug 93077?
<ubotu> Launchpad bug 93077 in console-setup "Non-exsisting layouts" [Medium,Confirmed]  https://launchpad.net/bugs/93077
<jono> Hobbsee, kmos?
<ogra> jono, a slightly over enthusiastic guy
<jono> right
<ogra> he's trying to help with bugs since some days
<jono> ok
<pygi> ogra, shirish folk?
<ogra> but rushes beyond the target without knowing or respecting the procedures ....
<jono> right
<jono> have you spoken to him/her about this?
<ogra> there was some discussion in #ubuntu-bugs for the last hour
<doko> encompass: better pack it from the upstream source, you may want to contact pkg-zope-developers@lists.alioth.debian.org
<StevenK> And on -motu a few days ago ...
<ogra> (or half hour)
<Hobbsee> jono: he's not following developer protocol, filing mass sync requests, closing bugs for no reason, filing mass removal requests (the firs tand third of these are mostly incorrect), continually pinging people, including archive admins.  all this he has not been asked to do.  he's had explained to him over and over why these things are wrong (technically), yet doesnt seem to listen or take in the information.  he doesnt respect the requests
<Hobbsee> of not filing the bugs, especially when he doesnt understand them.  the upshot of which, if he refuses to behave in a sane way, he needs to be removed from the ubuntu development community, as he's damaging ubuntu development, and not letting people get stuff done.
<cjwatson> ivoks: I'll try to get round to it, can't right now ...
<Hobbsee> StevenK: and on motu tonight.
<Hobbsee> jono: there have been repeated attempts, yes.
<ivoks> cjwatson: thanks!
<Hobbsee> of course, the sponsorship queues are being disrupted when over half of the requests tend to be Kmos' bugs, which are mostly wrong.
<Hobbsee> jono: so it's all effecting MOTU quite badly.  and ignoring doesnt work, due to the mass bug filing, and how it lands on the queues.
<jono> Hobbsee, ok, well I can't do anything this week as I will be away, but I will speak to him when I get back
<jono> Kmos, ping
<Hobbsee> jono: the thing i more want to know is, is this worth taking to the CC, etc?
<jono> Hobbsee, not right now
<Hobbsee> jono: how is it best to solve this issue?
<Kmos> jono: i'm here
<jono> Hobbsee, let me speak to him
<jono> Kmos, can we chat?
<Kmos> jono: sure
<jono> Kmos, are you aware of some of the problems people are concerned about with your contributions?
<Hobbsee> jono: okay
<ScottK> jono: Be sure and get him to explain why he thinks he's authorized to approve backports.
<Hobbsee> oh yes, i forgot the backports in my original list
<ScottK> Hobbsee: Would you please unsub u-m-s from bug 128402.  He's gone and subscribed them for some random reason too.
<ubotu> Launchpad bug 128402 in k3b "Please backport k3b 1.0.3 from Gutsy to Feisty" [Undecided,Invalid]  https://launchpad.net/bugs/128402
<jono> Kmos, you still there?
<Hobbsee> ScottK: cant, sorry, not part of the team.
<Kmos> jono: private please
<ScottK> Ah.
<jono> Kmos, ok
<Hobbsee> ScottK: but it's marked as invalid anyway, so they wont get too much mail
<Kmos> Hobbsee: why it's invalid d?
<ScottK> Hobbsee: I marked it until I get it fixed.
<jono> Kmos, you get my priv msg?
<Kmos> jono: yep
<pitti> ScottK: any idea what was wrong with bug 128402
<ubotu> Launchpad bug 128402 in k3b "Please backport k3b 1.0.3 from Gutsy to Feisty" [Undecided,Invalid]  https://launchpad.net/bugs/128402
<ScottK> pitti: The person that subscribed both the archive and ums wasn't in backporters.
<ScottK> Frankly I think it's probably fine, but jdong has been the one working it.
<pitti> ScottK: right, but why is the bug invalid?
<pitti> ScottK: there were two positive tests
<ScottK> I marked it invalid until the subscriptions could be fixed
<ScottK> I had planned to un mark it once the archive and ums had been unsubbed.
<ScottK> Agreed that there were two postitive tests, but the person that subscribed the archive wasn't someone who should have done that.
<pitti> ScottK: ah, I see; well, I cannot unsub ums, and u-a is unsubbed
<ScottK> OK.
<pitti> ScottK: so maybe it should be 'Incomplete'?
<Hobbsee> ScottK: the marking will still send bugmail, btw
<Hobbsee> as in, each time you mark it, it sends more bugmail
<ScottK> Right.
<Hobbsee> so you may be better off not touching it
<pitti> ScottK: archive guys only consider bugs which are Confirmed or In Progress (maybe even only the latter)
<ScottK> OK.
<ScottK> Good to know.
<pitti> ScottK: alright, thanks for clearing that up; I was just confused by that
<ScottK> I mostly didn't want it getting accidentally backported.
<ScottK> I've had enough trouble recently with backports that didn't go through the procees.
<ScottK> err process.
<pitti> ScottK: right; I think 'Incomplete' will work fine for that
<pitti> seb128: ^ do you agree?
<ScottK> Agreed.
<seb128> pitti: I did unsubscribe ubuntu-archive some minutes ago
<seb128> pitti: what backport team does now is concern them, but yeah look like Incomplete or New is about right
<pitti> https://launchpad.net/feisty-backports/+bugs?field.status%3Alist=In+Progress
<pitti> ^ that's my canned search for backports to be processed
<ScottK> Good to know.
<pitti> ScottK: hm, so even 'confirmed' will not be on my radar; does that coincide with your process?
<ScottK> Yes it does.
<seb128> pitti: ideally if ubuntu-archive is subscribed the bug should be to process
<pitti> ok, cool
<StevenK> I can unsubscribe u-m-s if you wish
<seb128> no reason to subscribe the team otherwise
<ScottK> Please do.
<pitti> seb128: yeah, but we might put it back to needsinfo e. g. if it is out of date or so
<seb128> right
<pitti> erm, "Incomplete" in newlpspeak
* pitti has some troubles purging "needs info" from his brain
<seb128> :)
* ogra tries to pronounce newlpspeak
<ScottK> Ideally yes, but as we've just seen random people subscribe the archive (and set in progress).
* seb128 understands "Needs Info"
<StevenK> ScottK: Done.
<ScottK> Thanks.
<iwj> IJLTS `bug nnnn - Unimportant Incomprehensible'
<ScottK> Up until now, I've been against the idea of the status restrictions, but I'm convinced it's needed.
<seb128> ogra: do you plan to do the gnome-screensaver and gnome-power-manager updates, there is some of the few modules left to update to get GNOME 2.19.6
<ogra> i'm on it, should be done today
<seb128> cool, thanks
<Hobbsee> ogra: you're german.  you should have no problem :P
<ogra> sorry for the delay, had some ltsp things before
<pitti> Hobbsee: "Rotkraut bleibt Rotkraut und Brautkleid bleibt Brautkleid"
<jono> ok everyone
<ogra> Hobbsee, depends ;)
<seb128> ogra: no problem
<jono> listen to me for a second :)
<jono> I have spoken with Kmos
<pitti> Hobbsee: (common tongue twister in .de)
<jono> the problem here is that Kmos just needs to learn how the community works, and learn from everyone
<ScottK> jono: That's not the problem.
<Hobbsee> pitti: yeah, that.
<jono> ScottK, one second
<Hobbsee> pitti: i thought it was something like that.
<Hobbsee> ogra: :)
<jono> I have asked if Kmos could ask in #ubuntu-devel before making an action
<jono> and to ask generally in #ubuntu-devel
<jono> I would like him to ask before he does things, and act on the advise of the community
* ScottK is convinced that he's incapable of learning it, but is listening.
<ogra> jono, he also needs to learn to listen a bit and step back from being overly enthusiastic ... while thats great, its harmful if unchanneled
<jono> ScottK, please, the aim here is to resolve the problem, please work with us
<pitti> I have quite a lot of contact with Kmos, too, and while I agree that he did some bad things in the bug tracker etc., he did some helpful things, too, so it's mainly a matter of education (not malice)
<Mithrandir> anybody know where the pimlico/openedhand people hang out?
<jono> indeed
<ScottK> jono: We've tried that before.  It lasted about a day.
<ogra> pitti, ++
<jono> Kmos is a good contributor, he just needs to learn how to do things right
<jono> ScottK, you are not helping if you take that attitude
<seb128> I'm not sure encouraging him to ask things on the chan is a good idea
* ScottK is listening
<jono> the point here is that Kmos needs to understand the right way of doing things
<Hobbsee> jono: however, that does require that he listens to what people tell him, and puts it into action.
<jono> the only way that can happen is for him to step back, stop firing on all barrals and ask for help
<Kmos> ScottK: don't need to ignore me..
<jono> Hobbsee, which I have asked him to do
<jono> Kmos, you will listen to the advise people give you and act on it, right?
<seb128> jono: my issue with him is that he keeps asking me to look at his bugs rather than waiting
<Hobbsee> jono: excellent.  i hope he then does so
<pitti> "stop firing on all barrels" ++
<Kmos> jono: Ok
<pitti> throwing ten "plz fix this, kthxbye" /queries a day at me won't do much good
<Kmos> [14:57]  <ogra> jono, he also needs to learn to listen a bit and step back from being overly enthusiastic ... while thats great, its harmful if  unchanneled
<jono> Kmos, you really *do* need to take a step back, and take advise from people in here
<Kmos> ogra: i agree with you
<jono> Kmos, stop providing quotes
<jono> listen to my words
<Kmos> i'm listenin
<jono> we can *all* work *really* well together
<jono> it just needs patience on behalf of ogra, Hobbsee and ScottK and willingless to learn on behalf of Kmos
<jono> I don't want to see people suggesting we eject Kmos out of the channel or ban him, and I also don;t want to see Kmos ignoring advice
<ScottK> jono: You have NO idea how much patience has already been shown.
<pitti> Kmos: try to do fewer things and focus on them to understand them thoroughly and get them right
<jono> ScottK, I agree, but this is a community, and some people take longer to get the idea than others
<seb128> Kmos: and be patient, no need to ping people on IRC because has bug has been opened without reply for a day
<jono> Kmos, so everything clear?
<Kmos> seb128: ok, sorry for everything
<Kmos> pitti: ok
<Kmos> jono: yes
<Hobbsee> jono: i have limited time.  i cannot spend hours on someone, and find that htey're not listening to what i say.  at all.  it's like talking to a brick wall, and i frankly have better things to do, both on ubuntu and outside of it, than that.
<ScottK> I would just like to note for the record that everything that was said to kmos just now was (almost verbatim) already said to him several days ago.
<jono> Hobbsee, then step back
<jono> Hobbsee, no one is expecting you to spend any more time on Kmos, so just seperate yourself from the issue
<cjwatson> everyone has a right to choose not to act on something
<Hobbsee> jono: this is the logical plan
<seb128> Hobbsee, ScottK: let's calm down and give him another try
<ScottK> You are welcome to.  I'm done.
<Hobbsee> jono: however, one can ignore irc.  one cannot ignore the sponsorship queue.
<Kmos> I'll try to change my attitude of enthusiastic/excess to see things better (we do mistakes when try to be GOD and be everywhere) from today..
<Hobbsee> jono: where one is actually the head of it
<Hobbsee> jono: which is really quite unfortunate.
<ScottK> Kmos: How is this different than when Hobbsee and I told you the exact same thing two days ago.
<jono> ScottK, PLEASE
<jono> Kmos has accepted he has made mistakes, lets give him a chance
<Kmos> ScottK: pitti told me a thing you've already said.. it's true
<Hobbsee> jono: one can also not really ignore the dropping rationale of the others who are looking at the sponsorship queue, and crying over it.
<Hobbsee> jono: the people crying over the state of the queue that is, not the rationale
<seb128> Hobbsee: let's say that things have been clarified now
<jono> Hobbsee, everyone has the ability to step back for a second, and Kmos will not be doing anything without checking first for the next few weeks anyway
<seb128> Hobbsee: if there is still issues in the next days raise them to jono
<jono> indeed
<Hobbsee> seb128: i hope so.  but i thought the same thing a few days ago, and kmos proved that they hadnt with this latest lot of sync requests :)
<jono> Hobbsee, please
<seb128> Hobbsee: let's say it has been done "officially" now
<Hobbsee> so, i'm a little wary of the "i promise i'm fixed"
<seb128> stop there
<seb128> and let's see how it goes
<seb128> ok?
<jono> indeed
<Hobbsee> seb128: you type faster than i do
<seb128> ;)
<jono> Kmos, so to be clear - you will not make any syncs or contributions without asking in #ubuntu-devel first, right?
<Hobbsee> what i was about to say next, was "however, if he can show actual change, then i'll not pressure for him to be removed from ubuntu development"
<desrt> seb128; i just opened this bug about some gnome packages released 12 seconds ago not being packaged for ubuntu yet.  please fix.
<ScottK> I'll also just note that I am currently angry enough that I'm considering quitting Ubuntu right now.
<Kmos> jono: ok
<seb128> ok, good, everybody goes back to work then ;)
* seb128 slaps desrt
<Hobbsee> ScottK: you should probably step away from your machine for a while.
<TheMuso> ScottK: Please? We need you.
<desrt> :)
<Kmos> can I say one thing
<Kmos> ?
<ScottK> Agreed.
<desrt> seb128; your level of service is falling :p
<Kmos> ScottK: please don't ignore me
<jono> we can all work well together, kmos just needs to know the boundaries and get the enthusiasm and work right
<jono> lets all be supportive of him for two weeks and see how he improves
<seb128> desrt: you are welcome to give me a hand then ;)
<TheMuso> I for one, am confident he will, after working with him regarding syncs, and positive outcomes being achieved.
<desrt> sebuild 3.0?  heh.
* Kmos maybe it's because I take some pills everyday.. paroxetina merck 20 mg and sedoxil
* Hobbsee tries not to ponder the state of the sponsorship queue, in 2 weeks, if it all turns to hell
<Kmos> Hobbsee: not on crack :P
* Hobbsee tries to be positive instead
<seb128> stop there
<seb128> enough
<seb128> let's rather see how it goes now
<desrt> less talking = more hacking :)
<Hobbsee> i am, i am.  or at least, will do
* coNP shuts up and hacks :)
<seb128> coNP: way to go ;)
<StevenK> pitti: libapache-mod-removeip can be NBS'd out
<StevenK> zul: Why does xen-utils-3.1 Depend on python-xen-3.1 if it isn't provided by any package?
<pitti> StevenK: I rejected the last round of binaries because they had too many RC bugs in them
<StevenK> pitti: input-modules-2.6.22-8-*-di is also listed, is that waiting on something?
<StevenK> Ahh
<pitti> StevenK: no, I'll get it purged along with the apache one now
<StevenK> pitti: Way cool, thanks.
<StevenK> pitti: They are the only zero sized under NBS, which should make it simple
<pitti> done
<StevenK> Danke
<pitti> StevenK: hm, should I purge lyx-{qt,xforms} and thereby render sdcc FTBFS?
<zul> StevenK: it should be fixed soonish
<pitti> it wouldn't make the package uninstallable, but remind the next person uploading it to fix it
<StevenK> pitti: Sure. It FTBFS anyway, due to the .lyx file provided containing encoding errors, and lyx ABRT'ing when trying to export plain text.
<pitti> ah, I see
<pitti> so, <jedi wave>away with them
* StevenK idly wonders if we should just consider silky dead upstream
<StevenK> Gnome moved from CVS to SVN, and the silky guys haven't noticed.
<stdin> anyone ever think about splitting #ubuntu in to a couple of channels?
<stdin> it needs it IMO :P
<seb128> stdin: there is #ubuntu+1
<seb128> ;)
<stdin> heh
<Amaranth> and #ubuntu-effects
<stdin> yeah, not quite what I meant there
<seb128> there is lot of #ubuntu-*
<seb128> bugs, motu, meeting, devel, mobile, x
<seb128> etc
<stdin> every time I join #ubuntu I instantly get a migraine
<jmillionator> yeah; that's why I joined the forums
* jmillionator ducks
<Amaranth> if you mean splitting it into several general channels #python tried that with a much smaller group
<Amaranth> all the smart people worked really hard to make sure they were in one of the two channels and everyone in the other channel lost out
<stgraber> asac: results are :
<stgraber> ap_scan=1 + unset bssid + connected to another WLAN -> 2xTimeout 00:00:00:00:00:00 and then disconnect+connect
<stgraber> ap_scan=1 + set bssid + connected to another WLAN -> disconnect+connect successfully
<stgraber> ap_scan=2 + set bssid + connected to another WLAN -> doesn't connect at all, connects immediatly after having manually set the AP with "iwconfig eth3 ap xx:xx..."
<stdin> Amaranth: can't you manually join the forwarded channels ? so people who want to help can be in both
<Amaranth> following one big channel is easier than following 5 smaller ones
<stgraber> asac: I'm currently connected using gprs so can't really download network-manager sources (due to the cost of such connection) but will do tomorrow on wlan, can you do a patch for NM to add "network_set 0 bssid xx:xx:" ?
<asac> stgraber: we ... it should be done by nm already
<munckfish> Why doesn't invoke-rc.d check it's being run by root? Is there ever a scenario where it gets run by a non-priv user?
<Amaranth> there is no explicit reason for it to not work as root
<asac> stgraber: what we should try is to use ap_scan 2 for ipw3xxx driver
<stgraber> asac: nope, it doesn't connect before I manually move to the correct bssid with iwconfig
<stgraber> asac: even with network_set 0 bssid
<asac> stgraber: yes ... i think network manager does that if it uses ap_scan
<asac> 2
<asac> but have to verify
<asac> stgraber: so setting right bssid in wpa doesn't help?
<stgraber> asac: it helps with ap_scan=1
<munckfish> Amaranth: ok I just found this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229972
<ubotu> Debian bug 229972 in sysv-rc "invoke-rc.d could check for root" [Wishlist,Open] 
<stgraber> asac: NM does : ap_scan=1, add_network, set ssid and key_mgmt here
<stgraber> asac: not set bssid
<asac> stgraber: yes
<munckfish> The problem is the init scripts don't check they have the correct privs
<asac> stgraber: let me look
<stgraber> asac: so setting ssid and bssid may help
<stgraber> asac: that's what tell the tests I've done the past two hours at least
<stgraber> asac: ap_scan=2 doesn't connect at all without manual intervention, ap_scan=1 without bssid set cause timeouts and with bssid it connects just fine
<asac> stgraber: does it invoke "SET_NETWORK %i scan_ssid 1" for you?
<asac> stgraber: right ... imo nm should manually select ap for ap_scan=2
<stgraber> no it doesn't (at least I don't set it in syslog)
<stgraber> imo, forcing it to set the BSSID helps as it'll automatically ignore this 00:00:00 thing (not matching bssid)
<StevenK> jono: I'd be curious to see the difference in which US states still need LoCo teams after your blogs/fridge posting got dugg. Can certainly wait when you're back from holidays.
<iwj> munckfish: Why would it matter ?  Either it will work, in which case fine, or it will fail harmlessly, in which case fine.
<iwj> It's rarely a good idea to check in advance for a specific kind of installation problem; best just to let things carry on and fail when they fail - and have proper error handling of course.
<munckfish> iwj: the guy sat next to me just tried to restart apache, but forgot to add sudo in front
<munckfish> the error message wasn't that helpful
<iwj> Yes, so it didn't work and ...
<iwj> ... the error message should be improved ?
<iwj> What did it say ?
<munckfish> vague things, but the error comes from the apache init script
<munckfish> now
<infinity> iwj: Check the debdiff between your dpkg upload and the one I made earlier today.  Have a good cry about the horrible hack I had to do.  Revel in the realisation that at least it works.  And maybe give some thought to making someone rewrite the triplettable madness to properly support our use case. :)
<iwj> Error messages shouldn't be vague.
<munckfish> rather than set about updating all the init scripts in history right now
<munckfish> I wondered if something helpful could be added to invoke-rc.d
<iwj> infinity: I have a bad feeling about this.
<infinity> iwj: Not as bad as the feeling I had uploading it.
<infinity> iwj: But at least it works for now. :/
<munckfish> iwj: So I found myself asking, in what situation would an init script not be run as root?
<Hobbsee> stdin: read teh ubuntu-ops mailing list - it has been proposed
<iwj> infinity: ROTFL
<iwj> This whole thing is a complete mess.
<jono> StevenK, been lots of new teams formed
<iwj> (And I wish w3m wouldn't insist on decompressing .tar.gzs when you download them!)
<jono> StevenK, we are going to have locos in every state for sure I think :)
<iwj> munckfish: As an example, I would expect that  /etc/init.d/apache reload  might well work when run as apache and if it does that would be worth keeping.  If not apache then there's probably another example.
<StevenK> jono: Way cool. :-)
<infinity> iwj: Yeah, if you follow what it was doing to me, you'll see why the hack was necessary.  That whole parsing subsystem needs to be rewritten to support what we're doing.
<munckfish> iwj: here's the output for apache init script without sudo: http://paste.ubuntu-nl.org/32150/
<jono> StevenK, kicking ass and taking names
<iwj> That whole parsing system is complete nonsense.
<jono> :)
<infinity> iwj: (And I needed it now, not in a few days, after I rewote it)
<iwj> Yes.
<iwj> Rewrote> and then it would do fourteen other crazy things at least until we'd had time to deal with the bug reports.
<aaroncampbell> We seem to be getting very regular Firefox updates for feisty (just got 2.0.0.6), but not Thunderbird...we're still on the 1.5 series.  Is there any reason why?
<infinity> iwj: Indeed. :)
<munckfish> iwj: of course it does the 'right thing' in the end, it's just that it's not as nice and clear as a "You need to run this as root" (exit)
<infinity> iwj: The hack is fine for now, just Sick And Wrong.
<elkbuntu> jono, you realise that'll be 52 baby birds chirping for worms, right ;)
<iwj> infinity: Yes.
<iwj> Reading that code it wasn't at all clear to me that all of this separate piping of different bits of these different insane arch strings is at all reasonable.
<StevenK> jono: Since when are there more than 50 US states?
<jono> elkbuntu, indeed
<Spads> StevenK: there are territories
<jono> hehe
<Spads> StevenK: puerto rico, virgin islands, guam...
<StevenK> Ahhh
<elkbuntu> ok, so i suck at america
<iwj> And of course there's no documentation of what a `Debian triplet is' and GNU triplets use concepts from 30 years ago.
<iwj> s/ is'/' is/
<Spads> of course, the territories get their own ISO names generally
<infinity> iwj: It's entirely unreasonable, IMO.  Could be reworked to something saner, but I'd prefer to do that upstream.
<jono> USA now, Africa next ;)
<elkbuntu> jono, africa is going to be a real challenge though, technologically
<iwj> upstream> Right.
<jono> elkbuntu, indeed
<jono> elkbuntu, but anything is possible :)
<iwj> munckfish: Seems fairly clear to me.  It says `Permission denied' twice, once as the last thing.  There's a bit of noise about the fqdn - is that a general problem with the installation ?  If not then there might be a bug there.
<infinity> iwj: Anyhow, after abusing it, I verified it on 7 of our arches, and it produces output I'm happy with, so we'll keep this crack for the time being.
<iwj> If you're at a prompt restarting apache then you ought to know what EACCES means :-).
<iwj> infinity: Right.
<elkbuntu> jono,  of course it is
<jono> we are going to make some serious shit happen with LoCos :)
<jono> right screw you all, I am on holiday :P
<jono> and I need to tidy my house :(
<munckfish> iwj: it's ok I give up :). The fqdn bit is cause it's running on localhost
<stgraber> asac: Will be back on WiFi tomorrow, this gprs is really way too expensive :)
<xxxxx1> we have many Psi users here?
<xxxxx1> bug 66940
<ubotu> Launchpad bug 66940 in psi "Psi version string presents as "Debian testing/unstable" on Dapper" [Low,Confirmed]  https://launchpad.net/bugs/66940
* xxxxx1 thinking... in add this code to recognize Ubuntu
<xxxxx1> :)
<Hobbsee> xxxxx1: that'd be cool :)
<xxxxx1> rock n roll
<ScottK> Well isn't there already an upstream bug on that?
<xxxxx1> i'll check
<ScottK> That's what the bug said.
<ScottK> OTOH, we've already got an Ubuntu specific version, so one more change shouldn't hurt.
<xxxxx1> sorry, what's "OTOH"?
<xxxxx1> :}
<coNP> on the other hand, IIRC :D
<norsetto> AFAIK, on top of my head
<xxxxx1> coNP, thx
* ScottK meant the coNP one.
<norsetto> ScottK: Hey Scott, I have a couple of hours to kill, any quiz?
* norsetto loves quizzes....
* Hobbsee tries to think of one
* norsetto doesn't like the shiny look in Hobsee eyes.....
<Hobbsee> norsetto: okay, fix turkey :)
<norsetto> Hobsee: turkey, right
<norsetto> Hobbsee: the country or the bird?
<Hobbsee> btw - hit hob<tab> to save typos, and to save typing
<Hobbsee> norsetto: the package :)
<Hobbsee> and i take no responsibility if it all blows up
<norsetto> Hobbsee: nice thx
<lemsx1> it looks like the Gutsy DVD is oversized... would making a DVD using jigdo work?
<norsetto> Hobbsee: ok, let me check that out
<Hobbsee> norsetto: if you get really brave, have a look at slash.  unsure if that should be removed, or a newer version synced from debian, or what
* Hobbsee cant immediately see what to do with that one, so try turkey first :)
<geser> Hobbsee: slash is on my watch list of the apache rdepends. there is already a Debian bug for it: Debian bug #429071
<ubotu> Debian bug 429071 in slash "please update/request removal of your package" [Serious,Open]  http://bugs.debian.org/429071
<Hobbsee> geser: even better :)
<Hobbsee> norsetto: that's part of the stuff to check for, of course - debian and launchpad bugs on it
<Hobbsee> BAD APT!
<Hobbsee> hm
<Hobbsee> apparently i put yn, instead of n, and it took it
<Hobbsee> oh, i'tll accept y*.  interesting.
* Hobbsee thought apt would purge things even if you did tell it no, instead aborting, for a minute there
<ScottK> That'd be fun.
<Hobbsee> that'd be special
<ScottK> norsetto: What should be done with thunderbird-quickfile?
<ScottK> There's one for you.
<norsetto> Hobbsee: what problem for turkey, I can see more than one .....
<Hobbsee> norsetto: oh, the fact that it doesnt install.  but fix all of them, really :)
<norsetto> Hobbsee: the install is just because of the miss. dep
<norsetto> Hobbsee: there is a debian bug as well on that
<norsetto> Hobbsee: do you know why libgcj7-awt is not in gutsy?
<norsetto> anyhow, that lib causes an exception in feisty
<norsetto> Hobbsee: so, all the problems I see are just for a common cause: libgcj7-awt
<Hobbsee> norsetto: try installing libgcj7-awt in gutsy
<Hobbsee> you're in luck with the output
<norsetto> Hobbsee: and there is also a missing build-depends ....
<Hobbsee> ah, then add them hwile you're at it :)
<norsetto> Hobbsee: well libgcj7-awt is not in unstable anymore too....
<Hobbsee> norsetto:
<Hobbsee> Package libgcj7-awt is not available, but is referred to by another package.
<Hobbsee> This may mean that the package is missing, has been obsoleted, or
<Hobbsee> is only available from another source
<Hobbsee> However the following packages replace it:
<Hobbsee>   libgcj7-1 libgcj7-0
<Hobbsee> E: Package libgcj7-awt has no installation candidate
<Hobbsee> (that outputs when you try to install libgcj7-awt
<norsetto> Hobbsee: yes, its mentioned in the debian bug too
<Hobbsee> ScottK: can you help?  i really need to head to bed
<Hobbsee> norsetto: does it build with the changed library?
<norsetto> Hobbsee: no, missing build-depends, I'm working them out one by one
<Hobbsee> ah
<geser> norsetto: have you checked if perhaps a rebuild fixes it?
<alex-weej> i want to get the notification-daemon package out of RCS, make some changes, and get the changes back into Ubuntu. how do i do that?
<norsetto> geser: yes, thats what I'm doing right now
<alex-weej> anyone?
<alex-weej> i've never been able to figure this out :/
<norsetto> so I'm getting the same build errors as debian #424445
<ubotu> Debian bug 424445 in turkey "turkey - FTBFS: /build/user/turkey-1.34.0/build.xml:28: Compile failed; see the compiler error output for details." [Serious,Open]  http://bugs.debian.org/424445
<encompass> can someone tell the poor noob how to easily translate utc time?
<encompass> I want to take part in this edubuntu meeting
<encompass> (at 20:00 UTC)
<coNP> encompass: where do you live?
<encompass> Finland
<coNP> @now Helsinki
<ubotu> Current time in Europe/Helsinki: August 01 2007, 19:05:47 - Next meeting: Edubuntu in 3 hours 54 minutes
<encompass> gmt +3 I think
<ion_> encompass: TZ=UTC date
<coNP> encompass: look what I asked from ubotu
<encompass> spiffy
<encompass> dang 10 pm tongiht... will lets hope this new father can do it :S
<encompass> thanks coNP that helps me alot
<coNP> your welcome, encompass
<coNP> s/r/ are/
* pitti files a couple of ebox bugs for soren to enjoy
<iwj> pitti: Would you care to look at my MIR for consolekit ?
<iwj> I wasn't able to derootify it unfortunately; it's full of ioctl(..,VT_...)
<iwj> (which give EPERM if not root)
<pitti> iwj: yeah, I was planning to have a look at that beast anyway (if keescook has some time to give it a quick review, that'd be much appreciated, too)
<iwj> OK.  I've been moderately deeply into the code since I had to add a new dbus message.
<iwj> Not pleasant but I think I can now say that the risk to the system as a whole isn't too great :-).
<iwj> keescook: ^
<pitti> I probably won't manage it any more today, though
<iwj> Right.
* _wattazoum_ is away: Away
<alex-weej> mvo__: talk here instead, OT for #gnome-hackers :P
<alex-weej> you made some changes to notification-daemon recently to fix the crash
<pitti> ogra: can I remind you of the two tribe-4 LTSP bugs? are they on your radar?
<mvo__> alex-weej: yes - and now the background color for the notification is no longer correct
<alex-weej> mvo__: i just tried to figure it out
<alex-weej> but i can't
<alex-weej> i've fixed up my gtkrc
<alex-weej> so that normal tooltips are the right colour
<alex-weej> (and it's on launchpad already)#
<mvo__> alex-weej: what bugnumber?
<alex-weej> but notification-daemon still doesn't use the right colour
<alex-weej> https://bugs.launchpad.net/bugs/129699
<ubotu> Launchpad bug 129699 in ubuntulooks "New style tooltips are not themed correctly due to name change" [High,Triaged] 
<alex-weej> but even so, i can't figure out why it's not working
<alex-weej> also, the code you changed (or at least what i think you changed) was copied elsewhere in the same C file
<alex-weej> in the countdown_expose_cb function
<alex-weej> (god knows why)
<alex-weej> (we need to switch to cairo there anyway)
<mvo__> alex-weej: hrm, copied code == bad code. I have  a look
<alex-weej> mvo__: :)
<alex-weej> i don't like the hack we're using to get the tooltip colour - is there no nicer way to do it? would it not be nicer if the bubble was an actual, bona fide, GtkWidget?
<keescook> iwj: I can try to take a look at it today
<iwj> Thanks.
<mvo__> alex-weej: when I last looked into this (a while ago) there was no official way to get the GtkStyle for a noticiation, it would be really cool if that would be possible
<iwj> I may be out - dinner date in a bit :-) - but do let me know what you think.  I'd be happy to answer any questions.
<alex-weej> mvo__: i guess that's an upstream task. for now, the hack will do :P
<mvo__> alex-weej: I at least fixed the duplication now (I really hope it was not me who did that in the first place, but I think it was not me :)
<alex-weej> haha
<alex-weej> right
<LaserJock> cjwatson: did you get my ping about debian-cd?
<alex-weej> mvo__: there was one more thing... Gossip's notifications don't work with the ubuntu theme, but they do with the standard theme...
<alex-weej> mvo__: they sort of flash up the shape, but disappear straight away and just dirty whatever was underneath
<mvo__> oh, hrm
<alex-weej> ah i know whyy
<mvo__> alex-weej: anything on the terminal when that happens? when you run notification-daemon ?
<alex-weej> because it has the countdown
<alex-weej> and you never fixed the countdown_expose_cb function
<alex-weej> mvo__: i can't force this one, have to wait for someone to log on LOL
<alex-weej> that's the only difference though, it has the pie chart + buttons
<alex-weej> and given that the pie chart drawing stuff still had the old code, i'll bet that's it
<alex-weej> actually, if you're familiar with the code and you have a couple of minutes
<alex-weej> the new cairo drawing stuff is in the standard theme
<alex-weej> i'd guess it's a copy paste job
<mvo__> alex-weej: *cough* ok
<alex-weej> because the pie chart is drawn pretty poorly with the ubuntu one
<alex-weej> but that's if you're not too busy :P
<alex-weej> i was gonna give it a go myself but i'm not too confident yet
<mvo__> alex-weej: I wouldn't mind a helping hand with it :)
<alex-weej> how?
<mvo__> alex-weej: a patch that fixes the pi thing would be great
<cjwatson> LaserJock: yeah, noted, remind me if I haven't replied to your mail by this time tomorrow
<LaserJock> cjwatson: ok, thanks, I don't mean to rush but I'd like to know when I can start testing as we need to get feedback
<lamont`> Riddell: is there any hope that kde will break the source packages up into something more sanely-sized?
<infinity> lamont`: You're talking about the same people who feel it's good practice to concatenate all their source before compiling, for better optimisation and OOMing compilers.
<lamont`> infinity: I'll refrain from making comments about the mental state that could possibly indicate
<mvo__> alex-weej: otherwise it will give it a go myself
<lamont`> infinity: but do they remember to use -pipe for that big runtime performance boost?
* infinity smirks.
<lamont`> hrm... ECHAN
<bddebian> Heya
* pedro is away: lunch
<keescook> Mithrandir: the apparmor apache module (which is built from the source) uses apxs; I'm open to whatever you recommend for changes if this is a problem
<infinity> keescook: Why would that be a problem?
<keescook> infinity: dunno, Mithrandir had asked about it.  :)
<infinity> keescook: Only because you first mentioned it to him. :P
<infinity> keescook: (FWIW, mentioning lpia breakages to me is slightly more helpful at this stage)
<infinity> It took a libtool, apr, and apache upload, and apparmor's happy again.
<keescook> infinity: yawp, I have already redirected to you.  :)
<infinity> Well, and a dpkg fix before that.
<keescook> heh
<keescook> easy!  ;)
<infinity> Yeah, barrel of laughs. :)
<alex-weej> mvo__: pi?
<mvo__> alex-weej: the pi chart
<alex-weej> oh, pie
<alex-weej> lol
<alex-weej> pi is 3.14195....
<mvo__> heh :)
* infinity heads to bed.
<mvo__> indeed
<ion_> 
<alex-weej> :P
<Riddell> lamont`: not any any significant extent
<ion_> I seem to remember pis Unicode number.
<lamont`> Riddell: just wishing is all
<mvo__> alex-weej: I may not be able to look into it today, its already evening in my TZ already :/
<alex-weej> mvo__: i wouldn't worry about it, the gdk one works fine. i'll have a go if i'm bored this week
<infinity> mvo__: Wimp.  It's 3:30am here...
<alex-weej> mvo__: unless you're actually taking about fixing the crasher?
<alex-weej> or just porting it to cairo?
<alex-weej> *talking
<alex-weej> bah, sorry, i've been really incoherent today to everyone
* mvo__ hugs alex-weej
<mvo__> alex-weej: no, the crasher should be fixed already :)
<alex-weej> ok cool, is it in the source archives yet?
<mvo__> alex-weej: it should be (-ubuntu3 IIRC)
<mvo__> infinity: dude, go to bed
<lamont`> After installing, the following source dependencies are still unsatisfied:
<lamont`> sip4(inst 4.6-1ubuntu2 ! << wanted 4.6)
<lamont`> Source-dependencies not satisfied; skipping python-kde3
<lamont`> bad python-kde3
<lamont`> Riddell: if you haven't seen that yet... ^^
<Riddell> lamont`: yeah, that's a recent problem, it's somewhere on my todo list to look into it
<Riddell> recent-ish anyway
<lamont`> np
<lamont`> part of the joy of hppa playing catch-up is that I get to find the broken-build-dep issues that have crept in
<lamont`> the good news is that skipping python-kde3 saved about 4 hours of build-time
<Riddell> :)
* lamont` the kernel to hit the front of the queue finally
<lamont`> my mass pretend-avail didn't help anything
<ScottK> lamont`: We did do some testing and IIRC the version dependendy for python-kde3 can be relazed without harm.
<lamont`> ScottK: cool.  I don't much care atm, though. :)
<ScottK> OK
<lamont`> and even if it got uploaded right now, linux-source-2.6.22 would still be ahead of it (hence my total lack  of caring))
<Windkracht8> does anyone know who is responsible for the update-notifier project?
<evand> Windkracht8: mvo
<Windkracht8> sorry, mvo stands for?
<evand> Michael Vogt
<Windkracht8> ok, his name is in the authors file, I
<Windkracht8> 'll send him a mail about my update suggestion
<ScottK> That or you could just file a bug against the package in Launchpad.
<Windkracht8> true
<Windkracht8> ubuntu launchpad, is it part of ubuntu?
<Pici> Windkracht8: http://www.launchpad.net/ubuntu
<Pici> Windkracht8: Its another of Canonical's projects
<Windkracht8> ok, just retrieving launchpad password
<Skiessi> could someone make a OpenGL-accelerated version of that speedmine-screensaver?
<psusi> anyone familliar with lvm and its boot time pv discovery got time to chat?
<psusi> trying to figure out how to resolve the brokenness of lvm on dmraid
<tkamppeter_> Anyone here interested in testing new software?
<tkamppeter_> I have packaged CUPS 1.3.0-rc2:
<tkamppeter_> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/cupsys13/
<tkamppeter_> and we need testing results to decide whether we change to the new CUPS
<elmo> err
<elmo> "Welcome to the Ubuntu Team Wiki, a place for the Ubuntu community to discuss ideas and store team-related information."
<elmo> when did it become a 'Team wiki'?
<johanbr> tkamppeter: I'd be happy to do some testing. Getting the packages right now...
<LaserJock> elmo: probably when help.ubuntu.com/community was split off
* elmo rolls his eyes
<mdke> https://wiki.ubuntu.com/Home?action=diff&rev2=101&rev1=100
<mdke> LaserJock is right, it was probably intended to distinguish it from the documentation wiki
<mdke> we discussed the changes on the doc list; although not specifically the title
<elmo> I think the change is a little drastic, personally
<tkamppeter> johanbr: Great! Once you should test all cups functionality whether there is no regression against 1.2.x, then whether new features work (http://www.cups.org/documentation.php/whatsnew.html), and whether it works well together with hal-cups-utils and system-config-printer.
<johanbr> tkamppeter: *all* cups functionality? I'm not sure I have the time or the hardware for that. :)
<tkamppeter> johanbr, at least what you are using from CUPS, there is no one who has all printers which are listed on OpenPrinting ...
<johanbr> tkamppeter: Alright. I'll report back soon.
<johanbr> tkamppeter: snmp printer discovery and printing to lpd and ipp hosts works. system-config-printer seems to mostly work, but crashes on a very hacky custom printer queue I set up myself.
<mikmorg> What is the ubuntu way to add init.d scripts into rc?.d/ folders?
<mjg59> update-rc.d
<mikmorg> ah, thanks!
<tkamppeter> johanbr, please file a bug against system-config-printer and tell, step by step what you entered to make s-c-p crashing. Thanks. If your crash triggers apport (crash pop-up window) follow the steps of apport and enter what you did in the bugs report which gets generated.
<johanbr> tkamppeter: Alright, that'll have to be later, have to go now. It was hardly an extensive test but cups 1.3 seems to work for me, anyway...
<tkamppeter> johanbr, the CUPS which I have uploaded is a lemon, it does not see all PPDs. I will upload a new version (same file names, same place) soon, with this problem fixed.
<TheInfinity> hello ... is it intention that nfs volumes are mountet after nfs volumes via fstab?
<TheInfinity> argh
<TheInfinity> local volumes after nfs volumes
<TheInfinity> because its impossible with this default setting to mount anything in /home for example when home is an extra partition
<phroom> I've build a fairly large project from source that I'd like to keep track of when I "make install". I've used checkinstall to create a debian package for this purpose but files in the resulting package conflict with a number of other packages on my system. I've looked around for a good strategy for removing potential conflicts from packages but nothing has come up. Any suggestions would be appreciated.
<ScottK> Don't use checkinstall would be the first one.
<prisca> some help starting kde4?
<prisca> I did everthing in the instructions but still can't start kde4
<phroom> ScottK: checkinstall does seem a bit like a hack, but I'm a packaging noob and it seems like the easiest way to keep track of what I've installed
<prisca> looked at .xsession-errors but not sure what i'm looking for
<ogra> prisca, #kubuntu ?
<prisca> yes
<prisca> wrong channel right?
<ScottK> phroom: For assistance with how to package stuff, #ubuntu-motu is a better channel.
<ogra> i mean: this is not a suport channel, did you try in #kubuntu
<ogra> right :)
<phroom> thx
<prisca> yeah they sent me here
<prisca> is there a channel for kde?
<pygi> #kde ?
<Riddell> kubuntu developers are in a meeting, wait half an hour
<TheInfinity> hmm. any information about the network fs mounting before lokal fs?
<TheInfinity> the debian guys say that it should be the other way round ...
#ubuntu-devel 2007-08-02
<mikmorg> Could someone tell me how I can assure my script runs before X starts, when I put it in init.d?
<mikmorg> I can't tell where X starts...
<mikmorg> oooh, nevermind.. i just noticed rcS.d
<yexiaodou> hello guys. Does anyone know how to fix the bug regarding the limitations of maximum number of partitions on Feisty (currently 15) ?
<ion_> How many partition do you need? :-)
<pygi> ion_, 31+1 :)
<Riddell> infinity: I just accepted the binary that libcaptury is dep-wait on, will it automatically re-try itself some point soon?
<Kmos> bug 129828
<ubotu> Launchpad bug 129828 in Ubuntu "[Gutsy]  creating initrd image fails with "invalid option -- c"" [Undecided,New]  https://launchpad.net/bugs/129828
<Kmos> this is a mkinitramfs bug, right ?
<Kmos> kmos@bash:~$ apt-cache search mkinitrd.yaird
<Kmos> yaird - Yet Another mkInitRD
<crimsun> assign it to yaird
<Kmos> yeah
<Kmos> thx
<Kmos> bug 128439
<ubotu> Launchpad bug 128439 in Ubuntu "depmod segfault" [Undecided,New]  https://launchpad.net/bugs/128439
<Kmos> this is depmod, nothing to do with kernel or sudo
<Kmos> i'll ask him to try depmod -a without sudo
<crimsun> that would fail
<crimsun> if he can run depmod through gdb, that _may_ help in debugging
<Kmos> :)
<Kmos> bug 129840
<ubotu> Launchpad bug 129840 in autoinstall "Installation of Ubuntu 7.04 failed " [Undecided,New]  https://launchpad.net/bugs/129840
<Kmos> this one is a bug from debian-installer ?
<Kmos> or kernel
<crimsun> the former
<Kmos> ?
<crimsun> debian-installer.
<Kmos> :)
<Kmos> thx
<crimsun> I'm not entirely convinced the user didn't screw something up, but we'll give him the benefit of the doubt.
<Kmos> yeah
<Kmos> I can ask him if the do anything after the installation
<Kmos> *he
<Kmos> "You do anything after the installation ? or just install and it didn't work after that ? Thanks"
<Kmos> i think it's good this way
<crimsun> it's probably more useful to query which installation method he chose
<crimsun> further, which boot loader install option was chosen, etc.
<Kmos> crimsun: he says "alternate"
<crimsun> Kmos: I mean whether he chose any additional "expert" ones.
<Kmos> ah ok =)
<Kmos> done
<avb> hello
<avb> guys, can someody tell me what is a difference of configuration of a gnome-sccreensaver on livecd and oninstalled system?
<avb> i just copied livecd system to mine harddrive, coz installator was broken
<avb> everything is fine, except that i can't lock screen
<Chipzz> crimsun: I realise jono  said Kmos should ask on #ubuntu-devel, but what he's doing is basically bug-triaging... wouldn't he be better off on #ubuntu-bugs for that?
<avb> i dont think that this is a bug. just because of nonstandrart install
<ScottK> IIRC jono said that and then changed his mind after, but didn't say where.
<crimsun> Chipzz: yes.  the channel and topic are obscured in this client.
<mjg59> Oops. I've lost backscroll.
<mjg59> Does anyone have the URL that calc gave me a couple of days ago?
<kylem> lastlog calc
<kylem> bleh.
<kylem> 20070731.log:05:30 < calc> mjg59: http://cheney.ws/debug/vbetool.debug.output.bz2 <- what i have so far, i'll try ctrl-alt-del without sync mount
<mjg59> kylem: There should be one after that
<mjg59> Though might be the same url
<mjg59> Oh, no, that looks like it
<kylem> 20070731.log:06:03 < calc> mjg59: i replaced the file on my server with the compressed 678MB one
<mjg59> Wow. Compressed well.
<mjg59> (~100 times)
<mjg59> Also looping
<mjg59> calc: Looks like I could probably do with a dump of your video BIOS
<mjg59> Oh, wait a second
<mjg59> PE is set, but JP is jumping
<mjg59> Uh. Rather, the parity flag is even, but JP is jumping.
<tkamppeter> Ghostscript 8.60 FINAL is out, get it here:
<tkamppeter> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/ghostscript/
<calc> mjg59: back
<mjg59> calc: Just trying to find documentation for how this damned instruction is supposed to behave
<calc> mjg59: ok
<calc> mjg59: if you need a dump i can get it to you if you tell me how to do it :)
<mjg59> Ah. Intel manual.
<infinity> Riddell: Yes.
<mjg59> calc: Hm. I'm probably going to need you to do a test in 32-bit mode
<calc> mjg59: ok no problem
<calc> i'll go get my tribe3 i386 disk
<mjg59> calc: You'll need to grab http://www.codon.org.uk/~mjg59/tmp/libx86-1_0.99-1.2debug1_i386.deb
<mjg59> Install that, switch to a terminal, do sudo vbetool post 2>vbetool.output
<calc> mjg59: i built it myself and got the log, about to compress and upload it now
<calc> mjg59: gar it logged 0 bytes again
<calc> mjg59: i'll try it again and see if i can convince it to write out to disk
<mjg59> calc: ?
<calc> mjg59: how much log do you need? if i mount it sync it will definitely write some out but not 600MB+ amount
<mjg59> calc: That's a different package to the one I gave you last time
<calc> mjg59: oh ok
<calc> i'll try it out and get back to you asap, probably 5-10min
<mjg59> Ok
<calc> mjg59: ok got it, very short
<calc> Calling INT 0x15 (F000:F859) EAX is 0x10005F36
<calc> Calling INT 0x15 (F000:F859) EAX is 0x5F34
<calc> Calling INT 0x15 (F000:F859) EAX is 0x5F35
<calc> there should be CR's before EAX on each line
<calc> irssi strips them for some reason
<mjg59> calc: Thanks
<mjg59> That's really helpful
<calc> great :)
<mjg59> calc: Ok. Final thing - could you do
<mjg59> dd if=/dev/mem of=/tmp/foo bs=1k skip=960 count=64
<mjg59> And stick /tmp/foo somewhere?
<mjg59> That's an image of your system BIOS
<calc> is that safe to do from a feisty boot (i'm guessing yes)
<mjg59> Yeah
<mjg59> Needs to be done as root
<calc> ok done
<calc> http://cheney.ws/debug/bios.dump
<mjg59> Can you do the same with skip=768 rather than skip=960?
<mjg59> That'll be the video bios
<calc> oh oops i removed the other one and uploaded the video bios as bios.dump also
<mjg59> That's ok
<calc> ok they are both up now as system.bios.dump and video.bios.dump
<pitti> Good morning
<ajmitch> morning pitti
<ajmitch> you're up & about early
<StevenK> Morning pitti
<pitti> ajmitch: my usual time in summer
<pitti> hey StevenK
* ajmitch would love to have summer :)
<Burgundavia> hey pitti
<StevenK> pitti: I note *-386-di and two -generic-di things have hit NBS. debian-installer built so I'm unsure why that is. Would you mind explaining it?
<pitti> hi Burgundavia
<pitti> StevenK: that's strange
<StevenK> pitti: That's what I thought.
<pitti> StevenK: reload, please *shrug*
<pitti> doko: https://launchpad.net/ubuntu/+source/sip4-qt3/4.6-1ubuntu3 \o/
<StevenK> pitti: Thanks.
<StevenK> infinity: Am I able to borrow some time of yours now?
<StevenK> pitti: Hopefully I can beat pdftk into building sometime today, which will get libgcj7 out.
<pitti> StevenK: that'll still need an OO.o ppc build, right?
<StevenK> pitti: What's irritating me with pdftk is that isn't the code that's broken, but the build system.
<pitti> StevenK: I need infinity, too! we must fix hal in buildds! he's mine, mine, mine!!!11!!
* pitti hugs StevenK 
<StevenK> pitti: I saw him first! I'll fight you for him. :-P
<StevenK> pitti: Do we care about OO.o being uninstallable on ppc? I daresay we can ask calc when he's next wanting to upload OO.o
<pitti> StevenK: I don't care on mine, OO.o is way too slow to be useful on a G4 800 MHz :)
<StevenK> pitti: But it breaks ubuntu-desktop installability on powerpc
<pitti> infinity: btw, Debian bug 435510 might be relevant here, but I doubt that hald is already running on the buildds?
<ubotu> Debian bug 435510 in hal "Please permit installation in chroots" [Minor,Open]  http://bugs.debian.org/435510
<pitti> StevenK: oh, poing
<pitti> StevenK: point, even
* StevenK pedals faster. C'mon pdftk, finish building
<pitti> infinity: then again, I can successfully install hal in a feisty chroot with the outside hal running; so maybe the buildd chroots don't have /sys?
<StevenK> pitti: Does it fail with /sys not mounted?
<pitti> meh, now the init script just hangs eternally
<pitti> StevenK: no, it works here without /sys
<pitti> bah, I guess I'll just fix it 'blindly'
<pitti> infinity: TBH I think that policy-rc.d is the answer here...
<infinity> pitti: Is this failing on buildds as a build-dep, on livefs builds...?
<pitti> infinity: buildds
<pitti> http://launchpadlibrarian.net/8633317/buildlog_ubuntu-gutsy-i386.nautilus-cd-burner_2.19.6-0ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> pitti: If I use a policy-rc.d, I'd be curious if any packages start failing because they depend on a running daemon as a build-dep...
<infinity> pitti: I, personally, don't think that should ever be done, but who knows if it is...
<pitti> infinity: I actually thought by just 101'ing hal
<pitti> we can add more stuff to it if we need to later
<pitti> infinity: the more expensive way is to find out why it actually fails
<infinity> That might not be that much effort. :)
<pitti> infinity: that'd require going into a buildd chroot and doing 'hald --verbose=yes --daemon==no'
<infinity> Let me unpack a chroot on a buildd.
<pitti> infinity: I assume there is no 'outside' hal?
<infinity> I sincerely hope not.
<infinity> Anyhow, setting up a buildd environment now.
<infinity> pitti: Why does this build-dep on runtime stuff like hal and initramfs-tools anyway?
<infinity> pitti: That's kinda sketchy.
<pitti> infinity: it is indeed, but hard to avoid
<infinity> That would be the gnome-mount build-dep, I guess...
<pitti> right
<infinity> But, why is that needed?
<pitti> I asked seb, and he only needs the .pc file inside
<pitti> I'm not sure why, gnome-mount doesn't export any .so or .h
* infinity scratches his head...
<infinity> This init script sucks.
<infinity> root@vernadsky:~# /etc/init.d/hal start * Starting Hardware abstraction layer hald                                                         root@vernadsky:~# echo $?
<infinity> 1
<infinity> Why doesn't it output a failure on failure? :P
<pitti> I had the same on my first try in my feisty chroot
<pitti> but the second time it just hung eternally
<infinity> *** [DIE]  osspec.c:watch_fdi_files():349 : Unable to initialize inotify: Function not implemented
<infinity> There you go.  No inotify in the buildd kernels.
<pitti> hrmpf
<infinity> And hald really refuses to start because of that?  Can it not function at all without it?
<infinity> Surely, it still contains some static data and other useful stuff, regardless of polling being broken...
* infinity shrugs.
<pitti> I'll have a look
<infinity> So, wait, all these hideous runtime build-deps are pulled in for the sake of a single .pc file?
<infinity> Ngh.
<pitti> I'm still not convinced that it is necessary at all
<infinity> I'd lean pretty heavily to "no, it almost certainly can't be".
<pitti> it's the only reverse build dep at least
* pitti tries what happens without it
<pitti> infinity: I guess it uses it for build-time detection of whether or not to build gnome-mount support
<infinity> pitti: Since we know we want gnome-mount support, surely that can be hardcoded.
<pitti> right
<infinity> pitti: Just like you don't need to build-dep on random binaries just to tell autoconf where they are (pre-seeding, FTW)
<infinity> pitti: Anyhow, I'm down with whatever the "best" solution is, I just like to keep the magic in the buildd chroots to a minimum, so the environment is as easily reproducible as possible for devs.
<infinity> pitti: It was one of the arguments for ditching gcc-opt and ccache.
<pitti> infinity: if it's just the inotify thing, then hal can certainly be taught not to die on that
<pitti> better than chroot hacks, I agree
<Fujitsu> Why are mangled kernels used? Surely that makes them particularly unreproducable?
<infinity> Fujitsu: We use distro sources, but compile our own kernels.  Even if we didn't, though, the buildds run dapper, so it wouldn't be the same as an end-user machine running a gutsy kernel.
<pitti> bryce: still awake?
<pitti> bryce: is xserver-xorg-video-amd particularly nasty? or can we just add it to -all and move it to main?
<StevenK> infinity: I'm guessing dapper with hacked sbuild and co for the build environments, so it can build gutsy and such?
<pitti> infinity: hm, even if explicitly given --enable-gnome-mount it checks for it *grumpf*
* StevenK runs through the rest of pdftk build by hand, sobbing.
<infinity> StevenK: We don't use a distro copy of sbuild.
<infinity> StevenK: Not even close.
<infinity> pitti: autoconf?
<infinity> pitti: Preseed the variable on the command line with ac_whatever=/usr/bin/gnome-mount
<pitti> infinity: yeah, I'll hit it over the head, I think
<pitti> if test "$ENABLE_GNOME_MOUNT" = "yes"; then
<pitti>         PKG_CHECK_MODULES(GNOME_MOUNT, gnome-mount >= 0.4,
<pitti>                 [ AC_DEFINE(USE_GNOME_MOUNT, 1, [defined if using gnome-mount] )
<pitti>                   msg_gnome_mount="yes"] ,
<pitti>                 [ USE_GNOME_MOUNT=""] )
<StevenK> infinity: I figured.
<infinity> Oh, bleh.  That's broken autotools usage, IMO.
<infinity> Anything that doesn't allow preseeding should die in the face.
<StevenK> infinity: Still no time for libnss-db?
<infinity> StevenK: Making time shortly for that and openssl.
<StevenK> infinity: Okay, way cool.
* StevenK will be out driving home in roughly 30 minutes, but I can wait back if need be.
<pitti>         gnome-mount support:      yes
<pitti> \o/
<pitti> hi carlos
<carlos> pitti: hi!
<infinity> StevenK: Surely you have some sort of internet access at home? :P
<tepsipakki> pitti: actually, x-x-v-amd is now in debian too, with a maintainer
<StevenK> Some sort, yes. :-)
<pitti> tepsipakki: right, Martin-Eric just asked me about it (and I sponsored the uploads)
<tepsipakki> pitti: yes, same guy :)
<pitti> tepsipakki: it'd support the ThinCan thin client, so maybe ogra would be happy, too :)
<tepsipakki> I bet
<pitti> hi thekorn
<thekorn> hey pitti
<\sh> moins
<pitti> hey \sh
<bryce> heya pitti, just checking in on my way to bed
<pitti> bryce: ok, nevermind, it's not that urgent; sleep well!
<bryce> re the -amd package, yes I think it'd be fine to move into main
<bryce> I've been working with Q-FUNK on it, and it's close to getting a release with a real version number soonish
<pitti> cool, thanks
<pitti> bryce: I'm Q-FUNK's Debian sponsor for it and he just asked me about it
* pitti jumps aside due to Hobbsee's sudden appearing
<pitti> carlos: can I get a gutsy base export soon?
<Q-FUNK> bryce: ?
<pitti> Q-FUNK: just went to bed
<Q-FUNK> ah
<pitti> <bryce> re the -amd package, yes I think it'd be fine to move into main
<pitti> <-- hunger hat sich getrennt (Read error: 113 (No route to host))
<pitti> <bryce> I've been working with Q-FUNK on it, and it's close to getting a release with a real version number soonish
<pitti> Q-FUNK: ^ FYI
<Hobbsee> pitti!
* Hobbsee hugs pitti 
* Hobbsee watches the cloud of smoke vanish
* pitti hugs Hobbsee back
<Hobbsee> :)
<carlos> pitti: sure, I'm going to change the export script to generate one today
<pitti> carlos: thnaks
* pitti hugs seb128 
* seb128 hugs pitti
<pitti> seb128: so, I talked about the hal thing with infinity, and I think the easiest solution is http://people.ubuntu.com/~pitti/tmp/n-c-b.debdiff; WDYT?
<pitti> seb128: hal fails on the buildds because their kernels do not have inotify support; that could be fixed in hal, of course, but with some effort
<Q-FUNK> pitti: right. you had questions about the upcoming release?
<pitti> Q-FUNK: you mean xserver 1.4?
<seb128> pitti: looks fine to me
<carlos> pitti: you should have it later today
<pitti> seb128: ok, uploading
<seb128> pitti: thanks ;)
<Q-FUNK> pitti: of -amd, as mentionned by bryce
<pitti> Q-FUNK: ah; no, no particular questions
<carlos> seb128: which package should I look at for problems with the laptop backlight? gnome-power-manager?
<carlos> seb128: btw... hi :-P
<seb128> hey carlos, yes might be it
<seb128> or linux-source
<Q-FUNK> alright then :)
<carlos> seb128: the main problem is with GNOME's window that shows you how you move it up/down
<seb128> gnome-power-manager then most likely
<carlos> ok
<carlos> thanks
<pitti> seb128: do you have a dapper vmware image or installation?
<seb128> pitti: no
* Hobbsee throws live spiders at mvo in greeting
<mvo> pitti: I should have one, do you need one?
<seb128> I might have an installation still on a partition on my desktop
<seb128> I can reboot and have a look if you want
* mvo gives a friendly wave to Hobbsee
<seb128> morning mvo
<Hobbsee> mvo: :)
<pitti> mvo, seb128: I prepared new dapper langpacks (complete refreshment of -base, too) for dapper.2 and need some initial testers
* StevenK kicks off the n+i+eth build of pdftk
<StevenK> Oooooh, dapper.2
<StevenK> I like the sound of that.
<mvo> morning seb128
<seb128> pitti: URL?
<pitti> still scp'ing
<mvo> pitti: let me know what needs to be tested, I have booted it now
<pitti> seb128, mvo: basically, install the German and French langpacks (the current dapper ones) for now
<pitti> then, "deb http://people.ubuntu.com/~pitti/tmp/dapper-langpack/ ./" and dist-upgrade, when I give the mark (still scp'ing)
* seb128 should install vmware
<pitti> seb128, mvo: ok, deb source is ready
<pitti> soren: ebox-openvpn has this in the postinst:
<pitti> +               update-rc.d -f quagga remove
<pitti> soren: that's nasty and a no-no
<pitti> soren: (1) it doesn't even restore the symlinks again on removal, (2) it won't help, since the next install/upgrade of quagga will create them again, and (3) it destroys user configuration
<soren> pitti: Alright.
<pitti> soren: ah, good mornign
<soren> pitti: Yes, that too. :)
<pitti> (I just mailed you, for the records)
<infinity> Ooo, mail me too!  I feel left out.
<pitti> infinity: aren't you on u-archive@? :)
<infinity> Oh, then I guess you did mail me too. :P
<pitti> yep
<infinity> Though not really in that "I was thinking of you" sort of way.
<soren> pitti: If it restored the symlinks on removal, would it be fine?
<infinity> soren: Touching configuration for other packages is never fine.
<infinity> soren: Why does it need to do that?
<pitti> soren: no, see points 2 and 3
<infinity> soren: (Also, removing all the links means update-rc.d will restore them the next time quagga is upgraded)
<pitti> ^ (point 2)
<soren> infinity: You're asking why a system management framework would want to manage the system?
<pitti> soren: that doesn't exclude each other from what I can see?
<pitti> soren: if quagga does bad things in the default install, we should fix that
<soren> I think - for now - I'll just try and yank out the quagga stuff.
<pitti> soren: what's the particular reason you want to do that in the first place?
* infinity always gets a bit frightened by point-and-click BGP anyway...
<infinity> This is how entire continents get routed through random people's laptops by accident.
<pitti> 'BGP' (sorry for outing me as a routing noob)
<infinity> (True story, witnessed when I worked at PSInet, a UUnet engineer made a bit of an oops)
<pitti> ?
<soren> pitti: I'm not entirely sure. It seems even more weird that it's in the openvpn module rather than the network module.
<infinity> pitti: Border Gateway Protocol, used to advertise routes to peers.
<infinity> pitti: Large carriers tend to trust their peers implicitely... Until they do something really stupid.
<soren> Ah... It's because it supports advertising new routes to the vpn clients.
<mvo> pitti: install looks good, anything paricular you want to see tested?
<infinity> (We were by-handing our routing to UUnet for a week after that incident, until they assured us the engineer in question had been appropriately flogged)
<pitti> mvo: I tested the German ones here, too
<pitti> mvo: oh, just general 'oops, this app isn't translated any more' oddities
<infinity> pitti: Don't you debdiff the dapper.1 and dapper.2 debs to make sure they don't drop any po files?
<infinity> pitti: (re: 'oops, this app isn't translated any more' oddities)
<soren> infinity: Since you seem to know a bit about this.. In order for the new route advertisement to the clients to be useful at all, the clients will need to be running quagga too, won't they? (or another ripd)
<pitti> infinity: the old -base and -updates ones are merged into new -base and empty -update, so it's not that simple, but I'll still do it for some languages
<infinity> soren: Yeah.
<infinity> soren: Most little home DSL routers and such support RIP for that very reason, I believe.
<soren> infinity: Huh? I can push new routes to people's DSL routers?
<infinity> soren: It's also possible we're talking about PPP style VPN, which might be using quagga in more interestingly bizarre ways, I don't really know.
<infinity> soren: You can if they have it enabled with lousy blacklisting, sure.
<soren> blimey
<infinity> soren: (By default, those home routers won't accept routing updates over the public interface)
<soren> infinity: So they implemented rip in them, so average home users can send new routes to the it via rip?
<soren> infinity: That sounds like something that people are going to use a lot... er, no wait..
<infinity> soren: So home users can get RIP updates over VPN tunnels.
<infinity> soren: It's also handy if you have two or more of the little home routers, and just set-and-forget RIP on all of them.  Then you can set up your routing table once, and it Just Works.  In theory.
<soren> infinity: The RIP updates would be inside the vpn tunnel, surely? Why does the router need to worry about that?
<infinity> soren: I'm referring to routers that support VPNs, in this case, so the whole network has VPN access, not a single tunneled host.
<soren> "10:17 < infinity> soren: Most little home DSL routers and such support RIP for that very  reason, I believe.
<soren> I find that most litte home DSL routers don't know how to terminate a VPN connection.
<infinity> Yeah, "that reason" being "because they also support VPNs" :)
<infinity> All of mine do.
<soren> What sort of vpn can they terminate?
<infinity> But, yeah, the "multiple crap routers in a home" argument is the other reason they support RIP.
<infinity> Oh, hah, the one I'm using right now can't.  Bah.
<infinity> The one in the corner that's not on does PPTP and some random IPsec type things.
<infinity> (Using this one instead because it does VoIP)
<StevenK> Most home/SoHo type routers speak a subset of IPSec
<infinity> Also, I have too many of these devices...
<StevenK> Most won't handle special things like DPD (Dead Peer Detection), or NAT-T (NAT Traversal)
<soren> I don't remember seeing a single on that does that. If it does it's packed away in an impossible to find spot in the config ui.
<infinity> Note that different countries see wildly different types of these devices.
<infinity> Australia seems to have a host of needlessly complex ADSL routers.
<soren> Sure, my wrt54g does it, but that's because I'm running openwrt on it.
<infinity> Heck, I never even owned such a device before I moved here.
* StevenK currently has a dumb ADSL modem and a firewall with PPPoE
<StevenK> I ought to set up QoS one of these days.
<infinity> Yeah, which is the setup I prefer, and how I did it in Canada.
<infinity> But finding dumb modems here is harder than just getting cheap routers.
<StevenK> Most cheap routers can be configured into bridge mode.
<infinity> So I have a stack of routers. :)
<infinity> Yeah, but if you're buying the thing anyway, may as well use it, I guess.
<StevenK> If it's bridges, you're still using it. :-)
<StevenK> Er, s/it's/it/
<infinity> I think the only time I've ever bridged mine was when the ISP told me my unsupported hardware was clearly the cause of their inability to terminate PPPoA correctly.
<infinity> So I bridged it, terminated it on my laptop, said "see, still doesn't work", and that was that.
<StevenK> Hah
<infinity> Still, I look forward to returning to the land of "PPPoWhat?" some day soon.
<infinity> Never had to deal with DSL/Cable auth until I moved here either.
* StevenK still wishes he could find a two-three script that limits his outbound bandwidth so that the ADSL modem doesn't queue cells and get it wrong.
<infinity> "Why do I need a username and password?  Are you afraid someone else is tapping my copper?"
<StevenK> infinity: Depending on the situation, ADSL gets terminated by Hellstra and hands off authentication to different ISPs via realms so they can account traffic usage.
<infinity> pitti: Oh, hah. Funny story.  I'm not on ubuntu-archive anymore got bounced off.  Hilarious, since I'm one of the admins.
<infinity> I love mailman.
* infinity readds himself.
<StevenK> infinity: Since Telstra has basically told the Government, "You can have the local-loop when you pry it out of our backrupt fingers."
<StevenK> bankrupt, sigh
<infinity> StevenK: Yeah, I know why it happens, it's just annoying.
<infinity> StevenK: But iiNet has no such excsuse, either.  They own the DSLAM and bloody well know it's my port, so using PPPoX is just force of habit, and wasted overhead.
<infinity> StevenK: Which irks me.
<StevenK> Heh, yes.
* StevenK don't trust iiNet, having a workmate as an ex-iiNet person
<infinity> StevenK: Works well enough for me.  *shrug*
<infinity> StevenK: Better than the resold Telstra lines I've had in the past.
* StevenK is currently on one of them.
<seb128> pitti: looks like the update removes some translations
<seb128> -gconf-editor.mo
<seb128> -gdebi.mo
<seb128> -gnome-cups-manager.mo
<seb128> -gnome-desktop-2.0.mo
<seb128> -gnome-keyring.mo
<seb128> -gnome-menus.mo
<infinity> I had Telstra just randomly decide to cut my line and give it to someone else.  That was the last straw for me.
<seb128> -gnome-nettool.mo
<StevenK> I'm seriously considering jumping to Exetel's ADSL2+, but they're non-telephone line is rented from Powertel, and they're on the brink of getting bought out ...
<seb128> -gnome-system-monitor.mo
<seb128> -gnome-system-tools.mo
<infinity> The usual "But it didn't have a dialtone!" idiocy.
<seb128> -gnome-volume-manager.mo
<seb128> pitti: my script might be buggy though
<Burgundavia> get a real country with real internet you two ;P
<infinity> Burgundavia: I come from one.  Yours, even.
<infinity> Burgundavia: I grew up in Calgary, home of "we've had cable since 1995", feel my pain.
<StevenK> infinity: Hah. At my last job, I was a sysadmin for a small ISP. They cut all 60 of our ISDN lines due to that excuse.
<Hobbsee> Burgundavia: give us tickets out, and we'll come...
<pitti> seb128: NB that the update packages are empty now, everything should be in -basea
<pitti> seb128: s/a$//
<Burgundavia> Hobbsee: infinity left us
<StevenK> infinity: "They're ISDN, they aren't *supposed* to have a dial tone, you berk."
<Hobbsee> Burgundavia: well, us born in au, anyway
<StevenK> infinity: They dared to touch our 2Mbit frame relay. Once. That months bill was somehow waived. :-)
<infinity> 2Mbit.  How cute!
* infinity misses working for PSInet...
<infinity> We lived in an apartment building two blocks over and just kinda.  Uhm.  *cough*... Pulled Cat-5 with repeaters.
<Amaranth> Come to the US, you get fast internet and no caps in exchange for AT&T snooping all your traffic
<infinity> It was one of those "boy, we're glad management isn't smart enough to ask why there's a 4-port switch hanging off a port on the Juniper" moments.
<StevenK> infinity: Bwahaha
<StevenK> infinity: 2Mbit supporting about 3,000 customers. Not all at once, of course
<infinity> Ouch.
<StevenK> ... dial up customers. :-)
<infinity> I don't understand your terminology, and I refuse to acknowlege your statement.
<StevenK> Muahah
<infinity> Seriously, I've not had dialup since 1995...
<StevenK> infinity: In other news, any about openssl and friends?
<infinity> Oh, and about a week in Cairns.
<infinity> That was not a good week.
<StevenK> Of course not, you were in Cairns.
<infinity> Sort of landed, said "what, you don't have DSL?  This won't do" and fixed that in a hurry.
<infinity> StevenK: No news is good news, I hear.
<StevenK> Apparently. I remain unconvinced.
* StevenK runs off for some food.
<StevenK> And damn it, pdftk, you better have built sucessfully by the time I get back!
<saispo> hi all
<saispo> anyone maintain packages.ubuntu.com here ?
<soren> I'm having a problem with some gconfd-2 processes that won't die... If I strace it and send it a SIGTERM, strace doesn't even show that the process receives the signal. What could possibly cause this?
<soren> Even if the signal handler is SIG_IGN, strace still shows that the process receives it..
<soren> Ah, if it's masked, perhaps..
<seb128> Riddell: libcaptury-dev has no .so, any reason or that's an error?
<Riddell> seb128: sounds like an error
<seb128> I've accepted the binaries, please change it though ;)
<Riddell> seb128: thanks
<infinity> seb128: I prefer to reject broken lib-dev packages on the grounds that other packages may be dep-waiting on them, and then we'll get a bunch of build failures and give-backs cascading from the accepted broken binaries.
<seb128> infinity: rejecting binary upload is weird though, you get the source in the archive but no binary
<infinity> (dep-waits are autocleared when the packages get published to the archive)
<infinity> seb128: Nothing wrong with source and no binary.  *shrug*
<seb128> but you have a point
<infinity> seb128: Anyhow, since you and pitti seem to be doing most of the ftpmaster grunt work these days, I won't presume to tell you how to do your job.
<infinity> seb128: Just a friendly "this is what I do" thing. :)
<seb128> infinity: thanks ;)
<infinity> Mithrandir: Do you have enough screen sessions idling on drescher? :P
<tepsipakki> when will flashplugin-nonfree get released to feisty-security?
<tepsipakki> it's been in -proposed for over two weeks now
<pitti> tepsipakki: it's in updates already, isn't it?
<tepsipakki> doesn't appear to be
* tepsipakki goes and checks again..
<pitti> flashplugin-nonfree | 9.0.48.0.0ubuntu1~7.04.1 | feisty-updates/multiverse | source, i386
<tepsipakki> right
<tepsipakki> that's not added on installation
<pitti> that would be a bug
<tepsipakki> same for universe
<tepsipakki> hmm, I'll check a more recent installation..
<tepsipakki> yep, same there
<tepsipakki> if gutsy has it too, I'll fix it there
<pitti> tepsipakki: but -security is enabled for universe/multiverse?
<tepsipakki> yes
<pitti> hm, so we should copy that to -security, too, I think
<pitti> tepsipakki: done
<tepsipakki> pitti: whoa, thanks
<pitti> tepsipakki: but please file a grave bug against, erm, the installer? about -updates for universe/multiverse
<tepsipakki> I'll add an entry for the -updates locally (in sources.list.d)
<tepsipakki> yes, it's in apt-setup
<tepsipakki> deb $protocol://$hostname$directory $codename-updates $dists
<tepsipakki> dists="$dists restricted"
<tepsipakki> is universe/multiverse now always enabled?
<pitti> tepsipakki: I don't think so, but there should be a comment for it
<tepsipakki> hmm, I'll take this to #ubuntu-install :)
<pitti> tepsipakki: i. e. when someone uncomments universe, he should immediately stumble upon uncommenting -updates/-security for it, too
<tepsipakki> seems that universe/multiverse are indeed enabled since feisty
<tepsipakki> I can only blame myself, since I added the support for u/m -security, should've done -updates too :)
<pitti> ah, heh :)
<tepsipakki> shame on me
<pitti> hey tkamppeter
<tkamppeter> hi pitti
<pitti> tkamppeter: I had an idea this morning
<pitti> tkamppeter: I'm currently working on an apparmor profile for cups, and I got pretty far already
<pitti> tkamppeter: if we get that working and shipped by default, I'm fine with dropping the derooting patches
<tkamppeter> pitti, do you mean replacing non-root mode of CUPS by AppArmor protection?
<pitti> I currently have a cupsd running as root, yes
<pitti> profile more or less works, I'm currently fine-tuning it
<tkamppeter> A 1.3.x cupsd?
<pitti> tkamppeter: no, the current 1.2.12 one
<tkamppeter> pitti, which kind of protection actions AppArmor does exactly apply to CUPS with your profile?
<pitti> tkamppeter: unfortunately it is much less protection than what we currently have with the unprivileged system user, but it's still fairly good
<pitti> tkamppeter: http://people.ubuntu.com/~pitti/tmp/usr.sbin.cupsd  my current version
<pitti> tkamppeter: removing some important capabilities like NET_ADMIN or SYS_ADMIN, and FCHMOD/FSUID is already helping a lot
<pitti> tkamppeter: and confining fs access to the minimum
<tkamppeter> pitti, important is also not to over-protect, as on the CUPS mailing list one saw a lot of complaints from Red Hat users as Red Hat introduced SELinux and most were caused by the SELinux protection.
<pitti> tkamppeter: I'm sure that the current profile breaks some stuff, like cups-pdf
<pitti> tkamppeter: those backends need separate profiles with elevated privileges, like writing into user's homes
<pitti> tkamppeter: but *shrug*, it's easy to fix stuff like that with a profile
<pitti> tkamppeter: if upstream stays so absolutely unwilling to even recognize the need to confine it, that's the best we can do, I'm afraid
<tkamppeter> I see your profile now and is seems that it simply gives certain file access permissions to /usr/bin/cupsd
<pitti> tkamppeter: that, permissions to subprocesses, and capability confinement
<tkamppeter> What do the letters m and i in the permissions mean? rwx is clear for me.
<pitti> tkamppeter: 'm' -> mmap (in plain English: load a shared library, mostly)
<pitti> tkamppeter: 'ix' -> allow execution and inherit parent process privileges
<pitti> tkamppeter: there's also 'px' (allow execution and use a separate profile for the proces), and 'ux' (unconfined execution)
<tkamppeter> and "rm"? Is CUPS allowed to "rm /etc/group"?
<pitti> tkamppeter: no, that's 'r'ead and 'm'map
<pitti> mmap is probably not required for those files, but it doesn't hurt either
<tkamppeter> But why m for /etc/group? /etc/group is not a shared library.
<pitti> see my previous sentence
<pitti> I'll remove it, for cleanliness
<tkamppeter> Will AppArmor block actions not explicitly permitted by the profile or can you choose between blocking and warning, like you can do with Red Hat's SELinux?
<pitti> tkamppeter: you can choose
<pitti> tkamppeter: I developed the profile in 'complain' mode
<pitti> tkamppeter: my initial upload will be 'complain' and call for testing (and sending me the logs)
<pitti> tkamppeter: a bit later, when I got more testing, I'll flip the default to enforce, I think
<pitti> I do not plan to regress the default install security that much
<pitti> tkamppeter: so, WDYT about the plan?
<tkamppeter> pitti, I think this is great. The new CUPS has so many new authentication and network features which make the non-root patches arbitrarily complicated. And with AppArmor one drops the patches and the admin can easily configure the extra security by the profile.
<tkamppeter> And if a user complains that something goes wrong one does not open the CUPS completely but only changes a line in the profile and the problem gets fixed.
<pitti> (or flip the profile to complain)
<TheInfinity> hello ... i have a strange thing here which might be a bug ... upstart mixes the mount order - nfs volumes are mountet after local volumes altough it is the other way round in fstab
<TheInfinity> is it really a bug or is there somehow a reason for this?
<pitti> tkamppeter: "sudo aa-complain cupsd" btw
<pitti> tkamppeter: and 'aa-enforce cupsd' to enable it again
<cjwatson> TheInfinity: nothing to do with upstart - there are separate init scripts to mount local and network filesystems and they're explicitly ordered that way
<cjwatson> TheInfinity: this is necessary because local filesystems (e.g. /usr) might well be needed to bring up networking
<cjwatson> TheInfinity: we're not in a position yet (perhaps upstart will eventually let us be in such a position) to have the kind of flexibility to mount some network filesystems first if the network is available
<cjwatson> TheInfinity: I suggest not attempting to rely on having network filesystems mounted first
<TheInfinity> argh sorry wrong description ... first the nfs filesystem is mountet, then the /home FS
<TheInfinity> and thats my problem.
<cjwatson> that IS odd
<TheInfinity> http://www.ubuntuusers.de/paste/13354/?format=txt <-- this is the order
<TheInfinity> and i dont know why. it seems that /home is in rc5 "misc mounts" - which is quite strange
<TheInfinity> because if i mount with rc.local it works
<TheInfinity> should i report it as bug? or any suggestions where this problem comes from?
<cjwatson> TheInfinity: (rc5 isn't used by default; our default runlevel is 2)
<cjwatson> I have no scripts that call mount in rc2 here
<cjwatson> bizarre that you have /var/run and /var/lock mounted multiple times
<cjwatson> do you have any custom init scripts?
<TheInfinity> no
<TheInfinity> its a default 6.10 installation dist-upgraded to 7.04
<tkamppeter> pitti, nice, so we can perhaps have these two called by buttons in some admin GUI tool.
<cjwatson> TheInfinity: /home should be mounted from /etc/rcS.d/S35mountall.sh
<cjwatson> also is the ordering as visible in /proc/mounts actually causing a problem?
<TheInfinity> i use kubuntu as clients - so theres nothing i changed except installation of a few user apps and using somehow network data
<TheInfinity> yes because i want to mount the nfs volume in /home
<TheInfinity> and that does not work because /home is mountet after the nfs volume
<TheInfinity> hmm. strange at all ...
<pitti> tkamppeter: yay, it actually works reasonably now, and it just took two tiny patches to make cups work without DAC_OVERRIDE
<tkamppeter_> pitti, What is DAC_OVERRIDE?
<pitti> tkamppeter: man capabilities; in short, it allows a process to ignore any fs permissions
<pitti> tkamppeter_: i. e. read and write any file in the system
<pitti> tkamppeter_: i. e. as root you can edit a file which is  till:lpadmin 644
<pitti> tkamppeter_: this capability gives you full root power, so for any sensible privilege reduction this must be forbidden
<seb128> iwj: did you upload a gdm built with consolekit? There is no sign of it, maybe it did conflict with the new version which has been uploaded this week?
<cjwatson> seb128: looks like it clashed, yes
<cjwatson> 20:15:09 DEBUG   gdm_2.19.4-0ubuntu4.dsc: Version older than that in the archive. 2.19.4-0ubuntu4 <= 2.19.5-0ubuntu1
<seb128> cjwatson: ah, thanks. What log has upload errors?
<iwj> seb128: Ah, yes, I have a mail about a reject.
<iwj> I'll fix it up,.
<seb128> iwj: thanks
<seb128> I would have done it but I'm not sure if you just changed the configure option or if you did also some other changes
<cjwatson> seb128: /var/mail/lp_archive
<cjwatson> "log"
<iwj> There are other changes too.  I'll merge them.
<seb128> cjwatson: ok ;)
<StevenK> pitti: I have bent pdftk to my will, and uploaded it. Leaving openoffice.org on ppc as the last remaining rdepends on libgcj7
<pitti> StevenK: yay, thanks
<Tonio_> Mithrandir: I saw you uploaded bluez-libs last version, will you upload bluez-utils soon ?
<pygi> hey Hobbsee
<Hobbsee> hiya pygi
<geser> Hey Hobbsee
<Hobbsee> greetings, geser :)
<Kmos> https://wiki.ubuntu.com/UbuntuBugDay/20070801 -> this still valid for action? =)
<seb128> Kmos: bugs can be triaged any day
<Kmos> bug 127203
<ubotu> Launchpad bug 127203 in Ubuntu "After installation AVG anti-virus problems with louding up-dates" [Undecided,New]  https://launchpad.net/bugs/127203
<Kmos> we don't support AVG, so it must be invalid ?
<seb128> Kmos: I would use the standard reply for "not enough details"
<Kmos> seb128: ok
<seb128> like from where he installed AVG, what update issues he has, etc
<seb128> if that doesn't come from ubuntu the bug can be marked Invalid
<Kmos> yep
<pygi> seb128, I don't think we have avg in ubuntu repos?
<Kmos> i asked now if it's reproducible and the steps to get there
<Kmos> pygi: no, we don't
<seb128> pygi: I don't know what AVG is and what the guy is speaking about
<pygi> seb128, antivirus
<seb128> pygi: if you know that's something we don't ship feel free to close the bug
<pygi> seb128, ok, will do
<Seveas> isn't it in -commercial?
<Kmos> Seveas: nop
<Kmos> http://archive.canonical.com/pool/main/a/
<Kmos> only arkeia
<Kmos> :)
<pygi> Seveas, nop, isn't there
<pygi> Kmos, I'll close the bug as invalid
<Kmos> pygi: ok
<pygi> done
<stgraber> hi
<pygi> hey stgraber :)
<Kmos> can I request sync of treil ? http://packages.qa.debian.org/t/treil.html
<pygi> Kmos, sure, but would you be willing to learn a procedure how to request sync?
<Kmos> pygi: i already know that :)
<Kmos> requestsync is my friend also
<Kmos> i'm building it on pbuilder first :)
<pygi> Kmos, ok, so you know that you have  to check changelog of both ubuntu and debian package, see if ubuntu has any changes from debian, evaluate if they can be dropped, and all the other procedures mentioned at https://wiki.ubuntu.com/SyncRequestProcess ?
<Kmos> pygi: yep
<Kmos> treil has the first sync for gutsy
<Kmos> but it's out-of-date
<pygi> if you follow all procedures, you should be fine ;)
<TheMuso> Also be careful to ensure that the MD5Sum of both orig tarballs are the same, fi they are both the same upstream versino.
<Kmos> TheMuso: oki =)
<Kmos> it compiles fine on pbuilder for gutsy
<cjwatson> the other point is to check up on why it's needed
<pygi> cjwatson, +1
<geser> Kmos: re bug #129572: is it worth to sync powertop just to remove someone from uploaders?
<ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129572
<cjwatson> "is newer" isn't usually sufficient reason to spend the time bothering; there should be something useful in it
<pygi> i.e. bugfixes
<cjwatson> note that we will mass-sync everything after gutsy+1 opens; we've stopped the auto-sync so that things can settle down a bit
<cjwatson> pygi: we're before upstream version freeze, so interesting features are fine too
<Kmos> cjwatson: new upstream release ? and some bugs fixed.. like in ruby/triel.rb
<pygi> cjwatson, got it, but this is a game =)
* pygi thinks at least
<seb128> Does anybody know if there is a naming convention for package shipping pam modules? The new gnome-keyring has one, I'm wondering if the package should name gnome-keyring-pam or libpam-gnome-keyring
<cjwatson> Kmos: that seems to be the case for treil, but not powertop
<soren> seb128: libpam-foo
<cjwatson> so my point is just that it's something you should think about
<cjwatson> if we wanted to mass-sync everything from Debian that was newer, we could still do so :-)
<Kmos> cjwatson: ah powertop.. i understand now :)
<cjwatson> (without needing somebody to go through them all laboriously by hand)
<seb128> soren: thanks
<soren> seb128: np
<xxxxx1> hey Hobbsee :)
<Hobbsee> hiya xxxxx1
<Kmos> cjwatson: u're right :) i've invalid it myself with comment
<Kmos> bug 129547
<ubotu> Launchpad bug 129547 in workman "Please sync workman (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129547
<Kmos> this one can be invalided too.. only changed to the new menu system
<Kmos> that will be auto-synced in gutsy+1
<Kmos> right?
<geser> everything without Ubuntu changes will be auto-synced at the begin of the next dev cycle
<Hobbsee> geser: are you busy now?
<geser> it depends :) what work want you to delegate to me?
<coNP> Kmos: I guess this bug does not requires instant decision. There is a sync bug filed, someone will take care of it.
<Hobbsee> geser: reduce https://bugs.launchpad.net/~ubuntu-universe-sponsors
<geser> Hobbsee: already started looking on it
<Hobbsee> geser: i'm presuming one can ignore all of Kmos' bugs that are incomplete.  or at least, be very careful with them.
<Hobbsee> geser: great :)
<Kmos> Hobbsee: they all build fine :)
<Hobbsee> Kmos: yes, i'm more wondering over the "is there any point to them" question - like the drop in uploaders, or the standards change, etc.
<TheMuso> Kmos: But as previously discussed, its more than just making sure they build. I just pointed out that you should test build them as a first check point before filing a sync request.
* Hobbsee grabs the flashplugin-nonfree
<Kmos> TheMuso: yep..
<Kmos> Hobbsee: i'm killing the ones that are pointless.
<Tonio_> Hobbsee: did you notice than nspluginviewer crashes for a few weeks now ?
<Hobbsee> Tonio_: have not tried it.  but i've seen teh bugs
<Hobbsee> Kmos: great
<geser> should accepted sync request still be set to "confirmed" or now to "Triaged"?
<StevenK> geser: Former
<Hobbsee> geser: TheMuso ScottK StevenK and anyone else who works on these, if you could mention that you're locking the merges in here (or -motu i guess), so we dont try to upload the same things while we're all working on the queue, that'd be good
<cjwatson> Kmos: it's definitely best not to do a half-hearted job of switching to the new menu layout, and given that it doesn't actually much matter for Ubuntu (we use .desktop files instead), I don't propose to spend any time converting main
<Kmos> cjwatson: yeah, that's why i killed powertop and workman sync requests
<Kmos> -2 to check :)
<Hobbsee> woo!
<Kmos> bug 129544
<Kmos> i think this one can be killed too. but not 100% sure
<Kmos> [14:02]  <ubotu> Error: Could not parse data returned by Launchpad: The read operation timed out
<Kmos> bug 129544
<ubotu> Launchpad bug 129544 in xmms-midi "Please sync xmms-midi (universe) from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/129544
<Kmos> ah :)
<Hobbsee> Kmos: clean target might be the only vaguely useful thing there.  unsure too
<Kmos> yeah.. i see only that one
<Kmos> others are pointless
<Kmos> any preview of updated langpacks for gutsy ?
<pygi> Kmos, here:
<pygi> http://people.ubuntu.com/~pitti/langpacks/
<Kmos> thx
<pitti> pygi: that's obsolete
* Fujitsu thought it was done in PPA now.
<pitti> pygi: updated gutsy langpacks are uploaded straight to gutsy itself
<pygi> pitti, my apologies then.
<pitti> Riddell: just curious, what's wrong with qt 3.3.8?
<Zapek> when one fixes a (non reported) bug through bzr push sftp. do I have to create a launchpad bug entry about it or it will be seen?
<cjwatson> it won't typically be seen automatically
<cjwatson> report it
<Riddell> pitti: it broke chinese and other complex characters
<Riddell> pitti: not sure why though, other distros seem to be ok, it's something I need to look more at
<iwj> seb128: My gdm test build worked so I've uploaded.  Hopefully it won't clash again.
<seb128> iwj: could thanks, should be fine this time I didn't touch gdm since tuesday
<seb128> s/could/cool
<iwj> *snort*
<iwj> You're too dynamic :-).
<seb128> ;)
<Kmos> pitti: requestsync when has apt working (locked) says it doesn't have the package on gutsy =)
<Kmos> to use -n :)
<pitti> Kmos: hm, it uses rmadison, so that would be curious
<pitti> Kmos: it doesn't touch apt at all
<StevenK> Right, I fixed that.
<Kmos> pitti: apt-get rmadison =)
<Kmos> still apt
<Kmos> right ?
<coNP> Kmos: apt-cache rmadison
<Kmos> :)
<Kmos> i've only apt-get running with update-manager
<Kmos> and it says that
<Kmos> after i do apt-get update
<Kmos> and it's when I see it's locked
<pitti> kylem: is it actually necessary to update the kernel and both X video drivers for bug 123879? I just copied mesa to -updates
<ubotu> Launchpad bug 123879 in xserver-xorg-video-intel "[SRU]  feisty missing support for intel graphics hardware" [High,Fix released]  https://launchpad.net/bugs/123879
<pitti> Kmos: no, not apt. rmadison
<kylem> pitti, yes, the kernel bits are already done though.
<pitti> Kmos: seems like you are on feisty?
<pitti> hi mathiaz
<Kmos> pitti: i tested that on my laptop with gutsy
<pitti> coNP: apt-cache madison != rmadison
<mathiaz> hi pitti
<coNP> oh, I am sorry
<pitti> coNP: rmadison queries a CGI script on somewhere.ubuntu.com
<pitti> coNP: NP :)
<StevenK> Kmos, coNP: Actually, no. It's 'apt-get madison' which uses your local cache, requestsync uses rmadison which queries a script on people.ubuntu.com
<Kmos> :-)
* StevenK high fives pitti
<pitti> mathiaz: today I learned to love apparmor :) (see my cups mail)
<Kmos> StevenK: *g*
<mathiaz> pitti: great... more love comes to apparmor every day :)
<coNP> -EINVALIDOPERATION
<pitti> mathiaz: the profile probably needs some love, though, and I found a bug in the standard perl #include
<coNP> Oh I overlooked the last part.
<pitti> kylem: ok, so I'll remove the verification-done tag again for the other tasks
<kylem> ok.
<StevenK> pitti: In other news, it looks like I've run out of NBS stuff to do ... :-)
<pitti> \o/
<StevenK> pitti: python-xen-3.1 is handled, libsilc-1.0-2 is due to silky using the old API and I don't care enough to fix it, and all of libatlas-cpp-0.6-0c2a, libcal3d11c2a and liberis-1.3-11 are waiting on a new sear.
<Hobbsee> was anyone dealing with mail-notification?  i remember hearing talk about it
<Kmos> Hobbsee: how about to ask to remove package rt2400 on gutsy? now it's included in the kernel..
<Kmos> so after gutsy, no more rt2400
<Kmos> and less confusion with debian sync..
<Hobbsee> Kmos: no idea about kernel stuff.  i try to avoid it
<Kmos> zul says it's included now in kernel
<Kmos> in gutsy
<Hobbsee> then it should be fine to remove.
<StevenK> Kmos: Perhaps the rt2400 package contains a newer version than the one in the kernel?
<Hobbsee> pitti: when we ask for removals, do you auto-blacklist, or do we need to ask for blacklisting as well?
<zul> StevenK: if you can send me the fix for python-xen3.1 that would be cool
<StevenK> Kmos: So please check that first.
<Kmos> StevenK: so that's a question for kernel team
<pitti> Hobbsee: I'll check and blacklist if necessary
<StevenK> Kmos: Right. Ask them before dealing with the removal bug.
<Kmos> StevenK: ok
<Hobbsee> pitti: ah, great.  i dont suppose you could approve phpunit into feisty-proposed?  it's been sitting there since sunday
<Hobbsee> StevenK: zul is a kernel guy, btw...
<StevenK> zul: Did you also want me to deal with pitti's grievances?
<pitti> Hobbsee: tomorrow, when I'll have my next regular SRU shift
<zul> StevenK: I got half of them done so far
<StevenK> Hobbsee: Didn't know that.
<Hobbsee> pitti: ah great, that works.
<Hobbsee> soren: ^
<Hobbsee> StevenK: he's one of the xen guys
<pitti> I'd rather get those #$(*#$ dapper langpacks fixed now
<soren> Hobbsee: Saw it :)
<StevenK> zul: I can deal with the rest as well as python-xen-3.1 if you wish.
<Hobbsee> pitti: good luck with them :)
<StevenK> Hobbsee: Knew that, didn't know he was kernel
<zul> StevenK: no thats ok I been working on it for a while now I just need help with the python bits
<ogra> doko, did you have a look at jintys schooltool packages already ?
<Hobbsee> StevenK: well, i'm assuming xen and stuff is kernel too
<StevenK> Hobbsee: Xen is both.
<StevenK> Xen has userspace bits hanging out, too
<ogra> doko, i testbuilt them but apparently they still want python 2.4
<StevenK> zul: Is your packaging in bzr?
<ogra> no matter what version i set in debian/control
<Hobbsee> StevenK: there you go then.  enough of kernel to qualify as a kernel guy :)
<StevenK> Hobbsee: :-)
<zul> StevenK:  it hasnt been updated in a bit I can put the latest debian/ directory up somewhere
<doko> ogra: go ahead and upload
<ogra> doko, i need them in main ... 2.4 is in universe. no ?
<doko> ogra: no, and you should just use the default python version. and please fix all bugs you'll inroduce with zope 3.4alpha
<StevenK> zul: I'm happy to branch your bzr off and make my own and point you at it.
<zul> StevenK: Im at work right now and the bzr stuff is out of date right now
<StevenK> zul: Well, happy to send you a diff, if you like.
<zul> StevenK: please
<pitti> carlos: urgent ping
<pitti> carlos: the dapper rosetta export is incomplete
<carlos> pitti: urgent pong!
<carlos> is it?
<StevenK> infinity: I'm guessing the time for libnss-db and openssl came and went all by itself?
<pitti> carlos: most of the German files seem to be ok, but french is missing 20 files
<pitti> carlos: http://people.ubuntu.com/~seb128/language
<carlos> pitti: are we talking about the full export?
<pitti> carlos: yes
<carlos> hmm, how's that possible?...
* carlos checks
<pitti> carlos: I just tar tzf'ed the original tarball, they are not there (so not a problem with my scripts)
<pitti> carlos: search for the French gdebi.po as an example
<carlos> ok
<pitti> carlos: thanks
<carlos> pitti: confirmed, there are some files missing...
<carlos> pitti: oh, found the problem
<carlos> pitti: do you have time for a new full export?
<pitti> carlos: yes, that's ok (and anything else would be too hackish)
<seb128> carlos: what is the problem? just curious
<pitti> carlos: if you could start it by this evening, so that I'll have a tarball tomorrow morning, we should be good
<carlos> seb128: a bug in our export code related to launchpad accounts deactivated
<carlos> seb128: they don't have an email address anymore, and thus, the export fail
<seb128> ah ok
<seb128> good that we caught the issue before upload
<carlos> seb128: indeed
<carlos> pitti: I need to wait for the gutsy export finish
<carlos> after that, I will do the dapper one (although I'm not sure whether i will have time before the db refresh starts...
<geser> mvo: can you fix bug #123131 in your next compizconfig-settings-manager upload? it's the missing python-gtk2 dependency.
<pitti> carlos: ok, thanks; do you think that's manageable by tomorrow?
<Amaranth> uh oh, ubotu lag
<Hobbsee> ubotu: ping
<carlos> pitti: I think so, let me see how gutsy export goes...
<carlos> pitti: It only exported 1/4  of the .po files for gutsy...
<ubotu> Launchpad bug 123131 in compizconfig-settings-manager "ccsm crashed with ImportError in <module>()" [Medium,Triaged]  https://launchpad.net/bugs/123131
<carlos> pitti: let's see how it goes later tonight
<ubotu> pong
<pitti> carlos: ok; I can probably do some bits on Saturday morning, too, if needed
<carlos> pitti: well, in worse case, you would get it Friday evening
<pitti> carlos: ah, ok; that sounds good
<mvo> geser: thanks, doing that now in my bzr repo
<pitti> mathiaz: why does aa-unconfinded have so many duplicate lines? does that have any meaning?
<Hobbsee> seb128: being a desktop person, could you look at https://bugs.launchpad.net/ubuntu/+source/gnome-art/+bug/60258 at some point?  i dont have the expertise to figure the best solution.
<ubotu> Launchpad bug 60258 in gnome-art "Ruby crashes while using gnome-art-manager" [Medium,Incomplete] 
<seb128> Hobbsee: hum, why do you think it's a priority?
<Hobbsee> seb128: i tried to use a "at some point" - i'm not sure what you want done to request a "can you look at this at some point?"  it's not a priority
<seb128> Hobbsee: or rather "any reason you ping me on IRC about a bug assigned to me where I commented less than a week ago"? ;)
<Hobbsee> seb128: bugger, i didnt read the dates on there.  apologies :(
<seb128> Hobbsee: no problem, I was just wondering if there was  special reason for the ping, it's on my list but after some other things I want to get done for next tribe ;
<seb128> ;)
<desrt> seb128; i filed this bug 1 day and 12 seconds ago about the latest versions of gnome not being packaged and they're STILL not packaged!
<ubotu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]  https://launchpad.net/bugs/1
<Hobbsee> seb128: ah, no problem.  it was a general ping about it.  i thought your comments were from months ago, as there were many comments after.
<StevenK> Hah
<seb128> desrt: lying, take a penalty card
<StevenK> Go, ubotu go
<seb128> desrt: it is packaged ;)
<desrt> win :)
* desrt should actually upgrade to gutsy one of these days so that he can pretend to care :)
<mathiaz> pitti: it seems that it's to support different cases.
<Hobbsee> desrt: we could just mark you with the invalid stick, or something :P
<mathiaz> pitti: but I agree that it needs to cleaned up.
<mathiaz> pitti: It's not the latest version from upstream.
<pitti> 6411 /usr/sbin/avahi-daemon not confined
<pitti> 6411 /usr/sbin/avahi-daemon not confined
<pitti> 6501 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'
<pitti> 6501 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'
<seb128> desrt: do you use anything from the stock GNOME anyway?
<pitti> mathiaz: ^ I don't see any difference there
<desrt> seb128; almost all of it
<pitti> mathiaz: avahi has two threads (the other one is pid 6412), so that could be it
<mathiaz> pitti: well - it's says if it's confined or not.
<pitti> mathiaz: but cupsd is only one thread
<seb128> desrt: because between your gdm hacked for smooth transition, your new panel and applet, dconf, etc ... ;)
<pitti> mathiaz: right, but why twice?
<seb128> desrt: we should name GNOME 3 DNOME
<desrt> seb128; i'm a l33t platform hax0r now.  git masters (or svn trunk) of glib, cairo, pango, dvalue, dconf, gtk :p
<mathiaz> pitti: ah. hum - don't know.
<pitti> mathiaz: just cosmetical anyway, I was just curious what it means
<mathiaz> pitti: the script is a bit old - it may be fixed upstream.
<desrt> seb128; all my apps are more or less stock
<Riddell> Mithrandir: could you give back libcaptury in feisty-backports?
<desrt> seb128; btw: gnome 3 is proceeding as planned :)
<pitti> mathiaz: ok, thanks
<StevenK> Riddell: I think Mithrandir is on VAC
<seb128> desrt: well, one looking at your screen could have the feeling that you don't use many desktop applications
<pitti> mathiaz: http://people.ubuntu.com/~pitti/tmp/usr.sbin.cupsd is my first profile, btw \o/ I hope I didn't screw it up too much (it still needs some love, though)
<desrt> seb128; i'm a big gnome-terminal user.....
<seb128> desrt: you usually have some form of small panel, an IM client and a command line
<seb128> ha ha
<desrt> gnome 3 = telepathy, gvfs, dconf, all the love gtk has been getting recently, etc
<mathiaz> pitti: I'll have a look at it.
<mathiaz> pitti: did you put the profile in the cups package ?
<pitti> mathiaz: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024027.html
<pitti> mathiaz: why, do you rather want to keep it in -profiles?
<pitti> mathiaz: my plan is to ship gutsy with an enforced profile, so with -profiles in universe that would be kind of hard
<mathiaz> pitti: the current plan is to ship profiles in -profiles
<pitti> mathiaz: that's why I put it there
<mathiaz> pitti: but if the package maintainer wants to ship a profile in the package that's fine also
<mathiaz> pitti: that's what suse is doing.
<tepsipakki> desrt: dconf? can't find anything on that
<pitti> mathiaz: ah, ok; should it be any problem for you, then we can still change it
<mathiaz> pitti: they were shipping all profiles in -profiles and they've moved the profiles into each package.
<desrt> tepsipakki; it's this secret project being hacked on by some madman
<mathiaz> pitti: it just requires more work from the maintainer.
<pitti> mathiaz: eventually this shuold happen in Debian/Ubuntu, too, but while the profiles are still under heavy development, it's easier to group them
<tepsipakki> desrt: sounds promising :P
<mathiaz> pitti: but shipping in the profile is fine by me.
<mathiaz> pitti: we support both scenario.
<pitti> mathiaz: ok, great
<mathiaz> pitti: I guess it'll be on a per-package basis.
<mathiaz> pitti: may be we could ship profiles that have been well tested in the package.
<mathiaz> pitti: and others in -profiles.
<pitti> mathiaz: I agree
<mathiaz> pitti: if I want to add a general hook in apport, does it have to be a python script ?
<pitti> mathiaz: yes, it has to ATM
<mathiaz> pitti: ok. Thanks.
<mathiaz> pitti: I'm trying to run apport-cli on a server - and it fails with :" No module named xdg.DesktopEntry"
<mathiaz> pitti: I guess that apport.ui needs more tweaking for a server environment.
<pitti> mathiaz: ah, can you please file a bug about this?
<pitti> mathiaz: I don't want to depend on the xdg python module, it should quietly forego those tests instead
<pitti> anyway, time to leave for today (grandma's bday)
<pitti> cu tomorrow!
<mathiaz> pitti: yes. I will.
<Riddell> infinity: could you give back libcaptury in feisty-backports?
<Riddell> oh actually it's needs building, so that should be fine
<infinity> Riddell: If it's being auto-given-back, that could be problematic...
<infinity> Oh, no, it's never failed in the first place.
<infinity> What made you think it needed giving back? :)
<Riddell> impatience problably, ignore me :)
<Kmos> asac: backport of thunderbird from gutsy to feisty not possible, right ?
<Kmos> bug 129968
<ubotu> Launchpad bug 129968 in thunderbird "Outdated Mozilla Thunderbird in Add Programs" [Undecided,New]  https://launchpad.net/bugs/129968
<infinity> That's not a bug, it's a feature.
<seb128> doko: can you give a retry to gcin on powerpc i386 sparc?
<seb128> or infinity ;)
<infinity> seb128: I'll do it.
<ScottK> Kmos: There's already a backports request in for it.  More testing needs to be done.
<ScottK> See you all later.
<seb128> infinity: thanks
<Kmos> i've marked it as duplicate
<Kmos> infinity: hehe
<asac> Kmos: well ... not possible is not right
<asac> Kmos: but not trivial either
<Kmos> asac: yeah
<Kmos> i've duplicated the bug, because already there is one
<asac> Kmos: if there is someone interested in backporting tbird, I would be happy to help :) ... in fact i think we already have a feisty backport in mozillateam archive.
<Kmos> it was done by gnomefreak ?
<asac> yes
<Kmos> :-)
<mikmorg> Is there a bug report for Feisty's Ubiquity auto-mounting when partitioning?
<mikmorg> cjwatson: Hello there
<johanbr> seb128: Could I ask you a quick question? Is the evince version in gutsy supposed to support fillable PDF forms? I got that impression from the evince mailing list, but it doesn't seem to work.
<coNP> johanbr: it is sure that this not listed in the evince changelog
<johanbr> coNP: Okay, thanks. I just got that impression from http://mail.gnome.org/archives/evince-list/2007-July/msg00011.html , but maybe that part of the announcement doesn't actually apply to evince 0.9.2.
<coNP> !info evince gutsy| johanbr
<ubotu> johanbr: evince: Document (postscript, pdf) viewer. In component main, is optional. Version 0.9.3-0ubuntu1 (gutsy), package size 1130 kB, installed size 5888 kB
<johanbr> That information doesn't seem to have much bearing on my question.
<coNP> Sorry, form support comes from libpoppler as the mail also says. It should be in.
<coNP> Okay, I was just not sure if we have 0.9.2 or 0.9.3 in gutsy.
<johanbr> So you mean it should work? I couldn't get it to work and nor could someone else I asked to try out. Have you tried it?
<Seveas> "Currently it requires poppler HEAD, but let's hope we'll see a new
<Seveas> release of poppler."
<coNP> Yes, that is what I am investigatint
<Seveas> so unless ubuntu compiled evince against bleeding edge poppler, no forms support
<Seveas> !search libpoppler gutsy
<ubotu> Found: gibbon, gutsy, newqueue, pidgin, ubuntu+1, gusty
<Seveas> meh
<coNP> !info poppler gutsy
<ubotu> Package poppler does not exist in gutsy
<elmo> popplar
<coNP> !info libpoppler gutsy
<ubotu> Package libpoppler does not exist in gutsy
<johanbr> !info libpoppler1 gutsy
<ubotu> libpoppler1: PDF rendering library. In component main, is optional. Version 0.5.9-0ubuntu1 (gutsy), package size 635 kB, installed size 1720 kB
<seb128> johanbr: need poppler CVS version
<johanbr> seb128: Ahhh, okay. Thank you. Is there any chance of a poppler with forms support going into gutsy?
<seb128> johanbr: depending of upstream
<seb128> if it's ready yes
<seb128> if it's not, no
<seb128> I can't speak for them
<johanbr> Where "ready" means "0.6 release", I'm guessing?
<coNP> We have 0.5.9 in gutsy now that is development version. Relased in May, though.
<johanbr> Seems like the release is being delayed due to ISP trouble: http://tsdgeos.blogspot.com/
<seb128> johanbr: no, when "ready" means "ready", like working correctly
<johanbr> Okay. Thank you.
<seb128> you're welcome
<seb128> sorry to not have extra details
<seb128> as said it's mainly a matter to see if upstream consider it stable enough to be distributed
<seb128> which also mean waiting for them to roll a new tarball
<seb128> and then we can see if they break ABI again and that sort of things
<seb128> if they roll a new one I'll try to get it in gutsy though
<LaserJock> cjwatson: poke :-)
<iwj> I don't believe this.  dpkg has no standard sll and dll manipulation macros.  What was I thinking ??
<Mertiki> does somedody have a laptop with a synaptic touchpad that can help me in confirming a bug in launchpad?
<maxb> Would anyone be able to point me toward the software that actually creates the distribution .iso images? I'd like to learn about it.
<BenC> what's easiest way to test a webcam?
<LaserJock> maxb: you might want to look at https://launchpad.net/ubuntu-cdimage
<maxb> Thanks!
<LaserJock> maxb: in particular, also look at configs/devel in the bzr branch for ubuntu-cdimage as it has links to other branches that are important
<maxb> I guess I should get around to learning bzr
<geser> is it possible to sync NEW packages from Debian after UVF and before NewPackagesUniverseFreeze?
<LaserJock> geser: I'm pretty sure that's what it means
<geser> ok, because I had the choice to sync now and file later an UVF exception for the next version or wait for the next version and sync later
<LaserJock> if you know it'll be there before the New Package freeze then that seems ok
<geser> upstream will try to get the new version out and into debian before end of the month
<Zero_> Hi, i'm fixing a bug on the installation of Ubuntu Alternate, and i wanna know if the Automatic Network Detection detected correctly the DNS
<doko> asac, seb128: how do I convince firefox/thunderbird to use normal sized fonts again? changing prefs in the applications itself doesn't change anyting
<Zero_> i know
<Zero_> go in preferences and change the font
<Zero_> it need be by prefs in the applications
<Zero_> but you need click in a botton in right to change
<tkamppeter> Yesterday I asked you all for testing CUPS 1.3.0-RC2. Now there is a better version, with nonroot stuff removed from the packaging more cleanly and the AppArmor protection introduced by pitti. Get the new packages (0ubuntu2) here:
<tkamppeter> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/cupsys13/
<mattwalston> Where is a roadmap or schedule for the next release?
<geser> !gutsy
<ubotu> Gutsy Gibbon is the code name for the next release of Ubuntu (7.10). See https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000276.html and https://wiki.ubuntu.com/GutsyReleaseSchedule - Roadmap and specifications: https://blueprints.launchpad.net/ubuntu/gutsy - Support in #ubuntu+1
<hggdh> Mertiki: what bug? I do have a laptop on Gutsy
<asac> doko: did you find a solution?
<theCore> mjg59:  ping
<mjg59> theCore: Hello
<theCore> mjg59: hi, I heard you are reviewing Automatix for the TechBoard, is that true?
<theCore> mjg59: I started since yesterday I fairly intensive review myself
<mjg59> theCore: Ok, that's good
<theCore> mjg59: so, maybe what I have found could help you
<mjg59> Sure
<theCore> would you like to read my working draft?
<mjg59> Sounds good
<theCore> honestly, I am not sure yet if I will publish it, even though I did put a lot of effort
<theCore> I will certainly have to smooth the tone of article, even if I tried to be neutral
<mjg59> theCore: It ties pretty much in with what I'd noted
<doko> asac: no
<asac> doko: so did you zoom your fonts or what?
<theCore> mjg59: do you plan to review EasyUbuntu too?
<mjg59> theCore: We hadn't been asked to, but it might be worth it
<seb128> what do you review automatix for? do you want to get it uploaded to Ubuntu?
<theCore> at least, there isn't major security concerns in it
<mjg59> seb128: No, the tech board were asked to provide feedback on the technical quality of it
<ogra>  did you find any ?
<seb128> well, the concern with it would rather be what it install and how that breaks installations
<seb128> rather than the technical quality of the thing
<mjg59> seb128: Not really, no
<mjg59> It's perfectly able to break your system all on its own
<seb128> we should just make clear to users they should not install it
<TheInfinity> seems to be impossible to get information about mounting local FS ... why does ubuntu mount local FS after network file systems (and any other FS)?
<seb128> I think pitti already made apport stop sending bugs if it has been installed
<mathiaz> seb128: yop
<ogra> seb128, did you ever read their faq ?
<seb128> ogra: no
<ogra> http://www.getautomatix.com/wiki/index.php?title=FAQ
<mvo> seb128: I think it is better to have it in the archive than outside of it
<theCore> ogra: that FAQ is certainly misleading
<mvo> same for envy, I think if it comes into the archive, we can work on it better and improve pthings
<ogra>  Does Automatix2 break Ubuntu upgrades? - "The chances of Automatix being behind the breaking of a Ubuntu upgrade is as high as the packages which Ubuntu releases for that release and the subsequent one. Most of what Automatix installs comes directly from the Ubuntu repositories and is installed using apt-get (just like in synaptic and Add/Remove). It is more likely that an upgrade problem lies upstream in the Ubuntu repositories."
<ogra> yay, its our fault
<mvo> ogra: I have seen my share of upgrade issues :)
<ogra> the next two sentences are pretty rude ...
<ogra> In fact Ubuntu has been notorious for breaking xserver packages several times on stable releases in the past. They have also been extremely notorious for passing on the blame to Automatix for their own failings (which they still haven't stopped doing).
<seb128> I read something about not listening to people who recommend not installing it
* mjg59 shrugs
<theCore> that? --- Is Automatix2 safe? Folks in #ubuntu on IRC keep telling me it isn't.   * Yes, it is perfectly safe. Thousands of users worldwide use Automatix2 every day without any issues. If you think you have run into any issues related to Automatix, please report to our forums to get quick and high quality support.
<mjg59> Worrying about what people write is fairly uninteresting
<theCore> One thing is sure, though, Automatix is truly bloated
<ogra> i'm not worried, i'm sad ... with some guidance the guys putting work inot it might be good MOTUs
<Nafallo> ogra: the first thing they need to be teached is to dput _source.changes.
<ogra> heh
<theCore> I wonder such tools are so popular
<theCore> wonder why*
<Nafallo> cause people are fucking lazy. that's why.
<stdin> becuae people are too lazy to read what the proper way is
<theCore> stdin: that is a weak argument
<Nafallo> I'm glad my ex-gf won't do it again anyway. she received a massive lecturing for about 20 minutes.
<stdin> it's true tho, they just don't read the wiki
<stdin> or even ask
<minghua> theCore: I think because automatix generally have does a good job with installing stuff those people want, and as long as upgrade is not involved, it doesn't cause much problems.
<Nafallo> stdin: not even that in many cases. they need to TRY to play an mp3 and get the nice coded-installer.
<Nafallo> codec even
<theCore> minghua: then, perhaps it would be a good time to start providing meta-packages for these peoples
<fdoving> i've noticed many reviewers mention they use automatix to get this and that.
<minghua> theCore: Not impossible for many packages.  Examples I know are Adobe acroread, Windows codecs, Real player.
<stdin> there is (k)ubuntu-restricted-extras for instance
<stdin> (for things in the repos anyway)
<mneptok> minghua: Automatix is a problem whether you dist-upgrade or not.
<minghua> theCore: We can probably try providing some installer-like package like msttfcorefonts, though.
<mc44> minghua: you mean like ubuntu-restricted-extras? :)
<minghua> mneptok: I don't use it.  I just read that many people are happy with it.
<mneptok> minghua: try the view from my chair ;)
<stdin> many people use windows, doesn't make them right :p
<theCore> minghua: hmm, the msttcorefonts package isn't enough?
<minghua> mc44: I don't exactly know what ubuntu-restricted-extras does.
<mc44> " Installing this package will pull in support for MP3 playback and decoding,
<mc44>  support for various other audio formats (gstreamer plugins), Microsoft fonts, Java runtime environment, Flash plugin, LAME (to create compressed audio files), and DVD playback."
<minghua> theCore: enough for those fonts, sure.  But not enough for people who need Adobe acroread, Real player, etc.
<theCore> realplayer is in the commercial component, no?
<minghua> Oh, that reminds me, Opera is a frequently requested package, too.
<minghua> The thing is, automatix is just convenient for many people.  And we probably should advocate/advertise ubuntu-restricted-extras more.
<stdin> opera and realplayer are in commercial
<theCore> minghua: well... I am not sure if advocating restricted plugins is a good thing
<seb128> doko: looks like no GNOME package needs to be change for lpia from a quick greping
<dobey> it's hard enough trying to get the fluendo mp3 codec package. the "you need additional non-free codecs" thing wants to install the gstreamer-ugly package. i had to go command-line apt-get install the fluendo package
<doko> seb128: please send a list to infinity
<seb128> doko: "no"
<Nafallo> dobey: sounds like a bug to me.
<doko> and mark them on the wiki
<minghua> theCore: Neither am I sure.  But a lot of people still see it essential.  If we turn them down, they all seek help from other places, like automatix.
<doko> seb128: ?
<dobey> Nafallo: bug or not, it's relevant to the issue at hand :)
<seb128> doko: there is no package that need to be changed, what do you want in the list?
<mvo> dobey: please remind me about it (fluendo mp3)
<doko> seb128: infinity needs a list of packages for manual bootstrap. that shouldn't be that difficult ...
<doko> seb128: and at least glib had to be updated
<seb128> doko: there is no DEB_HOST_ARCH or DEB_HOST_GNU_CPU to it
<seb128> so I've not looked for everything
<DaSkreech> Hello Has anyone been approached about Smolt?
<theCore> hmm... what happened to acroread in feisty?
<theCore> issues with Adobe?
<doko> seb128: still infinity needs a list, "all of gnome" is not enough
<seb128> doko: ok, will do that
<doko> thanks
<seb128> you're welcome
<seb128> DaSkreech: is that the hardware database thing?
<DaSkreech> Yes
<DaSkreech> They invited other Distro to join in so that it would be a Linux effort rather than a Fedora effort
<minghua> theCore: Removed.  Because it's not redistributable according to the new license terms.
<DaSkreech>  I'd assume that Ubuntu was one of those given consideration
<seb128> DaSkreech: not sure, maybe ask to pitti when he's around tomorrow or to mvo
<theCore> minghua: ah, I remember now
<theCore> minghua: thanks
<seb128> DaSkreech: I don't know about it
<DaSkreech> mvo: Ping
<theCore> maybe after all, the best thing to do would simply be to ignore Automatix / EasyUbuntu
<dobey> mvo: remind you?
<ogra> seb128, cr3 does the hwdb stuff now ... dunno who else
<Nafallo> dobey: about fluendo-mp3
<ogra> DaSkreech, ^^^^
<DaSkreech> ogra: ah thanks cr3 isn't around now?
<ogra> he's not regulary in -devel
<dobey> Nafallo: yes, i saw that. the question was what he means by "remind me"
<seb128> ogra: there was some specs during the Sevilla UDS where mvo and pitti spoke about it I think
<ogra> DaSkreech, i pinged him ... not sure he's around
<mvo> hello DaSkreech
<DaSkreech> ogra: Well he's online but not in any chans is that an indication that he's not AK ?
<Nafallo> dobey: to poke him about it tomorrow probably so he can fix that bug :-)
<seb128> or open a bug
<DaSkreech> mvo: Hi I was asking if you had heard of anything about smolt ?
<mvo> dobey: remind me to fix that fluendo-mp3 is not listed in the codec installer
<dobey> ok
<seb128> mvo: I think you discussed it with pitti during the Sevilla UDS so I directed him to you
<mvo> ogra: hwdb? yes, I talked about this with cr3 and pitti, there is some LP work going on there too
<ogra> mvo, any idea who is the head for it now ?
<mvo> DaSkreech: I did and I like it. the client was easy to sport to ubuntu IIRC
<mjg59> seb128: My panel seems to have stopped grouping multiple applications. Any idea if that's deliberate?
<mvo> ogra: not really, lets talk about it after the meeting
<DaSkreech> mvo: So we are interested?
<DaSkreech> What about the HWDB that Ubuntu currently has will that be moved into this new initiative?
<DaSkreech> Or is this all too early to ask? :-)
<ogra> that will rather be rewritten from scratch some day
<mvo> DaSkreech: I guess its a bit early, but I definitely feel that something better is required. and smolt looks quite good so I think we should not re-invent the wheel if we can help it
<DaSkreech> mvo: Wonderful thanks a lot
<seb128> mjg59: it used to group windows without a class and that has been fixed, otherwise it should still group application in the same class
<seb128> (libwnck change)
<mjg59> seb128: I've got a large number of gnome-terminal windows all showing up separately
<mjg59> Though I'm running panel from about a month ago
<seb128> mjg59: if you open the task lists properties, what mode is selected?
<mjg59> Ah - never group windows
<mjg59> I'm sure I didn't change that myself
<mjg59> Given I didn't know that window existed :)
<seb128> mjg59: maybe vuntz changed the default choice ;)
<mjg59> seb128: I haven't deleted my gconf settings...
<mjg59> Oh, so yeah, if I've never touched it the default would change
<seb128> mjg59: if you have never touched the option you use the system schemas value
<seb128> right
<theCore> how could I recognize a package build with checkinstall?
<theCore> ah, know. nevermind
<Kmos> http://packages.debian.org/changelogs/pool/main/g/gambas2/current/changelog
<Kmos> can I resquest a sync for gambas2 ? it has some bugs fixed
<theCore> mjg59: thanks for you feedback, btw
<theCore> your*
<mjg59> theCore: I'm just tidying up what I've got - I'll show you in a few minutes
<cr3> DaSkreech: hi, ogra tells me you want to talk about the hardware database?
<theCore> mjg59: ah, ok
<DaSkreech> cr3: hi Yes
<DaSkreech> Quick lil guy ins't he?
<DaSkreech> Ah he's back
<DaSkreech> cr3: hi Yes
<su-hoens`rZ> anyone know why the kubuntu alt cd installer doesn't locate 3 of my 4 sata drives even though the bios and the main cd find them fine? :(
<DaSkreech> cr3: Fedora invited Ubuntu to use Smolt?
<cr3> DaSkreech: sounds like a good idea, how is the HAL data transmitted to smolt?
<DaSkreech> cr3: Not sure I just hit the Linux.com article and decided to ask in #kubuntu-devel they hadn't heard of anythign so I asked in here
<DaSkreech> I'm for the move to having one HWDB for all Linuces as long as we can give in the data that Ubuntu has collected before
<DaSkreech> cr3: I'm just naively guessing that lshw should be good enough :)
<cr3> DaSkreech: I was asking more specifically about the data format used to transmit, but that's implementation detail I can gather from the source
<cr3> DaSkreech: I agree that information should be gathered in a single location, but that is difficult to enforce as can be seen with bugtracking for example: some projects use bugzilla for example, but launchpad tries to integrate that
<cr3> DaSkreech: in a similar respect, different hardware database may have different objectives so I think it's a reality that there will have to be duplicate information in order to meet each of these objectives
<cr3> DaSkreech: for example, the hardware database does not aim to strictly report hardware but also report status of the hardware by running tests. it's one thing to know you have a wireless controller, it's another to know that it works
<cr3> DaSkreech: in that sense, I see the hardware database exporting data to smolt or, the other way around, allowing smolt to query the hardware database
<DaSkreech> cr3: What would be the basis of having an aggregate database that knows wether someone's specific card is working?
<cr3> DaSkreech: let me ask you a question: have you ever wanted to buy a computer and know beforehand if the hardware worked?
<DaSkreech> I think that having a dual layer would be useful though
<DaSkreech> cr3: Yeah
<DaSkreech> That's what Live Cds are for :)
<cr3> DaSkreech: I see you've never bought online...
<DaSkreech> cr3: Yes I have but only with machines I've tested with Live CDs ....
<cr3> DaSkreech: anyways, that is ultimately the question that the hardware database will attempt to answer rather than just gathering metrics
<DaSkreech> cr3: I know I understand
* Nafallo always build custom, and buys stuff he know works.
<DaSkreech>  It will also give good stats to show case to hardware \vendors to show that they should provide support
<cr3> Nafallo: you could eventually buy stuff *others* know works :)
<ogra> Nafallo, hard to do with laptops
<Nafallo> cr3: yes. google, ubuntu wikis, maintainers etc... :-)
<Nafallo> ogra: Dell Latitude D630. only problem is sound, and that has a patch floating round.
<Nafallo> s/rou/arou/
<DaSkreech> Course there is already a KDE app that does this :(
<cr3> Nafallo: been there, done that, it's a clunky approach. for example, you might find a wiki posting about one graphics controller working on one release of ubuntu and a wireless controller on another release. it's hard to find unified information about hardware.
<Nafallo> ogra: to bad the damn Dell wanted to deliver 22nd and I'll move to England 16th :-P
<Nafallo> cr3: that's why it takes weeks indeed :-)
<cr3> Nafallo: heh, well put :)
<cr3> Nafallo: I'm dedicated to saving you and others those weeks of painful sleuthing
<Nafallo> cr3: sounds to good to be true ;-)
<cr3> Nafallo: there's a reason why such a service exists already: it's a difficult problem to solve
<DaSkreech> cr3: Woah. this will keep version info as well?
<cr3> err, doesn't exist already :)
<cr3> DaSkreech: that's critical indeed
<Nafallo> cr3: yes, I know :-)
<DaSkreech> cr3: Versions of products? Like hal or X or versions of distros ?
<cr3> DaSkreech and Nafallo: would you guys like me to contact you in case we need help, like beta testing and so forth?
<DaSkreech> cr3: Yes
<Nafallo> cr3: just put it in Ubuntu and I'll see the new package and betatest it when/if there is time :-)
<cr3> DaSkreech: release version but also package versions, which is also important to detect regressions
<cr3> DaSkreech: thanks for having taken the initiative of mentionning smolt in this channel and expressing your interesting in consolidating hardware information!
<Nafallo> cr3: is there a wikipage or something with your project? :-9
<Nafallo> :-)
<ogra> Nafallo, you could recycle the old HardwareDatabase page ;)
<cr3> Nafallo: there are a few blueprints on launchpad, let me check...
<Nafallo> ogra: not me! :-P
<Nafallo> cr3: thanks :-)
<DaSkreech> cr3: I've been loking for somethign like this since Knoware
<ogra> DaSkreech, well the first implementation of the hwdb client in ubuntu was in hoary
<DaSkreech> I know :)
<DaSkreech> It's just much more useful to have a LInux DB rather than an Ubuntu DB
<DaSkreech> http://developer.kde.org/summerofcode/knoware.html
<ogra> indeed it is
<cr3> Nafallo: this search will return most of the relevant blueprints: https://blueprints.launchpad.net/?searchtext=hwdb
<cr3> Nafallo: I am currently most active in developing the client for the release of gutsy
<DaSkreech> See if we could have smolt have a CLI core with an X front end a GTK front end and Qt front end it would easily implementable by all Distros
<DaSkreech> It could also have multiple layers with the core info going to >the< database
<Nafallo> cr3: I'll read that then. you will be using the existing package I guess?
<DaSkreech> other info that individual distros want to collect can be kept by them
<cr3> Nafallo: it's being rewritten, please don't look at the current state of the code :)
<DaSkreech> Ubuntu can still have it's Users hardware Webpage :)
<Nafallo> cr3: will not. was more about getting notification of testing in apt-listchanges ;-)
<cr3> Nafallo: oh, so I indeed intend to use the same package, but that's not confirmed yet
<Nafallo> cr3: you might want to ping me anyway then ;-)
<cr3> Nafallo: will do
<DaSkreech> Fedora is complaining that it's only used by GUI users
<DaSkreech> cr3: Watch the Smolt page?
<BenC> 21:24:44 ERROR   Exception while accepting:
<BenC>  Unable to find source package linux-source-2.6.22/2.6.22-9.22 in gutsy
<BenC>  -> http://launchpadlibrarian.net/8671171/pm6r6EGyiU4s02vU7yLeyYqsyyw.txt (Unable to find source package linux-source-2.6.22/2.6.22-9.22 in gutsy)
<BenC> anyone aware of that problem?
<su-hoens`rZ> anyone know why the kubuntu alt cd installer doesn't locate 3 of my 4 sata drives even though the bios and the main cd find them fine? :(
<cr3> DaSkreech: why is it only used by GUI users?
<Nafallo> cr3: baah. I'm not allowed to see the spec.
<DaSkreech> cr3: Thats what they are implying
<cr3> Nafallo: sorry about that :(
<Nafallo> will just need to see the client then ;-)
<cr3> Nafallo: feature freeze is in a couple weeks, so it shouldn't take too long
<Nafallo> :-)
<DaSkreech> I'll take a look at it this weekend are they still taking suggestions on framework or is that locked?
<superm1> cjwatson, i saw you assigned bug 129038 to yourself, out of curiosity, what were you planning on it?
<ubotu> Launchpad bug 129038 in lirc "lirc overwrote my lircd.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/129038
#ubuntu-devel 2007-08-03
<cjwatson> superm1: it's in the main sponsors queue
<cjwatson> superm1: I assigned it to myself for sponsorship review
<superm1> cjwatson, ah right.  Just wanted to check and see if that was why or if you had other ideas for it
<cjwatson> I don't know yet :-)
<LaserJock> hi cjwatson
<cjwatson> LaserJock: hi, you have mail ;-)
<ajmitch> morning
<cjwatson> you know, I might be able to respond to mikmorg if he didn't keep asking me questions in my evening and then quitting before I get back ... sigh
<LaserJock> heh
<LaserJock> cjwatson: so, any ETA on when the CD build machine will be back up?
<ajmitch> great, still 2 weeks until UVF
<ajmitch> a new version of f-spot came out today
<cjwatson> LaserJock: I'll get it sorted out tomorrow one way or the otherr
<cjwatson> other
<LaserJock> ok cool
<cjwatson> either by fixing mkisofs to stop segfaulting or by just downgrading it to dapper
<LaserJock> I'd just like to make sure it works before Tribe 4
<cjwatson> oh, sure
<cjwatson> I'm not going to leave CD builds broken over the weekend if I can help it
<LaserJock>   cool, thanks for doing all that
<superm1> cjwatson, is this what was breaking the ppc dailies too, or is that a sep issue?
<LaserJock> I *might* need to do one more patch to add in icons before Gutsy is released
<LaserJock> but I'm not sure at this point so I didn't want to add it in for nothing
<dobey> ajmitch: hey
<ajmitch> hello
<cjwatson> superm1: err I have no idea what was breaking the powerpc dailies; reference?
<cjwatson> as in, roughly when
<cjwatson> and which images, etc.
<superm1> cjwatson, i just tried the last 3 days images
<superm1> aug 1, july 31, july 30
<cjwatson> broken in what way?
<superm1> they boot to a busy box shell
<superm1> and sit there
<cjwatson> that's not this problem
<cjwatson> I have no idea what that is
<cjwatson> live cd?
<superm1> yes
<cjwatson> booting to a shell is usually the kernel failing to detect hardware, though it could conceivably also be initramfs-tools or casper breakage
<superm1> i just obtained a powerpc eMac for a week or two to experiment with, and ran into that imm
<superm1> i see
<cjwatson> have you got *any* Ubuntu live CD to boot on it?
<superm1> yes
<superm1> well
<superm1> with a little work yes
<superm1> xorg conf generation needs a litle work
<superm1> but after fixing the xorgconf on a live boot it boots
<superm1> i did a feisty live disk
<superm1> actually as i recall, a dist-upgrade to gutsy did the same thing
<superm1> i'll have to look more into it and file a bug yet then
<mpt> hi LaserJock
<mpt> Was my bootloader GUI feedback helpful?
<LaserJock> mpt: I think quite
<LaserJock> mpt: hopefully he can parse it all
<LaserJock> mpt: I also have a 1024X768 screen and it was fine (in fact that's what I used to take the screenshots in my blog)
<LaserJock> mpt: so I guess it must be some sort of bug
<mpt> LaserJock, one possibility that occurs to me
<mpt> Is the "Operating System List" set to scroll?
<LaserJock> mpt: not sure
<mpt> I can see about 12 items in the list, there are probably more
<LaserJock> oh geeze :-)
<cjwatson> ok, what the hell
<mpt> and if the list is set to insist on showing all of them, that might be the problem :-)
<cjwatson> mkisofs on antimony works fine if I recompile it in an edgy chroot
<cjwatson> sigh, tomorrow
<LaserJock> mpt: yep, that could be it
<calamari> hi
<calamari> I'm attempting to loop mount a fuse systems in the initramfs.  Got the fuse working, but for some reason losetup doesn't seem to work (the resulting /dev/loop0 is empty.  Any ideas?  Works okay from normal environment
<calamari> actually, maybe I'd be better off working from normal init.. nm
<ajmitch> hello Hobbsee
<Hobbsee> hi ajmitch
<mneptok> good morning campers!
* Hobbsee pokes mneptok with a pin
<bddebian> Sheesh, glad I didn't say hello :-)
* mneptok deflattusates
<ajmitch> good day mneptok
<mneptok> arr ajmitch
<bhale> hi ajmitch
<bddebian> Whoa, hey bhale
<ajmitch> hello bhale, how are you?
<bhale> whoa bddebian
<bhale> ajmitch: good, you?
<ajmitch> alright
<Hobbsee> dobey: if you dont file bugs on u-r-e, how do you expect me or someone else to find out about what other codecs people want, and add them too?
* Hobbsee failed mind-reading 101
<Hobbsee> Nafallo: irc is a dodgy bug tracker.  please use the proper one.
* Hobbsee has, incidently, done the last whole bunch of uploads for u-u-s
<TheMuso> Hobbsee: I did one a while ago.
<TheMuso> Or it maybe was two.
<Hobbsee> oh, sorry, u-r-e
<Hobbsee> TheMuso: which?
<dobey> huh?
<TheMuso> Hobbsee: nvm since you are referring to ure.
<Hobbsee> dobey: ubuntu-restricted-extras, how you're complaining that it doesnt have fluendo stuff.  please make a bug against u-r-e for that, so it gets fixed.
<dobey> i wasn't complaining that restricted-extras doesn't have fluendo stuff
<Hobbsee> s/complaining/mentioning/ :)
<Hobbsee> dobey: still, i'd appreciate if you could file said bug.
<dobey> i mentioned that the codec installer didn't list the fluendo stuff. it has nothing to do with restricted-extras to me. and i mentioned it because it was relevant to the conversation of people complaining about automatix :)
<dobey> and i never said i wouldn't file a bug
<Hobbsee> dobey: afaik, the codec installer *is* the restricted-extras.  or close to it.
<Hobbsee> dobey: i think i've seen too much of forums - they say "it'd be so cool to have this added" yet never file a bug or actually tell someone about it, usefully
<dobey> welcome to teh internets
<mneptok> it would be so cool to kck Hobbsee's ass. maybe i should start working out .... nah, i'll have some more Doritos and do it tomorrow.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mneptok was kicked off #ubuntu-devel by Hobbsee (as would it be to give mneptok a BOOT TO THE HEAD!!!)
* mode/#ubuntu-devel [-o Hobbsee]  by Hobbsee
<Hobbsee> mneptok: :P
<mneptok> i like it rough.
<mneptok> which is a good thing, as my reprehensible personality incites abuse.
<Hobbsee> dobey: then again, if they know that they have to file bugs, and refuse to, do they really want it added?  :)
<Hobbsee> dobey: tbh, i'd prefer not to try the uni uplink - it works for irc, but uploading things might be a bit evil
<ajmitch> Hobbsee: you've been reading the thread about packages to add to universe, haven't you?
<Hobbsee> ajmitch: no.  although i get that every once in a while, as i got subscribed to everything i post
* Hobbsee definetly ignores that one
<Hobbsee> ajmitch: i was more thinking little bugs
* Hobbsee goes off in search of lunchi
<Hobbsee> hi spam
<StevenK> infinity: Have I hit near the top of your todo list yet?
<infinity> Ish. :)
<infinity> Only 8000 lpia builds to go, after all.
<StevenK> Hah
<calc> lol
<kylem> hhe.
<StevenK> calc: Have you got a plan to upload OO.o 2.3?
<StevenK> calc: And will it build on powerpc? :-)
<infinity> That's our hope.
<bddebian> Is there an archive admin aboot that could throw a package back up for me?
<calc> StevenK: plan is as soon as i get it fully merged, and i don't know about ppc yet
<su-hoens`rZ> anyone know why the kubuntu alt cd installer doesn't locate 3 of my 4 sata drives even though the bios and the main cd find them fine? :(
<drago> guys, what kernel will be used in 6.06.2 release?
<Burgundavia> drago: given the api/abi stability statements, probably the same one as is in current 6.06.1
<RAOF> 2.6.15, same as always?
<LaserJock> are we doing a 6.06.2?
<ajmitch> apparantly it's planned
<ScottK> Yes.
<ScottK> It's due out this month.
<ScottK> If your LP-foo is sufficent you can get a list of the targetted bugs.
<Burgundavia> ScottK: you doing evil things to goats again?
<ScottK> Not that I'm willing to admint too, no.
<ScottK> admint/admit
<Burgundavia> ScottK: by admitted you are able to get that kind of information out of LP, you already have :)
<ScottK> Ah.
<ScottK> No, I can't do it.
<ScottK> I just happened to be on IRC when I saw someone else.
<ScottK> Didn't book mark it though.
<ScottK> My LP-foo mostly consists of bitching and filing bugs.
<Burgundavia> https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
<ScottK> Yeah.  That's the one.
<Seveas> Burgundavia, so *you* are doing evil things to goats?
<Burgundavia> Seveas: a gentleman never tells
<Seveas> but a wease^H^H^H^H^HBurgundavia does :)
<Burgundavia> you know, I thought somebody might make that joke
<Seveas> it's fairly predictable
<Burgundavia> nah, I just sleep with LP developers
<pitti> Good mooooorning!
<LaserJock> morning pitti
<StevenK> Morning pitti
<StevenK> pitti: lib{gn,kl}ash0 look be able to be NBS'd when gnash gets NEW'd
<pitti> the unstoppable Steve :)
<StevenK> Heh
<StevenK> pitti: It seems infinity can stop me. He doesn't love me at all. :-)
<lamont> NBS?
<StevenK> Not Build from Source
<StevenK> It looks like gaim has hit NBS, too.
<lamont> as in FTBFS?
<coNP> You mean pidgin?
<lamont> (fails to build from source)
<RAOF> No, gaim.  Pidgin still builds from sources, obviously :)
<coNP> But why do we still have gaim? :)
<RAOF> lamont: As in: there are binaries in the archive that can't be rebuilt.
<StevenK> lamont: No, as in Pidgin no longer builds a gaim package, not that it fails to build. :_)
<lamont> ah, ok
<StevenK> One I can fix simply.
<StevenK> My problem is, the others have gaim- in their name.
<pitti> StevenK: erk, pidgin not building a transitional package any more? that's wrong
<coNP> Replaces: gaim (<< 1:2.0.0+beta6-3)
<StevenK> pitti: Nope. Okay, let's get seb128.
<StevenK> pitti: You get the pitchforks, I'll get the flaming torches, and then we can lay in wait. :-)
* pitti grins evily and hides around a corner
* StevenK grins
<coNP> Why is gaim needed any more?
<StevenK> pitti: I saw no mention of it being dropped in the changelog.
<StevenK> pitti: I can upload pidgin adding gaim back, or I can wait, and we can interogate seb128 and ask him what for. :-)
<pitti> Package: pidgin
<pitti> Binary: pidgin-dbg, pidgin-data, pidgin, pidgin-dev, gaim
<pitti> hmm
<StevenK> Weird.
<pitti> StevenK: seems it's a glitch in archive-cruft-check...
<StevenK> pitti: It isn't listed as being published on Launchpad.
<pitti>       gaim | 1:2.0.2-0ubuntu1 |         gutsy | all
<StevenK> Binary: pidgin-dbg pidgin-dev pidgin-data pidgin
<StevenK> (From the i386 build logs)
<pitti> weird
<StevenK> pitti: Actually, is your Package and Binary paste from 2.0.2?
<pitti> yep
<StevenK> That's why, it isn't in 2.1.0
<pitti> ah, true /me tries to wake up properly
<coNP> it seems it is based on a debian sync
* StevenK hands pitti a large cup of tea
<pitti> thanks, that helps
<StevenK> pitti: So, should I fix pidgin, or shall we ask seb128 what happened?
<pitti> StevenK: if you feel like it, please fix it (just a debian/control re-addition, I think)
<StevenK> Agreed.
<coNP> StevenK: why is it a problem that gaim has been dropped?
<infinity> coNP: Upgrade path.
<infinity> coNP: How do you upgrade gaim to pidgin if there's no gaim transitional package?
<coNP> Is "provides not enough?
<pitti> coNP: no, apt won't see that
<pitti> coNP: well, it won't install pidgin just because of that
<coNP> Oh. I see, many thanks. It seems to be Debian-related.
<coNP> Okay I see the problem.
<pitti> coNP: you need an actual Conflicts: to coerce apt/dpkg to replace a package
<infinity> Sure, we'll just make libc6 conflict with gaim, that'll force the upgrade!
* infinity waits to get hit.
<StevenK> pitti: I daresay you trust me enough to just upload it? :-)
* coNP asks pitti for the pitchfork
<pitti> StevenK: sure
* StevenK hits infinity. Look at libnss-db!
<StevenK> infinity: :-)
<infinity> I look at it every day.  It brings me joy.
<infinity> Sometimes I look twice.
<infinity> I'd upload, but I fear that sharing that much beauty and perfection with the world may cause mass hysteria and confusion.
<StevenK> /dev/mapper/system-home 15G   15G     0 100% /home
<StevenK> Sigh
<infinity> And so, regretfully, I keep it to myself.
<infinity> StevenK: I'm sure you understand.
<infinity> (Also, lpia can bite me... That is all)
<StevenK> infinity: But I want yada demoted! *bounce impatiently*
<infinity> So do I, so do I.
<infinity> Patience, young one.
* Starting logfile irclogs/ubuntu-devel.log
* Hobbsee waves
* Hobbsee kills the network mangler again
<ivoks_> nonexsisting ALLMULTI and RUNNING makes some services broken
<ivoks_> is it possible to set those flags somehow? :)
<carlos> pitti: btw, Gutsy full export should be ready
<pitti> yay
* Hobbsee hugs pitti 
<carlos> pitti: the Dapper one should be ready anytime between this afternoon and this evening
<pitti> carlos: does the gutsy one also have the problem of dropped .po files?
<carlos> pitti: I guess some files would have that problem
<carlos> yes
<carlos> let me see the log...
<carlos> pitti: there are two files in that situation
<carlos> so I guess is ok to go ahead and use it
<pitti> carlos: something important?
<carlos> next full export update will include them (I fixed the problem so future exports should work)
<pitti> ok, cool
<Tonio_> Mithrandir: ping ?
<Hobbsee> Tonio_: on leave
<StevenK> Mithrandir is on VAC until Tuesday
* StevenK high fives Hobbsee 
<carlos> pitti:
<carlos>  system-config-kickstart | fr
<carlos>  pppoeconf               | zh_TW
<Hobbsee> StevenK: ^5 :(
<Hobbsee> * :)
<Tonio_> StevenK: argh :/
<Tonio_> StevenK: well he told me he would upload latest bluez packages before leaving, but it looks like one of them is missing
<StevenK> pitti: I'm test building pidgin, since the transitional package also provides symlinks.
<Tonio_> oki let's wait a week then ;)
<pitti> carlos: ok, doesn't sound too bad, it doesn't affect central desktop packages; I'll use that then
* infinity scratches his head.
<infinity> Don't we modify rmadison to work against a CGI on gluck?
<infinity> Cause my rmadison here is hitting qa.debian.org...
<infinity> (And clearly isn't modified at all)
<stgraber> asac: ping
<StevenK> infinity: Trying to query Ubuntu packages?
<infinity> StevenK: Yeah.  Just doing it on drescher instead. :P
<StevenK> infinity: rmadison -u ubuntu
<infinity> Unknown option: u
<infinity> Oh, wait.  I bet this snazzy feature was added in gutsy's devscripts.
<infinity> And I'm a slacker on feisty.
<StevenK> Heh
* Hobbsee wonders what the changes since last milestone are
<infinity> I'm still not used to not being distro and, hence, not running development crack...
<infinity> On the other hand, the stable system is kinda a pleasant change.
<Fujitsu> Stability is boring, though.
<infinity> Exceitment is pain.
<infinity> Excitement, too.
<Fujitsu> I don't think I could live with knowing for sure that my system will work when I boot it up. :P
<StevenK> Then turn it off and put an axe through it?
<Fujitsu> StevenK: Good idea!
<StevenK> Then you'll know for sure it won't work when you boot it up. :-P
<infinity> Bugs lead to anger, anger leads to hate, hate leads to dead coworkers.  I'm sure we're all better off with me running stable releases.
<StevenK> Maybe I should send you an AGP video card we have here.
<Fujitsu> infinity: You have no local coworkers, do yo
<Fujitsu> +u?
<infinity> I'm willing to travel.
<StevenK> The other sysadmin here put a different AGP video card into a server on last Friday and fried the motherboard. The server being a dual Xeon 2GHz expensive thing.
<Fujitsu> StevenK: Ooh, nice.
<infinity> StevenK: Was he trying to get a better framerate in Doom or something?
<lamont> infinity: feisty is love
<lamont> well, with gutsy's git-core backported
<StevenK> infinity: No, trying to free up a remote management board.
<StevenK> Oh, nice one Pidgin. It's Makefile has CFLAGS that contains " -g -g  -O2 -O2"
<StevenK> Evidently, it wants to be really sure.
<infinity> No harm in that, except for the "HAHA" factor.
<infinity> AKA, the Nelson Factor.
<StevenK> infinity: Which is why I'm commenting. :-)
<infinity> Morning, Michael.
<infinity> mvo: I'm not entirely happy with apt, you have a moment?
* infinity kicks himself as he realises the binaries he wanted weren't published yet because he didn't NEW them.
<infinity> Not my day, this one.
<mvo> infinity: sure
<mvo> good morning infinity
<infinity> mvo: Aww, I was hoping for a more entertaining response.
<infinity> mvo: (I don't have any issues with apt right now, I just like to see you panic)
<mvo> infinity: like 'I'm not happy with apt either' ?
* StevenK whispers "openssl" near infinity
<mvo> infinity: don't do this to me in my morning before I had a cup of tea :P
<infinity> mvo: Something closer to "dear god, Adam has another obscure apt feature request, where can I hide?"
<Hobbsee> hiya mvo.  please dont break things again for the tribe ;)
<infinity> mvo: Your last bizarre feature request is holding up well, though.
<mvo> Hobbsee: actually that was the plan ... new abi breaking apt today
* Hobbsee beats mvo with a big stick
<infinity> mvo: A mainline upload with the SecondaryArch hacks would be cool.  Do you have a branch with those patches on it that I could branch from and help you clean up the code?
<StevenK> pitti: Pidgin uploaded.
<Hobbsee> calc: please get OOO fixed ASAP.  I dont want to have to boot to windows, and write this long evil report there.
<pitti> yay you, thanks
<lamont> infinity: s/obscure/obscene/???
<mvo> infinity: I have a branch, I just need to check if I pushed it to the world
<infinity> lamont: Yeah, or that.
<mvo> lamont: :P
<infinity> lamont: Have you SEEN the SecondaryArch stuff?  It's just plain wrong.
<infinity> (But feels oh so right...)
<lamont> mvo: many of infinity's requests are obscene.  not sure how much he's walking in my footsteps, and how much he's leading-out now.
<lamont> infinity: lalalalalalalala
<mvo> lamont: that is really hard to say, but infinity is definitely creative in his feature reuquests
<infinity> lamont: I owe everything I am to having been driven insane by your shell.
<lamont> mvo: "creative" ...  I'll have to remember that term
<lamont> infinity: dude.  it works.  who needs python/perl/whatever
<lamont> ??
<infinity> lamont: I do everything in shell too, generally.  But my shell used to be readable until I met you. :P
<lamont> learned some tricks? or just fried your brain?
<infinity> The latter.
<lamont> hehe
<lamont> hrm... 2am... I should really sleep soonish
<infinity> Wimp.
<lamont> I'm only like 3 times your age until you graduate from high school, turkey.
<lamont> (I actually expect that I'm less than twice your age...)
<infinity> Hey, I'm hitting the big three-oh in a month, I'm feeling more LaMonty every day.
<lamont> 44 in a month or so
<StevenK> That's three-uh-oh
<Hobbsee> you're just all old :P
* lamont looks up infinity's birthday
<lamont> after mine
* infinity is too lazy to look up LaMont's.
<stgraber> morning
<lamont> mine's more work, since I'm not on that page anymore.
<lamont> iz 11 days before yours
<mvo> infinity: welcome to the old-farts club
<infinity> lamont: Damn, I was going to use db.debian.org to find yours, but you don't have it listed.
<lamont> :-)
<infinity> Hrm, neither do I.
<infinity> Is that field new?
* Fujitsu is too young.
<lamont> I think so
<lamont> Fujitsu has been in business since before I was born, I believe
<lamont> == not young. :-)
<StevenK> Hah
<Fujitsu> Heh.
<Fujitsu> Hm, why did ubuntu-crashes-universe get subscribed to bug #130089?
<ubotu> Bug 130089 on http://launchpad.net/bugs/130089 is private
<StevenK> pitti: Get him, he's here!
<seb128> ?
* StevenK whistles innocently.
* seb128 runs away from pitti
<mvo> hey seb128!
<Hobbsee> Fujitsu: because it's private?
<Hobbsee> heya seb128!
<seb128> mvo: hello
<seb128> Hobbsee: hello
<StevenK> seb128: Your Pidgin merge from Debian dropped the gaim transitional package.
<Hobbsee> Fujitsu: marked as dead
<seb128> StevenK: yes, that's because Debian use the gaim source to build transitional packages now and I'm going to sync that
<StevenK> Oh drat, I didn't know that.
<Hobbsee> seb128: got any new stuff since the last tribe that should be in the release notes?
<seb128> Hobbsee: GNOME 2.19.6
<seb128> Hobbsee: transition to rarian
<seb128> Hobbsee: fast user switching using consolekit
<stgraber> Hobbsee: I think the problem is that it should have been in crashes-main not -universe as notification-daemon is main
<StevenK> pitti: Right, what do we do now?
<Fujitsu> Hobbsee: The package is in main, though.
<Hobbsee> StevenK: ah right
<seb128> Hobbsee: gnome-keyring pam integration (coming)
<Hobbsee> seb128: great.  pity i dont know what #2 and #3 are :)
<seb128> Hobbsee: tracker installed (need some work though)
<Hobbsee> seb128: thanks
* seb128 grrrrr
<pitti> hey seb128
<seb128> StevenK, pitti: can't you wait for me to show up before uploading desktop things?
<seb128> I did drop that transitional package on purpose
<seb128> hello pitti
<StevenK> But if that was mentioned in the changelog, I wouldn't have questioned it.
<seb128> StevenK: why should I have mentionned it? that's a merge, I mention only things we add there, not every change we don't do
<pitti> seb128: oh, you want to have a separate source package which only builds a transitional package?
<seb128> pitti: yes, what Debian does and what we can sync
<seb128> easier
<pitti> hmkay; sorry then...
<seb128> StevenK: I'm on IRC often enough to wait for me to be connected and ask before uploading random changes
<StevenK> seb128: Shall I revert my change and grovel at your feet?
<seb128> not that's ok
<Fujitsu> Can someone please give back mysql-admin on i386 and powerpc?
<seb128> I still have my upload from yesterday, I'll dch on it and upload
<StevenK> seb128: Okay. Sorry for the trouble.
<seb128> that's alright
<seb128> thanks for the work
* Hobbsee goes home
<pitti> seb128: ok, next time we'll wait; perdon
<seb128> if that's a package I maintain actively though better to ask before doing changes
* StevenK nods.
<seb128> usually I don't screw to much and there might be a reason for a change ;)
<seb128> s/to/too
<seb128> pitti: that's alright
* seb128 hugs pitti
* StevenK runs off home.
<tuxcrafter> Can somebody explain to me the difference between libc6and libc6-i686and why  they are both installed. And what happens if I have removed libc6-i686?
<seb128> tuxcrafter: apt-cache show libc6-i686
<tuxcrafter> in fedora you can install only one
<Seveas> ubuntu is not fedora
<Seveas> and #ubuntu-devel is not for support :)
<infinity> We're obviously more clever.
<tuxcrafter> infinity: exactly
<tuxcrafter> Filename: pool/main/g/glibc/libc6_2.5-0ubuntu14_i386.deb
<tuxcrafter> oke so if i remove  libc6-i686
<infinity> Then you don't have a 686-optimised libc anymore.
<tuxcrafter> it will automatic be take over by ibc6_2.5-0ubuntu14_i386.deb
<tuxcrafter> and i will use i386 instructions
<infinity> i486, actually, but yeah.
<tuxcrafter> on my i686 cpuy
<seb128> tuxcrafter: where do you want to go with that?
<tuxcrafter> is there some trick to let linux think there is an i386 machine instead of an i686
<seb128> tuxcrafter: if the optimized version is installed it's used, if it's not installed it's not used
<seb128> seems to be logical, no?
<tuxcrafter> there is an bug with the via C7 cpu and glibc / libc6 thanks makes the system get a total lockup
<tuxcrafter> under fedora we could fix this by only using i386 instructions
<tuxcrafter> but we want this also on ubuntu
<tuxcrafter> just for testing
<seb128> uninstall the i686 package?
<tuxcrafter> seb128: yes i will do this, but i needed to be sure it has the wanted effect
<seb128> pitti: I'm doing syncs, you are busy enough and I've nothing urgent to do
<tuxcrafter> so I came to this cannel
<pitti> seb128: ah, thanks; appreciated
<pitti> Riddell: I published the koffice and qt updates now, waiting for them to appear before sending out USNs
<tuxcrafter> apt-cache show glibc-2.5.0-0exp1 and ..exp2 does not show any information
<infinity> Why would it?
<infinity> That's not a package name.
<tuxcrafter> whould be nice
<tuxcrafter> ow
<pitti> seb128: alternatively, if you feel like it, there's https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/129940
<ubotu> Launchpad bug 129940 in koffice "[XPDF]  possible buffer overflow and execution of arbitrary code" [Undecided,Fix committed] 
<seb128> pitti: will have a look to that as well
* pitti hugs seb128 
* seb128 hugs pitti back
<ogra> pitti, could you update mkelfimage ? Q-Funk fixed the build in -3 in debian
<pitti> ogra: right, I remember, I sponsored the upload
<pitti> ogra: I'll sync it (unless seb128 is doing syncs ATM)
<tuxcrafter> seb128: thank you for the information, i did every thing i could on a default xubuntu installation run the i368 kernel and removed libc6-i686
<ogra> pitti, thanks :)
<tuxcrafter> good luck with gusty everybody
<tuxcrafter> gutsy
<seb128> tuxcrafter: you're welcome
<seb128> thanks
<ogra> pitti, and please, please dont make dhcp use a static interface setup, that will make our lifes in ltsp support lots harder :(
<pitti> ogra: no, I wasn't planning to :) (it was just an example more or less)
<ogra> phew
<ogra> you scared me :)
<Fujitsu> pitti: If you haven't got anything better to do, can you please give back mysql-admin on {i386,powerpc}?
<tkamppeter> hi pitti
<pitti> Fujitsu: I have, byt that's quick :) done
<pitti> hi tkamppeter
<pitti> tkamppeter: just answered your mail, thanks for pointing out
<tkamppeter> pitti, this means that the aa protection for CUPS should be only optional?
<pitti> tkamppeter: in gutsy final I want it installed by default
<pitti> tkamppeter: but -profiles is supposed to stay in universe for gutsy
<pitti> tkamppeter: so either the #includes move to apparmor itself, or I'll drop the #includes and copy their contents
<tkamppeter> From the two solutions which you suggest in your mail I prefer the one of movin the includes into the aa main package.
<pitti> tkamppeter: me too, it makes most sense
<pitti> (for custom profiles installed by the admin, too
* pitti files a bug
<tkamppeter> under no circumstances you should move the CUPS profile into the aa package. This profile should stay with CUPS.
<tkamppeter> Also copying the contents of the includes into the CUPS profile is bad, as then one has a duplicate implementation of one thing which is bad for maintainability.
<Hobbsee> holy cow
* Fujitsu drops a cow on Hobbsee.
<tkamppeter> pitt, so you are filing a bug now for moving the profiles into the main package of aa?
<Fujitsu> pitti: Thanks.
<pitti> tkamppeter: bug 130114
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Undecided,New]  https://launchpad.net/bugs/130114
<pitti> tkamppeter: I agree, that's my favourite as well
<pitti> tkamppeter: (why oh why does Mike even reject such simple and nonintrusive patches like adding a PidFile option??)
<pitti> tkamppeter: sorry, I don't have time ATM to look into bug 103878
<ubotu> Launchpad bug 103878 in python-cups "[apport]  system-config-printer.py crashed with SIGSEGV in free() //trying to print test page on my Canon i560 " [Medium,New]  https://launchpad.net/bugs/103878
* Hobbsee throws Fujitsu at the wall
<Hobbsee> ooo actually works, it seems.
<cjwatson> drago: authoritatively (and agreed with your boss ;-)), 2.6.15
<drago> cjwatson: OK. tks for attention ;-)
<tkamppeter> pitti, I cannot reproduce bug 103878, it simply works for me. Seems to be already fixed upstream.
<ubotu> Launchpad bug 103878 in python-cups "[apport]  system-config-printer.py crashed with SIGSEGV in free() //trying to print test page on my Canon i560 " [Medium,New]  https://launchpad.net/bugs/103878
<tkamppeter> pitti, so perhaps there is nothing to do. Perhaps better to ask Tim Waugh.
<pitti> tkamppeter: can you please ask the reporter to check in gutsy?
* Hobbsee kicks thunderbird.  please stop crashing.
<tkamppeter> pitti, done.
<carlos> seb128: hi
<seb128> hello carlos
<carlos> seb128: is a known bug that 'Places' entries doesn't get the Music, Pictures, etc... folders if you change them by hand?
* carlos talks about gnome-panel's Places
<seb128> what do you mean "change them by hand"?
<carlos> seb128: edit ~/.config/user-dirs.dirs , rename directories and restart the session
<carlos> after that, Places doesn't have the updated entries
<seb128> carlos: they are GTK+ bookmarks I think and not updated dynamically
<seb128> carlos: what is listed to .gtk-bookmarks?
<carlos> seb128: I see, I guess it makes sense
<carlos> right, that's the problem
<carlos> it points to old directories
<carlos> seb128: is there any UI to do this change?
<seb128> you can change bookmarks from nautilus
<seb128> in the shortcut menu
<carlos> I mean to edit everything in one single step
<seb128> no
<carlos> ~/.config/user-dirs.dirs + bookmarks
<carlos> ok
<carlos> seb128: is there any tool planned to do it?
<seb128> not that I know but I would not be surprised if somebody gets annoyed enough to write one
<carlos> ok :-)
<carlos> seb128: thanks for your help
<seb128> you're welcome
<Hobbsee> pitti: since when could you read my mind?
<pitti> Hobbsee: forever, why?
<Hobbsee> pitti: ah right :P
<Hobbsee> pitti: was just going to ask you to shove a sync i just filed, to give a hopeful a chance to fix it tonight
<Hobbsee> and then i saw my email :)
<pitti> Hobbsee: that was seb128, though
<seb128> k, I'm done with syncs, removal and backports cleaning
<mvo> thom: did you had a chance to test the https patch I send to you? I would like to merge it if it works for you
<seb128> pitti: ^
<pitti> seb128: you rock, thanks
<seb128> you're welcome
<seb128> pitti: when you have a minute can you have a look to cheese in source new?
<seb128> pitti: it should be easy, I did sponsor the upload so I would prefer have somebody else having a quick look at it
<pitti> seb128: when you got a minute, can you please test http://people.ubuntu.com/~pitti/tmp/gutsy-langpack/ for French?
<pitti> seb128: sure, will do
<seb128> pitti: ok, looking now to the language pack update
<pitti> seb128: ^ those are new gutsy langpacks (fresh -base for tribe CDs)
<thom> mvo: no, going to do so in a minute
<seb128> pitti: the restricted-manager po has been dropped
<seb128> the mo rather
<seb128> pitti: same for freetype
<pitti> bwah
<pitti> carlos: ^ ?
<seb128> and gdebi is new ;)
<mvo> thom: thanks!
<thom> just need to get it to build on edgy ;)
<mvo> thom: let me know if that is a problem, I can build something for you if it does not apply cleanly or anything like this
<Nafallo> mvo: fluendo reminder :-)
<mvo> Nafallo: haha, thanks!
* mvo hides
<Nafallo> :-P
* mvo hides and goes for lunch
<Nafallo> mvo: I'll remind you later then ;-)
<seb128> hum, lunch ;)
<Nafallo> lunch!
<thom> mvo: compared to the rest of the packaging madness i've suffered this week, backporting apt is trivial :)
* soren is on a bit of a jumpy wifi connection..
<thom> mvo: looks good, go for it
<pitti> carlos: did you see above problems with  the gutsy langpack? (missing restricted-manager and freetype)
<mvo> thom: rock, thanks a lot!
<pitti> asac: can you please make bug 119038 conformant to SRU requirements? i. e. verify that it is fixed in gutsy, attach reproducing instructions for verifiers, subscribe ubuntu-sru, etc.
<ubotu> Launchpad bug 119038 in enigmail "MASTER Key management / Recipient Key Selection broken (endless loop in EnigConvertToUnicode)" [High,In progress]  https://launchpad.net/bugs/119038
<pitti> ugh, quite a patch
<carlos> pitti: no, I didn't see it
<carlos> let me check...
<carlos> pitti: could I see more details?
<pitti> carlos: <seb128> pitti: the restricted-manager po has been dropped
<pitti> <seb128> the mo rather
<pitti> <seb128> pitti: same for freetype
<carlos> freetype is not available in Gutsy, but restricted-manager is
* carlos checks whether freetype is in a different sourcepackage...
<pitti> carlos: restricted-manager moved from main to restricted a while ago, could that be it?
<asac> pitti: isn't https://wiki.ubuntu.com/MOTU/SRU the document describing the procedure?
<carlos> pitti: for sure, that's it
<carlos> pitti: we only have main packages
<pitti> asac: no, it's in main, therefore https://wiki.ubuntu.com/StableReleaseUpdates
<pitti> carlos: d'oh, why?
<carlos> pitti: dude, because language packs are only for main
<carlos> nothing changed here...
<pitti> carlos: hm, too bad; can we have restricted? it's supported and isntalled by default, after all?
<carlos> pitti: if you tell me that restricted should be handled in language packs now, we can change it without problems
<pitti> seb128: hm, I guess we'll go with those langpacks then for now, and fix that later
<pitti> carlos: that would be cool
<carlos> pitti: this means that your script should strip off translations from restricted packages too
<pitti> carlos: for most stuff in restricted it probably doesn't matter, since most of it doesn't have po files
<pitti> carlos: right, good point; I'll do that
<carlos> pitti: the problem is that until we 'fix' launchpad no translations will be imported
<pitti> carlos: can I get the old translations still? and put them into upstream bzr?
<carlos> pitti: I will need to check with kiko whether I could get this cherry picked or whether you need to wait until 1.1.8 milestone (later this month)
<carlos> pitti: yeah, for restricted-manager is not a problem
<pitti> carlos: if I can get the .po files, then waiting a bit is no problem
<carlos> it's still available
<pitti> carlos: right, just for that one
<carlos> and I could include its translations in next full export without major problems
<carlos> but my point is that newer .pot files will not be uploaded into launchpad until we allow restricted packages to be imported
<carlos> ok
<carlos> pitti: https://translations.launchpad.net/ubuntu/gutsy/+source/restricted-manager/+pots/restricted-manager/+export
<carlos> pitti: you can get the .po files now if you want
* carlos files a bug
<pitti> carlos: thanks a lot
<Kmos> PHP 5.2.4 RC1 is out.. let's test it :)
<asac> pitti: bug 119038 updated ... as you wished
<ubotu> Launchpad bug 119038 in enigmail "MASTER Key management / Recipient Key Selection broken (endless loop in EnigConvertToUnicode)" [High,In progress]  https://launchpad.net/bugs/119038
<pitti> asac: cheers
<pitti> asac: ah, so the gutsy task can be closed, I figure; thanks
<asac> was it ever opened?
<pitti> asac: yes, it was 'in progress'
<asac> i don't see a gutsy task ... just main task + dapper/edgy/feisty
<asac> oh ... so you say that main task is gutsy task?
<pitti> right 'main' -> development rellease -> gutsy ATM
<asac> ok
<asac> the visualisation as root node of the task tree is a bit confusing then
<asac> pitti: its really a bit confusing that you have MOTU/SRU + StableReleaseUpdates
<asac> pitti: i just searched for SRU :)
<pitti> asac: yeah; StableReleaseUpdates was there first, though
<asac> pitti: and there are even two SRU documents that appear to be somehow redundant ... SRU + Process/SRU
<pitti> eek
<asac> what shall we do about that?
<asac> i mean ... maybe we say: wiki.ubuntu.com/SRU/Main
<asac> SRU/MOTU ?
<asac> or ... just use one policy for all
<asac> e.g. just SRU aka StableReleaseUpdates
<pitti> asac: Processes/SRU redirects to MOTU/SRU already
<asac> ah
<asac> pitti: maybe we can make one policy document out of it ... with a section for "special main requirements" ?
<pitti> asac: not sure whether this would be more easy to read
<pitti> asac: but the packages should link to each other at least
<pitti> with a prominent warning about main/universe
<asac> right ... i will add those links on top for now
<pitti> policy changes on one don't automatically apply to the other, after all
<pitti> asac: thank you
<pitti> asac: enigmail again> what about the 'dapper ftbfs' changelog bit in the edgy diff?
<asac> pitti: it fails on edgy too
<pitti> asac: ok, so it's just a copy&paste glitch in the changelog and actually necessary?
<pitti> good
<asac> sorry for the inaccurate changelog ... copy&paste error
<pitti> ok, np; I just want to make sure
<asac> yes ... needed ... don't ask me why it fails now
<asac> its black-magic ... but it does
<pitti> bug updated
<asac> thanks
<carlos> pitti: https://bugs.launchpad.net/rosetta/+bug/130138
<ubotu> Launchpad bug 130138 in rosetta "Allow translations imported for 'restricted' pocket" [Undecided,New] 
<carlos> pitti: just in case you want to track it
<pitti> carlos: thanks, I'll subscribe
<Kmos> Can I do a request sync for gambas to fix it (because it only builds on i386) - http://packages.qa.debian.org/g/gambas/news/20070702T140204Z.html ?
<Hobbsee> Kmos: looks smart
<Kmos> Hobbsee: not enough for a sybc ?
<Kmos> *sync
<Hobbsee> Kmos: looks worthy of a sync, to fix the ftbfs on the other arches
<Kmos> jono: hey
<jono> hey
<Kmos> Hobbsee: i'll request the sync soon
<Hobbsee> hi jono
* Hobbsee pokes pitti if he's not busy, to show him new shiny
<Hobbsee> (and any other archive admins interested)
<seb128> re
<seb128> carlos, pitti: fine with me for the language pack update
<cjwatson> doko,agoliveira_brb: re the conversation in #ubuntu-meeting last night, the germinate output in http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/ already looks at universe and multiverse as well as main and restricted, so you should be able to use it to build the list of source packages for lpia bootstrapping
<cjwatson> I'm seeing if I can give you an automated compiled list now
<cjwatson> doko,agoliveira_brb: how about http://people.ubuntu.com/~ubuntu-archive/gutsy-lpia-sources ?
<cjwatson> 561 /home/ubuntu-archive/public_html/gutsy-lpia-sources
<doko> cjwatson: minus the binary-all packages, if you have this information handy?
<cjwatson> I can give it a try
<cjwatson> and presumably minus Architecture: powerpc and the like
<cjwatson> though actually the germinate output that's generated from is for i386 so that's not relevant
<doko> well, currently you don't get correct dependencies for lpia, because many packages are still missing
<cjwatson> indeed
<cjwatson> doko: I think that's right now
<cjwatson> 396 public_html/gutsy-lpia-sources
<cjwatson> for x in required minimal standard mobile mobile-dev; do for y in "$x" "$x.build-depends"; do tail -n +3 "$HOME/public_html/germinate-output/gutsy/$y" | head -n -2 | cut -d\| -f1,2 --output-delimiter=' ' | tr -s ' ' | sed 's/^ *//; s/ *$//'; done; done | sort -u >"$TMPDIR/germinate"
<cjwatson> for c in main restricted universe multiverse; do wget -q -O- http://archive.ubuntu.com/ubuntu/dists/gutsy/$c/binary-i386/Packages.gz | zcat; done | grep-dctrl -nsPackage -vXFArchitecture all | sort -u >"$TMPDIR/not-all"
<cjwatson> join -o 1.2 "$TMPDIR/germinate" "$TMPDIR/not-all" | sort -u >"$HOME/public_html/gutsy-lpia-sources"
<cjwatson> hello, SQL in shell
<doko> hello or hell?
<cjwatson> I meant the former, though either would do :)
<StevenK> infinity: Is it libnss-db time yet? :-P
<cjwatson> doko: I'm not sure I can easily split that up by priority, since the list is by source package so I'd have to fish out priorities for all the binary packages and compare them and stuff
<cjwatson> but hopefully <400 is accessible enough that that's less of a problem
<cjwatson> doko: can you have the existing wiki list in a form that you can automatically cross-reference with that? maybe wget ?action=raw, munge, join
<doko> no, that's ok,
<doko> will look at it
<cjwatson> if you can prepare a shell snippet that prints out the list of remaining packages by fetching the list of done packages from the wiki and subtracting them off, I could make that output to ~ubuntu-archive/something as well
<pitti> Hobbsee: back from lunch, what's up?
<Hobbsee> pitti:
<Hobbsee> [22:16]  <kiko> so the new queue UI is live:
<Hobbsee> [22:16]  <kiko> https://edge.launchpad.net/ubuntu/gutsy/+queue
<Hobbsee> [22:16]  <kiko> Hobbsee, you can now inspect packages directly
<pitti> Hobbsee: that's awesome!
<Hobbsee> pitti: yeah!
<seb128> pitti: good, now other people can do reviews ;)
* pitti pokes NEW now
<pitti> seb128: shall I sync gaim from Debian then?
<seb128> pitti: feel free to do it, I'll upload pidgin, the update from this morning should be available now
<pitti> seb128: ah, cool
<pitti> seb128: hmm, not sure whether this will work... 'gaim' binary is at 2.0.2, while the fake gaim is 2.0.0
<pitti> elmo: gaim is in main but its source (gaim) is not.
<pitti> elmo: sorry, that was "E:"
<pitti> seb128: sync failure ^
<pitti> seb128: I'll --force it away, but it's still a bit fishy
<pitti> seb128: I'll also promote gaim binary to main
<seb128> pitti: we need to take the Debian package and dch it to add a new revision number
<pitti> seb128: if you do that, then it might be easier to just keep the transitional package in pidgin...
<pitti> but your call
<seb128> pitti: hum
<seb128> let me think about it, there is no hurry
<pitti> ok
<seb128> but adding new binary packages to pidgin is non trivial
<seb128> where running dch on a package is
<StevenK> It so is, it took me three minutes.
<pitti> seb128: that's done already, question is how much effort it is to maintain it until 8.04 release
<seb128> StevenK: should I say I admire you or something like that for being so quick? ;)
<pitti> seb128: we can drop this after the next LTS, after all
<StevenK> seb128: *shrug*
<seb128> k, let it your way if you prefer
<seb128> I'm not going to argue against that
<cjwatson> CD builds should be alive again; I just turned the cron jobs back on
<seb128> I've other things to do
* pitti doesn't care either way
<pitti> cjwatson: yay
<cjwatson> with a local rebuild of mkisofs, but who's counting
<pitti> what was the new name of lithium now?
<pitti> phosphor? iridium? uranium? helium? :)
<cjwatson> antimony
<cjwatson> Li -> Sb
* pitti aliases it to 'cdimage' in .ssh/config
<pitti> cjwatson: thanks
<pitti> asac: sunbird binary NEWed FYI
* asac hugs pitti
<Company> pitti: ping
<pitti> Company: I just said something three seconds ago :) Hi
<Company> i just joined ;)
<pitti> Company: right, nevermind
<Company> pitti: i want apport to have a "i'm a developer, give me the stacktrace" button
<pitti> Company: I agree, that would be nice
<Kmos> a Save button, but also submit it :)
<pitti> Company: it's quite a lot of effort to generate this on the client side, though
<pitti> Company: that's bug 75901 FYI
<ubotu> Launchpad bug 75901 in apport "Integrate apport-retrace into GUI" [Wishlist,Confirmed]  https://launchpad.net/bugs/75901
<Company> pitti: good, i guessed you were aware of the issue :)
<Company> i'm hitting it with the swfdec mozilla plugin - when epiphany crashes, i'd like to see the trace
<pitti> Company: yeah, it's just a moderate amount of work to port it to the three frontends
<pitti> Company: I mean, you can run apport-retrace on your box today, so it's not very hard
<pitti> but it doesn't have a button yet :0
<Company> heh
* Company is lazy
<Company> stereotypical gnome user
<superm1> Any udev hackers around?  I was was looking for a workaround to using RUN+="/etc/init.d/SCRIPT restart" for hotplug events, since it seems to hang if i try that
<pitti> seb128: btw, did you already change the seeds for rarian?
<seb128> pitti: no, neither that nor consolekit nor tracker
<pitti> ah, seems I should stop attacking NEW and start looking at CK; I still gotta do the RM bits for today
<seb128> pitti: https://wiki.ubuntu.com/MainInclusionReportConsolekit is about consolekit, is that you who should look at accept it or iwj?
<pitti> seb128: yes, it is
<seb128> I would appreciate if that could be done today
<pitti> so I'll just do cheese and then turn my attention to that
<seb128> so we can add it to desktop now
<seb128> thanks
<pitti> dendrobates: so that auth-client-config in source NEW from Jamie Strandboge is what you need for server?
<dendrobates> pitti: what about auth-client-config?  It was written by jdstrand, as part of my ldap-auth-client .
<pitti> just curious
<dendrobates> Yes.  It will allow a user to use a template to configure pam and nss.
<dendrobates> Currently, it uses python ConfigParser, but I would like to switch to something better for the templates.  XML perhaps.
<pitti> ok, package looks fine, accepted
<dendrobates> BTW,There is nothing server specific about any of the stuff I am doing.  So far it is all client side stuff.
<dendrobates> pitti: thanks.
<pitti> hi mathiaz
<mathiaz> hi pitti
<pitti> mathiaz: do you think that bug 130114 is reasonable?
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Undecided,New]  https://launchpad.net/bugs/130114
<mathiaz> pitti: makes sense.
<mathiaz> pitti: about bug 129920
<ubotu> Launchpad bug 129920 in apache2 "/var/lock/apache2 has wrong owner and group for webdav" [Low,In progress]  https://launchpad.net/bugs/129920
<mathiaz> I've used nominate bug instead of adding feisty in the url.
<mathiaz> if after that I close the bug for as fix released I can't find it anymore.
<mathiaz> ie the bug is not listed under /ubuntu/feisty/+source/...
<ScottK> mathiaz: I believe there is an open LP bug about that.
<pitti> mathiaz: but over the non-release URL you should still see it
<mathiaz> pitti: by non-release, you mean ubuntu/+source/... ?
<pitti> mathiaz: yes
<mathiaz> pitti: I don't think so, as it's marked as Fix released.
<mathiaz> I had this problem for a bug in mysql-dfsg
<pitti> https://launchpad.net/ubuntu/+source/apache2/+bugs
<pitti> I see it here
<mathiaz> I used nominated for a release, then marked as Fix released. Now I cannot find it anymore
<pitti> and here https://launchpad.net/ubuntu/feisty/+source/apache2/+bugs
<mathiaz> pitti: yes - that's because bug 129920 is not marked as fix released.
<ubotu> Launchpad bug 129920 in apache2 "/var/lock/apache2 has wrong owner and group for webdav" [Low,In progress]  https://launchpad.net/bugs/129920
<mathiaz> pitti: let me try to find the mysql-dfsg bug
<mathiaz> pitti: hum. I can't find it anymore.
<pitti> mathiaz: that was the bug, right? :)
<mathiaz> pitti: anyway, it's better to use the url hack over the nominate ?
<pitti> mathiaz: nominate works again for me at least
<pitti> but it shouldn't make a difference
<mathiaz> pitti: well - yesterday I used nominate, but there wasn't any task for feisty that was created.
<mathiaz> pitti: that's why I didn't mark it as 'Fix released' for gutsy.
<mathiaz> pitti: as I though I would 'loose' the bug.
<pitti> mathiaz: I don't remember any more, I might have accepted the feisty task
<mathiaz> pitti: that's my point. If I use the url hack, the release task shows up directly.
<mathiaz> pitti: but if I use nominate, someone else has to accept (a member of the driver I guess) - correct ?
<pitti> mathiaz: I can do this again, so it's apparently restricted to a group you aren't a member of
<pitti> mathiaz: I'm not in -drivers and I can accept
<pitti> mathiaz: are you in ubuntu-qa?
<pitti> I'll be right back
<Hobbsee> pitti: you're in release thoguh.  i thought it was ~ubuntu-dev
<ScottK> For accepting tasks I'm pretty sure you need to be MOTU or core-dev for Universe/Main packages.  -qa just gets you importance, IIRC.
<pitti> Hobbsee: yeah, -release might be it
<Hobbsee> it's certainly not drivers
<Hobbsee> but i though tit was ~ubuntu-dev now
<pitti> iwj, seb128: hm, I just wanted to test f-u-s with new gdm, but the password dialog now doesn't allow me to click any button; mouse clicks don't work at all
<seb128> pitti: how do you switch?
<iwj> pitti: Freaky.
<pitti> seb128: System -> quit -> switch
<iwj> Can you log in by typing ?
<pitti> seb128: ah, after opening a new session and Ctrl+Alt+F7, that second time the mouse worked
<pitti> iwj: yeah, typing and tab+enter to select a button works
<iwj> Why do you need to select a button ?
<iwj> I mean, not that you shouldn't be able to ...
<pitti> iwj: default is 'unlock', I wanted 'switch user'
<pitti> door bell
<iwj> Oh, on the unlock password prompt screen.
<iwj> Wait a moment.  System / quit / switch  ought to produce a new gdm, not a screen lock.
<infinity> If it's producing a screen lock, the second X is crashing. :P
<iwj> That would be consistent with the mouse being broken somehow.
<iwj> I mean, the mouse might have been messed up by the second X.
<pitti> re
<pitti> iwj: it still locks the screen by default before
<iwj> Yes.  It locks the screen you're leaving and is supposed to start a new X server with a gdm flexiserver.
<pitti> erk, and now ctrl+alt+Fn doesn't work any more
<iwj> Definitely an X bug then.
<pitti> it definitively did before I started that second X session
<pitti> how am I supposed to switch now?
<iwj> You can use chvt if you like.
<iwj> But that may not work either.
<iwj> Can you reproduce these problems ?  If so then the X people will thank you for your bug report :-).
<pitti> nope, it doesn't
<pitti> yes, I can
<pitti> I just tried the 'switch user' button in the logout dialog again, again no mouse
<iwj> Good.  Err, well, better than random lossage, anyway.
<pitti> and this time I cannot even switch users any more
<pitti> "Too many X screens"
<iwj> No, I mean, start from a fresh boot.
<iwj> Too many X screens ?
<iwj> How many do you have ?
<pitti> iwj: believe it or not. TWO!
<pitti> my usual one, and the test user session I just started before
<StevenK> Evidently, two is too many.
<pitti> (I think; I don't know, I can't switch any more after all)
<iwj> Even if it were leaking sessions it's supposed to go up to 50 or 60 or something.
<StevenK> pitti: ssh in and run w, that'd tell you.
<iwj> I think that's probably a misdiagnosis then.
<pitti> seb128: anyway, this stuff is gdm/g-s-s or so; CK itself seems quite harmless to me, and "advanced static code analysis" (IOW: grep for usual vuln patterns) didn't show anything, so please go ahead and seed it
<pitti> StevenK: point
<seb128> pitti: ok, doing it
<pitti> joe      pts/5        2007-08-03 16:21 (:22.0)
<pitti> joe      tty12        2007-08-03 16:21 (:22)
<seb128> thanks
<pitti> that's the second one
<iwj> pitti, seb128: Yay, thanks.
<iwj> grep> I did that too :-).
<pitti> iwj: "grep -r alloc" was impressively small
<iwj> It likes to start at about :20 IIRC.
<seb128> pitti: I'll add fast-user-switch-applet to the MIR queue soon, time to write it
<iwj> pitti: Most of the actual memory allocation is dbus or gobject craziness which uses new and init and names like that.
<pitti> so, I don't usually use that "switch user" button in the logout dialog, so it might have been broken before CK and the new gdm
<pitti> iwj: right, but that's usually fine
<iwj> pitti: Right.
<pitti> iwj: I'm particularly looking for stuff like malloc(n * sizeof(foo)) and such
<iwj> broken before> Do you normally do VT switching at all ?
<pitti> (integer overflow)
<iwj> pitti: Mmm.
<pitti> iwj: yes, I do
<pitti> iwj: both to the text consoles, and other X screens
<iwj> And no trouble ?  You use gdmflexiserver ?
<pitti> but for the latter I just got used to Alt+F2 gdmflexiserver -l
<pitti> iwj: I do
<pitti> iwj: but with -l, since that 'lock screen by default' annoys me
<iwj> Ah, but not starting a new X when the VC is currently another X ?
<pitti> iwj: if I run "gdmflexiserver -l" in my current X, that should be the case
<pitti> iwj: Alt+F2 in the sense of the gnome "run command" dialog, not Ctrl+Alt+F2 (switch to VT)
<iwj> Yes.  That's approximately what the switch user logout dialogue does.
<iwj> OIC.
<iwj> Mysterious.
<pitti> aah
<iwj> Maybe some kind of hideous race, but between what ?
<pitti> so Ctrl+Alt+F12 actually works
<pitti> that brings me to that 'joe' session
<pitti> (I'm used to normal X on 7 and second X on 9, but now the first session is on 9)
<iwj> Which one the first session is on seems to vary, annoyingly.
<iwj> That is, if you switch users a bit you can end up with the first one moving itself from 7 to 9.
<pitti> right, that's what apparently happened
<iwj> But we still don't understand this mouse thing, right ?
<pitti> right
<iwj> You selected switch user and got a gnome-screensaver unlock prompt ?
<pitti> and why my text VTs are broken
<iwj> In which the mouse didn't work ?
<pitti> yep
<iwj> Your text VTs are broken ?
<iwj> I definitely blame X.
<pitti> well, I cannot switch to them any more after the first user switch
<iwj> What does chvt 2 do ?
<pitti> the very same; quickly switch to vt 2, flicker, and switch back
<pitti> maybe it relies on ck-list-sessions listing a valid session?
<pitti> (which it doesn't for VT)
<pitti> I'm logged into VT1, the rest is just getty
<iwj> It should let you switch to an inactive vt.
<iwj> Can you /etc/init.d/consolekit stop and try then ?
<iwj> I admit that I didn't try using the text VTs much during testing.
<pitti> confirmed, that fixes it
<iwj> OK.  Definitely a bug then.
<pitti> I start it again -> still works
<iwj> wtf
<iwj> Oh, I know.
<iwj> I bet I can reproduce this but my testbed is doing something else right now.
<iwj> I should fix this for the next tribe at least though.
<StevenK> 
<StevenK> Oops
<pitti> hm, now 'switch user' didn't give me the lock dialog, but immediately a new gdm
<iwj> That's what it's supposed to do.
<pitti> oh, gdmflexiserver -l is interesting
<pitti> iwj: it shows me a list of four 'nobody' sessions on :20 to :24 (terminals 10 to 14)
<pitti> it didn't do that in the past
<lamont> pitti: just oh by the way, abiword and nabi are two main packages that currently (and apparently for a while) build-depend universe packages...
<pitti> iwj: indeed, those are now full of gdms. funny
<pitti> lamont: erk
<StevenK> lamont, pitti: Happy to look at the two of them in the morning, if you wish.
<pitti> lamont:  link-grammar?
<pitti> and libhangul
<lamont> pitti: I only mention it because I noticed them looping in hppa's efforts to get ready to get back into the archive (tries, fails, dep-waits, dep-wait gets cleared because wb doesn't know about universe not being avail to main, repeat)
<lamont> pitti: yeah thouse./
<pitti> lamont: they are on anastacia output; I'll get them fixed soon, thanks
<pitti> I just wish anastacia wouldn't be so cluttered with mobile stuff...
<seb128> pitti: https://wiki.ubuntu.com/MainInclusionReportFastUserSwitchApplet ;)
<iwj> pitti: Did you do any manual vt switching before it went wrong ?
<pitti> iwj: yeah, I stopped and restarted gdm from vt1 after the dist-upgrade
<pitti> iwj: maybe it's best to just reboot this bloody thing and test again
<StevenK> pitti: I can take one of them if you want to look at the other. My machine is busily rebuilding ghc6, so a test-build could take a little longer than usual.
<pitti> StevenK: test build?
<pitti> StevenK: it's just reviewing/promoting them, possibly involving a MIR
<StevenK> I shall leave it alone then. :-)
<iwj> pitti: Well, these things ought to work.  I don't understand why ck is fighting with other programs over vt switches.
<pitti> seb128: rarian is in main, too, btw; so if you are confident in it for tribe 4, please seed it as well
<iwj> I suppose it needs to fight with exiting X servers.
<pitti> hm, I have CK running for a few days already, so that wasn't installed just today
<seb128> pitti: yeah, it's on my list, trying to fix some issues still
<pitti> seb128: if we don't do it for T4, that's perfectly fine for me; I'd just like to know what to watch out for
<iwj> pitti: There's a new thing in latest ck and gdm which might cause what you're seeing.  Ie, a new thing I did.
<iwj> I only did the briefest of tests with the gdm I merged yesterday; perhaps there's some conflicting logic.
<jwendell> Hi, seb128
<jwendell> seb128, the fast switch user you said in your blog is that one: http://ignore-your.tv/fusa/ ?
<seb128> jwendell: no, read the comments on my blog entry, there is a link to the fedora wiki
<seb128> hi jwendell
<jwendell> :)
<pitti> seb128, Riddell, Hobbsee: WDYT is worth mentioning on the Tribe 4 wiki page from the Gnome/KDE front?
<Hobbsee> pitti: seb128 answered some of that earlier.
<Hobbsee> pitti: the stuff in http://blogs.gnome.org/seb128/2007/08/02/ubuntu-desktop-updates/
<Hobbsee> pitti: kde 4.0 beta 1
<seb128> pitti: GNOME 2.19.6, fast user switching and consolekit, gnome-keyring pam integration, rarian, tracker
<seb128> pitti: do you still have to review the fast-user-switch-applet today so I can commit consolekit and that? ;)
<pitti> seb128: yeah, I will
<seb128> thanks
<pitti> seb128: currently doing the bits of MilestoneProcess, then I'll turn to that
<pitti> seb128: tracker still needs those b-dep fixes, btw, before I cannot promote it
<seb128> pitti: I did upload that like an hour ago
<pitti> seb128: you are too fast for me!
<pitti> seb128: (for changelogs.u.c. anyway)
* pitti hugs seb128
<seb128> well, the list of new things is not short and I would like to get most of it landing before next tribe ;)
* seb128 checks on the schedule when if feature freeze
<Hobbsee> aug 16 or something
<seb128> so tribe5?
<Hobbsee> sounds about right, from memory
<seb128> k
<seb128> I was not sure if that was the coming tribe or the next one
* lamont ponders the meaning of  /usr/include/glib-2.0/glib/gthread.h:335: error: cannot convert 'volatile gsize*' to 'void* volatile*' for argument '1' to 'void* g_atomic_pointer_get(void* volatile*)'
<seb128> anyway would be better to land things now so they get testing
<lamont> beyond "you're screwed" that is
<seb128> lamont: "update your glib2.0 to a fixed version"
<seb128> that's what it mean :p
<lamont> oh, rock
<lamont> iz glib bug.  got it
<seb128> yeah
<seb128> I've fixed it like 1 week ago
<seb128> what version do you use?
<lamont> hrm... I hope glib2.0 builds this time, instead of timing out in the tests
<pitti> seb128: tracker will be in desktop seed?
<lamont> libglib2.0-0_2.13.7-1ubuntu2_hppa.deb is what I currently have in the archive....
<pitti> seb128: gnome-keyring pam integration> ah, it won't ask you for the keyring password by default any more?
<seb128> pitti: if your keyring password is the same as your login one, no
<pitti> cool
<seb128> lamont: 2.13.7-1ubuntu3 is the fixed version
<lamont> and 1ubuntu4 is current
<seb128> pitti: tracker, I think so
<seb128> lamont: right
<seb128> pitti: I'm not 100% happy with it but we need to give it some testing, might roll back if that's not good enough
<pitti> seb128: right
<asac> calc: can you please try if my crazy nm.dev branch cures you?
<asac> calc: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev
<calc> asac: ok i'll take a look at it
<asac> calc: its an all-in branch ... just branch and build ... no need for an orig et al
<calc> asac: ok
<iwj> pitti: I can reproduce your can't-select-text-vt thing.
<pitti> iwj: good! it does seem to be a race somewhere
<iwj> ck is fighting you is the problem.
<iwj> It thinks you're an exiting X server.
<pitti> heh
<doko> calc: new glibc-2.6.1~pre packages in the archive; please update and make sure that you reinstall, overwriting my packages from puc.
<calc> doko: ok
<pitti> ogra: just gently poking you about the two tribe-4 bugs in ltsp? we already moved them two times
<pitti> BenC: there are currently 5 tribe-4 kernel bugs (one is fix committed); for the sake of planning and NEWing, do you mean to have another upload today, or shall we move them over to Tribe 5?
<pitti> cjwatson: that gfxboot vs. syslinux bug (118744) -- is that something you still plan for T4?
<BenC> pitti: let me check them..the main one I want to for tribe-4 is this AMD mobile timer problem
<pitti> mathiaz: I take the liberty and sponsor bug 129920
<ubotu> Launchpad bug 129920 in apache2 "/var/lock/apache2 has wrong owner and group for webdav" [Low,In progress]  https://launchpad.net/bugs/129920
<pitti> BenC: oh, dynticks on amd64? yay
<BenC> pitti: No, lost timer interrupts on Turion when running 32-bit kernel
<asac> calc: any news?
<calc> asac: not yet i was in the middle of working on an OOo build
<calc> asac: i am going to try to build it now
<Riddell> iwj: if ubuntu is having consolekit installed by default, will that be required by HAL as I believe it is in fedora?
<pitti> Riddell: no, it's not required at all ATM
<Riddell> ok, so I don't need to worry about making KDM talk to consolekit
<doko> calc: if aot-compile still fails, please give me the failing jar file
<pitti> Riddell: our hal has CK disabled ATM
<calc> doko: ok
<pitti> Riddell: I might look what that actually does (I think I have an idea), and turn it on if it is compatible with CK not being installed
<iwj> Riddell: You should test that ck doesn't fight with kdm.
<iwj> But only after the upload I'm going to make shortly :-).
<pitti> iwj: oh, you fixed it already? awesome
<Riddell> pitti: it doesn't seem to be, judging by fedora's experience
<iwj> I'm testing my fix but I'm pretty sure it will work.
<Riddell> iwj: what does the fix do?
<fdoving> seb128: as you're the glib/gtk guy, can you figure out something usefull from https://bugzilla.novell.com/show_bug.cgi?id=294385 ? - that's making konqueror with nspluginviewer (flash) and openoffice.org among others, unusable on gutsy.
<ubotu> Novell bug 294385 in KDE "nspluginviewer block konqueror and takes 100% CPU" [Critical,Assigned] 
<iwj> Riddell: Makes it not fight with X's VT switch except once after a session ends.
<seb128> fdoving: looking, calc said that openoffice is working correctly with 2.3 and he wants to do the update soon
<fdoving> seb128: i care more about nspluginviewer, but it also kills acroread for example.
<iwj> pitti: consolekit_0.2.1-1ubuntu2 should fix it for you, just uploaded.
<pitti> yay
<seb128> fdoving: acroread http://www.adobeforums.com/cgi-bin/webx/.3bc4895e
<cjwatson> pitti: yeah, I'm going to sit down on Monday and see if I can squash that once and for all
<pitti> cjwatson: good, then I'll leave it to T4 for now, thanks
<seb128> fdoving: I'm not convinced that's a GTK bug
<mathiaz> pitti: thks for the sponsor.
<seb128> fdoving: openoffice and acroread seem to be bugs from those applications and there is no indication that's not the same for nspluginviewer
<fdoving> seb128: well, it works if i build gtk with glib 2.13.5.
<seb128> fdoving: that doesn't mean they are not doing something wrong which used to work because GTK+ was permissive on it
<fdoving> seb128: true..
<pitti> tepsipakki, bryce: erk, current live CD fails to start X with "SubSection is not a valid keyword in this section" (in section "Display"); WTF?
<calc> asac: about to reboot and try out the new nm branch on i386 gutsy
* calc bbl
<asac> calc: ok ... already build?
<pitti> bryce: ok, I tracked it down, see bug 130206
<ubotu> Launchpad bug 130206 in xorg "X.org fails to start: "SubSection is not a valid keyword in this section"" [Critical,Triaged]  https://launchpad.net/bugs/130206
<Q-FUNK> a LinuxBIOS developer is asking me who he should talk to at Debian/Ubuntu, to ensure that the GRUB menu.lst generated by kernel packages will be compatible with options needed by FILO.
<Q-FUNK> who should I send him to?
<cjwatson> Q-FUNK: the kernel packages don't generate that directly; update-grub does it - so probably best send him to ubuntu-installer@lists.ubuntu.com
<Q-FUNK> cjwatson: noted.  thanks!
<calc> asac: doing that now
<pitti> bryce: wow, this is the first time EVER that the live CD correctly detected my screen resolution (through DVI cable; it has always worked through VGA); presumably this is because xorg.conf does not have any "Modes" any more by default; is that by design?
<pitti> bryce: hm, this could actually be related to above bug, since the bit of dexconf that writes this looks quite broken
<calc> asac: gutsy has diverged to much from tribe3 to be able to install the compiled debs :\
<asac> calc: well thanks ...
<asac> anyone else with ipw3945  here?
<pitti> bryce: I think I got down to the bottom of that bug now
<calc> asac: i could try it once i have time to upgrade my laptop to gutsy again, but that will be at least several days from now, since i need to try to get OOo 2.3 done asap
<asac> sure ... np
<asac> :)
<calc> i will hopefully have OOo 2.3 done by the end of the weekend, since OOo 2.2 is broken
<asac> calc: how large is the patchset we carry for ooo =
<asac> ?
<calc> and tribe4 is due next week .oO oh crap  ;)
<pitti> calc: so you intend to get this into tribe4?
<calc> asac: vs debian or overall?
<pitti> calc: typo: s/.oO/OOo/ :-P
<calc> pitti: yes, OOo 2.2 is broken at the source level apparently
<asac> calc: he? ... i mean the patches you have against pristine upstream sources
<calc> pitti: and i haven't looked into how to fix it for 2.2 since i expected to have 2.3 done soon
<pitti> yeah
<calc> asac: well ooo-build + debian dir is around 90MB i think (uncompressed)
<pitti> calc: broken in which way? I just tested current ubuntu i386 desktop CD, and it started at least
<calc> pitti: oh the claims i had seen were that it would not start at all
<calc> pitti: due to break in glib abi compatibility of something that wasn't guaranteed to be stable
<calc> if OOo 2.2 starts on current cd images then i have a bit of breathing room
<pitti> calc: from what I have heard, it does work if you have ooo-gnome installed
<calc> pitti: ok
<pitti> and spectacularly fails if not (e. g. when installing on ubuntu)
<pitti> erm, kubuntu
<calc> ok :\
<pitti> calc: so if all else fails, I think the current packages would at least not block the T4 release
<pitti> seb128: wow, upstream bugs for f-u-s-a look scary
<doko> calc: may I have a look at the source before you upload?
<calc> doko: i had to disable java for a different reason now its broken in another way, grr :(
<calc> after about 5min into the compile it dies
<pitti> seb128: fusa approved and promoted
<Kmos> # Add here commands to compile the package.
<Kmos> CFLAGS+='-fPIC' /usr/bin/make FOUND_PERL5=0 FOUND_RUBY=0 FOUND_PYTHON=0 FOUND_SWIG=0 FOUND_SPL=0
<Kmos> /bin/sh: CFLAGS+=-fPIC: not found
<Kmos> make: *** [build-stamp]  Error 127
<Kmos> someone knows what's that error about ?
<stdin> is that in a scrpt or makefile?
<Kmos> stdin: from debian/rules
<Kmos> http://launchpadlibrarian.net/7567284/buildlog_ubuntu-gutsy-i386.stfl_0.8-2_FAILEDTOBUILD.txt.gz
<Kmos> and the newest version on debian gives the same error
<Kmos> on my pbuilder for gutsy
<stdin> hmm
<stdin> because /bin/sh shouldn't be sourcing that, should be make
<Seveas> stdin, i think it does and then executes sh -c 'CFLAGS+='-fPIC' /usr/bin/make FOUND_PERL5=0 FOUND_RUBY=0 FOUND_PYTHON=0 FOUND_SWIG=0 FOUND_SPL=0'
<Seveas> which looks weird to me (the +=)
<stdin> yeah, += will work with make, but not in sh
<stdin> hmm, shouldn't there be a space after CFLAGS too ?
<Kmos> stdin: on debian it uses
<Kmos> the /usr/bin/make
<stdin> and after +0
<stdin> *+=
<Kmos> http://buildd.debian.org/fetch.cgi?pkg=stfl;ver=0.15-1;arch=hppa;stamp=1185653888
<stdin> yeah, shouldn't there be a space after CFLAGS tho?
<Kmos> CFLAGS +='-fPIC' $(MAKE) $(MAKE_FOUND_INTERPR)
<Kmos> like this ?
<stdin> yeah, that looks better to me
<Kmos> i'll try
<Kmos> if it builds
<Kmos> at debian it doesn't have that space
<Kmos> and it builds
<Kmos> strange
<lamont> doko: ping
<stdin> debian/rules is really a makefie, and I recall that there are spaces after the variable name and the oporator
<infinity> Who told you that?
<infinity> makefiles MAY have whitespace surrounding the operator, they don't HAVE to.
<Kmos> it doesn't build
<Kmos> dh_testdir
<Kmos> CFLAGS +='-fPIC' /usr/bin/make FOUND_PERL5=0 FOUND_SWIG=1 FOUND_SPL=1 FOUND_RUBY=0 FOUND_PYTHON=0
<Kmos> make: CFLAGS: Command not found
<Kmos> make: *** [build-stamp]  Error 127
<Kmos> pbuilder: Failed autobuilding of package
<lamont> uh.. .that's shell generating that error, not make
<lamont> well, that's make trying to run the binary CFLAGS
<infinity> Yeah.  DDTT.
<infinity> Put your variable assignment on a line of its own.
<infinity> Non-indented.
<Kmos> this is at build-stamp:
<Kmos> infinity: i'll try
<pitti> evand: were you ever able to get to the bottom of bug 122645?
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [Medium,Confirmed]  https://launchpad.net/bugs/122645
<lamont> seb128: glib2.0 tests seem to be running for a very long time...
<lamont>  /build/buildd/glib2.0-2.13.7/gobject/gobject.c:1776: warning: dereferencing type-punned pointer will break strict-aliasing rules
<Kmos> infinity: it gives error
<lamont> I wonder if that's bad
<Kmos> ebian/rules:22: *** commands commence before first target.  Stop.
<evand> pitti: yes, I have a patch, but I'm not sure why it works: http://people.ubuntu.com/~evand/tmp/18_stderr.patch
<Kmos> debian/rules:22: *** commands commence before first target.  Stop.
<pitti> kwwii: did you notice that the usplash progress bar recently got much too big and not centered any more?
<infinity> Kmos: http://cerberus.0c3.net/~adconrad/argh.diff
* lamont grumbles at glib2.0
<lamont> strace -p 4803
<lamont> Process 4803 attached - interrupt to quit
<lamont> futex(0x40a6088c, FUTEX_WAIT, 2, NULL
<pitti> evand: curious; did you show this to mvo already?
<lamont> something tells me it's gonna stay there for a while, too
<Kmos> infinity: nice, thanks
<evand> pitti: negative.  mvo, care to take a look?
<mvo> evand: the above patch? let me have a look. is it to fix the hang in gksu that seems to appear sometimes?
<mvo> evand: you remove the "-	gksu_context_launch_complete (context);" line, why is this?
<evand> mvo: yeah, stderr gets mangled
<mvo> evand: do you have a bugnumber for this?
<Kmos> infinity: it works, but there is more problem like that one in next steps of rules :)
<evand> mvo: it was a regression from 2.0.3, so to be honest I just diffed and stripped what I thought wasn't necessary.
<su-hoens> does dmraid work for sata?
<evand> mvo: bug 122645
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [Medium,Confirmed]  https://launchpad.net/bugs/122645
<mvo> evand: thanks, the launch_complete bit is something I would like to keep in, is there a testcase too?
<Kmos> $(MAKE) -C ruby$* clean && CFLAGS+='-fPIC' $(MAKE) -C ruby$* LIBS+="../libstfl.a -lncursesw" CFLAGS+="-I.."
<Kmos> CFLAGS again =)
<evand> specifically https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/122645/comments/6
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [Medium,Confirmed] 
<evand> mvo: it's hard to reproduce, it only seems to happen for some people, but basically:
<infinity> Kmos: Just remove that, since it's already set above.
<Kmos> infinity: yep, that's what i've done
<evand> mvo: take a live cd, comment out the try block on line 184 in /usr/lib/ubiquity/bin/ubiquity and run the installer.  Select manual partitioning, make some changes and hit next.  If the bug is reproduceable on your system it will hang.
<evand> there's probably a simpler test case
<zyga> mvo: hi
<mvo> hey zyga, long time not seen, how are you?
<zyga> mvo: yeah! I've been quite busy -- and still am unfortunatly
<zyga> I'm in Tokyo right now
<zyga> (I was in Poland before that)
<mvo> zyga: cool, that is quite a change
<zyga> I have no time to maintain c-n-f now
<zyga> maybe once I return home in october
<Seveas> I just found a nice c-n-f bug
<Seveas> dennis@mirage:~$ --moo
<Seveas> Usage: command-not-found [options]  <command-name>
<Seveas> command-not-found: error: no such option: --moo
<Seveas> bash: --moo: command not found
<zyga> Seveas: fixed
<zyga> Seveas: just not released
<Seveas> ah
<Seveas> no need to file then, was about to
<zyga> I didn't have the time to work on that in ages
<zyga> the patch basically adds '--'
<zyga> mvo: how about you? I see you are keeping busy as usual :-)
<Kmos> infinity: now it builds fine :)
<zyga> what time is it in EU right now?
<mjg59> Which bit of the EU?
<zyga> median ;] 
<mjg59> Somewhere between 17:31 and 20:31
<IntuitiveNipple> It's harvest-time!
<Kmos> 18:32
<Kmos> at Portugal =)
<zyga> one thing I hate about being here is the timezone
<zyga> the other is that tokyo is pretty much linux free :/
<Seveas> zyga, use ubotu as worldclock
<Seveas> @now Amsterdam
<ubotu> Current time in Europe/Amsterdam: August 03 2007, 19:33:13 - Next meeting: Kernel Team in 3 days
<zyga> :-)
<zyga> @now Tokyo
<ubotu> Current time in Asia/Tokyo: August 04 2007, 02:33:30 - Next meeting: Kernel Team in 3 days
<mvo> zyga: unfortunately yes :)
<zyga> time to sleep soon
<agoliveira> @now Joainville
<agoliveira> Bah :)
<mvo> zyga: its fine, thanks for keeping me updated, I will see that I maintain it and get it ready for gutsy
<zyga> mvo: I can help you get the most of what I have unfinished
<zyga> there is alot of interesting stuff that I started soon after feisty got released
<zyga> if you don't have the time to pick everything up then I'd recommend to get the UI fixes and improvements and leave the new build system untill someone finishes the process
<Kmos> infinity: patch sent to debian maintainer :)
<mvo> zyga: ok, thanks
<Kopfgeldjaeger> does the ipw4965 support monitor mode with the ubuntu drivers?
<Kopfgeldjaeger> (gutsy)
<dendrobates> jdstrand: did you see we got approved.
<jdstrand> dendrobates: yeah-- I thought the timing was funny
<dendrobates> jdstrand: in what way
<jdstrand> dendrobates: just that I thought you were still thinking about all the details (particularly remove/purge)
<jdstrand> dendrobates: but obviously that can still be worked out
<dendrobates> jdstrand: we can creep the scope a bit. It was implrtant to get it approved so we can be sure and get into gutsy.
<jdstrand> dendrobates: this is great news.  big steps towards easier network authentication.  users will be pleased
<jdstrand> dendrobates: you were generous to say 'we' too.  :)
<dendrobates> jdstrand: how well do you think the ini semantics work for the templates?   I know it is an RFC standard.
<jdstrand> dendrobates: you mean for auth-client-config?  I think it works fine, particularly since it is standard python config parsing.
<jdstrand> dendrobates: I should probably add a manpage for it though, now that you mention it
<dendrobates> for auth-client-config.  I like the python module, but wonder if in the long run xml doesn't make sense.
<dendrobates> Maybe both.
<jdstrand> dendrobates: I understand the attraction for xml.  I think the simplicity of the code with ConfigParser as well as getting ordering lines (ie for pam) for free is nice too.
<jdstrand> dendrobates: I am open to other ideas though
<jdstrand> dendrobates: right now I am focusing on writing the tests, as well as verifying the state machine.  I also added an '-a' option, so you can specify just the profile instead of having to specify each type individually.
<dendrobates> jdstrand: I like ConfigParser as well.  It will do a good job for now, but we might want to keep a more complex solution in the back of our minds.  Just in case.
<jdstrand> dendrobates: will do
<dendrobates> jdstrand:  are you in Rochester NY?
<jdstrand> dendrobates: yep
<psusi> iwj: ping
<dendrobates> jdstrand: I've got lots of family there.  I go there every couple years.  Not the same since kodak had so many layoffs, though.
<iwj> psusi: Yes ?
<jdstrand> dendrobates: cool (not about kodak).  I am not from here, but been here 8 years now.
<psusi> iwj: wanted to discuss the relattionship between udev and lvm/dmraid with someone familiar with it... would that be you and do you have time?
<dendrobates> jdstrand: i have to get writing the the MIR's to get this auth stuff into main.  I'm a bit behind.
<iwj> I'm somewhat out of date but I may be able to help.
<jdstrand> dendrobates: I will keep plugging away at 0.3.  Did you want to talk about the ldap-client-config more now, or do you want to think about what we said earlier for a bit?
<dendrobates> I want to think about it.  We should bring others into the conversation as well.
<psusi> iwj: ok.... I think that right now, lvm operates by running pvscan, which essentially does an ls /dev/hd? and checks any found devices for lvm signatures, and when found, adds them to a list somewhere in /etc right?
<iwj> More or less.
<psusi> then later another utility looks at the devices in that conf file and tries to activate the list
<psusi> essentially then, lvm has no working relationship with udev at this time
<psusi> except that udev re-runs lvscan etc al on new device add events to rescan all devices in the system and add any new ones to its database and try to activate them
<psusi> right?
<iwj> More or less, yes.
<psusi> that's pretty crappy and we want it to work better with udev don't we?
<iwj> Err, well it's not wholly ideal but what specifically do you think is wrong ?
<psusi> well, several problems... one is that lvm on dmraid is broken because lvm wants to use the underlying physical disks instead of the dmraid device
<psusi> I would think the same problem would happen with mdraid
<iwj> This is just a general problem with autodetection.
<iwj> lvm knows about md metadata and avoids those partitions.
<iwj> Does dmraid put the metadata at the end then ?
<psusi> ahh, but not about dmraid?  k
<psusi> yea
<iwj> IDIOTS
<iwj> That CAN'T BE MADE TO WORK PROPERLY
<psusi> sure it can
<iwj> No, not reliably.
<psusi> why not?
<iwj> If you've got a disk that looks like this       lvm metadata | something | raid metadata
<iwj> how can you tell whether it's raid-in-lvm or lvm-in-raid ?
<psusi> hrm...
<iwj> What if in fact it was    lvm metadata | filesyste
<iwj> where filesystem happens to contain a user file containing something that looks like raid metadata.
<psusi> well, in the case of dmraid, it will ALWAYS be lvm on dmraid
<psusi> can't go the other way
<iwj> ... unless it's just a user file with some interesting data.
<iwj> Still as a workaround, teach lvm not to touch things with dmraid metadata.
<psusi> wouldn't be in the right location on disk, and the activation attempt would fail
<iwj> Then you're just left with the hideous security vulnerability and not an actual complete inability to boot.
<iwj> It might well be in the right location on disk.
<psusi> the right location is like the last cylinder of the disk, outside of any partitions
<iwj> If I'm a resourceful user I can probably fill the cause the bit of the disk where dmraid looks to look like a dmraid.
<iwj> If dmraid is outside any partitions then what's the problem ?
<iwj> LVM is inside partitions.
<psusi> the problem is that lvm is directly accessing the physical disk because it sees its header there
<psusi> instead of going though the raid device
<iwj> The problem is that the kernel is showing these partitions.
<psusi> yes, that is
<iwj> This isn't just a problem for lvm.  What if you have dmraid with a filesystem ?
<psusi> what do you mean?
<iwj> That is     partition table | filesystem | dmraid metadata
<psusi> the metadata is at the very end of the disk
<iwj> now the auto fs finder thingum will spot your fs and mount it by uuid.
<psusi> so it's outside the filesystem
<psusi> right... what needs to happen is for dmraid to "claim" the disk
<iwj> You have hda1 which containing 1234...., hdc1 containing 1234...., and dmraidsomething1 containing 1234... as well.
<psusi> so other components don't try to detect things in it
<iwj> Yes.  So nothing to do with lvm.  If you can stop partitions showing up then you're sorted.
<psusi> true....
<psusi> well, partly
<psusi> the second part of the problem is getting lvm to look for pvs in the dmraid device
<psusi> right now it only looks for them on /dev/hd? and not on other device-mapper devices, right?
<iwj> That part is probably easy.  You may need to add some dev patterns to the relevant udev rules.
<iwj> No, it looks for them on various other things too.
<psusi> well the udev rules just run pvscan... pvscan doesn't scan /dev/mapper/*
<psusi> does it?
<iwj> /etc/udev/rules.d/65-persistent-storage.rules is the relevant file.
<iwj> OIC
<iwj> You want pvscan to look at dmraid stuff.
<psusi> yea, you can run pvscan, but it won't do anything
<iwj> Yes, you'll have to patch lvm for that.
<psusi> right
<psusi> ok... now... I kind of don't like how lvm is not udev friendly
<psusi> I don't like seeing utilities detect hardware by stat()ing well known names
<psusi> so it seems to me that pvscan should be looking for disks to scan in the udevdb, where you can use attributes to easily control things like "claiming" devices so it doesn't look there
<iwj> Hah.
<iwj> What you really want is just an interface provided by lvm2 which can be called by udev, where udev can say `here is new block device which is one of your pvs'.
<psusi> plus when the state of the vg changes, i.e. if a pv goes offline, udev pushes that state change out to monitoring applications which can lead to things like desktop popups warning the user of a failed disk and degraded raid operation
<iwj> And never to pvscan.
<psusi> more like here is a new block device, scan it and see if it looks like a pv
<psusi> if it does, let me know and I will record that in my db
<iwj> udev already calls vol_id.
<iwj> To decide what kind of thing it is.
<psusi> then the other tools can consult the udevdb to see what pvs are there instead of its proprietary conf files
<psusi> yea... but lvm does nothing with that information
<iwj> Having that there is good because it's much faster than passing the device to every possible thing which might understand it.
<psusi> that's fine.... but my point is that once it is decided that the thing is an lvm pv, that fact should just be added to the device's udevdb attributes
<psusi> rather than recorded in an lvm conf file
<iwj> The whole thing with lvm's conf files in /etc is just hideously ebw.
<psusi> ebw = evil?
<iwj> Evil, Bad, and Wrong.
<psusi> yea
<psusi> that info should be in udevdb I think
<mweichert> I want to start ubuntu dev. What do you guys use for a python ide?
<psusi> I don't do python, but I use emacs for everything ;)
<psusi> iwj: so what do you think about moving it out of the /etc files to udevdb?
<iwj> I think lvm shouldn't depend on udev.
<psusi> why not?
<psusi> and where do you think the evil /etc stuff should be moved to if not udevdb?
<mweichert> does anyone use pydev/eclipse for their python development?
<iwj> udev is not an essential part of the system and shouldn't be made into one.
<iwj> Plenty of people are using lvm without udev and they will all come and murder you personally if you try to force them to have udev :-).
<mweichert> does anyone know how to get gtk "intellisense" working in eclipse? When I use "import gtk" I get the error "unresolved import: gtk" ?
<mweichert> I'm going insane here trying to figure it out!
<psusi> well I guess they could fall back to using the ebil conf files then ;)
<psusi> iwj: so where do you think the data should be moved instead of the ebil conf files?
<iwj> It would be fine if it had some kind of cache in /var/run.
<psusi> ahh, true
<psusi> but I'd rather have it in udev because it makes the information so much easier to share and access
<psusi> and build rules with
<psusi> I wonder if we can disable the partition detection in the kernel and let udev take care of that, and when it finds a dmraid disk, skip the partition check
<mvo> Riddell: I uploaded a new apt + rdepends, adept should be fine, but please keep a eye open in case of problems
<Riddell> mvo: ok, will do
<doko> seb128: does gtk support parallel builds?
<Riddell> mvo: do you know where the beryl kcontrol module has disappeared to in the merge?
<seb128> doko: what do you mean by parallel?
<mvo> Riddell: no, I guess it was never ported to compiz-fusion
<doko> seb128: DEB_BUILD_OPTIONS=parallel=... but it seems so
<doko> trying DEB_BUILD_OPTIONS=parallel=32
<desertc> Hello - I am taking a look at the Ekiga package, and I see that there was a security fix released (2.0.5) in February.  I wonder whether Feisty should not be updated from current version (2.0.3)
<desertc> Information identifying the release information can be seen on http://www.ekiga.org (second page of news, Ekiga 2.0.5 Released)
<seb128> desertc: new versions are not uploaded to stable, we backport patches rather
<seb128> not sure about what security issue you are speaking about
<mjg59> desertc: The security fix was backported to 2.0.3
<seb128>  ekiga (2.0.3-0ubuntu6) feisty; urgency=low
<seb128>  .
<seb128>    * SECURITY UPDATE: remote code execution via format string overflows.
<desertc> I understand that the security fix was backported to 2.0.3 -- thank you for your time
<seb128> you're welcome
<ynezz> any idea how to tell the 7.04 installer to perform "modprobe ide-generic" during boot? otherwise the installer can't find cdrom (new notebook)
<mjg59> Press alt-f2, hit enter, type "modprobe ide-generic"
<mjg59> Though this implies some sort of ridiculous failure on our part to begin with
<ynezz> i can't do alt-f2
<mjg59> ?
<ynezz> (initramfs) cat /casper.log
<ynezz> Unable to find a medium containing a live filesystem
<ynezz> I'm inside busybox
<mjg59> Oh.
<mjg59> In that case, I have no idea
<ynezz> i think, that there is no such option to specify additional module to load during boo
<ynezz> seems to be related to this http://bugzilla.kernel.org/show_bug.cgi?id=8835
<ubotu> bugzilla.kernel.org bug 8835 in Serial ATA "IDE CD/DVD RW drive ignored at boot with sata hd" [Normal,Closed: patch_already_available] 
<ynezz> thanks for looking into it
<ynezz> just wonder what to do now
<ynezz> patch a kernel and cook own install cd?
<wasabi> Hmm. apt-cdrom uses a "cdrom id". What is this?
<mikmor1> wasabi: I believe the id you are referring to is in the '.disk' directory in the base of the ISO
<wasabi> ahh.
<wasabi> And that's only required for apt cds?
<mikmor1> wasabi: Not sure.. however, I don't know of anything else that uses it.
<mikmor1> ynezz: If you want an external module to be loaded during boot, you have to use a driver disk. It doesn't work in Feisty Desktop, but it is fixed for Gutsy
<ynezz> mikmor1: ah ok, thanks
<mikmor1> ynezz: np.
#ubuntu-devel 2007-08-04
<ynezz> hm booted, but the installer is not usable in 800x600 :)
<ynezz> suppose it's this bug, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/38442
<ubotu> Launchpad bug 38442 in ubiquity "MASTER: Doesn't support < 1024x768 resolutions" [High,In progress] 
<ynezz> oh its bot
<ynezz> nice one :)
<mikmor1> I wonder how useful it would be to start up synaptic right after installing onto a device, so you could give the user the option to customize the installation from the live environment...
<mikmor1> not that it is functionally restricted, really.. but it might look nice
<jetscreamer> dselect used to be an option in d-i
<jetscreamer> during the install i mean
<jetscreamer> so there may even be an entry point
<mikmor1> i was thinking about Ubiquity
<jetscreamer> yes, but i was just cheering you on
<mikmor1> heh, thanks
<jetscreamer> personally i prefer being able to install all i want then
<mikmor1> i think it would be nice for users who haven't used ubuntu before (or linux)
<mikmor1> kind of adds a layer of "hey, look what you can do"
<jetscreamer> that too
<mikmor1> esp. since almost everyone is always connected to the internet anymore
<mikmor1> of course, if you aren't connected.. it might be confusing
<mikmor1> so maybe have it starting up contingent upon if you can connect to the pool
<mikmor1> anyway, just brainstorming
<jetscreamer> oh yeah ya'll don't have netinstalls
<mikmor1> ?
<ryanakca> Hey, can an Ubuntu dev help me with http://groupware.kubuntu.co.uk/openssl_0.9.8e-5ubuntu2.debdiff ? All I did was create a patch on apps/s_client.c, update changelog, add quilt to build dep, XSBC-Original-Maintainer/Maintainer fix, and add 'include /usr/share/quilt/quilt.make' to rules. But... there's a pile of extra changes in the debdiff.
<ryanakca> doko_: ping, you made the last change to openssl, right? Safe to ignore?
<infinity> ryanakca: Still here?
<ryanakca> infinity: yep, and I fixed the debdiff. https://groupware.kubuntu.co.uk/openssl_0.9.8e-5ubuntu2.debdiff
<infinity> No, you really didn't. :)
<ryanakca> no?
<infinity> Please, please, please don't add patch systems to packages that don't have them.
* ryanakca scratches his head and nods
<infinity> It makes the Debian<->Ubuntu delta much harder for us to maintain, honest.
<infinity> Your debdiff would have been all of two changed lines without that gratuitous change.
<ryanakca> Ah, ok, so, plain old seperate patches?
<infinity> Err, what?
<ryanakca> infinity: https://wiki.ubuntu.com/MOTU/School/PatchingSources ... udev:
<infinity> Err, no.  OpenSSL doesn't have any sort of patch system, please don't add one.
<infinity> pitti's tutorial there is great for people making their own packages, or learning how existing patch systems work, but please don't take it as a ringing endorsement to gratuitously deviate from Debian and inflate our merge diffs.
<infinity> Anyhow, I'm likely to be making an OpenSSL upload soon anyway, so I can just fix this bug at the same time and we can stop arguing about it.
<Riddell> infinity: I think python-kde3 needs given back, it's complaining that python-qt3 can't be installed but the new build can be
<infinity> synacktion: Also, doko's change to openssl is most definitely not safe to ignore. :)
<infinity> ryanakca: ^^
<infinity> synacktion: Sorry, misfire.
<ryanakca> infinity: I sent the patch itself to openssl-dev@openssl.org
<infinity> ryanakca: Well, that part's good, yes.
* ryanakca nods
<infinity> Riddell: Still looks uninstallable to me.
<infinity> Riddell: On i386, anyway.  The other arches seem happy enough.
<Riddell> guess the i386 python-qt3 is still on its way to the archives
<infinity> Oh, for some value of fine.  Some of them dep-waited on the new python-qt3
<infinity> s/Some/All/
<Riddell> I can live with dep-wait I guess, better than failing
<Riddell> infinity: I missing a (rather important) package, kdelibs5-data has vanished for 3.92.0-0ubuntu1~feisty2 in feisty-backports, any idea where it's gone?
<infinity> What source is that from?
<Riddell> kdelibs5, I guess it's because the i386 buildd was so slow
<infinity> I sure would like to know why LP doesn't think there's a kdelibs5 source package..
<Riddell> oh, sorry, it's kde4libs source
<Riddell> and I'm missing a versioned build-dep from kdelibs5 to kdelibs5-data, which is why a bunch of my builds failed
<Riddell> infinity: could you give back kdepimlibs kde4graphics kde4graphics kde4multimedia kde4games kde4edu once kde4libs 3.92.0-0ubuntu1~feisty2 i386 has reached the archives
<infinity> Yeah, the i386 build only recently finished.  You need to learn patience. :)
<Riddell> I've been waiting for it to compile all day, are backports lower priority for the buildds than gutsy builds?
<infinity> Yes.
<Riddell> suspected so
<infinity> I imagine the reasons for that should be obvious. :)
<Riddell> yeah, it's fair enough
<Riddell> but it makes it hard to have timely releases of new kde releases for my loyal fans, it's much easier just to compile them locally and upload and I know they're done
<infinity> Well, unfortunately, soyuz is a bit slow right now.
<infinity> Partially due to the 8000 build queue in lpia that slows some things down, partially due to a slightly braindead behaviour in slave-scanner.
<infinity> I'll be working on the latter with cprov later, once I'm done with lpia.
<infinity> The former is something we just have to cope with for now.
<Riddell> anyway, hope I havn't ruined your weekend by making you give back all those when kde4libs is done, I should be off to bed
<Burgundavia> infinity: are you building the entire archive for lpia? I thought it was just x86
<infinity> Burgundavia: Err, come again?
<mjg59> Burgundavia: It's x86 with different build optimisations, and we'll want different binary configuration from the same source package
<infinity> Burgundavia: It's a new dpkg arch so, i386 binary compatibility notwithstanding, you can't mix _i386.deb and _lpia.deb packages on the same system.
<Burgundavia> right, ok
<mjg59> And given that we don't have support for multiarch...
<infinity> mjg59: I totally have poor-man's multiarch going on here!
<mjg59> Yeah, and I had poor-man's multiarch implemented for installing i386 binaries on NetBSD 4 years ago
<mjg59> That doesn't make it /right/
* infinity grins.
<mjg59> Wow. I even wrote a paper for that conference.
<mjg59> I must have been feeling enthusiastic
<mjg59> Especially since they didn't do printed proceedings
<infinity> Trying to impress a girl, no doubt.
<infinity> I know that's the only reason I write papers.  Chicks dig a guy who can string multiple sentences together and still look hot doing it.
<mjg59> Gosh. I even went to Leeds to present it.
<twb> Hiya.  Edgy's casper could not netboot, Etch's casper could.  I'm looking at the casper 1.87 changelog in Feisty and it looks it can netboot now.  Could someone confirm this?
<lamont> doko_: that newer libtool (sans java) is there now
<calc> i'm testing my newly merged OOo 2.3 :)
<calc> only have some minor patches left not merged and doing the build now :)
* calc hopes the merge sped up the 4.5hr build time as well
<encompass> doko: I am looking at the restricted python module here... http://pypi.python.org/pypi/RestrictedPython/3.4.2 and finding that there is no specific package to handle this module... infact there is some duplicate code found here... http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=RestrictedPython&searchmode=searchfilesanddirs&case=insensitive&version=feisty&arch=i386 is it possible to pull restricted python out and 
<encompass> doko_: I am looking at the restricted python module here... http://pypi.python.org/pypi/RestrictedPython/3.4.2 and finding that there is no specific package to handle this module... infact there is some duplicate code found here... http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=RestrictedPython&searchmode=searchfilesanddirs&case=insensitive&version=feisty&arch=i386 is it possible to pull restricted python out and
<doko_> encompass: as I said before: better package the upstream version and check that zope3 still works with this one
<StevenK> Morning pitti
<pitti> hey StevenK
<encompass> doko: sorry, didn't know you responded... thanks, I will "try" I can bearly make my own packages as is.
<Riddell> infinity: aww, you never gave back those packages
<pitti> Riddell: shall I give back something?
<Riddell> ooh, please, kdepimlibs kde4graphics kde4graphics kde4multimedia kde4games kde4edu in feisty-backports
<Riddell> pitti: will you be able to look at our main inclusion requests before going on honeymoon? (when is that again?)
<pitti> Riddell: honeymoon starts at august 25, so yes
<pitti> Riddell: given back
<Riddell> thanks
<pitti> Riddell: not on ia64, though, since I guess that's busted anyway
<Riddell> I don't much care for ia64 :)
<mvo> infinity: could you please give-back debtags on amd64? and libapt-front on all arches?
<pitti> mvo: done
<mvo> pitti: thanks!
* pitti sighs and kicks the German langpacks from the amd64 live
<pitti> we're getting fatter and fatter with every tribe
<Burgundavia> pitti: we do ship two photo apps
<Burgundavia> if we kicked off gphoto we would win some space
<pitti> Burgundavia: gphoto?
<pitti> Burgundavia: you mean gthumb or f-spot?
<Burgundavia> gthumb, right
<pitti> yeah, that's a long-standing issue
<Burgundavia> since dapper
<coNP> BTW, ajmitch, do you think you will package f-spot 0.4.0 for the next tribe?
<pitti> last time I tried f-spot, its cam download sucked, not sure whether that changed
<Burgundavia> I think the one thing that would need to be done is the popup when a camera is entered
<pitti> Burgundavia: that's easily done
<Burgundavia> plugged in. wow, my english sucks tonight
<pitti> Burgundavia: if f-spot has a mode "download pics from the cam to that directory and display it", then all is well
<pitti> last time, this seemingly simple task was a mess
<Burgundavia> I own exactly 0 digital cameras, so I never use either
<ajmitch> coNP: most likely
<pitti> so, let's try
<pitti> wow, merely opening and closing f-spot makes it crash
<StevenK> What do you expect from an Mono application? :-P
<tepsipakki> pitti: does the xorg.conf generator (dexconf) work for you now?
<pitti> tepsipakki: I just dist-upgraded, will try now
<pitti> tepsipakki: that was an interesting race condition: you uploaded late enough for me not to see your version yet, and early enough so that the bug was already closed, so I didn't find it any more
<pitti> tepsipakki: with the result that I uploaded a fix, too, which was rejected :)
<coNP> By the way, has f-spot directory support?
<tepsipakki> pitti: heh :)
<coNP> I think without the ability to browse all images in a directory we should s/gthumb/f-spot/g
<pitti> tepsipakki: yeah, works fine now. It skips all the SubSection stuff
<pitti> tepsipakki: it is *soo* great that it doesn't hardcode the 1024x768 Mode limitation any more when it cannot detect the resolution
<pitti> tepsipakki: apparently X's own detection is much better and figures it out correctly
<mvo> has anyone tried the latest apt yet?
<pitti> tepsipakki: which means that after three years of Ubuntu I finally don't need to reconfigure my X after install \o/
<tepsipakki> pitti: yeah, there's been a lot going on in debian.. next thing to happen is that it doesn't need discover anymore
<pitti> tepsipakki: I know an awful lot of people with the very same problem (it's a showstopper for many of them), I'll ask them for testing gutsy :)
<coNP> mvo: /me reinstalled amarok with it
<pitti> tepsipakki: current xorg.conf is very clean; no triplicate wacom any more and such
<mvo> coNP: and that was fine I assume?
<coNP> Yes. It worked as usual.
<tepsipakki> pitti: really? that should be there I think..
<pitti> tepsipakki: oh, wait, that's still there, just somewhere else
<mvo> good :) thanks
<coNP> thank *you* :)
<pitti> tepsipakki: why does it need to be there three times? I don't even have such a thing
<pitti> oh, stylus/eraser/cursor
<pitti> tepsipakki: well, that might eventually go with 1.4 and hal input hotplug?
<tepsipakki> pitti: I've been following the wacom ml every now and then, and yes, input hotplug will solve that eventually
<pitti> tepsipakki: oh, something that is now missing are the font paths; that's on purpose?
<pitti> with all the InputDevice gone, I only have Device/Monitor/Screen/ServerLayout; that thing becomes manageable :)
<tepsipakki> pitti: yes, the ones that are needed (fixed fonts) are hardcoded on xserver build
<tepsipakki> the rest was just cruft
<pitti> tepsipakki: ah, the rest is handled on the client side? pango and such?
<tepsipakki> should be
<tepsipakki> if it works :)
<pitti> tepsipakki: what happens with WMs like fvwm which don't use pango?
<tepsipakki> pitti: seems to work just fine, I've tested that yesterday with a fresh install
<tepsipakki> I'm not that familiar with those
<tepsipakki> ..changes
<pitti> ah, great
<pitti> ajmitch: hm, so f-spot-import seemingly worked
<pitti> hm, except that the target folder is empty
<pitti> no, it's still as broken as before
<pitti> I told it to import to /mm/Fotos/<name> and don't import
<pitti> and instead it imported into ~/Photos
<StevenK> pitti: What do you expect from an Mono application? :-P
<pitti> and f-spot doesn't display any photos, most menu items are greyed out, I cannot select folders, etc.
<pitti> this thing sucks
<pitti> Burgundavia: it seems f-spot isn't anywhere near to replace gthumb ATM :(
<pitti>  Photos/2007/07/18/img_0001.jpg
<pitti> whoever came up with *that* directory layout must have been on utter crack
<pitti> yay, and that sigsegv again
<StevenK> Here's a question. Why was it even promoted to main?
<pitti> StevenK: it's in -desktop, and besides tomboy it's responsible for a lot of MB of CD space...
<StevenK> I don't think tomboy is as bad as that, though...
<pitti> no, probably not
<pitti> I never tried it, though (keeping TODO lists as a wiki is ... dramatically overengineered for my taste)
<pitti> some people like it, though, so if it works, that's fine
<pitti> but f-spot doesn't leave us in a good light, I'm afraid
<coNP> Why do we have f-spot in -desktop? Tomboy is fine IMHO. It definitely *works*.
<StevenK> It was added during Feisty, if I recall correctly.
<StevenK> (f-spot)
<pitti> coNP: not sure any more; desktop people wanted it because it's shiny
<StevenK> I've been told f-spot rocks. I remain unconvinced.
<pitti> well, YMMV; it never did what I wanted, but I might just be strange
<elmo> I've never had f-spot crash on me, FWIW and apart from the whole wanting to own the photos, I found it a nicer UI than gthumb
<pitti> I insist on keeping my photos in a sane directory structure; that's what mankind did for hundreds of years...
<pitti> elmo: might just be gutsy, or amd64, or whatever; as I said, other people seem to be much more lucky than me with this
<StevenK> Great. gtk2hs now fails the same way on i386 and amd64.
* StevenK uploads the first step.
* StevenK kicks pinentry, and ScottK for getting it promoted.
<pygi> hello
<pitti> hi pygi
<elmo> (but I did stop using it because of the 'all your photos are belong to me' thing)
<elmo> pitti: ah, right, yeah, I use/used it on edgy/feisty i386
* Fujitsu_ would use it if it wasn't for that.
<elmo> I don't suppose someone would be willing to try (again) to convince dbus upstream that 'restart your computer on upgrade' isn't reasonable?
<jetscreamer> ???
<jetscreamer> omg
<geser> pitti: is bug #114855 important enough to be milestoned or should I be more patient? Without the drivers for my wifi card (prism54) the gutsy kernel isn't of much use for me (still running the feisty kernel)
<ubotu> Launchpad bug 114855 in linux-ubuntu-modules-2.6.22 "prism54 and other wlan drivers missing in kernel 2.6.22" [High,In progress]  https://launchpad.net/bugs/114855
<sladen> ooh, all the team memberships are expiring again.  what joy
<pitti> geser: actually the window for a complete kernel upload is closed already, but if it's just a non-ABI-change of l-u-m, that's still fine
<pitti> geser: can you please mail BenC with the details?
<pitti> geser: or, if it's all in the bug, let me do it
<pitti> erk, metacity made my other xchat window disappear again, brb
<geser> pitti: it would be the re-addition of the missing drivers which got lost between the the feisty kernel and the gutsy one
<pitti> mailed
<geser> thanks
<sbalneav> Morning all
<pitti> hi sbalneav
<sbalneav> Hey pitti.
<geser> StevenK: have you some time to review bug #130348?
<ubotu> Launchpad bug 130348 in festival "[Merge]  festival 1.4.3-21ubuntu1" [Undecided,New]  https://launchpad.net/bugs/130348
<Hobbsee> mjg59: ...wow.
<StevenK> I'm still impressed at some of the downright stupid things Automatix has done.
<pitti> StevenK++
<Fujitsu> The killall -9 dpkg is a little evil.
<StevenK> A little?
<Hobbsee> pitti!
* pitti tickles Hobbsee 
* Hobbsee stomps on pitti's feet
* Fujitsu hides.
* Hobbsee throws pitti at Fujitsu 
* pitti throws a gummybear at Hobbsee 
<Fujitsu> Aw.
<Fujitsu> Mmm... gummybears.
* StevenK has Allen's snakes here.
* Kmos watchs the party
* Hobbsee hands it to Fujitsu 
* pitti throws a couple of crisps at Kmos 
* Hobbsee doesnt eat lollies.
<Hobbsee> that's...really...wow.
<Fujitsu> Hobbsee: What is?
<StevenK> Hobbsee: Which part?
<Hobbsee> Fujitsu: automatix report
* StevenK kicks Haskell for existing.
* Fujitsu looked at it himself 3 months ago, and has mostly recovered from the horrors.
<ajmitch> Hobbsee: where is that?
<Hobbsee> StevenK: particularly the parts where the system can be left unbootable
<Hobbsee> ajmitch: http://mjg59.livejournal.com/77440.html
<StevenK> Hobbsee: Indeed.
<ajmitch> ah, interesting
* Hobbsee has a horrible thought
<Hobbsee> automatix doesnt exist for gutsy yet, does it?
<ajmitch> I hope not
<ajmitch> but it most likely will be around
<Fujitsu> It should be soon.
<TheMuso> Shocking is only the start of the long line of descriptive words I'd use.
<Hobbsee> it's just going to be a lot easier to break your entire system, passing -assume-yes to apt on a development version
<elkbuntu> it'll happen, unless certain people get into really horrible accidents some time soon
<Fujitsu> Hobbsee: True, even better!
<Hobbsee> Fujitsu: although most of that breakage is gone now
<TheMuso> Wasn't easyubuntu created to combat automatix or some such?
<Hobbsee> TheMuso: yeah
<StevenK> TheMuso: Most of the descriptive words I'd use to describe Automatix are unprintable.
<TheMuso> StevenK: Same here.
<Fujitsu> StevenK: Mhm... Darn CoC.
* Kmos got scared after pitti crisps
<pitti> Kmos: don't worry, they don't bite back
<Hobbsee> TheMuso: it should be fairly sane, but the guy has no interest in ubuntu packaging
<elkbuntu> TheMuso, easyubuntu doesnt sell as many souls to the devil though
<Hobbsee> pitti: much.
<Kmos> pitti: hehe
<pitti> they just nibble a bit
<Kmos> :)
* Kmos remembers his best friend bought a scorpion imperial some days agoo
<Kmos> :)
* Hobbsee nibbles on pitti 
* Hobbsee "dinner #2?"
<sbalneav> ogra: ping
* pitti stuffs some herring into Hobbsee to quiesce her
<Hobbsee> i hope that's cooked!
<ajmitch> pitti: I'm afraid it'll take more than that
<Hobbsee> ajmitch: yes.  chocolate?  :D
<TheMuso> Hobbsee: I thought that would be desert.
<pitti> ajmitch: an entire whale?
<ajmitch> Hobbsee: I don't think chocolate & you would be safe
<Hobbsee> ajmitch: sure it is!
<TheMuso> ajmitch: Me neither.
<ajmitch> nor any form of caffiene
<TheMuso> Chocolate can be my best friend at times. :p
* Hobbsee doesnt go that crazy on caffiene
* Hobbsee just...relaxes a fair bit...
<ajmitch> Hobbsee: undoubtably that's because you're already a long way towards crazy? :)
<Hobbsee> ajmitch: hehe :)
<elkbuntu> ajmitch, 'towards'? dude, she's already there
* Hobbsee tickles elkbuntu 
<ajmitch> elkbuntu: well we're not quite sure just how far down that path she can go
<elkbuntu> ajmitch, since she didnt try tickle me on the plane to spain, she's not at the manical point yet
<ajmitch> you'll be glad of that, I bet
<Hobbsee> elkbuntu: we had a truce.
<Hobbsee> elkbuntu: i wanted to get some sleep at all on the plane.
<elkbuntu> Hobbsee, a manic wouldnt have remembered a truce enough to honor it ;)
<Hobbsee> haha
<Hobbsee> elkbuntu: well....if people piss me off by continually tickling me, or taking my stuff, then i *will* get pissed at them.
<TheMuso> lol
* TheMuso loaths being tickled.
<TheMuso> And will literally strike back if its done too much.
<Hobbsee> so, being pissed at you on the plane wouldnt have been so fun, especially with it being so long
<elkbuntu> Hobbsee, :)
<Hobbsee> elkbuntu: then agian, we were kinda close to the wing - so we could have had a wrestling match.  "oops, we lost elkbuntu out the plane, somewhere on the way to frankfurt"
<Hobbsee> :P
<ajmitch> strange people
<Kmos> hehe
<Hobbsee> ajmitch: yes, we know you're strange.  you seem to like being tickled, for one thing...
<TheMuso> hahahaha
<ajmitch> sorry, you're confusing me with someone else
<Hobbsee> ajmitch: seeing as there have been very few ubuntu developers in my house, that's kinda hard to do.
<Riddell> pitti: could you give back python-kde3
<pitti> Riddell: kicked
<Riddell> you're the best pitti
<pitti> no problem :)
<pitti> just watching postgresql build and run tests anyway
<Riddell> sounds about as much fun as watching big brother
* StevenK is trying to figure out why gtk2hs FTBFS
<pitti> Riddell: now that it actually works it is much better!
<bigon> hi,is it normal that I get: Failed to fetch ftp://archive.ubuntu.com/ubuntu/dists/gutsy/universe/binary-i386/Packages.bz2  Hash Sum mismatch ?
<coNP> bigon: I can confirm :)
<coNP> (not sure it is normal, though)
<pitti> http:// amd64 works here
<coNP> So it is not a bug, but a feature. Please buy a new computer.
<bigon> ^^
<TheMuso> Riddell: If you don't mind asking me, where does KDE 4 stand in regards to accessibility? I, and a few others from the community have asked the same question of the accessibility team for KDE, but with no answer...
<TheMuso> s/asking me/me asking/
<Riddell> TheMuso: qt4 has all the infrastructure and APIs and ATK standards, but it doesn't use the same corba protocol as gnome so none of the existing tools work
<Riddell> and I don't know of anyone working on equivalent tools
<Riddell> the best hope seems to be that qt will adopt a dbus protocol for ATK and gnome will follow and everyone will be talking the same
<TheMuso> Hmm ok. I need to see what I can do about trying to give them a shove to a more desktop neutral solution.
<Riddell> but it's quite frustrating after years of expecting qt 4 to fix everything and it hasn't
<Riddell> I don't think gnome is very enthusiastic about moving to dbus, it's too much work
<TheMuso> Out of all the freedesktop standards stuff, this is unfortunately one of the biggest things to not happen yet.
<TheMuso> I get the same feeling.
<TheMuso> Ok thanks for that.
<pitti> bye everyone!
<geser> doko: I've added the last changelog entry from Debian to bug #130348. But how does building with -v<last version in ubuntu> change a debdiff?
<ubotu> Launchpad bug 130348 in festival "[Merge]  festival 1.4.3-21ubuntu1" [Undecided,Incomplete]  https://launchpad.net/bugs/130348
<doko> geser: dpkg-buildpackage -S -v<version>
<geser> doesn't it only changes the .changes file? which isn't included in a debdiff
<doko> geser: sure, but how should one review a merge without knowning all changes?
<geser> doko: so I should simply copy all the new changelog entries into the comment field the next time?
<doko> geser: yes
<geser> ok, will remember for the next time
<geser> doko: is something still missing?
<doko> geser: I don't think so
<coNP> Can some core-dev review / sponsor my magyarispell REVU upload (http://revu.tauware.de/details.py?upid=6332), please?
<TheMuso> c
<TheMuso> ugh
<bigon> has someone already had a look at http://people.debian.org/~rleigh/pam/ to help debian (and ubuntu) to have an uptodate pam (it seems that that package a a nasty but rleigh had no time to catch it)
<booza> Hi all , where is the autostart function on a livecd , i want start firefox or something with the login in the livecd
* cjwatson tracks down the cause of the cdimage mkisofs breakage and files bug 130376
<ubotu> Launchpad bug 130376 in cdrkit "crash while checking MD5sums on jigdo include list" [High,Fix released]  https://launchpad.net/bugs/130376
<elmo> cjwatson: \o/
<ceztko> all: i am having troubles with the security repository of edgy...where i can signal problems about repositories?
<pygi> siretart, around by any chance?
<siretart> pygi: you're very lucky, but I'm at my gf's parents
<sbalneav> urgh, ltsp chroot isn't building.  What is it again to finish all postinsts?  dpkg -i --recover?
<kylem> dpkg --configure, i think is what you want
<kylem> if i understand what you're wanting
<mjg59> dpkg --configure -a
<sbalneav> ah
<sbalneav> right.
<sbalneav> durr
<pygi> siretart, oki, not urgent anyway. Do enjoy ;)
<mattwalston> There may be an issue with the repos.  See http://paste.ubuntu-nl.org/32516/
<dobey> works fine for me
<mjg59> mattwalston: More likely there's a cache between you and the server that's screwing things up
<mattwalston> mjg59: as in on my system?
<dobey> as in between you and the server
<dobey> your system isn't a single hop to the server
<elkbuntu> mattwalston, like your ISP
<mattwalston> elkbuntu: sounds about right, we have bellsouth afterall
<elkbuntu> haha
<lamont> will gutsy's udev work on feisty?
<stdin> possibly, but I wouldn't risk it if it's not in -backports
<lamont> stdin: ah, come on... where's your sense of adventure?
<stdin> on my development PC :p
* lamont backports udev
<Nafallo> the kernel didn't boot for me on feisty atleast :-)
<Nafallo> 9.25 I think I tried.
* jetscreamer votes for the death of udev, but is ignored
<pygi> hey folks
<tcleval> hi... after the last update my system is slow(3D), how do i know the list of packages of the last fiesty update ? i need to "downdate", so i get my 3D working fine
<geser> look in /var/log/dpkg.log (but it's not easy to read)
<tcleval> geser, thx i am going to read it
<geser> iirc aptitude has also an own log, if you use aptitude
<tcleval> geser, no i use command line :-)
<tcleval> geser, ok.. now i have the list of files based on the date of the update.. so how can i downdate?
<geser> downgrade aren't officially supported but works most of the time
<geser> you need to find an archive with the old versions or download the old .deb yourself
<tcleval> geser, thx.. i think the problem is the new mesa packages.. i ll try them  first
* pygi rolls on the:
<pygi> <geser> iirc aptitude has also an own log, if you use aptitude
<pygi> <tcleval> geser, no i use command line :-)
#ubuntu-devel 2007-08-05
<poningru> ...
<poningru> is the xorg.conf being horribly broken a known bug?
<poningru> latest live
<poningru> in the screen section there is extra 'Subsection "Display"' in between Depth and Modes
<sebas_> Hi, why is the ubuntu installation/boot/integrity check now less verbose than in previous versions?
<cypherbios> sebas_: because the end-user don't need verbosity?
<sebas_> cypherbios: yes, I thought something like that... but I would like
<cypherbios> sebas_: for ubiquity you can start it on debug mode; for boot you can remove the quiet parameter from the correct menu.lst line; and so forth
<stub> Launchpad is going down in 15 minutes for scheduled database maintenance
<mikmor2> cjwatson: Hello.
<mikmor2> Could someone direct me to the source related to building the Desktop distribution?
* Hobbsee pokes asac with a rusty fork
* Hobbsee waves
<Kmos> LP is back
* Kmos LP is back
<Fujitsu> Yay.
<Riddell> infinity: please give back kde4pim/3.92.0-0ubuntu1~feisty1
<jwendell> cjwatson, around?
<Hobbsee> jwendell: it is a sunday there...
<jwendell> Hobbsee, here too :)
<Hobbsee> :)
<mattwalston> Why are there so many how-to documents offering a fix for "slow to establish ssh connection" but a patch has not been offered?  Is this a feature that should be solved some other way?
<sbalneav> It's usually a dns problem.
<elmo> sbalneav: no, it's not
<mattwalston> sbalneav: a lot of how-to's suggest disabling GSSAPIAuthentication
<elmo> disabling GSSAPI authentication is a suitable work around for now
<sbalneav> elmo: Ok, I'll rephrase: every time it's been a problem for ME, it's been a dns issue :)
<mattwalston> elmo: Is there any reason that a patch should not be applied in  the repo
<elmo> mattwalston: (I am not the SSH maintainer but,) as I understand it, it's a complex problem that isn't just in openssh but goes all the way down the static to avahi and mdns
<mattwalston> elmo: oh ok, thanks
<elmo> mattwalston: because there are people who use GSSAPI and simply disabling it, especially in a stable release isn't appropriate
<mattwalston> elmo: good answer
* StevenK idly wonders how elmo got static instead of stack
<elmo> StevenK: because I'm a muppet
<StevenK> elmo: :-)
<StevenK> elmo: Too much C coding?
<elmo> StevenK: no, just a random malapproprism - the world's thankfully avoided me using C for the most part
<asac> Hobbsee: huh?
<Hobbsee> asac: any idea if the new thunderbird is majorly unstable for everyone, or just for me?
<Hobbsee> particularly with enigmail, which looks out of date
<asac> hmm ... not heard of any instability issues so far
<asac> will keep my eyes open when reading bug mail
<Hobbsee> ok
* Hobbsee is having to regularly xkill it
<asac> Hobbsee: are you using our package at all :) ?
<Hobbsee> asac: yes, i have been ever since i told you
<asac> stgraber: thats good news
<asac> Hobbsee: ok cool ... so what happens for you?
<Hobbsee> asac: and our enigmail, and it's been unstable ever since the tb update
<Nafallo> maybe Hobbsee uses automatix...
<Hobbsee> asac: window only partially redraws, thunderbird freezes, nothing useful in console output
* Nafallo hides quickly
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<asac> Hobbsee: hmmm ... desktop effects?
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<Hobbsee> asac: nope - kubuntu
<elkbuntu> lol
<asac> Hobbsee: hmm ... ok ... I will come back when i read bugmail :)
<Hobbsee> asac: cool :)
<asac> Hobbsee: what versions do you have?
<Hobbsee> asac: latest gutsy
<Hobbsee> oh *neat*.  thunderbird doesnt even start now
<pygi> :D
* Hobbsee ponders that
<Nafallo> _that_ was confusing. should have shown something in win 1 :-P
<Hobbsee> why, with a purged thunderbird and enigmail, and the .thunderbird/ moved out the way, would thunderbird not start?
<Hobbsee> Nafallo: it usually does
<Nafallo> yes. that's what's strange :-)
<Nafallo> it didn't
<Hobbsee> asac: absolutely no idea if this is helpful to you, or if i've called it right, but http://rafb.net/p/QmgCYQ99.html is thunderbird strace, then xkilled at the end
<Hobbsee> might be a starting point
* Hobbsee --> bed.
<pygi> night Hobbsee
<asac> Hobbsee: sleep well
<Hobbsee> will do
<asac> Hobbsee: need strace -f
<asac> as tbird forks a process right in the beginning ... just strace usually doesn't yield anything :)
* Kopfgeldjaeger test
* Kopfgeldjaeger test
<aaroncampbell> How can I find out who maintains the eclipse packages for kubuntu?  It seem that there is a problem, because I keep getting "IDEWorkbenchPlugin for bundle org.eclipse.ui.ide is invalid" but I can use the version I download from the eclipse site
<Kopfgeldjaeger> try launchpad.net
<desrt> aaroncampbell; you can usually get a good idea by looking at the changelog for the package
<geser> there is only one eclipse for kubuntu and ubuntu
<desrt> aaroncampbell; check in /usr/share/doc/[pkg name] /changelog.Debian.gz
<aaroncampbell> thanks
<Monk-e> Can anybody tell me why debhelper does a 'cat configure.sh>configure' if it (sometimes) finds a configure.sh file?
<Monk-e> (or actually pbuilder does it, but debhelper sets it up afaik)
<Riddell> pitti: ping
<Riddell> ok if I upload restricted-manager with kde stuff merged?
<pitti> Riddell: I guess that changes some bits in the core and gtk implementation?
<Riddell> pitti: yes
<pitti> Riddell: if so, I'd like to give this some testing and review first, if you don't mind?
<Riddell> sur
<Riddell> sure
<Riddell> it's in the k-r-m branch now
<pitti> ah, cool
<Riddell> 21:48 < pitti> Riddell: I guess that changes some bits in the core and gtk implementation?
<Riddell> 21:48 < Riddell> pitti: yes
<Riddell> 21:48 < pitti> Riddell: if so, I'd like to give this some testing and review first, if you don't mind?
<Riddell> mhb: ^^
<pitti> hi mhb
<mhb> hi Riddell, pitti
<mhb> pitti: of course
<mhb> Riddell: is there something wrong with adept?
<mhb> Riddell: libapt-pkg-libc6.6-6-4.4 breaks adept-batch, which breaks restricted-manager-kde
<Riddell> mhb: not that I know of, although mvo uploaded a new apt version recently
<Riddell> do you have the latest adept?
<mhb> Riddell: I cannot install it
<geser> why?
<mhb> like I said:   adept-manager: Depends: libapt-pkg-libc6.6-6-4.4 but it is not installable
<geser> which version of adept?
<Riddell> hmm, the new adept doesn't seem to have got through
<nixternal> I installed adept fine on my laptop and my amd64 desktop today
<geser> adept 2.1.3ubuntu4 is a rebuild for the new apt
<makkalot> Hi all i need to know how it is done the signing and verification of deb packages,i want to develop something similar based on public key infrastructure for another linux distribution,can someone point me a documentation or the software that does that job in ubuntu?
<Riddell> "gutsy amd64  Failed to build"  do you have an amd64 mhb?
<mhb> Riddell: yes
<Riddell> makkalot: it's just gpg
<Riddell> mhb: that'll be it then
<Riddell> pitti: could you give back adept on amd64, libept should be installable now
<makkalot> <Riddell>: isnt there a software which manages all the stuff for example certification etc
<pitti> Riddell: done
<nixternal> ahh, ya, my amd64 box doesn't have adept anymore...yay! :)
<Riddell> makkalot: as I say, it's just gpg verifying the signature on the md5sum, there's dozens of gpg tutorials on the web
<mhb> pitti: https://code.launchpad.net/~martin.bohm/restricted-manager/k-r-m
<mhb> oh rats
#ubuntu-devel 2008-07-28
<weirdbro> has anyone thought of integrating the Application Launcher menu with other programs that need to choose applications?
<weirdbro> Its just seems really silly to me that for Sessions, to add a new startup program, users need to find the binary file/terminal command
<weirdbro> when there's already a menu to do what they most likely want
<diogo> I really want to know why FGLRX 8.7 has better performance on blender when using ubuntu than on other distros... is this because of xorg... of patches...
<diogo> ?
<RAOF> diogo: We can't patch the driver, obviously (barring totally crazy binary patching).
<RAOF> diogo: apt-get source on the various components will get you the source package that the binaries are built from; I don't know of any specific "make fglrx magically faster" patches we apply, though.
<diogo> its just that it seems as fast as windows... and the other distros don't have this "fastness"
<diogo> its weird... I really like conary for example but rpath and foresight1s has not been so fast as ubuntu's xorg
<LaserJock> anybody know of a bug about audio "crackling" in Intrepid, even if volumes are muted?
<RAOF> LaserJock: No, but that sounds pretty cool.
<LaserJock> RAOF: rather annoying is more like it ;-)
<LaserJock> everybody looks at me funny when I start up Intrepid
<diogo> this is radio intererence I had it on my pc too... some sound cards has the "ability" of crackling when a frequency passes through it... this is a hardware thing... at least my case were
<RAOF> Oh, you mean on _startup_?
<RAOF> Yeah, I hear that.
<LaserJock> RAOF: well, it starts at the gdm login
<RAOF> On alsa init.
<RAOF> Ah, no, not than.
<RAOF> s/n./t./
<LaserJock> RAOF: and then thereafter any sound event get's a crackle
<LaserJock> it's over the top of the intended sound
<LaserJock> but when I mute the device I still get the crackle
<RAOF> Wicked.  How are you muting the device?
<LaserJock> just in the gnome volume control
<RAOF> I wonder if: (a) You've accidentally set the 'combine sinks to create one big virtual sink' option, then (b) pulseaudio is picking up pcspk, and (c) the default sink has somehow been set to the virtual combined sink?
<LaserJock> RAOF: well, this is off a fresh install of Alpha2 I believe
<LaserJock> so I'm fairly certain it's not something I did intentionally
<LaserJock> but I can perhaps look around to see if something like that has happened
<pwnguin> is there a built in mic on the computer running intrepid?
<tanath> anyone else get nothing on display when booting?
<Hobbsee> boot without splash?
<tanath> yeah
<tanath> at first i had no video output at all. now i just get a blank screen, until GDM
<tanath> and VTs don't work. get a corrupt display
<RAOF> I thought that got fixed in usplash; mine's working.
<tanath> hm
<tanath> i was wondering what intrepid would look like booting up, but didn't get to see. that was a while ago. still haven't seen what it looks like :P
<RAOF> Looks exactly like hardy, once you've got the fixed usplash.
<tanath> ah
<tanath> well the 'fixed' usplash may be what got me the blank screen as opposed to no output
<Fjodor> tanath: Your problem also sounds like what I used to see when the wrong framebuffer console driver got loaded. To test, you might want to compile your own kernel, either without framebuffer console support, or with just vesa or the one you should be using...
<Fjodor> And then report back
<pitti> Good morning
<emgent> moin pitti :)
<RAOF> Howbitie.
<RAOF> If you're up, maybe it's time to ping again about gnome-python-extras.
<RAOF> Debian's source package builds a couple of binary packages we don't, and I'm wondering whether that's a deliberate divergence or what.
<pitti> ScottK: sauerbraten-data seems fine to me? same version in hardy-backports as sauerbraten
<pitti> ScottK: (and intrepid)
<pitti> Hobbsee: yes, most probably
<Hobbsee> pitti: cool
<pitti> Hobbsee: promoted
<Hobbsee> thanks :)
<pitti> Hobbsee: (oh, that was about libltdl7-dev)
<Hobbsee> pitti: i figured, seein gas i only poked you about one thing :)
<tkamppeter> pitti, hi
<nxvl> hi all!
<pitti> hi tkamppeter
<tkamppeter> pitti, I have succeeded now to get the hal-cups-utils work with and without usblp now.
<pitti> tkamppeter: rocking! did you patch hal, or just h-c-u?
<pitti> tkamppeter: btw, I got your mails, but didn't catch up with them yet
<tkamppeter> There is only one small problem:
<tkamppeter> I patched only h-c-u.
<tkamppeter> When there is no usblp I trigger the script by the USB interface entry. With interface class 7 and subclass 1 I have a printer,
<tkamppeter> There is no device ID in the HAL DB then. So I poll the ID from the printer using libusb.
<ogra> no way to get it out of sysfs ?
<tkamppeter> This makes creating queues with the correct PPD, recognizing that there is already a queue, and re-enabling queues working as well as before.
<tkamppeter> pitti, problem is on turning off the printer. From a printer turned off I cannot poll the ID. I must use what got into the HAL database while the printer was on.
<tkamppeter> Here I can at best get manufacturer and model name as shown by lsusb (which is not as perfect as from the device ID) and the serial number (which is not reported by all printers).
<pitti> tkamppeter: hm, that sounds odd; even with usblp, the device disappears from hal once you turn your printer off
<pitti> tkamppeter: frankly, if the user turns off the printer while autodetection is in progress, I'd just silently exit
<tkamppeter> pitti, but with usblp the HAL database contains the device ID and it seems that the complete HAL database entry is sent to the scripts (as env variables) which a removal event happens.
<tkamppeter> pitti, I am not treating queue setup here but disabling the queue when the printer is turned off.
<pitti> tkamppeter: hm, doesn't cups care about this already?
<pitti> tkamppeter: also, why does the queue need to be disabled?
<pitti> if the printer is off, documents should just be kept in the spooler until it is turned on again?
<tkamppeter> pitti, no, CUPS does not disable queues on turning off printers.
<Mithrandir> why would you care about disabling the queue?  CUPS notices it can't send anything to the printer and waits.
<tkamppeter> pitti, many backends, like the usb backend of CUPS retry every 30 seconds, once using resources (filtering and rendering the complete job) and second popping up a tray message that the printer is not connected.
<pitti> tkamppeter: I still think that'd be the correct thing to do, but independently from that, how did it work in the past? you can't get info about hal nodes any more after they disappeared (when the printer is turned off)
<pitti> that seems pretty independent to the usblp issue to me?
<tkamppeter> pitti, with usblp you had the full device ID also on a printer removal event, as it was in the HAL DB and before HAL discards a DB entry on removal of a device it starts the removal callout supplying the complete DB entry to it as env variables.
<pitti> ah, I see
<pitti> tkamppeter: right, so ideally hal could still have the device ID without usblp
<pitti> s/could/would/
<tkamppeter> Without usblp the hal_lpadmin script is triggered from another HAL DB entry which does not contain the device ID.
<pitti> right, I understand
<tkamppeter> So I would like to know if I could do the following:
<tkamppeter> Printer turned on: hal_lpadmin script polls the device ID from the printer and WRITES it into the HAL database entry
<tkamppeter> Printer turned off: HAL database entry contains device ID and so printer can be identified as well as on turn-on event.
<pitti> tkamppeter: yes, you can use hal-set-property to add a property to a hal node; you need to be root for that, though
<tkamppeter> pitti, as hal_lpadmin is called by HAL, it runs as root.
<pitti> tkamppeter: so either hald itself detects the device id (if that's possible without much code), or you use hal-set-property
<pitti> oh, it's a python script, handy
<pitti> tkamppeter: /usr/lib/hal/scripts/hal-system-power-set-power-save uses hal-set-property (example)
<tkamppeter> pitti, as hal-set-property is a command line utility, one can call it from any language.
<pitti> exactly
<tkamppeter> Or are there python bindings for HAL
<pitti> tkamppeter: no, there aren't; from python you usually use straight d-bus calls to hal
<ogra> there are dbus bindings, hal understabds them
<tkamppeter> pitti, I have tried hal-set-property directly from the command line and it does exactly what I want. I can add properties to HAL DB entries now.
<pitti> great
<tkamppeter> Thank you for your help, pitti
<pitti> tkamppeter: no problem, I didn't do much :)
<pitti> tkamppeter: thanks for fixing it
<Hobbsee> pitti: what about libltdl7?
<pitti> Hobbsee: promoted, thanks
<Hobbsee> pitti: np
<Hobbsee> oh, sigh.  buildd.py's broken again
 * Hobbsee tries to remember how to redo the cookie
<jpds> ./cookies-sql2txt ~/.mozilla/firefox/*/cookies.sqlite launchpad.net > ~/.lpcookie
<Hobbsee> jpds: done that.  it still blows up
<jpds> Hobbsee: No error?
<Hobbsee> urllib2.HTTPError: HTTP Error 500: Internal Server Error
<jpds> Hobbsee: What are you trying to do?
<Hobbsee> retry imlib2 builds
<jpds> Yep, I get that error too.
<Hobbsee> pitti: remind me, how did this get fixed last time?  :)
<seb128> Hobbsee: previous time you were using the wrong cookie because you had several mozilla directories around
<Hobbsee> seb128: that's what i thought.  i checked that, and there's no more there.
<seb128> Hobbsee: ls .mozilla/*/*/cookies.txt?
<Hobbsee> .mozilla/firefox/4usr3i1j.default/cookies.txt
<seb128> Hobbsee: cp .lpcookie .mozilla/firefox/4usr3i1j.default/cookies.txt
<seb128> Hobbsee: and try again
 * pitti hugs seb128, bonjour
<Hobbsee> seb128: still dies.
 * seb128 hugs pitti, guten tag
<seb128> Hobbsee: suck to be you then ;-)
<Hobbsee> oh, ffs!
 * Hobbsee mutters at stub
<seb128> Hobbsee: maybe strace -e open -f buildd.py ... and see what cookie it opens
<Hobbsee> seb128: i've found the problem.
<seb128> ah?
<Hobbsee> looks like they've logged everyone out *again* today.
 * Hobbsee already got logged out earlier today.
<seb128> ah, yes, I did have to enter my login and password again this morning too
<Hobbsee> there we are.  now it's working
<seb128> good
<Hobbsee> seb128: thanks :)
<seb128> doh, I was looking to NEW apport-crash bugs this weekend
<seb128> there is around 3000 of those
<seb128> we should try to clean old ones or failed retracings
<seb128> the retracing success rate is also pretty low
<seb128> not sure of why though
<Hobbsee> hm, somehow i forgot that promotions aren't immediate.
<seb128> pitti: I'm wondering if we should not remove the dump and close automatically using a stock reply the bugs where retracing doesn't work correctly
<pitti> seb128: tricky question; in a lot of cases the retracers are broken
<pitti> but right, we'll hardly keep up with the flood anyway
<askand> Hi, how do one get blueprints approved?
<cjwatson> don't get overly obsessed with the status of blueprints. If it's something that you're capable of doing, then just go ahead and do it. (If it's not something that you're capable of doing yourself, then you probably shouldn't have registered a blueprint for it; they're detailed software design documents, not wish-lists.)
<cjwatson> if you're a developer, then the question you should be asking is how to get peer review for your design, rather than how to get the blueprint approved; and in that case the answer is to find a group of like-minded interested developers and talk to them about it
<askand> cjwatson:  ah thanks, in fact I am not asking about a blueprint I have made, but one that I do like the sound of. The creator of that blueprint asked in the forums how do get blueprints approved, I will forward your message :)
<cjwatson> askand: for non-developers, it's much better to use brainstorm.ubuntu.com than to use blueprints
<cjwatson> we have a problem at the moment that we have hundreds or probably even thousands of blueprints that weren't created by developers, aren't plausible software design documents, and can essentially never be approved
<askand> cjwatson:  I have indeed seen that problem arising too
<askand> However this wasnt a complex blueprint (at least it does not sound so to me as a non-developer), it was simply a blueprint about changing the default screensaver from black to something else to avoid confuse new users when the screensaver starts during installation
<cjwatson> so why is that a blueprint rather than a wishlist bug?
<cjwatson> it makes no sense for trivial things to be blueprints
<cjwatson> there has been a trend for people to follow up to all wishlist bugs and say that they should be blueprints, and it's completely wrong - complex things that require careful design work sometimes merit being blueprints, but simple enhancements don't
<cjwatson> anyway, the person involved should talk to the desktop team
<askand> cjwatson: hm, that make sense..here is the link to the forumdiscussion in case you want to write something there :) http://ubuntuforums.org/showthread.php?t=854500
<cjwatson> I don't
<cjwatson> I don't want to get involved in this, just offering general advice
<tkamppeter> pitti, applied changes to hal-cups-utils upstream, Ubuntu package will follow.
<norsetto> pitti: I have f*d up bug 249355, can we override the previous upload to hardy-proposed?
<ubottu> Launchpad bug 249355 in ocamlsdl "ocamlsdl and lablgl conflict over Raw" [Undecided,Confirmed] https://launchpad.net/bugs/249355
<pitti> norsetto: no, we can't; we can only do a followup upload
<pitti> norsetto: so you'd need a -8build2 which is in fact -7, if you want to revert
<pitti> norsetto: however, the changes in -8 don't actually look scary or intrepid specific
<askand1> Hi,  I talked to cjwatson about blueprints earlier and the problem with blueprints created by non-developers thinking that is the best way to get their ideas and wishes fullfilled. I begun to look and there are a lot of blueprints out there, many which only contains a link to a brainstorm-idea. Perhaps a sticky in the Intrepidsection in the forums would be good?
<askand1> A sticky about not creating blueprints of things you are not capable of doing yourself
<cjwatson> sounds good but the forums guys would have to do that
<askand1> Ok, I forward it to them
<norsetto> pitti: ok, you are right, the new dependancies dragged in are not hurting, quite the contrary
<tkamppeter> pitti, new hal-cups-utils uploaded
<pitti> yay
<AlexCONRAD> tseliot: hello ! I wanted to know if you were able to compile the latest ati drivers ?
<tseliot> ï»¿AlexCONRAD: what's the problem?
<AlexCONRAD> tseliot: there's no problem, I just wanted to know if were about to release the new ATI drivers that came out a few days ago... :)
<AlexCONRAD> I was looking at the xorg-driver-fglrx's version number. I have 1:7.1.0-8-3+2.4.24.13-19.45. Would this mean we're running the 8.3 version of ATI's drivers ?
<tseliot> ï»¿AlexCONRAD: yes, however the -envy flavour is 8.6.
<AlexCONRAD> tseliot: aah, good to know
<wgrant> Why does new GNOME feel that I need to be notified about the ability to change my screen resolution?
 * pitti joins the complaint
<james_w> through a libnotify popup?
<pitti> now I have this tray icon all the time
<wgrant> pitti: Right.
<pitti> which I don't want, and just wastes space
<wgrant> I would expect GNOME folks to get it right, of all people.'
<pitti> supposedly it only happens if you have more than one screen?
<wgrant> Not here.
<pitti> (I'm working in docked mode, with an external TTF on my laptop)
<wgrant> Well, I only have LVDS connected, but there are two other outputs...
<james_w> the randr capplet was merged upstream, I haven't seen what changes were made yet, it's perhaps related to that.
<wgrant> Anyway, it shouldn't be there. Like NM.
<wgrant> Except this has no reason to be here at all.
<seb128> re
<seb128> wgrant, pitti: calm down, the changes just landed upstream and it's still early in the unstable cycle
<pitti> seb128: oh, I'm not furious at all, just agreeing :)
<seb128> comment about GNOME not getting it right are not really useful there
 * pitti hugs seb128
 * seb128 hugs pitti
<seb128> well, having a rant on new changes because they are not perfect is not really constructive
<pitti> it's not exactly a bug, this looks like a deliberate decision
<pitti> but yeah, we'll figure it out soon enough
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=542822
<ubottu> Gnome bug 542822 in plugins "option to make xrandr status icon optional" [Normal,Unconfirmed]
<seb128> pitti: no, it's a bug
<james_w> from the code: http://paste.ubuntu.com/31247/
<seb128> james_w: right, that's mentionned in the bug too ;-)
<james_w> just seen it :-)
 * wgrant didn't see a rant.
<seb128> wgrant: your comments about expecting GNOME to get such things right are annoying and not constructive
<james_w> seb128: would you be ok with filing an Ubuntu bug milestoned for intrepid, or are you fine tracking it yourself?
<seb128> wgrant: the code is just new and needs some tweaking, that doesn't tell anything on GNOME choices
<seb128> james_w: feel free to open a bug but I'm already tracking it
<james_w> seb128: and thanks for forwarding all the other bugs to do with this.
<seb128> we will get bugs anyway so you can as well open one now ;-)
<james_w> heh :-)
<seb128> my please for the forwarding, having bugs upstreamed is good ;-)
 * pitti comments and subscribes
<pitti> seb128: thanks for the gnome #
<seb128> james_w: upstream did take the "don't apply changes immediatly" patch apparently, I noticed after the upload, I opened a bug upstream about the issue
<james_w> seb128: that's interesting, I wonder if they ended up doing it the same way.
<seb128> doh
<seb128> james_w: "didn't"
<pitti> I used the dialog this morning, and it felt pretty much the same as always
 * pitti agrees that "don't apply immediately" makes sense there
<seb128> that's basically the same code
<james_w> seb128: ah
<seb128> james_w: http://bugzilla.gnome.org/show_bug.cgi?id=545115
<ubottu> Gnome bug 545115 in Screen resolution "should ask for confirmation before writting the changes" [Normal,New]
<zul> morning
<glock> If i wanted to start contributing to ubuntu - would you guys recommend I start with bugs or look at something like the MOTU?    I have no experience with building debs, but could learn..
<cjwatson> I always recommend that people start by doing something they find interesting and that fixes something that annoys them personally
<cjwatson> https://wiki.ubuntu.com/ContributeToUbuntu may help - there are all sorts of avenues
<glock> The MOTU stuff seems nice with the sponsorship / mentoring kinda approach.  I can fix and work out bugs, just never know if im fixing things correctly according to the procedures. I guess the idea would be to work in as many teams as possible to gain an overall understanding, so was just looking where to start which would give me a good understanding
<pitti> seb128: FYI, I tried the upstream patch for gnome-keyring, didn't work; I reopened the upstream bug
<seb128> pitti: right I noticed the comment and it doesn't work for me either
<norsetto> glock: if you want a good overview about ubuntu development, you should look at this wiki page: https://wiki.ubuntu.com/UbuntuDevelopment
<saispo> any ftp maintainer in this room ? : )
<Hobbsee> wrong distro?
<saispo> Hobbsee: i think there is a "shitty" link on archive.ubuntu.com for a packages
<Pici> No need for the language.
<Lightkey> indeed, let us all switch to latin. english is so outdated
<ScottK> pitti: RE sauerbraten-data, Riddell took care of it over the weekend.
<Pici> Quod? Er, saispo can you provide an example?
<saispo> Pici: ie example
<saispo> lftp archive.ubuntu.com:/ubuntu/pool/universe/libn> ls -al libnet
<saispo> drwxr-sr-x    2 1001     1001         4096 Oct 30  2007 .
<saispo> drwxrwsr-x  135 1001     1001         4096 May 30 08:04 ..
<saispo> lrwxrwxrwx    1 1001     1001           63 Oct 30  2007 libnet1-dev_1.1.2.1-2build1_amd64.deb -> ../../../main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
<saispo> excuse me for the flood...
<saispo> i think one must be deleted or removed...
<\sh> saispo: no...it's correct...it was demoted to universe
<\sh> in hardy...
<saispo> drwxrwsr-x    2 1001     1001         4096 Jul 02 08:04 .
<saispo> drwxrwsr-x  135 1001     1001         4096 May 30 08:04 ..
<saispo> lrwxrwxrwx    1 1001     1001           63 Jul 02 08:55 libnet-ip-perl_1.25-2.diff.gz -> ../../../main/libn/libnet-ip-perl/libnet-ip-perl_1.25-2.diff.gz
<saispo> same for this ?
<saispo> i get some error when i try to build custom Ubuntu Cd with this links, but if you say it's ok...
<\sh> saispo: yes...it was moved from universe to main in intrepid...
<\sh> saispo: but the wonder is why do you have links?
<\sh> ah ok...you showed the source files
<saispo> yes
<saispo> i thinl dangling symlink is not a good idea to me
<saispo> s/thinl/think/
<\sh> saispo: how did you do the mirror?
<saispo> with rsync on an .de mirror
<\sh> use debmirror and everything is good :)
<cjwatson> it's not a dangling symlink.
<saispo> cjwatson: when you use COPYMODE in Ubuntu-CD it's a dangling symlink :)
<\sh> saispo: afaics there are no links on the webserver of the archive...if there are it's wrong imho
<cjwatson> saispo: that's a mirroring problem. it's not dangling on the master archive system.
<cjwatson> \sh: you're wrong on both counts, I'm afraid
<cjwatson> there are symlinks, and they're correct
<cjwatson> lp_archive@drescher:~$ ls -l ubuntu/pool/universe/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
<saispo> cjwatson: hmmm, see my copy/paste
<cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 63 Oct 30  2007 ubuntu/pool/universe/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb -> ../../../main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
<cjwatson> lp_archive@drescher:~$ ls -l ubuntu/pool/main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
<cjwatson> -rw-r--r-- 1 lp_publish lp_publish 339158 Jul 31  2007 ubuntu/pool/main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
<cjwatson> saispo: your mirroring setup is wrong. fix it ...
<devfil> pitti: there?
<saispo> cjwatson: hum, as you wish but...
<cjwatson> I've checked both the examples you gave and they are not dangling symlinks in the master archive
<saispo> cjwatson: must remove --links and --hard-links in rsync can be a solution ?
<\sh> cjwatson: well, it's not shown on the directory index of the archive
<cjwatson> \sh: that doesn't prove anything
<cjwatson> \sh: rsync archive.ubuntu.com:: shows the symlinks
<saispo> cjwatson: for example
<saispo> Copy: /home/eole/mirror/cdimage/scratch/eole/daily/tmp/hardy-i386/CD1/pool/universe/libn/libnet-ip-perl/libnet-ip-perl_1.25-2_all.deb => /home/eole/mirror/cdimage/ftp/pool/universe/libn/libnet-ip-perl/../../../main/libn/libnet-ip-pe+rl/libnet-ip-perl_1.25-2_all.deb
<saispo> cp: not writing through dangling symlink `/home/eole/mirror/cdimage/scratch/eole/daily/tmp/hardy-i386/CD1/pool/universe/libn/libnet-ip-perl/libnet-ip-perl_1.25-2_all.deb'
<cjwatson> saispo: the anonftpsync script included in cdimage already uses --copy-links to avoid this problem
<saispo> ok, thanks, will see it
<\sh> cjwatson: well...rsync is too slow from me here..that's why I'm using debmirror and http...and it doesn't show it to me using http..and avoids those problems.
<pitti> hi devfil
<cjwatson> \sh: sure
<saispo> thanks \sh and cjwatson
<devfil> pitti: you've worked at libgphoto2 in the past, so you probability know it, can you please take a look at bug #252408 ?
<ubottu> Launchpad bug 252408 in libgphoto2 "Please upgrade libgphoto2 to 2.4.2" [Undecided,Confirmed] https://launchpad.net/bugs/252408
<cjwatson> and the reason that they're symlinks is that, as \sh said, e.g. libnet1-dev was moved from main to universe between gutsy and hardy, but is at the same version in both, so we need the same file in the pool; symlinks save a good deal of disk space here
<cjwatson> same file in two locations in the pool, I mean
<pitti> devfil: thanks! I'll sponsor this (not right now, but today or tomorrow)
<devfil> pitti: thanks to you
<\sh> cjwatson: but that means, source one time in main, it's always symlinked to universe? regarding libnet-ip-perl it was in main (dapper) then demoted to universe and since intrepid again in main....
<devfil> pitti: I hope it is ok
<pitti> devfil: I'll follow up on the bug report if there are problems
<cjwatson> \sh: only if the same version is in main and universe in two different releases
<devfil> pitti: thanks
<cjwatson> \sh: in this case dapper is irrelevant because it's a different version, but the same version (1.25-2) is in feisty/gutsy/hardy universe and intrepid main
<cjwatson> \sh: this means that dists/feisty, dists/gutsy, and dists/hardy refer to it as pool/universe and expect it to be there, while dists/intrepid refers to it as pool/main
<cjwatson> \sh: so we move the file itself to main but put a symlink in universe
<\sh> cjwatson: ok
<tkamppeter> Whom should I as if I want to get admin of the ubuntu-printing Launchpad group?
<cjwatson> tkamppeter: the current administrator
<tkamppeter> cjwatson, thanks.
<tkamppeter> doko, ping
<doko> tkamppeter: done
<tkamppeter> doko, thanks, as I am doing all the printing stuff now and you do not do printing stuff any more, should perhaps the team ownership be transfered to me?
<doko> tkamppeter: sure, please do
<kirkland> cjwatson: hiya, I was wondering what you thought of the usplash patch attached to https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/251656
<ubottu> Launchpad bug 251656 in usplash "lsb calls to usplash_write should fail silently" [Undecided,Triaged]
<cjwatson> kirkland: looks fine
<kirkland> cjwatson: could I trouble you to sponsor the upload?
<cjwatson> kirkland: oh, except this is C so use /* */ comments rather than //. (Yes, I know C99 allows // ...)
<cjwatson> kirkland: sure, I'll make the comment change and upload
<kirkland> cjwatson: ;-)  i'll update the patch
<cjwatson> kirkland: do you have a bzr branch for it?
<cjwatson> kirkland: also, version number -> 0.5.23
<kirkland> cjwatson: I do not have a bzr branch
<kirkland> cjwatson: i'll pull one
<NCommander> seb128, morning
<kirkland> cjwatson: help me understand the bzr work flow ....
<kirkland> cjwatson: i should register a branch here?  https://code.launchpad.net/usplash
<cjwatson> no, create the branch locally then push it to the right place
<cjwatson> bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/ name-of-your-new-branch
<cjwatson> cd name-of-your-new-branch
<cjwatson> hack commit hack commit hack commit
<cjwatson> bzr push bzr+ssh://bazaar.launchpad.net/~kirkland/usplash/name-of-your-new-branch/
<kirkland> cjwatson: and the difference between https://code.launchpad.net/usplash and http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu is upstream vs. ubuntu's?
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu is a single branch associated with the upstream project https://code.launchpad.net/usplash
<cjwatson> the namespace on bazaar.launchpad.net is ~OWNER/PROJECT/BRANCHNAME
<cjwatson> in this case 'ubuntu' is just a conventional name rather than having any database-level association with Ubuntu
<cjwatson> put UNRELEASED in the changelog when committing; generally the uploader should be the one to set that to intrepid
<bryce> morning
<seb128> NCommander: hey
<kirkland> cjwatson: okay, so I've made the change to the C code...  do I update the changelog too, or not?
<kirkland> cjwatson: ah, make the changelog entry, but set to UNRELEASED
<cjwatson> yes
<NCommander> seb128, how are things going for you this morning?
<kirkland> cjwatson: okay, so my bzr diff looks like http://pastebin.ubuntu.com/31295/
<seb128> NCommander: busy as usual after the weekend but good otherwise, how are things going for you?
<NCommander> seb128, Eh, driving over the state of NY. Watching people play with the ne and improved REVU
<kirkland> cjwatson: adding link to LP #
<tkamppeter> doko, I cannot move team ownership. Can you look whether you are able to do so?
<seb128> NCommander: and people like the new REVU then? ;-)
<NCommander> seb128, it's not brown, which I think has shocked some people into submission
<seb128> lol
<NCommander> seb128, http://revu.tauware.de/
<dmishd>  Hello all.  Wanted to check on the process for getting a new upstream version of mypasswordsafe uploaded for intrepid.  I've packaged it in my ppa, registered it as a bug in launchpad, nominated it for release and subscribed the ubuntu-universe-sponsors.  Did that a few weeks ago and have heard nothing since.  Is it usual to wait for several weeks or is there something else I should do?
<dmishd>  The bug url is https://bugs.launchpad.net/ubuntu/+source/mypasswordsafe/+bug/221893
<ubottu> Launchpad bug 221893 in mypasswordsafe "MyPasswordSafe package needs updating" [Undecided,In progress]
<kirkland> cjwatson: okay, try this: bzr+ssh://bazaar.launchpad.net/~kirkland/usplash/usplash.251656
<cjwatson> kirkland: looks good, uploaded, thanks
<kirkland> cjwatson: cool, thanks for the bzr workflow details, i've added them to my process documents ;-)
<cjwatson> kirkland: you could just add a link to https://wiki.ubuntu.com/BzrContributorHowto :)
<kirkland> cjwatson: will do ;-)
<tkamppeter> doko, still there?
<doko> tkamppeter: yes
<tkamppeter> doko, I did not succeed to move ownership of theb ubuntu-printer group. Probably only you can do so. Can you check?
<mario_limonciell> pitti, i got a hold of some more broadcom hardware, but unfortunately LRM appears to be broke in hardy-proposed for the wl driver.  There wasn't an SRU bug opened for it's last upload, so what's the proper way to indicate regression in hardy-proposed?
<pitti> mario_limonciell: can you please open a new one and subscribe timg-tpi and ubuntu-sru?
<mario_limonciell> yup
<pitti> thanks!
<kees> tedg: okay, I'm sold on pulseaudio.  :)
<tedg> kees: What did it do for you?
<kees> tedg: though I think the volume control is a bit wonky, so I left my volume management attached to the ALSA output.
<kees> tedg: being able to move streams live... that's just bad-ass.
<kees> tedg: and the knowledge that when I feel like it, I can code up a "to-disk" sink like mplayer's --dumpaudio :)
<tedg> kees: Heh, yeah.  I think there's some great infrastructure there now, we just need to get apps using the power of it more.
<tedg> kees: I'd really like to see apps like pidgin have a volume control in their preferences.
<kees> there's some broken logic in libflashsupport that causes it to not select the correct pulse output (it seems to ignore the default), but after I sorted that out, I was golden.
<tedg> kees: Oh, cool.  A lot of people will be happy for you for fixing that :)
<tedg> kees: See, everything we do on the desktop is to make you happy.  You just have to trust us, and give us all your passwords.
<kees> tedg: I didn't fix it -- I just moved the stream to the right place.
 * kees cries quietly
<tedg> kees: Don't worry, it's flash, I'm sure that Adobe will submit a patch in just a few hours, or days, or decades...
<Laney> In CDBS, how can I pass options to my make target? I want it to be "make VERBOSE=1"
<pitti> Laney: DEB_MAKE_ENVVARS (real environment files) or just use CFLAGS
<pitti> Laney: see /usr/share/cdbs/1/class/makefile-vars.mk
<Laney> Oh whoops, I meant to say that in -motu
<Laney> but thanks pitti, will look into it
<slangasek> well, not CFLAGS in this case, CFLAGS="VERBOSE=1" doesn't sound like what you want :)
<pitti> Laney: erm, what did I say; s/environment files/environment vars/, of course
<Laney> That works great, thanks pitti and slangasek
<RichW> What channel do I use for Ubuntu PPA/Package Building?
<crimsun> RichW: #ubuntu-motu generally.
<totopalma> Riddell: can you please take a look at bug #250579
<ubottu> Launchpad bug 250579 in kdewebdev "Missing some xpm icons" [Undecided,Confirmed] https://launchpad.net/bugs/250579
<Riddell> totopalma: looks good
<Riddell> totopalma: ah, bug "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<Riddell> totopalma: uploading
 * totopalma hugs Riddell :)
<kees> lamont: when you get a moment, can you look at bug 252675?
<ubottu> Launchpad bug 252675 in bind9 "Please include 9.4.2-P2 patches in Hardy server" [Undecided,New] https://launchpad.net/bugs/252675
<lamont> kees: muppets
<lamont> I'll go look at it
<lamont> kees: ah.  yeah, when ISC releases the real (better performing) patch, we want it
<kees> lamont: okidoky
<lamont> generally, if ISC calls it -Pn, uh, we want it./
<lamont> whether for -security or -updates, that varies
<kees> :)
<lamont> but they don't do -P releases trivially
<mathiaz> slangasek: I'm about to send an updated cn=config patch to pkg-openldap
<slangasek> mathiaz: ok, cool
 * calc hopes he doesn't blow up his repo
 * calc is going to try to branch his 2.4.1 into 3.0.0 then merge debian into it, heh
<lamont> kees: likewise, I'm not going to release it before ISC. :-)
<lamont> and make that "they don't do -P releases without great care"
<lamont> s/trivially/frivously/
<lamont> or however that's spelled
 * lamont wanders afk for a while
<jdstrand> I find it curious that mk-sbuild-lv did not install apt for my intrepid chroot
 * slangasek looks at apt askance for pulling in wcatalan to satisfy the pam build-dep
<calc> wow OOo 3.0 source is big 314,704,496 for m28
<calc> not including diff.gz
<calc> they also have the source split up into bits but not buildable separately yet
<calc> at least its a step in the right direction
<asac> TheMuso, are you there?
<rubikcube> hi, do can someone please tell me where dpkg-reconfigure linux-image-${version} takes the modules from to compile into?  Only from /etc/initramfs-tools/modules or from other sources as well?
<NCommander> seb128, hola
<seb128> hello NCommander
<NCommander> seb128, got any more updates for me to tackle?
<seb128> NCommander: still don't want to do the glibmm, gtkmm, etc?
<jdstrand> dpkg: dependency problems prevent configuration of apt:
<jdstrand>  dpkg (1.14.20ubuntu3) breaks apt (<< 0.7.7) and is installed.
<jdstrand>   Version of apt to be configured is 0.7.6ubuntu14.1.
<jdstrand> well, I guess that answers that...
<NCommander> seb128, libglibmm-2.4-dev - I get these weird packages, and I can't pull a source package for them ...
<seb128> NCommander: did you try again?
<NCommander> yeah
<seb128> that's weird, those work just fine for me, what error do you get?
<NCommander> Right now, I'm updated to intrepid, but I couldn't get them in my chroot either
<NCommander> "Unable to locate source package for ..."
<seb128> NCommander: apt-get source glibmm2.4?
<NCommander> that works
<seb128> so what is the issue?
<NCommander> human error on my part :-P
<seb128> ;-)
<seb128> james_w: around?
<james_w> hey seb128
<seb128> james_w: hello, I don't get your comment on bug #252564
<ubottu> Launchpad bug 252564 in conduit "Please sync conduit 0.3.11.2-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/252564
<seb128> ah, you need somebody to approve the request you mean
<james_w> requeststnc by default assumes you have permission to upload the package, and so confirms the bug and subscribes the archive admin. I need sponsorship, so I unconfirmed and subscribed the sponsors.
<seb128> I was going to do sync the new version and just looked at the bug list and found your bugs there
<james_w> seb128: exactly.
<seb128> I'll ack it and sync then
<jdstrand> hmm, I grabbed the wrong dpkg up above, but still curious why apt wasn't pulled in be debootstrap...
<jdstrand> s/dpkg/apt/
<james_w> thanks seb128
<seb128> you're welcome ;-)
<seb128> james_w: oh, btw they undoed the bug #251508 changes
<ubottu> Launchpad bug 251508 in conduit "conduit missing dependencies" [Unknown,Fix released] https://launchpad.net/bugs/251508
<james_w> seb128: eh? the -2 upload was in response to me filing that in Debian, did the make a mistake with the upload?
<seb128> james_w: debian doesn't split python-desktop the way we do, the current package was not installable on debian
<seb128> python-gnome-desktop I mean
<james_w> seb128: oh really? oops, that's my fault.
<seb128> they just uploaded a -3 to fix those depends
<james_w> ah, I didn't see that.
<james_w> we can still sync -2 and we get what we want though right? :-)
<seb128> james_w: I just read the change on the debian -changes list
<seb128> james_w: the maintainer did an another typo, and we don't need those changes, python-gnome2 depends on python-gconf already
<seb128> james_w: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492767 for the record about the issue
<ubottu> Debian bug 492767 in conduit "conduit: unsatisfiable dependencies (one Ubuntuism, one typo)" [Grave,Open]
<norsetto> ubuntuism? lol
<james_w> seb128: so are we able to sync that version?
<seb128> yes
<james_w> seb128: great, thanks for your help
<seb128> np, thanks for working on reducing the debian,ubuntu delta for desktop packages ;-)
<seb128> enough for today, see you tomorrow
<TheMuso> asac: I'm around now.
<TheMuso> kirkland: If you have finished your work with those initramfs-tools/mdadm patches, is it ok if I look at them today, and merge the changes I need to make into initramfs-tools and upload both our changes?
<TheMuso> kirkland: I've noticed that you have made some nice improvements.
<kirkland> TheMuso: hiya!
<kirkland> TheMuso: well, actually, Kees just committed them today
<kirkland> TheMuso: we debated pinging you about it, but Kees got comfortable with the commit
<TheMuso> Fair enough.
<kirkland> TheMuso: I'd appreciate any feedback, though, even if in retrospect
<asac> TheMuso, great. would you mind to upload and push crimsun's alsa-lib branch?
<TheMuso> asac: I'd rather wait till we have 1.0.17 in the kernel.
<kirkland> TheMuso: the work isn't entirely done yet, either mind you, but we're at an incremental point where the commit makes sense and stands on its own
<asac> TheMuso, whats the point of waiting?
<TheMuso> asac: I've asked the kernel guys to look into that.
<TheMuso> asac: Mismatch/breakage between library and kernel space?
<asac> TheMuso, the branch just adds a single patch
<TheMuso> kirkland: Alright then, I'll just do the change I want to make then.
<TheMuso> asac: Oh its not to update to 1.0.17? Right, I can do that.
<TheMuso> asac: Will look at it this morning.
<kirkland> TheMuso: cool, there was one bug in there that I stumbled upon, in case you're interested
<TheMuso> kirkland: Sure, fire away.
<asac> TheMuso, its adding the pulse plugin by default so flash 10 works nicely for all
<kirkland> TheMuso: bit me for a while, until I figured it out ;-)
<TheMuso> asac: That wil affect KDE users.
<asac> crimsun, ^^ whats the idea for that?
<kirkland> in the local script, i had to initialize FSTYPE="unknown", if unset
<kirkland> TheMuso: in the case where $(fstype) runs, but doesn't find anything meaningful, it doesn't set FSTYPE="unknown"
<TheMuso> kirkland: Right.
<TheMuso> asac: I'll have a look at how he has done it anyway.
<asac> TheMuso, any idea if kde will adapt pulse at some point in the future?
<TheMuso> asac: I doubt it, Riddell would be abel to answer that better than I.
<asac> TheMuso, http://bazaar.launchpad.net/~crimsun/alsa-lib/ubuntu.new/annotate/9?file_id=use_pulse_pcmctl_by_-20080607184226-whgrt66pie4ls67q-1
<kirkland> TheMuso: anyway, minor item, but kept me bemused for a bit, why [ ! -e "${ROOT}" ] || ! $(get_fstype "${ROOT}" >/dev/null) || ! /sbin/udevadm settle wasn't doing what I wanted
<kirkland> TheMuso: and it was because $(get_fstype) was malfunctioning ;-)
<asac> TheMuso, i think if kde really doesnt use pulse, we need to have different configs for kde and gnome
<TheMuso> kirkland: Right,a fair Keybuk said that udevadm settle doesn't do what one sthinks it should.
<kirkland> TheMuso: anyway, I have to shift my focus this week to iSCSI, but I'm going to return and finish the RAID stuff thereafter
<kirkland> TheMuso: I have some bootloader changes to make, and want to add a deconf bit to mdadm
<kirkland> TheMuso: i think i'm probably mostly done with initramfs-tools, though
<TheMuso> kirkland: Ok.
<calc> ok i don't know if i screwed up or if lp is just slow
<asac> crimsun, will the config make alsa fallback to something if there is no pulse on the system?
<calc> i merged debian's ooo into my branch resolved the conflicts then bzr commit the change
<calc> but its not showing up on launchpad and a bzr update elsewhere isn't getting the revision i committed
<calc> do i have to push it?
<cjwatson> if it isn't a bound branch (bzr checkout, or bzr branch; bzr bind) then you have to push it manually
<cjwatson> you can use 'bzr bind' to convert an ordinary branch into a bound branch so that it gets autopushed
<calc> oh crap i committed it to the wrong branch somehow
<TheMuso> asac: It doesn't look like it.
<calc> is there a way to rollback cleanly like it didn't happen?
<cjwatson> bzr uncommit
<calc> yipee, thanks :)
<calc> so now i have it ready where i could push it but it says there is nothing to push
<calc> Checkout (format: pack-0.92)
<calc> Location:
<calc>        checkout root: .
<calc>   checkout of branch: bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/2.4.1-intrepid/
<calc> Related branches:
<calc>     push branch: bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/
<calc>   submit branch: bzr+ssh://ccheney@bzr.debian.org/srv/bzr.debian.org/bzr/pkg-openoffice/packages/openofficeorg/3.0/experimental/
<calc> i probably branched 2.4.1 to 3.0 incorrectly but it mostly worked, heh
<calc> do i need to redo the merge since it was a checkout of the wrong branch?
<asac> calc, if you uncommitted the merge then you probably have to redo
<calc> ok
<asac> calc, if you have a checkout you will auto-push. so your changes might end up in the checkout branch. not sure if that is what you want to do
<calc> i think i can make it redo it pretty easily by copying the conflict fixed files over to the new checkout after attempting a merge
<asac> calc, i'd suggest to use a full branch so you can decide when and where to push ;).
<cjwatson> calc: 'bzr unbind', or 'bzr bind bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/', before doing anything with that
<cjwatson> calc: otherwise you'll be committing directly to ~openoffice-pkgs/openoffice/2.4.1-intrepid on LP
<cjwatson> calc: looks like maybe you branched with 'cp -a' rather than with 'bzr branch'
<asac> cjwatson, why binding at all instead of branching and then pushing?
 * asac wonders if checkout gives any real performance improvements nowadays
#ubuntu-devel 2008-07-29
<cjwatson> asac: some people (myself included) find it much more convenient and less prone to human error
<cjwatson> I don't use it for performance advantages so have no idea whether it provides those
<cjwatson> I don't find that it has any performance disadvantages, and wouldn't expect anything either way really
<asac> human error == forgetting to push?
<cjwatson> yes
 * cjwatson is rather fed up of the tedious conversations that go "hmm, where's your change?" "I committed it" "did you push?" "oh, no, whoops"
<asac> hehe
<cjwatson> also checkouts mean you never accidentally commit to non-head and have to merge, so if what you want is a single mainline most of the time, then it's neater
<asac> cjwatson, hmm. good point. what happens if you commit and you have non-head on your disk?
<cjwatson> in a checkout, it refuses and tells you to update
<asac> right. does it smart merging then?
<cjwatson> normally neatness isn't a big concern of course, but when the branch is "current thing that's packaged in Ubuntu or next thing to be uploaded" then it's a bit more important
<cjwatson> it's just the same as pulling into a modified working tree
<cjwatson> it'll do a three-way merge if possible and leave you conflicts if it fails
<asac> for a moment i really forgot that you cant have more than one uncommitted change ;)
<slangasek> mathiaz: ah, I see you've been tracking the changes in the openldap package svn, since you patch applies cleanly... thank you :)
<mathiaz> slangasek: bzr merge FTW
<slangasek> indeed :)
<slangasek> in fact, did you have a bzr branch published, so that when the time comes I can merge it into the official repo?
<mathiaz> slangasek: I don't have a public branch
<mathiaz> slangasek: but I could push one to LP
<slangasek> that would be nice, then the bzr-heads can get the whole revision history in the tree :)
<mathiaz> slangasek: lp:~mathiaz/openldap/debian-cnconfig
<slangasek> wooho
<slangasek> o
<slangasek> mathiaz: is this a missing merge?:
<slangasek> -       if dpkg --compare-versions "$OLD_VERSION" lt-nl 2.4.7; then
<slangasek> +       if dpkg --compare-versions "$OLD_VERSION" le-nl 2.3.30-6; then
<slangasek> vorian: hrm, the lemonpos package in NEW appears to be empty.
<kees> Can I add a standing "remove from ubuntu archive" request for "joomla"?  it's itp in debian and really really don't want it in ubuntu given it's terrible security record.
<vorian> slangasek: let me take another look at it
<slangasek> kees: you can ask for it to be blacklisted preemptively, sure
<slangasek> kees: you can also comment on the ITP :)
<kees> slangasek: I would like that, yes.  standard ubuntu-archive bug?
<slangasek> kees: yes
<mathiaz> slangasek: not that I know of - It was just to keep the functions to handle a db upgrade around
<mathiaz> slangasek: upgrading from etch and hardy doesn't involve a db transition
<slangasek> mathiaz: hrm, then where did that line come from in the first place :)
<mathiaz> slangasek: IIRC it comes from dapper -> hardy support
<slangasek> ah
<kees> slangasek: jmm is all over the ITP already, I just wanted to block it Ubuntu too.  :)
<slangasek> mathiaz: er, that doesn't make sense to me either
<slangasek> mathiaz: hang on, will investigate
<slangasek> kees: \o/
<mathiaz> slangasek: upgrading from dapper (and sarge) required ldbm conversion
<slangasek> mathiaz: oh, I see; so the transition is already done on both sides, and this change will let us avoid unnecessary redumps on sarge->etch?
<mathiaz> slangasek: that function was used to handle the ldbm -> db transition
<slangasek> ... er, unnecessary redumps on etch->lenny
<mathiaz> slangasek: yes
<mathiaz> slangasek: as of now, this code won't be called in ubuntu (hardy -> ..) and debian ( etch -> lenny)
 * slangasek nods
<mathiaz> slangasek: however the package can be configured to dump the ldap tree to ldif on every upgrade
<mathiaz> slangasek: so some of the functions need to be kept around
<slangasek> yes, I'm not disputing that
<slangasek> I was just trying to figure out why the version number used in the check is different in your tree
<slangasek> mathiaz: we have a changelog entry here of "- need to dump and reload databases again for the upgrade from 2.3.39."
<slangasek> no other documentation, but apparently I was convinced of that in December
<slangasek> mathiaz: indexing issue; http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/2007-December/001819.html
<slangasek> (at a minimum)
<mathiaz> slangasek: right - so it seems that 2.4.7 should be kept
 * slangasek nods
<bryce> ogasawara: can you look at 204423?  Since it results in a system reboot it sounds like probably a kernel issue
<emgent> pitti: https://launchpad.net/~we-love-pitti big lol!
<ion_> :-D
 * slangasek squints at jbossas4.  How does a jar have a circular build-dependency?
<calc> ugh several packages need updating for the new libtool still
<calc> apt-cache showpkg libltdl3-dev
 * calc notes this is blocking OOo for the moment
 * calc is investigating to see what needs to be done now
<TheMuso> calc: I am having to relibtoolize pulseaudio as well, and its getting slightly annoying.
<slangasek> calc: ITYM "libtool needs fixing to provide libltdl3-dev"
<TheMuso> slangasek: there lis libltdl7
<slangasek> yes, I'm aware
<TheMuso> I'm trying to make use of that instead.
<slangasek> by provide I mean a literal Provides:
<TheMuso> ah ok.
<calc> slangasek: oh is that what needs to be done? then yea someone needs to fix that asap
<calc> slangasek: should i just upload a new version with just that one change?
<slangasek> calc: well, Keybuk didn't raise any substantive objections, so yes, that's the better way about it
<slangasek> calc: that would be fine, I think
<calc> ok
<calc> Keybuk: ping (sure you are awake at 4am right?) ;-)
<calc> er 2am
<calc> slangasek: oh was this already discussed elsewhere?
<slangasek> calc: only here, and not at any great length :)
<calc> slangasek: but scott is aware of the need to have the provides?
 * calc doesn't want to annoy anyone or potentially cause issues
<slangasek> calc: he punted on the question
<calc> ok
<calc> well it can be backed out later if needed i'll upload it here in a few min
<TheMuso> I wonder whether packages will still need relibtoolizing then...
<TheMuso> Because if not, I am willing to wait for that change.
<calc> maybe i should fix it up locally see if it helps ooo to build and then decide whether to upload it, heh
<slangasek> calc: it should be done anyway; if you prefer, I can do the libtool upload here
<slangasek> TheMuso: libltdl has very little to do with libtoolizing
<calc> slangasek: ok go ahead :)
<TheMuso> slangasek: Hrm ok.
<calc> i'll make the change locally and verify it works ok for OOo
<calc> but it will take several hours to build OOo
<slangasek> 0 upgraded, 122 newly installed, 0 to remove and 2 not upgraded.
<slangasek> build-deps ftw
<slangasek> does apt-get build-dep follow recommends by default now?
<calc> that would be bad
<calc> why does libtool depend on openjdk
<calc> "texi2html texinfo gfortran gcj automake autoconf quilt" - explodes into the world
 * slangasek lets pam and libtool battle for bandwidth
<calc> approx is great at least for repeated use
<calc> of course you still have to wait the first time you have to pull the debs
<ion_> Iâm using a generic HTTP proxy, polipo to be accurate. Havenât bothered to use a separate apt cacher.
<calc> 136MB build-depends for libtool (ouch)
<calc> i need better broadband
<TheMuso> Well the change to libltdl7 for pulse means that symbols cannot e found when building, so I'm digging into that.
<TheMuso> So even if libltdl3 was a provides, it may still break things.
<slangasek> what are the names of the missing symbols?
<TheMuso> slangasek: There is only one that I can see so far, lt_preloaded_symbols
<slangasek> hmm
<slangasek> well, that's not a symbol name present in libltdl3 either
<slangasek> so it's possible that this was a macro in the old version, but is now deprecated
<TheMuso> No I think it actually gets generated by the libtool bits for the package.
<TheMuso> the scripts rather.
<calc> wow libtool actually has a test suite it runs during build
 * calc thinks libtool might take as long to build as OOo
<slangasek> heh
<calc> hmm only 11m6s but it seemed longer than that
<calc> is this right: Provides: libltdl3-dev
<calc> even with that its claiming it needs to install the package
 * calc is either too tired to see the issue or is doing something wrong
<calc>   libgphoto2-2-dev: Depends: libltdl3-dev but it is not installable
<slangasek> that's right; I don't know what issue you're running into
<StevenK> Does libgphoto2-2-dev have a versioned dep on libltdl3-dev?
<calc> no
<slangasek> no
<calc> is there some sort of don't allow a provides satisfy a depends thing?
 * calc has no idea why this isn't working
<StevenK> The version of libltdl7-dev I have here doesn't have Provides
<calc> StevenK: i hacked a local copy
<StevenK> Why does the soname need to be in the -dev package name? :-/
<calc> http://pastebin.ubuntu.com/31539/
<slangasek> StevenK: doesn't
<slangasek> shouldn't be
 * StevenK gets tempted to fix it.
<slangasek> to make things even more incompatible with the archive? :)
<StevenK> slangasek: Well, if the new libltdl-dev Provides: both libltdl7-dev and libltdl3-dev?
<slangasek> sure; except Debian hasn't done that, so if packages come along with versioned deps on libltdl7-dev, hilarity ensues
<StevenK> calc: Did you just install that package directly? apt is trying to resolve it, and it doesn't tend to check installed packages
<calc> StevenK: yea i installed it directly
<StevenK> calc: Don't do that. :-)
<slangasek> huh?
<slangasek> apt doesn't try to install packages that are already installed
<calc> apt doesn't look at what is installed on your system?
<slangasek> (or complain about being unable to do so)
<crimsun> asac: no, that's currently not possible
<crimsun> asac: (meaning it's not possible to have a graceful fallback if you redefine pcm.default to have a different type)
<calc> StevenK: why isn't that a bug in apt?
<calc> StevenK: shouldn't it be looking at what is on the system to know if it needs to download something?
<crimsun> asac: for an example of a graceful fallback, you'd have to have something along the lines of what `asoundconf set-default-card foo' does, which means defaults.pcm.card gets redefined but defaults.pcm.device 0 is the fallback [for card 0]
<slangasek> calc: it's not a bug in apt because StevenK's comment has no correspondence to reality ;)
<calc> ok
<slangasek> unless what you did was install libltdl7-dev without *also* installing libltdl7, in which case apt might choose removal first
<StevenK> Try it? It will either prove me right or wrong
<calc> slangasek: well i rebuilt it without bothering to change the version number
<calc> then just installed the -dev package (the non dev was already installed)
<TheMuso> crimsun: So what is the use of your changes then?
<TheMuso> crimsun: As XFCE/KDE don't use pulse.
<crimsun> TheMuso: I was asked to draft a solution that doesn't involve a system-wide asoundrc
<StevenK> calc: I think that might be causing the problem. The version isn't different so apt is using what's in Packages file?
<calc> maybe so
<crimsun> TheMuso: I haven't finished hacking alsa-lib to fallback sanely if another type is used
<StevenK> And therefore doesn't "see" the Provides
<TheMuso> crimsun: Fair enough, but your changes are merged anyway.
<calc> that probably should be considered a bug that it isn't using the dpkg available file first (i guess that is where it should be getting the data?)
 * StevenK waits for slangasek to say otherwise again. :-)
<calc> i'll rebuild it with a bumped version number and see if it helps
<slangasek> StevenK: nah, now you're talking about a corner case I've never tested, then. :)
 * calc guesses he should file a bug if this works
<calc> its not ideal way to rebuild packages but it should still use what is actually on your system over what is in the archive
 * StevenK watches libtool build
<calc> StevenK: just get Keybuk to apply your change to Debian ;-)
<StevenK> 2.2.2-1 is in experimental, and 2.2.4-0ubuntu1 is in Intrepid
<slangasek> calc: Keybuk seems an unlikely person to do that, since he's not a DD?
<slangasek> (nor the libtool package maintainer in Debian)
<StevenK> It's Kurt now
<calc> slangasek: oh he's no longer a DD?
 * calc didn't realize he retired, heh
<slangasek> years ago
<calc> yea that was the problem apt doesn't look at the dpkg info unless it is newer than what is in its own Packages file
<slangasek> heh, ok
 * StevenK wins
<calc> so apt is stupid (my opinion of course) ;-)
<calc> is there a tool that can fixup the numbers in a diff?
<ion_> The numbers?
<calc> eg @@ -3,107 +3,114 @@
<ion_> rediff (1)           - fix offsets and counts of a hand-edited diff
<calc> ok
<pitti> Good morning
<Hobbsee> pitti!
<pitti> emgent: *cough* how embarassing...
<pitti> it's a Hobbbbbbbsee!
 * StevenK waves to pitti 
 * pitti sends a bunch of cookies to StevenK
<StevenK> :-)
 * Mithrandir grumbles.
 * pitti gives some to Mithrandir, too
<pitti> hey Tollef, how are you?
<Mithrandir> feeling grumbly today.   A bit too early and moving is an interesting exercise.
<pitti> Mithrandir: oh, different city, or just within?
<Hobbsee> pitti: it is!
 * Hobbsee freezes
 * pitti started early to still have some hours with moderate temperature
<Mithrandir> same city, but a semidetached house (I think that's the term) rather than a flat.
<pitti> ah, nice; sounds like an upgrade :)
<Mithrandir> absolutely.  It's just that moving is a bit of work with loads of planning and packing.
<StevenK> pitti: Send the "hot" weather here, I'd prefer it to 13 degrees
<Mithrandir> 13Â°C sounds lovely.
<Mithrandir> but then, aircondition is also lovely.
 * pitti doesn't like AC
<RAOF>  Who's syncing Conduit?
<RAOF> And why aren't they testing that it's installable first?
<TheMuso> RAOF: Changed-By: James Westby <jw+debian@jameswestby.net>
<pwnguin> plus addressing in a changed by?
<TheMuso> pwnguin: Thats how it appears in mutt/gnome-terminal.
<RAOF> In particular, conduit depends on python-gtkmozembed, which is built by debian's gnome-python-extras package, but not ours.
<RAOF> So, I'm not sure if the correct fix is to merge in gnome-python-extras from Debian or to change conduit.
<RAOF> Or, alternatively, split out python-gtkmozembed packages from our gnome-python-extras without merging from Debian, I suppose.
<Sikon> Could a main sponsor please look at https://bugs.edge.launchpad.net/f-spot/+bug/250047 ? Or is main frozen?
<ubottu> Launchpad bug 250047 in f-spot "f-spot FTBFS in intrepid due to deprecated symbols in libeog" [Wishlist,Confirmed]
<TheMuso> Sikon: Main is not currently frozen no. See topic.
<wgrant> Why is it Wishlist?
<RAOF> Sikon: That's a really odd patch description, too.  In what way are you adding missing headers?
<Sikon> ah, indeed, I should fix the patch description
<Sikon> reuploaded
<RAOF> Does anyone here know of any reason why gnome-python-extras hasn't been merged from Debian since Gutsy?
<RAOF> The debian package now builds a couple of extra binary packages; in the intrests minimal divergence I'd like to merge the Debian package.  This should make Conduit installable again.
<RAOF> seb128: Aha!  There you are.  You seem to have touched gnome-python-extras the most: ^^^
<seb128> RAOF: you are welcome to do the merge if you want, no reason we didn't do it out of the fact that it's not going to be trivial and that I was not convinced by their recent split
<RAOF> seb128: Thanks.  Given the 'not trivial', I might file that one away for the weekend.
<RAOF> You don't think python-gtkmozembed is a good idea?
<RAOF> Or python-eggtraywhatever it is?
<seb128> I'm just not sure there is a real need to split those
<seb128> but since debian did it now, we can as well reduce the delta
<RAOF> Right.
<seb128> the fun part will be to do -dbg variants for all of those
<RAOF> Oh, right.  Python.  I don't just get dbgsym for free.
<seb128> well, ideally those python-dbg should would have been sent to debian some cycles ago and we could just sync now
<seb128> but looks like doko have been too busy to send his changes and nobody else picked up on the job either
<RAOF> Oh, well.  A weekend of fun, I bet :).
<seb128> btw there is no need to do this merge to have conduit installable
<RAOF> True.
<mvo> Riddell: hi, thanks for your kde4 stuff, what is the package name for the qt4 designer? qt4-designer seems to be gone?
<seb128> so why did you said it'll make conduit installable again?
<RAOF> But other packages will start to move to the new package split,.
<seb128> the issue is just a typo which is fixed in -3 that we should sync when it's available
<RAOF> Because it will?  conduit currently depends on python-gtkmozembed
<RAOF> And that typo, yeah :)
<seb128> well, we can easily change the conduit depends too
<RAOF> Yes.
<seb128> or make python-gnome-extra provides the other debian binaries
<RAOF> But I presume that other packages will start growing dependencies on the split packages.  I think miro may have already.
 * mvo grumbles and just edits the .ui xml with emacs
<seb128> hey mvo ;-)
<RAOF> seb128: Tempting.  Are there any downsides to that?
<mvo> hey seb128
<Riddell> mvo: it is qt4-designer
<seb128> the provides are not versionned
<seb128> so if any package uses a versionned depends that will not work, otherwise that should not be an issue no
<Riddell> mvo: the package is qt4-designer, the binary is designer-qt4
<mvo> Riddell: aha, outdated sources.list, thanks!
<mvo> Riddell: should i merge your changes if they look good or do you have other things in the queue?
<Riddell> mvo: go ahead
<Riddell> mvo: oh well
<Riddell> mvo: DistUpgradeViewKDE4.py could be renamed back to DistUpgradeViewKDE.py
<mvo> Riddell: right
<mvo> Riddell: I can take care of the integration, thanks a lot for doing the port!
<mvo> Riddell: the new designer looks very nice, much better than the qt3 one
<tseliot> pitti: where do you keep the extra_conf_options that you pass as an argument to xorg_driver.XorgDriverHandler in Jockey?
<Mirv> mvo: do the new package description translations have (theoritically) everything merged from Debian's ddtp?
<mvo> Mirv: yes
<mvo> Mirv: they should, unless there is a bug in the script. the debian import is ~2-3 days old
<Mirv> mvo: ok, that's great
<Mirv> I have to try to check it. Some descriptions are different in Ubuntu but a good sample of some that have been recently translated in Debian would answer the question well enough.
<mvo> Mirv: please do and let me know your findings
<geser> soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge?
<jc-denton> how does the network manager talk to the wlan driver
<tkamppeter> Are there any plans to have Samba 3.2 in Intrepid?
<geser> !info samba intrepid
<ubottu> samba (source: samba): a LanManager-like file and printer server for Unix. In component main, is optional. Version 2:3.0.30-2ubuntu3 (intrepid), package size 3795 kB, installed size 9392 kB
<geser> tkamppeter: samba 2:3.2.0-4ubuntu1 is in intrepid but depwaits on libtalloc-dev
<jc-denton> does it use iwconfig?
<jc-denton> wpa_supplicant
<jc-denton>  /dev/somethign?
<geser> tkamppeter: and talloc is in universe
<tkamppeter> geser, thanks, so it is waiting for the approval of a MIR?
<geser> tkamppeter: it might be also waiting for a MIR to get written
<pitti> tseliot: in the concrete subclasses, such as NvidiaHandler
<pitti> tseliot: data/handlers/nvidia.py or fglrx.py
<pitti> tseliot: (in the ubuntu branch)
<tseliot> ï»¿pitti: ah, ok I was looking in the wrong directory. Thanks
<tseliot> ï»¿pitti: expect something new for xorg_driver.py soon ;)
<pitti> tseliot: what are you working on?
<pitti> tseliot: oooh, xkit?
<pitti> yay
<tseliot> pitti: xkit and some deeper logic
<pitti> tseliot: could you work on that relative to the trunk branch, not ubuntu?
<pitti> tseliot: a lot of xorg.conf scenarios have test cases already, and thus can be conveniently tested just with tests/run
<pitti> tseliot: that should provide a good first conformance test for the x-kit switch
<tseliot> pitti: ok
<pitti> tseliot: (well, xorg_handler.py are identical in trunk and ubuntu, so it doesn't matter so much)
<pitti> tseliot: many thanks!
 * pitti goes offline again for yet more gdm debugging, bbl
<tseliot> ï»¿pitti: ok, my branch will be based on trunk then.
<pitti> where's seb128?
 * tseliot goes back to hack on Jockey
<pitti> seb128: wb
<seb128> pitti: good morning!
<mpt> If an update is a "no change rebuild", why is Ubuntu offering it to me in the first place?
<mpt> (e.g. today's Firefox updates)
<Mithrandir> mpt: "no source change rebuild" is what is meant.
<StevenK> mpt: Because it was to pick up a library soname change or similar.
<StevenK> mpt: The binary packages will be different, the only source change was adding a changelog entry.
<mpt> That would be more useful information
<persia> mpt: More specicially, you need to have the update in order to use the new xul, which was a security fix.
<mpt> "This update uses the latest version of <library name> which does <faster/better/stronger>"
<persia> Well, we don't always know <faster/better/stronger> ...
<StevenK> mpt: Usually, I will have changelog entries like, "No change rebuild for libgpmg1 -> libgpm2 transistion."
<mpt> Otherwise, the only effect of showing the Changes in Update Manager will be to *discourage* people from installing it.
<mpt> (Which I assume is not what we want.)
<cody-somerville> \o\ Heya Everyone /o/
<_Angelus_> guys
<_Angelus_> will someday exist an ubuntu i686?
<_Angelus_> :p
<persia> _Angelus_: No.  There are support libraries for i686 in Ubuntu i386.  Alternately, lpia is close to i686.
<_Angelus_> so there is no plan of creathing a whole i686 ubuntu for download?
<pitti> _Angelus_: define what you understand as "i686 Ubuntu"?
<pitti> _Angelus_: if you mean a variant that won't run on real Pentiums or VIAs, or whatever, then "most unlikely"
<_Angelus_> every package compiled as i686 instead of i386
<Mithrandir> _Angelus_: what is the problem you are trying to solve?
<_Angelus_> like gentoo
<pitti> why should we? our current compiler already optimizes instruction order for i686, and uses i486 command set (AFAIR; doko, please correct me)
<_Angelus_> im not trying to solve problem, im asking because im curious and i wish  for a whole ubuntu compiled as i686 like arch and gentoo
<Mithrandir> pitti: correct.
<pitti> _Angelus_: we have kernel and libc6 optimized for 686, where it matters (well, a bit anyway)
<_Angelus_> yeah i know
<pitti> the rest hardly matters...
<cjwatson> _Angelus_: the significant extra disk space requirement is not worth the miniscule performance difference (given that, as pitti says, we already tune for i686)
<_Angelus_> but every program compiled as i686 would make a speed burst :p
<laga> _Angelus_: can you prove that?
<cjwatson> _Angelus_: no, actually, we strongly believe it wouldn't. Please feel free to produce benchmark figures if you disagree.
<pitti> maybe some ultra-optimized math libraries, but those can still have special cases
<cjwatson> and libraries can have variants built for particular processors quite easily
<_Angelus_> well i can't really prove it , its a matter  ifyou belive it or not
<jcristau> no it isn't
<cjwatson> this is a matter of scientific fact
<_Angelus_> i just felt my computer going alot faster when i changed grfrom kubuuntu to gentoo
<cjwatson> changing distribution involves so many other variables, and you've picked just one? :)
<cjwatson> also, there is a psychological effect there
<_Angelus_> bot arch and gentoo where faster then kubuntu
<_Angelus_> and both are i686
<cjwatson> "I've spent all this time compiling software - it must be worthwhile"
<cjwatson> anyway, the simple answer is no, we aren't going to produce an i686-optimised variant. Sorry.
<_Angelus_> cjwatson: on arch you dont compile, its precompiled i686, and its still alot faster then 1386 at least on my pc
<_Angelus_> ok
<_Angelus_> ;p
<doko> _Angelus_: you have to back your claims. which improvement in which application?
<_Angelus_> doko: application opening alot fast, and things like that
<_Angelus_> im not a geek so i can't really prove it with geek words, al i can say is what my eyes see
<_Angelus_> in normal words
<_Angelus_> so sorry if im not being specific
<cjwatson> timing isn't a matter of geekness
<Mithrandir> _Angelus_: you need to come up with measurements where you've just changed one variable, not everything else.
<_Angelus_> dont get me wrong guys im not talking bad about ubuntu or something
<_Angelus_> kubuntu is my favorite distro and iv been using it for a year and a half now
<cjwatson> we understand, but you're asking for a change that we believe there is no justification for, and we are explaining what justifications would be needed in order to make a change of this enormous magnitude
<_Angelus_> but i saw a speed up in programs when i changed tto genoo
<cjwatson> it is NOT sufficient to simply point at another distribution and say that it subjectively runs faster
<_Angelus_> cjwatson: then dont make a change, leave i386 and make i686 available too, aint that posible to have both version available ?
<cjwatson> that would be a vast, enormous change
<cjwatson> and require a huge amount of additional resources
<stgraber> _Angelus_: that'd take twice the space on the mirrors and twice the testing efforts. Not something we can afford
<_Angelus_> hmm
<cjwatson> you don't have to believe me or understand me, it is simply a fact
<_Angelus_> i see
<mpt> We could make "i686" symlinks to the i386 versions. Then it would still "feel faster", without the need for extra disk space. :-)
<Mithrandir> we did roughly that for lpia, and it took what?  Four months and a team of three-four people full time for that period?
<Mithrandir> (plus maintenance cost)
<_Angelus_> i see
<_Angelus_> i think its possible dough for example for some to compile the whole kubuntu froom surce and compile i386
<_Angelus_> right?
<cjwatson> therefore, it is in fact much cheaper to identify why particular applications are running faster, and incorporate particular optimisations
<_Angelus_> i mean *i686 sorry
<cjwatson> it very likely has nothing to do with CPU optimisationss
<_Angelus_> nah
<cjwatson> somebody could do that, and then be disappointed when it made little difference, sure :)
<_Angelus_> i see
<cjwatson> I believe that somebody did in fact try it in the past, and presented benchmarks with very small percentage-point differences
<cjwatson> though I don't have a reference to hand
<stgraber> it's of course possible to rebuild the whole archive using i686, people are doing that for arm and some other archs IIRC but that'll take you days/weeks to have everything rebuilt
<_Angelus_> but i think in future when i386 will not  be need anymoree because all pc's will be compatable with i686, then  i think ubuntu will change right?
<cjwatson> forget i386; we actually build for i486 anyway
<persia> _Angelus_: There are many computers being made today that are i586.
<cjwatson> and we investigated this just recently and found that there was still a substantial pre-i686 requirement (e.g. LTSP thin clients)
<stgraber> _Angelus_: I think that the current moev is to go 64bit
<stgraber> *move
<Mithrandir> stgraber: yeah, I think i386 will just move into the embedded space and amd64 will take over desktops and servers completely.
<_Angelus_> hmm
<Mithrandir> who'd want a desktop with less than 8G RAM anyway?
<jdstrand> mpt: the firefox-3.0/xulrunner-1.9 update for -security was because firefox-3.0 and xulrunner-1.9 had a security fix that went into -updates that had to be rebuilt for people who only have -security enabled. Hence 'no change rebuild for security'.
<_Angelus_> so kubuntu will move to 64bit and not to i686
<_Angelus_> ?
<stgraber> What I meant is that we already have x86_amd64 that's optimized for newer CPUs (at least I'd expect it to be), I don't think spliting i386 or limitating it to >=586 is a good idea.
<jdstrand> mpt: I could have used '-v...', but then that would have been confusing for people (a lot more than just -security) that have -updates enabled, as they would have seen the same changelog text twice
<_Angelus_> i understand
<cjwatson> _Angelus_: we already supply a 64-bit version of Kubuntu
<mpt> jdstrand, are you saying that people with both -updates and -security turned on would have received two updates with the same summary?
<cjwatson> oh, stgraber said that
<_Angelus_> btw
<stgraber> _Angelus_: as cjwatson we have some hardware like thin clients that can't run anything >486 and having both 486 and 686 is not an option for space reason, testing reason, ... and all that for (as far as we know) no real speed improvment
<jdstrand> mpt: it is a standard text that we use in these situations, but it can certainly be improved if warranted
<jdstrand> mpt: I'm saying that if I used '-v<earlier version>' (which I purposely didn't), then yes
<_Angelus_> why deos kubuntu only offer 1 64bit version? should there be an amd64 one and an ia64 one ?
<stgraber> _Angelus_: ia64 is not a supported arch
<_Angelus_> ah
<norsetto> with regard to bugs like bug 252037, can any motu upload a fix or is the solely prerogative of backporters?
<ubottu> Launchpad bug 252037 in sauerbraten "sauerbraten cannot upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/252037
<mpt> jdstrand, why would they have received two updates instead of one in the first place?
<persia> stgraber: ia64 works fine.  No reason to deprecate it.
<_Angelus_> so 64bit intel cpu's are not supported?
<cjwatson> yes, they are
<cjwatson> "amd64" is just the codename (because AMD designed the architecture) but it also supports Intel Xeon-class systems
<cjwatson> ia64 is Itanium, which is not the same as the 64-bit Intel systems that most people in fact have.
<_Angelus_> aint ia64 for intel 64bit cpus?
<Mithrandir> cjwatson: more than Xeon, really.  Most desktop and laptop CPUs from Intel those days are 64-bit capable.
<jdstrand> mpt: it went into -propsed for more widespread testing, then was mistakenly pocket copied to updates rather than rebuilt in -security. it linked against (and depended on) a newer version of pango that made it uninstallable for people with just -security enabled
<cjwatson> _Angelus_: Itanium only, not things like Core 2. Please listen to what I said.
<jdstrand> mpt: so we had to send it through -security too
<_Angelus_> hmm i see
<cjwatson> _Angelus_: Wikipedia should have a good summary if you want the complicated history
<Mithrandir> ia64 systems need lots of cooling and are generally not something an end user would ever buy or interface directly with.
<_Angelus_> so Core 2 uses the amd64 arch
<cjwatson> _Angelus_: furthermore, we document quite clearly that our 64-bit CD images (for example) support Intel systems
<cjwatson> yes.
<_Angelus_> i  understand.
<TheMuso> I think EM64T is the official Intel 64-bit name.
<jdstrand> mpt: I say 'mistakenly' here, but it is no one's fault, as there wasn't a clear policy at the time. that has since been adjusted in SecurityUpdateProcedures
<StevenK> TheMuso: Not any more. Now they're calling it Intel 64
<Mithrandir> TheMuso: it is.  And the gnu arch string is x86_64.  And MS and Sun's name for the architecture is x64.
<TheMuso> StevenK: haha great.
<cjwatson> names are hopelessly marketing-infected. The solution is not to actually expect users to understand "amd64", but to display a description alongside or instead of the name wherever necessary
<mpt> jdstrand, ah, I see. Perhaps it would be more understandable in cases like that for Update Manager to have the same full update description as before, but followed by "This replaces a previous update that did not install on some systems" or something like that.
<jdstrand> mpt: had to disagree with that. :) however, with our new procedures, and me talking with all the archive admins personally, hopefully we'll avoid it completely in the future
<mpt> ok
<jdstrand> s/had/hard/
<warp10> pitti: I just subscribed you to bug #252262, since you modified the piece of code involved in that bug in a past revision. I am not sure that one is actually a bug, BTW
<ubottu> Launchpad bug 252262 in dpkg "dpkg-source: Ubuntu maintainer check too broad" [Undecided,Incomplete] https://launchpad.net/bugs/252262
<pitti> warp10: replied, thanks
<skymuss> hi
<pitti> seb128, Riddell: any chance one of you could wave gdm-guest-session through source NEW? it's tiny, ubuntu specific, packaged by me, so I hope it won't take more than two minutes
<seb128> pitti: looking
<pitti> seb128: (might actually still take 2 minutes until it hits the quue)
<pitti> seb128: merci
<seb128> ok, grabbing coffee and looking to that next then
<seb128> de rien
<tseliot> pitti: is the "XorgDriverHandler.enabled()" method called when Jockey installs or uninstalls the driver or only in one of these cases?
<pitti> tseliot:in both; (if you really mean enabled(), and not enable() )
<tseliot> pitti: I mean enabled()
<tseliot> pitti: ok, thanks
<tseliot> ï»¿pitti: oh, and enabled is called before enable() or disable(), right?
<pitti> tseliot: yes
 * pitti -> bbl
<pitti> tseliot: it is called to check whether to enable or disable the driver, or if you specify --enable, whether it already is, and so on
<pitti> tseliot: however, API-wise you sholdn't bet on any particular order; why do you want to?
<tseliot> ï»¿pitti: I was trying not to call the same method twice. Currently enabled() calls it to check the xorg.conf and this other method sets self.devices_to_check
<tseliot> pitti: ï»¿self.devices_to_check is a list
<tseliot> pitti: otherwise I would have to call the other method in both enable() and disable()
<pitti> tseliot: you should still do that  then
<pitti> tseliot: you shouldn't parse xorg.conf twice; just do it once and then just work with the internal XKit object and modify its state
<pitti> and just write() in enable()/disable()
<tseliot> ï»¿pitti: I don't parse the xorg.conf more than once. I'm talking about calling a quite useful method i.e. check_serverlayouts() twice
<tseliot> ï»¿pitti: I'll explain you everything as soon as it's complete.
<tseliot> pitti: why is there no nvidia.py in data/handlers/ in trunk?
<tseliot> pitti: furthermore is it really necessary to override enabled() in nvidia.py? Shouldn't it use the inherited method?
<pitti> re
<pitti> tseliot: doesn't sounds as if it would be too expensive to do so; mind you, that isn't called 10.000 times a second or so
<pitti> tseliot: nvidia.py isn't a supported handler upstream, since it is ubuntu specific
<pitti> tseliot: in trunk it is in examples/handlers/
<tseliot> ï»¿pitti: aah, I see
<tseliot> ï»¿pitti: I'll work on ï»¿examples/handlers/nvidia.py and fglrx.py then
<pitti> tseliot: indeed, with the latest trunk fixes, nvidia shouldn't need to overide enabled() any more
<tseliot> ï»¿pitti: yes, that's why I commented it out
<tseliot> ï»¿pitti: also, it would be nice if (in the future) you could add a "disable_modules" argument to the superclass
<tseliot> so as to disable modules which are enabled by default
<tseliot> such as "dri2"
<tseliot> and to set something like Disable "dri2" in the Module section of the xorg.conf
<pitti> tseliot: right, so far I just have a parameter for modules which shuold be removed
<pitti> I hadn't implicitly loaded modules in mind when I wrote that
<tseliot> ï»¿pitti: adding that argument wouldn't break anything, I guess
<tseliot> ï»¿if you want, I can deal with it
<tseliot> when my changes are stable
<pitti> tseliot: if you feel like it, sure
<geser> mvo: is it a bug or a feature that "apt-cache unmet -i " also lists Breaks:?
<pitti> tseliot: just remember, every new feature needs a corresponding test case :)
<tseliot> pitti: yes, of course ;)
<mvo> geser: sounds like a bug to me, let me check the bzr history
<tseliot> pitti: would it be possible to add a dependency on pciutils to jockey?
 * tseliot hides
<tseliot> pitti: seriously, I would need it to do hardware detection. Or do you do hardware detection in a way which is different from using lspci?
<NCommander> seb128, morning
<seb128> hello NCommander
<NCommander> seb128, someone already beat me to glibmm :-P
<seb128> NCommander: oh?
<NCommander> The latest upstream I could find was 2.16.4
<NCommander> Which is what's in intrepid
<seb128> NCommander: http://download.gnome.org/sources/glibmm/2.17/glibmm-2.17.1.tar.gz
<NCommander> It says 2.16 is stable
<NCommander> That's under unstable
<seb128> yes, but we track glib 2.17
<NCommander> Oh
<seb128> and GNOME 2.23
 * NCommander inserts hit foot in his mouth then ;-)
<seb128> intrepid will have GNOME 2.24
<seb128> so we package unstable versions along the way until the stable one
<NCommander> That makes sense
 * NCommander learns more about the desktop team ;-)
<NCommander> ls
<NCommander> whoops
<StevenK> total 0
<Keybuk> ?!
<Keybuk> how do I have a version of python-2.5 installed that's not in the archive?
<Keybuk> seems it came from hardy-proposed, but then vanished
<NCommander> seb128, I'm now testing out glibmm2.17; I noted in the changelog the reason we were tracking an unstable release
<seb128> NCommander: ok good
<pitti> tseliot: pciutils? no, why? IMHO we should read everything from /sys
<tseliot> ï»¿pitti: I use "lspci" so as to look it up in /usr/share/xserver-xorg/pci/ if no driver is specified in the xorg.conf. In this way I can see what driver Xorg assigned.
<tseliot> pitti: and by Xorg I mean Xorg's autodetection
<jcristau> tseliot: what happens when /usr/share/xserver-xorg/pci goes away?
<tseliot> ï»¿jcristau: we replace it with whatever is available
<tseliot> ï»¿jcristau: but if these files are available we make use of them.
<tseliot> a simple "if" block will be enough
<jcristau> tseliot: as long as you don't break when they're not, that's good enough for me :)
<jcristau> (because 'whatever is available' might well be 'nothing')
<tseliot> ï»¿jcristau: yes, I know
<tseliot> pitti: never mind, I misread the custom handler. Ignore my request.
<vadi2> Is there a channel for "ï»¿application development on Ubuntu" if this isn't it?
<ion_> Itâs just application development, âon Ubuntuâ is irrelevant.
<vadi2> Is that a no or a yes?
<vadi2> I'd like to find out the proper way of adding a program that requires root privileges to startup.
<vadi2> (In ubuntu)
<Mithrandir> vadi2: add an init script
<ion_> mithrandir: Or an Upstart job.
<Mithrandir> that's also an option.
<vadi2> Great, thanks. I'll look into that.
<rubikcube> hello, I need some help concerning building a working initrd (or so I think).  How can I tell it which modules to load when booting (specifically pata_via)?
<cjwatson> rubikcube: add module names to /etc/initramfs-tools/modules; run update-initramfs
<cjwatson> (update-initramfs -u, probably)
<rubikcube> well, that's what dpkg-reconfigure linux-image-foo should do already, right?
<cjwatson> sure, if you want the long way round
<cjwatson> that's really only an incidental side-effect. dpkg-reconfigure means "ask me debconf questions again".
<rubikcube> anyway, that didn't work :/ I'm trying to solve https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/32123 or something very similar
<ubottu> Launchpad bug 32123 in initramfs-tools "initramfs not generated correctly on dist-upgrade" [High,Confirmed]
<rubikcube> but if that's all it should take, I'll just retry it :-)
<vadi2> Just to confirm... does upstart work for GUI applications?
<cjwatson> vadi2: I think you need to be a bit more specific
<vadi2> Can it launch a gtk application?
<vadi2> The issue that I have is that I'd like to have an application auto-start, but it requries root privileges. If I copy the .desktop to ï»¿.config/autostart, it'll start - but it asks the user for root password (right after he already put it in once for login)
<bdmurray> pitti: I've found an apport-package report regarding a non-ubuntu package.  Should I open an apport task for it?
<cjwatson> upstart doesn't know how to talk to your X display, so is inappropriate for graphical applications
<cjwatson> vadi2: remember that a normal gksudo-ed application would do the same thing ...
<jcristau> vadi2: you don't put in the root password for login
<cjwatson> I think he meant the sudo password, which == the user password
<vadi2> Yes.
<jcristau> ah. yeah, ignore me :)
<vadi2> I find it a bit silly to bug the user for the same password twice. Is there a set policy on this though?
<cjwatson> this is a normal property of the Ubuntu desktop. Elevating to root privileges requires additional confirmation.
<cjwatson> (otherwise you might as well just run the whole thing as root)
<cronholio> hi guys, launchpad user 10111 and i want to work on https://blueprints.launchpad.net/ubuntu/+spec/webcam - we wrote emails to the creator of the blueprint as well as the mentor withiout getting a reply - any ideas or anyone that would mentor us?
<vadi2> ï»¿cjwatson: alright, thank you.
<cjwatson> vadi2: your options include: rewrite application to not require root, or to use PolicyKit, or similar; use a setuid helper to launch the application (and figure out how to make that safe); accept the current situation
<vadi2> We were looking into PolicyKit actually before. That can be used not to require the password?
<cjwatson> cronholio: that blueprint was created inappropriately by a user who was trying to use it to make a wishlist request. I don't think there's any need for you to treat it as blocking you in any way if you want to work on it
<cjwatson> vadi2: it would provide a different experience. Compare e.g. the GNOME system tools
<cronholio> cjwatson, yeah but the problem is we have no experience in working for ubuntu, though we have programming experience, and we need to know if the app/feaure is still needed and someone that can provide minimal mentoring to help us integrate the app in ubuntu
<cjwatson> if you can't even tell whether it's needed, are you sure you're the best person to work on it? ;-)
<vadi2> cjwatson: Okay, thank you for your input!
<cjwatson> (no offence) the very first step ought to be caring about it yourself
<cjwatson> cronholio: remember, *anyone* can create a blueprint. That wasn't created by anyone on the Ubuntu development team
<cronholio> cjwatson: well we both have working webcams but i guess some people do not :-)
<vadi2> We do require root to even start (as we can't get the info we need without root). So... looks like password it is.
<cjwatson> it's going to be very difficult for you to work on something that doesn't affect you personally. Some experienced people can do that but it takes a lot of work
<mvo> vadi2: out of curiosty, what does this app do?
<cjwatson> cronholio: it would be better to have made some fairly substantial progress on your own before looking for mentoring, I think; you ought to decide what you're going to do and lay out a design
<cjwatson> then you can ask for design review; not many people are going to step up for mentoring in a vacuum, though
<vadi2> mvo: manage ufw with buttons. While really, it in no way needs to be auto-started, people still have the idea that if it's not running, the firewall isn't active. And there are some very dangerous "tips" on the web now on how to make it autostart. So we want to implement a "proper" way before these tips get too popular.
<cronholio> cjwatson: ok thanks, probably that's a good idea. i checked and found that these webcam drivers are not installed by default so probably this app would make sense to have
<cjwatson> cronholio: consider whether they should simply be installed by default rather than creating a complex infrastructure to download them on the fly
<mvo> vadi2: if all you need is a read-only view you may write a dbus backend that runs as root and is able to read the values, then you can use policykit to restrict the read to certain groups (e.g. admin). for the enable/disable stuff you can use the same mechanism, just add a confirmation step (like in gnome-system-tools)
<cjwatson> cronholio: if the space increase is not too great, that would be a much more normal Ubuntu approach
<cronholio> cjwatson: will do, thx again
<vadi2> mvo: Thank you! That sounds great. We'll look into it.
<ion_> benc: http://heh.fi/tmp/grub_0.97-29ubuntu32.debdiff
<johanbr> cronholio: I'm not sure exactly what the blueprint is asking for. The gspca kernel module is already included, and Cheese can record video (although not upload it to youtube).
<rubikcube> could someone please tell me if the possible contents of /etc/modprobe.d/blacklist.local are made by ubuntu or if I made them myself?
<cjwatson> we don't ship blacklist.local; it's, well, local :)
<rubikcube> that's why I was wondering :-)
<rubikcube> but I couldn't remember editing it either ;-)
<rubikcube> And I was wondering why those modules weren't loaded
<cronholio> johanbr, the blueprint is asking for an app that downloads the webcam driver according to the usb device id
<cronholio> if the gspca module supports all these then we don't need it at all
<johanbr> cronholio: Downloads what, exactly?
<cronholio> johanbr, the drivers from http://mxhaard.free.fr/spca5xx.html
<johanbr> Again, the gspca driver is a kernel module and already included in the standard ubuntu kernel.
<cronholio> johanbr, ok thx, i guess it is not needed then, i will update the info in the blueprint
<slangasek> calc: is OOo happier now with libltdl -dev provides?
<calc> slangasek: it seems to build ok, the problem was that some of its build-depends required the provides
 * slangasek nods
<Riddell> tkamppeter: do you know that hal-cups-utils can't be installed?
<Riddell> python-usb needs a main inclusion report
<tkamppeter> Riddell, thanks for telling me. I will post it. The package looks small for me, should not break the CDs.
<BenC> ion_: Uploaded fixed grub, thanks
<ion_> benc: Thanks
<pitti> bdmurray: please, that's worth investigating; thanks!
<bdmurray> pitti: its bug 252734
<ubottu> Launchpad bug 252734 in apport "package mythstreams None [modified: /var/lib/dpkg/info/mythstreams.list] failed to install/upgrade: trying to overwrite `/usr/share/mythtv/media_settings.xml', which is also in package mythtv-frontend" [Undecided,New] https://launchpad.net/bugs/252734
<alex-weej> question
<alex-weej> the PC speaker in a macbook pro seems to not be connected
<alex-weej> yet ALSA is now exposing a device for it
<alex-weej> this needs a fix in... HAL?
<alex-weej> it's clearly on the chipset, just not used by the builders
<slangasek> fta: is anything happening with bug #218534 for seamonkey?  this has been sitting at the top of the bug list for intrepid for some time now
<ubottu> Launchpad bug 218534 in seamonkey "[Needs Packaging] JavaScript vulnerability in Firefox/Thunderbird/SeaMonkey/Xulrunner before 2.0.0.14/1.1.10/1.8.1.14" [Critical,In progress] https://launchpad.net/bugs/218534
<Keybuk> dear Intrepid,
<Keybuk> X server
<Keybuk> Useful
<Keybuk> Love, Keybuk
<BenC> Dear Intrepid,
<BenC> Shutdown != Logout
<Keybuk> BenC: I can't fix that bug, because the kernel doesn't let me have an X server to start with <g>
<ion_> Dear Interpid,
<ion_> Please make me some coffee.
<Keybuk> BenC: oh, and sound doesn't work either
<Keybuk> so the latest kernel has no sound or graphics
<Keybuk> keyboard seems to work though ;)
<BenC> Keybuk: I thought you knew we enabled CONFIG_KERNEL_REQUIRES_STROKING...you have to tell it nice things for it to work
<BenC> Using a goofy baby voice is optional, but reported to help
<Keybuk> I tried that
<Keybuk> I think that it hates Intel and it hates Dell
<mkrufky> ...i havent logged into Launchpad for a few days.... now i did, and the Belmont stuff is all screwed up
<mkrufky> i cant find my bugs anymore
<mkrufky> and i have no idea how to navigate
<mkrufky> wth happened here?
<mkrufky> oh, oops... my bad ...
<mkrufky> its funny how i find the answer the moment AFTER i complain
<slangasek> seb128: is bug #210468 still applicable to intrepid?
<ubottu> Launchpad bug 210468 in gvfs "try to access a .Trash-$USER directory on autofs mounts" [High,Fix released] https://launchpad.net/bugs/210468
<seb128> slangasek: yes
<slangasek> darn
<slangasek> :)
<seb128> why?
<slangasek> because it's on my List
<slangasek> and I was hoping the fix was in intrepid since it was an SRU :)
<seb128> slangasek: fix uploaded to intrepid now
<calc> OOo is failing in weird ways on me :-\
 * calc hopes to have it figured out and uploaded (to ppa) by the end of the night
<slangasek> seb128: cheers :)
<hachi> morning, this may be a bit offtopic, but in the last week nobody on #ubuntu has had a clue... I'm trying to find how you can specify the filename of the filesystem for casper. I've been reading the startup scripts in the initramfs and just can't make heads or tails of it.
<hachi> ahh, forgot the question part. Do any of you happen to know what the options may be, or where this might be documented?
<tormod> hachi: documentation for casper? lol
<hachi> well, on the upside I finally know that there is no documentation
<hachi> though you could have told me without laughing at me
<tormod> hachi: :) maybe we are less off-topic in #ubuntu-installer
<pitti> Keybuk, BenC: FYI, I updated bug 253076 with my experiences, since you subscribed me
<ubottu> Launchpad bug 253076 in linux "No X with current kernel (downgrade fixes it)" [Critical,New] https://launchpad.net/bugs/253076
<Keybuk> cool
<ScottK> pitti: Does your revised regex for ubuntu.com addresses in dpkg allow kubuntu.org addresses?
<asac> jdstrand, did you respin ffox 3?
<asac> jdong, why?
<jdstrand> asac: yes, had too-- the -updates packages pulled in pango that was only in -updates, so it was uninstallable in -security
<asac> err, jdstrand
<asac> hmm
<jdstrand> asac: no change rebuild
<jdstrand> (just bumped the version and ran through dak)
<asac> yeah. someone complains about font regressions now
<asac> jdstrand, can you commit that change to bzr?
<asac> e.g. the changelog
<jdstrand> asac: sure, can you point me to it?
<asac> jdstrand, its in debian/control
<asac> ;)
<jdstrand> oh, duh
<asac> should be lp:~mozillateam/firefox/firefox-3.0.hardy
<asac> most likely not in control :-D
<asac> jdstrand, let me add you to mozteam then
<jdstrand> asac: I had to do the same with xulrunner-1.9
<asac> jdstrand, ok. whats your lp id?
<jdstrand> asac: jdstrand
<asac> jdstrand, xulrunner is lp:~mozillateam/xulrunner/xulrunner-1.9.hardy
<asac> ok have to move the conference room
<jdstrand> asac: ok
<asac> jdstrand, thanks a lot
<jdstrand> asac: np
<jdstrand> asac: this ff3 update highlighted a number of issues that we can improve on in the future. I have updates SecurityUpdateProcedures and talked to all the archive admins about not pocket copying from -poposed to -updates a package that ultimately needs to go to -security
<jdstrand> asac: however, you mentioning the font regression when built against released pango illustrates that the PPA builds need to have -udpdates disabled as well
<jdstrand> asac: (in case you didn't know or infer from what happened, people are supposed to be able to get all -security updates without having -updates enabled, therefore the buildds can't have -updates enabled either for anything in -security)
<jdstrand> asac: security-in-soyuz will help with all of this, btw
<bondolo> hello, how do I make a launchpad bug depend upon another bug? (I'd like to make 154038 and 238977 depend upon 251369)
<totopalma> hello
<LaserJock> bondolo: I don't think you can, but you can link to other bugs by just doing "bug #251369" in the description/comment
<ubottu> Launchpad bug 251369 in freetype "Please merge freetype 2.3.7-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/251369
<totopalma> Riddell, can you please take a look at bug #39383 ?
<ubottu> Launchpad bug 39383 in kdebluetooth "No icons in GNOME" [Medium,Confirmed] https://launchpad.net/bugs/39383
<cprov> hi guys, do you know from where synaptic downloads the so-called "changelog" information ?
<LaserJock> cprov: changelogs.ubuntu.com perhaps?
<cprov> LaserJock: yes, good. Do you know how it's built ?
<LaserJock> cprov: my guess is from the archive
<LaserJock> extracting perhaps from the source package
<cprov> LaserJock: right, some apt-ftparchive spell on top of a.u.c
<LaserJock> ah, it looks like it's actually extracting from the .debs
<LaserJock> at least the .copyrights are per-.deb
<emgent> evening
 * ion_ â¥ https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/GuestAccount
<__keybuk> I've been thinking about InitKit again over the last few days
<__keybuk> oops, ww
<__keybuk> ion_: your message here confused me ;)
<ion_> :-)
<calc> did mv used to not return an error code if the file was non-existant in hardy timeframe?
<slangasek> only if it was buggy..
<calc> hmm
<calc> i'm getting a failure that should have failed in the past, trying to look at a buildd log now to see why it didn't fail before
<calc> oh hmm the file i thought didn't exist actually should so the problem is apparently it doesn't now
<calc> slangasek: if i just add a line in rules: ls foo   it will show the dir contents in the build log, right?
<slangasek> yes
<calc> ok
#ubuntu-devel 2008-07-30
<__keybuk> kees: weird
<__keybuk> your patch to vte to fix bold fonts seems to break subpixel rendering
<__keybuk> I can't see why it would though
<__keybuk> oh, no, weird
<__keybuk> it's a fontconfig issue
<__keybuk> seems that its settings override gnome's, at least for gnome-terminal
<__keybuk> ArneGoetje: ?
<ArneGoetje> Keybuk: gnome-terminal uses vte for its terminal. vte does not use gnome settings but fontconfig. That's why.
<ArneGoetje> __keybuk: ^
<Keybuk> ArneGoetje: but it worked in gutsy?
<Keybuk> oddly enough, if I remove the fontconfig directory, gnome-terminal does appear to obey gnome settings
<Keybuk> indeed, it obeys them enough that they update live with changes to the font rendering dialog
<Keybuk> so it seems that it's more that vte allows fontconfig to override xsetting
<Keybuk> whereas other gnome apps only obey xsetting ?
<Keybuk> (with the added sub-bugs that fontconfig doesn't follow the preferences *and* fontconfig doesn't honour user changes to its conf.d directory)
<TheMuso> Yay for daily alternate CD brokenness.
<ArneGoetje> Keybuk: yeah... seems like there is more to fix...
<ArneGoetje> Keybuk: I guess that other gnome apps allow fontconfig to override xsetting...
<ArneGoetje> Keybuk: err... do not allow, of course
<TheMuso> oh its to do with a new kernel I think...
<kirkland> TheMuso: you get a chance to look at the mdadm/initramfs-tools stuff i was working on?
<TheMuso> kirkland: Yeah looks fine to me. I also got my change uploaded as well. Now if someone uses usplash and has such errors, they will actually see them.
<kirkland> TheMuso: ;-)  cool
<kirkland> thanks for taking a look
<TheMuso> kirkland: np.
<TheMuso> kirkland: One thing I forgot to check is that the documentation in the manpage was updated...
<TheMuso> Rather, whether the docs were updated.
<TheMuso> in the example script and the manpage.
<kirkland> i didn't touch the docs (yet)
<TheMuso> kirkland: Right, because nothing is finalized?
<kirkland> TheMuso: right, i definitely have more to do on this
<TheMuso> kirkland: Ok.
<kirkland> TheMuso: but my current focus has been shifted to iscsi support in the installer
<TheMuso> kirkland: Gotcha.
<TheMuso> kirkland: How is that going by the way?
<kirkland> TheMuso: well, i saw an iscsi target as a block device on the initiator for the first time today ;-)
<kirkland> TheMuso: it was an "aha" moment :-)
<kirkland> TheMuso: evand is here in Austin this week, so he's given me some good pointers
<TheMuso> Ah ok.
<TheMuso> kirkland: How much work was it to get the device to be seen in the initiator?
<kirkland> TheMuso: anyway, i've figured out the userspace magic to get it to the point of seeing a block device, so I'm over the initial hump
<TheMuso> kirkland: Nice.
<kirkland> TheMuso: fairly well documented here: http://www.howtoforge.com/iscsi_on_linux
<TheMuso> ah ok.
<kirkland> TheMuso: once you've discovered the target identifier, it's not much more than:
<kirkland> iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84211978 -p 192.168.2.222:3260 --login
<TheMuso> kirkland: Nice.
<kirkland> where "iqn...." is the identifier and 192..... is the IP
<kirkland> TheMuso: discovery is fairly straight forward too:
<kirkland> iscsiadm -m discovery -t st -p 192.168.2.222
<kirkland> that should print out some awk-able  iqn.1992-08.com.netapp:sn.84211978 looking strings
<TheMuso> Nice.
<kirkland> TheMuso: I still need to figure out the /etc/fstab magic
<kirkland> TheMuso: i better call it a night... we're at Dell again tomorrow
<TheMuso> kirkland: Ok have fun.,
<jack> hi
<jack> any packages.ubuntu.com admin around?
<LaserJock> jack: Frank Lichtenheld's email address is on the packages.ubuntu.com page
<jack> uhm, ok
<jack> just wanted to let someone know all source download links are broken
<LaserJock> well, packages.ubuntu.com is still in a state of flux perhaps
<jack> how/why this?
<LaserJock> jack: packages.ubuntu.com isn't formally run by the Ubuntu
<LaserJock> it is/was Frank's service
<jack> oh ok
<LaserJock> but he emailed a while back to say that he was running out of resources to do
<LaserJock> it
<jack> a nicce service, though
<LaserJock> so I'm not sure if it's on a new host now or not
<LaserJock> perhaps that's what broke it
<LaserJock> yes, it's a very needed service
<jack> you should sponsor that guy a bit maybe ;(
<johanbr> Well, the IP it's on now belongs to canonical.
<LaserJock> well, I've just got a DSL connection and an old machine ;-)
<LaserJock> johanbr: ah good
<LaserJock> jack: my guess is that the move is still being worked out
<jack> ok
<LaserJock> I'm not sure who'd responsible for it right now
<LaserJock> *who'd be
<jack> it's a minor flaw anyway
<jack> i can find out the links of course
<LaserJock> well, it'd be nice to get it fixed though
<jack> just a bit ugly ;)
<jack> yeah
<pwnguin> anyone have a good citation for the time someone realize Debian had a ton of money just sitting around?
<pwnguin> (am i miremembering it?)
<slangasek> doesn't ring a bell
<pwnguin> i coulda sworn there was someone who was like "oh, we have all this money we forgot about" maybe im thinking of the linux fund?
<pwnguin> like 2003, 2004-ish
<RAOF> I seem to recall something like that, too.  Didn't a bunch of porter boxes get bought with it?
<pwnguin> basically, im trying to do the research jeff atwood didnt
<pwnguin> provided i dont get hit by tornado
<pwnguin> sounds pretty bad outside right now
 * RAOF doesn't get the reference
<pwnguin> theres a thunderstorm
<pwnguin> i mean a literal tornado; no metaphor here
<pwnguin> http://www.wunderground.com/
<pwnguin> anyways, back to digging
<slangasek> pwnguin: I don't believe we ever discovered money we'd forgotten about; Debian's parent corporation, SPI, has a checkered history when it comes to receiving and accounting for donations
<slangasek> ("accounting for" in the sense that donations were received and in the early days, no records were kept of the earmarking and it wasn't clear how much of the money was meant to be an SPI cut vs. a Debian cut)
<pwnguin> i guess it was linuxfund
<pwnguin> not the spi
<StevenK> slangasek: But there was a period in 2003 or 2004 where we just spend any of it. I'm not sure if that has changed.
<slangasek> Debian did go through a phase when SPI suddenly was roused and became functional and Debian actually started /using/ some of the money, so I guess that sorta fits the description
<pwnguin> heh
<pitti> Good morning
<pitti> ScottK: ah, not ATM; it won't give you the error for @kubuntu.org, although it probably should
<emgent> moin pitti :-)
<dr-know> hi
<huats> morning all
<mvo> pitti: do you have any idea about bug #249024 ? its the second report I have seen about this, it seems that for some reason localedef hangs for some people (#253180 is the other one)
<ubottu> Launchpad bug 249024 in update-manager "Process hanging while upgrading remotely to 8.04" [Undecided,New] https://launchpad.net/bugs/249024
<pitti> mvo: incidentally I'm just debugging this
<mvo> pitti: heh :) is there another bug already that I should duplicate this to?
<pitti> mvo: I'm using bug 249340
<ubottu> Launchpad bug 249340 in langpack-locales "Gutsy->Hardy upgrade hangs in localedef" [High,Triaged] https://launchpad.net/bugs/249340
<cjwatson> mvo: localedef uses a metric shitload of memory
<cjwatson> mvo: in my "spare" time (ho ho) I've been working on paring it down, though am having some difficulty ensuring that it remains correct at the same time
<cjwatson> mvo: but given that at the moment it uses 50MB or so, it's quite plausible that people's systems are simply thrashing to death
<pitti> I just tried to create a gutsy chroot and upgrade locales, belocs-locales-bin, and libc6 to hardy, and it worked well (with the same locales as mentioned in the bug)
<cjwatson> though that said I see that 253180 claims 1.2GB of memory, so probably not that in that case
<pitti> cjwatson: hm, but 50 MB doesn't sound too scary?
<pitti> I mean relative to modern memory sizes, not relative to the task it has to do
<cjwatson> pitti: on a 256MB system it's probably enough to shove lots of other things into swap
<mvo> cjwatson: I got a report by someone with 1,2gb of ram, so that is probably not the reason
<cjwatson> it's certainly a chunk of what's responsible for making installations suck on 256MB systems
<mvo> I was wondering if it might be a fd leak (update-manager might leak some)
<mvo> but I haven't seen this problem in all my upgrade testing so far
<Hobbsee> cjwatson: ah, thanks for the reminder about memory thrashing.
 * Hobbsee goes to burn an alternate cd, for the friend with 230mb of ram.
<cjwatson> fd leak does seem plausible-ish if it only seems to happen in u-m
<pitti> sjoerd: any idea how to forge intrepid's kvm to boot a gutsy CD? I just get an unintelligible exception dump
<pitti> erm, soren ^ I mean; sorry, sjoerd
<soren> pitti: I actually thought it would Just Work[tm], but if not, there's the hack in the "How to boot Dapper, Edgy, Feisty or Gutsy ISO" section of https://help.ubuntu.com/community/KVM
<tseliot> pitti: why does Jockey think that nvidia-glx-96 is the right driver for my card (ubuntu-core-dev/jockey/ubuntu branch)?
<tseliot> pitti: my card is supported by 177, 171, 96 and Jockey doesn't show multiple version (on purpose, I guess) and installs 96. The highest number should be preferred over the lowest
<tseliot> unless there's a driver which supports all the available graphics cards
<pitti> tseliot: it should show all three of them actually
<tseliot> pitti: I built jockey from the ubuntu-core-dev/jockey/ubuntu branch
<pitti> tseliot: hm; do you have all modalias packages installed?
<tseliot> pitti: yes, they are installed
<pitti> tseliot: hm; can you please do the foreground daemon/--debug exercise then?
<pitti> tseliot: it did work fine the last time we tested it, didn't it?
<tseliot> pitti: yes, it did. I have modified xorg_driver.py and the custom handler but that should affect only the X part
<pitti> aah
<pitti> tseliot: does it work with the current intrepid packages?
<tseliot> pitti: I haven't checked yet
<tseliot> pitti: http://pastebin.com/m28cd8458 log
<pitti> I currently have my amd64/nvidia box running, trying here..
 * tseliot gets the current package
<pitti> 2008-07-30 11:11:30,712 DEBUG: querying driver db <jockey.detection.LocalKernelModulesDriverDB instance at 0x9c4c8cc> about HardwareID('modalias', 'pci:v000010DEd000002E2sv00000000sd00000000bc03sc00i00')
<pitti> 2008-07-30 11:11:31,264 DEBUG: no corresponding handler available
<pitti> tseliot: ^ seems it doesn't find it at all for you ATM
<pitti> tseliot: with the current intrepid packages I get all three versions
<pitti> (my GeForce 5200 is supported by all of them, it seems)
<pitti> tseliot: did you run the test suite? any regressions from your modifications?
<tseliot> pitti: it seems to work well with the current package.
<tseliot> I'll do some testing with it
<tseliot> pitti: no, I didn't run your test suite. I would like to write something customised but I have to study your test suite first
<pitti> tseliot: just try running it
<pitti> tseliot: it doesn't make assumptions about guidance, it just does blackbox testing
<pitti> after the move to x-kit, the entire set of tests should still succeed
<tseliot> pitti: is there a file which executes all the tests?
<pitti> tseliot: just call "tests/run"
<tseliot> pitti: 3 failures and 2 errors. 2 errors and 1 failure should be my fault
 * tseliot tries to debug things a bit
<pitti> tseliot: please compare with current trunk
<pitti> tseliot: occasionally one of the XML-RPC tests fails due to a race condition in the test suite
<pitti> tseliot: feel free to pastebin and let me comment
<tseliot> pitti: ok, I'll try the current trunk
<tseliot> pitti: failures=2, errors=2
<tseliot> errors for trunk:
<pitti> tseliot: hm, fun; please show me? (they all succeed for me)
<tseliot> pitti: the log for trunk: http://pastebin.com/m4f1751bf
<pitti> tseliot: can you please pastebin the test suite output?
<pitti> tseliot: log is only helpful together with it
<tseliot> pitti: yes, I know, I'm uploading the output
<tseliot> pitti: output: http://pastebin.com/m4788c4fb
<tseliot> this is without X-Kit
<pitti> mvo: hm, I just tried to upgrade a freshly installed gutsy to hardy in vmware; it gets as far as updating the package index, and then just disappears
<pitti> mvo: main.log ends with "runing doUpdate() (showErrors=True)", no exception or so
<pitti> mvo: http://piware.de/tmp/apt.log -> does that tell anything to you?
<pitti> mvo: no exceptions on stdout/stderr either, BTW
<pitti> tseliot: ah, the package thing is certainly because you don't have packagekit installed
 * tseliot installs packagekit-gnome
<pitti> tseliot: no, not -gnome
<pitti> tseliot: the ubuntu branch doesn't use packagekit yet, but trunk does
<pitti> (well, -gnome doesn't hurt of course, but jockey doesn't use it)
<tseliot> pitti: packagekit is a dependency of packagekit-gnome
 * tseliot runs the test suit again
<tseliot> pitti: http://pastebin.com/m2a674f05 http://pastebin.com/m7d290e80
<pitti> tseliot: hm, no real idea right now about those two failures
<pitti> but they should be totally unrelated to the xorg drivers, so maybe ignore them for now
<pitti> tseliot: let's track those down later, shall we?
<tseliot> pitti: ok
<pitti> mvo: I tried it again, this time with enabling universe/multiverse; same failure
<sebner> tseliot: ping =)
<tseliot> sebner: yes?
<sebner> tseliot: I was on holidays ^^, now time to look at my Xorg.log to discover why nvidia-glx isn't working?
<tseliot> sebner: can you send me an email with the log? I'll have a look at it later
<sebner> tseliot: great, thx
<mvo> pitti: oh, how strange. let me try that
<mvo> pitti: could you strace it just to get some idea what might go wrong? maybe its segfaulting somewhere?
<pitti> mvo: currently running apt-get dist-upgrade; I can do that afterwards, yes
<pitti> mvo: shouldn't a segfault be displayed in the terminal, thuogh?
<pitti> hm, maybe the root backend crashed, and the user-invoked GUI just exited with it
<pitti> mvo: does it crash on unsatisfieable dependencies or so? apt.log seemed to have some resolution trouble, but nothing it couldn't handle AFAICS
<mvo> pitti: it should not crash because of dependencies or anything like this, but if it does, the only explaination I have right now is a segfault somewhere
<mvo> pitti: thanks, Please let me know what you found
<pitti> ok, will do
<pitti> mvo: dist-upgrade will still take a while, though
<mvo> no problem, I fire up my vmware just to see if that is a general problem here
<pitti> mvo: argh, I just accidentally killed the d-u, so I can as well do it now
<pitti> mvo: how do I strace the 'inner' u-m which runs as roo?
<pitti> mvo: or can I just call "sudo strace update-manager", does that work?
<mvo> pitti: sudo strace -f update-manager should work I think
<pitti> ok, doing
<mvo> thanks
<pitti> ok, crashed again
<pitti> mvo: you were right, segfault
 * pitti runs under gdb
<pitti> mvo: ah, it's ignored by apport because it happens in the downloaded code
<mvo> pitti: hm, that sets itself to /usr/bin/update-manager iirc. where does the crash happen ? somewhere in python-apt/libapt?
<pitti> mvo: ?? -> ?? -> PyString_FromString () -> ??
<pitti> the second ?? is in libglib
<pitti> and the topmost (first) ?? is at address 0
<pitti> not too helpful, I guess?
<mvo> pitti: could you please paste the full thing somewhere? or is that all relevant information?
<pitti> mvo: stack trace? that's all
<mvo> pitti: meh, that is indeed not a lot
<pitti> mvo: you can have the strace if you want, but it's largely uninteresting
<pitti> it was a standard i386 gutsy desktop install, then apt-cdrom add the hardy.1 dvd
<pitti> and then u-m
<mvo> pitti: how big is the virutal image? I suppose to big to sent it over the network?
<mvo> pitti: I will try to reproduce it here
<pitti> mvo: ugh, 8 GB; I'm afraid it is, yes :/
<mvo> pitti: hm, could you tar up /var/lib/dpkg and /var/lib/apt and /var/cache/apt (after apt-get clean) and /etc/apt/ and put that somewhere? maybe that is enough to reproduce it
<pitti> sure
<pitti> mvo: I'll add /var/log/dist-upgrade and /etc/apt, too
<mvo> pitti: thanks
<pitti> mvo: http://www.piware.de/tmp/apt-status-gutsy-about-to-upgrade.tar.bz2
<mvo> pitti: thanks, downloading
<pitti> mvo: hm, hang on; I ran gutsy-final, not gutsy-updates; might that be it?
<mvo> pitti: I can reproduce it here it seems, let me debug it further. it might be because of this, but I don't remember a fix in python-apt in gutsy-updates that would have this effect
<pitti> mvo: there's no p-a in gutsy-updates
<pitti> mvo: I'll upgrade some essential bits of this gutsy install before I dist-upgrade to hardy
<mvo> pitti: ok
<pitti> mvo: (python2.5, apt, update-manager)
<ScottK> Good morning pitti.  I think allowing kubutu.org addresses is a good thing.  I know a number of people who use those and not ubuntu.com even though they have one.
<pitti> ScottK: it's not a matter of "allow"; it's a matter of requiring correct Maintainer: fields from @kubuntu.org maintainers, too
<pitti> so it doesn't break, but of course I agree that the regexp shold be fixed
<ScottK> Ah.
<pitti> mvo: damn, same segfault with those guty-updates packages :/
<mvo> pitti: :( I think I found the bug, strange that it wasn't seen earlier
<pitti> mvo: oh, wow, that was fast. you rock!
<mvo> pitti: it seems like the Priority is NULL for some package on the CD and that makes it crash, I'm trying to figure out which package is causing this now and add some safeguard against this kind of failure
 * pitti runs another test dist-upgrade and toddles off to lunch in the meantime
<doko> err, there is both webkit and webkitkde???
<mvo> pitti: for some reason openssh-blacklist and openssl-blacklist have no priority, this is causing the crash. I'm preparing a sru for python-apt now so that it at least does not crash
<doko> seb128, asac_ : did gnome just copy webkit, and we now have two copies in main? one in qt4/kde4 and one for gnome?
<seb128> doko: "webkit" is not a GNOME thing, it's upstream webkit
<doko> but kde doesn't use it?
<ogra> its an apple thing :)
<doko> Riddell: ^^^
<mvo> pitti: seems to be only happening with the CD too
<stefanlsd> am i allowed to ask a silly bash question here?
<mvo> pitti: I filed #253255 for this crash
<sommer> slangasek: wondering if you have time for a pam, kerberos, auth-client-config question?
<mvo> pitti: I wonder how it happens that the priority did not end up on the CD for those packages. I'm preparing fixes now
<pitti> re
<pitti> mvo: maybe because the 8.04.1 CD has a special hack to use ssh from hardy-final? we wanted to avoid adding the openssh-blacklist package to the live CD, since it took too much space and isn't necessary for the live environment
<pitti> Riddell (CC: doko): how come that webkitkde doesn't build-depend on webkit? /me sniffs a code copy
<doko> pitti: afaiu webkitkde is included in kdelibs5-dev
<mvo> pitti: would that affect the alternate cd as well? because this is where I see the error
<pitti> mvo: oh, right, of course the desktop CD is irrelevant here (I'm using /pool on the DVD as an apt source)
<tkamppeter> pitti, doko, https://wiki.ubuntu.com/MainInclusionProcess has a bug: Step 7 is unnecessary, as this part is already done in step 5.
<pitti> doko: ah, and webkitkde is just the plugin, not the engine
<tkamppeter> doko, what does it mean that you have set my MIR bug 253123 to "In Progress"? Are you currently reviewing it?
<ubottu> Launchpad bug 253123 in pyusb "Main Inclusion Report for pyusb" [Medium,Fix released] https://launchpad.net/bugs/253123
<doko> tkamppeter: waiting for an archive-admin to process
<pitti> tkamppeter: I just promoted it FYI, and closed the bug
<pitti> doko: ISTR that we can demote lesstif2 again? or was this just a dream?
<pitti> oh, it is already
 * pitti closes the bug then
<tkamppeter> pitti, thanks.
<pitti> so, all remaining bugs on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs are incomplete
<doko> lesstif can go
 * pitti hugs doko for his reviewing
<tkamppeter> Riddell, hal-cups-utils should get installable again in some hours.
<pitti> mvo: is bug 253255 actually an issue in update-manager? or only in p-apt?
<ubottu> Launchpad bug 253255 in update-manager "crash gutsy -> hardy hardy 8.04.1 cdrom upgrade" [High,In progress] https://launchpad.net/bugs/253255
<mvo> pitti: python-apt, but I added a workaround into update-manager too for good measure
<pitti> mvo: ah, sweet; do you think we need the workaround in hardy-updates, too? or will the p-apt fix suffice?
<pitti> mvo: oh, I see; you mean for the cases where you dist-upgrade from gutsy-final instead of gutsy-updates
<mvo> pitti: I think it won't hurt to have it in hardy-updates in updat-emanager too, its a pretty small workaround
<pitti> mvo: I keep that VM around for verifying the SRU
<mvo> pitti: thanks a lot!
<pitti> mvo: I agree
<pitti> mvo: thanks to you for the fast fix!
<mvo> I still wonder how that slipped during the 8.04.1 qa :(
<mvo> pitti: any luck with the localegen hang yet?
<pitti> mvo: no, it worked fine in all three scenarios that I tried
<pitti> I guess I have to try again with u-m
<erikg> does ubuntu have a recovery mode invokable when the system's root partition fills up and writes become impossible?
<pitti> erikg: in this case we mount an 1 MB tmpfs to /tmp, so that you can at least log in
<pitti> we are still working on a program to do some guided cleaning, though, ATM you have to clean up yourself
<erikg> pitti: i've worked out a scheme to run a union mount
<mvo> erikg: there is also a recovery-menu that might be useful, however it does not have a "make free space" item yet (also that is probably a good idea to add)
<erikg> ... a tmpfs+root overlay
<erikg> with aufs (and the uber-buggy unionfs) you can run a script which checks which files are 'deleted' and remove them from the underlying fs
<erikg> all software will run provided there is enough ram
<erikg> is this roughly what y'all are doing?
<cjwatson> we don't use a unionfs, we just slap a tmpfs on /tmp which is enough to get gdm going
<cjwatson> we'd rather not have any kind of union filesystem involved outside the live CD
<erikg> is the concern about code stability?
<cjwatson> once bitten, twice shy
<erikg> have you tested aufs?
 * erikg is a two-brick kind've guy
<cjwatson> I don't care :)
<pitti> *cough*
<cjwatson> the less code involved when your system is already screwed, the better
<cjwatson> KISS
<cjwatson> we're using aufs on the live CD now
<emgent> evening
<erikg> cool
<cjwatson> that seems sufficient
<erikg> cjwatson: yup.  makes sense.
<cjwatson> although, since I'm a pessimist, I assume that it will simply exchange the bugs we knew about for different bugs we haven't worked around yet :P
<cjwatson> we had tested unionfs exhaustively in the live CD for two years, and worked around or fixed the major problems that bit us
<cjwatson> we have tested aufs for one milestone release of intrepid
<cjwatson> not really the same thing :)
<pitti> I wonder which interesting interactions it will do with AppArmor this time
<erikg> i ran into serious issues using unionfs on top of jffs2.  aufs didn't smoke nearly as much.
<cjwatson> I'll let you know in two years
<erikg> i'll be happy to hear
<cjwatson> until then, I'll remain sceptical, I think ;)
<erikg> i admire your skepticism :)
<erikg> if, in two years you find aufs to be trustable, you can use it to implement system recovery at a low enough level that software on the system need not be told what's going on.
<erikg> that's my thought.  i've been working on the idea for a week or so.
<cjwatson> I don't think you'd want to run it too silently
<erikg> you just need a flag of some kind that a recovery console can find on dm startup to inform the user of what's going on and offer recovery solutions.
<cjwatson> after all, if the overlay is a tmpfs, power failures will lose any data that an unwitting user creates
<erikg> right.  ^^
<erikg> you have to tell them very loudly what's going on.
<cjwatson> it seems like unnecessary complexity when you could just mount a tmpfs and help them to delete unnecessary files, though
<cjwatson> what is the *advantage* of a union filesystem approach?
<cjwatson> seems like you actively wouldn't want the user to be able to run all applications completely smoothly
<cjwatson> because then, well, they might use them ... and start trying to save files etc. "well, it all seems to work, I'll just get this done"
<erikg> right
<erikg> you're just trading one set of problems for another
<erikg> if you go the recovery console approach then there is no specific advantage.
<erikg> in that case the union filesystem code paths add a lot of potential complexity.
<erikg> the specific advantage of the recovery-mode solution is the amount of code change required to get unaware applications, dms, etc. running on the recovery-mode system is much less.
<erikg> because the system presents a familiar face to them.
<erikg> that's maybe totally unnecessary
<erikg> and as you said potentially confusing.
<Hattory> Hi asac, can you please take a look at bug 252793 ?
<ubottu> Launchpad bug 252793 in xulrunner-1.9 "xulrunner ships some images as executables" [Undecided,Confirmed] https://launchpad.net/bugs/252793
<lamont> jdstrand: wth is /etc/apparmor/severity.db named that?  it's not a *&)*^% db file
<tseliot> pitti: what does XorgDriverHandler.can_change() do?
<jdstrand> lamont: *shrug*
<lamont> meh
<lamont> it offends me
<pitti> tseliot: if can_change() returns a string (and not None), it is the rationale why the driver cannot be enabled/disabled
<pitti> tseliot: see Handler.can_change() documentation
<pitti> tseliot: if current xorg.conf cannot be parsed, we better not modify it any further
<jdstrand> lamont: apparently apparmor uses that file to map events into severity levels when logging
<jdstrand> lamont: this is a nice touch though:
<jdstrand> $ file ./severity.db
<jdstrand> ./severity.db: ASCII Pascal program text
<pitti> pah, it doesn't even end with "END."
<lamont> jdstrand: yeah, but it means I can't tell my /etc-VCS of any choice to ignore '*.db'
<pitti> . o O { IMHO real .db files don't belong into /etc in the first place }
<pitti> *cough* postfix *cough*
<mvo> pitti: a dist-upgrade just finished for me (in vmware, gutsy->hardy with no hangs via update-manager)
<mvo> just fyi
<pitti> mvo: with thew new p-apt? rocking!
<tseliot> pitti: ok, thanks
<mvo> yes
 * pitti hugs mvo
<jdstrand> pitti: well, it's not just postfix-- sendmail will do the same thing
<mvo> pitti: but no hangs in localegen
<pitti> jdstrand: yeah, unfortunately
<pitti> but IMHO these belong into /var/cache/
<jdstrand> I'd agree with that
<pitti> or at least /var/lib, if people want to deliberately keep the /etc/ master and .db file inconsistent
<jdstrand> I see your point though-- users aren't suppoed to touch those .db files, so why in /etc?
<pitti> /etc/libgda-3.0/sales_test.db
<pitti> *blink*
<ogra> haha
<ogra> great
<lamont> pitti: yeah - is historical in origin
 * lamont wonders idly if xkb is needed anywhere outside of, um, X
<lamont> (with apologies to the name-pedants from MIT)
<lamont>  /etc/hddtemp.db: ISO-8859 English text
<lamont> sigh
<geser> soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge?
<pitti> lamont: even then, what's wrong with ignoring all *.db by default? did you actually come across any which you would actively want to manage in VCS?
<pitti> lamont: (even then you can still explicitly add it...)
<lamont> pitti: depending on the vcs
<lamont> but yeah
<ion_> Iâd suggest managing /etc with e.g. puppet and having puppetmasterâs rules in VCS, not the actual /etc.
<lamont> one could also argue that keeping *.db in the vcs is perfectly fine
<lamont> ion_: too much work. :-)
<zul> tkamppeter: ping
<pitti> lamont: I only add/manage files I actually touched
<lamont> pitti: managing everything is wonderful for noticing when (and how) a dist-upgrade trashed something you care about (now that it's wrong^Wdifferent)
<pitti> I usually ignore unmodified conffiles, but yeah, for those purposes it's certainly handy
<pitti> but too much noise for my taste
<ion_> lamont: Initially thereâs some work for sure, but if you ever have to replace the box with another that should behave identically, or replicate a certain change to multiple boxes, something like puppet will pay for itself.
<lamont> true enough
<lamont> ion_: is puppet VCS-centric?
<ion_> Nope, you can pick any VCS you want.
<lamont> ruby.  vomit
<ion_> ruby â¥
<lamont> language-du-jour crap
<ion_> Not that you ever need to know or care which language puppetâs implemented in when using it.
<ion_> AFAIU
<thom> indeed
<ion_> Hey, at least itâs nicer than python. :-)
<jcastro> puppet is fantastic
<cjwatson> lamont: yes, xkb is used by console-setup too
<lamont> cjwatson: ok
<lamont> thanks
<pitti> I usually ignore unmodified conffiles, but yeah, for those purposes it's certainly handyoperation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=114 name="/etc/"
<pitti> argh, what was that...
<pitti> kees: do you know which apparmor rule is missing here: operation="inode_permission" requested_mask="::r" denied_mask="::r" fsuid=114 name="/etc/"
<pitti> kees: I already have
<pitti>   /etc r,
<pitti>   /etc/** rmk,
<pitti> kees: many rejects look like "wk::" (whcih is fine, I'll fix that); does the first, second, third position (separated by colons) matter?
<sbeattie> pitti: change the first rule to /etc/ r, there was some small semantic changes around how directories are handled.
<pitti> oh, trailing slash?
<sbeattie> yes
<pitti> aaah
<pitti> thanks
<sbeattie> Though I thought that came into effect in hardy or before.
<kees> pitti: sbeattie beat me.  :)
<pitti> the one thing I really don't like is that I essentially have to write all rules twice
<pitti> once for the directory itself (/etc/), once for everything in it (/etc/**)
<kees> pitti: the position wrt :'s indicates the type of access (user::group::other)
<sbeattie> yes, that's a slight pain.
<pitti> kees: ah, helpful; thanks
<kees> pitti: but it doesn't really matter for writing rules, it's a future extention, AIUI
<sbeattie> Yes, that's mostly correct; in particular the semantics around the group stuff will likely change.
<pitti> ok, one other question while I have you both on the wire
<pitti> [ 4350.726750] type=1502 audit(1217431494.911:211638): operation="file_lock" requested_mask="::wk" denied_mask="::k" fsuid=114 name="/var/log/wtmp" pid=19878 profile="/usr/share/gdm/guest-session/Xsession"
<pitti> I have   #include <abstractions/wutmp>
<pitti> I think I should file this as a bug, /etc/apparmor.d/abstractions/wutmp is missing a 'k' privilege
<pitti> right?
<sbeattie> I agree.
<pitti> or is there any reason to deny this by default in wutmp?
<sbeattie> Not that I'm aware of; I'd assume everyone that's going to write to wutmp will try to lock it.
<pitti> I think 'k' is fairly new (intrepid?)
<pitti> at least it was new to me, last time I wrote AA rules was hardy (for cups)
<pitti> ok, done (253328)
<pitti> sbeattie, kees: thanks!
<sbeattie> Hmm, I'm not actually sure what version of apparmor went in to hardy; it may be new.
<tkamppeter> zul, hi
<zul> tkamppeter: I noticed that you uploaded system-config-printer which version of samba does that work with?
<sbeattie> pitti: you're welcome, always glad to have users of and feedback for apparmor!
<pitti> sbeattie: I'm currently writing a profile for the guest user, and AA rules are handy for that (locking out of /home, etc.)
<sbeattie> Cool!
<tkamppeter> zul, the current upload is the s-c-p 1.0.x series and it works with Samba 3.0.x or later. It accesses Samba by calling command line tools.
<zul> tkamppeter: ok because we have samba-3.2 for intrepid
<pitti> sbeattie, kees: hm, seems @{HOME} gets hardcoded to /home instead of the fsuid's home directory?
<kees> pitti: unfortunately, yes.
<pitti> argh
<kees> AIUI, the kernel has no way to knowing fsuid's home dir
<tkamppeter> zul, the GIT head branch (1.1.x) of s-c-p needs Samba 3.2.x. It access es via a Python bindings library written by Tim Wuagh.
<pitti> kees: hm, how does that work then? i. e. what's the particular substituded value?
<pitti> bash:  @{HOME}/.bashrc                  r,
<pitti> is that basically "/home/*" ?
<ion_> pitti: /me â¥ the guest account spec
<pitti> ion_: you're welcome to try and test it, first version is in intrepid (pretty crappy still, though)
<tkamppeter> zul, for now I have uploaded 1.0.x as Samab 3.2 did not arrive. According to yesterday's IRC talk it is waiting for a MIR on talloc.
<kees> pitti: /etc/apparmor.d/tunables/home
<pitti> ah, nice
<pitti> eww, that has /root/, too
<kees> pitti: feel free to branch the AA bzr tree and make patches to stuff as you see fit.
<kees> pitti: doing an AA profile for a _user_ instead of a _process_ is likely going to be tricky.
<zul> tkamppeter: uh ok..
<ion_> pitti: /me aptitude updates. Yesterday there was still no guest-account package in the archive.
<pitti> kees: yeah, I guess it would be pretty expensive to teach the kernel the fsuid's home dir
<pitti> ion_: went in this morning
<ion_> Cool
<pitti> kees: well, to be precise it is for the process /usr/share/gdm/guest-session/Xsession and all of its descendants
<pitti> kees: I wrapped that script around /etc/gdm/Xsession precisely to have a process anchor for AA
<kees> ah-ha, okay.
<pitti> that's much easier in SELinux, but that way it works in AA, too
<pitti> denied_mask="::r" fsuid=114 name="/home/"
<pitti> MUHAHA
<ion_> pitti: /usr/share/gdm/guest-session/guest-session-launch started a new gdm login, but didnât seem to run any of /usr/share/gdm/guest-session/*.sh
<davmor2> I've noticed an issue with intrepid.  Everytime the screen goes blank (for the screensaver) a second or two after it wakes back up.  This means that it isn't cutting into power saving mode correctly :(
<davmor2> What do I report it against?
<pitti> ion_: just a gdm login? with the greeter?
<pitti> ion_: you should have gotten a guest session right away
<ion_> pitti: Yeah. Asking for a password.
<pitti> ion_: do you have gdm 2.20.7-0ubuntu3 ?
<ion_> pitti: Yeah
 * pitti fixes that dependency
<pitti> ion_: and restarted gdm since the upgrade?
<ion_> pitti: Oh! Havenât done that. Will do.
<tseliot> pitti: xorg_driver + XKit passed all your tests. Yay!
<pitti> tseliot: rocking!
<pitti> ion_: dependency fixed in bzr head, thanks
<aos101> bdmurray: Could you have a look at bug 199393 and see why it hasn't been verified yet?
<ubottu> Launchpad bug 199393 in dolphin "servicemenu for amarok has an invalid menu entry "addAsPodcast"" [Undecided,Fix committed] https://launchpad.net/bugs/199393
<jack> dolphin is obsolete now anyway
<jack> successor = d3lphin
<aos101> jack: But it's a SRU.  People still use Kubuntu 8.04 KDE3 :-)
<jack> d3lphin is kde3
<jack> the upstream folks dropped developing kde3 stuff, hence dolphin->d3lphin
<jack> new guy
<aos101> jack: The package was renamed I think.  The dolphin package is the KDE3 version in Hardy.
<jack> oke
<sbeattie> aos101: I haven't gotten around to verifying it yet, I'll try to get to it in the next day or so.
<slangasek> sommer: shifted time, perhaps. :)
<aos101> sbeattie: Thanks for taking a look.
<sommer> slangasek: with the current auth-client-config kerberos example: http://paste.ubuntu.com/32251/ you can't get a ticket if your system password is the same as the kerberos principal password
<sommer> slangasek: I was just wondering if there was some way to adjust it to where you can
<sommer> slangasek: at least in my testing when the passwords are the same, it only authenticates using the shadow password
<slangasek> sommer: configure 'minimum_uid' for pam_krb5, then list pam_krb5 first
<slangasek> or 'ignore_root' instead of 'minimum_uid'
<sommer> slangasek: awesome, I'll look into that... heard you were a pam genius, so I thought I'd ask, thanks
<sommer> slangasek: thanks again, the 'ignore_root' worked great
<warren> Hey folks, I suspect Adobe is about to release a VERY broken flash 10, and I need quick testing to confirm.
<warren> I need testers using 32bit Ubuntu.
<ogra> asac, ^^^^
<warren> The test is simple:
<warren> 1) Make sure you don't either do not have nspluginwrapper, or nspluginwrapper-1.1.0.  (nspluginwrapper-0.9.x does not support windowless plugins, which hides the crasher.)
<warren> 2) http://labs.adobe.com/technologies/flashplayer10/  install Flash 10 beta plugin
<warren> 3) Run firefox, check about:plugins, make sure you are running the plugin
<warren> 4) go to http://weather.com
<warren> kaboom?
<ogra> warren, note that we dont have nspluginwrapper for 32bit anyway
<warren> ok good, simpler test.
<cody-somerville> warren, that issue is known
<cody-somerville> warren, the bug is in Firefox
<warren> bug #?
<warren> oh?
<warren> bug URL?
<ogra> cody-somerville, not the pulse bug
<warren> This has nothing to do with sound
<ogra> warren knows about it
<ion_> Iâd like to have nspluginwrapper. :-)
<warren> Flash (or something) is giving a NULL pointer and it crashes firefox somewhere in cairo.
<warren> btw, where is your pulseaudio bug?
<ogra> warren, asac would be the best to comment here (he maintains ff) but seems not around
<warren> ogra: Any other tester with 32bit Ubuntu would be fine.
<cody-somerville> warren, https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025779.html
<warren> no lauchpad bug?
<ogra> cody-somerville, that was because someone backported libflashplugin together with flash 10
<warren> cody-somerville: where is the pulse bug?
<warren> cody-somerville: did you backtrace it to cairo?
<ogra> thats cant work, libflashplugin clashes with flash 10
<warren> btw, you might want to try flash 10 without libflashplugin
<cody-somerville> ogra, I don't think so
<ogra> cody-somerville, wel, the only backport i saw depended on libflashplugin
<cody-somerville> This was the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=435764
<warren> We RH gave adobe some advice, and now pulseaudio alsa can handle flash directly without libflashplugin.
<ubottu> Mozilla bug 435764 in Plug-ins "crash [@ cairo_draw_with_xlib] painting windowless plugins when MIME type is obtained from data/src" [Critical,Resolved: fixed]
<ogra> cody-somerville, so there was a backport without depentding on libflashplugin ? else trying out backports is moot
<ogra> since thats definately broken
<warren> oh, I see Adobe already knows about htis.
<cody-somerville> ogra, The backport is not related to this discussion besides the face that the same bug showed its head then.
<cody-somerville> s/face/fact
<ogra> cjwatson, btw, another package to pull from the archive :)
<cody-somerville> ogra, sorry if my lack of context with the link was confusing
<ogra> cody-somerville, well, i always block on the fact that i know someone did that broken backport
<ogra> and that it has to crash by design
<warren> thanks for pointing out that upstreaa bug #
<warren> that seems to be it
<ogra> good
<LaserJock> Ubuntu QA meeting in #ubuntu-meeting in 1 minute, if anybody's interested
<ogra> well, that was good inter distro work :)
<ogra> warren, we should definately talk more across the borders ;)
<warren> ogra: I rather continue the war.
<ogra> :P
<warren> ogra: I forget why this war started.
<warren> I just know I'm supposed to hate.
<warren> =)
<ogra> who cares as long as we can fight *g*
<warren> ogra: oh right, the war started because we both needed propaganda to excite our users.
<jcole> anyone here know where to find information on rebuilding a live cd, but re-building it in such a way that files are placed "in order" as they would boot up on the live cd? this supposedly drastically decreases the boot time... i read something about this trick a while back but cannot seem to find a link
<ogra> heh
<ogra> jcole, afaik you hav to patch the squashfs module for that
<jcole> ogra: oh ok... ï»¿this looks a looks like this may be a start to what im looking for -> http://lichota.net/~krzysiek/projects/kubuntu/dapper-livecd-optimization/
<jcole> ogra: i would rather have a howto though, lol
<ogra> yeah, i dont know how to make squashfs spit out the info though, but i know you need to add a patch
<warren> ogra: ok, so I might spy.
<ogra> :)
<ion_> pitti: The guest session still doesnât seem to work after restarting gdm. How to debug this? The screen goes blank, but then it just returns to my original session.
<pitti> ion_: can you please enable debugging in gdm, try one guest login, and send me /var/log/syslog ?
<pitti> /etc/gdm/gdm.conf-custom:
<pitti> [debug]
<pitti> Enable=True
<ion_> Thanks, will do.
<pitti> ion_: appreciated
<ion_> pitti: Duh, it was my fault. I had created a âguestâ account before, and the script didnât like that. âUser account guest already exists and is not lockedâ
<ion_> Iâll just remove the account.
<pitti> ion_: ah, that's indeed a safety measure I built in
<pitti> ion_: I think in that case I should create a guest2 account or so
<pitti> the -setup.sh script should iterate until it finds a unused one, until a reasonable limit
<pitti> but that's a bit hairy
<ion_> Perhaps guest-$(uuidgen) :-P
<pitti> if you exit the guest session normally, the temporary account is deleted again, but that doesn't always work (if your system crashes, or you don't log out the server, etc.)
<hwilde> anybody for help on ssh ? :(
<hwilde> I can ping and telnet to port 22 but ssh rejected :((    http://paste.ubuntu.com/32303/
<pitti> hwilde: anything more helpful in the server-side log?
<hwilde> if I could get to it
<hwilde> :/
<hwilde> it fails right after the KEXINIT but the keys are (were) setup and even so it should failover to keyboard-interactive
<pitti> the "connection reset by peer" doesn't actually look like a proper ssh message; rather rejection by firewall or something
<hwilde> no firewall, it's a direct connect, on the same subnet even
<hwilde> 10.0.84.100 to 10.0.84.202
<hwilde> and I can get to .201 and .203
<hwilde> plus a firewall would reject before it tries kexinit right?
<hwilde> it would just straight up block port 22
<hwilde> so it wouldn't get to  debug1: Connection established.
<hwilde> and telnet would also fail then
<ion_> pitti: The session opened nicely, but gnome-settings-daemon died almost immediately and the Gtk theme changed to the default grey theme until i started gnome-settings-daemon manually. Strange.
<pitti> ion_: right, here too; but that's not specific to the guest session, that happens on normal fresh profiles as well
<pitti> itz seb128 bug
<ion_> Ah, okay
<hwilde> pitti, any ideas I could try to login?
<hwilde> dead in the water right now :/
<pitti> hwilde: sorry, no :( I have only user level ssh fu, I'm afraid
<pitti> hwilde: try giving a good ale to cjwatson or so...
<hwilde> lol he will just take an hour to explain to me why I shouldn't need to ssh to it
<pitti> really? I thought Colin can solve every problem with a clever combination of ssh, xargs, and join?
<hwilde> ha
<hwilde> +expect
<hwilde> he usually just tells me I shouldn't be doing what I'm doing :)
<hwilde> and in this case he will be like why don't you just reboot it
<hwilde> as if I can get to it to reboot it
<pitti> if it's the same subnet, it should be in walking distance? :-)
<hwilde> yeah, if I was in Alabama
<hwilde> but I am not
<hwilde> that's a long walk.
<hwilde> I have 7 machines there and I can only ssh to 6 of them :(
<ion_> pitti: I managed to get the session to crash (by playing with xrandr). Running /usr/share/gdm/guest-session/guest-session-cleanup.sh manually fails with âuserdel: user guest is currently logged inâ.
<pitti> ion_: it at least removed the tmpfs, and so on
<ion_> pitti: Yeah
<pitti> ion_: the last error is a bit of a mystery to me, too, I've seen it as well
<pitti> no idea what userdel checks for this
<ion_> utmp probably.
<pitti> do you see any guest in "who"?
<ion_> No
<ion_> % grep guest /var/run/utmp
<ion_> Binary file /var/run/utmp matches
<pitti> maybe wtmp then?
<pitti> last | head   -> any "still logged in"?
<Mithrandir> ps axu | grep guest ?
<ion_> guest    tty9         :20              Wed Jul 30 22:14    gone - no logout
<ion_> mithrandir: Nope, the cleanup script kills all guestâs processes.
<hwilde> who -u
<ion_> No guest there.
<pitti> ion_: bug 239449
<ubottu> Launchpad bug 239449 in ubuntu "Can't delete an account after first time login and logout" [Undecided,New] https://launchpad.net/bugs/239449
<ion_> The latter lines in who -aâs output are interesting: http://heh.fi/tmp/typescript
<seb128> doko: you really don't want to use sync request tool to request syncs?
<pitti> ion_: oh, uh...
<ion_> who -d, to be more accurate
<totopalma> hi all :)
<hwilde> why... I can ping and telnet to port 22 but ssh rejected :(   http://paste.ubuntu.com/32303/
 * pitti fends off seb128 sponsor bug subscription attack with a triple dput move
<seb128> ;-)
 * seb128 hugs pitti
<pitti> seb128: if only seahorse would remember my gpg key... :-)
 * pitti hugs seb128
<seb128> my issue is rather gnome-keyring not remembering my ssh key at the moment :--
<seb128> :-(
<pitti> seb128: but that can be circumvented with a single ssh-add at session start
<pitti> but I don't know an equivalent thing for gpg
<seb128> right
<seb128> downgrade seahorse to the hardy version, that should work on intrepid too ;-)
<pitti> seahorse? not g-k?
<pitti> seb128: looking at kwwii's new theme package, too, while I am at it
<seb128> ah, thanks
<seb128> pitti: seahorse does gpg, gnome-keyring does ssh
<pitti> oh, so they broke at the very same time? strange
<seb128> pitti: they splitted seahorse but didn't roll a new tarball for the extra package which has the gedit, epiphany-browser, agent, etc
<seb128> well seahorse is technically not a bug
<seb128> they decided to move all the side features to a new component
<seb128> I'm not sure I agree about the agent being a side feature though
<seb128> but it's good to have the epiphany-browser, gedit, etc plugins splitted
<seb128> they just didn't roll a tarball for that yet
<totopalma> hi Riddell , can you please take a look at bug #39383 and 250459?
<ubottu> Launchpad bug 39383 in kdebluetooth "No icons in GNOME" [Medium,Confirmed] https://launchpad.net/bugs/39383
<ubottu> Launchpad bug 250459 in net-snmp "Example in snmpcmd man page shows wrong parameter" [Undecided,Confirmed] https://launchpad.net/bugs/250459
<Riddell> hi tonohono_
<tonohono_> howdy
<norsetto> lol
<Riddell> totopalma: I asked tonio look at that, he's more familiar with kdebluetooth
<Riddell> totopalma: he says he'll change it in the next upload, he's currently packaging kdebluetooth4 and I guess things will change
<Riddell> totopalma: I've assigned it to tonio, let me know if he doesn't upload it by the end of the week
<slangasek> TheMuso: is this issue with pulseaudio indexing the alsa devices backwards one that you're working on?
<slangasek> TheMuso: looks like there was a pulseaudio update, then the bug was reopened
<totopalma> Riddell, ok :)
<slangasek> ogra: there are a number of bugs in ltsp that have been fixed in hardy SRU but are still open for intrepid; are these in progress somewhere?
<totopalma> Riddell, can you please take a look at bug #250459?
<ubottu> Launchpad bug 250459 in net-snmp "Example in snmpcmd man page shows wrong parameter" [Undecided,Confirmed] https://launchpad.net/bugs/250459
<ion_> pitti: utmp contains a ut_type=USER_PROCESS, ut_user=guest entry with a nonexistent pid. who doesnât list it because coreutils lib/readutmp.c desirable_utmp_entry causes who to ignore any USER_PROCESS entries that kill -0 fails for. deluser does not have such a test.
<ion_> pitti: who ceases to do the kill -0 check if it is passed an utmp filename:
<ion_> % who /var/run/utmp | grep guest
<ion_> guest    tty9         2008-07-30 22:14 (:20)
<geser> seb128: re bug 250632: could you please rerun the sync script with the option to overwrite Ubuntu changes? thanks. (I've reopen the bug already)
<ubottu> Launchpad bug 250632 in pdfedit "Please sync pdfedit 0.4.1-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/250632
<ogra> slangasek, oh, i havent closed them, most were fixed last week when i was in portland at the freegeek hackfest ... i added it to my TODO to go through them tomorrow
<slangasek> ogra: ok, thanks
<seb128> geser: hum, the script should not close bugs in such cases, thanks for noticing
<ogra> (currently classmate has higher prio)
<seb128> geser: synced
<geser> doko: re the java changes in intrepid: is it safe to assume that a lib*-java package will be fine with a -headless dependency?
<doko> geser: depends on the package
<geser> so if I'm not sure better use default-jre?
<calc> doko: oh btw OOo currently fails to build with openjdk but there is an open bug upstream about it
<doko> calc: URL?
<calc> lemme find it
<calc> http://qa.openoffice.org/issues/show_bug.cgi?id=91641
<ubottu> calc: Error: Could not parse XML returned by OpenOffice.org: HTTP Error 404: Not Found (http://openoffice.org/issues/xml.cgi?id=91641)
<doko> geser: if a package doesn't provide a UI, -headless should be ok.
<doko> UI = X based UI
<doko> calc: build with the rhino from the system?
<geser> doko: is looking at the package contents enough? e.g. a package which ships only some jars in /usr/shar/java and nothing in /usr/bin?
<calc> doko: rene was the person who pointed me to the bug, he claimed its not possible to build with external rhino or he would have already switched it over himself
<calc> doko: i haven't taken the time yet to look at what would be involved to attempt to do so
<doko> geser: no, e.g. a library on top of awt/swing must not only depend on -headless
<calc> doko: he said he has already set OOo to use everything from the system possible (or i guess at least has hooks to do so)
<geser> doko: ah, I guess I understand
<geser> doko: an other question (build-dependencies): does the use of default-jdk-builddep only apply for package names ending in -gcj? so for package (lib*-java) build depending currently on java-gcj-compat-dev it's correct to replace it with default-jdk?
<doko> geser: yes, this should work
<geser> doko: thanks
<TheMuso> slangasek: The upload I made for that bug was to fix it. I'll read into why it was re-opened this morning, but suspect someone has settings laying around to set the pc speaker as the output device.
<calc> slangasek: how does it break windows browsing?
<slangasek> calc: it lies and returns A records for all hosts, breaking Samba's fall-through name resolution mechanism
<ogra> and its not really a content filter, is it?
<slangasek> to work around this, you have to do broadcast NBNS resolution before DNS resolution, when looking for a server's IP; this would be a horrible thing to have to set as a default, we were almost rid of NBNS
<TheMuso> slangasek: Ah people think its not entirely fixed due to the crackling. Hopefully that can be solved by muting the device, but I'll have a look today.
<slangasek> TheMuso: excellent, thanks :)
<calc> slangasek: can't you disable the bit that causes it to pop up for non-existant hosts?
<calc> s/pop up/return A records/g
<slangasek> calc: I don't know, but I can infer that their /default/ setting breaks Samba browsing
<liw> opendns falsifies dns responses?
<calc> iirc there is way to not have it do that for non-existent domains
<calc> liw: it shows a page if you go to a non-existent site, so er yea more or less
<ogra> liw, in black/whitelist manner ...
<ion_> Ew
 * ogra wishes he had more time for willowng ...
<slangasek> liw: yes, it helpfully directs you to their customized "page not found" page, basically
<slangasek> which doesn't work so well *when the thing doing the lookup doesn't speak HTTP*
<liw> er, um. er, um. er. um. um. er. um. er. and um.
<ogra> heh
#ubuntu-devel 2008-07-31
<cjwatson> liw: you don't speak fluent HTTP?
 * ion_ is quite happy with his own server that sends the queries to the source.
<ogra> cjwatson, he just tried but missed the tags :)
<liw> cjwatson, _I_ do, after implementing it for Kannel, but, er, um...
<cjwatson> well, yeah, as it happens I do too but :)
<cjwatson> ogra: no tags in HTTP, that's HTML :)
<ogra> well :)
<calc> slangasek: well it does return the response as non-authoritative
<liw> I've had to battle with enough weirdness in DNS even when things work according to spec (my brain find DNS to be illogical), I really wouldn't want to have to deal with more broken DNS implementations than I have to...
<slangasek> the logical next step is for them to run a POP3 server on the same IP, and start remotely deleting your email for you
<slangasek> calc: that's, er, meaningless to almost all local resolvers
<slangasek> calc: because *every* reply that doesn't come directly from the authoritative nameserver is supposed to be tagged that way
<mathiaz> is it normal that libtoolize --copy --force deletes config.{sub,guess} but doesn't restore them ?
<slangasek> not traditionally, but who knows with the new libtool :)
<mathiaz> slangasek: I'm running into this problem when trying to build openldap on intrepid
<mathiaz> slangasek: config.{sub,guess} are copied before autogen.sh is run, and then the build fails
<slangasek> that really sounds like a libtool bug to me, then
<slangasek> Keybuk: ^^ ?
<slangasek> mathiaz: did you see my reply/branch on the cn=config stuff, btw?
<mathiaz> slangasek: yop - I've got a reply ready in my Outbox.
<mathiaz> slangasek: I've come up with a solution to *not* bring back the perl code :)
<mathiaz> slangasek: I've also cherrypicked some of the changes you've made in your bzr branch
<slangasek> wow, I'm interested to see how you managed that, then. :)
<mathiaz> slangasek: well - just a for loop - but not that I think of it, it doesn't support includes in included files... yet
<slangasek> does it handle merging of continued lines?
<mathiaz> slangasek: such as ?
<slangasek> mathiaz: slapd.conf supports line continuation with \
<mathiaz> slangasek: on includes ?
<slangasek> mathiaz: so if you don't handle this, you won't necessarily have parsed the file correctly
<slangasek> on any directive, sure...
<mathiaz> slangasek: hm - then my solution won't work :/
<mathiaz> slangasek: I'll dive into that once I've uploaded something in intrepid
<slangasek> ok
<cjwatson> mathiaz: try adding --install
<mathiaz> cjwatson: thanks - works well now :)
<slangasek> mathiaz: pushed a couple more updates to the cnconfig branch; debconf template updates, basically
<mathiaz> slangasek: great - I've merged your change in my branch
<mathiaz> slangasek: I've also fixed the multi-line parsing stuff for includes
<mathiaz> slangasek: I've pushed all of it to my lp branch
<mathiaz> slangasek: which patch should I send for review: the one against your bzr branch or the against debian svn ?
<__keybuk> mathiaz: probably a bug?  try --install
<__keybuk> ah yes
<__keybuk> don't use --force without --install ;)
<__keybuk> it won't do what you think
<dmb> this new openjdk that is going to be in 8.10, is it fully open source?
<dmb> because i heard openjdk still had some close elements in order for it to build
<ScottK> If it's in Main, it's fully open source.
<pwnguin> or its a bug
<dmb> is there a java plugin associated with openjdk?
<lukehasnoname_> Is another hardy point release coming in the October area?
<lukehasnoname_> sry if I doubled that
<persia> pwnguin: There's no such bug, although not every feature present in sun-java6 is implemented (although 97% are)
<persia> lukehasnoname: More likely December.  October is for intrepid.
<lukehasnoname_> figures
<lukehasnoname_> well, bedtime for me, I'll be on in... 9 hours.
<slangasek> persia: january, rather
<persia> slangasek: Early January?
<slangasek> well, we'll see :)
<persia> Ah.  I was sorta guessing 8.04.1 + six months, and (posibly mis-) remembered that being a few weeks ago.
<slangasek> depends on how well we think we can get the dominoes set up before everyone goes on vacation in December
<slangasek> 8.04.1 was beginning of July
<persia> I guess.  Last year-end seemed fairly active: I'm not sure how this year will turn out.
<wgrant> persia: Where fairly active == two major Soyuz breakages?
<persia> wgrant: Well, there was that, but I also remember there being a bunch of people who were working on stuff: perhaps it was just extra visible because of the Soyuz breakages.
<pitti> Good morning
<pitti> ion_: so you really did have a runaway process?
<pitti> or is it a bug in deluser?
<Hobbsee> hey pitti!
<pitti> hey Hobbsee, how are you?
<Hobbsee> pitti: good :)
 * StevenK waves to pitti 
<Hobbsee> pitti: i found the pieces of paperwork i wanted, so \o/
<ion_> pitti: Neither. A bug in something that is supposed to remove a USER_PROCESS entry from /var/run/utmp.
<ion_> pitti: I changed the USER_PROCESS byte in utmp to DEAD_PROCESS with a hex editor and then deluser worked fine.
<ScottK> Good morning pitti.
<ScottK> pitti saying good morning is really I sign I should go to bed.
<ion_> Ditto
<pitti> ScottK: heh, sleep well!
<Mithrandir> hiya dudes and dudettes
 * Hobbsee stomps on Mithrandir's feet in greeting
<Mithrandir> evilHobbsee
<Hobbsee> :D
<ScottK> Mithrandir: That's redundant.
 * Hobbsee MUHAHAHAHA
 * Hobbsee tickles and pokes ScottK with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<Mithrandir> ScottK: I work for the Redundant Department of Redundant Redundancy.
<StevenK> Sounds like the government
<Mithrandir> njet
<ScottK> Fortunately ScottK has had too much Scotch to feel any of it.
<StevenK> Let's try a pool cue, then
<ScottK> Let's not.
<StevenK> It could be fun
<ScottK> I've just fixed an RC bug in Lenny, so I'd appreciate a break.
<Hobbsee> well, you may well get the break.   it would probably be your kneecaps, though.
<ScottK> Yeah.  Many StevenK will just sponsor the NMU upload instead.
<ScottK> Many/Maybe
<StevenK> Will I? :-)
 * ScottK double checks to make sure he really uploaded to mentors.
<ScottK> Apparently, but that doesn't mean it actually shows up there.
<ScottK> Since mentors appears to have eaten his upload, ScottK tosses out http://kitterman.com/debian/xmms2tray_0.4-1.1.dsc in the hopes that perhaps some DD present (StevenK maybe) will pick it up.
<ScottK> It was an easy one to fix.
 * ScottK stumbles off to bed.
<pitti> doko: is debian/patches/javazic-fixup.patch still required? it's not applied anywhere
<pitti> doko: I guess it's just noise (I already elminitated the sharutils b-dep and the debian/copyright amendment), but I want to confirm with you first
<doko> pitti: no, not needed anymore
<pitti> doko: ok, thanks; where do these three additional javazic/tzdata_jdk/* files come from?
<pitti> there's no documentation in the changelog, nor upstream (bug/code) references
<doko> pitti: part of openjdk as well. openjdk/jdk/make/sun/javazic/tzdata_jdk/*
<pitti> ah, and they are not shipped in -headless, so that they need to be copied?
<doko> yes, I only did want to add the code only. this is data, which could change more often as well?
<pitti> so whenever a timezone is split, the changes need to be applied there as well?
<doko> well, it's an additional symlink, isn't it?
<pitti> right
<pitti> mvo: good morning
<mvo> good morning pitti
<pitti> mvo: some problems with your p-apt SRU, I mailed you
<mvo> pitti: yes, I noticed. thanks. I will re-upload in some minutes
<mvo> pitti: the python-apt stuff is reuploaded with the requested changes
<pitti> mvo: danke sehr!
<lifeless> assertion: config files that include non-active lines make upgrades harder.
<pwnguin> if nouveau didn't rely on unstable kernel interfaces and was sufficiently stable versus nv, would ubuntu ship it?
<persia> pwnguin: Most likely.  As I understand things (and I'm not a nouveau expert) libdrm is currently the main blocker.
<tseliot> pitti: I managed to make Jockey show the 3 supported drivers instead of just one, however the result is far from perfect (and I feel that it's just a cheap workaround) : http://albertomilone.com/Screenshot-Hardware-Drivers.png
<pitti> tseliot: in terms of code hten? the screenshot doesn't have anything surprising
<pitti> (unless one driver is supposed to be enabled0
<tseliot> pitti: the entries in the screenshot don't have the "(VERSION)" beside the name
<pitti> oh, indeed
<seb128> pitti: thanks for moving some of the GNOME srus to -updates (and thanks to pedro who did some testing rounds yesterday)
<pitti> tseliot: I might be able to give you a hand there?
<tseliot> pitti: let's talk in private, I have some code to show you
<pwnguin> persia: well, im curious about why people might feel accepting money is more dangerous than shipping code
<persia> pwnguin: I don't understand what you mean
<Wubbbi> Hello :) I've one question. did you updated the non-free nvidia driver to the current version? "http://www.nvidia.com/object/linux_display_ia32_173.14.12.html" "Fixed a problem with missing rendering in OpenGL Workstation Overlays. " that maybe fix the bug with the kde 4.1 desktop performance?
 * pitti summons our nvidia driver expert tseliot
<tseliot> LOL
 * pitti hugs tseliot
 * tseliot hugs pitti
<Hobbsee> hmmm.  why don't keys work anymore, on intrepid?
<cody-somerville> Hobbsee, we decided keys were too much work to maintain so we disabled them
 * Hobbsee beats cody-somerville
 * cody-somerville is hurting.
<Hobbsee> Agent admitted failure to sign using the key.
<Hobbsee> looks like https://bugs.edge.launchpad.net/seahorse/+bug/201786
<ubottu> Launchpad bug 201786 in seahorse "ssh Agent admitted failure to sign using the key" [Unknown,Confirmed]
<Hobbsee> hmmm.  maybe it isn't, as the workaround doesn't work for me
<seb128> Hobbsee: http://bugzilla.gnome.org/show_bug.cgi?id=544554
<ubottu> Gnome bug 544554 in general "ssh agent doesn't work correctly" [Normal,Reopened]
<seb128> Hobbsee: if the issue is the ssh agent
<Hobbsee> seb
<Hobbsee> seb128: i'll live in hope...
<seb128> Hobbsee: use ssh-add meanwhile?
<Hobbsee> seb128: that looks broken too.  i've installed the pinentry stuff, so we'll see if that fixes it
<seb128> Hobbsee: how is that broken?
<Hobbsee> couldn't connect to agent
<ramvi> Can you help me with customizing a livecd? I've made this sexy /etc/gconf/schemas/local-panel-default-setup.entries and to try to load it as default panel with this command: gconftool-2 --config-source=xml:readwrite:/etc/gconf/local.xml.defaults \   --direct --load \   /etc/gconf/schemas/local-panel-default-setup.entries
<ramvi> But the livecd starts up the same God damn standard panels every time
<ramvi> Why? :)
<Riddell> pitti: I think the language-pack scripts need to be changed to take /usr/share/locale/xx/entry.desktop from kde-l10n-xx instead of kde-i18n-xx, where can I find that?
<pitti> Riddell: the files are actually copied in the langpack-o-matic tree, not taken out of the packages (they are not exported)
<pitti> Riddell: lp:langpack-o-matic has a directory extra-files/ with all the extra KDE bits (entry.desktop, charset, flag)
<pitti> Riddell: those need to be unpacked, the .desktop replaced, and re-tar'ed
<pitti> Riddell: I can do that for you, if you give me the new set of .desktop files? or want to do it yourself? (should just be a moderately complex bash for loop)
 * Riddell grumps as his internet dies for the third time today
<Riddell> pitti: http://www.kubuntu.org/~jriddell/tmp/desktop.tar.gz
<pitti> Riddell: just bear in mind that this won't actually become active until we get the first intrepid export from Rosetta
<pitti> (which we all desperately wait for...)
<pitti> Riddell: will apply, thanks
<Koon> pitti: I was wondering what would be your take on bug 253032 -- also do you think one day it should get integrated to network-manager rather than using a separate applet ?
<ubottu> Launchpad bug 253032 in likewise-open "likewise-open-gui needs a better menu item name" [Low,Confirmed] https://launchpad.net/bugs/253032
<Riddell> pitti: flag.png and charset seem to have disappeared, so should be just entry.desktop now
<pitti> ah, that's good to know; I would have kept them
<pitti> Koon: hm; knowing nothing about AD myself, "Likewise AD settings" is not much more helpful to me, I'm afraid
<pitti> Koon: what does that app do?
<pitti> does it just set the AD server name/workgroup, or something like that?
<Koon> pitti: it allows you to join or leave an Active Directory domain (accepting new logins that are authentified in AD)
<pitti> if so, that should eventually become a n-m plugin, yes
<Koon> "Likewise Active Directory Membership" is a little long
<pitti> I don't think we'll find a name which is both descriptive and short
<pitti> the entire concept is just too complex to explain in a menu entry, IMHO
<pitti> since users shouldn't even care about concepts like AD or pam-ldap, etc.
<Koon> pitti: we can remove "Likewise" since likewise-open is in main as the preferred way of handling AD membership
<pitti> Koon: let's do a step back
<pitti> Koon: do you need that AD membership to log in in the first place, or to access network services?
<pitti> (since I suspect the former, too)
<Koon> pitti: the idea is to let users defined on the domain log in, so the former
<pitti> Koon: shouldn't that be exposed in the login manager rather?
<pitti> Koon: i. e. (just purely as a "how it should look like), gdm displays a list of available domains and allows you to pick one?
<pitti> or, if it's just one, just use it?
<Koon> pitti: makes sense. Though in Windows joining the domain is also done as a logged-in user
<pitti> Koon: hmm; I don't understand where PAM should get your credentials from if it isn't already connected to the AD?
<pitti> or is the concept based on the assumption that the user db is present locally?
<pitti> (wouldn't that make the entire idea pretty worthless?)
<Koon> pitti: you can both use domain logins and local logins
<pitti> I understand it as the windows pendant of pam-ldap
<pitti> I used the latter, but not the former
<Koon> you use a local login to set up AD membership, which plugs pam modules, nsswitch etc.
<Koon> from then on you can log in as a domain user
<pitti> but ICBW (my windows networking knowledge is about this ---><---- big, sorry)
<Koon> pitti: closer integration of AD into login would be the subject of a nice spec I think
<pitti> hm, working as two different users?
<pitti> that sounds overly complex to me?
<pitti> Koon: what does the app actually need to do to join a domain, do you need any authentication to even connect to the server and become able to locally log in users?
<Koon> pitti: that's the way it works on Windows
<broonie> pitti: AD is LDAP+Kerberos so yes, it's roughly where pam-ldap is (it can interoperate with some configuration).
<pitti> so setting up a network with AD requires the admin to set up local logins for every user in addition to maintaining the AD?
<Koon> pitti: when you click "join" (in the elevated-privilege Likewise applet) it prompts you for a AD domain admin user/password
<pitti> (well, there's probably some sort of replication going on, but it still seems weird to me)
<Koon> pitti: no, no need for local users for each domain user
<pitti> Koon: how do users log into a machine then? certainly not through a shared account?
<broonie> The LDAP part provides a user database.
<Koon> pitti: likewise hooks into nsswitch to accept users from local passwd/group and remote AD-provided ones
<Koon> exactly as an external LDAP thing
<pitti> (I actually meant on windows, where you mentioned the two-stage login, but ok)
<Koon> on Windows you log in with the local admin defined during install, join the domain then domain users can log in and you get two admins, a local one and a domain one.
<Koon> both in the "local admins" group
<pitti> Koon: ah, hang on; "prompts you for a AD domain admin user/password" -> so that's *not* the user's name/password for login, but the AD admin's password for setting up this machine to allow AD user login in the future?
<pitti> i. e. something that is done once as a setup, not every day as normal user login?
<Koon> pitti: yes
<pitti> aaah
<Koon> (sorry I'm being unclear)
<pitti> that's where my misunderstanding came from
<pitti> so yeah, integration into gdm doesn't make too much sense then
<pitti> in current hardy/intrepid I'd say that it belongs into network-admin
<Koon> pitti: better as an additional tab in network-manager
<pitti> but that's going away
<pitti> since n-m replaces network-admin, it should go there, yes
<Koon> pitti: ok so we should spec closer AD integration, but for Intrepid+1
<Koon> pitti: for Intrepid do you have any preference ? I mean, anything more descriptive than "Likewise" is OK ?
<pitti> Koon: I'd aim for consistency here; ATM, the large majority of entries in the Admin menu have descriptions without names
<pitti> i. e. it says "Printers" and "Hardware drivers", not system-config-printer and Jockey
<pitti> so what about "Active Directory Setup"?
<Koon> it's a little confusing because you aren't setting up Active Directory. You're setting up your membership to an existing AD
<Koon> I think I prefer "Active Directory Membership" -- the two functions the applet can do is "Join" and "Leave"
<persia> "Active Directory Membership"?
<pitti> Koon: right, "Membership" WFM
<pitti> Koon: thanks for the heads-up!
<Koon> persia: as in "setting up my integration inside an AD domain"
<Koon> pitti: many thanks for taking the time to bear with my explanations :)
<persia> Koon: Right.  It was meant as a suggestion, but you suggested the same thing at the same time :)
<Koon> persia: great minds alike ?
 * pitti sighs at lightweight bzr checkouts; painfully slow...
<Ng> hmm. is this overflow /tmp/ thing a new feature in hardy?
<pitti> Ng: no, it's been there a little longer; feisty?
<Hobbsee> seb128: hmmm.  running ssh-add first seems to fix the problem
<Hobbsee> the key-based auth works after that
<Ng> pitti: interesting. I only just came across it, someone's laptop was full, so the deleted a load of files, but the 1MB overflow /tmp/ was full too, so things still gave out-of-space errors (specifically thunderbird, which uses /tmp/ extensively)
<pitti> Ng: ah; well, it's just meant to allow you to login in the first place to clean up
<pitti> there should be some kind of notifictaion, right
<Ng> pitti: unfortunately the laptop in question is some thousands of miles from me, so I didn't see whether it notified or not, but evidently the user in question didn't notice it, or understand it :/
<Ng> perhaps it should trigger a similar reboot-required thing to kernel updates, so there is a more persisent notification?
<pitti> it would warrant a panel icon, yes
<pitti> it would integrate nicely with liw's system cleanup app
<liw> yay! more files to delete!
<mvo> I added a "clean" hook into the friendly-recovery menu too - this should be integrated with the system-cleanup too probably
<liw> system-cleaner: because files are tasty and unlink(2) is faster than gzip(1)
<gaspa> is there a way to get diffs beetween a generic -ubuntuX  and ubuntuX+1 revision?
<gaspa> i mean, a place where _all_ revision were keeped, or their patches (in latter case i know the answer: no)
<seb128> gaspa: launchpad has those diff now, so for recent version the package summary on launchpad
<gaspa> seb128: ok, i'll see.
<cjwatson> gaspa: also http://patches.ubuntu.com/by-release/atomic/ubuntu/
<gaspa> cjwatson: ah, i didn't know... thanks.
<pitti> seb128: gpm d-bus activated? that would be really weird...
<seb128> pitti: why? it has a /usr/share/dbus-1/services/gnome-power-manager.service
<pitti> oh, really!
<pitti> but I thought that would be a g-p-m backend, not the applet
<pitti> well, I'm confused
<seb128> pitti: what do you mean?
<seb128> pitti: gpm is what is used to know if you can suspend, hibernate, etc
<pitti> seb128: I usually thought applets are started with autostart .desktop files, not via d-bus
<seb128> yes, but I'm not speaking about the applet there
<seb128> the applet is fine
<seb128> that g-p-m itself which doesn't have the right environment
<pitti> ah, I thought daemon and applet are the same process
 * pitti doesn't find a separate power-applet process on his system
<pitti> seb128: hm, so at least my session dbus does have the $XDG_SESSION_COOKIE; it might not pass it to activated services?
<seb128> pitti: there is no applet, it uses the notification area and yes that's gpm itself which doesn't that
<seb128> pitti: right, dbus activation doesn't pass an environment, a patch has been commited to dbus git recently to provide a way to do that
<seb128> pitti: that's one of the reasons why we didn't active gnome-settings-daemon over dbus, otherwise the applications started using multimedia key can't connect to gnome-keyring, etc
<seb128> *idea*
<pitti> right, I remember
<seb128> pitti: thanks pitti, that talk gave me an idea about the issue
<pitti> seb128: so, would it help to have an autostart .desktop file for g-p-m?
<seb128> gdm has an autostart directory
<pitti> /etc/xdg/autostart/gnome-power-manager.desktop, hm, there is
<seb128> but I put something in there to get a command line handy start on the gdm screen
<seb128> and that didn't work
<pitti> gdm might not look at /etc/xdg/autostart/
<pitti> ?
<seb128> I guess for whatever reason it doesn't manage to autostart those
<seb128> and g-p-m get started over dbus when queried
<seb128> pitti: no it doesn't
<pitti> hah; that would be it then
<seb128> it looks to /usr/share/gdm/autostart
<pitti> well, I guess that's a feature
<seb128> well, there is nothing in this one
<seb128> I'm wondering if that's the issue
<pitti> since even though it is a session, you might not want *all* the user stuff in gdm
<seb128> maybe we should have gpm there
<pitti> right, I think you should
<seb128> but why the upstream tarball doesn't install an autostart there then?
<pitti> that's also a little less brittle than relying on d-bus activation env passing
<pitti> maybe Fedora symlinks the one from /e/xdg/autostart?
<seb128> doesn't seem so
<seb128> at least not in the gdm spec
 * seb128 grrrrs at soren
<seb128> virt-manager still doesn't work in intrepid
<mvo> seb128: kvm is also a bit on the crashy side for me in interpid, not sure if that is kvm or the kernel though
<seb128> mvo: well, virt-manager doesn't allow to select an iso, the "next" button in the wizard does nothing
 * pitti currently uses only kvm directly, which seems to work fine
<mvo> meh, different problem I guess, for me kvm (directly without virt-manager) behaves unstable (crashes in the guest etc)
<mvo> sometimes, not always
<seb128> pitti: the fc9 beta iso I have on the disk indeed has a gnome-power-manager.desktop in the gdm autostart directory ;-)
<pitti> with virt-manager, it is unbearably slow (theory: not using /dev/kvm)
<pitti> seb128: Qapla'!
 * pitti hugs seb128
 * seb128 hugs pitti
<seb128> what is the rpm equivalent to dpkg -S file?
<pitti> seb128: see, that should get filed upstream, Fedora didn't properly contribute patches back *cough*
<seb128> ;-)
<pitti> seb128: rpm -q something, --help usually worked for me
<pitti> seb128: however, IMHO it's debatable whether this symlink shuold really go into gpm or gdm
<seb128> pitti: rpm -q -f worked
<seb128> I'm talking to upstream about it
<pitti> argh, too many 'manager's in the session
<pitti> nothing that does the real work :-P
<ScottK> Rename them all 'kit' and it'll be fine.
<Hobbsee> ScottK: *grin*
<pitti> seb128: oh, was the -q -f successful? which package ships it in fedora?
<seb128> pitti: gnome-power-manager
<pitti> ok
<pitti> Riddell: quite a few language desktop files got dropped, though
<pitti> and 5 added
<pitti> Riddell: committed and pushed
<Riddell> pitti: yeah, there's not as many completed langagues in kde 4 yet, I guess you can keep the entity.desktop files from KDE 3 though
<Riddell> entry.desktop rather
<emgent> moin
<LocutusOfBorg> hello!
<LocutusOfBorg> is this a bug report channel???
<LocutusOfBorg> I don't know if is really a bug...
<LocutusOfBorg> I run under ubuntu intrepid ibex, but I cannot usa tty1 to 6
<LocutusOfBorg> no problem with graphics
<mkrufky> LocutusOfBorg: ubuntu uses a bug tracker, located at launchpad.net
<Pici> LocutusOfBorg: Also, the Intrepid discussion channel is #ubuntu+1
<Hobbsee> LocutusOfBorg: i don't think you should be running ibex...
<LocutusOfBorg> Hobbsee, now I run under both 8.04 and 8.10
<LocutusOfBorg> is only for nug huntung... :)
<LocutusOfBorg> mkrufky, I had already submitted a bug on launchpad...
<LocutusOfBorg> https://bugs.launchpad.net/bugs/253661
<ubottu> Launchpad bug 253661 in ubuntu "Intrepid Ibex bug" [Undecided,New]
<LocutusOfBorg> ubottu, yeah
<ubottu> Sorry, I don't know anything about yeah
<Hobbsee> LocutusOfBorg: you should leran to file better bugs than that.  put a more descriptive title on it, for a start.
<LocutusOfBorg> oh, I know
<LocutusOfBorg> thanks...
<LocutusOfBorg> But my english is not good, and I didn't find a better title... :P
<LocutusOfBorg> https://bugs.launchpad.net/bugs/253661
<Hobbsee> try "tty 1-6 does not work with a Ati Radeon 9600 pro" or something
<ubottu> Launchpad bug 253661 in ubuntu "TTY! to 6 Intrepid Ibex bug" [Undecided,Incomplete]
<Hobbsee> either way, this is not a support channel, so please continue this in #ubuntu+1
<LocutusOfBorg> ok...
<LocutusOfBorg> Hobbsee, title changed... :D
<LocutusOfBorg> thanks!
<LocutusOfBorg> have a nice day!
<LocutusOfBorg> i'll go on the other chan
<pitti> kirkland: I'm looking at ecryptfs to steal some knowledge about auth-client-config; how come that there is no postinst/prerm to trigger the PAM updating through a-c-c?
<calc> doko: ping
<pitti> kirkland: the a-c-c manpage suggests that this is necessary?
<doko> well, ask ...
<calc> doko: can you make me an admin on openoffice-pkgs also?
<doko> sure
<calc> thanks :)
<pitti> jdstrand: "auth-client-config -L" doesn't have 'pam-login'; does that mean that I cannot use it to update the 'login' profile? or will that Just Work once I actually add a profile for login?
<pitti> jdstrand: context: for a spec of mine I need to make libck-pam-connector to add itself to /etc/pam.d/login on installation (and cleanup on removal)
<pitti> jdstrand: however, I'm still pretty unsure how to use a-c-c for that
<jdstrand> pitti: hmmm, currently auth-client-config only deals with common-* (and nsswitch.conf)
<calc> how do i delete a package that hasn't built yet from a ppa?
<pitti> jdstrand: I tried to add it to common-auth, but that applies to gdm sessions as well then, which screws up
<calc> i thought i needed admin access to the group, but that doesn't appear to be enough
<pitti> jdstrand: would it be difficult to make it work for login as well? if so, I can cook my own solution in the postinst, but I'd much rather use a-c-c as common infrastructure
<jdstrand> pitti: there isn't a technical reason why auth-client-config couldn't handle arbitrary /etc/pam.d/* files
<jdstrand> pitti: it just currenty doesn't. I'd need to extend it
<pitti> eek, except that /etc/pam.d/login is a conffile
<pitti> while common-session isn't
<pitti> urgh
<jdstrand> pitti: you planning to do this automatically from postinst?
<pitti> jdstrand: ok, seems I can't use a-c-c for this anyway
<slangasek> pitti: why is it specific to login?
<pitti> jdstrand: seems I should rather modify the default conffile accordingly and make it silent if the package isn't installed
<pitti> slangasek: I don't want it for {g,k}dm sessions
<pitti> since then you'll get two CK sessions for the same TTY, which confuses PolicyKit and others, and breaks
<slangasek> pitti: the only way to make it silent right now is to use the 'missingok' module option, which is a horrible kludge that I was planning to get rid of as soon as I had the PAM framework stuff implemented
<pitti> jdstrand: modifying other package's conffiles is a no-no, that's why I can't
<pitti> slangasek: hm; would "the PAM framework stuff" include a scenario like mine? (just apply to VT logins)
<jdstrand> pitti: yes I know, I was trying to ascertain if you were trying to do this via packaging, or have the user run a-c-c
<slangasek> how does that cause two CK sessions for the same TTY, and couldn't that be addressed in either the PAM module (making the module a no-op for X sessions) or in the DM (deferring to PAM)?
<slangasek> pitti: no, not in the least :/
<slangasek> the framework is for managing the "common" files only
<slangasek> the per-service files are conffiles, deliberately
<jdstrand> pitti: based on your comments, it sounds like the former
<pitti> slangasek: I guess that depends on which order the two CK sessions are created
<pitti> jdstrand: just packaging, since we want to install it by default
<jdstrand> (in which case, a-c-c is not a good fit-- unless you plan to have it own login)
<pitti> jdstrand: no, that would be bad
<slangasek> pitti: well, couldn't your module just check pam_get_item(PAM_TTY) and only start a session if it's a real TTY?
<jdstrand> right
<slangasek> (as opposed to an X display)
<pitti> slangasek: if that's possible, sure; also, if gdm registers the CK session before PAM does, the pam-ck could just check for one
<pitti> but if it's the other way around, it gets hairdy
<pitti> hairy
<pitti> slangasek: unfortunately there is no call for modifying an existing session, such as adding an X11 display
<pitti> but it seems you both recommend to do use common-session and fix it in the PAM module itself
<pitti> ok, I'll look into that then
<pitti> jdstrand: so assume I use a-c-c with common-session, a-c-c still needs to be called in the postinst, right? ecryptfs-utils currently doesn't seem to do that
<jdstrand> pitti: correct
<slangasek> I don't think you want to just check for an existing session; I'm not sure that gdm keeps enough PAM state around until the end to let the PAM module know it didn't open it in the first place
<slangasek> a-c-c isn't meant to be called in a maintainer script either :/
<jdstrand> pitti, slangasek: there is documentation in the a-c-c source packge about ideas for using it in packaging, but there is no policy in place
<jdstrand> pitti, slangasek: though I believe there are enough options to safely do it...
<pitti> slangasek: hm, so you neither like changing the default conffile to include it, nor using a-c-c in the postinst?
<pitti> what's the recommended way to set things up then?
<slangasek> pitti: https://wiki.ubuntu.com/PAMConfigFrameworkSpec; you work on fixing your PAM module to handle the TTY, and I'll work on this :)
<pitti> slangasek: ok :)
<jdstrand> slangasek: wrt your Spec-- it doesn't handle nsswith.conf (obviously, it's a pam spec). do you have thoughts on dealing with nss too?
<slangasek> jdstrand: only vague and incomplete thoughts; nss is much simpler by comparison, really
<slangasek> it's "insert this block with the priority I tell you" and then "sed -e's/mymodule( \[[^]]*\])*//'
<jdstrand> slangasek: sure-- I was just thinking of the out-of-the-box experience that is trying to be achieved
<slangasek> "
<slangasek> I mean simpler in terms of implementation
 * jdstrand nods
<jdstrand> slangasek: I guess I am getting at-- what packages will do that?
<slangasek> jdstrand: well, a simple tool to do it can be provided by glibc itself, and then each nss package can call it in the maintainer scripts
<seb128> cjwatson, evand: is https://bugs.launchpad.net/ubuntu/+source/grub/+bug/253323 a known issue? the user who filed it mailed me about it (not sure why) asking if he needed to do something to have the bug triaged correctly
<ubottu> Launchpad bug 253323 in grub "no grub installed when installing ubuntu 8.10 alpha3" [Undecided,New]
<jdstrand> slangasek: there will have to be policy built into that tool for ordering... won't there?
<slangasek> jdstrand: hmm, somewhere, yes :)
<slangasek> sorry, going into a meeting now
 * ogra wonders about the likelyness to get sshfs into main in intrepid 
<jdstrand> slangasek: ok, just wanted to bring it to your attention :)
<ogra> does anyone see any big drawbacks i should know about ? (i.e. is it worth to start a MIR process)
<cjwatson> seb128: I'm not familiar with it, I'm afraid
<seb128> cjwatson: ok, I was wondering if grub is the right component there or if that should be assigned to some installer component
<cjwatson> grub seems a plausible enough start
<seb128> ok, thanks
<cjwatson> it won't be possible to tell without digging into it
<warren> Hmm
<warren> https://bugzilla.mozilla.org/show_bug.cgi?id=435764  was pointed out here yesterday as an upstream fix for the flash 10 crashers.
<ubottu> Mozilla bug 435764 in Plug-ins "crash [@ cairo_draw_with_xlib] painting windowless plugins when MIME type is obtained from data/src" [Critical,Resolved: fixed]
<warren> I patched my xulrunner in Fedora 9, but I found that crashes now happen in nspluginwrapper-1.1.0 instead of firefox.  So it seems further work is needed to fully fix this.
<warren> Just mentioning this because you folks likely will have the same problem.
<ogra> how does it work without nspluginwrapper ?
<warren> ogra: i'm testing that now
<ogra> warren, btw, note that our FF maintainer is at the FF conference atm
<kirkland> pitti: hey, i have meet someone for lunch, i'll get back with you in a bit
<ogra> so it might not be easy to catch him online
<kirkland> pitti: or perhaps jdstrand has answered your questions
<kees> TheMuso: say, your chvt change to initramfs-tools -- won't that hide the messages from the mountroot-fail hooks?  Maybe those should switch to vt1 as well?
<warren> ogra: without nspluginwrapper it seems to no longer crash.
<ogra> warren, hmm ,intresting
<warren> (with the above patch to xulrunner)
<ogra> you probably need to adapt that patch to nspluginwrapper then
<warren> ogra: nspluginwrapper-1.1.0 has new support for the windowless plugin mode in flash 10, so there might be an additional issue in nspluginwrapper
<warren> hm
<warren> I have no idea how this stuff works =)
 * ogra looks at the launchpad downstream bug
<ogra> probaby that gives some hints
<warren> URL?
<ogra> warren, https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/239182/comments/19
<ubottu> Launchpad bug 239182 in firefox-3.0 "segfualt in cairo_draw_with_xlib" [Undecided,Confirmed]
<ogra> hmm, you said you use that version
<warren> yes
<warren> prior versions of nspluginwrapper hid the firefox bug because it didn't pass the windowless stuff to firefox
<ogra> well, in the LP bug some people seem to have it working
<ogra> but we dont have nspluginwrapper on i386
<ogra> (we planned to for intrepid though)
<thibs> hi
<thibs> I have a little question about packaging
<persia> thibs: You may wish to ask in #ubuntu-motu
<thibs> I'll do that!
<thibs> thanks
<warren> ogra: it works on maybe 50% sites
<ogra> hmm, thats not really sufficient
<ogra> but then i doubt upstream mozilla actually uses nspluginwrapper
<ogra> so they might not really care
<warren> ogra: yes, that's part of the problem
<ogra> we do care on amd64
<ogra> and as i dicussed with asac might move to it for i386 as well
<mathiaz> zul: is samba 3.2 in intrepid ?
<mathiaz> zul: I only see 3.0.30 in the archive
<seb128> mathiaz: launchpad is your friend
<seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba
<seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba/2:3.2.0-4ubuntu1
<mathiaz> seb128: oh - thanks - I was looking at packages.ubuntu.com
<seb128> mathiaz: it's in NEW due to libwbclient0 and samba-tools, looking at accepted it now
<alex-weej> new synaptics touchpads support detection of number of fingers when stroking the pad
<mathiaz> seb128: ah - this is why I don't see it there.
<alex-weej> the synaptics driver has an option for enabling scrolling/panning when making a two-fingered stroke
<seb128> mathiaz: https://edge.launchpad.net/ubuntu/+source/samba/2:3.2.0-4ubuntu1 has the "NEW" indications
<alex-weej> it's not on by default, instead with the right and bottom edge serving as vertical and horizontal scrolling areas, purely because of a lowest-common-denominator approach
<seb128> mathiaz: do you know if libwbclient0 and samba-tools need to go to main?
<alex-weej> i had opened a "bug report" for the proposal to enable it by default where possible
<alex-weej> but timo aaltonen said "not likely to happen, besides it's a feature request so I'm tempted to close this."
<alex-weej> *headdesk*
<mathiaz> seb128: let me check - I'm sure slangasek will give a quick answer too
<seb128> mathiaz: ok, binaries accepted, we can adapt the override later
<mathiaz> seb128: ok - samba-tools is only testing stuff - libwbclient0 would definitely find its place in main
<alex-weej> does anyone know what's going on with the seahorse gpg agent in intrepid? it doesn't seem to work...
<alex-weej> *ssh key agent, whatever
 * alex-weej can't push his bzr branch :<
<poningru> just use gpg in the command line
<poningru> oh ssh key
<poningru> check .ssh/
<poningru> err ~/.ssh/
<alex-weej> poningru: check it for what?
<alex-weej> it's fine, and when openssh-ssh fails to get the key from seahorse it asks me for my password on the CLI and it works fine
<alex-weej> it's just i can't log in to launchpad with a password with bzr
<alex-weej> wait, that makes no sense
<seb128> alex-weej: ssh or gpg?
<alex-weej> ssh
<seb128> alex-weej: http://bugzilla.gnome.org/show_bug.cgi?id=544554
<ubottu> Gnome bug 544554 in general "ssh agent doesn't work correctly" [Normal,Reopened]
<alex-weej> i know of at least one other person on #gnome-hackers who has the same problem
<slangasek> seb128: libwbclient0 needs to go in main, samba-tools doesn't
<alex-weej> seb128: thanks
<seb128> slangasek: ok, what I though, thanks
<seb128> alex-weej: you can "unset SSH_AUTH_SOCK" and use no agent as a workaround
<alex-weej> seb128: great, thanks
<poningru> can someone help me write a bug for a particular audio issue?
<poningru> https://help.ubuntu.com/community/AspireOne
<poningru> check under audio
<poningru> just rebuilding it seems to fix aud9io
<tjaalton> alex-weej: so how would you detect such devices?
<alex-weej> tjaalton: any myriad of ways
<alex-weej> tjaalton: if the synaptics hardware doesn't reveal itself
<alex-weej> then you can get the model information of my notebook from HAL
<alex-weej> tjaalton: btw your IRC nick on launchpad is different
<alex-weej> tjaalton: i filed it against xorg for that reason. i don't expect drivers to be looking stuff up in HAL
<tjaalton> alex-weej: so the driver should contain a database of models that support that?
<tjaalton> er, list
<alex-weej> tjaalton: probably HAL FDI with mechanism in Xorg to apply the policy
<alex-weej> tjaalton: basically, i'm sick of Mac OS getting all the fun.
<alex-weej> it "just works"
<tjaalton> well, they don't have that much hardáºare to support..
<alex-weej> tjaalton: and neither do we if we just start building whitelists of models for this kind of thing.
<kees> is vte's rendering engine single-threaded, or something?  when having text pooring past my screen in one terminal, other terminals are laggy.
<ion_> All gnome-terminals are a single process IIRC, and it might very well not be multithreaded.
<Treenaks> gnome-terminal --disable-factory
<Treenaks> takes a bit more memory, but speeds them up nicely for me
<Treenaks> also, a bug in gnome-terminal doesn't kill all my terminals at once
<tjaalton> alex-weej: btw, my nick seems to be correct on lp :)
<alex-weej> tjaalton: odd. for some reason i only say tepsipakki before. not sure what i was looking at.
<alex-weej> *only saw
<ogra> tjaalton, input devices usualy have a cpability set in hal, just look for that one, synaptcs devicdes usually have input.touchpad
<ogra> *capability
<tjaalton> ogra: so the fdi-file could append a setting that matches that capability
<ogra> why an fdi file ?
<ogra> fdi files are usually needed to fix kernel bugs only
<ogra> if the kernel doesnt set that capability, fix the kernel :)
<ogra> the hal-input module should handle it properly, if it doesnt fix the cause and dont work around it :)
<ogra> fdi files are a last resort :)
<tjaalton> ogra: er, they are needed to get input-hotplug working
<ogra> oh ? who designed that ?
 * ogra cant imagine upstream likes that
<tjaalton> daniels et al I guess :)
<tjaalton> ie. upstream
<ogra> woah
<ogra> well, then be it ... i wont argue with daniels about input stuff :)
<kirkland> slangasek: hi, you around?
<slangasek> kirkland: hiya
<kirkland> slangasek: I'd like to run an email to debian-devel by you that I'm drafting, regarding 'status' in the init scripts
<kirkland> slangasek: mdz pointed me to you, as a good person to vet this by
<slangasek> ok
<kirkland> slangasek: i'll send it your way once I get it cleaned up a bit
<kirkland> slangasek: I'm curious if you've grown any more comfortable with those patches as they stand for samba in Debian?
<slangasek> kirkland: I don't think there's a "comfort" question now, just one of reviewing the multiple proposals and getting it committed
<slangasek> it's been all pam/openldap for me the past week and a half, no time to squeeze in samba work :)
<kirkland> slangasek: ogey doke ;-)
<emgent> slangasek: when you have time can you accept rapache backport for hardy? Bug #252777
<ubottu> Launchpad bug 252777 in hardy-backports "Please backport rapache 0.6-0ubuntu1 from Intrepid to Hardy" [Wishlist,In progress] https://launchpad.net/bugs/252777
<infinity> kirkland: Why do this:
<slangasek> emgent: "when I have time", yes, but pitti has his archive day tomorrow, and that's probably before I have time
<infinity> +		pidofproc -p $SMBDPID $DAEMON >/dev/null
<infinity> +		status=$?
<emgent> ok Thanks slangasek
<infinity> kirkland: If you did it with "if pidofproc -p $SMBDPID $DAEMON >/dev/null; then", it would work for a "set -e" script too.
<kirkland> infinity: b/c pidofproc doesn't do the log_success_msg() and log_failure_msg()
<slangasek> infinity: well, we know that the smbd script isn't set -e
<infinity> slangasek: Yeah, but I assume he has boilerplate here.
<infinity> (And I write set -e init scripts)
<infinity> kirkland: No, no.  "if pidofproc foo; then log_msg; else log_msg; fi"
<slangasek> infinity: true LSB init scripts aren't allowed to be set -e \o/
<infinity> kirkland: Has the same effect as testing if status is "0", which is the very next thing you do. :)
<kirkland> infinity: please point me to what you're looking at specifically
<infinity> slangasek: Seriously?  All my shell is set -e, usually.  To protect myself from bad coding, more than anything.
<infinity> kirkland: http://patches.ubuntu.com/s/samba/samba_2:3.2.0-4ubuntu1.patch, the init script part of the patch.
<slangasek> infinity: the LSB init script spec is full of win; it explicitly prohibits use of set -e with the /lib/lsb/init-functions
<slangasek> (I've tried sneering at the LSB maintainers in Debian until they provided an implementation that *is* safe under -e, but it's possible this has not been a wholly successful strategy)
<kirkland> infinity: that patch is out of date
<kirkland> infinity: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087
<infinity> kirkland: Though you would lose the return of pidofproc that way, which I suppose you want.
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,Triaged]
<kirkland> infinity: this is the latest revision: http://launchpadlibrarian.net/16367257/samba.247087.debdiff
<infinity> kirkland: Ahh, I see you fixed it with || status=$? ... That resolves my whine. :)
<kirkland> infinity: ;-)  wanna sponsor that upload then?  :-P
<infinity> slangasek: I suspect I don't actually have to tell you how I feel about that.  Meh.
<infinity> slangasek: I mean, I can see the argument that init scripts aren't always the ideal place to use set -e, but I want the option available, should I be the sort of pedant who prefers to be strict.
<infinity> kirkland: Yeah, I might be able to be convinced to do that.
<infinity> kirkland: I do have a mushroom next to my name in LP, after all.
<kirkland> infinity: ;-)  well, it's been hanging around in the sponsor queue for a couple of weeks now
<kirkland> infinity: everytime i think of it, it seems like the archive is frozen for alpha-spinning ;-)
<infinity> kirkland: I never check those things anymore, since I'm not technically on distro... But I'm happy to sponsor things that look "obviously correct" to me.
<infinity> kirkland: And this (for pedants like me) is an obvious improvement. :)
<kirkland> infinity: woohoo!
 * infinity sets vorlon's init script to -e while he's in there and watches it asplode.
<kirkland> infinity: i was beginning to wonder if I was the *only* person who sees value in 'status' actions in init scripts in the Ubuntu community
<infinity> kirkland: I don't care one way or the other, but it's already THERE in samba, and your new patch is better, IMO.
<kirkland> infinity: oh, i see your view now
<kirkland> infinity: yes, clearly better than before
<kirkland> infinity: which was better than nothing ;-)
<slangasek> infinity: well, I was happily using set -e in all my init scripts before the LSB helpers came into vogue; then it became prohibitive
<kirkland> *slangasek is easily kirkland's favorite LSB-hater
<slangasek> heh
<slangasek> I don't hate the LSB, just the parts of it that didn't come from Debian policy
<slangasek> ;-)
<Nafallo> haha
<infinity> I always disliked the "pretty init scripts for the sake of prettiness" thing, though you'll find my name in a LOT of changelogs in Ubuntu adding such prettiness, since it was part of my job.
<infinity> But when that prettiness comes at the cost of error checking, I'm even grumpier.
<slangasek> my favorite LSBism is still the part where they tried to grandfather all known init scripts on all Linux distributions, and then declare the rest of the init script namespace reserved for LSB
<infinity> Also, people who require cdbs, dbs, quilt, etc in clean targets need to die.
 * infinity glares at slangasek.
 * Mithrandir ruffles the angry man
<infinity> (peloy's fault?)
<slangasek> infinity: feel free to rebuild it as a v2.0-quilt package instead ;)
<infinity> kirkland: Uploaded.
<slangasek> infinity: if you're using a patch system, it needs to be used in the clean target; I'm not going to duplicate quilt logic in the debian/rules themselves
<kirkland> infinity: many thanks
<infinity> slangasek: I know.  I'm still a slave to the "ZOMG, simple" patch system we used in PHP, even if it wasn't perfect.
<slangasek> yeah, I think that was the one that drove me into quilt's open arms
<slangasek> :)
<infinity> slangasek: And, actually, that's not entirely true.  If you use the brute-force "create a build-tree, then patch it" method, clean can just be "rm -rf build-tree".
<slangasek> well, perhaps
<infinity> The only real problem PHP's system had was it's lack of forgiveness for fuzziness... Which I actually came to appreciate, because it forced me to re-evaluate patches on new upstream releases and make sure they were still useful.
<slangasek> the other problem it had was that it didn't have quilt push -f && quilt edit && quilt refresh
<infinity> (And I got insanely good at hand-editing diffs...)
<TheMuso> kees: No. Usplash runs on tty8, all messages echoed to the console are on tty1. When you boot without splash, you are on tty1 anyway, so unless a change to tty1 is made when usplash quits, only the initramfs prompt will be seen, and you have to switch to tty1 to see any errors you get, and then have to switch back to tty8 just to type commands.
<kees> TheMuso: heh, okay.  so the messages echo'd by the fail hooks will still be visible?
<TheMuso> kees: If one ends up panicking, yes, but if things boot, the need for showing them is not necessary I guess, unless you want to show them within usplash.
<kees> nah, no need for it to show up in usplash.
<TheMuso> As in letting the user know that an array is degraded, even if they use that command-line argument kirkland added.
<kees> mdadm will yell at them after they're booted
<TheMuso> kees: Yeah I thought as much.
#ubuntu-devel 2008-08-01
<slangasek> kees: is bug #190329 completely resolved on the kernel side?  It's been marked 'confirmed' on ntfs-3g, but I don't see anything to suggest it still needs an upload
<ubottu> Launchpad bug 190329 in ntfs-3g "DAC permissions not correctly enforced" [Undecided,Confirmed] https://launchpad.net/bugs/190329
<kees> slangasek: I was wondering about that too -- afaiu, it was just a kernel-side issue.
<slangasek> ok, marking as 'invalid'
<IntuitiveNipple> I've got a problem when using pdebuild for i386 on an amd64 host, building kvm (testing prior to PPA upload). In kvm, qemu/configure does a big/little-endian test and as part of that causes /usr/include/gnu/stubs.h to be referenced. That in turn tries to include gnu/stubs-64.h. But since this is building in an i386 environment, libc6-dev doesn't include /usr/include/gnu/stubs-64.h. Is there a solution?
<ion_> benc: Btw, anything i could help with to move last-good-boot forward?
<BenC> ion_: The only bit left is to check over cking's grub changes to detect a failed boot and default to last-good-boot
<ion_> Where are those changes?
<BenC> ion_: in my inbox :)
<BenC> ion_: want to test them out?
<ion_> benc: Sure
<BenC> ion_: what's a good addy to send to?
<BenC> ion_: sent
<ion_> Thanks
<lifeless> james_w: http://www.gnome.org/~federico/news-2008-07.html#30
<superm1> BenC, do you have some sort of notification flag that gets set to let the user know about the failed previous boot once it comes back up too though?
<[Relic]> any updates on when the proper coretemp.c file and new lm-sensors will be added to the kernel for 45nm support?
<BenC> superm1: that's the whole point of the grub changes :)
<superm1> BenC, ah :)
<BenC> superm1: it will stop at the boot prompt and tell them the last boot failed and default to last-good-boot being selected
<BenC> superm1: I've been looking into a desktop notification to say "You are booted into the last successfully booted system" (which is independent of it actually failing)
<BenC> just a general notice so people know where they are
<superm1> BenC, yeah that's what i'm sorta thinking here
<superm1> it should be a matter of dropping a file in place, and the notification-daemon detects it and shows you
<BenC> right, should be easy in the last-good-boot event.d script, I just haven't come up with good verbage for it
<superm1> BenC, i want to say i've seen some warnings showing up in the init script when i turn off the splash, about a hard link already existing
<superm1> perhaps you want to 2>/dev/null those?
<BenC> superm1: actually, that was a real bug...if you update grub, it should go away
<superm1> BenC, ah okay
<BenC> superm1: old script wasn't removed, so it was being run twice (in parallel)
<superm1> my mirror is usually about a day behind, so i'll see any newer grub updates soonish
<dholbach> good morning
<gaurdro> g'morgen
<dholbach> hi gaurdro
<gaurdro> hello dholbach
<lifeless> hi dholbach
<lifeless> dholbach: I was going to suggest you consider structuring your 5-a-day stats so that bzr-search can be useful for you ;P
<dholbach> hi lifeless
<dholbach> lifeless: hm? what do you mean?
<lifeless> well, when I looked at the stats stuff
<lifeless> it seemed to me a lot of the guts of it was simply counting how often stuff turns up
<lifeless> hmm, I had this thought the day after you went on leave
<lifeless> I'm trying to page it in :)
<pitti> Good morning
<Hobbsee> pitti!
 * Hobbsee throws pitti some gummy bears in greeting
<pitti> yummy! /me tosses back some cookies
 * Mithrandir steals them all
<pitti> Mithrandir: so you ate the ones with moustache and pepperoni as well?
<pitti> erm, mustard
<Mithrandir> yup
<pwnguin> moustache is probably worse
<Mithrandir> actually, no
<Mithrandir> I just stole them.
<ion_> Moustache cookies â¥
<pitti> I guess I just invented a new ad video :)
 * Hobbsee looks at pitti strangely
<Hobbsee> and weather applet, you lie!
<lifeless> argh updates to conf files argh
 * lifeless hates
<lifeless> lol
<lifeless> fail:
<lifeless> Searching for GRUB installation directory ...
<lifeless> No GRUB directory found. To create a template run 'mkdir /boot/grub' first. To install grub, install it manually or try the 'grub-install' command. ### Warning, grub-install is used to change your MBR. ###
<pitti> doko: yippie, we can sync tzdata, Aurelien applied the -java patch (slightly differently, but it's ok)
<fabbione> morning guys
<fabbione> doko: ping?
<pitti> hey fabbione!
<fabbione> hey pitti
<fabbione> how is life?
<pitti> fabbione: warm :)
<pitti> and pretty good, we started to learn diving yesterday
<fabbione> pitti: yeah it's warm here too....
<fabbione> we are melting
<pitti> BenC, cjwatson: hm, it just occurred to me that we can just as well remove the linux meta packages which are NBS; they are uninstallable anyway (pointing to hardy kernel still)
<BenC> pitti: anything that isn't built by linux-meta anymore can be deleted
<pitti> BenC: right, doing so ATM
<pitti> BenC: but I guess eventually we'll need at least some of them back/
<BenC> pitti: it will get replaced by linux-ports-meta src pkg
<pitti> like the default linux for the ports?
<pitti> ah
<pitti> BenC: and the unsupported flavors? like openvz and rt?
<pitti> Riddell: kde4bindings source is in main, but most of its binaries are in universe; also, I thought that we're moving away from kde4*? (it is in binary NEW)
<BenC> pitti: those will get provided by other packages, if community ends up creating them
<tkamppeter> Anyone here who packages bluez-libs or bluez-utils
<dholbach> tkamppeter: you could try #ubuntu-mobile
<tkamppeter> <dholbach>
<tkamppeter> dholbach, thanks for the hint, but neither there nor here someone answers. Seems that no one really cares about Bluetooth.
<ion_> Feel free to donate cool bluetooth hardware to me, i'll become interested. :-)
<dholbach> tkamppeter: it might help if you ask the question you have
<tkamppeter> ion_, fix bug 206579 and I try to organize a Bluetooth printer for you.
<ubottu> Launchpad bug 206579 in bluez-utils "Bluetooth CUPS backend takes very long time on device discovery" [Critical,New] https://launchpad.net/bugs/206579
<liw> it's often hard to fix a bug that depends on some hardware without access to that hardware; someone donating or lending the hardware would be a great boon to such bug fixing, I'm sure
<persia> tkamppeter: I'm not sure I understand.  Does it only take a long time when you don't activate bluetooth on your printer?
 * pitti cuts a huge dent into the NBS list, but it's still alarmingly huge
<StevenK> ichthux-desktop
<StevenK> Sigh
<StevenK> ichthux-desktop is still the cause of a bunch of it
<tkamppeter> persia, if a Bluetooth printer is there, all is fine. The backend finds the printer and finishes within 10 seconds. Problem is only if there is no Bluetooth printer. then it never exits.
<pitti> StevenK: I killed all of those
<tkamppeter> According to the bug it is hanging somehow on DBUS communication.
<persia> That ought be easier then.  The bug depends on the *absence* of certain hardware :)
<tkamppeter> So fixing the bug must be possible without the hardware.
<pitti> well, it's still helpful to test if your fix still works with the hardware, of course, but debugging should be easier, yes
<tkamppeter> While testing make sure that the Bluetooth of your cell phone is turned off, as some cell phones get detected as printer.
<persia> Wait, does this only happen when there is *no* local bluetooth environment?
 * persia can usually detect >15 bluetooth devices due to population density
<pitti> it can usually be turned off in the BIOS, or just with rmmod
<tkamppeter> persia, yes, the bug only occurs if NO Bluetooth devices are present.
<StevenK> I wonder if someone better versed with Bluetooth could look at bug 211252
<ubottu> Launchpad bug 211252 in obex-data-server "Cannot recieve files using bluetooth" [Undecided,Confirmed] https://launchpad.net/bugs/211252
<tkamppeter> persia, a local Bluetooth environment is there, What is needed for the bug to occur is that there is no Bluetooth device. A Bluetooth printer must be turned off.
<persia> tkamppeter: I'll try, but I can't control my neighbours :)
<tkamppeter> persia, simply run the bluetooth backend with "time sudo /usr/lib/cups/backend/bluetooth" and see what happens.
<pitti> hello sabdfl
<sabdfl> howdy
<pitti> Riddell: there is a digikam-kde4 in source NEW; do we really still want packages with -kde4?
<persia> tkamppeter: I get 10 seconds on hardy.  What should I check to see if there was an undesired detection?
<tkamppeter> persia, do you have any output?
<persia> tkamppeter: Only the time report.
<persia> Running without time gets no output.
<tkamppeter> persia, is there a tool with which I can see whether there are really no Bluetooth devices present here?
<liw> "hcitool scan" should do that
 * persia is finding a MAC and a phone
<tkamppeter> liw: till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$ hcitool scan
<tkamppeter> Scanning ...
<tkamppeter> Inquiry failed: Device or resource busy
<tkamppeter> till@till-laptop:~/gutenprint/cvs/HEAD/print/src/cups$
<liw> I think that means your bluetooth stack is not fully working
<liw> or something else is using it or something
<tkamppeter> persia, also with the Bluetooth on my cell phone turned on, the bluetooth backend does not exit.
<persia> tkamppeter: Well, I can't replicate that.  I've no bluetooth printers detected, and at least two bluetooth devices I cannot disable within range.  It takes 10 seconds.
<Riddell> pitti: yes, in this case it's still beta and upstream don't want us to remove the kde 3 version yet (same as amarok), so universe for it
<pitti> Riddell: alrighty
<tkamppeter> Riddell, the kde3 version is not installable.
<Riddell> tkamppeter: yes, it's somewhere on my todo to fix that
<tkamppeter> persia, I have rebooted my Intrepid box now and still cannot scan the Bluetooth:
<tkamppeter> till@till-laptop:~$ sudo hcitool scan
<tkamppeter> [sudo] password for till:
<tkamppeter> Scanning ...
<tkamppeter> Inquiry failed: Device or resource busy
<tkamppeter> till@till-laptop:~$
<tkamppeter> I hope this is not a DoS from a neighbor ...
<persia> tkamppeter: Are you sure your bluetooth device works?
<tkamppeter> persia, I have already used a Bluetooth mouse and also Bluetooth printers with this laptop.
<persia> tkamppeter: Hmm.  I'm not sure then.  I thought "Device or resource busy" meant that there was some issue accessing a local device, rather than a remote device.
<mdz> am I the only one getting nightly errors from checksecurity on intrepid?
<persia> StevenK: I can't replicate that with hardy.
<mdz> sort: fflush failed: standard output: Broken pipe
<pitti> Riddell: can you please have a look at the "source/binary demotion" part of http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, the KDE stuff? (k*)
<pitti> Riddell: kdeaddons, kdebluetooth, etc. are really obsolete?
<seb128> doko: hey, I've some python packaging issue, maybe you can help ;-) pygobject not has a /usr/lib/libpyglib.so and I don't how to handle that since it's build against one python version only, one way would be to build pygobject and pygtk for one python version only...
<tkamppeter> persia, I have turned on two Bluetooth printers and the backend found them in 20 seconds, then I have turned them off and the backend still found them in 55 sec
<Riddell> pitti: kdeaddons is
<Riddell> pitti: kdebluetooth I'm not sure, kdebluetooth4 is ment to be being packaged today by tonio so I guess it'll get updated
<tkamppeter> persia, only on Intrepid, on Hardy the backend returned to hanging infinitely.
<persia> tkamppeter: I only tested in hardy.  Still 10 second return, other devices present, no bluetooth printer.
<Riddell> pitti: keep kipi-plugins, konq-plugins, libkdcraw, libkexiv2, libkipi, webkitkde. I'll add them to seeds  other kde bits can be demoted
<pitti> Riddell: ok, that list plus bluetooth?
<pitti> Riddell: thanks
<Riddell> pitti: yes
<tkamppeter> persia, for me it hangs on two laptops
<pitti> soren: seems qemu again started to b-dep on gcc-3.4; merge error?
<pitti> Riddell: erm, did you mean to keep "keep", or not?
<pitti> i. e. was the first word in your sentence a verb or package name?
<Riddell> pitti: do not keep "keep"
<pitti> ok :)
<soren> pitti: qemu had b-d'ed on gcc-3.4 all along.
<soren> pitti: kvm... not so much.
<pitti> ah, right
<persia> tkamppeter: I'm guessing it's either device-specific or related to some configuration, as I'd not done any bluetooth things on this machine between install and this test.
<pitti> soren: ah, I see now; libvirt0 recommends: qemu and thus qemu wants to go into main, together with its (b)deps
<pitti> -> suggests:?
<soren> Quite. I'll make a note of it and see to it when I'm back on Monday.
<pitti> soren: thanks
<pitti> soren: I can file a bug for you if that helps
<soren> pitti: That would be good, thanks.
 * soren climbs back under his rock
<pitti> soren: done, bug 253900; enjoy your holiday!
<ubottu> Launchpad bug 253900 in libvirt "drop qemu recommends: to suggests:" [Undecided,New] https://launchpad.net/bugs/253900
<pitti> seb128: rb's recommends: gst-plugins-ugly will pull -ugly, a52dec, and other stuff into main; do you think dropping to suggests: is appropriate? I'd think so, given easy-codec-install
<seb128> pitti: hum, probably yes, will change that when I do the next upload
<pitti> seb128: WDYT about the same problem with python-{coherence,louie}? MIR or drop?
<pitti> seb128: oh, I can do the upload, just asking for your opinion
<seb128> do we really need to break recommends or promote those?
<seb128> I though recommends in universe were handled correctly if universe is not activated
<pitti> component-mismatches is horribly big, we need to cut it down to some sanity, otherwise we'll drag it forever; I'm happy to do some uploads
<seb128> pitti: well I just uploaded a svn snapshot so make sure to get this one and to verify that the current upload built first ;-)
<persia> seb128: main should be recommends-complete.  Not doing that means all sorts of confusion about what is installed.
<pitti> seb128: but we install it by default, and we install recommends by default
<pitti> so either the recommends is worthless (because apt will not auto-install missing ones), or we should really install it
<pitti> seb128: right, I saw that
<seb128> pitti: well, python-coherence is useful but it'll not fit on the CD
<seb128> that's required to have upnp working
<seb128> and that will not easycodec install
<pitti> right
<pitti> seems we need some similar magic for plugged in hardware
<seb128> I don't like to demote it to a suggests much :--
<seb128> :-(
<pitti> (well, jockey is on the way to become this magic, but it's not there yet)
<seb128> pitti: that's not hardware, that's network devices
<pitti> seb128: the question is not so much r: or s:, but rather whether we want to install it by default
<seb128> want yes, can is an another question
<pitti> if we don't install it by default, the recommends: won't help anyone
<seb128> I think I looked at it before hardy
<seb128> installing python-coherence is an extra 11meg
<seb128> the one CD limitation is starting being really though :-(
<seb128> $ sudo apt-get install python-coherence
<seb128> After this operation, 5370kB of additional disk space will be used.
<seb128> on my intrepid
<seb128> and that's not a stock install so I might have some extra things already installed
<cjwatson> pitti: NBS kernel metapackages> I'd been deliberately leaving them there so that we could see what needed to be replaced
<pitti> seb128: python-louie is trivial and tiny, though; not sure what it does in RB, but that can easily be added
<cjwatson> pitti: otherwise we'll have upgrade problems
<seb128> pitti: no, rhythmbox requires python-coherence to get that working, python-louie will not bring anything
<seb128> pitti: debian bug #474733
<ubottu> Debian bug 474733 in rhythmbox "rhythmbox: Please suggest python-coherence instead of python-louie" [Normal,Closed] http://bugs.debian.org/474733
<seb128> pitti: well, I guess demote python-coherence to a suggest and remove python-louie if you want to change something
<seb128> I don't think we can afford that on the CD
<pitti> seb128: right, will do; thanks
<seb128> thanks
<seb128> did we discuss a way to have "recommends which don't fit on the CD but that people might want to install if they have internet access after the installation"?
<fabbione> BenC: right now you would be the proudest father on this planet if you had my son.. he learned to say "burger" and goes around asking for it all the time :)
<fabbione> doko: unping.. problem solved
<pitti> cjwatson: I filed bug 253904 about it, FYI
<ubottu> Launchpad bug 253904 in linux-meta "does not build a lot of metapackages any more" [High,Triaged] https://launchpad.net/bugs/253904
<doko> fabbione: fine =)
<pitti> fabbione: lol; not "spaghetti"?
<seb128> oh doko is there
<pitti> doko: run!
<seb128> doko: did you read my question before?
<fabbione> pitti: pizza was his first food related word... even before "Daddy"
 * doko ducks and runs
<fabbione> pitti: pasta come in later.. no spaghetti yet.. too long ;)
<pitti> fabbione: "noodles" then
<fabbione> pitti: will try :)
<seb128> pitti: oh, http://bugzilla.gnome.org/show_bug.cgi?id=545828
<ubottu> Gnome bug 545828 in plugins "Add apport monitoring" [Enhancement,Unconfirmed]
<pitti> seb128: rb built everywhere, FYI; grabbing and uploading
<seb128> mvo: ^ did you know about that?
<seb128> pitti: excellent ;-)
<doko> seb128: hmm, no, looks like we have to patch to build two versions (like we do e.g. for subversion-svn)
<seb128> doko: "2 versions"? then we will have to patch other bindings to use the versionning correctly or something?
<pitti> seb128: niice! looks very similat to what we have in update-notifier
<doko> yes, but building just for one version will get us into upgrade hell ...
<seb128> doko: do you think you would have some time to look at it? I'm not sure to get what changes are required there, I can hand you the current source package, build breaks because python2.4 and python2.5 builds have this same lib
<mvo> seb128: no
<doko> sure, can have a look.
<mvo> soren: I get really bad network thorughput with the current kvm in intrepid, do you have any idea about this? its currently in the range of 20kb/s from my local proxy, this used to be more like 2000kb/s or more
<mvo> soren: do you have any idea about this or got similar reports?
<pitti> mvo: do we need apt-xapian-index in main/on the CD, or can we drop the synaptics recommends: to it?
<mvo> soren: could be a local misconfiguraiton of course, but I would like to hear your opinion
<mvo> pitti: we don't need it, it would be nice to have it though
<seb128> doko: http://people.ubuntu.com/~seb128/pygobject/
<pitti> mvo: 'nice to have' sounds like suggests:, not recommends: :)
<pitti> don't get me wrong, I don't really like the new strongness of recommends: in the first place, but now that we have it, we need to be consistent
<mvo> pitti: well, its not essential, if available it provides very fast search in the package descriptions (search as you type) with ranking and goodies like this. however if it is not there, then the old search will still work (also that is much slower and does not provide ranking)
<pitti> I always have the feeling that recommends: is now exactly like depends:, and suggests: is the new recommends:, and the old suggets: was dropped now
<mvo> pitti: so in summary I think we should have the xapian-index if possible (and CD space allows it)
<pitti> mvo: answer to 'CD space allows it' is generally "no", I'm afraid
<seb128> I'm wondering if this "install recommends by default" makes sense if that just means demote most of the recommends to suggest
<pitti> seb128: exactly my thought; it basically seesm that Debian wanted to get rid of recommends entirely
<pitti> there might be a perfectly reasonable rationale behind it, I'm just not aware of it ATM
<mvo> pitti: the extra space is in the range of ~1mb
<mvo> pitti: its a perfect use-case for recommends, it should be installed (apt-xapaina-index) but it can work without
<seb128> mvo: we have lot of things which "should be installed" but the one CD limitation is though ...
<mvo> pitti: where is that discussed (that debian wants to get rid of them entirely)?
<mvo> seb128: I'm fine with that, I will add code that cehcks for it and offers to install it in the ui if it is missing. I'm just explaining that I think its the perfect example for a "recommends" IMO
<Sikon> pitti> Thanks for moving batik out of multiverse
<Sikon> fop can follow suit now, should I file a bug for it?
<seb128> mvo: right, but since we had not space on the CD before installing recommends by default I'm wondering if installing recommends by default makes sense
<seb128> mvo: it basically means we need to drop all the recommends for packages on the CD
<pitti> mvo: I don't know; but that's how it feels
<pitti> Sikon: same rationale? I can just do it
<mvo> well, we could do the CD install without recommends and have something in synaptic telling people about packages they might want to install (all the missing recommends basicly)
<Sikon> yes, same rationale - its only multiverse dependency was batik and now it's been moved
<seb128> mvo: right, that's what I asked before, <seb128> did we discuss a way to have "recommends which don't fit on the CD but that people might want to install if they have internet access after the installation"?
<mvo> I don't have strong feelings about recommends in general, if debian would decides that they are not useful and we should only have "depends" and "suggests" I would not mind, it just needs to be consistent and in the policy
<mvo> seb128: oh, I missed that
<seb128> they are useful
<seb128> and the idea rocks
<seb128> it just doesn't fit on the CD
<mvo> seb128: I don#'t think we dicussed that, I think that is a nice idea. we could offer something similar to the langpacks, a option to install the missing bits
<mvo> seb128: and have a mode  in synaptic (or somewhere else) that tells about the missing ones
<seb128> that would be cool
<mvo> I think especially the bits in the installer (getting the list of not-installed recommends) is really straightforward
<pitti> Sikon: moved, thanks
<pitti> they'd still need to be in main, thuogh
<pitti> we shouldn't in good faith Recommend: a package in universe
<pitti> that would be saying "we want it, but then we don't"
 * mvo agrees
<pitti> and the "do the post-install huge recommends: install" is both confusing and also user-unfriendly as well
<pitti> then we should be straight and rather offer a bigger install media as an alternative, such as the discussed 1 GB USB stick image, or the DVD
<seb128> pitti: well, how do you solve things like the xapian index should be installed, or python-coherence so upnp is working?
<mvo> pitti: you think so? if it is offered similar to the langpack install in ubiquity? I guess it depends on how big it is
<mvo> but it sounds not too bad to me (moving to a bigger media is of course even better :)
<pitti> seb128: my opinion is still that a bigger alternative install media is better than to inflict a 300 MB download right after installation
<seb128> right, my opinion too
<persia> Maybe a 1GB USB stick?
<seb128> but previous times we had this discussion you were opposed to anything bigger than 1 CD
<pitti> that's worse than downloading those extra 300 MB beforehand with the install media
<seb128> persia: yeah, that's what Scott suggested too already
<pitti> seb128: oh, I still love the idea of having a CD
<pitti> seb128: but I never opposed to us offering a DVD
<pitti> *alternate* media :)
<mvo> I'm not sure if its that much of a issue, especially since we force a huge download on people anyway for the secuirty updates etc after the install. it depends on the size, if its 300mb that is a bit much of course, if its  30mb I think that is not too bad
<seb128> I love it too, but not if it means that the installed product start degrading because we don't have space to put what we need
<pitti> the ubuntu-bells-and-whistles 2 GB images, if you can afford the download
<pitti> I'm just opposed to dropping the CD entirely, for two reasons: first, it would encourage us to add bloat without ever cleaning up, and second, with every added 100 MB we'll lose a lot of users who cannot download it any more
<persia> Also, CDs are cheap to hard out to random folk.
<persia> s/hard/hand/
<seb128> right, I'm not suggesting *dropping* the CD
<Mithrandir> persia: I don't see a price difference between CD and DVD media here.
<pitti> e. g. xapian index is exactly the case how it should not be
<seb128> but maybe 1 CD installs should not be the recommended media for desktop installs
<persia> Mithrandir: Really?  We still have one here: about the same price for 50 CDs as 20 DVDs (not that it's much, really)
<seb128> if we think we are degrading the user experience due to the CD space limitation
<pitti> if it works well, and we support it, then we shouldn't have two different apt backends, but just use xapian and nothing else
<pitti> Mithrandir: the download size difference matters a lot, though
<seb128> pitti: that's not only xapian index, that's upnp not working in rhythmbox for example
<pitti> right
<Mithrandir> persia: well, it's 59 NOK vs 71 NOK for 25 CDs/DVDs, but then the CDs are noname and the DVDs are Verbatim.
<mvo> pitti: I don't understand, how is that "how it should *not* be" ? I could just make a depends and claim that this is now the way to do it (for good reaosns). but instead I decided to provide the added flexbilibty for people with small systems that don't want the extra diskspace. in what way is that bad?
<pitti> seb128: that's why I'm so opposed to webkit, for example
<Mithrandir> pitti: sure, just saying that I don't think price of media is much of a factor here at least.
<pitti> seb128: because webkit doesn't give the user *any* benefit ATM, it just takes CD space
<seb128> pitti: well, that's not up to us though
<pitti> I know that this isn't exactly our fault
<pitti> it's an upstream decision
<pitti> but from the user's POV that doesn't matter
<seb128> and it makes sense for them
<seb128> that's an orthogonal issue anyway
<pitti> it's not for the topic of what we use our precious CD space for, IMHO
<seb128> there is no "we" there since we don't lead upstream work and have no say in their decisions
<seb128> we have no real choice there, either we ship what they do or we fork the code and maintain it
<pitti> well, in cases where all the distros say "no", they'd reconsider for sure
<seb128> not sure
<pitti> but of course if the other distros don't care about how many GBs they dump on the user, we are left alone :(
<seb128> and all distros will not say no
<seb128> well, that's not a matter of how many gbs
<seb128> GNOME use only only webkit
<seb128> we are the one who decided to ship firefox and not epiphany-browser
<pitti> (but there might be a correlation why millions of people download Ubuntu CDs, and magnitudes fewer download SuSE DVDs)
<seb128> -only
<pitti> seb128: hm, that's a good point actually
<sladen> pitti: ...being left alone is a *unique selling point*
<pitti> seb128: replacing ffox by epy by default is something that we could do
<davmor2> pitti: I wouldn't do it yet there are som major flaws at the moment still :(
<seb128> right, but we will not likely due because firefox is known, etc and users will want to use it
<sladen> but "mindshare" means that it would not be wise
<mvo> plugins is another common reason cited for using ff
<sladen> Ubuntu got noticed and used for shipping sane defaults that roughly aligned to what a sizable majority "just wanted".  1 CD, with Firefox, with OpenOffice, with bling and with nekkid people
<persia> A number of plugins work with epiphany-browser in hardy.  Does that go away with webkit?
<pitti> persia: I'd think so
<seb128> well, webkit is not there yet
<persia> pitti: That would be a bug.  I'm an epiphany user, but appreciate the current featureset.
<seb128> but it's getting there so maybe next cycle
<pitti> persia: which brings me back to GNOME prematurely dropping xul support :)
<persia> heh
<seb128> persia: they still didn't make epiphany-webkit the default, they expect that to be ready for GNOME 2.26 (intrepid+1)
<seb128> pitti: they didn't drop it for epiphany-browser actually
<davmor2> seb128: even if webkit is epiphany isn't using it to it's greatest advantage yet :(
<pitti> seb128: ah, *phew* :)
<seb128> but webkit is good for desktop applications
<persia> seb128: So epiphany will ship both epiphany-webkit and epiphany-gecko?
<seb128> persia: it does in intrepid yes
<pitti> seb128: what happens to gtkhtml, BTW? we still ship that as well
<seb128> pitti: going to be remplaced by webkit too
<pitti> good
<persia> So webkit doesn't need to be on the CDs for intrepid?
<seb128> persia: yelp will likely use it but we can hold back to the current version if we want to
<persia> Let's do that.  WIth such a plan we can delay the webkit discussion until upstream has caught up with itself.
<seb128> they dropped over 1000 lines of code when switching to webkit, improved the start time and got some thing working which were broken when using gecko
<pitti> mvo: my feeling is just that we keep accumulating three different alternatives/libraries/programs to do a job; once, Ubuntu's strong point was to select the best and use just that
<pitti> mvo: unfortunately we seldomly have the power to decide that for the entire distro, sure
<pitti> but we should still strive to do that
<seb128> pitti: again that's an orthogonal issue, we should still be careful on having a clean set of packages and no duplication, etc
<pitti> mvo: so in terms of apt, if xapian is the way to go, then let's use it, and use *just* it
<seb128> pitti: but that doesn't mean we will make all the feature we need to fit on one CD
<pitti> otherwise we have to test and support systems with both alternatives, which doesn't make things easier
<pitti> seb128: sure, that's true, but we shuold at least consistently aim for throwing out redundancy, so that we don't waste space
<pitti> and wasting space is all too easy if your install media is unlimited
<seb128> right, agreed
<pitti> I'm regularly amazed how big a Windows installation is, and I wouldn't like to install a complete DVD from SuSE to take some 10, 15 GB
<pitti> so, I agree that a CD limit is probably too tight for a really good desktop experience, but a DVD is too big IMHO
<pitti> and I'm just afraid that it'd cost us a *lot* of users to just have DVDs
<Ng> pitti: I re-installed the vista image from my new laptop recently and it refused to work with less than a 15-20GB partition
<sladen> first boot of this laptop (the auto vista install) took 1.5hours.  The Ubuntu install took 11minutes
<Ng> I figured that 20gb was a bit much to update my phone firmware, and gave up ;)
<persia> sladen: Just boot first with the livecd.  Saves time.
<sladen> and the Ubuntu install did more out of the box...
<sladen> persia: cough.  lack of CD drive
<sladen> persia: so I wubi'ed it with the lack of anything else to hand to netboot
<Ng> (although XP fits fine in 2GB, it has to be said)
<pitti> someone (Keybuk?) raised the idea of an 1 GB usb stick image
<pitti> I actually quite like that
<sladen> a stick image of $size is really a must; the current instructions for how to convert an ISO to a stick image are too convoluted
<seb128> pitti: yes, that was Scott
<persia> ubuntu-mobile currently installs off a 500MB USB stick image.  Mind you, -desktop needs more space, but it's not that much different than CDs.
<pitti> sladen: full ack
<seb128> pitti: I would like at least get a media where we don't need to cut too much and where we could have translations installed
<seb128> pitti: 1Gb keys would be nice indeed
<persia> There's also a work-in-progress wizard to put a USB image onto the stick, which ought make intrepid.
<pitti> persia: yep, ogra uploaded it a week or two ago
<persia> pitti: Yep.  Should come back to you next week.
<joaopinto> Hello, any archive admin available for a licensing question ?
<pitti> joaopinto: just ask the question, please
<joaopinto> I am packaging game, the source code is distributed under GPL, the artwork is distributed "Free Art License"
<mvo> pitti: ok, thanks for explaining that to me. I will make apt-xapian-index a depends then in ubuntu. xapian is the way to go for the frontends, it will just not be part of the stock apt (apt-cache). but I think every frontend should use it (the packagekit apt backend is using it too)
<pitti> mvo: well, "explain" -> that's just my feeling
<pwnguin> joaopinto: the guidelines we use are often called "DFSG"
 * pitti apologizes for being in such an argumentative mood today and hugs seb128 and mvo
 * seb128 hugs pitti, nothing to apologize about, that's a good discussion to have
<pitti> mvo: why not for apt-cache then? wouldn't that still mean to have two backends to care about?
<pitti> mvo: e. g. the normal apt cache and the xapian db?
<joaopinto> pwnguin, I have read the FAL license, it seems fine except for the GPL incompatibility (as per GNU's assessment), does the DFSG addresses license compatibility ?
<pitti> mvo: out of interest, what would that speed up in particular?
<mvo> pitti: I don't think that would go well in debian to force it on people, apt-xapian-index creates a index that is roughtly equal in size to the package lists (unpacked) and it takes ~1-2min to build the index. as far as maintainace costs are concerned, that is not too bad, the xapaian code is small and all the heavy lifting is done by the libxapian. so I think that is ok
<mvo> pitti: it makes the full text search over name and description fast. if you run synaptic and do a search for name+descrption that takes a couple of seonds (its not too bad)
<pitti> mvo: well, but then you have that huge index *and* the other apt cache...
<mvo> pitti: if you install the apt-xapian-index, then the result are there instantly
<pwnguin> joaopinto: im browsing debian-legal's archives now. GNU's incompatibility may or may not matter, but there's a question of whether FAL discriminates against business or corporate use
<pitti> mvo: hm, apt-cache search only takes < 2 seconds, too?
<mvo> pitti: right, the other apt cache is not primarely concerned with name+description, it contians the dependency information (that is the primary aim for it)
<mvo> pitti: right, apt-cache is pretty fast, however for search-as-you-type it is not fast enough
<mvo> pitti: again, its a "nice-to-have", we certainly do not need search-as-you-type, we could do without just fine
<pitti> right (especially since you don't usually install ten packages every day)
<pwnguin> joaopinto: if this game isnt brand new, there may already be a conversation about it on debian-legal. however i believe that ubuntu does choose to adopt some things debian does not, so don't give up hope!
<pitti> so that again seems to be the inconsistency between "we don't want to force it to all people, but then again everyone should have it"
<mvo> pitti: agreed, I have no particularly strong opinion on this, I'm fine with demoting it if we don't want to trade this feature for the cd space
<joaopinto> pwnguin, there is no such restriction, in fact it's own compatibility requirements includes the ability to distribute for comercial purposes
<pwnguin> joaopinto: the FAL uses phrases that could be construed as anti corporate, but not anticommercial
<pitti> joaopinto: GPL/FAL incompatibility shouldn't matter for things like code/artwork, since they are not linked together (in the .so lib sense); unless it's .xpms, of course
<mvo> pitti: I don't see a inconsitency here. from my upstream perspective it is something I want everybody to use because it is cool and makes a good impression and is useful. however I understand from the distro perspective that we need to balance space and features
<mvo> (or maybe I misunderstoof it?)
<pitti> mvo: you meant that you wouldn't put it into Debian by default, and rather maintain two backends instead of one, and then install both? that's the bit that seems inconsistent to me
<pitti> if xapian rocks, then let's get rid of the huge /var/lib/apt/lists/ dir and just use the xapian db everywhere
<pitti> and if it doesn't rock, then we shouldn't install it by default
<mvo> pitti: debian will have synaptic: recommends. apt-xapaian-index and that will get installed by default
<mvo> pitti: xapian is only about text search, the lists/ dir is still required for the building of the cache information
<pitti> mvo: ah, and that can't be put into the xapian db?
<mvo> pitti: no, xapian is really only a text-indexer/searcher, its not a general purpose db
<pitti> (fulldisclosure: I have no idea what xapian does exactly)
<mvo> :)
<mvo> maybe the "xapaian is just a text-indexer" was the missing bit then :)
<mvo> ok, so for cd space reason we don't add the fast search for now?
<pitti> if we can free up some space, and it is generally considered a good feature, we should by all means discuss it, but personally I'm inclined to say no because it doesn't seem to be the most urgent thing
 * pitti stops sobbing at http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and toddles off to lunch
<pitti> which is always a good approach to hopeless problems which take a manweek to sort out :)
<mvo> hmm, luch. a good idea :)
<mvo> just as a data point for the discussion, the currnet live-cd (with universe enabled) requires additional 20mb of download if recommends are enabled
<mvo> some of those can be trimmed down (e.g. synaptic recommends deborphan which it really shouldn't anymore)
<pitti> yeah, it was already heavily trimmed down
<pitti> mvo: and we can substract gst-plugins-{bad,ugly} in good faith, too, because of easy-codec-install
<lifeless> james_w: see my link in backlog ?
<james_w> lifeless: yeah, thanks.
<james_w> I've spoken to Federico about something similar before, interesting to see where he went with it. I haven't looked at the code though
<pitti> TheMuso: do you think denemo should stay in main? if so, it needs MIRs for lilypond, csound, and aubio
<pitti> TheMuso: I'm asking because I'm not 100% sure whether ubuntustudio is built from universe or just main
<persia> pitti: From universe
<persia> Unless something outside studio needs it, no need to stay in main
<pitti> oh, seens that edubuntu-desktop depends on it, too
<pitti> ogra: ^ that's built from main, right?
<persia> pitti: Yes, edubuntu is main
<ogra> yup
<ogra> mainly fo writing musical annotation though, i dnt know why it now depends on the sequencer stuff
<pitti> ogra: so, if you can/want to afford the space, they don't seem too bad for main (haven't looked in detail, but sound quite harmless)
<persia> ogra: Recommends.  It likes lilypond as a front-end, and that gets csound (for reasons I don't understand).  I'm not sure about aubio
<ogra> pitti, i have 400M fee, feel free to drop anything on me you like ;)
<ogra> *free
<pitti> ogra: heh
<ogra> pitti, btw, ltsp will need sshfs, anythin you could think of that would block it from main fom the top of your head ?
<ogra> (and from the CD indeed)
<pitti> ogra: that's the fuse layer over ssh, right?
<ogra> yep
<ogra> the new localdev implementation we developed last week will need it
<pitti> ogra: if the gvfs ssh backend doesn't work for you at all, it doesn't sound too crazy
<ogra> no gvfs on the clients ... to heavy deps
<pitti> if you want to own it?
<ogra> i can, yes
<pitti> should not take a lot of maintenance; if it works for you, fine
<ogra> great, i'll file a MIR during the day
<pitti> fta: do you think the "Recommends: cvs, mercurial" recommends of mozilla-devscripts can become suggests:? they aren't needed for using m-d as a build dependency, and mercurial would need a MIR; also, a developer will notice pretty fast that he needs to install mercurial (command-not-found helps there, too)
<fta> pitti, hm, sure. no problem
<pitti> fta: thanks; (sorry, I can't commit to the branch, it's owned by ~mozillateam
<fta> i will do it
<pitti> fta: but I'm happy to check it out and sponsor the upload for you, if you want
<fta> ok, i will let you know if i need a sponsor (depends on what else is in the pipe and if asac is responsive)
<TheMuso> pitti: Ubuntustudio is built from universe, I wasn't the one who requested denemo be in main.
<pitti> TheMuso: ok, thanks
<tkamppeter> pitti, I did not find it by the search function of Synaptic, which package do I need to install to get the German locale?
<pitti> tkamppeter: if you *just* need the locale, you can "sudo locale-gen de_DE.UTF-8"
<pitti> tkamppeter: but usually you would install language-pack-gnome-de
<pitti> tkamppeter: and a real GUI lover would use system -> admin -> languages and click on "German" :)
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, and now the more difficult question:
<tkamppeter> I want to build Gutenprint with I18ned PPDs. Upstream tells me that I need the locale for every language supported by Gutenprint (~20 languages).
<tkamppeter> How do I proceed there?
<tkamppeter> Especially to avoid installing language-pack-gnome-?? into a pbuilder chroot.
<tkamppeter> I cannot put "sudo locale-gen ??_??.UTF-8" into the Build Dependencies.
<ogra> tkamppeter, there is a "language-pack-base" it could probably go into that one instead
<pitti> ogra: no, that's still per-language
<ogra> pitti, ah, you want to have it completely independent
<pitti> tkamppeter: why do you need locales for using gettext/whatever for translating PPDs?
<pitti> tkamppeter: anyway, you could create them locally into a temporary directory by iterating over /usr/share/i18n/SUPPORTED
<pitti> tkamppeter: ah, for having correct representations of number formats, and so on?
<tkamppeter> pitti, I do not know the internals of the build system of Gutenprint ...
<ogra> seb128, i had some complaints from intrepid ltsp users that things in /media/$USER/device dont get catched by gvfs anymore, did anything change in there wrt monitoring /media ?
<seb128> ogra: "catched"?
<ogra> well, they dont show up on the desktop/in places and dont open a nautilus window
<ogra> but are mounted in /media/$USER/<device> as before
<pitti> hm, for me it's the other way around
<pitti> I get two icons and nautilus windows, plus an error message, for each device I plug in
<ogra> you dont mount in subdirs though
<ogra> ltspfs is always been kind of special here dur t being multi user
<ogra> *due to
<seb128> pitti: that's bug #251991 and fixed in svn
<ubottu> Launchpad bug 251991 in gvfs "Mounted USB harddrive showes twice on the desktop - right click one of the icons and choose "Unmount Volume" results in error "DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given mount was not found"" [High,Fix committed] https://launchpad.net/bugs/251991
<pitti> seb128: nice, thanks
<seb128> ogra: no, no idea but there is too much to track at the moment for me so I might just not have read about it yet
<ogra> seb128, i was assuming its still to much in flux ... i'll ping you later in the cycle if it still happens then
<seb128> ogra: alright, thank you
<ogra> stgraber, ^^^^
<seb128> the current gvfs is known to have issues, cf the bug I pointed to pitti, they just did changes to the monitor process and the gphoto create conflicts
<seb128> the next version which is due next week should fix some issues
<ogra> i'm just worried they drop the subdir monitoring ....
<ogra> that was a big advantage beyond other ways (thunar, KDE) for ltsp
<ogra> but we'll see what they'll do ...
<seb128> there is no "subdir" monitoring
<seb128> gvfs does the mounting when devices are plugged and watch /proc/mounts otherwise
<ogra> it did monitor /media before
<ogra> additionlly to the above
<seb128> ogra: monitor to do what?
<ogra> if i created a dir there it showed up as device
<seb128> mounts are listed in /proc/mounts
<seb128> it never added a location because I did a "mkdir /media/something"
<seb128> no
<pitti> mvo: rejecting your libgksu SRU upload, there's no bug in the changelog
<ogra> no, but if we did a bind mount to /media
<norsetto> ouch, that hurts :-)
<ogra> or a subdir
<ogra> as well as move mounts
<seb128> ogra: are you sure those are not listed in /proc/mounts?
<ogra> (we switched ltspfs between gutsy and hardy from bind to move mounts)
<ogra> no, i'm not
<ogra> i'll check that
<seb128> anyway gio and gvfs didn't drop anything that I know in intrepid
<ogra> fact is that the current implementation doesnt pick them up
<seb128> but I doubt they were monitoring subdir in media
<ogra> but lets postpone the discussion until upstrem is evolved further :)
<ogra> i dont want to waste your time on something upstream hasnt made ready yet
<seb128> ogra: _g_get_unix_mounts () basically uses setmntent () getmntent () to go through the mounts
<seb128> alright
<mvo> pitti: meh, sorry :( there will be a day when I learn it I hope
<mvo> pitti: I upload a new version :)
<pitti> mvo: danke
<Riddell> mvo: app-install-data doesn't seem to have KDE apps any more, probably it needs the changes done for hardy removed
<mvo> Riddell: oh? let me check. I did some kde/kde4 changes
<mvo> Riddell: it seems that all of kde4 is here in gnome-app-install, I'm not sure about kde3
<Riddell> mvo: hmm, so it is, never mind me then, I'll look into why it's not appearing
<Riddell> mvo: able to look at gdebi at some point?
<mvo> Riddell: is it in adept?
<Riddell> mvo: adept 3 (of which new alpha just appeared in mornfall's PPA)
<mvo> Riddell: yes, it looks good (gdebi-kde), I want to do some more testing before I merge it
<Riddell> it's not appearing though
<mvo> Riddell: ok
<seb128> doko: did you look at the pygobject update?
<doko> seb128: working on it. you basically need to have a different soname for each library and install these separately
<seb128> ok, I see
<seb128> thanks for working on that, we will need it to update some GNOME components to the current versions
<doko> but automake doesn't allow macros in these lib_ macros, and libtool ignores my own -Wl option :-(
<alex-weej> mvo: something up with notification-daemon? standard became the default theme with my last update i think
<norsetto> anybody knows if asac is on holidays?
<seb128> alex-weej: are you sure you didn't switch themes the appareance capplet?
<seb128> norsetto: yes until monday
<alex-weej> seb128: not 100% -- does that now affect the notification theme?!
<norsetto> seb128: ah ok, guess I can wait then, thx
<seb128> alex-weej: the appareance capplet has notification themes support now, it seems some themes set that to GNOME but we didn't update the ubuntu theme to list a notification theme yet
<seb128> alex-weej: so the key might have been switched and not switched back there
<alex-weej> seb128: yes that is correct
<alex-weej> i forgot how ugly the standard theme was
<seb128> alex-weej: set /apps/notification-daemon/theme to "ubuntu"
<alex-weej> yeah got it
<mvo> alex-weej: oh? that should not be the case, let me check
<alex-weej> mvo: see above!
<mvo> alex-weej: aha, ok
<mvo> thanks seb
<mvo> thanks seb128
<seb128> np ;-)
<seb128> mvo: you are welcome to update human-theme to add the "NotificationTheme=ubuntu" line though ;-)
<mib_bfeqw2> tseliot: around? :) I'm sebner. already time to look at my xorg.log?
<tseliot> mib_bfeqw2: no, sorry I'm working on other stuff. I'll get back to you ASAP
<mib_bfeqw2> tseliot: kk,  thx
<jdstrand> mvo: hi!
<kirkland> pitti: hi there-  i was wondering if you might take another look at the MIR for ecryptfs-utils again soon?
<jdstrand> mvo: so I was installing an intrepid schroot the other day, and apt didn't get installed. So then I copied apt to /tmp, and dpkg -i'd it, and thought things were ok, until today, I see:
<jdstrand> debconf: delaying package configuration, since apt-utils is not installed
<jdstrand> dpkg: syntax error: unknown group `Debian-exim' in statoverride file
<jdstrand> E: Sub-process /usr/bin/dpkg returned an error code (2)
<jdstrand> mvo: so I try to install apt-utils, but get the same error. what is the best way to get apt-utils installed? (I didn't see an option to dpkg that was applicable, but maybe I'm blind)
<tseliot> pitti: xkit 0.3.1 is available (revision 17) in my bzr branch. The ParseException is back (and a sensible sanity check is performed now) but I haven't had the time to plan the migration to x-kit of some of the code in Jockey.
<doko> seb128: http://people.ubuntu.com/~doko/tmp/pygobject.debdiff  ugly, I know. have to run now. but the idea should be clear. didn't figure out why it's rebuilt all the time ...
<kirkland> pitti: i see it's been approved, thanks!
<seb128> doko: thanks!
<mathiaz> slangasek: so what's your pov about openldap 2.4.11 ?
<mathiaz> slangasek: IIUC it won't happen in lenny
<sebner> tseliot: mail sent :)
<warren> ogra: around?
<slangasek> mathiaz: well, it's not definite that it won't happen in lenny; there's at least one important bugfix we should still get for lenny
<slangasek> so depending on how much else there is, it may be easier to just push the new upstream version in
<slangasek> mathiaz: but I also don't think we need to wait for it to be accepted into Debian before revving in Ubuntu, under the circumstances
<mathiaz> slangasek: I've talked with dendrobates about this - it seems that we'll diverge from debian within the intrepid timeframe
<ogra> warren, yeps
<slangasek> mathiaz: most likely, yes
<warren> ogra: so upstream nspuginwrapper has failed for a long time now to create an upstream devel list
<warren> ogra: making it impossible for developers to collaborate around it
<mathiaz> slangasek: there is some code in the cn=config branch that I could drop for intrepid that is still needed in debian
<warren> ogra: so I'm just going to create one
<warren> ogra: would your nspluginwrapper maintainer be averse to joining my list?
<ogra> warren, make sure to invite asac then
<mvo> jdstrand: sorry, I missed your ealier question. it seems like for some reason your have a incorrect /var/lib/dpkg/statoverride entry in your schroot
<mathiaz> slangasek: so I may just move on in intrepid and we'll sync again once lenny/intrepid are released
<ogra> warren, i'm sure he wouldnt
<slangasek> mathiaz: hmm, I'm skeptical of whether dropping code that we don't need, but Debian does, is worthwhile from a maintenance POV :)
<mvo> jdstrand: could you please open that file and check for a line with "Debian-exim" there?
<mathiaz> slangasek: aggreed - however that could would be dropped once lenny is released anyway
<mathiaz> slangasek: that *code*
<ogra> warren, but as i said, he's at the mozilla conf this week ... Alexander Sack <asac at ubuntu dot com>
<ogra> warren, he was in #ltsp for a while when we poked at the pulse bugs ... you met already
<mathiaz> slangasek: or do you think that keep supporting slapd.conf in debian is an option ?
<warren> nod
<slangasek> mathiaz: I don't think so, but I need to wait for my comaintainers to come around to the same opinion on their own :)
<slangasek> and if they take too long, we might slip past the window for doing this in lenny
<slangasek> (which would be unfortunate, indeed
<slangasek> )
<jdstrand> mvo: it's the only line in there
<jdstrand> root Debian-exim 0640 /etc/exim4/passwd.client
<mathiaz> slangasek: hm - so my current plan for intrepid is to upload 2.4.11 *and* enable the cn=config migration
<mvo> jdstrand: could you try deleting that line and see if that cures the issue? I have no idea how this line came into that file though :)
<mvo> jdstrand: is exim4 installed in the chroot?
<jdstrand> mvo: yes-- it was a brand new schroot built with mk-sbuild-lv that ended up without apt
<mvo> jdstrand: ok, I know now that the exim4 pakcage installs that line
<mathiaz> slangasek: do you have another opinion/suggestion on that subject ?
<jdstrand> mvo: that did solve the problem, and I sould install apt-utils
<mvo> jdstrand: does your /etc/group contain Debian-exim (I guess not)?
<jdstrand> mvo: no
<slangasek> mathiaz: nope; that seems to be the correct course of action
<slangasek> mathiaz: are we converged on what we think cn=config migration should look like, now?  i.e., we've addressed any concerns about being able to re-sync after lenny/intrepid?
<mathiaz> slangasek: I've sent my latest patch
<mathiaz> slangasek: there are some issue you've raised wrt to new templates questions
<jdstrand> mvo: do you think this might have prevented apt from being installed in the first place? (I've long lost the log)
<slangasek> yes, I haven't read in enough depth yet to see if there's anything significant that you disagree with me on :)
<mvo> jdstrand: is exim4 still installed in the chroot? the exim4-config postinst creates both the Debian-exim group and the statoverride
<mathiaz> slangasek: I think we should explictely ask for the cn=config password as it's a big change
<mathiaz> slangasek: so that users know that their installation has been migrated
<mvo> jdstrand: that is something strange for sure (that apt did not get installed). do you have some setup where getent passwd DEbian-exim would return "true" in your chroot? nis/ldap or somesuch?
<mathiaz> slangasek: I don't think that trying to extract the admin password  from an existing database is worth the trouble
<slangasek> mathiaz: oh, that was one point I was going to respond on - I really don't see the use of a separate debconf question for the /crypted/ admin password, since we're only ever storing one crypted password in debconf at a time
<mvo> jdstrand: that might explain it, there is a check if the group needs to be added or if it is there already in the exim4-config postinst
<jdstrand> mvo: it is, I just dpkg-reconfigure'd it and it was added
<jdstrand> mvo: needless to say, I don't have a lot of faith in this chroot ;)
<mathiaz> slangasek: well - there are two scenarios to be supported: new installs, in which case the debconf question is asked only once and the password is used both in cn=config and the default directory
<mvo> jdstrand: heh :) I can understand that
<mathiaz> slangasek: the second scenario is on upgrades
<mathiaz> slangasek: you'd suggest to use the same question in that case ?
<jdstrand> mvo: I'm going to try to see if the latest intrepid happened to fix this, to see if it is transient of not.
<slangasek> mathiaz: the same question for the /crypted/ password, yes; rather than having two separate internal questions, when we only ever use one at a time
<jdstrand> mvo: I can say it was repeatable on the day I tried to set it up
<mvo> jdstrand: ok, let me know your findings, that is definitely a strange problem
<slangasek> mathiaz: it's a minor point, but it will simplify a little; and if there's no reason conceptually that we want these two passwords to be different, I think it's cleaner
<jdstrand> mvo: agreed. thanks! :)
<mathiaz> slangasek: aggreed -so the goal would be to get rid of cfgadminpasswd
<slangasek> mathiaz: slapd/internal/cfgadminpw, yes
<mathiaz> slangasek: however, we still need to have an internal template to keep track that we've asked for the admin password when migrating on upgrade
<mathiaz> slangasek: I've tried to use on adminpw and then I was asked three times to enter the password
<mathiaz> slangasek: adminpw wipes the password, but the seen flags needs to be reset to false on upgrade
<mathiaz> slangasek: but that has to be done only once
<slangasek> hmm, I don't understand how that would happen; can you show me the code?
<jcristau> mvo: maybe schroot copies /etc/{group,passwd,...} from the host?
<mathiaz> slangasek: let me search for the code
<jcristau> mvo: so if exim isn't installed there, the group doesn't exist, and dpkg goes boom
<jdstrand> jcristau: I would expect it to go boom on all my schroots then-- I recreated dapper-intrepid on that day, and only intrepid failed
<jcristau> jdstrand: does exim install the statoverride in other versions too?
<jcristau> hrm, looks like it does
<jdstrand> jcristau: dapper didn't
<jdstrand> hardy didn't
<jdstrand> I wonder if this has to do with pulling in Recommends automatically...
<jdstrand> none of the others have exim
<askand> Where is it defined what folders should be in the homefolder on instal?
<jdstrand> mvo, jcristau: new intrepid schroot is still broken
<jdstrand> mvo: interesting-- there is no 'I: Retrieving apt' line
<mathiaz> slangasek: http://bazaar.launchpad.net/%7Emathiaz/openldap/debian-cnconfig/annotate/224?file_id=877%40dce93848-5eb8-0310-a98f-f2b027ff39d8%3Aopenldap%252Ftags%252Ftrunk-2.3%3Adebian%252Fslapd.config
<jdstrand> mvo: http://paste.ubuntu.com/33072/
<mathiaz> slangasek: http://tinyurl.com/6hdvl2
<mathiaz> slangasek: that's the version of slapd.config I ended up with before I introduce cfgadminpwd
<jdstrand> mvo: there there is no Debian-exim statoverride entry. so I must have done something when I added apt before (I don't know what though)
<jdstrand> mvo: that's it-- debootstrap 1.0.10 doesn't install apt
<jdstrand> (for intrepid)
<slangasek> mathiaz: hmm, maybe I'm not explaining myself clearly, then
<slangasek> mathiaz: here's what I'm thinking:
<slangasek> mathiaz: keep a separate debconf question (with different text, etc.) to use for prompting the user for a password
<slangasek> mathiaz: but when /encrypting/ the password, use the same internal question to store it
<slangasek> I think that avoids the issue you were having before?
<mathiaz> slangasek: I think so
<jdstrand> mvo: eg $ sudo debootstrap --variant=buildd --arch i386 intrepid ./intrepid  http://127.0.0.1/ubuntu/ -> no apt
<jdstrand> sid and hardy work
<jdstrand> and it's just with --variant=buildd on intrepid
<jdstrand> mvo: I just filed bug #254042, but seems it is more of a dependency problem with Build-Essential
<ubottu> Launchpad bug 254042 in debootstrap "debootstrap does not install apt with --variant=buildd for intrepid chroot" [Undecided,New] https://launchpad.net/bugs/254042
<mvo> jdstrand: thanks, I check it out
<kees> mvo: say, can you update the libcap library in debian?  2.12 is current, I think.
<mvo> kees: there is a libcap2 package that has 2.11
<kees> mvo: oh.  heh.  yeah, that works.  :P
<mvo> I need to check if we can not just drop the libcap1 stuff
<kees> mvo: one of the cap upstreams is in #ubuntu-hardened (hallyn) if you have any questions.
<mvo> kees: cool, thanks. good to know
<mvo> blueyed: hello! good to see you :) have you seen my question regarding the crash of update-manager with the virtualbox-ose package?
<blueyed> mvo: just answered.
<mvo> blueyed: cool, thanks!
<blueyed> mvo: hope it helps.. I'm not really sure, since the traceback seems to be in python libs only..?!
<mvo> blueyed: only the "hardy: Fatal IO error 9 (Bad file descriptor) on X server :0.0." ? but that was reproducable for you?
<blueyed> mvo: not sure.. (I've tried to find a bug that I might have submitted for reference and marked as dupe, but could not find it). I'm quite sure though, that answering "no" to the "abort"-question in vbox-ose once caused two crashes (update-manager and virtualbox-ose).
<mvo> blueyed: ok, thanks. I will try to reproduce it here, thanks for looking into that
<slangasek> hrm; OOo now depends on ttf-liberation, which isn't in main and has no MIR open?
<mathiaz> kirkland: I'd more enclined to put ecryptfs-utils in the supported seed rather than the server-ship seed
<kirkland> mathiaz: okay
<mathiaz> kirkland: if adduser depends on ecryptfs-utils, it will go on the -alternate iso also
<kirkland> mathiaz: okay, shall i make that change in my branch?
<kirkland> mathiaz: supported looks like a strange place to put it, looking at the other things in there
<mathiaz> kirkland: probably dvd then
<mathiaz> slangasek: do you have a suggestion on where to put ecryptfs-utils now that it's MIR has been accepted ?
<slangasek> mathiaz: seed-wise, you mean?
<mathiaz> slangasek: yes
<slangasek> if the plan is to use it as a dependency, it doesn't need seeded directly at all
<mathiaz> slangasek: well - that's the plan - but it hasn't been accepted yet
<kirkland> slangasek: okay, i'm hoping to have adduser depend on it, eventually
<mathiaz> slangasek: so if the adduser doesn't make it for intrepid, we still need to seed ecryptfs-main somewhere
<slangasek> ok.  I have no opinion on server-ship vs. supported, that's entirely a question of whether you guys want it on the CD right now, I think
<mathiaz> kirkland: ok - so I don't think we need it on the CD
<kirkland> mathiaz: okay
<kirkland> mathiaz: i'll try and get my adduser work done sson
<kirkland> soon
<mathiaz> kirkland: I'm looking at the platform.intrepid branch
<mathiaz> kirkland: we could add ecryptfs-utils to the supported-sysadmin seed
<mathiaz> kirkland: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.intrepid
<kirkland> mathiaz: okay
#ubuntu-devel 2008-08-02
<emgent> hello
<moreau> ï»¿/j ï»¿#ubuntu-motu
<dholbach> good morning
<Laney> Am I right in thinking that these two lines are equivalent: http://pastebin.ubuntu.com/33333/
<james_w> Laney: have you seen https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-June/000430.html ?
<Laney> james_w: Yeah, I found that a couple of minutes ago
<Laney> thanks :>
<emgent> moin
<Mez> ze
<Mez> zul, you broke php
<persia> Mez: Consider it a security fix
<Mez> persia, what? making 30+ packages FTBFS?
<persia> Yep.  That makes all the PHP webapps uninstallable.  Immediately reduces the work of the security team :)
<Hobbsee> funny, i *don't* think the users will agree with you.
<Mez> persia, why the PHP bashing?
<Mez> bug #254215
<ubottu> Launchpad bug 254215 in php5 "PEAR depends not included" [High,New] https://launchpad.net/bugs/254215
<persia> Hobbsee: Neither do I.
<persia> Mez: Not PHP, so much as the dependent apps.  Seems to be a persistent set of security problems, as likely related to the domain as the implementation.  Anyway, it was supposed to be a silver lining.  Apaarently it's well tarnished, and I'll take it away again.
<Mez> persia, to me, it just seems like you're PHP bashing... saying that anything written in PHP is a security hole. Which ... I'm pretty offended by as a PHP developer
<persia> Mez: Not anything, just some things.  No offense intended.  I've also been a PHP developer, I just dislike all languages equally.
<dholbach> Mez: it'd help zul, if you told him what's broken
<Mez> yes, there are some badly written scripts out there. But, that's the same as anything. Look at some of your higher end apps... and you'll see what I mean (wordpress, wikimedia, etc etc). Yes, there are going to be security holes... but because it's written in PHP, it doesn't mean that there are going to be more in it... Unless it's written by a bad programmer. Who would make those same problems in any other package
<Mez> dholbach, I thought I did ?
<Mez>     - Depend on php5-cli in php-pear (Closes: #482517)
<dholbach> I just read "you broke php"
<persia> dholbach: Details are in the bug.
<dholbach> alrighty
<Mez> dholbach, https://bugs.edge.launchpad.net/ubuntu/+source/php5/+bug/254215
<ubottu> Launchpad bug 254215 in php5 "PEAR depends not included" [High,New]
<persia> Mez: well, wordpress was one of the apps with the persistent updates, but yes, there can be well written apps.
<Mez> persia, wordpress to me seems to do more feature releases than security releases...
<persia> Mez: Yes, and sometimes with security fixes mixed in.  Anyway, we're well away from the original point.  Again, I'm sorry that my comment was taken as offensive, and do agree the bug should be fixed.
 * Mez goes and watches tv to help him contemplate whether to order pizza or not
<james_w> should dd-list be taught to give sensible results on Ubuntu?
<james_w> I can't imagine that anyone would be interested in the current output
<emgent> heya
<nxvl> any archive admin here?
<geser> nxvl: I guess it's not the best time of day to find an archive admin around
<nxvl> geser: yes, that's what i thought
#ubuntu-devel 2008-08-03
<jack--> does packages.ubuntu.com work for anyone atm?
<cvasilak> jack--, no i can't connect myself too
<jack--> ;<
<jack--> ok, thx
<cvasilak> jack, :)
<jack--> wow, now it does
<jack--> 5 minutes later
<jack--> no css though..something seems broken
<jack--> now it even has its css again
<jack--> that poor box must be under heavy load
<jack--> what happened to seveas, btw?
<jack--> did he switch to suse or something?
<calc> the ooo-langpacks diff is getting big
<calc> bzr diff| wc 7384   15488  192068
<calc> and that is around 1/6 of the way done
 * calc hopes it actually works once he is done patching the files
<emgent> calc: heya :D
<calc> special casing out all binaries from building in OOo is very tedious
<calc> looks like i will probably have to modify 2000 makefiles to do it
<lifeless> MEEEEEP
<emgent> woow
<AnAnt> is Matvey Kozhev here ?
<Kamping_Kaiser> hi all. the recent update to xulrunner causes it to conflict with epiphany ( https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/253462  ). Who should be aproached to get the updated packags copied/moved from -updates into -security ?
<ubottu> Launchpad bug 253462 in xulrunner-1.9 "xulrunner-1.9 in hardy-security Breaks {epiphany-gecko, yelp} in hardy" [Undecided,New]
<Kamping_Kaiser> this bug is a release blocker for gNewSense, as we use Epiphany as our primary browser.
<persia> Kamping_Kaiser: You need an archive-admin to do that.
<Kamping_Kaiser> persia, iirc theres an archive-admin list - fire them off an email?
<persia> Kamping_Kaiser: I've always had more success finding them here in the 06:00 - 02:00 UTC range on weekdays, but you may have a different experience.
<persia> Also note that while yelp can likely be copied, epiphany-browser has a new upstream update in -updates, so may need a specially crafted version for -security (which is both less than the one in -updates and sufficient to meet the needs for xulrunner)
<Kamping_Kaiser> i dont think i'll try to fix this one *g*.
<Kamping_Kaiser> not sure if i'll be able to be here in those times
<persia> Kamping_Kaiser: It's a 20-hour range, but I understand :)
<Kamping_Kaiser> persia, it is yes :) i'll send off an email, if i can make it here as well thats a bonus.
<geser> Hobbsee: have you time to give-back pbuilder?
<geser> please
<Hobbsee> geser: given back
<emgent> heya \sh
<geser> soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge?
<soren> geser: Erm.. Good question. Let me check.
<soren> geser: Oh, right, I think I remember now. Let me find the bug reference.
<soren> Oh.
<soren> I found a bug about libiptc's inclusion being a mistake, and thought that was true of libipq as well..
<soren> geser: If you throw me a patch to enable it again, I'll be happy to apply it.
<soren> Sorry for the inconvenience.
<bfields> I've got a bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/227837 with a patch available.  https://wiki.ubuntu.com/Bugs/HowToFix suggests that the next step is to ask here for a developer to do an upload?
<ubottu> Launchpad bug 227837 in libvirt "overzealous masquerading affects vm to vm traffic" [Undecided,Confirmed]
<stgraber> bfields: you should poke soren he's the one who last uploaded that package. Though it's weekend and you'll probably have more luck tomorrow.
<bfields> stgraber: ok, thanks.  So would email to soren at ubuntu.com do the job?
<owen1_> can u say that ubuntu development is agile? if yes, do u have any links for more info?
<stgraber> bfields: well, the Ubuntu virtualisation team is subscribed to this bug and he's the owner of the team so he already received e-mails from Launchpad
<owen1_> (it's for a university assignment)
<bfields> stgraber: ok, so by "poke", you mean try to reach him by irc?  (I'm not used to irc, so a bit lost...)
<stgraber> bfields: in my case just saying my nickname in a sentence adds it to a list of messages that I read when I'm back (/away displays them). That's the default behaviour in irssi and probably some other IRC clients
<bfields> stgraber: ok, thanks.  So I guess I should hope the above does the job, then maybe try again during the week if nothing obvious happens.
<greg-g> package gnome-color-chooser's description has " http://www.punk-ass-bitch.org/gnome-color-chooser/" as its homepage.  That link forwards to "http://gnomecc.sourceforge.net/"  Would it be acceptable to file a bug to request the change of that Hompage link?
<james_w> greg-g: you mean in Debian?
<greg-g> james_w: I guess that is where it should be filed yeah.
<james_w> I don't see why not
<greg-g> even if the Debian maintainer's email is @punk-ass-bitch.org ? ;)
<james_w> greg-g: if there is a redirect then updating it seems to make sense
<james_w> you can always ask
<greg-g> yeah
<pwnguin> heh
<pwnguin> why is "fuck" censored in one description of a brainfuck package but not the rest?
<greg-g> that doesn't make sense
<pwnguin> its not even related to differing DD maintainers
<pwnguin> actually, i misspoke
<pwnguin> of course, we also dont seem to ship bitchx
<pwnguin> seems debian stopped too
<ion_> greg-g: Why request a change? The link works, doesnât it? Perhaps upstream migrates away from sourceforge, and the current link will then redirect to the new location.
<greg-g> ion_: if upstream migrates away from sourceforge the update the homepage to their new home, no?  Otherwise, we should just create a packagename.redirect.debian.org or similar for homepages, which seems redundant/not useful.
<greg-g> s/sourceforge the update/sourceforge then update/
<ion_> The link works right now. I donât see the problem. :-)
<ScottK> pwnguin: We don't ship bitchx due to it's stunningly poor security history as I understand it.
<ScottK> greg-g: I don't see the problem either.
<emgent> heya
<ion_> Howdy
<ScottK> Particularly when (given the maintainer's address) you can be pretty sure it's not left that way by accident.
<greg-g> ScottK: well, right.  But it seems like the Homepage field should point to the homepage of the project (if there is one), not the maintainer's personal redirect page for it.  but that is just personal opinion.  We'll see what he says.
<ScottK> greg-g: OK.  Personally I'd have better problems to spend my time on, but volunteer however suites you.
<greg-g> ScottK: thats great, I will.
<ScottK> :-)
<emgent> argh packages.u.c down again.
<jpds> emgent: Reported hours ago.
<ion_> greg-g: The author of gnomecc seems to own the domain punk-ass-bitch.org.
<ion_> greg-g: It seems to be the upstreamâs redirect page, not just the maintainerâs.
<greg-g> ion_: thanks for the info.
#ubuntu-devel 2009-07-27
<spotter> there appears to be a major problem w/ gnome settings daemon
<spotter> filling up my hd w/ output that .xession-errors is catchng
<spotter> repeated ** (gnome-settings-daemon:3457): WARNING **: Connection failed, reconnecting...
<TheMuso> spotter: Is this karmic? Have you filed a bug?
<spotter> karmic
<spotter> just figured out what it was
<spotter> also noticed gnom-volume-control-applet chewing up all my cpu
<funman> hi
<funman> i just noticed a bug in karmic related to gnome/pulseaudio interaction, i'm not sure who to bug about it and how to look deeper into it
<TheMuso> funman: please file a bug against pulseaudio and it can be taken care of from there.
<funman> 287 open bugs on https://bugs.launchpad.net/ubuntu/+source/pulseaudio :/
<TheMuso> funman: well if you don't find a bug thats similar to your bug, please file a new one.
<funman> the problem is more, will it be looked at considering the number of "new, undecided" bugs
<funman> i'll just try to talk with the gnome people
<arand> funman: well, if you don't report it it will definitely not be looked at ;)
<funman> arand: true :)
<funman> 01:50 [gnome] !irc.acc.umu.se *** Banned: botnet (2007/09/02 19.51)
<funman> or perhaps i'm not ..
<funman> thanks!
<billybigrigger> what version of grub is karmic going to end with?
<fagan> 2.0
<fagan> Its the default at the moment for new installs
<billybigrigger> 1.96
<billybigrigger> 1.96+20090611-1ubuntu4
<billybigrigger> since when was it updated to 2.0?
<fagan> Oh my mistake
<billybigrigger> 1.96 is the latest in svn
<fagan> https://wiki.ubuntu.com/Grub2
<billybigrigger> it is dubbed grub2 i know
<billybigrigger> yeah, i created that page thanks :P glad it's becoming known :)
<fagan> Thats why I got mixed up
<billybigrigger> its old, started at a2 and haven't done much with it since
<fagan> Bloody long page
<ScottK> lool: I'm just uploading libio-compress-perl to resolve the problem we discussed last week.  It took awhile since upstream merged several modules into one package.  It'll also have to go through New and then get promoted to Main.
<AnAnt> Hello, can someone sponsor this merge: LP  404561
<ubottu> Launchpad bug 404561 in debhelper "Candidate revision debhelper_7.3.8ubuntu1" [Undecided,New] https://launchpad.net/bugs/404561
<AnAnt> and should I retitle this bug LP 401816 to a merge request ?
<ubottu> Launchpad bug 401816 in guile-1.8 "Conflicting types for 'jmp_buf' " [Unknown,Fix released] https://launchpad.net/bugs/401816
<AnAnt> as there is a patch for a merge there
<lesshaste>  the touchpad on my toshiba tecra a9 fails intermittently and I see this in dmesg psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
<lesshaste> I have to restart the computer to recover from this
<MementoMori> hi
<MementoMori> where can I find ext4 kernel headers?
<lesshaste> http://bugzilla.kernel.org/show_bug.cgi?id=12577 appears to fix my problem
<ubottu> bugzilla.kernel.org bug 12577 in Input Devices "DualPoint TouchPad at isa0060/serio1/input0 lost sync" [Normal,New]
<lesshaste> any chance of including it in jaunty?
<lesshaste> or should I email someone about it?
<tseliot> lesshaste: can you file a bug on launchpad about it and send a request to the kernel-team mailing list (attach the patch), please?
<lesshaste> tseliot, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/365968 I added to there
<ubottu> Launchpad bug 365968 in xserver-xorg-input-synaptics "touchpad randomly failing" [Undecided,New]
<lesshaste> tseliot, how do I email the kernel-team mailing list?
<lesshaste> ok I worked out the mailing list :)
<tseliot> lesshaste: subscribe to the mailing list https://lists.ubuntu.com/mailman/listinfo/kernel-team
<lesshaste> tseliot, done
<tseliot> lesshaste: ok, thanks. I'm sure that someone from the kernel team will get back to you
<lesshaste> ok
<lesshaste> it's a shame those kernel bugs in launchpad don't get triaged much
<lesshaste> I suppose it's a manpower problem
<Tonik> will new releases keep the "Delete removes files without asking" behaviour of Nautilus?
<YokoZar> hmm, ubuntu-bug ubiquity doesn't work
<YokoZar> should probably bother pitti about that
<gaspa> I need a rebuild of graphviz package (main), for ocaml transition... it builds in my ppa, apart lpia, which it already does.
<gaspa> james_w: are you around?
<ogra> Keybuk, does udev have any rules to create framebuffer devices or does that totally rely on the hardcoded stuff in initramfs ? i seem not to be able to find who it would create such devices
<ogra> s/who/how/
<Keybuk> how do you mean?
<ogra> Keybuk, ogra@babbage1:~$ lsmod|grep fb
<ogra> mxcfb_ch7026            3876  0
<ogra> ogra@babbage1:~$ ls /dev/fb*
<ogra> ls: cannot access /dev/fb*: No such file or directory
<Keybuk> then that module didn't request one
<ogra> that module should create a frambuffer device
<ogra> weird, it does so if its compiled in
<ogra> (which was the case in jauntys kernel)
<Keybuk> probably a bug in the module
<Keybuk> anything in /sys/class/framebuffer ?
<ogra> ogra@babbage1:~$ ls /sys/class/framebuffer
<ogra> ls: cannot access /sys/class/framebuffer: No such file or directory
<ogra> nope
<Keybuk> there you go then
<ogra> ok
<ogra> thanks
<Keybuk> in theory, udev needs no rules
<Keybuk> it will create all devices the kernel asks for
<Keybuk> rules are only needed to override the kernel (e.g. changing names or ownership)
<ogra> CONFIG_FB_MXC=y ... i guess that needs to be modularized too if the device driver is a module
<Keybuk> if it's ARM, I'd sarcastically guess that nobody implemented that bit of the kernel yet <g>
<ogra> oh man ... ogra@babbage1:~$ sudo modprobe uvesafb
<ogra> uvesafb: failed to execute /sbin/v86d
<ogra> why the heck is that even compiled
<cody-somerville> mvo, You asked me a question about update-manager, and a dbus service or something the other day. What was that question again?
<mvo> cody-somerville: if xuubntu supports shutdown via the gnome-session dbus interface. but as I understand it xubuntu now uses gnome-session too, so my question is mood
<mvo> (or answered)
<cody-somerville> mvo, gnome-session only runs when logged in as the gdm user
<cody-somerville> mvo, so the answer is no, the gnome-session dbus interface is not available in Xubuntu
<mvo> cody-somerville: oh, ok
<mvo> cody-somerville: thanks, then I need to look at some update-notifier changes again :(
<cody-somerville> mvo, Sorry :(
<mvo> np
<cody-somerville> mvo, I'll investigate if xfce4-session provides a similar interface
<ogra> HA !
 * ogra found the issue
<mvo> cody-somerville: that would be very nice, having something to use on the dbus would be great
 * cody-somerville wishes there was an fd-o standard/spec for cross-desktop session manager dbus interfaces like this.
<mvo> ++
* You're now known as ubuntulog
<ogra> hmm, are modules in /etc/modules loaded top to bottom or bottom to top ?
<cody-somerville> mvo, doesn't hal provide an interface?
<chrisccoulson> cody-somerville - HAL is not used for power management anymore
<chrisccoulson> it is consolekit that provides an interface for stopping/restarting, but the issue with using that directly is it doesn't give the session a chance to terminate properly
<cody-somerville> How did HAL accomplish that?
<chrisccoulson> AFAIK - HAL has never had anything to do with stopping/restarting (only hibernate + suspend)
<chrisccoulson> mvo - how did update-notifier work before (I can't remember now)?
<seb128> chrisccoulson, it was using the session client interface and gdm I think
<seb128> chrisccoulson, ie closing the session and putting gdm in restart mode
<chrisccoulson> seb128 - thanks, i thought that was probably the case
<cody-somerville> seb128, would gdm-legacy be an okay name for the source and binary package for gdm 2.20.x?
<seb128> I would rather use gdm-2.20
<cody-somerville> seb128, okay.
<ogra> ogra@babbage1:~$ ls /sys/class/graphics/
<ogra> fb0  fb1
<ogra> HA !
<ogra> Keybuk, you were right, the module misses a dep on another module that has to be loaded before
<lamont> so out of curiosity, how in the &&%( was backporting debhelper 7 to hardy-backports justified?
<lamont> I mean, it's not like it potentially affects the majority of the archive....
<lesshaste> I get " shm.c: mmap() failed: Cannot allocate memory" all the time when using pidgin
<lesshaste> is this a known problem?
<lamont> lesshaste: in karmic?
<Keybuk> ogra: fbcon?
<ogra> Keybuk, nope, mxcfb_ch7026 needs to depend on mxc_ipuv3_fb
<ogra> Keybuk, seems FSL never uses frambuffers modularized :)
<ogra> ogra@babbage1:~$ modinfo mxcfb_ch7026|grep depends
<ogra> depends:
<lesshaste> lamont, jaunty
<\sh> hmmm..where is config dir of postgresql-8.3 in jaunty hiding nowadays? normally there was a /etc/postgres  directory in the past...
<kkszysiu> Hello. Im making deb package but I dont know how to make tar.gz archive with dir tree started from "."
<kkszysiu> like in data.tar.gz
<kkszysiu> dir structure starts from . like ./usr/lib...
<ion> Youâll want to create a source package (dh_make) and build the deb out of it using dpkg-buildpackage (or the handy wrapper, debuild). #ubuntu-motu should help.
<Pici> kkszysiu: Have you read the packaging guide:  http://wiki.ubuntu.com/PackagingGuide  Also, packaging related questions are more on-topic in #ubuntu-motu
<superm1> cody-somerville, you are uploading an old gdm to be available side-by-side with 2.26+?
<cody-somerville> superm1, side-by-side, no
<cody-somerville> superm1, installing 2.20.x will uninstall 2.26
<superm1> cody-somerville, yeah that's what i meant
<superm1> why not just sort out issues with new gdm
<superm1> this seems like a problem in the making..
<cody-somerville> superm1, We will eventually but its unlikely such an endeavour would be complete for karmic
<superm1> cody-somerville, what are the current issues?
<cody-somerville> superm1, its requires gnome-session and gnome-settings-daemon
<superm1> cody-somerville, ah right
<superm1> well you are going to have issues with the installer not being able to support autologin anymore once you switch to old GDM
<cody-somerville> superm1, Could you elaborate?
<superm1> cody-somerville, in the appropriate installer component(s), when it offers automatic login reconfigures the custom.conf in /etc/gdm nowadays.  it used to do gdm-cdd.conf, but I don't believe that legacy support remains
<cody-somerville> superm1, I guess I'll have to fix that
<cody-somerville> superm1, Thanks for pointing that out
<superm1> nonetheless, you need a nice way to query what version of gdm is on the livefs if you wanted to use gdm-cdd.conf or custom.conf on demand
<superm1> cody-somerville, yup np.  take a look through user-setup, i think most of that happens there nowadays
<seb128> cody-somerville, superm1: having gdm2.20 and gdm will make conffile handling trickier too
<seb128> ie you will need to support people switching between those
<seb128> and the conffile move between binaries and versions
<superm1> i'm not encouraging gdm2.20 myself, i'm fine just having gnome-session-bin and gnome-settings-daemon stuck in the install for mythbuntu until xfce has suitable replacements
<superm1> we've got a workaround for bug 403291 for now (albeit a bit of an ugly one)
<Usama> hello, https://bugs.launchpad.net/ubuntu/+source/icewm/+bug/270019 when it will be decided
<Keybuk> decided?
<Usama> importance undecided
<Usama> it's simple patch that could make it works
<lamont> lesshaste: that would make it a question for #ubuntu....
<ubottu> Launchpad bug 270019 in icewm "Arabic support in icewm" [Undecided,New]
<Laney> Usama: I suggest you try and get that patch integrated upstream
<Laney> pop by their IRC channel
<lesshaste> lamont, really?.. the chances of anyone in #ubuntu even being able to understand the question... :(
<Usama> they don't respond
<lamont> lesshaste: this would be the channel to discuss your patch to fix the problem
<Usama> http://sourceforge.net/tracker/index.php?func=detail&aid=1440618&group_id=31&atid=300031
<lesshaste> lamont, I take your point.. although it makes me sad :)
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0x1178908> bug 1440618 not found
<lesshaste> lamont, maybe this is an acceptable question.. I see https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/317537 but in my case I get it just by running pidgin
<ubottu> Launchpad bug 317537 in gstreamer0.10 "E: shm.c: mmap() failed: Cannot allocate memory" [Medium,New]
<lesshaste> lamont, should I open a separate bug report?
<lamont> lesshaste: either that, or if it matches closely enough, you could just mark the existing bug as also affecting pidgin
<lesshaste> lamont, ok but I feel sure it's not a pidgin problem
<gaspa> Ampelbein: hi.
<Ampelbein> gaspa: hi
<gaspa> have you plan to merge ocaml-bjack?
<Ampelbein> gaspa: it's pretty far down my list so if you want to take it, feel free to.
<gaspa> thanks, it's required to go on with ocaml transition,
<Ampelbein> no problem.
<gaspa> :)
<spotter> would not having pulse audio installed making gnome-volume-control-applet and gnome-settings daemon go crazy?
<spotter> i.e. they both keep on repeating to .xsession-errors "WARNING **: Connection failed, reconnecting..."
<spotter> hmm. it appears so
<seb128> spotter, yes, there is bugs about those and next upload will recommends pulseaudio
<spotter> it keeps on trying to run /usr/bin/pulseaudio and open related files
<spotter> seb128, this seems like a depends
<spotter> it fills up my hd
<seb128> no, a recommends
<spotter> then it shouldn't output warnings every 1ms
<seb128> you are not forced to use the the applet or enable the g-s-d option
<spotter> what options in g-s-d?
<seb128> the volume control
<seb128> it's a plugin you can enable or not in gconf
<spotter> hmm
<seb128> anyway the excessive pulling is a bug
<spotter> well, I can't seem to disable it easily :)
<seb128> the gnome-media issue is fixed in git
<spotter> so is an ubuntu desktop going to be usable w/ pulse?
<seb128> well recommends are thing installed by default you can uninstall if you know what you are doing
<seb128> no
<spotter> as I was having major issues w/ flash with pulse b4
<seb128> or rather yes but you will have no volume control
<spotter> I mean usable w/o
<seb128> you need pulseaudio to get volume control
<seb128> that's a GNOME choice
<spotter> but you read it right
<spotter> have the flash issues been fixed? (or dont know?)
<seb128> dunno
<seb128> ultimately flash is an adobe problem if you use the closed source adobe version
<spotter> I can deal without volume control at least on this machine (thinkpad w/ hardware buttons)
<spotter> didn't fedora make a non pulse mixer?
<spotter> thought I read something in lwn
<seb128> dunno, that's fedora who pushed to pulseaudio requirement over GNOME
<spotter> what gconf do I change for g-s-d
<seb128> I would find ironic if they wrote a non pulse version too
<seb128> ie they just rewrote the capplet to be pulseaudio only
<seb128> that's probably what you read about
<spotter> right, and people complained as it killed their audio
<spotter> so they put a non pulse one in for those who need it
<seb128> I would be surprised
<seb128> we had a non pulse version before in GNOME
<seb128> ubuntu patched jaunty to still use it
<seb128> the fedora guys said they would want such hack upstream and that audio stack and drivers should be fixed
<seb128> but there is plenty of non pulse mixers around
<seb128> in ubuntu too
<seb128> spotter, /apps/gnome_settings_daemon/plugins/media-keys/active
<spotter> anyways, know the gconf key i need to change?
<spotter> ah
<spotter> :)
<spotter> hmm
<spotter> that just killed g-s-d :)
<seb128> restart it?
<spotter> did
<seb128> and?
<spotter> though didn't seem to affect widget in xchat
<spotter> no more noise
<spotter> didn't redo widgets in any app running
<spotter> weird
<spotter> any idea how to remove gnome-volume-control-applet?
<seb128> spotter, go to system, preferences, session
<seb128> and uncheck the corresponding line
<seb128> or startup application it's named
<cody-somerville> seb128, gnome-keyring-daemon installs a autostart file to /etc/xdg/autostart - that shouldn't happen anymore right because pam takes care of it now?
<seb128> cody-somerville, pam is only used when you don't set autologin no?
<seb128> ie in the autologin case you need the autostart
<spotter> seb128: this is what I remember http://lwn.net/Articles/330432/
<cody-somerville> seb128, correct
<spotter> thanks
<spotter> hopefulyl now wont end up with a 4GB .xsession-errors file after one day
<spotter> :)
<cody-somerville> seb128, I have three gnome-keyring-daemon processes running - do you imagine that could cause problems?
<seb128> spotter, you should better use pulseaudio and try to get it working
<seb128> ie better to use energy to solve issues than to roll back to old technologies to avoid having to do the work
<spotter> seb128: except I cant deal w/ firefox hanging every time I close a tab that ran flash
<seb128> cody-somerville, I doubt it other people would have noticed
<spotter> I could avoid flash
<spotter> but unfortunately, want it for some things
<spotter> need either chrome or firefox process model to come around so this wont be an issue :)
<billybigrigger> dtchen, ping
<cody-somerville> hmm...
<cody-somerville> why is /usr/sbin not in my PATH anymore?
<seb128> soren, hi, could you look at bug #403216 which is waiting for sponsoring?
<ubottu> Launchpad bug 403216 in vm-builder "[debdiff] vm-builder dies with: AttributeError: 'VM' object has no attribute 'ec2'" [High,Confirmed] https://launchpad.net/bugs/403216
<seb128> soren, could you also look at bug #391224?
<ubottu> Launchpad bug 391224 in open-vm-tools "open-vm-tools should recommend open-vm-toolbox" [Low,Triaged] https://launchpad.net/bugs/391224
<kozz> where should packages that contains python code install the files?
<kozz> because coherence installs the files in /usr/share/coherence/ so I have to set PYTHONPATH to that directory for coherence so work
<kozz> are the files installed in the wrong directory or is there some PATH that need to be adjustet
<kozz> looks like most packages have their files installed in /usr/lib/python2.6/dist-packages
<DktrKranz> kozz: it's a known issue. I talked to coherence co-maint about it, he has to provide a public module via a new python-coherence package
<kozz> DktrKranz: right, was no bug about it on launchpad so I though it could be something on my machine only, some path that hadn't been updated during the upgrade or similar
<kozz> thanks for the info
<DktrKranz> np
<ebroder> Is there any way to suppress certain messages with notify-osd?
<ebroder> e.g. the system-config-printer messages that a job has completed?
#ubuntu-devel 2009-07-28
<TheMuso> Hrm, got some weird FTBF sstuff happening here.
<TheMuso> this is on the buildds BTW.
<jelmer> mathiaz, hi
<rickspencer3> ArneGoetje: hi
<jelmer> mathiaz, Thanks for the sync requests
<mathiaz> jelmer: sure :)
<mathiaz> jelmer: I've successfully built samba4 and talloc in a ppa
<ArneGoetje> rickspencer3: morning
<mathiaz> jelmer: thus the sync request
<mathiaz> jelmer: that should fix seb128 build failure for openchange (IIRC)
<jelmer> mathiaz, Ah, cool
<TheMuso> Yay, udev package setup is borking for some reason.
<TheMuso> which in turn breaks other pieces needed by the packages I have recently uploaded.
<twb> A package (dovecot-imapd) is listed as being maintained by MOTU.  How do I find out who the "real" stakeholders are?
<twb> I want to pay them to backport dovecot 1.2 to Hardy.
<twb> Oops, s/MOTU/Core devs/
<twb> Hmm, I guess I should look at Debian.changelog
<billybigrigger> is anyone here around to answer some questions about v4l and my webcam?
<billybigrigger> all through karmic development my webcam hasn't worked, is this because of v4l apps trying to use v4l2 devices?
<Tronic> How do you file a bug for fetching new version from Debian to Karmic?
<Tronic> We fixed some rather serious bugs and the new version is now in Debian Unstable.
<TheMuso> Tronic: What is the package?
<Tronic> performous
<Tronic> (performous-dbg and performous-tools also)
<Tronic> Ummh, wait a sec, I think it is still in NEW.
<Tronic> 0.3.2 is the fixed version.
<TheMuso> You need to file a bug against the performous source package in launchpad, requesting a sync from unstable. Then you have to subscribe the ubuntu-universe-sponsors team to the bug so they can look at it. Please mention why the package should be updated in the bug.
<StevenK> But it isn't in unstable yet, if it's in NEW
<TheMuso> Tronic: Well once its out of the new queue, file the bug.
<StevenK> And we can't pull from NEW.
<Tronic> No, seems to be accepted to unstable, but I guess packages.debian.org hasn't updated its index yet.
<Tronic> TheMuso: Ok. Do I need any tags or something for it?
<TheMuso> No.
<Tronic> Will do that, thanks :)
<hile> helvetti ne olivat nopeita, 'luovutusta yritetty, vastaanottajaa ei tavoitettu' mÃ¤ tilasin sen hitto torstaina, yleensÃ¤ toimitusaika thomannilla 8-10 tyÃ¶pÃ¤ivÃ¤Ã¤!
<hile> oops wrong channel :)
<sanmarcos> in 9.04, does anybody else notice images (icons) in libnotify popups are blurry?
<phurl> anyone can help me with reprepro Error: Distribution doooh contains an architecture called 'all'. any ideaS?
<joaopinto> phurl, you dont need "all" listed on the Architectures field of a distribution
<phurl> joaopinto, thanks.
<joaopinto> I am using: Architectures: i386 amd64 source
<phurl> so when i remove it. i got a different error. lets see
<phurl> it is for java stuff
<phurl> josm_0.0.svn1529-1_all.deb
<joaopinto> no problem, "all" packages will be accepted anyway
<phurl> ahh
<sanmarcos> why does ubuntu break something new every release
<sanmarcos> pulseaudio, now libnotify
<phurl> working now joaopinto thanks!
<joaopinto> :)
<sanmarcos> notify-osd is such shit
<sanmarcos> you hove rthe notification and it hides, what the hell where they thinking
<sanmarcos> I give you a 512x512 icon and it still looks blurry
<joaopinto> sanmarcos, what your language !
<TheMuso> Seems like anything that pulls in udev to be built FTBFSes on all except for powerpc and armel.
<phurl> so how can i test my new repo on fedora?
<phurl> it only wants to use apt for rpms but not for debs :(
<phurl> how can i get apt on fedora to download debs?
<AnAnt> Hello, could someone sponsor those: LP 401816 & LP 404561
<ubottu> Launchpad bug 401816 in guile-1.8 "Conflicting types for 'jmp_buf' " [Unknown,Fix released] https://launchpad.net/bugs/401816
<ubottu> Launchpad bug 404561 in debhelper "Candidate revision debhelper_7.3.8ubuntu1" [Undecided,New] https://launchpad.net/bugs/404561
<slytherin> TheMuso: cjwatson_: infinity: A million thanks to whoever fixed powerpc buildd problems. :-)
<directhex> yay powerpc
<ares4you> Hi! I am ( was ) from Ubuntu developing team.  I had one big problem with  network manager ( i coldn`t acces internet ) I want to help developing ubuntu but I don`t want to test that packages with network
<ares4you> who can help me?
<slytherin> ares4you: What development team are you member of?
<ares4you> testing
<slytherin> oh
<ares4you> can someone help me?
<ares4you> I think I can`t test just some pacages
<ares4you> am I right?
<ares4you> what is doing computer janitor in developing team ( testing )? Can be used to reconfigure my system?
<maxb> ares4you: You might do better finding a channel specific to your native language. I'm sorry but your English is a bit too muddled for you to be understood clearly.
<ares4you> maxb: I am sorry! I am learning....
<ares4you> maxb: I do my best and I try to explain  if you do not understand me
<ares4you> from where can I download an older version of network manager?
<TheMuso> slytherin: and so far as things go now, powerpc is more healthy than supported architectures. :)
<joaopinto> ares4you, if you need general support, please ask on #ubuntu
<ares4you> thanks
<slytherin> TheMuso: how so?
<TheMuso> slytherin: Due to a weird bug that is being triggered whenever a package installs udev as a dependency, a lot of packages on everything except for armel and powerpc are failing to build.
<TheMuso> Its a buildd host issue I think. Armel and powerpc are not running hardy, so don't seem to be affected.
<slytherin> I saw one such error. But I didn't know the reason
<TheMuso> slytherin: I worked it out, thinking I may have been able to upload a fix somehow, but it seems not.
<simon-o> Hi, does anyone now if pitti is on vacation?
<seb128> simon-o, he is
<simon-o> seb128: thanks. Is anyone from ~ubuntu-mir around?
<seb128> you're welcome
<seb128> dunno, use launchpad and open a bug, etC?
 * ogra guesses its a hard week to catch people on IRC, half the world is at debconf and the other half on vacation :) mail and bugs might be the best bet
<simon-o> I've got a specific question about an existing bug, where I need some advice from someone from ubuntu-mir
<ogra> ask in the bug then
<simon-o> ogra: Yes I could, but who should answer that question ;)
<ogra> oh, its not a MIR bug ?
<james_w> simon-o: the LP page would tell you the other members
<simon-o> ogra: no it's bug 403565. And I don't know what to do next.
<ubottu> Launchpad bug 403565 in lyx "Sync lyx 1.6.3-4 (universe) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/403565
<simon-o> james_w: thanks, I'll see if I can catch someone from the team
<james_w> why is that ubuntu-mir?
<james_w> oh
<james_w> I see why
<james_w> but I think it's just oddness and shouldn't need them
<simon-o> james_w: geser from ubuntu-motu told me to ask someone from ubuntu-mir.
<geser> james_w: who should he ask instead?
<simon-o> :)
<james_w> I just happen to be sitting next to cjwatson, who is the perfect person to ask
<james_w> we're just fixing it now
<simon-o> james_w: thanks, that's great
<geser> james_w: why him?
<james_w> because it's cjwatson :-)
<james_w> he knows everything
<james_w> the problem is a cryptic error message
<james_w> it's a safety catch
<cjwatson> so the problem here is that lyx, a source package in universe, wants to produce a new binary package called latex-xft-fonts, which is already produced by a source package in main
<geser> yes
<cjwatson> latex-xft-fonts is in main for abiword and koffice
<cjwatson> which means, I think, that lyx needs to be MIRed
<cjwatson> I don't see any particular way around it
<cjwatson> the sync can be forced with sync-source.py -F
<geser> james_w: will remember that for the future (and if he complains I'll refer to you :)
<cjwatson> or maybe (as james_w says here) if latex-xft-fonts is just a transitional package then its rdepends should be updated?
<cjwatson> it happens that I've run into this problem before, that's all :)
<cjwatson> latex-xft-fonts Depends: ttf-lyx
<geser> cjwatson: that won't help here as latex-xft-fonts depends on ttf-lyx-fonts (build from lyx)
<cjwatson> so unless I miss my guess we're going to need to MIR lyx anyway
<cjwatson> perhaps an MIR that said "we only actually need the fonts, and won't be promoting the other binaries"
<cjwatson> but I'm not in ubuntu-mir :)
<geser> as I don't know the chances for lyx to pass MIR, I suggested simon-o to get some more input (if there are any other options)
<cjwatson> I can't think of any other options that are easier
<cjwatson> splitting the binaries back out doesn't seem like a great idea maintenance-wise
<geser> if the fonts didn't change, would it be an option to don't build the fonts package by lyx? and leave latex-xft-fonts in main as is?
<cjwatson> that would work but I think it's a bad idea in the long term, if it's just to try to avoid an MIR
<geser> but that would have the disadvantage of a package without proper maintainace in main
<cjwatson> we should just suck up the main promotion IMO
 * geser hands https://wiki.ubuntu.com/MainInclusionProcess to simon-o
<simon-o> geser, cjwatson: thanks for the insights. I'll request the main inclusion.
<YokoZar> kees: Just saw your name on the copyright of Wine's crypt32.dll ;)
<seb128> directhex, hi, do you know if anybody is working on updating mono and gnome-desktop-sharp2 to current version?
<directhex> seb128, mono is being worked on over the next week(ish) - all the mono stack except the main mono package itself is up to date
<seb128> directhex, gnome-desktop-sharp2 is 2.24 and upstream is 2.26?
<directhex> i know i looked at g-d-s, but i decided to hold fire for some reason. don't remember why
<seb128> directhex, ok, that was just a reply to your 'all the mono stack except the main mono package itself is up to date'
<seb128> directhex, no issue, I'm just checking was is marked outdated on the desktop team versions.html list
<directhex> (the mono stack is mono, libgdiplus, gluezilla, mono-tools, xsp, mod-mono, mono-basic and mono-debugger)
<seb128> oh ok
<seb128> learning every day ;-)
<directhex> i THINK (don't quote me on this) i held off when i noticed it was outdated, as our ABI validation tools are currently broken, and the guy making their replacement is MIA
<directhex> gnome-sharp people can occasionally cock that one up, which is what lead to that whole gnome2.24-cil in jaunty
<seb128> ok
<seb128> I will ignore it for now then ;-)
<directhex> but if you want it updated, i could take a look
<seb128> I'm just trying to clean the outdated list a bit
<directhex> oh, here's a better idea
<directhex> let's make slomo do it. slomo, you're gnome team AND mono team!
<seb128> ;-)
<slomo> directhex: what's the problem (in a single sentence please)?
<directhex> slomo, uupdate gnome-desktop-sharp2 from 2.24 to 2.26, assuming it doesn't horribly break everything
<directhex> seb128, i've been repeatedly promised a new f-spot from upstream before FF, by the way
<seb128> directhex, excellent!
<directhex> they're in FF themselves, so.... it might slide past FF, but i think things like this should go in with a minimum of fuss...
<seb128> right, desktopish upgrade are usually not an issue
<directhex> oh, and mono 2.4.2.2 will hit binary NEW, due to re-adding a library we disabled for DFSG reasons, and adding a lib that upstream forgot (!) to put in 2.4.0
<directhex> just FYI
<seb128> ok
<directhex> with luck we should also be able to actually deliver on something I promised earlier in the cycle (need to deal with some useless linkages in order to strip a 3 meg lib from the CD)
<ion> lc
<slytherin> Can any of the core devs please give back gnome-applets on powerpc?
<seb128> slytherin,
<seb128> done
<slytherin> thanks
<Riddell> ArneGoetje: did you do the language-support-zh-hant and other new pages?  why does language-support-zh-hant conflict/replace itself?
<ArneGoetje> Riddell: ?
<ArneGoetje> Riddell: like all language-pack/-support packages it conflicts/replaces a lower version of the same package... has always been that case.
<Riddell> why does it do that?
<Riddell> ArneGoetje: also how do these packages relate to language-support-zh ?
<ArneGoetje> Riddell: they replace language-support-zh. language-support-zh becomes a dummy package for transitioning to zh-hans/zh-hant
<ArneGoetje> Riddell: the language-pack/-support-zh packages got split into zh-hans and zh-hant
<Riddell> ArneGoetje: ok accepted, but that conflict/replace on itself should go, it's just confusing
<Riddell> ArneGoetje: and while I'm mentioning it, language-pack-kde-xx should depend on language-pack-xx
<ArneGoetje> Riddell: oh, damn... bug in the script... :( will fix it
<gaspa> TheMuso: any news on this morning problem?
<Riddell> dpm: any idea what should be done with bug 378075 ?
<ubottu> Launchpad bug 378075 in ddtp-ubuntu "Typos in package summaries" [High,Fix committed] https://launchpad.net/bugs/378075
<dpm> Riddell: on a call atm, I'll have a look and try to reply when I'm done
<mathiaz> kees: jdstrand: how do you feel about processing a MIR for mysql 5.1?
<kees> mathiaz: I likely won't have time this week (travelling to Blackhat)
<mathiaz> kees: travelling -> mysql 5.1 is amazing to be reviewed on a plane :)
<hyperair> dtchen: regarding pulseaudio, is it supposed to scale the system volume together with the apps volumes?
<hyperair> dtchen: it's causing some rather annoying issues with mplayer's pulse plugin when there is more than one pulse client
<hyperair> dtchen: e.g. if you repeatedly scale mplayer's volume up and down, you eventually mute all other clients.
<mathiaz> how can I find all the packages in main that build-dep on libmysqlclient-dev or libmysqlclient15-dev?
<lucas> mathiaz: using the edos tools
<pochu> or build-rdeps?
<lucas> ah, depends if you want transitive b-deps or not
<seb128> mathiaz, grep-dctrl -F Build-Depends -s Package libmysqlclient-dev /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_karmic_main_source_Sources
<mdz> Keybuk: I've created https://wiki.ubuntu.com/TechnicalBoard/TeamReports/09/July with the notes from today's meeting, if you could fill in the previous one
<Keybuk> mdz: sure, I'll paste from the mail
<AnAnt> Hello, can someone sponsor this merge: LP 404561
<ubottu> Launchpad bug 404561 in debhelper "Candidate revision debhelper_7.3.8ubuntu1" [Undecided,New] https://launchpad.net/bugs/404561
<sebner> Riddell: thanks for syncing themonospot that fast! :)
<Riddell> sebner: when it's my archive day, things get done! :)
 * directhex requestsyncs nant
<Riddell> too late, my archive day is over
<directhex> well, poop
<sebner> directhex: ahaha!
<sebner> Riddell for 7 days a week archive master \o/
<AnAnt> Riddell: when's your archive day ?
<Riddell> AnAnt: tuesday afternoons
<AnAnt> hmm
<AnAnt> isn't that today
<ogra> it was
<pitti> howdy
<AnAnt> Hello
<AnAnt> so, who's archive day is it ?
<sebner> pitti: \o/
<AnAnt> pitti: would you sponsor this merge: LP 404561 please?
<ubottu> Launchpad bug 404561 in debhelper "Candidate revision debhelper_7.3.8ubuntu1" [Undecided,New] https://launchpad.net/bugs/404561
<pitti> AnAnt: please sub u-main-sponsors, will go back to real work tomorrow
<maxb> It's impossible to purge sysklogd because it wants to deluser syslog, which is now used by rsyslogd - what needs to be done here?
<maxb> Perhaps karmic needs a dummy sysklogd package that can be upgraded to to nuke that postrm
<AnAnt> pitti: done
<superm1> mvo, ping.  i wanted to talk to you about helping figure out why the mythbuntu tasks are so broke when you get a sec
<mvo> superm1: hello! yeah, please tell me about the problem
<mvo> superm1: but its quite possible that I will do the actual investigation tomorrow morning, its getting a bit late here
<superm1> mvo, okay so the issue is installing the mythbuntu-desktop meta pulls in half of gnome.  installing the task doesn't pull in enough of the mythbuntu-desktop stuff. installing the task and meta at the same time pulls in about the right balance
<superm1> if you look at the livecd-rootfs branch you can see the current workaround that we have in our live disks that gets the right set of packages installed, but is still a hack
<mvo> superm1: ok, I check it out (tomorrow :)
<superm1> mvo, okay great thanks :)
<infinity> I'll give all the spare change in my pocket to the first person who tells me why perl is FTBFS on sparc.
<infinity> (Bonus points if you also fix dbus on ia64)
<infinity> That it all. :P
<Sarvatt> Does anyone know of any existing scripts or packages that handle reverting all packages in a PPA to the distro ones?
<arand> May I poke someone about a requested SRU which already has a debdiff? Bug #316502
<ubottu> Launchpad bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released] https://launchpad.net/bugs/316502
<stefanlsd> seb128: Im looking at Xchat in Karmic, where on the server list I see C_onnect. The xchat code is right, and it should be an accelerator for alt o. Do you know if any other GTK apps under Karmic are having an issue with this?
<seb128> stefanlsd, bug #404767
<ubottu> Launchpad bug 404767 in gtk+2.0 "gtk: mnemonic/accelerator shows as underscore instead of underline, and does not register with keyboard" [Low,Confirmed] https://launchpad.net/bugs/404767
<seb128> stefanlsd, testcase would be useful
<stefanlsd> seb128: thanks. somehow lp search never finds this stuff for me :)  will see what info I can add
<seb128> stefanlsd, you probably use the wrong keyword, usually sort by newer first that give you a good overview of recent issues
<maxb> doko: Hi, are you around?
<maxb> I'm trying to push a s/default-jdk-builddep/default-jdk/ change back to Debian and the maintainer is hesitant because no Debian Policy explains the purpose of these
<maxb> Can you provide an authoritative Debian citation for the correct usage of default-jdk vs. default-jdk-builddep?
#ubuntu-devel 2009-07-29
<pam> cjwatson: Is there a gfxboot language reference somewhere (not just the vocabulary but more general like stack handling,...)? I am failing miserably trying to walk through arrays (http://pastebin.com/m193ef855)
<pitti> Good morning
<geser> Hi pitti
<pitti> hey geser, wie gehts?
<geser> fine
<geser> and you?
<pitti> great, enjoyed some days off
<StevenK> Hey pitti!
<StevenK> pitti: It appears that the UNR and Ubuntu livefses fail to build due to: system-config-printer-udev: Conflicts: hal-cups-utils but 0.6.19+git20090217-0ubuntu7 is to be installed
<StevenK> pitti: Should hal-cups-utils just get unseeded in both cases?
<pitti> StevenK: yes, it should; it's obsolete
<StevenK> pitti: Okay, shall I fix both seeds and both meta packages?
<pitti> StevenK: I'm just committing the ubuntu change
<StevenK> pitti: You'll fiddle ubuntu-meta, or shall I?
<pitti> StevenK: please go ahead while you are at it
<maxb> I'm feeling a bit snubbed by the fast closure of https://bugs.launchpad.net/bugs/406070. Isn't a feature present in Jaunty being lost from Karmic a valid regression bug worth tracking, regardless of whether it's upstream's fault?
<ubottu> Launchpad bug 406070 in gnome-control-center "gnome-sound-properties removed without adequate replacement" [Undecided,Invalid]
<pitti> mbiebl: FYI, I committed 20_cpufreq_warning_message_fix.patch upstream, so we are back to two distro specific and easy patches in hal
<pitti> mbiebl: do you want me to commit the hal smartdimmer support that we have in Ubuntu to the debian experimental branch?
<pitti> mbiebl: I won't commit it for now, it's a bit dubious
<pitti> mbiebl: oh, and it's obsolete in the new DK world anyway
<seb128> maxb, the bug is not constructive, you should rather open request to add features to the new capplet
<maxb> Hrm. Tracking a feature regression in the distro is not useful?
<maxb> The features don't really belong in an applet calling itself the "Volume Control" anyway
<seb128> maxb, what feature?
<seb128> maxb, opening bugs about "the new capplet version sucks" is of no use no
<seb128> maxb, you should open a bug about "gnome-volume-control should let you selection <option you need>"
<seb128> selection -> select
<maxb> I didn't say "it sucks", I said "removed without adequate replacement"
<maxb> furthermore, I stated in the bug why adding features to gnome-volume-control didn't make sense
<seb128> maxb, still not a constructive way to approch things, we don't write this code
<seb128> well try being constructive there
<seb128> suggest what we should do knowing that we will not roll back to distro patch deprecated code
<maxb> Leaving aside all other matters, isn't it important to track the fact that we've removed a user-visible feature and not supplied any replacement?
<maxb> Especially when the feature is something Windows has had since 95? 3.1?
<seb128> maxb, I stop this discussion there I'm not interested in non constructive discussion there, we already have a collection of bugs about people like the old version better for random reasons
<maxb> Removal of a concrete features is not a "random reason"
<maxb> * feature
<seb128> you can select sound theme in the new interface
<maxb> You can coarsely choose between "Ubuntu" and "No sounds", yes
<maxb> that falls a long way short of selecting individual sounds for events
<seb128> well open a bug about "new capplet should you set custom sounds for events"
<maxb> and also it provides no way to select visual alert rather than audible, as the old one did
<seb128> maxb, bug #324700 is your request about sound events made in a constructive way and not with an unclear ranting title
<ubottu> Launchpad bug 324700 in gnome-media "gnome-volume-control is missing system events sound adjustment" [Low,New] https://launchpad.net/bugs/324700
<maxb> Your definition of ranting is considerably more sensitive than mine
<seb128> maxb, sorry but your bug title suggest that we should not have changed to capplet without have some features there but the decision of rewritting is not ours
<seb128> and we distro patched the previous codebase in jaunty to address those concerns
<seb128> so better to suggest changes to make it adequate rather than complain about the switch not being adequate
<maxb> OK, well, for my future reference, what _is_ the procedure when an upstream drops a feature without having firm plans to replace it?
<maxb> I guess another example would be the gdm graphical configuration tool, which we luckily have someone interested in writing a new one
<seb128> maxb, open a bug on the new component saying "the tools should have this feature"
<maxb> But in the general case, do we aim to track such feature-loss regressions in any way, or do we just aim to make upstream's current feature set work well?
<seb128> maxb, not saying "you switched before it was ready" or "how could you do that" or "new version sucks"
<seb128> maxb, depends of the feature, I'm not sure sound events ever worked correctly under GNOME and they are not a stopper
<seb128> maxb, ie they don't prevent any work to get done, don't destroy any data, etc
<seb128> we don't aim to replace every corner case option or at least don't consider that has a stopper
<seb128> as
<hile> for people who care about the sound themes the new capplet is of course a step backwards. myself, I only care about the 'disable all event sounds and themes' buttons
<hile> maybe this is some evil plan for 'sound theme feature pack' sales :)
<dpm> pitti: may we borrow you for a second on #kubuntu-devel for a question on translations (Riddell tells us that you also initially set up the kde i18n packaging infrastructure)
<pitti> dpm: joined
<dpm> thanks! :)
<sebner> pitti: uploaded lyx. thanks for you help
<PecisDarbs> hi people, is there any plans to address mobile broadband modem issue with usb_modeswitch? This utility isn't in repos even.
<pitti> sebner: just saw it, thanks for sorting this out
<sebner> pitti: well, my duty since I acked the sync :)
<sebner> pitti: really fixing it during archive-reorg?
<pitti> sebner: not really, I think
<pitti> we still don't want to officially "bless" lyx with support, do we?
<sebner> pitti: heh, well sooner or later ...
<sebner> it's the main -> universe problem
<pitti> well, it's not a technical bug in any way, we specifically don't want to support each and every package in the universe
<sebner> pitti: right, so what the long-term solution do you have in mind?
<pitti> sebner: keep a separate source, or fix the two packages in main which pull it in to depend on an alternative
<pitti> or drop to suggests
<ttx> pitti: about the Eucalyptus MIR process, I've started writing up MIR reports for a first set, see bug 405715. Please let me know if the way it's presented, the level of details etc. is OK and I should continue this way. For example, let me know if I should push reports to a wikipage instead.
<ubottu> Launchpad bug 405715 in qdox "Main Inclusion Report (Eucalyptus dependencies set 1)" [Undecided,New] https://launchpad.net/bugs/405715
<tseliot> pitti: what would be the best way to add a hal quirk? A separate package or adding it to hal would be better?
<pitti> ttx: looks okay; please note that it's enough to mention dependencies which are not in main
<pitti> tseliot: what kind of quirk?
<ttx> pitti: ok thx
<tseliot> pitti: for suspend/resume (for an OEM project)
<pitti> tseliot: suspend quirks for models should go into hal-info (I can commit them upstream)
<tseliot> pitti: ok, thanks, that's exactly what I needed to know :-)
<pitti> tseliot: send it to hal@lists.fd.o or to me, or to a bug report and sub me
<sebner> pitti: for karmic +1 I suppose?
<pitti> sebner: not particularly; it can happen whenever it's convenient
<sebner> heh, kk
<tseliot> pitti: I can't do this yet as I can't disclose the vendor's identity but I'll do it ASAP
<pitti> oh
<pitti> tseliot: right, just send it once it's possible, and keep it as a private patch until then
<tseliot> pitti: yes, the patch will live only in the OEM repos for now
<tjaalton> pitti: wrote a MIR for audit, it's holding xorg-server back, bug 406226
<ubottu> Launchpad bug 406226 in audit "promote audit to main" [Undecided,New] https://launchpad.net/bugs/406226
<pitti> Guest82317: I still know who you are!!!
<tjaalton> probably needs kees or someone to check it first
<NCommander> pitti, I continue to retry to regain my lost ID
<pitti> tjaalton: right, tossed to kees
<tjaalton> pitti: thanks
<robbiew> evand: welcome back to the world of the internets :)
<evand> thanks!
<pitti> hey evand
 * evand was starting to get the shakes
<evand> hi
<pitti> feeling lonely? :-)
<highvoltage> welcome back to the webs evand
<evand> haha, indeed
<evand> thanks highvoltage
<unggnu> hi all
<gnomefreak> .win 10
<unggnu> Is there a reason why the Firefox 3.5 package even in Karmic needs so many Gnome dependencies while the 3.0 not? There are probably many KDE users who want to install Firefox.
<unggnu> And Firefox 3.5 from the homepage even works fine without all this dependcies. Could somebody please fix this?
<gnomefreak> unggnu: not the pace for that question please join me in #ubuntu-mozillateam
<Timmy2Tall> i am trying to play world of warcraft on ubuntu but after i have installed it it wants to update but when i get to the terms and conditions it will not let me click accept. help plz
<directhex> Timmy2Tall, this is really the opposite of a "user support running wine" channel
<directhex> YokoZar, what's the wine users' channel?
<YokoZar> directhex: #winehq
<directhex> Timmy2Tall, ^^
<Timmy2Tall> Hey man lol
<maxb> Where, and after what duration of posting sensibly, may I apply for unmoderated posting on ubuntu-devel@ ?
<maxb> It's a bit awkward participating in a discussion when your responses don't hit the list for hours/days
<hyperair> maxb: i thought you were a MOTU. =O
<maxb> one day :-)
<hyperair> go get UUC-ship first then!
<hyperair> that'll effectively allow you to post without moderation
<maxb> I probably have (almost?) enough knowledge, what I lack is the skill at actually managing my time to get Ubuntu dev stuff done having been at work all day doing employee dev stuff
<kees> tjaalton: hah, funny, I was going to be writing the audit MIR since AppArmor needs it too now.  :P
<pitti> kees: so now you have the chance to "self" approve it :)
<kees> pitti: yup!  perfect.  :)
<kees> it should be pretty trivial, actually.  I just hadn't made time for it yet -- had it on the security team's sprint todo list.  :P
<tjaalton> kees: heh, great :)
<robbiew> cjwatson: doko: evand: james_w: Keybuk: liw: mvo: slangasek: al-maisan: mterry: FYI - No Meeting
<liw> robbiew, ack
<james_w> thanks
<mterry> yup
<doko> siesta ...
 * robbiew sent email, but knows not everyone checks their's every 5min like he does :P
<al-maisan> robbiew: thanks for letting me know!
<maxb> doko: Hi, did you see my question about default-jdk-builddep yesterday?
<maxb> < maxb> I'm trying to push a s/default-jdk-builddep/default-jdk/ change back to Debian and the maintainer is hesitant because no Debian Policy explains the purpose of these
<maxb> < maxb> Can you provide an authoritative Debian citation for the correct usage of default-jdk vs. default-jdk-builddep?
<doko> maxb: no, there's none. the one from the ubuntu wiki looks ok however
<mvo> robbiew: ok
<maxb> OK. I've pointed the maintainer in question at your java-gcj-compat-dev builddep mass bug filing, if that's not good enough I shall refer him to this irclog
<snadge> tried #ubuntu, google.. can only find old info on 64bit sun java.. it appears to be broken, applets not initializing .. jnlp failing to launch .. i have other 64bit ubuntu machines that i stuffed around with and cant remember how i got it to work.. opinions?
<snadge> i think it may have involved downloading it from sun and installing it manually
<ScottK> NCommander: More powerpc fun: https://launchpad.net/ubuntu/+source/dc-qt/0.2.0.alpha-4ubuntu2/+build/1139325/+files/buildlog_ubuntu-karmic-powerpc.dc-qt_0.2.0.alpha-4ubuntu2_CHROOTWAIT.txt.gz
<snadge> has anyone suggested the support channel for ubuntu be broken up into two channels.. #ubuntu-n00b or #ubuntu-idontknowhowtousegoogle and #ubuntu
<snadge> the signal to noise ratio in there is ridiculous
<Pici> snadge: There is a discussion about it currently on the Ubuntu IRC Council agenda as well as something ongoing on the ubuntu-irc mailing list.
<mathiaz> james_w: when you submit a merge proposal and you subscribe a specific person, it seems that no notification are sent
<mathiaz> james_w: ex: https://code.launchpad.net/~mathiaz/ubuntu/karmic/cim-schema/2.22.0-update/+merge/9397
<mathiaz> james_w: ttx didn't get notified by LP
<snadge> im only saying this because #ubuntu-devel is not a support channel.. i just thought someone knowledgeable on sun java on 64bit jaunty, would take pity on me and point me to something useful
<snadge> considering i have read the forums wikis.. the information is mostly outdated, and advocates manually installing it from sun.com
<ttx> mathiaz: or maybe it got eaten by a spamfilter, but that would be by the canonical one :)
<Tronic> snadge: It would have to be #ubuntu and #ubuntu-longtimers or something like that.
<Tronic> Newbies always come to #ubuntu.
<Pici> Anyway, a better place to discuss this would be in #ubuntu-irc, as -devel is really for development stuff
<ScottK> Tronic and snadge: This isn't the channel for Ubuntu IRC channel planning.
<snadge> thanks.. duly noted
<james_w> mathiaz: did you put ttx in the "reviewer" box?
<mathiaz> james_w: yes
<mbiebl> pitti: so your commits, thanks
<mbiebl> s/so/saw/
<mathiaz> james_w: regarding pywbem rejection, should the license use of "either" be fixed before a new upload?
<mathiaz> james_w: I've already corrected the other mistake (yacc.py is LGPL2 and not LGPL2+ in debian/copyright)
<james_w> mathiaz: I'm not sure
<james_w> I'll ask around
<mathiaz> james_w: ok - I've emailed the upstream authors to get a reponse from them.
<james_w> thanks
<vikram> Hi guys
<james_w> mathiaz: bug 406492
<ubottu> Launchpad bug 406492 in launchpad-code "Reviewer not subscribed to merge proposals" [Undecided,New] https://launchpad.net/bugs/406492
<vikram> How do I use this chat client
<vikram> please help
<alonswartz> question for mdz , mvo and anyone else knowledgable about apt pinning. I filed a bug on LP a while back and recently it manifested itself in a bad way in one of our systems. I was hoping someone could take a look http://bit.ly/10N2Ub
<james_w> mathiaz: upload and I'll accept
<mathiaz> james_w: new version of pywbem uploaded
<james_w> thanks
<maxb> alonswartz: bizarre, must be a bug deep in the guts of apr
<maxb> * apt
<alonswartz> maxb: yeah, i know - very weird. What would be the best way to get this confirmed and on its way to being solved?
<maxb> Well, confirming it is easy. (I just did). Solving it requires someone to actually dig deep into the apt sourcecode.
<maxb> You might like to upstream it to debian
<alonswartz> maxb: what version of apt are you using?
<maxb> I'm on karmic
<maxb> !info apt
<ubottu> apt (source: apt): Advanced front-end for dpkg. In component main, is important. Version 0.7.20.2ubuntu6 (jaunty), package size 1620 kB, installed size 5232 kB
<alonswartz> maxb: just saw you updated the bug report, thanks!
<maxb> !info apt karmic
<ubottu> apt (source: apt): Advanced front-end for dpkg. In component main, is important. Version 0.7.21ubuntu1 (karmic), package size 1623 kB, installed size 5196 kB
<maxb> Well that's interesting. apt-get may want to downgrade, but aptitude doesn't
<alonswartz> maxb: the plot thickens...
<maxb> Not particularly, apt-get and aptitude don't share 100% of the package management code
<alonswartz> I suppose that might help in narrowing it down (I'm not familiar with the apt code)
<james_w> chrisccoulson: hey, did you speak to the Debian maintainer about libgdamm4.0?
<chrisccoulson> james_w - not yet. it's on my list of things to do
<james_w> chrisccoulson: them not renaming in the same way, but I don't think it would be a killer would it?
<chrisccoulson> they should rename it in the same way shouldn't they?
<james_w> I assume so
<chrisccoulson> i can contact the debian maintainer still. i only started working on updating that last night because another update i'm doing needs it
<mathiaz> james_w: could you bump up the priority of sblim-cmpi-base pkg import?
<james_w> done
<mathiaz> james_w: thank you :)
<sroecker> hi, any jockey experts around?
<mathiaz> Using cdbs, how can I rename usr/share/sblim-cmpi-base/provider-regiser.sh (as installed by upstream) to usr/bin/cmpi-provider-register (as I want it in the final debian package)?
<ebroder> You have to add something to the debian/rules file
<ebroder> I usually use binary-install/PACKAGE_NAME::, I think
<ebroder> So do something like...
<ebroder> binary-install/PACKAGE::
<ebroder>         mv $(DEB_DESTDIR)/usr/share/sblim-cmpi-base/provider-regiser.sh $(DEB_DESTDIR)/usr/bin/cmpi-provider-register
<mathiaz> ebroder: awesome - thanks! I use install/PACKAGE instead of binary-install
<mathiaz> ebroder: it worked out well in the end :)
<ebroder> install should be fine - just be sure to put it after you include your cdbs classes
<kirkland> does anyone know why python-pysqlite2 might have dropped from main to universe?
<kirkland> looks like landscape-common is depending on it now, which would necessitate bringing it back into main
<kirkland> i'm wondering if i need an MIR to do this
<ScottK> kirkland: Generally if it was in Main before you don't need a full MIR.
<kirkland> ScottK: cool
<ScottK> kirkland: Is there a *pysqlite3 in Main?
<ScottK> There might be some resistance to supporting multiple versions.
<mathiaz> ScottK: I don't think there is a pysqlite3
<kirkland> python-sqlite - python interface to SQLite 2
<ScottK> OK.
<kirkland> python-pysqlite2 - Python interface to SQLite 3
 * kirkland finds those descriptions confusing :-)
<kirkland> both in universe
<ebroder> kirkland: SQLite 3 support is built-in to Python >=2.5, isn't it?
<mathiaz> ScottK: now that sqlite3 is in the standard library pysqlite doesn't need to exist anymore.
<ScottK> ebroder: I think that's right.
<TheMuso> /c/c
<kirkland> siretart: ping
<kirkland> siretart: would you please merge byobu-2.23 into Debian when you get a chance?
<ebroder> Is there a relatively easy way to figure out how the debian-installer does a particular step? Say, installing grub?
<ebroder> I guess I go hunting for udebs?
#ubuntu-devel 2009-07-30
<ion> org.freedesktop.PowerManagement.Backlight.SetBrightness has disappeared :-(
<ion> Ah, it has been renamed as org.gnome.PowerManager.Backlight.SetBrightness
<ebroder> Any backporters who could look at bug #406680?
<ubottu> Launchpad bug 406680 in hardy-backports "Please backport protobuf 2.0.3-2.2ubuntu1 from Karmic to Hardy, Intrepid, and Jaunty" [Undecided,New] https://launchpad.net/bugs/406680
<meunierd> exit
<dtchen> hyperair: yes, the flatvol implementation in 0.9.15 is ... interesting (and intentional). it has been tweaked in 0.9.16(-test3).
<dtchen> billybigrigger: unlikely pong
<billybigrigger> dtchen, hehe, vacation?
<billybigrigger> you must have a nice scrollback set that was days ago
<dtchen> billybigrigger: no, traveling for work
<billybigrigger> nice
<ScottK> ebroder: Commented.
<billybigrigger> well i think my question was something to do with pulse the other day
<billybigrigger> i don't really remember the problem anymore, i think changing tsched=1 in default.pa fixed some problems
<dtchen> billybigrigger: ok, well, the latest pulse upload in karmic has that set anyhow.
<dtchen> (thanks, TheMuso!)
<billybigrigger> oh, i remember now, everytime any audio player, or media player for that matter, changed to the next song/video, the application volume reset itself to mute or 0% in the new sound preferences
<billybigrigger> and a weird volume issue where the next song would be %100, then %118 140 160 etc...
<billybigrigger> but that seemed to have stopped too
<billybigrigger> so all is good with the new update i guess
<billybigrigger> keep up the great work guys, pulse seems to be coming along quite nicely, at least from a user perspective
<billybigrigger> i don't know how it goes on the other end :P
<ion> billybigrigger: One doesnât need a huge scrollback, just a functional awaylog. :-)
<ebroder> ScottK: For libcompizconfig, do I need to test that it still builds against the new protobuf?
<ebroder> Or just that the current one runs with the new libprotobuf3?
<hile> anyone noticed that firefox internal window cancel,ok buttons in karmic are reversed compared to gnome defaults? i.e. ok,cancel vs. cancel,ok
<hile> very, very confusing when open,print,save are coming from gnome and are in the 'normal' gnome order
<hile> I was downloading a file, press the usual button and wondered why nothing happened, then actually read the button 'oh it's cancel not ok in right lower corner'
<ion> themuso: I posted https://bugs.edge.launchpad.net/ubuntu/+source/rtkit/+bug/406702
<ubottu> Launchpad bug 406702 in rtkit "Failed to make ourselves RT: Invalid argument" [Undecided,New]
<TheMuso> ion: Yes, the kernel does not yet have the bits needed yet.
<TheMuso> ion: I hope to push the needed kernel aptches to the kernel team shortly.
<ion> themuso: Ah, ok. Should i change it to affect linux instead of rtkit?
<TheMuso> ion: Please, and assign it to me if you will.
<ion> themuso: Done
<TheMuso> ion: thanks
<ScottK> ebroder: I see you covered both cases.  That it runs.  If it didn't run, but would run after a rebuild, then we'd have to backport that too.
 * ebroder nods
<ScottK> ebroder: I did just approve the backport.  Up to a Canonical archive admin now.
<ebroder> Yeah, I saw. Thanks a lot
<ScottK> No problem.
<hyperair> dtchen: tweaked how?
<dtchen> hyperair: it's known as reference volumes; see commit fe8b10cc05b3b8e8633ffaff30e73a40a30c8bf8 and http://pulseaudio.org/wiki/InternalVolumes
<hyperair> hmm i'll take a look, thanks
<ebroder> Any recommendations for tools to create a partial mirror of an apt repo (e.g. just grab jaunty)?
<pitti> Good morning
<pitti> ebroder: use debmirror, it's magic
<ebroder> pitti: I'll take a look
<pitti> ebroder: that can filter by release, component, sections, and just about anything else
<TheMuso> Seems we have non-installable alternates. Went to do a fresh install on my notebook today before the sprint, and found that grub-pc is uninstallable, as well as an -en langpack. Yay! :)
<pitti> ebroder: you can also do things like exclude *-dev or *-doc
<ebroder> pitti: Awesome. That looks like exactly what I want
<ion> bryce: Does it look like karmic will get radeon KMS?
<hyperair> dtchen: in that case, wouldn't it be a good idea to have gsd change the reference volume as well, similar to scrolling on the volume control applet?
<hyperair> dtchen: it gets rather confusing if you use both
<hyperair> hmm no wait, it seems to use that already
<hyperair> nevermind, i'm just outdated
<hyperair> dtchen: is there some way to change this volume using the command line?
<\sh> ebroder: check http://www.sourcecode.de/content/ubuntu-mirror-what-if-i-need-it-easy <- those are my magic debmirror scripts
<\sh> I should push those shell snippets into an LP bzr repo..in the meantime those scripts evolved
<lool> ScottK: Thanks I see that libio-compress-perl is upgradeable now; probably some bits are still in universe but at least its insallable again
<evand> ScottK: Just a heads up: usb-creator for Windows didn't make it on today's kubuntu-netbook daily-live because there was an error in my changes to the cdimage build scripts.  I've fixed the problem and the next spin of kubuntu-netbook should have it.
<ojwb> mvo: I've uploaded 1.0.14-1 packages for xapian-* to debian unstable, with the include-links thing
<mvo> ojwb: oh, nice! I will sync/merge it into karmic, thanks a lot!
<ojwb> mvo: cool - also if you want to test the value update optimisation patch, that'd be great
<mvo> ojwb: thanks, I will give it a go - we do not yet use the values that much in apt-xapian-index, but I expect that is going to change :)
<mvo> ojwb: my feeling is we are still (by far) not using all the portential of xapian, I'm constantly impressed by it (I'm porting gnome-app-install to use it as its backend database currently)
<mvo> potential even
 * mvo makes too many typos
<ojwb> yeah, there are a growing number of neat features
<ojwb> .-
<ojwb> oops
<pitti> mvo: hm, apt-get source --only-source linux still doesn't give me what I want
<pitti> mvo: isn't --only-source meant to do that?
<mvo> pitti: you want linux-image and not linux-meta?
<pitti> yes
<pitti> it's as if --only-source did nothing
<pitti> I want the "linux" source package
<mvo> pitti: hm, that looks like the binary-name vs source-name problem came back, I have a look
 * mvo adds it to his gtg
<pitti> mvo: want a bug for that?
<mvo> pitti: I don't think its needed, I added it to my todo list for today
 * pitti hugs mvo, thanks! (not that urgent, though)
<pitti> I just wondered if I misunderstood --only-source or so
<mvo> pitti: its supposed to work like you expected it to work, probably a bug somewhere
<pitti> *nnng* need python 2.6 in sid
<pitti> doko: ^ any plan when that happens?
<doko> gcc-4.4 and openjdk-6 first ...
<pitti> ah, ok
<ScottK> evand1: Thanks.
<ScottK> lool: re: libio-compress-perl and the MIR paperwork is in progress too.
<pitti> doko: one question, even if I b-dep on python2.6-dev and set "XS-Python-Version: 2.6", the dependency ends up as python (>= 2.6)
<pitti> doko: this won't work in debian experimental, thouhg, since python-defaults still points to 2.5
<pitti> doko: is there a way to force the usage of 2.6 in dependencies, etc.? is there some magic to update the hashbang lines accordingly?
<doko> pitti: no, needs to be done manually
<pitti> ok
<slytherin> RainCT: nhandler: Is it possible to add a 'dateofupdate' field to revu DB. The purpose of the field will be to keep track of last updated date of the package (dateofupload will contain date of first upload). We can then sort the list on main page with dateofupdate. Will help in tracking which packager is more responsive to the comments.
<Keybuk> why are all my logins so slow now?
<seb128> Keybuk, define login?
<Keybuk> logins
<Keybuk> err
<Keybuk> ssh, console, that kind of thing
<jpds> Keybuk: Use encrypted ~/Private?
<Keybuk> npe
<Ng> hey look at that, console logins are slow. disabling pam_motd.so from pam.d/login helps some
<Keybuk> yes, I was wondering whether I was having a _personal_ MOTD generated just for me
<ogra> do you have your sound on ? it might try to talk to you with a hal'ish voice "hello dave^Wscott"
<Ng> Keybuk: looking at the code I don't think it does do that, or at least that module doesn't
 * Ng sighs, I just fail at getting the right source and reading it, apparently. it does run-parts /etc/update-motd.d/
<Ng> quite how apt-get source failed to show me that, I don't know
<RainCT> slytherin: there's no need to add such a field, you can just do a subquery
<RainCT> slytherin: something like   (SELECT dateOfUpload FROM Upload WHERE sid=X ORDER BY dateOfUpload DESC LIMIT 1) AS dateOfUpdate
<slytherin> oh
<slytherin> I didn't think that was possible. I am not yet completely familiar with DB structure.
<RainCT> slytherin: don't subestimate SQL ;)
<mvo> pitti: the apt-get source --only-source issue should be fixed in bzr now
<tgpraveen> has it been decided which bluetooth stack software will be used?is it blueman?
<slytherin> tgpraveen: Latest gnome-bluetooth (which is now fork of bluez-gnome) seems to have same functionality. So it is more like candidate. But I am not the maintainer of bluetooth stack, so I don't know for sure.
<dpm> pitti: hi, I've been working with Riddell to fix bug 376686. We've got a fix now and it's sitting in the unapproved -proposed queue. May I ask you to approve it?
<ubottu> Launchpad bug 376686 in kde-l10n-eu "Errors in KDE4 basque translation - Cyrillic characters and wrong names" [Undecided,In progress] https://launchpad.net/bugs/376686
<Keybuk> pitti: how did you force gdm to start X on vt7?
<Keybuk> and is there a way to override that?
<seb128> Keybuk, he did code changes to use -vt7
<seb128> -        res = gdm_server_spawn (server, NULL);
<seb128> +        res = gdm_server_spawn (server, (f > 0) ? "vt7" : NULL);
<lool> cjwatson: pokely
<ogra> heh, good luck
<lool> cjwatson: Your latest usplash change exposes crashes in usplash
<lool> ogra: He's on leave?
<ogra> debconf
<lool> Ah I thought it was over
 * lool sucks
<ogra> and you are even DD :)
<slytherin> any of the archive admins free enough to review and approve jakarta-jmeter source from NEW queue?
<gilesw> heya all
<mathiaz> james_w: hey
<mathiaz> james_w: regarding https://code.launchpad.net/~mathiaz/ubuntu/karmic/cim-schema/2.22.0-update/+merge/9397
<mathiaz> james_w: ttx approved the review
<mathiaz> james_w: and I just uploaded the new package to the archive. What should I do with the merge request?
<mathiaz> james_w: IIUC I cannot commit it to the lp:ubuntu/karmic/cim-schema/ branch. Should I just delete it?
<james_w> mathiaz: you will have to mark it as merged for now
<mathiaz> james_w: great thanks.
<james_w> you will be able to push soon, which will do that automatically
<mathiaz> james_w: regarding sblim-cmpi-base is it still in the import queue?
<mathiaz> james_w: https://code.launchpad.net/ubuntu/+source/sblim-cmpi-base/ is almost empty
<mathiaz> james_w: except for my own branch.
<james_w> mathiaz: good question
<james_w> mathiaz: I can't work out now
<james_w> mathiaz: fixed, should be up soon, thanks for reporting
<mathiaz> james_w: thanks. Does the fact that I've already created my own branch be a problem for the import?
<mathiaz> james_w: thanks. Does the fact that I've already *pushed* my own branch be a problem for the import?
<james_w> mathiaz: nope
<james_w> though it will completely ignore your branch :-)
<mathiaz> james_w: my own branch will just overwritten?
<james_w> if that's not the right thing then we should talk
<mathiaz> james_w: that's ok.
<james_w> nope, your branch is ~mathiaz isn't it?
<mathiaz> james_w: yes. ~mathiaz/ubuntu/karmic/sblim-cmpi-base
<mathiaz> james_w: I was thinking about the stacked branch format for the repository
<mathiaz> james_w: as this is what I'm using locally (bzr init-repo --2a)
<james_w> mathiaz: ah, yeah, it won't stack
<james_w> that's only an optimization though
<mathiaz> james_w: is bzr-loom still developed?
<james_w> vaguely
<james_w> lifeless merges packages
<james_w> patches I mean
<james_w> but doesn't actively develop at the moment
<james_w> he says that he still plans to
<mathiaz> james_w: ok - I've got a branch (openldap) that uses looms
<james_w> nice
<mathiaz> james_w: to maintain different patches that I wanna send to debian
<mathiaz> james_w: but my local version of bzr-loom doesn't seem to work with bzr 1.17
<james_w> we can have a look next week if you like?
<mathiaz> james_w: which branch of bzr-loom should I look at (lp:bzr-loom)?
<james_w> I assume so
<mathiaz> james_w: ok - it seems to work now :)
<bryce> ion, hopefully
<ebroder> Hmm...anybody have a ballpark estimate of how much space a mirror of jaunty{,-security,-updates} takes up?
<liw> a few tens of gigs
<liw> there should be a tool for computing that, somewhere, I'm sure of it
<ebroder> including source packages?
<liw> I think so
<ebroder> Cool. I should have that much disk space. Let's see how this goes
<liw> there's probably a statistics page somewhere
<ebroder> https://help.ubuntu.com/community/Debmirror has some old ballpark estimates
<ebroder> For a single architecture
<ssam> has the osmium builder got stuck? it should not take 24hours to compile a small package
<geser> ssam: better ask in #launchpad
<ssam> geser, thanks
<seb128> mathiaz, hello
<mathiaz> seb128: hey
<lifeless> mathiaz: james_w: I'd love to spend a week on just on loom, not on the immediate cards I'm afraid; however bugs will get fixed - just be sure to file em ;)
<mathiaz> lifeless: how is loom related with pipes?
<lifeless> theres some significant overlap in the use cases they want to solve
<lifeless> they take a significantly different internal approach to the problem
<mathiaz> lifeless: right - the user experience seem to be the same though.
<lifeless> mathiaz: the main difference is that a pipeline is a set of full branches; there isn't any versioning about that set
<lifeless> loom is a version set of lighter-than-normal branches
<mathiaz> lifeless: so there isn't an equivalent of record in the pipeline plugin?
<lifeless> correct
<d_ed> hey, if I have a source package that creates multiple packages (i.e kdepim creates kmail, organizer, etc...) is there a way I can tell debian/rules that I only want to build one of them?
<ebroder> In general, no
<ebroder> You have to assume that the products of a single build stage are being spread across a bunch of binaries
<d_ed> ok. that's a good enough answer as ever
<ebroder> And the rules file isn't usually clever enough to separate that single build stage into the individual stages that make up each binary package
<d_ed> yeah, I got that impression. There were a bunch of filenames that seemed to be a list of what to put where after doing a build
<d_ed> ta anyway
<LordMetroid> Is the upcomming Ubuntu based on Lenny?
<LordMetroid> I suppose so, right?
<directhex> LordMetroid, all ubuntu releases are based on a snapshot of sid
<LordMetroid> Ohh, I see
<pgraner> bryce: ping
<bryce> pgraner, yep
<pgraner> bryce: quick question, I just got a SDP from Intel with 2 G92 Nvidia cards. I have two monitors and wanted to run both at the same time, is there any X magic to get both cards working at the same time?
<bryce> pgraner, you'll need to use the proprietary drivers and use their config tools to set it up
<pgraner> bryce: :-(
<pgraner> bryce: ok, I'll give it a whirl then ...
 * pgraner notes that its complete suckage that way
<bryce> pgraner, X on the foss side doesn't support multiple video cards yet
<bryce> if you can hook both of the monitors to a single card, and leave the other card disabled, you may have luck using -nouveau
<pgraner> bryce: naw they both only have one port
<bryce> yeah then you're sol, sorry
<pgraner> bryce: thanks for the advice
<bryce> pgraner, a dual-output 5xx-class ATI card is cheap and would definitely do it....
<pgraner> bryce: good to know. I have 2x 30" monitors and would like a good 3d card that can drive both
<bryce> yeah I have a RV535 [Radeon X1650 Series]  with a pair of 30" screens here I use day to day.  No probs, can use compiz, 3d, dual-head with max res of 3840 x 1200, fully open source drivers and all
<pgraner> bryce: sweet, I need to get that card.
 * pgraner runs off to ebay
<pgraner> bryce: I was trying to make what Intel sent work, however the proprietary drivers are acting funky
<infinity> pgraner: So, you have some nvidia cards you need to get rid of, then? :P
<pgraner> infinity: I wish, Intel will want them back in the end :-(
#ubuntu-devel 2009-07-31
<Riddell> asac: where can I find the licencing information  on the firefox icon?
<DGMurdockIII> hi
<TheMuso> c/c
<slytherin> Any of the archive admins free enough to review jakarta-jmeter from new queue?
<seb128> slytherin, any reason it's urgent?
<seb128> slytherin, that's the second time you ask on IRC, any reason it should hijack things waiting for longer in the queue?
<slytherin> No. Nothing in particular. Sorry.
<seb128> ok, so no need to ping people for regular tasks, they are done often enough usually
<seb128> and no need to be sorry that's ok, that's just that people know about those and if they don't do it that's because they are busy or on holidays, etc
<slytherin> Ok.
<directhex> <meebey> Subject: mono_2.4.2.3+dfsg-1_i386.changes is NEW
<seb128> directhex, cool!
<directhex> seb128, includes a few little patches too, which ought to allow some more interesting things to run (e.g. ironruby). also includes the fixes to stop needless libmono0 inclusion on the CDs
<seb128> directhex, are you going to prepare an upload for karmic? ;-)
<directhex> seb128, i don't think binary NEW is too slow at the moment in debian, so i'd rather wait & sync (saves a layer of archive admin time, if anything, getting ftpmaster to check instead). i have a month before i need to do that icky FFe paperwork anyway
<seb128> ok
<dmentre> Hello. Could a core developer look at bug 406351 and bug 406434? Simple synchronizations are needed. These packages are blocking the remaining of the OCaml transition. Thanks!
<ubottu> Launchpad bug 406351 in ocaml-batteries "[3.11.1 transition][round 5/6] Please synchronize following packages from Debian sid in Karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/406351
<ubottu> Launchpad bug 406434 in ocaml-libvirt "[3.11.1 transition][round 5/6] Please synchronize source package ocaml-libvirt from Debian sid in Karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/406434
<directhex> dmentre, you scared seb128 away
<asac> Riddell: what do you want to know wrt licensing?
<Riddell> asac: what is the licence and are you allowed to make derivative works
<Riddell> asac: a package included a derived icon and I don't know if that's allowed
<asac> Riddell: its proprietary. you are not allowed to change it
<Riddell> asac: that probably makes most of these illegal doesn't it? http://packages.ubuntu.com/search?searchon=contents&keywords=firefox.png&mode=exactfilename&suite=karmic&arch=any
<pitti> Good moring
<pitti> mvo: yay you!
<pitti> dpm: will try (I'm officially off sick, but I think I can do an hour or two)
<dpm> pitti: hey, good morning. Thanks a lot, but don't worry about it! I'll just poke you once you're healthy again, don't do it if you're not feeling well
<tkamppeter> pitti: Should bug 372118 get SRUed?
<ubottu> Launchpad bug 372118 in cups "CUPS does not work with Firefox, HTTPS bug (Hardy LTS)" [Undecided,Confirmed] https://launchpad.net/bugs/372118
<dmentre> directhex: (about scaring seb128 away) nope! ;-)
<TheMuso> .deb
<TheMuso> woops
<pitti> tkamppeter: I'm fine with getting this SRUed; want to prepare an update?
 * pitti crawls back to bed, cu next week
<dpm> pitti: see you next week, get well soon!
<pitti> thanks!
<tkamppeter> pitti, will you be on the sprint?
<dvh> Hi, can somebody explain why Hugin depends on autopano-shift instead of autopano-shift-c? Why do I need 50MB of redundant C# libraries only because of this? Thanks
<gaspa> dvh: i recall a bug about that, but not sure.
<gaspa> dvh: uhm. can't find any package with that name...
<dvh> hold on
<dvh> autopano-sift-c                                   2.5.0-0.0
<dvh> so it's sift, not shift
<ion> There seems to be no autopano-sift-c in Ubuntu repositories. (Which is a shame.)
<gaspa> seems it needs to be packages.
<gaspa> *packaged
<gaspa> dvh: you could request it by filing a bug in launchpad. (or package it by yourself. :P)
<gaspa> ah, found: https://bugs.edge.launchpad.net/ubuntu/+source/hugin/+bug/323836
<ubottu> Launchpad bug 323836 in hugin "[needs packaging] Package and use autopano-sift-c" [Wishlist,New]
<Tronic> Could someone handle this? https://bugs.launchpad.net/ubuntu/+source/performous/+bug/406866
<ubottu> Launchpad bug 406866 in performous "request sync performous from unstable" [Undecided,New]
<cjwatson> pam: nothing other than the documentation in the gfxboot package itself
<cjwatson> pam: I think for editing arrays in ways other than just changing a single element in-place, it's usually easiest to effectively define a new array with the contents you want
<cjwatson> maxb: I've added you to the manual accept filter on ubuntu-devel@
<cjwatson> ebroder: there's a Debian paper on how the installer works linked from http://wiki.ubuntu.com/Installer/Development, which may be useful for orientation. (In this case the component you're looking for is grub-installer.)
<cjwatson> lool: usplash> really? it didn't actually change very much ...
<lool> cjwatson: I don't understand why your change triggers the crashes because I didn't understand where xres / yres are set in a regular boot (I think they are set from /proc/cmdline but I don't see why these would be set on end-users' boxes)
<lool> cjwatson: But we only received reports from the karmic version, not the jaunty one
<lool> cjwatson: In all cases your change is correct; it's just unfortunate that it shows that our theme and usplash are buggy
<lool> cjwatson: https://bugs.launchpad.net/bugs/401432
<ubottu> Launchpad bug 401432 in usplash-theme-ubuntu "usplash crashed with SIGSEGV in memset_var()" [Medium,In progress]
<lool> I started adding bound checking to some usplash code pathes but I'm not happy with the changes and I find it painful to debug (assert() leave the console broked and printf are a bit manual)
<lool> Also ubuntu-vm-builder is broken so I couldn't create vms for easy testing of various resolutions
<cjwatson> lool: xres/yres are in usplash.conf and sucked out of X in the postinst
<Riddell> james_w, slangasek: what's the status  of bug 400102? it looks like it was waiting on a patch being tested but now that patch has been tested
<ubottu> Launchpad bug 400102 in libaqbanking "Please sync libaqbanking 4.1.0-2 (universe) from Debian unstable (main)." [Unknown,Fix released] https://launchpad.net/bugs/400102
<evand> pitti: thanks for the review on pywebkitgtk
<james_w> Riddell: I haven't looked at it recently
<james_w> Riddell: but it seems to me that if it needs a patch then it's not a sync?
<Riddell> james_w: the patch is for qbankmanager which is an rdepends (presumably)
<james_w> ah, then I misunderstood
<Riddell> oh, no it's not
<Riddell> you're right james_w it's a patch to libaqbanking
<seb128> does anybody has an idea what component to blame on #407209?
<seb128> does anybody has an idea what component to blame on #407209?
<seb128> ups
<seb128> bug #407209
<ubottu> Launchpad bug 407209 in update-manager "Reboot after update results in "running in low-graphics mode"" [Undecided,New] https://launchpad.net/bugs/407209
<seb128> basically psb driver error after jaunty linux upgrade
<seb128> seems bug #406651
<ubottu> Launchpad bug 406651 in xserver-xorg-video-psb "2.6.28-14 kills PSB driver on Dell Mini 10 & Acer One 751h" [Undecided,New] https://launchpad.net/bugs/406651
<seb128> ^ that's a breakage due to a stable update, anything which should be done to mark those?
<tseliot> seb128: psb is not officially supported on Jaunty. Those users installed it from a PPA. Maybe DKMS didn't rebuild the kernel module against the new kernel
<seb128> tseliot, ok thanks
<slytherin> We should ask users about dkms log instead and check if it failed to build.
<tseliot> cjwatson: what's the proper way to add kernel parameters to the kopt line of GRUB's menu.lst in the installer?
<tseliot> seb128: np
<tseliot> slytherin: right
<seb128> mvo, what is the canonical source for SimpleGtkbuilderApp?
<pam> cjwatson: thanks, I actually sort of found a working solution (but the implementation is suboptimal so far).
<cjwatson> tseliot: boot the installer with those extra parameters after the "--"
<garymc> Yo Hi I need some help
<garymc> Ive got a Dedicated server with fasthosts
<garymc> I need to get my Mysql databse copied to my computer how di I do it
<garymc> I know its running ubuntu
<garymc> cos i aint used it for a while ive lost and forgot the commands to use in putty
<tseliot> cjwatson: I would like those parameters to be permanently set in the installed system. Would modifying the boot entries in the installer do that too?
 * tseliot admits that his question could have been a bit clearer
<cjwatson> tseliot: yes
<tseliot> cjwatson: ok, thanks
<cjwatson> tseliot: anything after -- gets copied to the installed system, with the exception of a few special cases that are filtered out (basically stuff that's installer-specific, or in a few cases just stuff that's a bad idea to propagate)
<tseliot> cjwatson: ok, I only need to pass different parameters for vga and console
<cjwatson> vga is one of the things that's filtered out
<cjwatson> because vga= at least used to break suspend/resume
<tseliot> d'oh
<cjwatson> you'll have to frob it in preseed/late_command if you really really want to set that
<tseliot> cjwatson: ok, I'll look into that, thanks again
<maco> cjwatson: is THAT why i couldnt use framebuffer before?
<cjwatson> vga= shouldn't be necessary for framebuffer
<cjwatson> did anyone ever manage to test https://launchpad.net/~cjwatson/+archive/ia32-libs-testing ?
<cjwatson> when I first published that stuff it had some installability problems
<maco> cjwatson: eh was the only way i knew to set the framebuffer mode
<cjwatson> oh, sure, if you want to *tweak* the framebuffer ...
<cjwatson> anyway, hopefully kms will make all this stuff unnecessary
<ogra> if you have a card that supports it :)
<blackxored> hello again folks
<maco> it has indeed, for me
<ScottK> jdstrand: boost1.37 can die if you're interested (I gather it's your archive day): Bug #407388
<ubottu> Launchpad bug 407388 in boost1.37 "Please remove boost1.37 source and all binaries from Karmic" [Medium,Confirmed] https://launchpad.net/bugs/407388
<ScottK> BTW, the scheduled execution date for boost1.35 is next week.
<mathiaz> james_w: hey - has the import of debian packages stopped in pkg branches?
<mathiaz> james_w: https://code.edge.launchpad.net/debian/sid/+source/openldap is not up-to-date
<pitti> tkamppeter: I'll most likely be at the sprint, yes
<apw> pitti, any idea how one gets devkit-disks to allow you to mount a specific disk with specific options?
<LaserJock> is devicekit really meant to be removed?
<arand> I'd like to request an SRU for Bug #316502
<ubottu> Launchpad bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released] https://launchpad.net/bugs/316502
<LaserJock> arand: man I hate that bug
<arand> LaserJock: Indeed, that was why I did make the effort to patch it ;)
<LaserJock> arand: so the bug is actually in goffice and not gnumeric?
<arand> LaserJock: well, it's libgoffice that is patched so yes, I guess... There was a comment on no necessity of adding goffice since it was contained in gnumeric, so I just went by that and left libgoffice as "invalid" witout arguing.'
<LaserJock> I think that's wrong, goffice is a separate source package
<arand> But goffice is a separate package, so I'd personally say that'd be more correct... yea, exactly.
<LaserJock> if the code that needs to be patched is in goffice then I think the bug should be against goffice
<LaserJock> wow, that's a tiny patch too
<arand> LaserJock: yes, it was a really nice one.
<Ng> LaserJock: the changelogs for devicekit{,-power} suggest that it is supposed to be removed
<LaserJock> Ng: k, thanks
<Ng> LaserJock: the Ng Corporation accepts no liability for your system breaking into many pieces ;)
<LaserJock> heh
<Ng> (I did the upgrade on mine and things are mostly holding together, seems to be some g-p-m oddness, but I've not had a chance to figure it out well enough to file a bug)
<jpds> http://paste.ubuntu.com/239705/
<arand> LaserJock: could you set a medium importance on the goffice part of the bug? I don't have permissions
<jpds> Ng, LaserJock: ^^
<Ng> jpds: aha
<LaserJock> arand: ok, reload bug #316502 and see if that looks right
<ubottu> Launchpad bug 316502 in gnumeric "cannot release a graph in gnumeric after click and drag" [Medium,Fix released] https://launchpad.net/bugs/316502
<arand> LaserJock: Thanks, that looks nice.
 * ccheney thinks we should have a UDS in Madrid, its a very nice city :) just went on a 4 hr sightseeing tour before my flight home from debconf
<arand> Now, is there anything else to do on my side, or do I just wait for the SRU team now?
<ccheney> er 'tour' being me with a map, heh
<LaserJock> arand: you need a Core Dev to sponsor the patch
<LaserJock> arand: could you fix up the bug description a little to follow point 2 on https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<arand> LaserJock: Ok, I'll see to it. For finding a dev, is that the devel mailing list, or should I go to the ubuntu maintainer(s) fro goffice?
<LaserJock> arand: I can do it if you like. That bug really annoys me :-)
<LaserJock> plus, I just got my PhD so what better way to celebrate but helping squash some nasty bugs :-)
<arand> LaserJock: Yea, that'd be nice: and...Congratulations!
<ScottK> LaserJock: Congratulations.
<LaserJock> ScottK: thanks
<LaserJock> it was a 2.5 hr defense but in the end it really wasn't that bad
<ScottK> So it's Doctor LaserJock now.
<LaserJock> yep
<LaserJock> took me 11 years but I'm finally finished
<LaserJock> no more school for me!
<arand> Doctor LaserJock: Must be great :) ...  Hum, thing is, I'm not sure what more to write in the "addressed-how?" than basically copying the upstream changelog entry...
<LaserJock> that works
<arand> ok done.
<LaserJock> ok, let me tweak something real quick there
<LaserJock> arand: ok, done. I just wanted to make it more clear that the bug is in goffice but manifests in gnumeric
<arand> Doctor LaserJock: It's kinda my first ever patch so
<LaserJock> awesome
<arand> Doctor LaserJock: :) Problem is , feels like I'm screaming for help at every step :/
<arand> Doctor LaserJock: Okay, so you're taking the contact to core devs then?
<LaserJock> arand: well, it so happens that I am a Core Dev
<LaserJock> arand: so I'm just getting the upload ready to go. Doing my own build and test
<arand> Doctor LaserJock: How convenient :) Thanks again.
<LaserJock> arand: no, thank you for following up on the bug, finding the patch, and putting together a debdiff
<LaserJock> arand: I'm just gonna tweak the version number and changelog entry slightly to conform to policy better
<arand> LaserJock: Yea, I was kinda guessing there, and hoped it would at least be informative...
<phurl> hi all. I am frustrated to get ubuntu to install from a debian busybox live usb. It just does not work!
<phurl> there are no loopback devices loaded.
<phurl> anyone use unetbootin?
<lool> cjwatson: Odd my laptop doesn't have xres and yres in usplash.conf; that might be why I was wondering how these are set; I do see these on my desktop
<lool> cjwatson: Thanks for the info
<LaserJock> arand: ok, I've uploaded your patch to intrepid-proposed and jaunty-proposed
<LaserJock> arand: next step is for an admin to accept them and then get the testing feedback
<arand> LaserJock: *smiles*
<ogra> lool, mine has them explicitly commented but usplash doesnt break over here
<ogra> LaserJock, hey Doc :)
<ogra> LaserJock, congrats
<lool> ogra: The breakage happens on < 600 pixels height
<lool> or < 640 rather
<LaserJock> ogra: thanks, it's been a long road
<ogra> yeah
<ogra> lool, so it does break for you and you have a value below 600 for y ?
<orogor> hi here, i got some troubles with a remote and lirc apparently that s lioked to the fact that it s incorectly being registred as a kbd device
<orogor> i saw a bug open for that , apparently the fix is already included in the version i use but i still have troubles
<lool> ogra: It does not break for me
<ogra> ah
<ogra> but for people with an actual value below 600
 * ogra understands
<knoob> Hello. I'm trying to upgrade a remote machine from 7.04 to the latest. The tutorial online works up to the last point at which I get a 404 Not Found error. This is for Packages.gz and Sources.gz. Any help is appreciated
<mathiaz> knoob: 7.04 is end-of-lifed - see https://help.ubuntu.com/community/EOLUpgrades for an upgrade process.
<knoob> mathiaz: that's the tutorial that i'm talking about
<knoob> when I run ./gutsy it does stuff for a while, then quits out on two 404 errors
<knoob> can I paste the error here?
<mathiaz> knoob: it's probably because gusty is also end-of-lifed
<mathiaz> knoob: look at the section about edgy->feisty upgrade
<mathiaz> knoob: and you'll to adapt it to do a feisty->gutsy upgrade
<knoob> ok i'll read that, thank you
<mathiaz> knoob: the 404 error is because the gutsy script is trying to use archive.ubuntu.com to retrieve the Packages.gz and Sources.gz.
<mathiaz> knoob: since gutsy is EOL, it has been moved to old-releases.ubuntu.com
<knoob> no it's trying tog et http://free.linux.hp.com/~brett ... etc
<mathiaz> knoob: thus the gutsy script probably needs to be patched the same way to use old-releases.ubuntu.com
<knoob> i'm still reading 6.10-7.04
<knoob> mathiaz: Could you help me understand the patch job? I create the patch file and did sudo patch, but I got a Hunk #1 error
<knoob> even if I change all existences of archive.ubuntu to old-releases.ubuntu, the gutsy installation still looks for http://free.linux.hp.com/~brett
<mathiaz> knoob: did you had an custom entry in sources.list?
<mathiaz> knoob: http://free.linux.hp.com/ doesn't look like a standard mirror
<knoob> mathiaz: i'll check... this wasn't my machine until a few weeks ago
<knoob> mathiaz: you're right, there's an installation of freenx that's preventing me from upgrading.. i don't even know what freenx is
<knoob> mathiaz: i added # before those two lines and it seems to have helped... upgrade is still running
<knoob> mathiaz: The distribution upgrade was running fine until just now. "kdepim" failed because "kmail" version was a little bit too old. The whole process stopped and I was dropped back to shell. How can I continue upgrading?
 * cody-somerville wonders what (deleted) besides the filename in the memory map of a process as presented by gnome-system-monitor means.
<cjwatson> it means that the file has been unlinked but the process still has the inode open
<cjwatson> you'll see it in particular when stuff gets upgraded under a running process' feet
<phurl> it works now
<knoob> Hey guys, I just upgraded from 7.04 to 7.10, and before upgrading to 8.04 I wanted to check MySQL. It fails to recognize any of the users with the correct passwords. Any help?
<ScottK> knoob: This is a development channel, not a help channel and both 7.04 and 7.10 are out of support anyway
<knoob> Just figured you guys would have a few of those questions
#ubuntu-devel 2009-08-01
<gandalfcome> I get an unresponsive hdd under 8.04 when rsyncing data from one to another drive. The dmesg output I get starts with invalid opcode: 0000 [#1] SMP. I have googled the problem and saw that this is an reported error. Can someone confirm this?
<mthaddon> gandalfcome: you'd probably be better off asking for support in #ubuntu
<gandalfcome> mthaddon: okay, thanks
<mthaddon> sure, np
<winstonw> ok so i uploaded what I thought would be my final package to REVU, but i forgot to change the distro target and add the bug number for "needs packaing bug".  Should I resubmit or will the REVU people change this for me?
<pef> hello
<iulian> Hi
<rkakkar> Hi
<JeremyBicha> I hate the Firefox multisearch experiment, fortunately I can disable that addon
<bluefoxicy> hey, a friend's having wireless problems with an acer laptop
<bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/318078 may be this
<ubottu> Launchpad bug 318078 in linux "iwlagn 5300 + acer wmi rf-kill bug (dup-of: 319825)" [Undecided,New]
<ubottu> Launchpad bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,Fix released]
<RioKuro> does anybody know how to set my global cflags?
<MIPS-beginner> NCommander: Do you think we should take the OS X Snow Leopard approach and only support the n64 model in Ubuntu Loongson?
<Keybuk> I don't like Leopard
<Keybuk> it really narrows our naming for L
<Daviey> Keybuk: Leaping Lice ?
<Keybuk> I still wanted Kinky Koala
 * Daviey notes Loon is an animal
<davmor2> http://wiki.answers.com/Q/Animals_beginning_with_L
<Daviey> Oh, and not forgeting the Leach
<davmor2> lordly lion
<Keybuk> Leaches!
 * Keybuk has Stand By Me flashbacks
<lifeless> Standing Snake?
<Daviey> lifeless: keep up at the back!
<maco> Leisurely Lemur?
<lifeless> Daviey: I'm getting ahead :P
<Daviey> Leisurely Loon, is somewhat better
<maxb> https://wiki.ubuntu.com/DevelopmentCodeNames :-)
<maxb> Lofty Lemming?
<maco> yeah i guess birds are better at leisure
<Keybuk> Lang-sao Labrador
<Keybuk> that's not a codename, it's a chinese delicacy
<LaserJock> Leisurely doesn't exactly seem right if it's going to be an LTS release
<directhex> LEMUR
<Keybuk> sabdfl will chose Leopard just because ;)
<directhex> wait, damn, remember the rules, shuttleworth picks names people DON'T talk about. um, anything but lemur!
<directhex> lurid lipizaner!
<Keybuk> Longhorn!
<Daviey> Can it be lolzcats?
<Keybuk> hahah
<Keybuk> Laughing Lolcat!
<Daviey> :)
<ion> Lolling Lolcat
<directhex> litigous llama!
<davmor2> I think it should be lazy llama
<directhex> but 10.04 won't be lazy, it'll be filled with omglolwtf amounts of hard work!
<directhex> holy **** it's a liger get in the car!
<maco> Keybuk: if it was true that the codenames weren't used outside of devel, lolcat would be win
<davmor2> directhex: I've seen the damage a tiger can do to a piece of 3mm hardened sheet steel I don't think a liger will have much both getting through .5mm steel on a car not to mention the glass ;)
<directhex> davmor2, maybe the guy who doesn't have time to get into said car will be enough to sate its apetite though
<maco> right you dont have to be the fastest, just not-slowest
<directhex> maco, im in ur distro, spreadin mono
<maco> oh no, get the antibiotics
<davmor2> directhex: no they eat sides of horse for a meal :)
<directhex> davmor2, so... they're french then?
<davmor2> leaping leprechaun, if we can have fictional rabbit with big pointy antlers why not little irishmen with big pointy green hats
#ubuntu-devel 2009-08-02
<directhex> james_w for DD!
<billybigrigger> dtchen, ping
<billybigrigger> or anyone
<billybigrigger> since karmic, how come there is no way to change the audio output device?
<billybigrigger> sound preferences nor pavucontrol can change the actual output device, just the volume and input device
<dupondje> New versions of debian packages are still getting synced into Karmic ?
<ojwb> not automatically
<maxb> dupondje: We are past DebianImportFreeze, syncs now happen only on a case by case basis when manually approved
<dupondje> oh ok, is there a way to request a sync ?
<directhex> yes. with requestsync!
<maxb> dupondje: http://wiki.ubuntu.com/SyncRequestProcess tells all
<dupondje> the 'requestsync' programm doesn't work ? it keeps waiting after Do you want to edit the report before sending [y/N]? Press Control-C to abort.
<dupondje> ok :) stupid ISP blocks port 25 :(
<dupondje> Sync request mailed.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/dutch/+bug/407951
<ubottu> Launchpad bug 407951 in dutch "Sync dutch 1:1.10-1 (main) from Debian unstable (main)." [Wishlist,New]
<dupondje> there it is ;)
<maxb> dupondje: requestsync --lp uses the LP http api to file the request - I like it
<maxb> You do have to set up the oauth credentials separately first, but i think it tells you how
<iulian> Yes, it's documented in the manual page (see man manage-credentials).
<dupondje> maxb: ok thx, anyway it worked with using my own mailserver ;)
<shtylman> when will the new kernel upload (-5.24) be in the repos?
<t3rm1n4l> may i know where is the hostname stored
<t3rm1n4l> ?
<shtylman> etc/hostname
<Abd4llA> hi there, any idea what's the difference between /lib/libc.so and /lib/tls/cmov/libc.so ?
<Abd4llA> /lib/tls/i686/cmov/libc.so
<pitti> apachelogger: devkit-disks does allow that, but it's not the place to configure the default moutn options (this needs to be fed by GNOME or other UI)
<pitti> apw: devkit-disks --mount has a --mount-options switch
<pitti> apw: unfortunately there is no counterpart for the old gnome "volume" properties (by design, as I learned from David)
<maxb> Abd4llA: The ones in deeper directories are ones compiled with certain optimizations requiring a kernel/cpu which supports certain features
<Abd4llA> maxb: thnx alot
<Edico> hi
<TheMuso> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<TheMuso> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<TheMuso> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<Edico> here looks like jaunty has mit-scheme http://packages.ubuntu.com/jaunty/devel/ but when I search it with synaptic is not there
<TheMuso> Ng: /x
<Edico> I included universe repos
<Edico> and mit-scheme is not in my x86_64 ubuntu
<StevenK> mit-scheme is a *source* package name, not a binary package name
<TheMuso> oops
<TheMuso> the jos of long tarveling
<StevenK> Oh, no, it is.
<StevenK> mit-scheme is i386 only
<Edico> StevenK, so mit-scheme is not included for ubuntu x86_64?
<markg85> Hi, i have a question about ubuntu packages.. What i want to do is build a package from source (nautilus) and use the configure line from the official ubuntu nautilus package. But the problem is that i can't find that configure line (not in the .asc file) so.. where is that hidden?
<ojwb> debian/rules
<StevenK> Edico: Right, it is only built for i386
<markg85> ojwb, that can't be everything: http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/nautilus/debian/rules
<StevenK> markg85: Looks fine to me
<markg85> ojwb, StevenK , like: what is the --prefix? what is the --bindir?
<ojwb> whatever cdbs defaults them to
 * ojwb knows little about cdbs, sorry
 * markg85 knows nothing about cdbs :P
<markg85> in prm and archlinux this is all just visible in the spec and PKGBUILD file....
<markg85> prm... rpm
<stgraber> hmm, the powerpc build is broken ?
<dtchen> billybigrigger: unlikely pong
<billybigrigger> why unlikely? :P
<dtchen> billybigrigger: i always check idle time first
<billybigrigger> :P
<dtchen> shtylman: after it's binary-NEWed, i.e., within a day
<billybigrigger> so quick question, is there a better app to be using than pavucontrol, or the dumbed down 'Sound Preferences' to change audio output device?
<dtchen> shtylman: if you're really itching to grab the debs, see the upload queue for /karmic
<dtchen> billybigrigger: unfortunately, on
<dtchen> no*
<billybigrigger> there is no way to change output device?
<dtchen> meaning: nothing better than pavucontrol at the moment
<billybigrigger> pavucontrol won't even let you change output, only input device is changeable
<billybigrigger> ahh atm :P
<dtchen> err, pavucontrol _should_. are you using the context menu (or dropdown menu) in the Playback tab?
<dtchen> (it's per-stream)
<billybigrigger> i must have been really tired last night haha
<billybigrigger> and hung over
<billybigrigger> i was trying to help someone in +1 and now that i look you can change output
<billybigrigger> in the configuration tab aswell as per stream
<billybigrigger> in the Internal Audio Profile
<dtchen> right.
<billybigrigger> my bad, sorry for the useless ping
<dtchen> np
<billybigrigger> looking closer, Sound Preferences is the same thing
<billybigrigger> 1 more question, why doesn't Sound Preferences = pavucontrol
<maco> is pavucontrol or padevchooser the thing that's goin away?
<dtchen> sound prefs has a couple bugs that are known. it has a subset of pavucontrol's functionality due to the latter being a bit complex and unintuitive UI-wise
<dtchen> maco: both are deprecated in some sense
<maco> you said you have a fix for the squeak when the sound powers down on this laptop right?
<dtchen> it was linked in my post to ubuntu-devel{,-discuss}
<maco> kk
<dtchen> it's an older kernel; i'll need to refresh my schroot and rebuild against current ubuntu-karmic.git
<johanbr> Does anyone feel any responsibility for abiword? 2.8.0 will be released soon. It'd be nice to have this version in Karmic (current is 2.6.8).
<ScottK> johanbr: It's used by xubuntu, so whatever their development channel is would likely be your best bet.
<ScottK> cody-somerville: ^^
<johanbr> ScottK: Ahh, right. Thank you.
<MaxPower9> #join #ubuntu
<MaxPower9> sorry
<picklesworth> before I try upgrading it, does anyone here happen to know /why/ the Imagemagick package in Ubuntu and Debian is quite out of date?
<dupondje> picklesworth: old ? 6.5.1.0 isn't that old ?
<picklesworth> well, it's /kind of/ old for impatient people like me :)
<dupondje> make an own package then ?
<dupondje> in a ppa ?
<dupondje> can't be that hard :)
<picklesworth> Doing so right now!
<picklesworth> It's my first time upgrading a package, actually. Looked crazy convoluted originally, but now I see it's quite straight-forward :)
<RAOF> picklesworth: You might want to check what Debian's doing; I noticed an imagemagik transition notice on debian-devel@.
<picklesworth> okay, thanks RAOF :)
#ubuntu-devel 2010-08-02
<kieppie> hi guys. I'm trying to substantiate a statement that Canonical/Ubuntu *does* contribute back to the GNU/GNOME desktop platform. is this true & are there online references I can refer to?
<kieppie> hi guys. I'm trying to substantiate a statement that Canonical/Ubuntu *does* contribute back to the GNU/GNOME desktop platform. is this true & are there online references I can refer to?
<spm> kieppie: http://www.markshuttleworth.com/archives/439 and links referenced within
<kieppie> thansk
<kieppie> spm: they. the "tribalism" article. read it & wholehartedly agree, but some feel it's not addressing the issue. one point was that canonical uses other project (GNOME desktop being the big one), but does not contribute upstream, or have people dedicated to those projects
<kieppie> i do not agree withthat assesment, but I'd like to substantiate my viewpoint
<spm> kieppie: this is emphatically not the channel for discussing those issues.
<kieppie> as far as I can see, it's a developer-releated issue, so I thought I'd ask the deveopers directly, as you guys, more than anyone else, may be able to point me in the right direction
<lifeless> ubuntu-devel-discuss@lists.ubuntu.com might be a better place
<lifeless> this channel is very technical-content-focused, and while this is relevant to developers, its not particularly technical in nature
<kieppie> lifeless: thanks. will pose question there
<kieppie> bb
<kish> sigh
<kish> are ubuntu 10.04 iso's hybrids?
<kish> will dd stick it to usb drives?
<bilalakhtar> tumbleweed: You there?
<RAOF> kish: WFMâ¢
<kish> What?
<RAOF> Works For Me.
<kish> and topc?
<bilalakhtar> !support | kish
<ubottu> kish: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<kish> #ubuntu really cant help with something this complicated
 * RAOF waits impatiently for his btrfs-tools segfaults to move from âIn Progressâ so he can blow away the stupid slow filesystem.
<bilalakhtar> kish: try it
<bilalakhtar> !ot | RAOF
<ubottu> RAOF: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics. Thanks!
<kish> bilalakhtar, of course, i did ;)
<kish> anyway, i'll find a way
<lifeless> bilalakhtar: how was RAOF's comment off topic ?
<bilalakhtar> lifeless: it was. It said 'stupid slow'
<bilalakhtar> lifeless: it suggests something offtopic
<RAOF> How's this for off-topic: Yay!  dpkg finished installing the 10 new packages after only 5 minutes!
<kish> very!
<bilalakhtar> lifeless: this is a highly-monitored channel.
<bilalakhtar> I suppose
<RAOF> I think a little gentle bitching about a development filesystem in #ubuntu-devel can be useful.  When people ask âhey, should I try this shiny new btrfs option in the installerâ, you can say âwell, RAOF did nothing but moan about segfaulting fsck tools and abysmal performanceâ :)
<StevenK> I thought that last statement was a tautology
<StevenK> "well, RAOF did nothing but moan about segfaulting"
<RAOF> :P
<bilalakhtar> !language | RAOF
<ubottu> RAOF: Please watch your language and topic to help keep this channel family friendly.
<bilalakhtar> RAOF: You said 'I think a little gentle ******** about .......'
<RAOF> I think you may have your language threshold set a little to low.
<RAOF> s/to/too/g.  Grammar is for the weak.
<un214> running apt-get dist-upgrade in a chroot system is a good way to brick the host
<un214> grub-install was too dumb to figure out that / wasn't the root of a drive
<RAOF> Anyway, bug #601874 and bug #601877 are me doing a little bit more than moaning :)
<ubottu> Launchpad bug 601874 in btrfs-tools (Ubuntu) "btrfsck crashed with SIGSEGV in btrfs_header_nritems()" [Undecided,In progress] https://launchpad.net/bugs/601874
<ubottu> Launchpad bug 601877 in btrfs-tools (Ubuntu) "btrfsck SIGSEGVs in find_first_block_group" [Medium,In progress] https://launchpad.net/bugs/601877
<lifeless> RAOF: is this M onky ?
<lifeless> s/k/l/
<johanbr> un214, could be https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/496435
<ubottu> Launchpad bug 496435 in grub2 (Ubuntu) "upgrades of the grub-pc package can overwrite wrong MBR" [High,Fix released]
<un214> actually not
<un214> in this case, the correct answer was "none"
<RAOF> lifeless: I'm not sure what you mean.  There's a bunch of stuff that's M-only that's a prerequisite for good btrfs support.
<lifeless> RAOF: well, I have a btrfs backup drive on my lucid home serverish box
<lifeless> RAOF: which is running quite ok :)
<un214> FYI, I managed to write a serial startup script that puts upstart to shame
<RAOF> lifeless: It's possible that something I've done has hit a poorly-tested path.  This laptop does a lot of power-off shutdowns.
<lifeless> ah
<RAOF> And since btrfsck segfaults, there's no way to repair.
<un214> how about mounting ro and using cpio to get your files out and reformat?
<RAOF> It's quite possible that my abysmal performance is due to a broken on-disc format.
<RAOF> un214: I'll do that just as soon as nothing needs testing - I can't btrfs-image this filesystem either.
<un214> dd will image it
<RAOF> dd will image it onto your choice of 240GB discs, true.
<lifeless> though it will keep it precisely as broken.
<RAOF> Yeah, that's the point.
<lifeless> hmm
<lifeless> what does securedelete do on btrfs ?
<un214> probably something else
<un214> securedelete is dead on journaled filesystems
<un214> there filed bug: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/612409
<ubottu> Launchpad bug 612409 in grub2 (Ubuntu) "grub-install bricks systems if ran in a chroot jail" [Undecided,New]
<un214> I have this propensity for finding really obscure bugs
<un214> I was told back in march that removing plymouth was simply a longer way to pain when I got bit by some early bugs that made it not work right (no failover for no fbcon)
<un214> well I had to remove it in the end anyway and now anybody else who needed it has left
<un214> so I can't get real support for removing the abomination anyway
<TheMuso> cjwatson: I was looking at freej earlier, and tried building the synced version of freej to see if it could be synced. As you see, it FTBFs, due to the joys of xulrunner.
<TheMuso> cjwatson: Tried to untagle whats required to work with out xulrunner to no avail so far.
<pitti> Good morning
<pitti> micahg: indeed, empathy FTBFSes on that, too
<pitti> micahg: I didn't actually remove them, but I'll have a look why they disappeared
<pitti> we should just clean the dependencies in the .la
<pitti> apw: ah, seems we got a -14 by now
<pitti> . o O { with a new kernel ABI each day we'll never get a working CD build }
<ion> :-)
<pitti> micahg: erm, do you really mean gtk+2.0? It  still ships .la files
<pitti> micahg: you might mean libgdk-pixbuf?
 * pitti fixes gdk-pixbuf
<pitti> bah, it seems the lagging dpkg build causes quite some FTBFS
<pitti> cjwatson: would you mind if I remove the upstream changelog from grub-{common,pc}? it's .5 MB for the two of them
<pitti> ogra, lool: do you already happen to know the root cause of all the armel uninstallability? (http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html)
<pitti> for i386/amd64 I now fixed everything but linux-backports-moudles
<slangasek> pitti: looks like most of it is still a continuation of the kde problem we've had for a while, plus some sort of java issue?
<slangasek> openjdk needed re-bootstrapping on armel in maverick ; I don't know whether that's done yet
<dholbach> good morning
<pitti> hello slangasek
<pitti> hey dholbach
<pitti> slangasek: ah, thanks; I just wondered about weird things like cpp-4.5-doc, which don't look very java-ish
<bilalakhtar> dholbach: good morning
<dholbach> hey pitti, hey bilalakhtar
<slangasek> pitti: arch: all w/ unsatisfiable arch: any dep on gcc-4.5-base
 * slangasek sleeps
<pitti> ah, thanks
<pitti> slangasek: good night!
<bilalakhtar> ev: You there?
<ogra> pitti, ubuntu-netbook-efl-default-settings seems to be stuck in NEW
<ogra> pitti, kde is still not completely rebuilt openjdk wasnt bootstrapped newly on purpose yet (which holds back openoffice)
<pitti> ogra: good morning
<ogra> heh, and good morning indeed :)
<pitti> ogra: ah, slangasek already followed up with why those -doc packages are uninstallable as well
<pitti> seems like a missing gcc-4.5 bootstrap or so?
<ogra> might be, thats linaro land
<ogra> they do toolchain and openjdk currently, so i'll defer to lool for that, what i know for sure is that we dont want the current openjdk source to be built on armel
<ogra> since it has a bug that makes java 5x slower, so we need to stick with the existing binary unless we want week long builds
<pitti> cjwatson: argh, new dpkg:
<pitti> *** buffer overflow detected ***: /usr/bin/dpkg-deb terminated
<pitti> that's not good :-/
<ion> If dpkg made reflinks (if supported by fs) out of duplicate files it installs (e.g. based on md5sumâfilename mapping with a byte-by-byte comparison check to verify the match), it seems my server would save about 319 MB of disk space and my laptop about 703 MB.
* pitti changed the topic of #ubuntu-devel to: All uploads FTBFS due to #612457 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> ok, so this isn't ddeb specific
<pitti> normal builds fail as well
<pitti> so of course the fixed dpkg package will FTBFS, too
<ion> :-)
 * pitti stops buildds
<pitti> all on MANUAL now
<ion> I wish apt and dpkg used a real, indexable database. The duplicate handling (re: what i said above) would be cheap if one could just add an index for the md5sumâfile mapping.
<ion> Things like dpkg -S foo would also be faster, taking advantage of an indexed filenameâpackage mapping. :-)
<DktrKranz> james_w: http://blog.ganneff.de/blog/2010/08/02/removalstxt---removals822.html
<pitti> ok, got the dpkg bug fixed
<pitti> now I need to whack debian/rules to use the local version to actually build..
<apw> bug #612457
<ubottu> Launchpad bug 612457 in dpkg (Ubuntu Maverick) "1.15.8.2 regression: dpkg-deb segfaults" [Critical,In progress] https://launchpad.net/bugs/612457
<pitti> apw: right, see /topic
<pitti> just uploaded a fixed one, I'll handhold it through the buildds
<apw> pitti, sorry ... was using ubbotu to get a link to the bug ... doh for doing it in here
<ion> I have a convenient quicksearch bookmark: âlpâ for https://bugs.launchpad.net/bugs/+bugs?field.searchtext=%s (so e.g. âlp 12345â works in the location bar).
<ubottu> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<apw> pitti, you are a stat btw :)
<apw> star
<pitti> stat?
<pitti> ah :)
<pitti> ion: "ubug" for me; those are quite handy indeed :)
<ion> File.stat('pitti').mtime
<apw> pitti, do you know if the PPA amd64 builders are switchable to i386?  and if so, who owns that sort of thing ... we have a major imbalance between the two in terms of queue right now, days for i386
<pitti> apw: I suppose they are, but I can't do tha
<pitti> apw: #soyuz perhaps?
<ion> Theoretically, they could do both on demand.
<pitti> ok, building everywhere, and all buildds back on manual
<asac> mvo: apt-transport-https/0.7.26~exp12ubuntu1 -> libapt-pkg4.10   ...  but libapt-pkg4.10 doesnt exist
<asac> e.g. our images ftb
<asac> https://edge.launchpad.net/ubuntu/maverick/armel/apt-transport-https/0.7.26~exp12ubuntu1
<apw> ion, yeah my thought exactly ... /me investigates
<pitti> wahwahwah, dpkg FTBFS
<asac> mvo: let me know how we can fix this ;)
<asac> oh
<mvo> asac: libapt-pkg4.10 is provided by ap
<mvo> asac: apt
<pitti> seems I didn't take the binary mangler into account
<asac> mvo: well. all i see is that the images fail to build for three days ;)
<mvo> asac: its very odd that you get 0.7.26~exp12ubuntu1 for a-t-https but not for apt
<asac> http://snapshots.linaro.org/10.11-daily/linaro-headless/20100801/0/build-log.txt
<asac> mvo: ^^
<wgrant> ion, apw: The main thing holding me back from doing that is job dispatch time estimation, unfortunately.
<asac> mvo: ah
<wgrant> ion, apw: Everything else is done or easy.
<mvo> asac: Setting up apt (0.7.26~exp12ubuntu1) ...
<mvo> ERROR: Can't find the archive-keyring
<mvo> Is the ubuntu-keyring package installed?
<mvo> dpkg: error processing apt (--configure):
<mvo>  subprocess installed post-installation script returned error exit status 1
<asac> ERROR: Can't find the archive-keyring
<mvo> asac: my mistake, I fix that
<asac> mvo: thats interesting. we didnt change anything
<asac> ah ok
<mvo> asac: it should not fail because of this
<apw> wgrant, could we perhaps give the build-admins a knob to bounce machines one way or the other ?
<asac> cool
<wgrant> apw: I just proposed that I merge the half of the work that lets them do exactly that.
<apw> wgrant, as obviously to a human it is something thats calculable
<apw> :)
<asac> mvo: once uploaded, can you poke someone to get the upload buildscore bumped so we can rerun the image build today?
<asac> nevermind
<asac> builders seem to be more or less empty
<pitti> dpkg upload, take II
<micahg> pitti: yeah, libgdk-pixbuf since it replaced that part of gtk+2.0
<pitti> micahg: ok, thanks for confirming; should be fixed now
<pitti> that is, once we actually get package builds back :)
<micahg> pitti: thanks
<pitti> https://edge.launchpad.net/ubuntu/+source/dpkg/1.15.8.2ubuntu3
<pitti> HAR HAR! pitti - dpkg 2:1
<tseliot> cjwatson: I can't unsubscribe from https://lists.ubuntu.com/mailman/listinfo/lucid-changes (basically the "unsubscribe" email never arrives). Can you help me, please?
<geser> mvo: you can close bug 611994 when you fix the keyring issue
<ubottu> Launchpad bug 611994 in apt (Ubuntu) "[Maverick] Missing dependency on ubuntu-keyring" [Undecided,New] https://launchpad.net/bugs/611994
<mvo> geser: will do, thanks
<pitti> ogra: is bug 600487 really in gnome-session (also?) or just in the new default-settings package, and seeds?
<ubottu> Launchpad bug 600487 in gnome-session (Ubuntu Maverick) "system fails to launch netbook-launcher-efl on arm system" [Medium,Fix committed] https://launchpad.net/bugs/600487
<ogra> pitti, only in ubuntu-netbook
<pitti> ogra: so the gnome-session task should be a netbook-meta task?
<ogra> it launches, but nautilus sits on top
<ogra> yeah
 * ogra changes
<ogra> heh, youre to fast
<pitti> ogra: thanks
<pitti> ogra: ah, now you added a task; but do we actually need to fix something in gnome-session?
<ogra> not at all
<ogra> should be wontfix
<ogra> or invalid
<pitti> ok, done
<pitti> ogra: you could just have changed it :)
<pitti> anyway, done now
 * pitti looks at NEW
<ogra> thanks
 * pitti wonders about the slightly weird debian/rules there
<pitti> a mere %: dh "$@" doesn't do? it just looks like boilerplate
<ogra> i must admit i didnt touch it at all :)
<pitti> ogra: also, can you please fix une-efl.desktop to say that it's the 2D launcher?
<pitti> right now it looks identical to the "real" 3d netbook one
<ogra> oh, k
<pitti> ogra: I'll source-NEW the package now (to main), but I won't binNEW for now; this should be fixed first
<pitti> but now you can upload a fixed version without the new queue
<ogra> great, thanks
<pitti> \o/ new dpkg is published
<ogra> yay
 * pitti tries amd64 gdk-pixbuf build
<pitti> yay, stuff works again
 * pitti unleashes buildds
* pitti changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<SpamapS> any moderators of ubuntu-devel around? Sent a message last Thursday, still have not seen it, and it relates to things that need to be completed by FeatureFreeze this week.
<SpamapS> sorry, Sent a message to ubuntu-devel@lists.ubuntu.com ..
<pitti> ogra: u-n-e-d-s binNEWed to main; so you can rebuild n-meta in 1:20 ohurs
<pitti> hours, too
<tkamppeter> pitti, hi
<pitti> apw: bin-NEWed -14, if you want to upload lbm and -meta soon? (armel -14 is still building, though)
<pitti> hello tkamppeter, how are you?
<tkamppeter> pitti, will you do the Jockey stuff for the driver download before FF/before release?
<pitti> tkamppeter: not sure yet; as I said, I'm in the OEM team this cycle, so I dno't have a lot of platform cycles left
<pitti> and if I do, it seems I get booked fulltime as acting RM or for SRUs..
<tkamppeter> pitti, so Jockey is unmaintained upstream for Maverick and I should skip this over to Maverick + 1?
<pitti> tkamppeter: we might need to defer it to N, yes
<pitti> I do some bug fixes, but this is a major new featuer
<tkamppeter> pitti, the problem is that Epson has made the first downloadable drivers and now they do not get used as there are no cycles to finish the development of a client.
<tkamppeter> pitti, is it so much to fix Jockey? Jockey probably has already the capabilities to check signatures for NVidia packages and it it is probably no big deal for Jockey to look for printer drivers without checking the whole system's hardware. And I reported everything early enough in the cycle.
<pitti> tkamppeter: no, jockey does not check any packages, apt does that
<pitti> but apt does not have a dynamic and magic way to import gpg keys, grab them from keyrings, compare to https:// web sites, etc.
<pitti> implementing all that is quite some work
<pitti> well, apt can import new gpg keys, of course
<pitti> but we shouldn't do that permanently
<ogra> pitti, merci
<tkamppeter> pitti, what would need to be done for implementing this? Or should we simply add Epson's key to our key collection for Maverick and then do a formal Blueprint with UDS session for automated key loading for Maverick + 1?
<pitti> tkamppeter: we could probably ship the epson key in jockey and only accept those drivers, that's a lot less work, yes
<tkamppeter> pitti, are these keys (like NVidia) in Jockey?
<tkamppeter> pitti, then we must set Jockey's config to accept binary packages if the key is present and non-binaries (like Ricoh's PPDs) without key as before.
<pitti> tkamppeter: no, nvidia is a regular ubuntu pacakge and is taken care of by apt
<tkamppeter> pitti, OK. So let us ship the Epson key for just this one cycle and assure that Jockey finds non-binary drivers and binary drivers and accepts the latter with an existing key. Then the Epson drivers will be accepted as we ship[ their key. Automatized key loading infrastructure will then be a feauture for N.
<apw> pitti, thanks ...
<tkamppeter> pitti, still there?
<pitti> yes
<tkamppeter> pitti, what about my last suggestion?
<pitti> tkamppeter: as I said, it's a lot less work; still nontrivial, but might be doable for M
<tkamppeter> pitti, OK
<tkamppeter> pitti, and is there a chance to fix the problem of Jockey checking the whole system when it get only asked for searching a printer driver?
<pitti> tkamppeter: well, sure there is a chance -- it's a SMOP :)
<pitti> so if anyone wants to tackle this, that's great
<tkamppeter> pitti, SMOP?
<pitti> simple matter of programming
<tkamppeter> pitti, have found it, seems to be a major rewrite of Jockey, seems to be better I provide an OpenPrinter driver package search and install client as a part of OpenPrinting ...
<tkamppeter> pitti, am I right?
<pitti> ..
<tkamppeter> pitti, what does this mean?
<pitti> tkamppeter: I meant of course it is possible to fix that bug; it just needs some time to fix it
<tkamppeter> pitti, OK. It would be great if you could solve these little problems, so that I can present results to the LF managers and the printer manufacturers, especially to get more manufacturers to package up drivers in LSB format.
<bdrung> mvo: edit-patch lacks an non-interactive mode
<mvo> bdrung: that is quite possible, could you please file a bug? its a pretty straightforward script, I'm happy to help with the implementation as well if you want to give it a try
<bdrung> mvo: i want to use it in sponsor-patch (current state: http://paste.debian.net/82041/ )
<mvo> bdrung: nice idea!
<bdrung> mvo: filed bug #612566
<ubottu> Launchpad bug 612566 in ubuntu-dev-tools (Ubuntu) "edit-patch doesn't have a non-interactive mode" [Undecided,New] https://launchpad.net/bugs/612566
<bdrung> mvo: could edit-patch be rewritten in python? then it could be used directly by sponsor-patch
<mvo> bdrung: I would not mind if it would be rewritten, but I don't have the time currently to do it myself
<dholbach> I think the idea was to get it into devscripts at some stage
<dholbach> (iirc)
<bdrung> k, then python would be not the right way
<cjwatson> TheMuso: yeah, I'm going to look at that some more
<cjwatson> tseliot: what e-mail address?
<cjwatson> SpamapS: I moderated your mail
<tseliot> cjwatson: alberto.milone at canonical.com
<cjwatson> tseliot: you're not subscribed to lucid-changes with that address
<cjwatson> tseliot: albertomilone at gmail.com is subscribed
<tseliot> cjwatson: yes, that's the one
<tseliot> sorry
<cjwatson> tseliot: unsubscribed
<tseliot> cjwatson: thanks a lot
<ttx> I'd need some AA love on this sync request, it blocks one of my specs for alpha-3 completion: bug 612124
<ubottu> Launchpad bug 612124 in tomcat6 (Ubuntu) "Sync tomcat6 6.0.28-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/612124
<cjwatson> ttx: done
<sense> Is there a good guide for editing a debian directory that is in an Ubuntu Bazaar branch with help from the apt-get source sources?
<pitti> sense: https://wiki.ubuntu.com/DesktopTeam/Bzr is the guide for the desktop team, but it's not really desktop specific
<sense> pitti: Thanks a lot!
<pitti> sense: but apt-get source is neither useful nor helpful there
<pitti> sense: we use bzr-buildpackage, which provides quite a nice and easy workflow
<ttx> cjwatson: great, thx !
<pitti> bzr-builddeb even
<sense> pitti: OK, thanks
<cjwatson> sense: try https://wiki.ubuntu.com/DistributedDevelopment/Documentation
<sense> cjwatson: Ah, of course, that documentation! I had completely forgot about it.
<pitti> sense: the difference between those is whether you have a package with an implicit auto-import branch (lp:ubuntu/pkgname) or an explicitly maintained debian/ only branch (Vcs-Bzr:)
<sense> pitti: gtk+2.0, more than just the debian direcotry
<pitti> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntu
<pitti> sense: you want the first link then
<sense> pitti: Isn't that equal to lp:ubuntu/gtk+2.0?
<pitti> sense: no, it's not
<sense> ah
<sense> ok, thanks!
<pitti> if a source package has a Vcs-Bzr: tag, then that is the definitive branch
<pitti> the auto-import is not used
<sense> I see.
<pitti> sense: admittedly this is rather confusing
<sense> A bit indeed. :)
<pitti> unfortunately there is no real way to mark those auto-imports as "please don't use"
<pitti> (or I'm not aware of it)
<sense> Branch status?
<pitti> sense: these are owned by the importer, and bzr get doesn't tell you the status anyway
<sense> That's true.
<pitti> it would be great if lp:ubuntu/gtk+2.0 could somehow point to the actually used branch
<pitti> but well, not quite there yet :)
<sense> Rome wasn't built in one day, shall we say? ;)
<pitti> apw: do you plan to have the -14 kernel in alpha-3?
<pitti> sense: and neither cathedrals and bazaars
<sense> nope
<Laney> pitti: I thought you could have that happen (redirecting the ubuntu/* branches)
<pitti> Laney: somehow it's possible, but (1) it's nontrivial even for full-source branches (e. g. apport), and (2) I was told we shouldn't have debian/ only branches in those lp:ubuntu/ ones
<Laney> hm, alright
<Laney> maybe it would be good to be able to make them read-only or have a warning when they are branched
<asac> mvo: apt uploaded already?
<asac> ah seems something went up. thx
<bdrung> pitti: what do you think about having a dh_apporthook command for installing apport hooks?
<mvo> asac: uploaded a couple of hours ago
<asac> mvo: yep. saw that. i am waiting for results from image build atm
<asac> let me see
<asac> seems fine. thanks mvo!
<SpamapS> cjwatson: thank you. :)
<SpamapS> hrm.. when building a package, doesn't dpkg-source ignore the top level directory from the orig tarball?
<cjwatson> mvo: does http://paste.ubuntu.com/472273/ look right to you?  apt-cdrom always fails right now
<cjwatson> (because it drops one too many characters from the end of the binary-* directory name)
<SpamapS> http://paste.ubuntu.com/472278/
<SpamapS> Very confusing..
<SpamapS> does the .orig tar ball have to match the name of the source package?
 * SpamapS wonders if he's just always accidentally gotten this right
<cjwatson> wow, running apt-cdrom replaces /dev/null with a regular file
<cjwatson> SpamapS: the filename of the tarball must match; the contents only have to be all under one directory, but the name of that directory doesn't matter
<SpamapS> cjwatson: I'm a bit confused by the output of dpkg-source (see paste link above) then.
<SpamapS> cjwatson: if I recreate the .orig.tar.gz to have its first level dir be php-gearman-0.7.0 .. the package is built as I would expect.
<cjwatson> can I download your original .orig.tar.gz somewhere?
<cjwatson> I mean, it looks from that paste as if it has some stuff at the top level
<cjwatson> so repacking it is probably reasonable anyway
<SpamapS> cjwatson: the upstream tarball is http://pecl.php.net/get/gearman-0.7.0.tgz
<cjwatson> it's probably just getting confused by the file at the top level
<cjwatson> repack and move on :)
<cjwatson> (package.xml)
<SpamapS> oooohhhhhh
<SpamapS> thank you for lending me your eyes for a bit.. ;)
<cjwatson> oh, wow, apt-cdrom has had this bug forever
<SpamapS> cjwatson: its a feature... turns the bit bucket into a recycle bin. ;)
<mvo> cjwatson: hi, thanks for the apt-cdrom fix, I assume its a very recent regression (by the latest apt upload)?
<cjwatson> mvo: can't tell quite how recent, though bzr blame suggests it's part of the multiarch changes
<JamesWstubbs91> Hello, I asked this question in #Ubuntu and wasn't able to get a response, I guess it's kind of relevant for development, I'm doing an iPhone port of Karmic, I have X11 fully up and running with wifi and a ssh connection, I can use the touchscreen using the "evdev" driver which works perfectly in a landscape orientation, I'm working on making it landscape for screen space, I've swapped the axes and invert the y axis so
<JamesWstubbs91> But now the top part of the screen is unaccesable by the mouse
<JamesWstubbs91> Is there a tool to calibrate the evdev driver for touchscreens?
<JamesWstubbs91> Any help's appreciated
<rsavoye> I had the same problem this week :-(
<JamesWstubbs91> I meant evdev works perfectly in a portrait orientation.
<JamesWstubbs91> Hm, I tried switching my MaxX and Maxy round, didn't make a difference
<rsavoye> I added full touchscreen support,m only to find I can't calibrate under GNOME
<JamesWstubbs91> Option "Calibrate" in xorg.conf doesn't do much
<micahg> JamesWstubbs91: if no one answers, you can try #ubuntu-x
<JamesWstubbs91> I'll join the channel now
<lool> pitti, ogra: Hey; I'm in NY for debconf, were the installability issue solved?
<lool> pitti: Did you find the patch for dpkg I worked on with Reinhard yesterday?
<lool> I see you did
<mvo> cjwatson: shall I do the apt upload with the apt-cdrom change? or do you want to do it (I'm fine uploading, unless you have everything prepared already etc :)
<lool> pitti: BTW, I made a point here that we would have catched that with -fstack-protector in Debian   ;-)  dpkg would just produce corrupted .debs instead on some arches!!
<pitti> bdrung: cjwatson added a dh-apport package the other day with exactly that :)
<pitti> lool: dpkg patch> yes, I found it
<pitti> lool: in fact, I had my own patch after 1 min of debugging :)
<pitti> but I took upstream's, since htat was a tad nicer
<pitti> lool: enjoy debconf!
<lool> pitti: I was really happy that we have -fstack-protector
<pitti> yes, it's great
<pitti> a solid crash was very obvious :)
<lool> pitti: You should offer the PATH change upstream though, I don't think we do that in Debian
<pitti> lool: it was only meant for this one upload
<pitti> since otherwise it would have FTBFSed
<lool> pitti: Hmm ok, I found it not a bad idea
<pitti> we were going to ditch it again on the next one
<pitti> lool: yeah, maybe; more dogfooding
<pitti> the previous (broken) dpkg would have FTBFSed right away
<cjwatson> mvo: if you could, that would be great
<mvo> cjwatson: sure thing, thanks for the fix!
 * Keybuk shakes his fist at pitti
<Keybuk> pm-utils now mucks around with readahead settings
<ResQue> Hello people
<ResQue> hello freddy
<ResQue> is there a channel for developer who like to develop apps for ubuntu, rather than the development of ubuntu
<micahg> ResQue: #ubuntu-app-devel ?
<ResQue> micahg:  thanks
<ResQue> freddy_: you want the room micahg just mentioned
<SpamapS> mathiaz: ping!
<mathiaz> SpamapS: o/
<SpamapS> mathiaz: I don't think CEPH is going to make it into Debian by FF
<mathiaz> SpamapS: agreed
<mathiaz> SpamapS: I've seen the comment from the merge proposal
<mathiaz> SpamapS: it seems that upstream is responsive
<SpamapS> mathiaz: very
<mathiaz> SpamapS: for now the plan I'd suggest that we don't wait for Debian
<SpamapS> mathiaz: Sage is quite excited to see ceph get out there and is hoping this will provide the testing that it needs to stabilize
<mathiaz> SpamapS: and instead upload ceph to Ubuntu in time for Feature Freeze
<mathiaz> SpamapS: is the bzr branch up-to-date wrt to the new usptream changes?
<mathiaz> SpamapS: IIUC Sage made some changes in the packaging branch as well
<SpamapS> mathiaz: no, I was going to ask you if you wanted me to merge his last few changes
<mathiaz> SpamapS: seems like a good plan
<mathiaz> SpamapS: given that he pushed fixes based on the feedback
<SpamapS> indeed
<SpamapS> mathiaz: /win 3
<SpamapS> bllaha
 * SpamapS must really write a script to stop that
<mathiaz> SpamapS: at least you're not doing /win 124
<SpamapS> mathiaz: anyway, I'm pulling down his git repository now, will merge and push as necessary
<mathiaz> SpamapS: great - thanks!
<SpamapS> mathiaz: of course not, the people in window 124 are boooring
<mathiaz> SpamapS: well - I'm not sure I'd see the value of having *124* windows opened
<SpamapS> $ bzr branch git://ceph.newdream.net/git/ceph.git
<SpamapS> | fetching revisions 6594/10811
<SpamapS> oi.. this has my laptop's fan spinning pretty hard. ;)
<bdrung> pitti: great, but it will lead to to a debian -> ubuntu diff.
<jelmer> bdrung: Hi, thanks for looking at those sync requests.
<bdrung> jelmer: np
<bdrung> jelmer: sync requests are the first priority in the sponsors queue
<SpamapS> mathiaz: absent any more issues, can you upload the package that is in that branch?
<mathiaz> SpamapS: I plan to have a second round of review
<mathiaz> SpamapS: I usually stop my review after outlining a few things
<mathiaz> SpamapS: in order to not come up with a long landry list of things to fix
<mathiaz> SpamapS: and I get tired of reviewing the package after some time as well
<mathiaz> SpamapS: it may well be that the package would be ready for upload this time around
<SpamapS> mathiaz: I will cross my fingers then. :)
<SpamapS> mathiaz: did you see my message from Hung?
<mathiaz> SpamapS: yes
<SpamapS> mathiaz: can you also give some attention to this one when you have some time? https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/rrdtool/merge-1.4.3-1/+merge/30675
<mathiaz> SpamapS: sure - review claimed
<SpamapS> mathiaz: ty.
<pitti> bdrung: hm?
<bdrung> pitti: on debian dh-apport does not exits. so how can i keep the debian and ubuntu package in sync if it contains an apport hook?
<pitti> bdrung: conditionally install it in debian/rules, that's what I do for my packages (udisks, etc.)
<Laney> yes, guard your call to dh-apport by dpkg-vendor
<pitti> bdrung: http://git.debian.org/?p=pkg-utopia/udisks.git;a=commitdiff;h=a9ddc5bb660a4f53c2533c8e154159dfcdd94519
<pitti> but dpkg-vendor is a bit more modern indeed
<bdrung> but then there is still the build dependency
<pitti> bdrung: you don't need a build dependency to install file?
<bdrung> then i can't use dh_apport
<pitti> right, what I said; use debian/rules
<bdrung> ok
<bdrung> and dpkg-vendor!
<pitti> :)
<Laney> bdrung: you can use dpkg-gencontrol to replace ubuntu specific substvars if you want
<Laney> in combination with dpkg-vencor
<Laney> dpkg-vendor
<pitti> doesn't work for build depends, though
<Laney> oh, yeah
<Laney> couldn't dh_apport just be added to the default debhelper sequence on Ubuntu?
<Laney> or does it bring in a long chain of depends?
<Laney> no, in fact it does not
<ajmitch> it'd be good to just have apport in debian, though I don't know if having it optionally file bugs to the BTS would be useful there
<Laney> cjwatson: what do you think to ^^^? (I see you wrote dh_apport)
<ajmitch> there's an ITP open for apport, but no action on it for the last year or so
<Laney> I imagine it would require quite some engineering
<ajmitch> the retracing part would, since there aren't currently debug packages, unless that gsoc work has been put in place
<cjwatson> Laney: I don't want to change debhelper defaults - joeyh tends to get unhappy when we do that.  I'd rather leave it as a sequence extension
<Laney> OK, just thinking how to reduce deltas, but it's no big deal
#ubuntu-devel 2010-08-03
<asac> pease promote libeina-svn-06 to main ;) ... the source already is in main, but this one is now needed by evas ;)
<asac> please
<asac> james_w: ^^ do you have powers?
<asac> thx
<cjwatson> asac: done
<ebroder> Is there a way for a program to catch an Upstart event (event, not job)? I want to have a program do something when an event comes from the upstart-udev-bridge
<un214> What I'd like to know is who was the dope who thought that setting the ionice of a process to idle would keep it from interfering with the disk activity of other processes.
<micahg> !coc | un214
<ubottu> un214: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere, and can be found at http://www.ubuntu.com/community/conduct/ .  For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct .
<ion> un214: If it doesnât, the kernel should be fixed.
<un214> it can't work on rotating disks
<ion> Sure it can.
<un214> seek time
<ebroder> un214: That's why you have a buffer cache and an I/O scheduler
<ion> If higher-priority processes do frequent disk IO, the grace time is never reached and the idle-priority process never gets to do its IO. Now, if thatâs not what happens, the kernel should be fixed. Perhaps the grace time is too low.
<un214> and replacing mountall with fsck -A -P && mount -a took minutes off boot time fsck
<un214> mountall correctly set the second fsck ionice to idle and it didn't help
<ion> I take it /sys/block/sda/queue/scheduler says cfq is active?
<un214> yes
<un214> oh duh
<un214> the actual problem is mountall set both fscks to idle priority
<un214> there's a third fsck on a second disk that actually runs first
<ion> Ok, that should not happen. Please add --debug >/dev/mountall.log 2>&1 to the end of the exec line in /etc/init/mountall.conf, start with forcefsck and provide /dev/mountall.log, thanks.
<un214> can't do it anymore, I ripped the whole boot setup out
<ion> Then itâll be difficult to fix the bug.
<un214> it's immediately obvious where the bug is coming from
<un214> mountall ignores the pass parameter in /etc/fstab
<ion> Did i get this correctly: you have two physical disks, and *all* of the fscks for one of them had the idle iopriority while one or more fscks were running for the other disk?
<eggonlea> Hi all, I have a question about how to install conflict configuration file. E.g. package A would install a default /etc/init/a.conf; but package B would enhance package A and therefore introduce a modified /etc/init/a.conf. What's the recommended way to do this?
<un214> yes you did
<eggonlea> Is there any way to hack package B only and leave package A untouched (because it's transparent to package A totally)?
<ion> The debug log from mountall would make it possible to pinpoint where the problem is. Whenever you are able to provide one, please contact me again, so i can debug the issue.
<RAOF> eggonlea: Policy forbids packages from modifying conf files owned by another packge.
<ebroder> eggonlea: You could look at config-package-dev (http://debathena.mit.edu/config-package-dev/)
<RAOF> eggonlea: There are two ways this is handled: (1) By having package A have a /etc/foo.d directory, where package B can drop a config snippet in, or (b) by having package A provide a programatic mechanism for modifying its config, and having package B use that.
<ion> eggonlea: If /etc/init/b.conf has âstart on starting aâ, whenever a is going to be started, b starts first, blocking the startup of a until running.
<ion> Dunno if thatâs what youâre after.
<un214> ion: it's safe to run mountall directly from a maintenance shell right?
<eggonlea> RAOF: thanks! Would take a look at config-package-dev
<eggonlea> ion: This should work on my case!
<ion> un214: Itâll probably never notice the disks until udev is running, and udev should be only started after mountall has mounted the virtual filesystems.
<ion> You could mount them manually, start udev and then start mountall. That *might* work. :-P
<un214> ion: I uploaded log to https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/599624 -- looks like ionice triggered but was ineffective
<ubottu> Launchpad bug 599624 in mountall (Ubuntu) "mountall ignores the pass parameter of /etc/fstab when scheduling fsck" [Undecided,Invalid]
<ion> un214: Ok, thanks. Iâll see what i can figure out.
<getpwnam> what do people think about adding a speed limit/pause to the Synaptic download dialog? I was in the middle of a post-installation ~1GB download when my wife tried to use Skype, but Synaptic was hogging the network so the call quality was very poor. It would've been nice to have a download speed limiter so I wouldn't have to cancel..
<ion> apt-cache show trickle perhaps
<tjaalton> sigh, is it ext4 failing or why do some package installations on current lucid fail by complaining "corrupt tar", and the succeed the next time
<tjaalton> happens at least with large in-house debs
<pitti> Good morning
<tjaalton> morning pitti
<pitti> hey tjaalton
<ajmitch> morning pitti
<tjaalton> hmm, I see a lot of ext4 changes in the latest lucid kernel.. maybe that's why I could do a full install before but not anymore
<tjaalton> on one go that is
* pitti changed the topic of #ubuntu-devel to: Soft freeze for Alpha-3 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<bilalakhtar> dholbach: good morning
<dholbach> good morning
<dholbach> hey bilalakhtar
 * bilalakhtar wished before dholbach could
<dholbach> pitti: oops, I should've read emails before doing sponsoring :)
<pitti> hey dholbach
<pitti> dholbach: did you break everything? :-)
<dholbach> no, just upload a couple of long-waiting main sponsoring requests
<dholbach> if there's blame, I'll decide to ignore it though :)
<dholbach> (and for today I'm done sponsoring)
<ajmitch> dholbach: soft freeze means you only get hit softly when you upload stuff, right?
<dholbach> ajmitch: not sure if the release team really dares to do that :-P
<directhex> time to upload mono 2.6.7!
<dholbach> pitti: do you have any idea why a source package maybe have been accepted but binary packages rejected?
<dholbach> https://launchpad.net/ubuntu/maverick/+source/mtdev/1.0.6-0ubuntu1
<pitti> dholbach: I mailed Chase
<dholbach> I'm not sure I understand this :)
<dholbach> ah
<pitti> dholbach: the library -dev shipped a .la, and I don't want this to infect the archive
<pitti> so I asked him to remove the .la and reupload
<dholbach> ara: ^
<dholbach> ara: if you prepare a branch for the change I'll test and sponsor it
<ara> dholbach, ok, will do later, thanks!
<dholbach> rock!
<asac> cjwatson: i would like to remove packages in a downstream seed. is that possible with some magic atm? like adding a "!xorg" to a linaro-xxx seed still using desktop-common to get rid of that part?
<dupondje> mmm, xterm removed libutemper again :(
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103
<ubottu> Launchpad bug 589103 in libutempter (Ubuntu) "[MIR] libutempter" [Undecided,Fix committed]
<alkisg> Hi, I'm trying to upload fixed tuxpaint/tuxtype packages to lucid-proposed, is there a wiki page that describes that process?
<alkisg> (trying to get an SRU for bug #572994 and bug #512285)
<ubottu> Launchpad bug 572994 in tuxpaint (Ubuntu) "Translations missing due to universe demotion (dup-of: 503919)" [Undecided,New] https://launchpad.net/bugs/572994
<ubottu> Launchpad bug 503919 in Ubuntu Translations "Translations missing in tuxpaint-data Ubuntu 10.04 package" [Medium,Triaged] https://launchpad.net/bugs/503919
<ubottu> Launchpad bug 512285 in Ubuntu Translations "Translations missing due to universe demotion" [Medium,Triaged] https://launchpad.net/bugs/512285
<geser> the SRU wiki page describes the process but beyond this uploading to -proposed is nothing special and works like any other upload
<alkisg> OK, so I'll just modify my ~/.dput.cf and upload. Thanks!
<geser> why modify?
<tumbleweed> alkisg: err, you shouldn't need any modifications
<alkisg> To add a [lucid-proposed] stanza there, just to make the dput command line easier :)
<geser> you need lucid-proposed in the changelog and upload to "ubuntu" as usual
<alkisg> "upload to "ubuntu" as usual" ==> sorry I've never done that so it's not usual for me :)
<alkisg> I've uploaded to my ppa, but nowhere else
<tumbleweed> alkisg: do you have the rights to upload this then?
<alkisg> tumbleweed: I believe so, I'm in edubuntu council which should indirectly put me in ubuntu-developers
<Laney> Is the edubuntu council supposed to confer developer rights?
<alkisg> I'm not sure. I'm also an edubuntu-developer, if that makes a difference.
<tumbleweed> alkisg: you need to be MOTU to upload arbitrary universe packages, if the package is in the edubuntu packageset then you can probably upload
<Riddell> ev, rgreening: how would you feel about a usb-creator upload?  I just fixed the kde frontend which had an issue that stopped it starting with the new PyQt
<tumbleweed> (easiest way to tell is to try) :)
<alkisg> Thanks tumbleweed, /me tries to find some wiki page about "uploading to ubuntu as usual" :)
<tumbleweed> alkisg: dput ubuntu foo.changes
<alkisg> Thanks
<Laney> alkisg: Have you had sponsored uploads before?
<alkisg> Laney, no
<alkisg> (this particular package requires no source changes, just a version bump)
<rgreening> Riddell: is there a bug/patch? ev does releases, but I can commit to bzr and bug/poke him to release
<Laney> hmmmmm
<Riddell> rgreening: I've already committed to bzr
<rgreening> k
<cjwatson> asac: sorry, it is not.  The blacklist syntax ("!") is a much bigger hammer that has effects you don't want - see germinate(1) for discussion
<asac> cjwatson: so what can i do to achieve this? is only way to fork desktop-common and modify and then regularly sync?
<cjwatson> asac: the upstream seed needs to be refactored
<cjwatson> (or else you need to fork)
<ivoks> i would appriciate guidance in one problem; is predepend justified if i have a package that requires mysql up and running before that package is configured? is there another way out (triggers or something)?
<cjwatson> depends is sufficient to have something happen before the package is configured
<ivoks> but depending on mysql doesn't guarantee that package would be able to populate database
<ivoks> mysql could be stopped during package's configure stage
<cjwatson> pre-depends won't help in the least
<ivoks> ok, is there other way out?
<cjwatson> don't know, look for other packages that depend on mysql for this kind of thing maybe
<ivoks> ok, thanks
<ivoks> well, everything else is broken too :)
<ivoks> 'broken'
<happyaron> kees: ping
<LukeD_> hi guys, I have a question about building gcc on x86_64, can anyone point me to the right ubuntu irc to ask about it?
<zul> can someone from the foundations team review the upstart scripts in bug #612975 and bug #612958
<ubottu> Launchpad bug 612975 in dhcp3 (Ubuntu) "Please convert init scripts to upstart." [Undecided,New] https://launchpad.net/bugs/612975
<ubottu> Launchpad bug 612958 in samba (Ubuntu) "Please convert winbind init script to upstart." [Undecided,New] https://launchpad.net/bugs/612958
<geser> ivoks: wouldn't that require that the app and the mysql db are on the same host?
<ivoks> geser: it would
<ivoks> geser: which isn't that bad since dbconfig-common with low priority assumes localhost
<ivoks> er... high priority
<ivoks> having mysql triggers which would be populated by dbconfig-common sounds like a solution
<geser> ivoks: wouldn't moving e.g. mysql-client to recommends in dbconfig-common fix it too? make mysql available by default but leave the opportunity to have a remote db and no need to have mysql installed just for the dependency
<ivoks> but if you want db on localhost, dbconfig will fail if mysql-server isn't installed
<ivoks> dbconfig really depends on mysql-client cause it needs it to populate database :)
<geser> I'm not sure if recommends are handled the same in installation order but recommending mysql-server in dbconfig-common doesn't work?
<ivoks> haven't tried it
<geser> IIRC depends should be enough for your case as IIRC the dependencies of a package get configured before the package itself
<geser> and what should happen if mysql is already installed but the admin stopped it?
<ivoks> same thing
<ivoks> depends is not enough
<ivoks> you get package installed and configured before mysql is configured
<ivoks> and if it's a service, it won't start and just die on postinstall
<ivoks> anyway, i'll think more about it later... take care
<smoser> cjwatson, are you around ?
<dpm> hi pitti, I believe you are the maintainer of langpack-locales. May I ask you to have a look at bug 124987? There is a patch available, but I'm not sure it can be used as is
<ubottu> Launchpad bug 124987 in langpack-locales (Ubuntu) "Month names in Russian Localization should be in lowercase" [Low,Triaged] https://launchpad.net/bugs/124987
<dpm> (I know they should eventually send the patch upstream, though)
<Damascene> hi, when is the meeting
<ScottK> Who is our "d-shlibs maintainer"? http://launchpadlibrarian.net/52996671/buildlog_ubuntu-maverick-armel.uw-imap_8:2007e~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz
<cjwatson> smoser: what's up?
<Chipzz> zul:
<Chipzz> +[ -f /etc/default/dhcp3-relay ] && ./etc/default/dhcp3-rlay
<smoser> would you be opposed to carrying a 'mbchk' in grub2? I need a reliable way to determine "is this a multiboot file", and I couldn't find any way to do so with grub2, but grub1's mbchk does exactly that.  I could write something, but don't really see the point in copying.
<Chipzz> typo
<zul> Chipzz: thanks
<Chipzz> you're missing a space after the .
<Chipzz> and a second one
<Chipzz> rlay instead of relay
<Chipzz> also
<Chipzz> I see no upstart script for the version built with ldap support
<cjwatson> smoser: I'm opposed to carrying it specifically in Ubuntu, but perhaps you could get in touch with upstream about it?
<cjwatson> smoser: I don't imagine anyone would object to porting it over (maybe as grub-mbchk)
<smoser> upstream as in grub? or debian? i'm fine with bringing it up to either.
<cjwatson> smoser: upstream upstream
<smoser> yeah. ok.
<rsavoye> did something happen with OpenJDK packaging in the last 24 hours ? Icedtea can't find the source package anymore
<pitti> dpm: can do
<dpm> pitti, awesome, thanks!
<ara> pitti, I am removing the .la from the libmtdev-dev package, but I would like to take the opportunity to learn more about the -dev packages, .la files and how they are considered harmful
<ara> pitti, where can I find information about it?
<Keybuk> mvo: why would update-manager hang when installing updates?
<seb128> Keybuk, hang or being very slow and use cpu?
<Keybuk> seems to freeze entirely after clicking "Install"
<Keybuk> (not my computer, family member's)
<seb128> ok, dunno then
<Keybuk> no, me neither
<mvo> Keybuk: might be a policykit issue? does ps afx show anything interessting?
<Keybuk> mvo: no idea, I'm not entirely sure I can get mother to open a terminal
<mvo> Keybuk: *ick* is that lucid?
<Keybuk> yeah
<alkisg> Keybuk: vnc can be handy in such cases :) x11vnc -connect <your-ip> to bypass NATs, firewalls etc.
<Keybuk> is that something she'd run that'd give me her screen?
<pitti> ara: they usually specify too many dependencies, so that auto-generated Depends: fields of packages carry way too many dependencies; this is a problem for library transitions
<pitti> ara: and those .la files are generally not needed on Linux; it's just a PITA to get rid of them
<ara> pitti, thanks for the explanation :-)
<Keybuk> pitti: *disagree*
<rsavoye> No package 'mozilla-plugin' found
<rsavoye> did something change yesterday ? I'm getting tons of new failures with packages trying to build icedtea and OpenJDK
<chrisccoulson> rsavoye, it's probably a silly question, but do you have xulrunner-dev installed? that provides mozilla-plugin.pc
<rsavoye> arg.... look slike build-dep missed some things...
<rsavoye> I'm also having problems (on maverick) finding the OpenJDK source
<rsavoye> I guess this is what I get by doing a full reinstall on my beagleboard...
<ion> keybuk: Bug #458299 perhaps.
<ubottu> Launchpad bug 458299 in linux (Ubuntu Lucid) "apparmor_parser: page allocation failure. order:5" [High,Fix released] https://launchpad.net/bugs/458299
<chrisccoulson> mvo - my girlfriend sees the "update-manager hanging when pressing the install button" on lucid too
<chrisccoulson> but it only happens on her account (it works fine on mine)
<chrisccoulson> and it only happens when u-m is autospawned from u-n (if i open u-m from the terminal, then it works fine)
<ion> keybuk: That one can make the system slow enough to be utterly unusable whenever something triggers the reload of apparmor profiles when upgrading.
<mvo> chrisccoulson: oh, i know - no policykit auth agent running?
<mvo> ^--- seb128
<chrisccoulson> mvo - that shouldn't matter for lucid though should it? (it's still using gksu)
<mvo> seb128: for what users is the polkit auth agent started?
<ion> keybuk: Oh, it seems a fix has been uploaded. Iâm not sure whether iâve encountered the bug since that or not.
<mvo> chrisccoulson: hrm, right
<chrisccoulson> mvo - the agent is started for all users
<mvo> chrisccoulson: ok, that was not the one then. she is in the admin group, right?
<seb128> mvo, right, the issue is only for the maverick version I think
<mvo> seb128: yeah, sorry. I had a similar issue in mav
<seb128> mvo, and it doesn't hang just goes back to the ui as if you hadn't clicked
<chrisccoulson> mvo - yeah, she's in the admin group (but she wasn't originally)
<mvo> chrisccoulson: hm, hm, if its reproducable, can we debug it together at some point (does not have to be now)?
<chrisccoulson> mvo - yeah, sure. i'll log in to her account at some point and see if i can get it to happen again
<chrisccoulson> i keep asking her why she's not updating the computer, and she keeps telling me it's because "It doesn't do anything when i press the install button" ;)
<mvo> chrisccoulson: please, maybe we can even track it down and fix for 10.04.1
<mvo> chrisccoulson: just a ps afx dump will be helpful for a start
<ion> keybuk: In any case, see if she has an âapparmor_parser: page allocation failureâ line in syslog.
<ion> keybuk: Oh, i misread your initial line, thinking her whole system hangs.
<dholbach> pitti: the mtdev .la fix was uploaded :)
<Keybuk> no, just update-manager
<mvo> Keybuk: just update-manager in ps afx ? or what does the "just" referes to?
<Keybuk> just update-manager hangs
<Keybuk> haven't got a ps :-/
<Keybuk> she's gone out now :p
<mvo> Keybuk: hrm, thats bad, so everything else works fine. did it happen the first time for her?
<chrisccoulson> mvo - ok, i can't get it to reproduce when i actually want it too ;)
<mvo> chrisccoulson: the best kind of bugs :(
<rsavoye> openjdk-6-source has a package dependency problem
<rsavoye> penjdk-6-source : Depends: openjdk-6-jre (>= 6b20~pre2-0ubuntu2) but 6b18-1.8-2ubuntu2 is to be installed
<micahg> rsavoye: what chipset do you have?
<rsavoye> this is on an XM board, running maverick
<micahg> rsavoye: is that armel?
<rsavoye> yeah
<micahg> rsavoye: armel's currently broke for openjdk
<rsavoye> I know, I'm trying to fix it...
<rsavoye> I had been running a patched kernel, then last night installed ubuntu-maverick-alpha2-minimal-armel.tar.7z
<rsavoye> major issues with build-dep and icedtea6-plugin
<apw> Riddell, i hear you are archive admin of the day ... we have some packages which are in need of removing and seem to be hanging about: details at the end of bug #595949
<rsavoye> which was working yesterday. COurse maybe I screwed something up too
<micahg> rsavoye: so, you probably want to pull down the .deb source
<ubottu> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) "linux-meta-ti-omap depends on the wrong binary kernel in maverick" [Low,In progress] https://launchpad.net/bugs/595949
<micahg> rsavoye: apt-get source openjdk-6
<rsavoye> I did , it installed, but I get other erro5rs
<rsavoye> E: Unable to find a source package for openjdk-6
<Riddell> apw: ok will do
<rsavoye> which was there yesterday...
<micahg> rsavoye: you need to enable the deb-src repo in sources.list
<rsavoye> I did, but maybe got the URL wrong
<rsavoye> I just grabbed the deb-src from my ia32 maverick machine, which used to work...
<micahg> rsavoye: you can dget this: http://archive.ubuntu.com/ubuntu/pool/main/o/openjdk-6/openjdk-6_6b20~pre2-0ubuntu2.dsc
<rsavoye> what's weirder is I build icedtea with --with-openjdk-src-dir=, so who cares about the source package ?
<rsavoye> I'll dig into it, I must be doing something wrong on my end
<rsavoye> the problem being apt-get build-dep is broke, so I have to install them by hand
<rsavoye> unfortunately, all the package error messages are for Fedora 13...
<tantiv> For some reason only partimage-i386 (not amd64) is in the Ubuntu respository.... two years ago there was an amd64 bug which is probably why it was never put into amd64.  However the most recent version (including the source in the Ubuntu repository) fully supports amd64 and I tested it after running dpkg-buildpackage myself.  Who should I go to, to get it released into the amd64 repository?
<rsavoye> my problem turned out to be a bad deb-src URL, now build-dep works again
<seb128> StevenK, can you set https://code.edge.launchpad.net/~bluetooth/ubuntu/lucid/obexd/main/+merge/24151 to merged? it seems only teams members can do that
<pitti> ogra: if you are still online, new efl launcher could be uploaded in 15 mins
<ogra_cmpc> pitti, i hope asac sees that :P
<pitti> ogra_cmpc: no, he's already offline
<ogra_cmpc> pitti, i know, but he has everything prepared
<ogra_cmpc> i dont even have the branch here
<seb128> ev: hi, could you get bug #538744 review? not sure if the bug or change still make sense but would be nice to clear it from the sponsoring queue
<ubottu> Launchpad bug 538744 in ubiquity (Ubuntu) "Partition dialog doesn't show partitions in top bar" [Low,New] https://launchpad.net/bugs/538744
<seb128> ev: same for bug #546445 if you can
<ubottu> Launchpad bug 546445 in ubiquity (Ubuntu) "Support for lxdm in ubiquity (autologin, only-ubiquity support)" [Wishlist,Confirmed] https://launchpad.net/bugs/546445
<ev> seb128: responded
<ev> okay
<seb128> ev: thanks!
<SpamapS> mathiaz: v2 of rubygems draft sent.
<mathiaz> SpamapS: gotcha
<SpamapS> mathiaz: still feels a bit long, but I think removing a lot of the FHS quotation helped narrow the focus
#ubuntu-devel 2010-08-04
<Deist> Hi!
<Deist> Sorry, in a bit of a mess with some c++ programing.
<Deist> ah, sorry. wrong channel.
<Deist> Hi!
<Deist> Sorry, in a bit of a mess with a c++ programing code.
<lucas> still wrong channel :-)
<Deist> hah
<Deist> what channel am i suppose to ask?
<lucas> probably not this one. This one is for "Development of Ubuntu (not support, not app development)" (see the topic)
<Deist> ah
<Deist> closed the wrong cannel window :P
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch
<bilalakhtar> good morning pitti
<dholbach> good morning
<bilalakhtar> dholbach: good morning
<dholbach> hey bilalakhtar
<bilalakhtar> dholbach: meeting's over
<dholbach> bilalakhtar: I saw you're universe-contributor now - congratulations
<bilalakhtar> dholbach: Thanks for your support and endorsement!
<dholbach> :-)
<dholbach> no worries
<pitti> kees: did we actually enable the default umask change to 002 in maverick now?
<dholbach> can somebody please review this? https://code.edge.launchpad.net/~marcelstimberg/ubuntu/lucid/gzip/gzip-fix-524366/+merge/27890
<dholbach> MWelchUK_work_ can probably answer questions about it ^
<MWelchUK_work_> Shame I missed the question :-)
<MWelchUK_work_> !logs
<ubottu> Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/
<pitti> MWelchUK_work_: can you please add the corresponding test case as well?
<MWelchUK_work_> Sorry - I'm not the author of the patch, just a stuck user :-(
<pitti> right, I know
<MWelchUK_work_> (I can't migrate off of 8.04 until this is fixed)
<pitti> the test case is in the upstream commit, too
<pitti> MWelchUK_work_: oh, sorry, so you aren't Marcel Stimberg
<MWelchUK_work_> Nope :-)
<pitti> dholbach made it sound like you were the one proposing the merge
<dholbach> I thought he was
<MWelchUK_work_> Afraid not.
<MWelchUK_work_> pitti, Thanks for the review.
<ara> pitti, I uploaded a new version of mtdev that does not install the .la file. Can you please review and accept it in the binary archive?
<pitti> ara: no, I can't
<pitti> ara: I already did that yesterday :)
<ara> pitti, ah, OK :-) thanks, then
<tseliot> ara: you might want to ask cjwatson today, at least according to the wiki: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
<pitti> SpamapS: so, I now regularly get DB timeouts from work item tracker -- seems the charts/reports now take more than an hour to generate; wasn't the intention to limit per-user charts to some teams?
<pitti> it now generates 1858 files every hour!
<pitti> (per-user)
<lifeless> pitti: DB timeouts ? LP ones or ???
<pitti> lifeless: no, WI tracker sqlite db
<pitti> i. e. next hour cronjob already kicks in while the previous one is still running
<lifeless> ah heh
<TheMuso> ouch
<nigelb> Daviey: How complicated was setting up an etherpad instance for ubuntu-uk?
<Daviey> nigelb, Pretty trival once the depends are satisfied
<Daviey> .. There is now a apt repo
<nigelb> Daviey: oh wow, apt-repo sounds really cool
<Daviey> nigelb, I've not used it tho..
<nigelb> Daviey: I'll try it out :) Thanks :)
<Daviey> nigelb, Just be prepared to throw significant resources at it
<nigelb> Daviey: ouch, how intensive is it?
<nigelb> 512MB is okay or it eats more?
<Daviey> Hmm.. that is pretty much the minimum - this server (oddly) has 818MB of RAM and etherpad is using 65%, and the whole system is marked at   711MB in use and 721MB in swap (but that is caching).
<nigelb> Daviey: the server I'm going to run it on has 2 GB of ram, but then it has a jabber server and apache
<Daviey> nigelb, I'm sure it will be ok.. give it a spin
<highvoltage> http://packages.ubuntu.com/maverick/ <- anyone happen to know what the blocker is for getting that fixed?
<geser> highvoltage: getting hold of someone with access, cjwatson might know the current status
<pitti> jdstrand: do you have any idea about bug 606163? does this need a kernel log to actually see the violations?
<ubottu> Launchpad bug 606163 in dhcp3 (Ubuntu Maverick) "apparmor profile for dhcp3-client is too strict" [High,Confirmed] https://launchpad.net/bugs/606163
<pitti> jdstrand: (it's marked for alpha-3)
<jdstrand> pitti: hey. reading
<pitti> it clearly doesn't happen for everyone
<pitti> otherwise hell would have broken loose a long time ago
<cjwatson> highvoltage: I filed a ticket with our sysadmins - it's awaiting a response
<jdstrand> pitti: this is probably a dupe of bug #599450
<ubottu> Launchpad bug 599450 in linux (Ubuntu Maverick) "[apparmor] getattr handled incorrectly in 2.6.35-6.7" [High,Fix released] https://launchpad.net/bugs/599450
<pitti> or it did, and everyone who wanted to tell us was now offline :)
<pitti> jdstrand: ah, thanks
<jdstrand> pitti: so the reporter can retest
<pitti> jdstrand: thanks! I'll follow up
<jdstrand> sure thing
<pitti> JontheEchidna: hello, how are you?
<JontheEchidna> pitti: pretty good
<pitti> JontheEchidna: bug 600606 says that you have a fix for the FTBFS?
<ubottu> Launchpad bug 600606 in kubuntu-notification-helper (Ubuntu Maverick) " fails to build from source in maverick" [High,Fix committed] https://launchpad.net/bugs/600606
<pitti> JontheEchidna: that bug is marked for alpha-3; I'm fine moving it, but I wondered if it could just be done now, to get it off the list
<JontheEchidna> pitti: yes, it's been committed to bzr, but other changes in bzr are waiting on an MIR for a new runtime dependency
<pitti> JontheEchidna: ah, ok; it's not an alpha-3 blocker, so is it ok if I move the bug to beta?
<JontheEchidna> pitti: sure. as long as it gets fixed by release it shouldn't block anything
<pitti> JontheEchidna: ok, thank you
<pitti> ogra: do you have a gut feeling whether bug 605488  and bug 605739 are serious enough to block alpha-3 on armel? or should we just move to beta?
<ubottu> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) "BUG: scheduling while atomic: mmcqd/46/0x00000002" [High,In progress] https://launchpad.net/bugs/605488
<ubottu> Launchpad bug 605739 in linux-ti-omap4 (Ubuntu Maverick) "BUG: Bad page state in process swapper pfn:94d23" [High,In progress] https://launchpad.net/bugs/605739
<ogra> just move them
<pitti> 605739  seems to have an upstream patch, but 605488 doesn't show any progress
<pitti> ogra: ok
<ogra> we dropped swap for the moment
<pitti> ah, so workaround
<ogra> i will only enable the sawpfile/partition creation once the kernel is fixed
<pitti> ogra: and for 605488 it seems that it doesn't actually halt the system, you just get this in dmeg?
<pitti> dmesg
<ogra> thats the MMC issue i mentioned before
<ogra> we wont get any fixes for either bug in, so just move them
<pitti> ogra: well, if it completely breaks boot, then we don't need to release alpha-3/armel at this point; we could release images later on when we have a fix
<pitti> it doesn't sound like it would break boot, but I wanted to confirm
<ogra> it breaks booting on certain HW, not on all
<ogra> but waiting for a kernel fix would take us days
<pitti> release note then?
<ogra> the archive would be out of sync agaion etc etc
<ogra> yeah, we definately need something like "doesnt boot on XM boards"
<ogra> though given the board isnt sold yet i dont think its important anyway :)
<pitti> ogra: ah, you already know those? please feel free to add to https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview#Known%20issues, otherwise I'll invent something
<pitti> ogra: ah, that'd help :)
<ogra> heh
<ogra> only the beagle C4 is available and that doesnt really meet the minimal HW reqs for netbook
<ogra> the actual arches we work for are all non existing :)
<pitti> JontheEchidna, Riddell: is bug 586497  already fixed in maverick? it was SRUed, but it didn't say that it was backported from maverick
<ubottu> Launchpad bug 586497 in kpackagekit (Ubuntu Maverick) "kpackagekit install security update in automatic mode without authorization" [High,In progress] https://launchpad.net/bugs/586497
<Riddell> hmm, checking
<JontheEchidna> looks like it was fixed in maverick too
<pitti> \o/
<JontheEchidna> http://launchpadlibrarian.net/50536327/kpackagekit_0.5.4-0ubuntu5_0.6.0-0ubuntu1.diff.gz
<JontheEchidna> +++ kpackagekit-0.6.0/debian/patches/kubuntu_06_no_automatic_updates.diff
<pitti> JontheEchidna: thanks
<Riddell> yes, although it doesn't seem to be in the changelog, that's strange
<pitti> ok, that makes https://bugs.edge.launchpad.net/ubuntu/maverick/+bugs?field.searchtext=&orderby=status&field.milestone%3Alist=27561 look much better now
<pitti> and I guess the ureadahead armel OOM is something for release notes
 * pitti comments on the bug
<dholbach> can somebody have a look at the ACKed syncs?
<seb128> dholbach, can do
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<dholbach> seb128: Jono had a mumble problem and I saw there was a sync open for it
<kees> pitti: I wasn't involved in the umask change, no.
<mathiaz> jjohansen: hi!
<jjohansen> mathiaz: hey
<mathiaz> jjohansen: it seems that the linux-virtual kernel now returns linux-virtual from uname -r
<mathiaz> jjohansen: http://paste.ubuntu.com/473154/
<mathiaz> jjohansen: is this something new in maverick?
<jjohansen> hrmm, yes
<jjohansen> virtual became a true flavor
<jjohansen> previously, -virtual was a subflavor of -server
<jjohansen> so it got the -server name appended, but with it being a true flavor it now gets -virtual
<mathiaz> jjohansen: -server on amd64 and -pae on i386
<mathiaz> jjohansen: starting from maverick -virtual on both amd64 and i386?
<jjohansen> mathiaz: right, so now it should be -virtual on both
<jjohansen> yep
<mathiaz> jjohansen: great - thanks for the help
<pitti> cjwatson: hm, usb-discover needs to be ported to discover-data (also in debian), discover1-data is NBS
<pitti> cjwatson: are you already planning this, or want me to have a look?
<pitti> it's the only remaining rdepends
<pitti> ttx, ScottK: hm, what happened to dovecot-postfix? it's NBS in maverick, but I don't see a transition path?
<pitti> oh, mail-stack-delivery, nevermind
<pitti> but that didn't exist in lucid, so we need dovecot-postfix as a transitional package until the next LTS
<pitti> so can you please reintroduce it?
<pitti> zul: ^
<zul> pitti: ack
<ScottK> pitti: IIRC there was a transitional package when last I touched it.  Not sure how it got dropped.
<shabbu> need help:  My pen drive is in write protection. How can i remove write protection in ubuntu 10.04?
<Pretto> does anyone had this problem using anjuta on ubuntu 10.04?? Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:196, function pa_tls_set(). Aborting.
<slangasek> cjwatson, lool: should xdeb use launchpad for upstream bug tracking, or should bugs be filed directly against the Ubuntu package?
<sbronsted> Question: How often is http://qa.ubuntuwire.org/ftbfs/ updated? I was look at httpcomponents-core but when I do pbuilder on the source there is no error
<kiko> crimsun, hey there
<kiko> have a second for a small bug?
<Pici> Hes been idle for two days... so likely not.
<pitti> ScottK: seems the last merge dropped it or so; seems zul's on it
<ScottK> OK.
<kiko> thanks Pici :-
 * soren hugs seb128 for the python-lockfile sync
<seb128> soren, ;-)
<mr_pouit> seb128: thanks for the syncs. At last there's no delta with goffice in debian. ;)
<seb128> yw ;-)
<seb128> thanks for getting the change in debian
<ari-tczew> cjwatson: could you merge package 'parted'? it's needed for build package
<ari-tczew> 'pyparted'
<maco> ugh, male enhancement spam on ubuntu-devel@l.u.c
<soren> And now in #ubuntu-devel :)
<micahg> thank you to whoever just ran through all the sync requests (thinking it Riddell)
<micahg> no, I guess it was seb128 <-- thanks :)
<geser> yeah, seb128 did them this time. thanks
<seb128> yw ;-)
<ScottK> Did we decide to skip the Alpha 3 freeze?
<ScottK> Seems like lots of Main uploads today.
<pitti> ScottK: no, I sent it yesterday
<maco> soren: i didnt give the link :P
<soren> maco: Don't worry, I googled for it. :)
<maco> soren: oh thats what you want in your browser history :P
<soren> maco: Hey, it's not my fault I'm highly suggestive.
<soren> :)
<highvoltage> being highly suggestive is my biggest weakness
<highvoltage> (I guess I shouldn't say that publicly :) )
<highvoltage> (and I actually meant "suggestable")
<soren> Err.. Yeah, s/suggestive/suggestible/ for me, too.
<soren> highvoltage: Good catch :)
<highvoltage> well I can be quite suggestive too, seems like it works both ways :)
<ScottK> cjwatson: Is there any intent to move to parted 2.3 in this cycle?  pyparted in Universe is currently depwait on >= 2.3, so if not, we'll need to do something with it.
<ScottK> DktrKranz: ^^^ It appears to be your pyparted upload that's not building.
<ari-tczew> ScottK: I endorsed the same 1 hour ago :)
<ScottK> ari-tczew: I see that now.  I'd rather see what cjwatson plans for parted and then adjust pyparted accordingly.  Looks like it will need a patch added back if parted isn't updated.
<ari-tczew> what about getting latest debhelper into ubuntu?
<andreserl> anyone expert in Python available to give me a hand around?
<RoAkSoAx> Anyone expert in Python and subprocess available to give me a hand around?
<geser> why this high demand for Python experts right now?
<micahg> geser: same person :)
<RoAkSoAx> geser: yep same person, :)!
<geser> RoAkSoAx: I'm no expert but perhaps I can still help. What's the problem?
<RoAkSoAx> geser: ok. For TestDrive-gtk I want to display the rsync progress. However, rsync shows the progress in 1 single line, and to capture the progress I'm doing something like: http://pastebin.ubuntu.com/473259/
<tumbleweed> RoAkSoAx: what's with the massive while loop?
<tumbleweed> RoAkSoAx: cmd = command.split()
<tumbleweed> ^ that probably does what you want
<geser> I've the same question about this part
<RoAkSoAx> tumbleweed: geser : the massive while loop just puts 'rsync -azP etc etc' into an array for subprocess
<geser> RoAkSoAx: like tumbleweed said "cmd = command.split()" gives you an array and the doc for Popen says that a string it also ok
<tumbleweed> geser: IIRC a string is only ok if you use shell=True
<RoAkSoAx> anyways, thge thing is that rsync displays the output in the way of: http://pastebin.ubuntu.com/473270/ and keeps updating that 4th line with the progress. However, when I run the script it diusplays only the first 3 lines: http://pastebin.ubuntu.com/473273/, and displays the 4th when rsync is done. Some I'm wondering how to do to grab that 4th line update with the progress
<tumbleweed> RoAkSoAx: rsync detects that it's not being run in a terminal, and doesn't output status
<RoAkSoAx> tumbleweed: geser: Yes, an string is good when using shell=True, but I'm not using that
<tumbleweed> RoAkSoAx: seriously, try simpler solution I gave you
<tumbleweed> (this isn't C, it's python)
<RoAkSoAx> tumbleweed: it outputs the status of the progress when rsync finishes syncing, or when for example, I kill the rsync process
<tumbleweed> s/status/progress/
<RoAkSoAx> tumbleweed: using shell=True?
<tumbleweed> RoAkSoAx: no
<RoAkSoAx> tumbleweed: then I think i missed your solution. What is it again?
<RoAkSoAx> cmd = command.split()
<RoAkSoAx> ?
<RoAkSoAx> instead of the loop?
<tumbleweed> RoAkSoAx: it's not a solution to your problem, i'm saying you can replace lines 4..12 with cmd = command.split()
<RoAkSoAx> tumbleweed: oh yep, I'm gonna do that thanks :). However, no ideas for my problem?
<geser> RoAkSoAx: why not write command as a list in the first place? "command = ['rsync', '-azP', ...]
<tumbleweed> RoAkSoAx: there are python rsync modules, maybe one of them can help you
<tumbleweed> but I don't see any easy way to persuade rsync to output progress
<RoAkSoAx> geser: because the way how testdrive did it initially was tu run a command directly, however, in testdrice-cli it still uses it that way, but in the -gtk I need the array given that I'm running the sync in a subprocess + threads
<RoAkSoAx> tumbleweed: ok I'll investigate that! Thanks :)
<pitti> superm1: mythbuntu has failed to build for some days (see http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/mythbuntu/20100803/livecd-20100803-i386.out); are you interested at all in an alpha-3 release, or do you want to skip it?
<RoAkSoAx> geser: and by directly I mean with os.system()
<tumbleweed> RoAkSoAx: to see what I mean, try this: rsync -azP foo bar | cat
<tumbleweed> err, I screwed up, RoAkSoAx it will work
<tumbleweed> RoAkSoAx: just look for \r to find the new line of output
<RoAkSoAx> tumbleweed: that's the thing, the progress update is done in one single line, which makes my script to hang up when reading that exact line.
<tumbleweed> RoAkSoAx: don't do readline(), read a handful of bytes at a time, and you know you've got a new line when you see \r
<RoAkSoAx> tumbleweed: ok. btw I;'ve just found same issue here with no solution yet: http://stackoverflow.com/questions/1606795/catching-stdout-in-realtime-from-subprocess
<tumbleweed> RoAkSoAx: http://paste.debian.net/82254/ all that's left is parsing the output with a regex (but I'd still see if there's a nice python library that make sthis easy)
<RoAkSoAx> tumbleweed: awesome!! thanks a lot :)
<tumbleweed> RoAkSoAx: assuming the output is always 43 chars, long, you can self-synchronise: buff += sync.stdout.read(min(16, 43 - len(buff)))
<RoAkSoAx> tumbleweed: :) thanks for the tips :)
<tumbleweed> RoAkSoAx: be aware that you now have to kill the rsync if your program dies
<tumbleweed> actually, no it should SIGPIPE
<RoAkSoAx> tumbleweed: I'll see what happens when I do that in a thread though
<SpamapS> wow.. seems like mdadm needs some bug fixing love https://bugs.launchpad.net/ubuntu/+source/mdadm
<superm1> pitti, we were interested, just been a little behind in testing :)
<superm1> i'll take a look right now
<dupondje> do we plan to upgrade mdadm btw ?
#ubuntu-devel 2010-08-05
<fargiolas> does ubuntu default installation includes udev extra stuff? I received a bug report in cheese about missing v4l_id in an almost fresh install of ubuntu 10.04
<ion> The udev package comes with v4l_id.
<fargiolas> ion: thanks, I wonder how the reporter managed to remove it
<ajmitch> fargiolas: the reporter says that they do have it, if you're referring to bgo #625999
<fargiolas> ajmitch: uh definitely shouldn't read bugmail at 3 am
<fargiolas> ajmitch: you're right
<ajmitch> hehe :)
<fargiolas> thanks :P
 * ajmitch has no idea about what the udevadm output is meant to be showing though
<ajmitch> I just know that cheese does work with lucid & my HP laptop :)
<fargiolas> ajmitch: it should show three properties ID_V4L_VERSION, ID_V4L_PRODUCT and ID_V4L_CAPABILITIES
<lool> slangasek, cjwatson: I think tracking xdeb bugs just in Ubuntu is enough as long as it isn't used outside of Ubuntu; releases are effectively happening in Ubuntu
<porthose> If there is an archive admin around I would like to request a rebuild or darcs-2.4.4-2 please.
<ajmitch> porthose: you should be able to hit 'retry' yourself on LP
<porthose> ooh ok was not aware of that thx :)
<ajmitch> see https://edge.launchpad.net/ubuntu/+source/darcs/2.4.4-2/+build/1904438
<ajmitch> it should have Retry this build
<porthose> ajmitch, thx :)
<slangasek> lool: ack
<pitti> Good morning
<dholbach> good morning!
<dholbach> Packaging Training Session: Fixing Small Ubuntu Bugs in 18 minutes in #ubuntu-classroom
<pitti> ScottK:
<pitti> - * (openoffice.org-kde) [i386 amd64 powerpc armel]
<pitti> + * (openoffice.org-kde) [i386 amd64 powerpc] #powerpc oversized
<pitti> ScottK: I guess that was a typo?
<pitti> ScottK: ah, nevermind; next commit :)
<DktrKranz> ScottK: indeed. It's quite trivial to fix in case new parted isn't plan to land in maverick
<pitti> superm1: hm, I can't make sense of http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/mythbuntu/20100805/, the logs seem cut off; but they failed again :/
<ara> pitti, when you said yesterday, about the mtdev package, that "you already did" you were meaning that you already accepted it in the archive, or that you already were archive admin the previous day?
<pitti> ara: I accepted it on Tuesday already
<ara> pitti, mmm, and how long does it take before it is actually available?
<pitti> it should have been available from Tuesday evening
<ara> pitti, ah, OK, it must be something with the mirror
<ara> pitti, thanks again!
<pitti> ibmtdev-dev | 1.0.6-0ubuntu2 | maverick/universe | amd64, armel, i386, sparc
<pitti>  libmtdev1 | 1.0.6-0ubuntu2 | maverick/universe | amd64, armel, i386, sparc
<pitti>      mtdev | 1.0.8-0ubuntu1 | maverick/universe | source
<pitti> mtdev-tools | 1.0.6-0ubuntu2 | maverick/universe | amd64, armel, i386, sparc
<pitti> looks good here
<pitti> apparently ia64 didn't build
<pitti> but I guess that's the least of your worries/
<pitti> ?
<ara> yes, that does not keep me from sleeping :)
<Adri2000> ccheney: any ETA on fixing bug #570147 ? could you please at least make a comment pointing to a fix or describing what the fix could be?
<ubottu> Launchpad bug 570147 in openoffice.org (Ubuntu) "[ooo-build] [3.2.1] lucid: no localization for find & replace dialog in writer" [High,In progress] https://launchpad.net/bugs/570147
<LucidFox> dholbach, nigelb, what would you say about changing the Behind MOTU theme? Someone I know has suggested moving away from the default WordPress one.
<dholbach> LucidFox: no opinion :)
<geser> mvo: bug #613756 should probably be moved to python-apt, right?
<ubottu> Launchpad bug 613756 in gdebi (Ubuntu) "AttributeError: 'DscSrcPackage' object has no attribute '_need_pkgs'" [Undecided,New] https://launchpad.net/bugs/613756
<mvo> geser: yes please
<pitti> superm1: ah, log synced now, but still the same problem as it seems
<pitti> superm1: it needs to build against libmpcdec6?
<LucidFox> dholbach, the WordPress admin interface also lists you as the administrative contact
<LucidFox> I wonder
<LucidFox> maybe we could create a Launchpad team and a mailing list, and send the contact there?
<JamesWStubbs> Hello, is porting Ubuntu a mobile device ( The Apple iPhone ) Considered appropriate in this room?
 * LucidFox blink-blink
<JamesWStubbs> ?
<JamesWStubbs> If it isn't please tell me and I'll go elsewhere,
<nigelb> LucidFox: +1
<nigelb> LucidFox: go for it.
<LucidFox> nigelb> Oh, you're here!
<nigelb> LucidFox: also if you're free later today, we could talk about how to go about taking interviews from now.  Probably in another 3.5 hours
<LucidFox> Sure!
<nigelb> LucidFox: yeah, at work.  busy day.
<LucidFox> Okay. I've created a Launchpad team with a mailing list, added you and bobbo
<LucidFox> the mailing list will apparently take some time to activate, though
 * nigelb hugs LucidFox 
<nigelb> you're awesome :)
<bdrung> tumbleweed: please don't forget to unsubscribe ubuntu-sponsors
<bdrung> pitti: ping
<pitti> hello bdrung
<bdrung> pitti: hi. why is the udev version '151-12'?
<bdrung> BlackZ: ^
<pitti> bdrung: there's a newer one in bzr, but Keybuk said it wouldn't boot
<bdrung> pitti: to be more specific: why is it 151-12 and not 151-0ubuntu12?
<pitti> bdrung: ah; Scott's decision
<bdrung> pitti: is it allowed to decide that the version clashes with debian?
<pitti> I'm not happy about it myself
<BlackZ> pitti: why the maintainer isn't Ubuntu Developers ?
<dholbach> LucidFox: for now I think we could just replace my name with somebody else
<LucidFox> In WordPress?
<dholbach> yep
<dholbach> LucidFox: shall I put you in ther for now?
<LucidFox> I've tried changing the contact email to the mailing list, but no email arrives and nothing is in moderation either
<LucidFox> I'll try changing it to mine
<LucidFox> huh, it did arrive
<LucidFox> changed the email
<vish> pitti: hi , when you get time could you merge this : https://code.launchpad.net/~evfool/jockey/proprietary/+merge/29254
<pitti> vish: it's still on my list
<vish> pitti: awesome thanks. [/me just trying to get it in before UIF :)]
<BlackZ> pitti: for udev: can't we just merge the package from debian?
<LucidFox> ...Great
<pitti> BlackZ: I'm afraid not; we use a pretty clean upstream packaging, and Debian uses its own set of rules still
<LucidFox> Yahoo is being "clever" and doesn't recognize Epiphany as a supported browser
<LucidFox> for its New and Improved mail
<BlackZ> pitti: ah, ok. Now it makes sense: so that's the reason why we have our own package in ubuntu and an ubuntu developer set as maintainer of the package?
<pitti> BlackZ: right; it's totally independent from the Debian version and is on the sync blacklist
<pitti> I'm still not quite happy about using Debianish version numbers, but oh well
<tumbleweed> bdrung: whoops, thanks
<bdrung> tumbleweed: for example bug #550261
<ubottu> Launchpad bug 550261 in One Hundred Paper Cuts "Backups cannot be started through the GUI" [Medium,Confirmed] https://launchpad.net/bugs/550261
<vish> tumbleweed: how do we check the package has been uploaded to -proposed?
<vish> is it still building?
<tumbleweed> vish: it's waiting on archive admin approval
<vish> tumbleweed: ah , cool ..thanks
<tumbleweed> bdrung: err, yes. I used to always unsubscribe sponsors but I noticed some other people don't when they mark incomplete
<bdrung> when marking as incomplete and requesting fixes, you need to comment that they should resubscribe u-s
<tumbleweed> bdrung: righto.
<ScottK> pitti: Did you respin kubuntu on powerpc?
<pitti> ScottK: no, sorry; misunderstanding; doing now
<pitti> ScottK: desktop, alternate, and/or DVD?
<pitti> dvd seems alright, I'll start with desktop
<tumbleweed> anyone know anything about the merges.ubuntu.com issue? Should a RT ticket be opened?
<superm1> pitti, that's weird, i just did a test build in my sbuild with no change rebuild and was able to install it fine...
<pitti> superm1: indeed; the build seems fine, but I don't see it in my chroot
<pitti> and nothing in NEW
<highvoltage> yay
<superm1> i think we might have to skip a3 then for now, i wont be able to look more until tomorrow or so :(
<pitti> superm1: ok..
<smoser> cjwatson, i would appreciate your thoughts on bug 613463
<ubottu> Launchpad bug 613463 in eucalyptus (Ubuntu) "[10.10 - Alpha 3 (candidate)] Prompts misleading grub dialogs during UEC Node installation." [High,Confirmed] https://launchpad.net/bugs/613463
<ScottK> pitti: Kubuntu desktop live powerpc is what I was looking for.
<pitti> ScottK: ah, good; it's on cdimage now
<ScottK> So it is.
<ScottK> No longer oversized, so it worked.
<dupondje> are there any plans to upgrade php5 in maverick ?
<ScottK> dupondje: 5.3.3 is planned after Alpha 3 is out.
<ScottK> NCommander, ogra, etc: I see Bug #504365  and Bug #579187 and am left deeply confused about the proper solution to http://launchpadlibrarian.net/52996671/buildlog_ubuntu-maverick-armel.uw-imap_8:2007e~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz - It looks like re-uploading the fix in 504365  would solve the FTBFS, but is somehow "wrong".  Help.
<ubottu> Launchpad bug 504365 in d-shlibs (Ubuntu) "[arm] typo of the dynamic load library prevents build-dependent packages from building" [High,Fix released] https://launchpad.net/bugs/504365
<ubottu> Launchpad bug 579187 in d-shlibs (Ubuntu) "Please sync d-shlibs 0.44 from Debian Unstable" [Medium,Fix released] https://launchpad.net/bugs/579187
<ogra> ScottK, cant help much here, i dont think the fix is wrong as a workaround, there seems to be no clean upstream solution though
<ScottK> ogra: Could you or NCommander take this on.  It's well out of my area and I'm not the one to argue with upstream about it.
 * ScottK just wants the package to build.
<ogra> ScottK, i'll ask NCommander about it and worst case re-add the ubuntu patch
<ScottK> Thanks.
<ogra> it served us well for karmic and lucid :)
<ScottK> ogra and NCommander: There's an NMU update in Debian you'll probably want to pick up at the same time.
<ogra> k
<dupondje> ScottK: great :) as alot of bugs fixed in it
<dupondje> ScottK: is there an SRU planned also?
<ScottK> dupondje: No idea.
<dupondje> 5.3.2-2 version in sid fixes lotsa bugs, would be nice to get it sru'ed
<ScottK> dupondje: I think SpamapS would be the one to ask.
<Chipzz> dupondje: I don't think "a lot of bugs" qualifies for an SRU?
<dupondje> Chipzz: http://packages.debian.org/changelogs/pool/main/p/php5/current/changelog check the changes in 5.3.2-2, think its nice it would be included in 10.04.1 no ?
<zul> dupondje: no it wont get srued as a whole but you can ask for a backport
<dupondje> maby not as a whole indeed, but some changes should be included
<sabdfl> hi folks, who's the expert on daily build packages? i'm hoping for a favour!
<Chipzz> dupondje: what I meant is, aren't SRU's meant to be *individual* changes, rather than a whole batch?
<Chipzz> individual -> specific, targeted
<Chipzz> dupondje: SRU's are, iirc, specifically not meant to fix a whole bunch of random changes; they're meant to fix high-impact bugs
<Chipzz> s/changes/bugs
<Chipzz> dupondje: and this:
<Chipzz>    * Upload PHP 5.3.3 to experimental for further testing
<Chipzz> is a TOTAL red herring
<dupondje> Chipzz: I don't say anything about 5.3.3 :) its 5.3.2-2 :)
<Chipzz> that still doesn't adres the other things I said
<Chipzz>    * Cherry pick patch to allow the timeout on mssql to be effective p/query
<Chipzz> I seriously doubt that such changes qualify for an SRU. By a VERY long shot
<dupondje> true, but    * Cherry pick patch to fix a memory leak in the cyclical gc for example should be added
<Chipzz> no it shouldn't?
<Chipzz> it doesn't fix a crash
<dupondje> it does
<Chipzz> not from the description it doesn't
<Chipzz> leaking memory is a very different thing than crashing
<dupondje> well the patch fixed a segfault for me. (http://www.dupondje.be/gdb.txt)
<Chipzz> I'm not saying leaking memory isn't bad; I AM saying it is seriously doubtfull such fixes qualify for an SRU
<Chipzz> then that is even more reason not to include it, unless you can clear out why the decsription differs from what it does
<Chipzz> I'ld say that quite the contrary, the fact that it does things which aren't in the description, makes it more likely that there are unwanted side-effects, making it unsuitable for an SRU
<tumbleweed> sabdfl: how big a favour? I've got one package I daily-build (no expert)
<sabdfl> tumbleweed: daily package of murrine and light-themes? murrine needs a git import (should Just Work on lp)
<sabdfl> cimi is doing some work for the Canonical design team and we want folks to be able t track it without having to build locally
<Chipzz> dupondje: but seriously, SRU's are not the free ticket to bug-fixes you seem to think they are
<tumbleweed> sabdfl: I'll have a shot at it
<Chipzz> dupondje: the whole point of SRU's is fixing bugs in a *controlled* manner; that means that we'ld rather live with bugs we *do* know, than fix those bugs "at random", possibly introducing new bugs
<dupondje> Chipzz: I know its not every bug is good for an sru, but this one looked ok to me (as it was causing a segfault)
<sabdfl> tumbleweed: can i send you mail with details?
<sabdfl> addy?
<tumbleweed> sabdfl: sure, stefanor@ubuntu
<Chipzz> dupondje: anyway, I don't decide what qualifies for an SRU and what doesn't; but from the look of it, this certainly doesn't
<sabdfl> thanks, if it's not straightforward that's ok, just tell me and i'll bring in the big guns :-) but i appreciate the offer of help!
<tumbleweed> hah :)
<Chipzz> like someone else mentioned before, you should cherry-pick the patches one by one, and make sure you understand what they do, and what their impact is
<sabdfl> tumbleweed: sent, and thanks again for having a shot at it
* pitti changed the topic of #ubuntu-devel to: Alpha-3 released! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Chipzz> dupondje: https://wiki.ubuntu.com/StableReleaseUpdates ; please read this and understand what it says
<dupondje> i'll do, thx Chipzz
<SpamapS> mathiaz: so, I really would like to mark ceph as "DONE" today and not "POSTPONED" ... is there anything more I can do to help you sponsor/review it?
<mathiaz> SpamapS: working on this now
<SpamapS> mathiaz: You are also my hero now.
<SpamapS> :)
<SpamapS> mathiaz: https://launchpad.net/clb  ... this is my proof of concept backend for node registration
<SpamapS> mathiaz: pretty lame but it works ;)
<mathiaz> SpamapS: is the ceph module in the maverick kernel?
<mathiaz> SpamapS: the ceph package fails to build
<mathiaz> SpamapS: in the debian/rules, src/logrotate.conf is copied to debian/
<mathiaz> SpamapS: and src/logrotate.conf doesn't exist
<SpamapS> mathiaz: oh hmm, I wonder if I just missed it on the import
<SpamapS> mathiaz: ok, I pushed a new one, and started a pdebuild on my system...
<mathiaz> SpamapS: next error while building the package: http://paste.ubuntu.com/473594/
<zul> there mysql 5.1.49, openldap 2.4.23 and php 5.3.3 uploaded
<SpamapS> zul: ^10
<SpamapS> mathiaz: clearly my merge from upstream's 0.21 tarball was incomplete. :(
<SpamapS> mathiaz: ok, I *think* the latest push fixes it.. takes a while to build though so I will confirm in about 20 minutes
<SpamapS> mathiaz: if nothing else I can confirm we're in sync with Sage's git repository
<mathiaz> SpamapS: ok
<mathiaz> SpamapS: I'm also looking that rrdtool merge
<SpamapS> mathiaz: cool.. I think I need to poke some people about the libdbi MIR
<SpamapS> mathiaz: I thought we only kept the changelog entries after the debian version...
<mathiaz> SpamapS: when merging we keep all of the changelog entries
<fta> any archive admin to reject python-pysnmp4/2010-07-29 from the lucid/proposed queue? i've uploaded a better version afterwards. https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=python-pysnmp4
<mathiaz> SpamapS: so that we know since when we've been doing changes and why
<SpamapS> mathiaz: Oh, thats actually not how I've done it up to now. :-/
<mathiaz> SpamapS: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/samba/maverick/annotate/head%3A/debian/changelog
<mathiaz> SpamapS: ^^ here is an example - the maverick branch for samba has lucid and hardy changelog entries
<SpamapS> actually wait
<SpamapS> no I have been doing that
<SpamapS> I just didn't realize it, because merge-o-matic did it for me
<SpamapS> seriously.. I don't know if one release cycle is long enough for Ubuntu dev status... there's just too many things to learn in 6 months. ;)
<mathiaz> SpamapS: :)
<mathiaz> SpamapS: we're learning all the time
<mathiaz> SpamapS: if you don't know and are unsure, better ask
<mathiaz> SpamapS: even when you're an Ubuntu core dev
<SpamapS> mathiaz: I have a very bad habit of "'tis better to ask forgiveness than permission" .. the sponsorship process is beating it out of me tho
<SpamapS> mathiaz: current package builds and installs
<mathiaz> SpamapS: /o\
<mathiaz> SpamapS: hm - It seems that there are some changes in the ceph bzr branch that haven't been included in the orig tarball
<mathiaz> SpamapS: doing lsdiff -z ceph_0.21-0ubuntu1.diff.gz shows some changes outside the debian/director
<mathiaz> SpamapS: debian directory
<SpamapS> mathiaz: the orig tarball changed on us
<mathiaz> SpamapS: well - if I take the tarball currently available from the usptream website
<SpamapS> mathiaz: hum
<mathiaz> SpamapS: it still seems that there are changes in the bzr branch
<SpamapS> mathiaz: the fact that we got a 0.21 that was not in fact 0.21 is driving me absolutely batty
<SpamapS> mathiaz: will diff against the tarball...
<mathiaz> SpamapS: IIUC you've merged all of the upstream git repo into the bzr branch
<mathiaz> SpamapS: so there may be some upstream changes that have been picked up while doing so
<mathiaz> SpamapS: there is a problem with that - the changes just need to be documented
<mathiaz> SpamapS: if they're bug fixes for the 0.21 release they may worth including
<SpamapS> mathiaz: the upstream tarball is broken I think.
<mathiaz> SpamapS: we just need to make sure we know what we're shipping
<mathiaz> SpamapS: and can figure out what changed
<SpamapS> mathiaz: right I'd rather ship w/ those things as patches
<SpamapS> mathiaz: the logrotate, and sbin/mkcephfs are the two issues I think
<SpamapS> mathiaz: the Makefile.am in the tarball puts mkcephfs in usr/sbin ... and logrotate.conf is not there at all
<mathiaz> SpamapS: right
<SpamapS> mathiaz: so maybe we ship w/ logrotate.conf already in debian (taking out the cp part of the rules file)
<SpamapS> mathiaz: and patch Makefile.am w/ quilt
<mathiaz> SpamapS: it's ok to include patches that fix these things so that it can build correctly
<mathiaz> SpamapS: seems like a solution to me
<mathiaz> SpamapS: I'd rather stick to 0.21 as close as we can
<SpamapS> mathiaz: agreed
<SpamapS> I'll push something momentarily
<mathiaz> SpamapS: great thanks
<SpamapS> mathiaz: I'll go ahead and let my build finish and test it a little, then push..
<mathiaz> kees: hi - would you mind looking at libdbi MIR - bug 608552?
<ubottu> Launchpad bug 608552 in libdbi (Ubuntu) "[MIR] libdbi" [Undecided,New] https://launchpad.net/bugs/608552
<kees> mathiaz: in a bit, sure. i'm trying to get through some security publications first
<mathiaz> kees: np - thanks!
<azeem_> W 40
<geser> ttx: as you sponsored the opendrim-* packages: they are currently in DEPWAIT on sfcb (multiverse). Should they get moved to multiverse too?
<neeraj> if a file inside source code, there is a filed Exec=@prefix@/bin/program
<neeraj> now I want to add a flag that i should always run in full screen mode
<neeraj> -f flag to be precise.
<neeraj> How should I add it..  Exec=@prefix@/bin/program -f will do?
<neeraj> or Exec=@prefix@"/bin/program -f"
<hyperair> the first one will do.
<RoAkSoAx> tumbleweed: Another way to what you help me do yesterday: http://pastebin.ubuntu.com/473686/
<ScottK> geser: I filed a bug asking for them to be moved already.
<geser> ok
<ScottK> geser: 613624
<geser> ScottK: some opendrim-* source packages are already in main, while their binaries are in universe. Do you know if a tool will notice this or are bugs needed to "fix" it?
<ScottK> geser: I just grabbed the ones that hadn't built yet due to depwait for 613624.  If moving ends up with some packages in Main/Universe depending on multiverse packages, I think that will get noticed.
<smoser> Keybuk, or slangasek maybe... or anyone... what causes mounted-varrun.conf to fire ?
<smoser> "start on mounted MOUNTPOINT=/var/run TYPE=tmpfs"
<smoser> does mountall just always mount a tmpfs on /var/run ?
<neeraj> ty hyperair
<Keybuk> well
<Keybuk> yes
<Keybuk> if mountall's config tells it to
<Keybuk> slangasek: so there's one problem with back-porting the manual/override stuff from 0.10 to 0.6
<smoser> Keybuk, mountall's config ?
<smoser> ah. i see. /lib/init/fstab
<slangasek> Keybuk: yes?
<Keybuk> slangasek: it's a big problem
<slangasek> Keybuk: it will crash the financial system?
<Keybuk> worse
<Keybuk> it means we have to come up for a name for the directory
<slangasek> Keybuk: heh
<Keybuk> since they're local overrides, rather than defaults, I did thing /etc/local/*.conf
<unimatrix> http://packages.ubuntu.com/maverick/ any idea what's going on here?
#ubuntu-devel 2010-08-06
<ari-tczew> unimatrix: packages.ubuntu.com is orphaned
<unimatrix> ari-tczew how so? is there a replacement?
<ari-tczew> unimatrix: in http interface? no
<jturek> hi guys, anybody running latest maverick, having their network wifi LED flashing on and off like mad?
<jturek> i don't know how to explain this in a bug report lol
<jturek> wifi is up and running, just the LED keeps flashing like its telling me morse code
<ansgar> How often do the moderators for ubuntu-devel-discuss@l.u.c approve messages?
<micahg> DktrKranz: are you familiar with yasm?  I see you touched the package about 2 yrs ago
<pitti> Good mornin
<pitti> (no 'g's just yet at this hour, sorry)
<ttx> geser: yes
<ttx> geser: sfcb depends on cim-schema, which still needs some work on licensing
<ttx> geser: so at this point it needs to live in multiverse
<ttx> and so do all the things that depend on it
<pitti> hey ttx, feeling better?
<ttx> pitti: slightly, meds starting to take effect. Thanks :)
<DktrKranz> micahg: no
<micahg> pitti: do you know about yasm?
<dholbach> good morning!
<pitti> micahg: I know it exists, not much else
<micahg> pitti: k, I'm wondering if I can update the package in Ubuntu since Debian isn't being responsive and we're right before FF
<pitti> sure
<micahg> pitti: k, thanks
<andersk> I think glib2.0 2.25.12-1ubuntu1 is badly broken (at least on i386): bug 614240.
<ubottu> Launchpad bug 614240 in glib2.0 (Ubuntu) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated" [Undecided,New] https://launchpad.net/bugs/614240
<andersk> If so, this is going to cause major headaches for maverick users tomorrow.  :-(
<micahg> robert_ancell: ^^^
<pitti> CDs failed to build the same way
<robert_ancell> micahg, yes, :(
<robert_ancell> occurs on i386, not amd64.  Anyone care to test a fix?
<pitti> http://cdimage.ubuntu.com/daily-live/20100806/maverick-desktop-amd64.manifest
<pitti> MUAHAH!
<pitti> no hal any more!!
<pitti> \o/
<robert_ancell> pitti, your quest is complete!
<Chipzz> pitti: gz :)
<robert_ancell> pitti, do you have i386 hw?
<pitti> robert_ancell: I have two amd64 installs
<pitti> robert_ancell: but I can test something in a VM
<pitti> i. e. boot the alpha-3 i386 VM and update or so
<robert_ancell> pitti, actually, the ppa is fast today, it's building there now.  thanks
<robert_ancell> pitti, build failed, it's pulling in glib to build glib...  can you try building lp:~robert-ancell/+junk/glib-i386-fix on i386 and see if there is the error reported in bug 61420 when it builds?
<ubottu> Launchpad bug 61420 in xorg (Ubuntu) "Xorg.conf AIGLX changes needed for 855GM cards" [Undecided,Invalid] https://launchpad.net/bugs/61420
<robert_ancell> bug 614240
<ubottu> Launchpad bug 614240 in glib2.0 (Ubuntu) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated" [Undecided,New] https://launchpad.net/bugs/614240
<robert_ancell> seb128, hey
<seb128> hey robert_ancell
<robert_ancell> seb128, been breaking stuff, sorry :(
<seb128> robert_ancell, you did upload the new glib?
<robert_ancell> seb128, yup, wasn't getting any problem here - do you have any i386 hw?
<seb128> "i386" in sense of non i686?
<robert_ancell> seb128, not sure, definitely broken on i386
<seb128> but yes my box is not amd64
<seb128> robert_ancell, I wrote you an email to tell you to not upload before having it tested by somebody who had the issue :-(
<robert_ancell> seb128, sorry, I misread that
<seb128> robert_ancell, we missed the :03 run now, I will do a testbuild with -O0 there
<seb128> did anybody tried that?
<robert_ancell> seb128, ok, thanks.  I can't reproduce the problem but I have a possible fix in  lp:~robert-ancell/+junk/glib-i386-fix
<seb128> robert_ancell, want me to test that first?
<robert_ancell> seb128, yes please.  Look for a warning after compiling gsignal.c
<seb128> robert_ancell, did you try to upload to a ppa? ;-)
<robert_ancell> seb128, yes, but it pulled in glib to build glib - how do we get around that?
<seb128> did it?
<robert_ancell> http://launchpadlibrarian.net/53153005/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz
<pitti> bonjour seb128
<seb128> that's going to be fun
<seb128> pitti, hey
<seb128> pitti, help!
<pitti> erm, why does glib b-dep on glib?
<pitti> ah
<pitti> libdconf2.0?
<robert_ancell> pitti, it may be because of the dconf depends
<seb128> let's change it back to a recommends
<pitti> robert_ancell: so, try the following:
<pitti> - upload a glib2.0 without dconf and the fix
<pitti> - let it build and publish
<pitti> - reupload glib2.0 with dconf
<seb128> just change it back to a recommend
<seb128> that's a circular depends anyway
<seb128> I will add the recommends to gnome-session or something
<pitti> recommends sounds good enough as well
<robert_ancell> ok, uploading now
<robert_ancell> (to ppa)
 * seb128 builds locally
<seb128> I hacked the rules to not run make check, that takes hours
<seb128> robert_ancell, sorry for not being clear in my email :-(
<robert_ancell> seb128, I should have checked the debian reports closer
<seb128> did you find it now?
<robert_ancell> seb128, yes, afterwards when I knew the compiler error to search for
<seb128> robert_ancell, oh, did they reassign it away from glib?
<seb128> in any case update building there
<robert_ancell> seb128, no, but I didn't realise that bug was the problem we were facing.
<seb128> I didn't realize it was not happening on amd64 ;-)
<robert_ancell> seb128, the weird thing is the compiler says "this is going to fail for sure" and then lets you keep compiling!
<seb128> I've noticed reading your email, I didn't notice the build warning yesterday
<seb128> robert_ancell, seems the warning is fixed
<seb128> it's building the udeb variant now but I've no "//usr/include/bits/string3.h:86: warning: call to __builtin___memset_chk will always overflow destination buffer" in the log after the shared build
<robert_ancell> seb128, good sign...
<seb128> oh come on
<seb128> building rfgdbg now
<seb128> why do need to build glib, gtk etc 3 times
<seb128> robert_ancell, btw you should add the dh_installdirs call to the rules while you are at it
<seb128>  	dh_install -i
<seb128> +	dh_installdirs -i
<seb128> and same for the -s
<seb128> robert_ancell, and be ready to upload if that build works ;-)
<robert_ancell> seb128, prepping now...
<seb128> robert_ancell, ok, it's running the dh_
<pitti> hm, what's all this complaining from uscan in maverick?
<pitti> dpkg: version ''2.31.6'' has bad syntax: invalid character in version number
<seb128> robert_ancell, works! go go go upload it ;-)
<seb128> ups
<seb128> robert_ancell, wait
<pitti> this seems to break bzr bd etc.
<seb128> robert_ancell, no, don't
<seb128> robert_ancell, any gtk software segfault on g_bsearch_array_lookup_fuzzy()
<robert_ancell> seb128, ?
<seb128> the install worked
<seb128> but gtk-demo or gedit or whatever still segfault
<robert_ancell> damn, plan B, can you upload with -O0?
<seb128> pitti, should we block the binaries? it makes any gtk software segfault on i386
<seb128> robert_ancell, can try
<pitti> seb128: ah, so the fix doesn't work?
<pitti> or any workaround?
<pitti> seb128: we could just upload the previous glib?
<pitti> it'd be better than blocking binaries IMHO
<seb128> ok
<seb128> ok
<seb128> pitti, robert_ancell: I've uploaded an untested version
<seb128> building it locally now
<pitti> a reversion to the previous glib?
<seb128> pitti, no, a build with -O0 which the debian guys says workaround the compiler issue
<seb128> pitti, I'm not sure the previous version wouldn't have the same issue
<seb128> pitti, we are running into a gcc bug not a glib one
<seb128> that code didn't change
<pitti> eww
<seb128> grrrr
<seb128> #0  0x011eb53e in ?? () from /usr/lib/gio/modules/libgvfsdbus.so
<seb128> #1  0x00761996 in _g_local_file_info_get
<seb128> gtk-demo runs now but not gedit
<robert_ancell> seb128, I have to go sorry, can you handle this?
<seb128> robert_ancell, yes, enjoy your evening, don't worry we will sort it
<seb128> pitti, should we block the binaries or not?
<robert_ancell> seb128, thanks, I owe you a pile of beers
<seb128> pitti, it makes all the gtk programs crash on i386
<seb128> which basically means no session for anybody upgrading I guess
<seb128> and we will not catch a fix in the next publisher run now
<seb128> pitti, or wait
<seb128> hum no
<seb128> pitti, hello?
<pitti> seb128: so, your workaround didn't work either? does it work with -O0?
<seb128> pitti, my workaround was -O0, that fixes a crash but anything using gvfs crashes still
<seb128> I'm trying to rebuild the previous version now
<seb128> pitti, bah
<seb128> pitti, does the buildds install recommends?
<pitti> they don't, no
<seb128> http://launchpadlibrarian.net/53155396/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu2_CHROOTWAIT.txt.gz
<pitti> The following NEW packages will be installed:
<pitti>   libdconf0 libmpfr4
<seb128> right, I'm wondering what brings libdconf0 in
<seb128> I changed it to a recommends
<pitti> hm, is that even the build-depends install already?
<pitti> it could just be the initial chroot upgrade
<pitti> Updating debian chroot for build 7d742a5eeb0eac0743fc0c3c1f21ea01fa1a5850
<pitti> glib is in the buildd chroot
<seb128> :-(
<pitti> darn
<pitti> so, I'm afraid this needs lamont love
 * pitti stops buildds
<pitti> well, the i386 ones, anyway
<pitti> other arches are not affected?
<pitti> seb128, lamont: i386 buildds on manual, to avoid further FTBFSes until the chroot is sorted out
<pitti> seb128, lamont, elmo: I think what needs to happen is a manual chroot upgrade with ignoring the segfault in libglib2.0-0's postinst
<pitti> and then build/publish a glib without the libdconf dependency
<pitti> then the chroot should at least be able to upgrade itself again
<seb128> pitti, well, I'm not so concerned about the buildds that about the fact that every i386 downloading that upgrade will get a non starting system
<seb128> or rather graphical system
<sebner> seb128: good to know that I don't do a restart :D
<seb128> sebner, well you shouldn't be able to start any gtk application either
<pitti> seb128: so, you want the i386 .debs blocked? you need to ask #is about that, I'm afraid, I can't do that
<seb128> pitti, well either we need to solve that quickly or we need to block the debs
<seb128> pitti, what do you think?
<sebner> seb128: uh great, good that I opened my browser and xchat already before the upgrade xD
<pitti> seb128: blocking debs would probably be prudent, since we need to fix the chroots either way, and it's a couple of hours until lamont wakes up
<seb128> ok
<sebner> seb128: but I guess a simple glib downgrade fixes it?
 * sebner waves at pitti btw :)
<seb128> yes
<pitti> hello seb128
<pitti> sebner, even
<debarshi> Where can I find some documentation on writing a Ubiquity plugin? I need to add some extra pages to Ubiquity for some Ubuntu-based boxes that we are making at the university.
<debarshi> I am currently reading through the sources of the existing plugins ...
 * Adri2000 needs a core-dev to approve lucid task in bug #569365, please
<ubottu> Launchpad bug 569365 in mountall (Ubuntu) "mountall messages are showed untranslated in Plymouth" [Medium,In progress] https://launchpad.net/bugs/569365
<pitti> seb128: worth a try: does it work with gcc-4.5?
<seb128> pitti, how do I try that easily?
<pitti> configuring with CC=gcc-4.5 should do it
<pitti> and b-dep'ing on gcc-4.5
<pitti> it's in main
<seb128> let me try
<pitti> seb128: i. e. in configure-stamp rule, where CFLAGS= is set
<pitti> (untested)
<seb128> I'm finishing my 2.25.12.is.2.25.11 build and then test that
<seb128> pitti, my 2.25.12.is.2.25.11 works
<pitti> nice
<seb128> pitti, so at least we have something we can upload one the buildds are sorted
<seb128> trying gcc-4.5 now
<pitti> seb128: so it's not quite clear then whether it's a glib or a gcc bug?
<seb128> pitti, other distros don't have the issue with that glib and the debian guys who investigated says it's a compiler issue
<seb128> pitti, I'm trying gcc-4.5 next
<lamont> pitti: what's up?
<seb128> lamont, hey! need help fixing the buildds
<seb128> lamont, we got a libglib uploaded which segfaults on i386
<lamont> oh joy
<apw> seb128, lamont its also affecting the PPA builders
<seb128> lamont, and we can't get a new version fixed because the buildds dist-upgrade pre-build fails on it
<apw> pitti, should we disable the PPA i386 buildd's too as they are pinging jobs to CHROOTWAIT
<lamont> apw: manualing them now, but I'm pretty sure that's not what pinging means
<apw> lamping them to CHROOTWAIT perhaps :)
<pitti> seb128: confirmed that armel and powerpc are affected too
<pitti> seb128: given that sparc also succeeded, looks like a 32 bit only issue?
<asac> all stop!
<pitti> glib doing something nasty to pointers?
<pitti> MANUALing powerpc and armel
<seb128> pitti, should I upload my downgraded version for now?
<pitti> seb128: if that works, please do
<seb128> done
<pitti> seb128: then it'll be ready to try when the builders are working again
<seb128> I'm away for a quick bite, will be back in 10 minutes or so
<lamont> pitti: so we need all 32-bit maverick architectures?
<pitti> lamont: seems so; i386, armel, powerpc AFAICS?
<lamont> joy
<pitti> lamont: what would you recommend here? manually upgrading the chroot and || true'ing the postinst of libglib?
<pitti> lamont: or temporarily disabling dist-upgrade?
<pitti> it fails during dist-upgrade of the chroot, before starting the actual build, AFAICS
<lamont> pitti: I just rolled a fresh i386 chroot, and helped libglib2.0-0 to land well
<pitti> lamont: ok; disabling dist-upgrade is harder to do/not advisable?
<lamont> produces a less reproducible result
<pitti> lamont: just saying that with that hacked chroot this probably needs another update once glib is fixed?
<lamont> once glib is newer, the dist-upgrade will take care of it each time
<lamont> glib isn't a quick build.  do we need the old glib to build the new glib, or is the gio-modules segv isolated?
<pitti> lamont: it's not quite clear yet whether it's a gcc bug or a bug in the newer glib, but so far we don't have any other solution than to downgrade glib
<pitti> lamont: we don't need the old glib for build, it was a circular dependency (now fixed)
<lamont> ah, ok.
<lamont> so I'm hearing that we want to disable the upgrade on 32-bit, upload the old glib as a higher version, let it publish, and then re-enable the dist-upgrade, yes?
<pitti> lamont: sounds good
<pitti> lamont: well, I don't insist on disabling the upgrade; I was just asking whether it might be easier for you
<pitti> it might be a central change, as opposed to having to fiddle with N chroots twice
<lamont> given the borked nature of the new build, and your promise not to reenable everything until I turn it back on, I'm happy
<lamont> it's not a central change
<pitti> ok; so whatever is easiest and works :)
<asac> i think if lamont wanted it to be simple we already would have a webUI to patch chroot etc. :-P
<pitti> lamont: the new build is broken?
<asac> j/k
<pitti> lamont: (sorry, I didn't actually follow the changes in glib; this time I was by and large a bystander)
<lamont> pitti: borked nature of a fresh chroot <-- forget what I said about "new build"
<pitti> ah
<lamont> pitti: use the following machines to build glib:  palmer, ross, artigas, hawthorn
<pitti> lamont: understood; I'll bump its build score to make sure it goes first
<seb128> lamont, pitti: thanks!
<asac> thanks all for fixing this
<lamont> once it's done and published, you can unmanual everything EXCEPT those 4.  poke me to go undo the hack, pls
<pitti> lamont: ack
<pitti> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.12.is.2.25.11-0ubuntu1
<pitti> hmm
<pitti> lamont: just to make sure everythign is as expected, did we drop sparc and ia64 arches from maverick now?
<lamont> final decision is slated for next week, iirc
<pitti> because above build doesn't have build records for those
<pitti> sorry, ia64 is there, but no sparc
<Daviey> cjwatson: Ciemon has been testing Maverick, and he encountered a bug which i haven't been able to reproduce yet.  He's found that grub->recovery mode can give him a root console.  Is there something that has changed in the last  few days that could have caused that?
<lamont> pitti: I wonder if it's still PaS on sparc
 * lamont looks
<pitti> glib? that'd ruin pretty much everything
<pitti> given that upstart needs it
<lamont> %glib2.0: !sparc                                                     # temporary workaround for buildd-killer
<lamont> I win
<lamont> pitti: sparc was dead in lucid
<lamont> lack of a kernel and all that
 * pitti sets artigas and sejong (sparcs) to manual
<lamont> why?
<pitti> ah, sorry, sparc is not affected
<pitti> lamont: you said to use artigas for the glib build
<pitti> no, sparc _is_ affectd
<pitti> sorry, had a phone call in parallel (done now)
<pitti> lamont: in general we still get sparc build records for maverick, so better to stop it
<lamont> sparc has 2.24.0-0ubuntu4
<pitti> ah, so it's not affected because the broken glib failed?
<pitti> indeed, https://edge.launchpad.net/ubuntu/+source/gnome-session/2.31.6-0ubuntu1 succeeded on sparc
<pitti> (from ~ 1.5 hours ago)
<lamont> sparc doesn't believe in glib of the current era
<pitti> ok, sparc back on auto
<pitti> lamont: so should I just ignore your "plz use those" for artigas then?
<pitti> and you can undo the hack there?
<lamont> hack gone on artigas, ignore artigas
 * pitti puts the other three back on auto, and puts a sweet cherry on top of the glib build to lure them into grabbing the builds faster
<lamont> pitti: on that, do you need anything more from me until glib is building?  (I can actually remove the hack once the build is into installing build-deps)
<pitti> there, they took the bait; I set them back to manual
<pitti> lamont: assuming that these builds will actually succeed, should be enough
<lamont> cool
<pitti> lamont: would it be okay to revert the hack in an hour or so? just in case..
<lamont> sure
<pitti> we don't have a desperatingly long queue
<pitti> so the outage of those three shoudln't hurt
<pitti> seb128: ok, I'd like to grab some lunch, and those builds will take a bit anyway; do you need anything else right now?
<seb128> pitti, no, thanks for helping there, I will email ubuntu-devel now
<pitti> seb128: it's past the build-dep isntall stage on all three, anyway, so seems lamont's hack worked :)
 * pitti &
<seb128> pitti, lamont: new glib failed to upload
<seb128> "2010-08-06 11:35:00 WARNING Upload was rejected:
<seb128> 2010-08-06 11:35:00 WARNING     invalid literal for int() with base 10: '24\t.'"
<seb128> wth?
<seb128> http://launchpadlibrarian.net/53161958/upload_1907875_log.txt
<seb128> "2010-08-06 11:34:50 ERROR   Exception while accepting:
<seb128>  invalid literal for int() with base 10: '24\t.'
<seb128>  -> http://launchpadlibrarian.net/53161956/hMxV26MZk2BTThKsEzJvkTYKbvL.txt (invalid literal for int() with base 10: '24\t.')
<seb128> "
<wgrant> seb128: That looks like the pkgstriptranslations issue from a few weeks ago.
<wgrant> (yes, the error message sucks)
<seb128> lamont, did your changes brought back pkgstriptranslations to an old version or something?
<geser> seb128: pitti fixed that already in the past
<lamont> seb128: that tarball was last upgraded some time ago
<wgrant> I didn't know that any chroots existed with the bad version held, though...
<lamont> so you're saying you want pkgstriptranslations?  any other packages vs weeks ago?
<seb128> wgrant, lamont has been tweaking things to fix the glib screwup
<lamont> wgrant: not held, we just completely skipped the dist-upgrade step
<wgrant> Hmm. I wonder why the chroots would have that version, though.
<wgrant> How odd.
<seb128> what was the buggy version?
<wgrant> I forget... the one where it was uploaded like 5 times in one day.
 * wgrant checks.
<wgrant> That bug was fixed in 73.
<lamont> wgrant: they have the july 14 binaries
<lamont> ish
<lamont> (all of the tarballs)
<wgrant> lamont: Hm, you recreated them during the brokenness? :/
<seb128> lamont, can you check the version on the builders?
<lamont> then the dist-upgrade step brings them current
<lamont> wgrant: I just looked at the timestamp on the tarball
<wgrant> Also, wouldn't this have been several hours easier if the old glib binaries were revived?
<lamont> wgrant: yes and no
<lamont> ii  pkgbinarymangler                70                        strips translations and alters maintainers d
<seb128> lamont, can we update that and retry build?
<wgrant> lamont: I mean, surely it'd be nice to fix archive breakage quickly without screwing with chroots....
<pitti> argh
<pitti> old ghosts come back then!?
<lamont> seb128: and crunching along nicely now
<lamont> pitti: you said no dist-upgrade... so you get july 14 bits
<lamont> that was my point
<seb128> lamont, thanks
<lamont> seb128: it'd be nice if once we get this published, you did a fresh upload of the old bits one more time
<seb128> lamont, you want another glib source upload?
<pitti> lamont: right, but I didn't think of the possibility that of all possible times we'd catch the two hours with broken mangler :-( sorry about that
<lamont> pitti: in other news, my plan (as of last night) was to build new chroots first thing this morning.
<lamont> there's some irony or such in there somewhere
<wgrant> So, seriously, wouldn't stuff like this be easier if you could remove the broken binaries and bring back the old ones into the archive? That's quite doable.
<lamont> wgrant: with a higher than broken version number?
<wgrant> lamont: Not critical if the chroots are old.
<pitti> lamont: nice timing for the win!
<lamont> except for the user
<seb128> lamont, you need a source upload? when?
<pitti> someone retried the glib i386 build then?
<pitti> "started 5 mins ago"
<wgrant> lamont: Well, the intention would be to get builds unbroken, then get a newer version out to users once the world is fixed.
<lamont> seb128: once the current one is published - I'll let pitti decide if he wants that to build (using current build-deps) before autoing the world, or if he's ok with the july 14 build-deps and letting it happen when it does
<lamont> pitti: I did
<lamont> with current pkgbinarymangler
<seb128> why do you need a new source upload?
<seb128> if you retried the current one
<lamont> seb128: totally separate issue
<pitti> seb128: the current build is bad, since it builds with an old toolchain, etc.
<lamont> seb128: I'd like glib to be built with current build-deps, instead of 3-week old build-deps
<seb128> ok, fair enough
<lamont> s/build-deps/maverick/
<seb128> I'm still aiming at trying to fix 2.25.12 if I can
<pitti> seb128: that'd be even better, of course :)
<pitti> seb128: it's an exercise in git bisect, by and large?
<lamont> if you give me a window where the world is happy, I'll freshen the chroots this morning
<seb128> pitti, I'm not sure, 2.25.12 built from tarball doesn't crash
<seb128> but I'm only LD_LIBRARY_PATH loading the libraries
<pitti> seb128: do you get a crash if you have the working glib installed, and LD_LIB_PATH'ing the one from the known-broken glib .deb?
<pitti> seb128: if that doesn't crash either, then apparently L_L_P doesn't work (enough); if it doesn't crash, then it might be a patch of our's?
<seb128> pitti, yes
<seb128> it crashes this way
<pitti> seb128: ok, so LD_L_P is working to reproduce the crash, and it's something that we patched in our package?
<pitti> seb128: i. e. I assume "build from tarball" means "from upstream"?
<seb128> pitti, it means tar xzf orig.tar.gz; cd glib; ./configure --prefix=/usr && make
<pitti> *nod*
<seb128> pitti, I'm doing a deb build without distro changes now
<pitti> seb128: my first suspect would be 71_gio_launch_handler.patch
<seb128> it's not
<seb128> debian doesn't have this change
<pitti> ok; well, then good hunting!
<seb128> I'm wondering if that could be due to the rules
<seb128> LDFLAGS += -Wl,-O1
<seb128> for example
<seb128> pitti, thanks ;-)
<seb128> pitti, thank you for trying to give me hints as well ;-)
<pitti> i386 finished
<pitti> seb128: would you mind testing the binaries from https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.12.is.2.25.11-0ubuntu1/+build/1907344 ?
<pitti> seb128: they were built with an older toolchain, so we can't assume that they work now (i. e. as in your local build)
<seb128> pitti, trying
<seb128> pitti,
<seb128> pitti, works
<pitti> \o/
<pitti> lamont: so, you can un-hack palmer/ross/hawthorn
<lamont> pitti: all unhax0red.
<lamont> pitti: ok if I leave the unmanual to you?  if it's published, I'll go do it now if you want
<pitti> lamont: yes, that's fine
<pitti> I'll reanimate them
<pitti> lamont: and seems seb128 just found the root cause
<pitti> so we now at least have a much better workaround
<lamont> yay
<didrocks> hum, I get some "Failed to upload", I think this is related to previous chroot/builder issue? (https://launchpad.net/ubuntu/+source/zeitgeist-extensions/0.0.3-0ubuntu1/)
<pitti> didrocks: yes, you can just retry those
<didrocks> pitti: ok, thanks :)
<didrocks> pitti: still the same upload issue
<pitti> didrocks: hang on, will look later
<seb128> didrocks, what does the upload log say?
<didrocks> sure, no hurry, good luck with you current debug stack :)
<didrocks> http://paste.ubuntu.com/474019/
<didrocks> 2010-08-06 12:36:42 WARNING Upload was rejected:
<didrocks> 2010-08-06 12:36:42 WARNING     Duplicated ancestry
<pitti> didrocks: ah, that's not mangler then
<didrocks> I don't remember we uploaded it beforeâ¦
<pitti> didrocks: someone promoted a package to main or universe while it was built
<pitti> you need to wait for a publisher
<didrocks> pitti: "a package"? I don't really understand where the error is here TBH
<pitti> didrocks: zeitgeist-extensions?
<pitti> didrocks: look at https://edge.launchpad.net/ubuntu/+source/zeitgeist-extensions/+changelog
<pitti> didrocks: it's published twice
<pitti> apparently it was moved to main within this our
<didrocks> oh ok, this is possible even if the first binary wasn't NEWed? ok, I understand now :)
<didrocks> pitti: thanks, I'll wait for the publisher so
<lamont> pitti: are we just waiting on a publisher run for the unmanual?  or are you waiting for another glib2.0?
<pitti> lamont: publisher, and https://edge.launchpad.net/builders/hawthorn to finish
<lamont> oh yeah.  hawthorn
<lamont> that has the current pkgbinarymangler, fwiw
<pitti> lamont: I'd like the packages to be published before I let any other package buildl
<pitti> otherwise we have to retry even more
<lamont> verily
<jcastro> mpt: any clue as to where to report bugs on the apt.ubuntu.com redirector thing?
<mpt> jcastro, no -- no-one is assigned to work on it
<jcastro> is it going away eventually or will it be superceded by something or ... ?
<jcastro> (trying to figure out if we should tell people to use it)
<hyperair> Can't locate Dpkg.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/dpkg-source line 22.
<hyperair> BEGIN failed--compilation aborted at /usr/bin/dpkg-source line 22.
<hyperair> what happened? O_o
<mpt> jcastro, I nagged rickspencer3 about finding someone to develop it at Guadec. More nagging would help. :-)
<jcastro> mpt: I am born to nag, I just need the name of the person who touched it last
<mpt> jcastro, Andrew Glen-Young iirc
<pitti> seb128: I think I can set the buildds back to auto now
<pitti> libglib2.0-0 | 2.25.12.is.2.25.11-0ubuntu1 |      maverick | amd64, i386, ia64, powerpc
<lamont> pitti: woot!
<lamont> pitti: you say so, I'll do it
<pitti> palmer and ross back on auto
<pitti> lamont: not yet armel
<pitti> that still needs 40 mins for publishing
<pitti> lamont: but the rest looks okay
<seb128> pitti, thanks
<lamont> pitti: so... terranova samarium lansones lychee actinium lemon litembilla rothera papaya hassium seaborgium thorium iridium thallium vernadsky adare muntries sandpaperfig radium rosehip nannyberry doubah uranium einsteinium dubnium shipova, yes?
<lamont> done
<pitti> lamont: https://edge.launchpad.net/builders looks good now
<pitti> lamont: oh, you have an en-masse way to enable/disable them? I usualy click through all of them on above page
<lamont> pitti: btw, you forgot ivy and kaylaberry when you did the manual thing... though I think we're safe there
<Lukian> testing an upgrade from lucid to maverick results in dpkg: parse error, in file '/var/lib/dpkg/status' near line 48098 package 'virtualbox-3.1': error in Version string `3.1.6-59338_Ubuntu_karmic': invalid character in revision number -- should I file this bug against virtualbox or dpkg?
<pitti> lamont: oops, indeed; wasn't aware that we had armel PPA builders
<lamont> pitti: nothing actually uses them quite yet that I've seen
<seb128> Lukian, known dpkg bug
<Lukian> known bug? cheets
<lamont> though in theory, that's going to change
<seb128> Lukian, it's filed in launchpad and debian already
<Lukian> cheers*
<seb128> Lukian, you can edit your available and status files to workaround the issue
<seb128> it does't like the _U..._
<Lukian> already done ;)
<pitti> seb128: how is that a dpkg bug?
<Lukian> pitti, because it's a semi-valid version number? :>
<pitti> how is 3.1.6-59338_Ubuntu_karmic a valid version number?
<pitti> it's clearly not
<Lukian> haha indeed
<Lukian> but yeah, it still needs to be filed and fixed
<pitti> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<Lukian> pitti, maybe one day Sun will even lowercase the executable from "VirtualBox" to "virtualbox"
<Lukian> Oracle*
<seb128> pitti, well dpkg allowed people to install it at some point so it should allow them to get out of it
<jcastro> didrocks: feature requests for banshee-meego that are ubuntu-specific should go in launchpad?
<didrocks> jcastro: if it's ubuntu specific, yeah it should
<didrocks> jcastro: if we can have the udev branch merge next week, it will be awesome. I'll be then on holidays for two weeksâ¦
<jcastro> ok let me see
<jcastro> didrocks: next wednesday fine?
<jcastro> that's 1.7.4
<didrocks> jcastro: yeah, it is :)
 * Laney hopes we can get banshee back in sync
<hrw> hi
<ttx> pitti: got one for you. Due to bug 614393 I consider reverting a recent upload to antlr3-3.2 and go back to antlr3-3.0.1 we had in lucid
<ubottu> Launchpad bug 614393 in antlr3 (Ubuntu) "[maverick] antlr3 3.2-4 FTBFS due to missing deps in main" [Undecided,New] https://launchpad.net/bugs/614393
<hrw> http://hrw.pastebin.com/PNhm3K5Y - can someone help me with debian/control file to make it pass lintian?
<ttx> pitti: I don't think we raelly want 30+ MIRs over this one
<ttx> pitti: I should do a 3.2-really3.0 upload ?
<pitti> ttx: ooh, please do
<ttx> pitti: I need some guidance on the process, I never did that.
<geser> hrw: on which architectures should the package get build? i386, amd64, armel, etc or a subset or only one specific?
<ttx> pitti: is it just about uploading a new "version" that is 3.0.1 but as 3.2-really3.0.1.orig.tar.gz ?
<hrw> geser: any basically
<pitti> ttx: right, rename hte old tarball accordingly, and bump debian/changelog
<ttx> pitti: what should the version name look like ?
<geser> hrw: then add "Architecture: any" to the source stance in debian/control to get rid of the error (E:)
<ttx> lucid has  3.0.1+dfsg-4ubuntu2, maverick has FTBFS 3.2-4
<hrw> ok
<pitti> ttx: 3.2.is.3.0.1-0ubuntu1 perhaps?
<ttx> pitti: that would force us to stick with it until debian goes to 3.3, right (not that I care, but...)
<pitti> ttx: but if you reuse 3.2-*, then you can't upload a new orig.tar.gz
<geser> hrw: and you can ignore the warning about "linux-source" as it's is a real-package, and the other warning looks like you missed the XSBC- before Original-Maintainer
<pitti> ttx: so 3.2 can't be built without the new dependencies?
<ttx> no, upstream migrated to maven build system and debian followed suit
<ttx> that's something we'll have to do at one point
<ttx> but I'm pretty sure this is not the right moment in cycle to do it
<ttx> especially with the possible outcome of breaking eucalyptus by upgrading a few libs in the process
<pitti>  ttx 3.2.is.3.0 it is, then?
<geser> ttx: as your are currently talking about a MIR (and AFAIK take also care about java packages): could you comment on bug 614000 (as additional input for the MIR team)
<ubottu> Launchpad bug 614000 in ant1.7 (Ubuntu) "[MIR] ant1.7, ant1.7-optional (source: ant1.7)" [Undecided,New] https://launchpad.net/bugs/614000
<ttx> yep, will do
<ttx> geser: looking
<ttx> sounds reasonable, at least for axis
<ttx> libservlet2.4-java is getting deprecated, shouldn't have anything in main depending on it anymore
<ttx> geser: commented
<geser> thanks
<ttx> pitti: thanks for your input !
<pitti> seb128, lamont: FYI, I switched the armel buildds back to auto as well now
<seb128> pitti, thanks
 * pitti hugs seb128 "hero of maverick"
<lamont> pitti: woot.
<pitti> seb128: note that the previous upload somehow didn't create a sparc build, but I guess/hope the next one will again
 * seb128 hugs pitti back
<lamont> I'll cook a set of tarballs today, and get blessings on them before deploying them monday
<pitti> but then again, let's just ditch it
<seb128> thanks again for helping sorting that
<pitti> lamont: we shold wait on the next upload from seb128 with the real fix, I think
<pitti> (for "good" chroots)
<pitti> have a nice weekend everyone!
<lamont> pitti: true
<lamont> seb128: poke me when it's uploaded, mk?
 * lamont -> town, afk
<sconklin> what's the right place for pure python app  modules to install? I'm working on packaging one and the original app installed to /usr/share/appname/, but the debian packaging tools want to put it in /usr/lib/pymodules/python2.6/appname/
<mathiaz> kees: once you've gone through all your daily USN, would you mind poking at libdbi MIR (bug 608552)?
<ubottu> Launchpad bug 608552 in libdbi (Ubuntu) "[MIR] libdbi" [Undecided,New] https://launchpad.net/bugs/608552
<kees> mathiaz: yup, MIR is on the list for today. :)
<mathiaz> kees: \o/ - think ya
<kees> oar welcome
<RoAkSoAx> can someone please take a look to the following MIRs: bug #515996 bug #527155 bug #527142 bug #527182
<ubottu> Launchpad bug 515996 in libesmtp (Ubuntu) "[MIR] libesmtp" [Wishlist,New] https://launchpad.net/bugs/515996
<ubottu> Launchpad bug 527155 in cluster-agents (Ubuntu) "[MIR] cluster-agents" [Undecided,New] https://launchpad.net/bugs/527155
<ubottu> Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,New] https://launchpad.net/bugs/527142
<ubottu> Launchpad bug 527182 in heartbeat (Ubuntu) "[MIR] heartbeat" [Undecided,New] https://launchpad.net/bugs/527182
<Daviey> jdstrand: Hey.. Are you thinking of doing a libvirt 0.8.3-1 merge?
<jdstrand> Daviey: yes
<jdstrand> Daviey: probably first thing next week
<Daviey> jdstrand: Okay, that's great - could i ask that you keep me posted on it.. i'd like to test it as soon as.. thanks.
<jdstrand> Daviey: sure
<Daviey> thanks!
<jdstrand> Daviey: I should qualify the 'first thing next week' -- that is when I will start it. it is a complicated merge and there is likely a migration script I need to finish writing
<jdstrand> Daviey: I'm not sure when it'll be done, but libvirt is my priority next week
<Daviey> jdstrand: yeah.. the delta looks kinda scary :(...   The migration script will be a debian/ maintainer script?
<jdstrand> Daviey: initially, yes. depending on my findings I may push to Debian and upstream
<Daviey> jdstrand: Well, if you want me to do some smoke testing with it against UEC before it hits the archive, i don't mind.. just point me to a branch :)
<jdstrand> k
<jdstrand> thanks
<Daviey> np
 * Daviey dashes.
<tkamppeter> pitti, hi
<geser> tkamppeter: he fled into weekend 3h ago
<hakzsam_> hi all
<hakzsam_> I try to install rhythmbox from the sources, I downloaded them with 'git clone git://git.gnome.org/rhythmbox'
<hakzsam_> but I have a problem with the './configure' script
<ion> topic
<hakzsam_> the error message is here : http://pastebin.com/6tNs0dtr
<Pici> hakzsam_: This isn't a support channel, please see the topic.
<hakzsam_> Pici, okay, but where is the topic ?
<Pici> hakzsam_: /topic should tell you
<hakzsam_> Pici, thanks !
<ebroder> Hmm...what happens if you build a live CD with a ureadahead pack? Are there too many differences across different hardware for it to help?
<ebroder> Could I build a live CD, generate a pack, drop the pack in and then re-squash the fs? Or is that going to re-arrange everything to the point that it does more harm than good?
<LucidFox> "Taking the time to fix all the reported bugs is likely to mean that the fully open beta will be somewhat delayed." <-- What :S
<ScottK> ebroder: If I tell you it's a bad idea will you give up?
<ebroder> ScottK: If I say no will you tell me how to do it? :-P
<ScottK> ebroder: No, because I don't know how.  I suspect you'll only be satisfied by trying it, so you should just go do that.
<ebroder> How can it be a bad idea, in theory at least? Let's see...I could drop the pack in the initramfs and copy it over to the aufs mount, so that would keep me from mucking with the squashfs...
<ScottK> Which reinforces my point.
<ebroder> Fair enough. I'm mostly curious if I can avoid duplicating someone else's work, but I'll probably just give it a go
<ScottK> If you are duplicating someone's work, it's not mine.
<hdon> hi all. i am debugging a program freeze in Pidgin on Lucid Lynx. (http://pastebin.mozilla.org/763072) i have installed libgtk2.0-0-dbg but gdb still doesn't know simple things like function prototypes to show me the arguments of functions on the stack automatically. please help :)
<hdon> .....
<LucidFox> Hmm
<LucidFox> how can I get an @ubuntu/member IRC hostmask?
<cody-somerville> LucidFox, If you're a Ubuntu member, you can ask the IRC Council.
<RoAkSoAx> kees: I'm wondering why you changed MIR's bug #527155 bug #527182 bug #527142 to incomplete, when I intentionally changed them back to new (by first updating the necessary information) to be processed?
<ubottu> Launchpad bug 527155 in cluster-agents (Ubuntu) "[MIR] cluster-agents" [Undecided,Incomplete] https://launchpad.net/bugs/527155
<ubottu> Launchpad bug 527182 in heartbeat (Ubuntu) "[MIR] heartbeat" [Wishlist,In progress] https://launchpad.net/bugs/527182
<ubottu> Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,Incomplete] https://launchpad.net/bugs/527142
<RoAkSoAx> without any further explanation
<kees> RoAkSoAx: heartbeat was already approved (so it should stay in "In Progress" state)
<kees> RoAkSoAx: cluster-glue is still missing manpages
<kees> RoAkSoAx: cluster-agents depends on cluster-glue
<kees> I didn't add any comments because the changes back to "new" looked accidental, and included no comments either. :P
<verb3k> Previous releases of ubuntu used to list CD/DVD drive device names in fstab, but in Lucid this is no more, why?
<RoAkSoAx> kees: oh ok, I thought it was because they were still unseeded... anyways, thank you :)
<kees> RoAkSoAx: they should go from In Progress to Fix Released once they're seeded and an archive admin promotes them
<RoAkSoAx> kees: ok. Thanks. I'll keep an eye on them till they get seeded. Thank you!
<kees> RoAkSoAx: cool; thanks!
#ubuntu-devel 2010-08-07
<hdon> hi all. i am debugging a program freeze in Pidgin on Lucid Lynx. (http://pastebin.mozilla.org/763072) i have installed libgtk2.0-0-dbg but gdb still doesn't know simple things like function prototypes to show me the arguments of functions on the stack automatically. please help :)
<YokoZar> slangasek: did you want me to reupload another wine1.2 to -proposed with the start change reverted?
<ricotz> stgraber, hello, are there plans to include ltsp 5.2.4 to lucid-updates or -backports?
<slangasek> YokoZar: yes please
#ubuntu-devel 2010-08-08
<anon^_^> Hi, question for devs. Recently a few patches were submitted to LKML to try and address a long standing issue with desktop responsiveness under heavy i/o disk activity
<anon^_^> any possibility that these patches will be backported for the next Ubuntu release?
<anon^_^> references
<anon^_^> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094
<ubottu> Launchpad bug 131094 in linux (Ubuntu) "Heavy Disk I/O harms desktop responsiveness" [Medium,Confirmed]
<anon^_^> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
<lifeless> #ubuntu-kernel may know more
<chrisccoulson> i suspect plenty of people have probably already asked them the same question
<anon^_^> it's only been a few days since the initial post
<anon^_^> but yes, assume it might have been asked already
<anon^_^> will try ubuntu-kernel, thanks lifeless
<weedar> I believe this package is synced from Debian, but if so why is the maintainer "Ubuntu MOTU Developers" and not the same as the Debian-maintainer? http://packages.ubuntu.com/source/lucid/openbios-sparc
<ebroder> Because the "Maintainer" field on that page is automatically calculated based on what component the package is in
<ebroder> See also the "Original Maintainer" field below it
<ebroder> If you actually grab and look at the package, the maintainer field hasn't been changed
<ebroder> If I had to guess, it's a measure to keep random users from e-mailing cranky DDs with Ubuntu problems
<weedar> ebroder: Thanks :)
<weedar> If I would like to become maintainer for the package in Ubuntu, should I mail the MOTU mailing-list or contact someone else?
<micahg> weedar: https://edge.launchpad.net/ubuntu/+source/openbios-sparc
<micahg> weedar: we don't have maintainers in Ubuntu
<micahg> well generally
<ebroder> We do have a concept of per-package upload permissions, although getting those is generally less common than just joining MOTU
<weedar> micahg:  The source package you linked to has "Failed to build"-messages for all releases from Hardy to Maverick, and there is no installation-candidate for the binary version - naturally I want to fix this :-)
<ebroder> weedar: That's great! You don't have to be the maintainer to do that, though
<ebroder> weedar: File bugs against the package, develop patches, test them in a PPA, then go through the sponsorship process to get them uploaded by a MOTU
<ebroder> !sponsorship | weedar
<micahg> weedar: https://wiki.ubuntu.com/SponsorshipProcess
<maco> weedar: you can bzr branch lp:ubuntu/openbios-sparc and then fix it and push it to lp:~weedar/ubuntu/openbios-sparc/buildnow or make a debdiff and attach it to a "ftbfs" bug and subscribe sponsors or ask in #ubuntu-motu
<weedar> ebroder: sounds good :)
<weedar> maco: I think I'll start by asking in #ubuntu-motu, but thank you for a summary of my options :)
<maco> well asking in #ubuntu-motu is a way to find a sponsor
<maco> /after/ you make changes in either a branch or a debdiff
<ebroder> Ugh. I really need to get a trustworthy Ubuntu box running so I can do sponsorship again
<maco> but folks in there can help you if you have questions while doing one of those
<maco> ebroder: so in the midst of everything moving around... where is the sponsor queue based these days?
<maco> i remember dholbach was working on a new one...where'd he put it?
<micahg> maco: http://qa.ubuntu.com/reports/sponsoring/
<maco> thanks
<maco> im on a new laptop with no bookmarks set yet too :P
<ebroder> Ugh. It's still impossible to find MOTU bugs in that list. Even "unseeded" isn't what you want
<maco> its not?
<maco> i thought in theory universe was now just anything-not-seeded
<maco> though i guess maybe that only goes into effect for maverick now
<ebroder> Unless it's gotten better in the last ~month or so, there are still unseeded packages in main/restricted
<ebroder> I guess honestly I've been too busy with other stuff lately to pay good attention. So I'll stop whining until I make sure my information is current
<maco> i see a distinct lack of motu things to sponsor though
<maco> like...maybe 4?
<maco> i see an unseeded branch for flash-kernel in main, so i guess you're right
<tumbleweed> maco: yeah almost all the unseeded stuff that's left in the queue isn't actually sponsorable by MOTUs
<ebroder> I can't remember - is anything that *is* seeded in main by definition?
<ScottK> ebroder: If it's seeded for Ubuntu Desktop, Ubuntu Server, UNE, or Kubuntu yes.  If it's seeded for other flavors, no.
<ebroder> ScottK: So if something is seeded to, say, mythbuntu, that's a MOTU package? That's...even more confusing
<maco> ebroder: i think mythbuntu is a "maybe" :-/
<ScottK> Mythbuntu, Ubuntu Studio, Edubuntu, and Xubuntu are built out of Main and Universe (and in the case of Mythbuntu and Ubuntu Studio, Multiverse too).
<ebroder> Oww
<ScottK> Mythbuntu also has a package set, so some of it is (IIRC) only uploadable by Mythbuntu or core-dev.
<ScottK> We should be building Kubuntu Mobile images soon.  Those will come from Main, Restricted, and Universe.
<ScottK> There's also Lubuntu that's built from Main, Restricted, Universe, and Multiverse.
<ScottK> But wait, there's more.
<ebroder> So what I think you're telling me is...the sponsorship queue gives me NO information about what I can and can't upload
<ScottK> No.  It doesn't.
<ebroder> :-/
<maco> insentive to become a core dev?
<maco> "so the sponsor queue stops wasting my time"
<tumbleweed> ebroder: also, it seems to misdetect seeding when a pacage has migrated into / out of main
 * micahg hopes that the new installer really doesn't say Please off me non-open-source software
<pkkm> When will bookmarks synchronization in Ubuntu One be up?
<Yura87> Hi.
<Yura87> Ubuntu (at least back at 8.x) has the user to find out the mac address for eth# setup. Puppy Linux has it nicer.
<Chipzz> Yura87: heh?
<Yura87> In Puppy, it retrieves the mac address automatically, you just click "eth0" > "static" and change "my IP", "gateway" and "DNS 1" according to your LAN setup.
<Yura87> #puppylinux
<Chipzz> Yura87: 1) 8.x is stable, and stable support is in #ubuntu; 2) what on EARTH are you talking about??? AFAIK you do NOT have to enter your MAC address anywhere???
<Chipzz> Yura87: 8.x is oldstable even
<Yura87> I didn't look at recent releases, so idk. But manuals for april-8 stable say you must take mac address from cmdline or something, to paste to eth# setup
<Chipzz> heh?
<Chipzz> ifconfig doesn't even take a mac adress as an argument
<Chipzz> and ubuntu has a GUI for setting up networking
<Chipzz> please paste the link to where you read that??
<Yura87> it was several days ago... something found when looking for "network setup ubuntu" on google
<Chipzz> and you claim that is the ubuntu manual?
<Chipzz> I severly doubt that
<LucidFox> Blimey
<LucidFox> Do we really need FIVE different Gmail notifiers for GNOME?
<Yura87> it's a third-party manual for ubuntu
<Chipzz> Yura87: and how is a third party manual relevant here?
<Chipzz> Yura87: if I write a manual about puppylinux that you have to configure your network via the command-line, does that make it the correct way to do it? I wouldn't think so...
<Yura87> well, and in Ubuntu 8 (my LiveCD), I didn't even figure out where "network setup" is. In Puppy, right-click the desktop > setup > network setup > eth#
<Yura87> so i got to inet on puppy - ok, but not on ubuntu
<Chipzz> Yura87: if you want support on how to connect to the internet, take it to #ubuntu pls, it is highly off-topic here
<Chipzz> and third party manuals are irrelevant
<Chipzz> although I would like to see a link to it ^^
<Chipzz> to apply a cluebat to the author :P
<hrw> hi
<hrw> I have a problem with PPA build: "/usr/bin/pkgsanitychecks: inconsistent /CurrentlyBuilding file, Package: value is armel-cross-toolchain (should be linux)
<hrw> I have a problem with PPA build: "/usr/bin/pkgsanitychecks: inconsistent /CurrentlyBuilding file, Package: value is armel-cross-toolchain (should be linux)" - the problem is that I need to do builds of other packages during build of mine.
<geser> pitti: ^^ any idea on this?
<geser> hrw: you need to wait on pitti coming back from weekend
<james_w> hrw: set NO_PKG_MANGLE=1 during those other builds, or something like that
<geser> right, I guess that's a valid use-case for this variable too
<james_w> PKG_IGNORE_CURRENTLY_BUILDING=1 perhaps
<james_w> NO_PKG_MANGLE=1 it is
<james_w> maybe set both to be sure
<geser> pkgsanitychecks is only executed when NO_PKG_MANGLE is empty
<hrw> james_w: thx
<hrw> thx guys
<PingJocky> is this the chanel to ask about 10.10 issues?
<nigelb> that would be #ubuntu+1
<PingJocky> thanks
<pitti> geser, hrw: right, you have to disable the mangler for such build; it's really an invalid file on the buildd, I'm afraid
<hrw> pitti: no, its my package - I am cross building binutils/eglibc/gcc/linux to build my package. I call dpkg-buildpackage 7 times
<janimo> hello, does anyone know why gdb is included on the liveCD (lucid)?
<highvoltage> janimo: apport-gtk depends on it
<highvoltage> *sigh* I hate it when people leave just as I start talking to them
#ubuntu-devel 2011-08-01
<RAOF> Is anyone here familiar with the archive side of the kernel SRU process?  It looks like the final step of copying from proposedâ{updates,security} is just a job for a regular sru-release.py, but I'm not sure of that.  And the combination of âunsureâ and âcopying to -updatesâ is not one I'm comfortable with âº.
<RAOF> Laney: Actually, here's probably more relevant :)
<lifeless> is there anyone in this tz familiar with apt internals ?
<RAOF> That's a fairly specific skillset; I don't know of anyone.  I generally shout at slangasek.
<RAOF> Laney: Also, how hard would it be to remove the darcs noise?
<micahg> oh is StevenK around?
<StevenK> micahg: FSVO.
<micahg> StevenK: heh, could you remove the libglew1.5-dev binary, it's blocking anything trying to build-dep on libglew-dev?
<micahg> I can file a bug if you like?
<StevenK> Yes, can haz bug
<micahg> StevenK: Bug #819087
<ubottu> Launchpad bug 819087 in glew (Ubuntu) "Please remove the libglew1.5-dev binary" [Undecided,New] https://launchpad.net/bugs/819087
<micahg> StevenK: It technically needs a core-dev ACK (IANA core-dev)
<StevenK> "Meh" :-)
 * ajmitch can ack it if you really need to tick the boxes :)
<StevenK> I just wanted a paper-trail -- but then micahg said the magic word 'NBS', which doesn't require one
<StevenK> micahg: Done
<micahg> StevenK: thanks :)
 * micahg goes to clean up the mess he created for others before they find out...
<RAOF> Laney: I've rejected the haskell-platform upload from natty-proposed queue that points at bug 711366; I presume that's correct.  I'd like to see the darcs changes cleaned out, though.
<ubottu> Launchpad bug 711366 in haskell-platform (Ubuntu) "update to 2011.2" [Medium,Fix released] https://launchpad.net/bugs/711366
<didrocks> good morning
<mdke> Laney: that works perfectly. Thanks *so* much
<fhd> If I've created a merge proposal on Launchpad, do I have to find and add reviewers manually for it to be reviewed?
<fhd> Or will someone (project owner?) get notified of my proposal automatically?
<RAOF> fhd: Depends on the project; the owner of the branch will get some notification, but there's no guarantee that goes anywhere.
<geser> fhd: if it's listed on http://reports.qa.ubuntu.com/reports/sponsoring/index.html one of the sponsors should pick it up
<fhd> RAOF: It's something for Unity (2D)
<RAOF> That'll get on someone's radar.
<fhd> I just remember that for Google projects, you always have to add reviewers manually
<fhd> Or you can wait for months
<geser> fhd: is this merge proposal for an upstream branch or an ubuntu packaging branch?
<fhd> geser: Um, the unity branch
<fhd> geser: This is the issue: https://code.launchpad.net/~fhd/unity-2d/fix-for-bug-795422/+merge/69919
<ubottu> Ubuntu bug 69919 in Launchpad itself "Bugs in non-existent product" [Medium,Triaged]
<geser> fhd: ok, I don't know how (upstream) projects handle merge proposals, especially unity-2d but I hope someone from the unity-2d team will pick it up
<fhd> geser: OK, I'll just wait then :)
<Laney> RAOF: you want me to retain it in the package?
<RAOF> Laney: After thought I decided that removing it is fine; it's accepted.
<Laney> awesome, thanks
<Laney> it disappeared because I have -I..._darcs in my DEBUILD_DPKG_BUILDPACKAGE_OPTS
<RAOF> You're welcome to review & upload colord to sid in return :)
<Laney> sure, moving today but I can do that
<Laney> give me a link to the .dsc :-)
<RAOF> http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git
<Laney> even better, ta!
<RAOF> Gah!  Too much X!  I just thought âbzr ci -mâ and typed âgit ciâ
<Laney> mr commit -m :-)
<Daviey> Are any AA's looking at sync's atm?
<seb128> Daviey, not really I think, I did an hour or so of cleaning and syncing previous week but that's about it
<nigelb> Daviey: I think it was because of Debconf.
<Daviey> nigelb: yeah, guessed so
<Daviey> seb128: My oldest sync request was placed 2011-07-20. :/
<seb128> Daviey, yeah, well I spent over an hour and I had to do other things so I didn't get to the bottom of the stack
<Daviey> seb128: I understand, thanks.
<geser> Daviey: there was also an accidental auto-sync last week. If you also requested sync of unmodified packages, you might want to check if it perhaps got already synced.
<Daviey> geser: Already have :)
<Daviey> One of my syncs was done by accident. \o/
<fhd> Ubuntu 11.10 has lightdm instead of gdm - is that just temporary or will it be the new default dm?
<geser> fhd: lightdm is the new default dm
<fhd> geser: I see. But the theme probably isn't finished yet, huh?
<Amaranth> fhd: clearly :)
<tjaalton> pbuilder create fails on oneiric, aborts when it notices /proc is mounted already
<tjaalton> anyone seen that?
<infinity> tjaalton: Known mount misfeature.
<infinity> tjaalton: I need to find some round tuits to look at it, I think.
<tjaalton> infinity: ok, good
<infinity> tjaalton: I have a basic idea of what's going wrong, just haven't found the time to dig deeper and fix it yet.
<tjaalton> infinity: is there a bug # open yet?
<infinity> tjaalton: There's a Debian bug, no idea if there's a launchpad one, but it seems likely.
<infinity> tjaalton: I need to fix it in Debian anyway, so it'll make it to UBuntu when I do.
<geser> tjaalton, infinity: bug #805886
<ubottu> Launchpad bug 805886 in util-linux (Ubuntu) "/proc does not get umounted after debootstrap" [High,Confirmed] https://launchpad.net/bugs/805886
<tjaalton> infinity: bug 805886 it seems
<tjaalton> echo :)
<infinity> geser: Thanks.
<tkamppeter> seb128, seems that a simple patch can make PackageKit optional. Will apply the patch, remove the dependency and suggest the patch upstream.
<seb128> tkamppeter, thanks
<tkamppeter> seb128, problem fixed upstream, taking new GIT snapshot ...
<seb128> tkamppeter, excellent, thanks
<seb128> jibel, ^
<jibel> tkamppeter, seb128 thanks!
<seb128> jibel, we can probably ask skaet to trigger a CD build once the fixed package will be published
<jibel> didrocks, is the upload of unity/compiz stack ready for a3 ?
<didrocks> jibel: compiz has been uploaded with some reverts for alpha3
<jibel> seb128, what is the ETA ?
<didrocks> jibel: unity/nux release will be there in 9 minutes normally, so then, time to test/release/package
<seb128> jibel, s-c-p? time to get upload, build and published it should be available in 1:28
<jibel> thanks. So we could respin with s-c-p and unity.
<seb128> jibel, well the publisher run around the hour and take some 45 minutes, so if the upload is built before 5pm which seems likely it should be published around 5:45 pm
<seb128> european time
<stgraber> jibel: I also just pushed the set of packages I needed for edubuntu alpha-3 and fixing LTSP on both edubuntu and ubuntu alternate.
<seb128> unity is going to take some 3 hours it needs to go through 2 publisher cycles
<seb128> jibel, but yeah, maybe better to wait a few hours and ask for a respin then
<didrocks> indeed, plan on 3 hours the time to get it and it's plublished
<jibel> stgraber, ack.
<jibel> I'll ask for a respin around 1800UTC
<seb128> jibel, I will watch unity uploads, build, etc and let you know when it's published
<jibel> seb128, thanks
<didrocks> I'll tell you when I have a release and I can upload :)
<infinity> So, is there a reason the Super+(number) shortcuts in Unity no longer actually launch applications?
<seb128> infinity, known bug
<seb128> should be fixed with the next update
<infinity> seb128: Cool, thanks.  Was just curious if I'd broken something inadvertently.
<diwic> infinity, it's intermittently broken in Natty (at least for me)
<jibel> infinity, bug 813359
<ubottu> Launchpad bug 813359 in compiz (Ubuntu Oneiric) "'Super' shortcuts for the launcher doesn't work anymore" [High,Triaged] https://launchpad.net/bugs/813359
<infinity> diwic: It worked fine for me in natty, broke completely in oneiric.  Well, for some value of "fine", I suppose.
<seb128> tkamppeter, how is the s-c-p upload going?
<diwic> infinity, for me the super+{s|a|f|t} are always working whereas the 1-9 are sometimes broken.
<infinity> On the other hand, someone (perhaps accidentally) fixed the misfeature where compiz/unity was trapping ALL super modifiers.
<infinity> So I can use Super+L for screen lock again.
<infinity> I wonder if that will get unfixed when Super+# is fixed. :P
<directhex> i just revoked unity's access to super. don't have time for games.
<smoser> slangasek, around ?
<tkamppeter> seb128, nearly ready.
 * infinity glares at base-files giving him spurious conffile prompts.
<tkamppeter> seb128, uploaded. Two bugs will close soon ...
<tkamppeter> seb128, we talked about a package rename in foomatic-db last Friday. OdyX from Debian did not like it, because it is a very complicated thing to rename packages in Debian.
<tkamppeter> seb128, so I made him the suggestion to get back into sybc by renaming foomatic-db-xml back to foomatic-db and let the drivers build-depend on foomatic-db but build-conflict with foomatic-db-compressed-ppds. Would the build handle this correctly then, installing foomatic-db and uninstalling foomatic-db-compressed-ppds if it is already installed?
<seb128> tkamppeter, yes, that would work
<tkamppeter> tkamppeter, I have also suggested the alternative to let foomatic-db Provide foomatic-db-xml. Would this also work, meaning that the build-depends on foomatic-db-xml then install foomatic-db and uninstall foomatic-db-compressed-ppds if it is already installed?
<tkamppeter> seb128, ^^ if that alternative also works, then I would not need to modify the driver packages.
<seb128> tkamppeter, that would work but provides are not versioned
<seb128> tkamppeter, so if you do that you couldn't have a build-depends on a specific foomatic-db-xml version
<seb128> or you would need to build-depends on foomatic-db (>= version), foomatic-db-xml
<seb128> which works as well
<seb128> tkamppeter, so basically your call, or whatever Debian prefers
<tkamppeter> seb128, so I will do the former, it is easier for versioned dependencies.
<seb128> right
<tkamppeter> seb128, will I need a transitional package named foomatic-db-xml to get correct updates for the few people who have taken my last foomatic-db package? And how long do I have to keep this transitional package?
<geser> tkamppeter: did you had a transitional package from -db to -db-xml?
<tkamppeter> geser, yes.
<geser> tkamppeter: I guess you could drop the transitional package for -db-xml to -db in a couple of weeks (but before release) as till then hopefully all affect alpha users should got it updated
<tkamppeter> geser, OK, thanks.
<seb128> tkamppeter, right, do one and drop it in a few weeks
<tkamppeter> seb128, I am doing this now, thanks.
<seb128> tkamppeter, thank you
<ScottK> If there's an archive admin with a moment: Can you do a binary promotion of smoke-dev-tools.  It's Universe binary from Main source now needed in Main to build other stuff due to package splits.
<Quintasan> Anyone has any idea what might be going on with pbuilder? When building anything dpkg-buildpackage uses -j1 even when I call with -j12
<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 hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<mterry> micahg, ping, I'm on
<micahg> jtaylor: can you show mterry what you need?
<jtaylor> mterry: please merge the branch attached to bug 780305
<ubottu> Launchpad bug 780305 in soya (Ubuntu) "unable to import soya due to undefined symbol" [Undecided,Confirmed] https://launchpad.net/bugs/780305
<mterry> jtaylor, looking
<jtaylor> it sould also be SRU'd
<jtaylor> affects oneirc and natty
<jtaylor> thx
<tkamppeter> seb128, all changes concerning foomatic-db are uploaded now.
<seb128> tkamppeter, thanks
<ScottK> seb128:  Can you do a binary promotion of smoke-dev-tools. It's Universe binary from Main source now needed in Main to build other stuff due to package splits.
<ScottK> We're kind of stuck on KDE 4.7.0 stuff on that right now.
<seb128> didrocks, ^
<didrocks> seb128: sorry, not really the time right now with this unity thing
<seb128> ScottK, can do a bit later, the box I'm on now doesn't have my ssh key
<seb128> jdstrand, ^
<ScottK> OK.
<ScottK> Thanks.
<seb128> ScottK, I will do after dinner if nobody else does it
<ScottK> Great.
<ScottK> Maybe slangasek can do it?
<slangasek> lookin'
<ScottK> Thanks.
<slangasek> ScottK: what needs it in main?  Doesn't show up on components-mismatches yet
<ScottK> slangasek: https://launchpad.net/ubuntu/+source/smokekde/4:4.7.0-0ubuntu1/+build/2659970
<slangasek> strange
<slangasek> ScottK: promoted, now we just need to figure out why it's not on the component-mismatches list...
<ScottK> slangasek: Thanks.
<hallyn> it seems DEB_DH_INSTALLINIT_ARGS is deprecated, but it doesn't tell me what replaces it
<hallyn> oh, i see.  that's cdbs doing all DEB_DH*
 * negronjl is away: out to lunch
<mterry> cyphermox, do you really need libsoup2.4 2.34.4 or can we just sync with Debian's 2.34.3?
<micahg> mterry: the merge is for 2.35.4 unless it was a typo
<mterry> micahg, right, sorry.  I meant do you really need 2.35.4 or can we just sync with Debian's 2.34.3?
<cyphermox> bah, no reason to necessarily go with 2.35.4; I guess you can sync
<micahg> shouldn't that wait until alpha3 though?
<mterry> micahg, sure, probably.  I'm not going to push the button, just sort out this merge and file a sync request
<micahg> mterry: k, there's one already you can resurrect (from ricotz)
<micahg> bug 818569
<ubottu> Launchpad bug 818569 in libsoup2.4 (Ubuntu) "Sync libsoup2.4 2.34.3-1 (main) from Debian unstable (main)" [Undecided,Invalid] https://launchpad.net/bugs/818569
<mterry> micahg, thanks!
<seb128> mterry, why not updating to the current version?
<mterry> seb128, because it's a delta, and I don't see a particular feature/bugfix wanted from the new one
<seb128> mterry, you could apply that to half of GNOME 3.1
<seb128> but fair enough, your call, we will update when something update its configure requirements
<mterry> seb128, :)  GNOME is a special case.  libsoup2.4 has historically been in sync, we only broke it for a security fix
<mterry> I mean, it was recently in sync, I don't recall its actual history
<seb128> mterry, but libsoup is a GNOME component ;-)
<mterry> seb128, barely  :)
<mterry> seb128, hrm... it does show prominently red in versions.html
<seb128> mterry, well as said there is a good stack of components in such cases we updated
<mterry> you're right seb128, I like to sync too much.  I'll go with cyphermox's merge
<cyphermox> heh, we could merge in debian's changes too, the small ones that aren't yet included
<seb128> mterry, i.e gdl, libgnome-keyring,gtksourceview3
<mterry> cyphermox, yeah, ricotz requested that in the merge comments
<seb128> mterry, trust me I like to sync, it's just that we follow unstable cycle and they don't, we will be back in sync for 3.2
<seb128> mterry, but i've to say versions push me to do those updates, I really dislike red on version :p
<mterry> seb128, yup.  I just didn't realize libsoup2.4 was in versions.html (i.e. among the set ubuntu-desktop cares about).  I thought it was a lesser-cared-for-by-us output of GNOME
<seb128> mterry, well version is basically 'what is in the default installation'
<slangasek> ScottK: so the reason for smoke-dev-tools not showing up as a mismatch is because smokekde wanted to be demoted
<slangasek> I guess that fixes itself once built and the seeded binaries show up
<ScottK> OK.  Thanks.
<ScottK> We've got layers of bindings dependencies now that kdebindings is split, so it may take a little bit of time yet to sort out.
<hallyn> Does anyone see anything telling in bug 818105?  Seems to be a general system fault (do i read this right, that it says stdin is 'file or directory not found'?)
<ubottu> Launchpad bug 818105 in qemu-kvm (Ubuntu) "package qemu-kvm 0.14.0 noroms-0ubuntu4.4 failed to install/upgrade: erro ao escrever para '<saÃ­da standard>': Arquivo ou diretÃ³rio nÃ£o encontrado" [Undecided,New] https://launchpad.net/bugs/818105
<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 hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* NCommander changed the topic of #ubuntu-devel to: Archive: soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<lifeless> slangasek: hi; do you have a sec to talk about bug 816606 ?
<ubottu> Launchpad bug 816606 in apt (Ubuntu) "apt postinst failure if ubuntu-keyring not installed" [Undecided,Confirmed] https://launchpad.net/bugs/816606
<SpamapS> hm, how can I get bzr bd -S to ignore this situation: dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field
<slangasek> lifeless: I do, though if you're looking to me because of RAOF's comments yesterday I fear he's steered you to the wrong person as I'm no expert on apt internals :)
<lifeless> slangasek: well, I guess I just need someone to agree on a path-to-fix
<SpamapS> lifeless: isn't it just as likely that the bug lies in debootstrap's dependency resolver which is , by its own man page's admission, quite limited?
<slangasek> SpamapS: unset DEBEMAIL in the environment for the build; but not for uploads to Ubuntu proper, as that warning shouldn't be ignored
<SpamapS> slangasek: its been a problem on the upstart package for a long time
<lifeless> SpamapS: no, its a recommends when as written it must be a predepends
<SpamapS> slangasek: I believe stemming from the fact that there are two maintainers listed. :-P
<lifeless> SpamapS: either the dep is wrong, or the code is wrong.
<lifeless> SpamapS: it affects upgrades as well
<slangasek> SpamapS: oh, right, that's an illegal maintainer field :)
<SpamapS> lifeless: indeed.. I think last I looked it was a Depends ..
<slangasek> SpamapS: mark the maintainer as James, move Scott to Uploaders: ?
<SpamapS> slangasek: that doesn't fix the gripe.. :-/
<slangasek> lifeless: um, certainly not a pre-depends if it's a postinst failure
<slangasek> SpamapS: why doesn't it?  provided that the Maintainer: field lists ubuntu.com, there should be no complaints about XSBC-Original-Maintainer IIRC
<micahg> well, it should change to a warning vs an error
<lifeless> slangasek: well, it seems to want it configured vs just unpacked. IMBW.
<SpamapS> slangasek: bug in the check maybe?
<slangasek> lifeless: ... which is the definition of Depends
<lifeless> slangasek: so, thoughts - disable the call, put an || true on the call, or change the relation ?
<SpamapS> I wonder, was ubuntu-keyring in base packages before and now isn't ?
<slangasek> lifeless: having a look at the history, one sec
<lifeless> slangasek: bah, its been too long since I refreshed my predepends definitions :) - sorry.
<SpamapS> please ignore.. that was a warning, but not what was failing my build
<slangasek> lifeless: looks like the Recommends: ubuntu-keyring is entirely inconsistent with Debian (which has Depends: debian-archive-keyring), so I'd say we should promote it to a Depends
<lifeless> ok
<lifeless> I'll see about tossing a bzr branch up later today; for now I have to take lynne down for a checkup
<hallyn> hm, python won't update in oneiric vm
<hallyn> debconf: DbDriver "config": could not open /var/cache/debconf/config.dat
<highvoltage> Daev: /win last
<highvoltage> (eek, sorry)
<jtaylor> hi, how can I mark a package as "should-not-be-merged"? argparse introduced a change in an upload which should not make it to ubuntu oneiric
<micahg> jtaylor: file a sponsorship request to have it blacklisted
<micahg> jtaylor: how permanent is the need to not sync?  there shouldn't be any more auto syncs until P opens
<jtaylor> depends on when the underlying issue is fixed, should probably be done before P
<jtaylor> it would need merging currently, but marking somewhere that it should not be done yet would be nice
<micahg> jtaylor: MoM would be the place for that, but there's not a lot of room to explain why
<jtaylor> I probably can't add comments there
<jtaylor> can someone comment, don't merge, would introduce problem in 793695
<jtaylor> for package argparse
<micahg> jtaylor: anyone can add a comment
<micahg> jtaylor: done anyways
<micahg> jtaylor: are you sure that's the correct bug #?
<jtaylor> thx
<jtaylor> it would probably introduce the same problem as in that bug
<jtaylor> its the same problem foolscap had, I think you sponsored my fix for that in foolscap
<jtaylor> argparse 1.2.1 added build-dependency on setuptools + dh_python2 => upgrade failure depending on file ordering in data.tar.gz in binary packages
<jtaylor> due to egg file -> egg folder
<micahg> k
<jtaylor> will python 2.6 still be in oneiric?
<ScottK> Depends on Debian
<ScottK> jtaylor: ^^^
<ScottK> jtaylor: The plan had been to wait for Debian to make 2.7 default before we dropped 2.6, but now that the Debian release team has dropped the 2.7 transition as a release goal, I doubt that makes sense.
<jtaylor> is there so much stuff only running with 2.6?
<broder> ScottK: I thought Debian release team dropped 2.7 as a "release goal", because it was too limited in scope
<ScottK> Look at Debian 622279
<ubottu> Debian bug 622279 in release.debian.org "transition: python-defaults (switching default: 2.6 -> 2.7)" [Normal,Open] http://bugs.debian.org/622279
<broder> maybe i misread the bits e-mail
<DooMMasteR> hui
<DooMMasteR> got my ubuntu down to 7,5sec boot time incl. XBMC startup :P
<micahg> ScottK: wait, for wheezy they're sticking with 2.6? ugh
<DooMMasteR> on an AMD E-350
<ScottK> broder: It doesn't change the fact that it puts it on a "Meh, whenever" schedule since there's no mechanism for NMUs to ease the transition (unless, of course, I decided to just make 2.7 default and who cares what it breaks)
<broder> ScottK: ah, i see
<ScottK> micahg: No, they decided switching wasn't a release goal.  It doesn't mean the switch can't happen, just that something preventing it isn't RC.
<ScottK> Now figure the odds of that.
<micahg> well, it just means that we'll be driving most of the transition as I think regardless we're dropping 2.6 for P
<ScottK> Yep.
<slangasek> hmm, my understanding of release goal is "the release team blesses NMUing for this under the same rules as for RC bugs", not quite "this is RC"
<slangasek> I think we could provide the necessary cover for NMUs without it being a release goal, too
<slangasek> (though the release team deciding it's not a release goal is certainly not helpful here)
#ubuntu-devel 2011-08-02
<ScottK> True.  I suppose the semantics are slightly different.
<ScottK> But it's, as you say, not helpful to have it explicitly not a goal for the release.
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<didrocks> good morning
<nigelb> Morning!
<fhd> I've asked this before, but: How do I keep the unity panel from restarting?
<fhd> I've been told that the dbus daemon does that, but I wasn't able to figure out how to make it stop. Except stopping the dbus daemon, but I have learned that this is something I do not want to do again
<RAOF> fhd: Why do you want to?  This might influence what I recommend.
<fhd> RAOF: I'm working on Unity 2D, so I want to launch my own panel
<RAOF> I'd generally drop the executable bit from the unity-panel binary you don't want running.
<fhd> RAOF: So far, I've renamed /usr/bin/unity-2d-panel
<fhd> RAOF: Oh, is there no nicer way?
<RAOF> You could *probably* drop a dbus service file somewhere to override the autospawner.
<RAOF> I'm not sure if that would disrupt the panel that you want to run, though.
<fhd> RAOF: brb
<broder> unity-panel is session bus, right? does d-bus look at ~/.share/dbus-1 or something?
<RAOF> I think it might look in ~/.local/share/dbus-1, yeah.
<RAOF> Then again, it might not.  It's evil like that.
<broder> ugh, this code is illegible, but it does seem like it supports *something* like that
<broder> ~/.local/share/dbus-1/services would be my best guess - you could try dropping .service files in there
 * RAOF wonders why âapt-get install libwayland0:i386â fails because it can't find an install candidate for emacs23.
<mvo> RAOF: try -o Debug::pkgDepCache::AutoInstall=true and -o debug::pkgProblemResolver=true
<RAOF> Ah.  Ok.  At least part of the problem is libwayland isn't Multi-Arch: same.
<fhd> RAOF: Okay, so it seems I better not mess with dbus, eh?
<RAOF> Messing with dbus can lead to sorrow.  So much sorrow.
<fhd> RAOF: Last time I seriously fiddled with Linux development, it wasn't there. I felt safer then.
<broder> aww, i <3 dbus
<broder> mostly because it's nice to have a typed, automatically marshalled ipc mechanism you don't have to think about
<RAOF> *I* like dbus.  But lots of other people like dbus, too, so messing with it is likely to make all sorts of things unhappy.  Like init :).
<fhd> I get the impression that dbus is pretty much anti unix philosophy
<fhd> It does many things (interprocess communication, autospawning and other stuff that seriously messes up my session if I stop the daemon) and does them in an (at least partly) undocumented way
<fhd> Not inteded as a flame, I don't really know how dbus works and what it does.
<RAOF> Nah; it basically does only one thing: IPC, and it's generally not badly documented in my experience.
<RAOF> But stopping it will indeed make one's session blow up.  Lots of things expect IPC to work!
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<AnAnt> would someone sponsor: LP 812120
<ubottu> Launchpad bug 812120 in debhelper (Ubuntu) "Please merge debhelper 8.9.3 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/812120
<AnAnt> also LP 819692
<ubottu> Launchpad bug 819692 in texlive-bin (Ubuntu) "Sync texlive-bin 2009-10 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/819692
<AnAnt> LP 815861
<ubottu> Launchpad bug 815861 in language-support-fonts-ar (Ubuntu) "Please add fonts-hosny-amiri" [Undecided,New] https://launchpad.net/bugs/815861
 * micahg wonders why AnAnt doesn't know the archive is frozen
<doko> please could an archive admin promote the eglibc and gcc-4.6 binaries seen in component mismatches (don't have my keys today)
<ogra_> didrocks, argh ! .... since when does unity-2d depend on nux ?
<didrocks> ogra_: since this release, with unitycore dep
<ogra_> hrm
<ogra_> also does anyone know if unity-greeter is supposed to work at all ?
<seb128> it's working yes
<ogra_> seems lightdm simply ignores it
<ogra_> i only get lots of errors in the log that it cant find the gtk greeter
<seb128> did you set it as to use in your config?
<ogra_> i tried that too
<ogra_> but it ignores the config completely
<ogra_> no matter what i set
<seb128> do you have an old conffile?
<seb128> the format changed in 0.9
<ogra_> well, i touched it once
<seb128> if you edited your config before that you might have an old format leftover
<ogra_> hmm
<seb128> no editing in the old keys will work
<ogra_> well, the file is mostly commented, there are about 5-10 lines that arent
 * ogra_ tries to remember the dpkg setting to force conffile overwriting
<seb128> --force-confnew
<ogra_> heh, found it that second, thanks !
 * ogra_ diffs the file ...
<ogra_> no differences it seems
<ogra_> hmm, it didnt overwrite it
<ogra_> grmbl
<seb128> [SeatDefaults]
<seb128> greeter-session=unity-greeter
<seb128> something like that should work
<ogra_> ogra@horus:~/tmp$ dpkg -x /var/cache/apt/archives/lightdm_0.9.2-0ubuntu4_armel.deb .
<ogra_> ogra@horus:~/tmp$ ls etc/lightdm/
<ogra_> users.conf
<ogra_> that doesnt seem right
<ogra_> or is lightdm.conf obsolete ?
<seb128> it's not, but it's not required by default I think
<ogra_> hmm, let me delete it and restart lightdm
<seb128> so maybe copy the source one over if you need a config
<seb128> well, lightdm default to the gtk greeter
<ogra_> but the .conf isnt shipped at all
<seb128> well it's not needed
<seb128> you only need to create one if you want to tweak
<ogra_> then i shouldnt need it either
<seb128> ogra_, what are you trying to do?
<seb128> it default to gtk, not unity
<seb128> didn't you say you want to try the unity greeter?
<ogra_> but the gtk greeter was removed with my last update
<seb128> no
<seb128> the binary was renamed
<seb128> you should have lightdm-gtk-greeter
<ogra_> i'm just trying to get a running system after an upgrade
<seb128> the -example in the name was dropped
<ogra_> which removed the gtk greeter and left me stuck with a black screen after boot
<seb128> dpkg -l |  lightdm-gtk-greeter
<seb128> dpkg -l | grep lightdm-gtk-greeter
<ogra_> yes, i installed that manually to actually get an x session up
<ogra_> (since startx doesnt work anymore)
<seb128> but lightdm doesn't start still?
<ogra_> the upgrade installed unity-greeter and removed lightdm-gtk-example-greeter
<ogra_> it starts now that i manually installed the gtk greeter
<seb128> hum
<ogra_> i was just assuming that the removal means we default to the unity-greeter now
<seb128> I think you had the unity-greeter installed manually before
<ogra_> yes
<ogra_> but never used it
<seb128> no, lightdm depends on lightdm-gtk-greeter | lightdm-greeter
<seb128> where lightdm-greeter is a virtual package provided by all greeters
<seb128> so you didn't get lightdm-gtk-greeter because you had a greeter already installed, the unity one
<ogra_> why wasnt the lightdm-gtk-greeter package pulled on my disk then ?
<seb128> it's a bit of a corner case we didn't consider in upgrades
<ogra_> ah
<ogra_> now it starts to make sense
<seb128> because unity-greeter that you install provide lightdm-greeter
<seb128> installed
<ogra_> right
<seb128> you could have tweaked your config for it and wanted to use it instead of the gtk one
<seb128> in which case you are allowed to uninstall the gtk one
<ogra_> and for that i need to create a lightdm.conf ?
<seb128> yours is a bit of a corner case due to the rename of the gtk greeter in oneiric
<ogra_> yeah
<seb128> I though you wanted to use the unity greeter
<ogra_> yes
<seb128> [SeatDefaults]
<ogra_> so i need to create a lightdm.conf
<seb128> greeter-session=unity
<ogra_> yeah, with the values you gave above, i got that
<seb128> it's "unity", not "unity-greeter"
<seb128> before I gave you the wrong name
<ogra_> ah, k
<ogra_> will try it in a sec
<seb128> in fact you might need
<seb128> [LightDM]
<seb128> [SeatDefaults]
<seb128> greeter-session=unity
 * ogra_ crosses fingers
<ogra_> seb128, thanks, works ... !!
<ogra_> greeter-session=unity-greeter was the right setting btw
<seb128> ogra_, great, yw ;-)
<seb128> ok
<ogra_> just unity doesnt work
<ogra_> now on to the rest of my broken desktop :/
<ogra_> hmpf, overlay-toolbars are clearly completely broken
<ogra_> if i hover over the scrollbar, the two arrows appear just fine, but moving the mouse to actually use them makes them disappear before i can reach them
<ogra_> not so helpful
<ogra_> didrocks, is there a chance that we make unity-2d (the metapackage) depend on nux too ?
<didrocks> ogra_: I don't think so
<ogra_> didrocks, my desktop is totally screwed because half of the elements are missing, seems the launcher was upgraded but i still have the old panel
<ogra_> which crashes immediately
<didrocks> ogra_: I'll try to separate nuxcore from nux
<didrocks> ogra_: hum?
<ogra_> well, whatever gets me a proper upgrade on arm
<didrocks> ogra_: not sure that influence it TBH
<ogra_> your upload of nux breaks the archive for two days
<ogra_> for arm
<ogra_> thats normal ...
<ogra_> it didnt affect unity-2d until the nux dep was there
<didrocks> ogra_: how come for two days?
<didrocks> do you mix 2 discussions there?
<didrocks> can we try to focus on one please:)
<ogra_> well, until everything is build, published and all the packages are given back
<didrocks> ogra_: so, I pushed nux yesterday evening
<didrocks> not two days again
<ogra_> its the same discussion
<didrocks> I was still there around midnight
<didrocks> and see that armel platform wasn't working
<ogra_> right, tomorrow or later tonight unity will be installable again
<didrocks> the build FTBFS because of the buildd being screwed
<didrocks> a give back was done few hours before
<didrocks> https://launchpad.net/ubuntu/+source/nux/1.0.8-0ubuntu1
<ogra_> well, that just adds up to the time
<didrocks> it's now build
<ogra_> yes
<didrocks> 14:38:38     ogra_ | your upload of nux breaks the archive for two days
<didrocks> the fact that:
<ogra_> my prob is that unity-2d-launcher was upgraded, but not the other buts
<ogra_> *bits
<didrocks> unity-2d deps on unity, which deps on nux
<didrocks> I raised the issue with dx
<didrocks> they ignored it
<didrocks> sorry, please, talk to upstream about that
<ogra_> ??
<didrocks> I can't magically patch their software
<didrocks> and remove that dep
<ogra_> i just want it packaged in a way that everything gets updated at the same time
<didrocks> ogra_: it is?
<ogra_> so i dont sit here with a non functional desktop if you upload a new nux
<didrocks> unity-panel deps on latest libunitycore and latest libnux
<ogra_> it isnt, i have the new launcher here and everything else crashes
<didrocks> what issue do you have? how did you end up with a semi working?
<ogra_> i ran update-manager
<seb128> seems like some upgrade should Breaks unity-2d <<
<ogra_> thats what i mean
<didrocks> ogra_: ah, for that upgrade, yeahâ¦
<ogra_> i just want all components upgraded at the same time
 * didrocks thoughts about next one, as there is a nux (>= â¦, <<) and unity (>=, <<)
<ogra_> so either everything is broken or everything works :)
<seb128> if apt didn't block it then a breaks is required
<didrocks> but forgot about that transition
<seb128> ok, let's move on then, this one is done and the next one will work
<seb128> thanks didrocks ;-)
<ogra_> yeah
<ogra_> thanks :)
<didrocks> sorry for that, just thought about the normal case, with new unity-2d with the dep
<didrocks> didn't thought about no dep -> dep
<didrocks> I can still fix it in a future nux upload, not sure that worth it though
<seb128> no worry, we can't think about everything ;-)
<ogra_> nah, its fine
<didrocks> ok, sorry ogra_ ;)
<ogra_> why ? i run the development version, i'm supposed to expect such issues ;)
<ogra_> no need to feel sorry
<didrocks> ogra_: yeah, but we try to minmize them :)
<ogra_> hmm, the unity-greeter is really slow
<ogra_> takes about 20sec to scroll the users behind the login element if i switch
<ogra_> (20sec to scroll from my account to the guest session or "other")
<seb128> works fine here
<ogra_> well, you dont use a framebuffer based xserver i would guess
<ogra_> :)
<seb128> indeed not
<ogra_> which is the default on arm
<seb128> note that the unity greeter is not default yet for a reason ;-)
<ogra_> no accel, not even 2d
<ogra_> yeah, i tought that, i'm just scared it will use clutter or other GL stuff
<seb128> ogra_, that's not planned
<seb128> ogra_, we would have to do a non-gl greeter and deal with fallback if we were to do that
<infinity> So, uhm.  Is compiz meant to work right now? :P
<infinity> I seem to be stuck at a console at this conference.
<seb128> infinity, it should work yes
<doko> should or does?
<seb128> doko, well it's not know to be broken, i.e works for others and no bug report yet
<infinity> seb128: Looks like I have #819739  Same trace.
<doko> seb128, on armel?
<seb128> oh, that's unity, not compiz ;-)
<infinity> This is on 686.
<seb128> doko, isn't armel using unity-2d?
<infinity> seb128: armel can use 3d on some platforms, but usually 2d.
<seb128> dunno about compiz on armel sorry
<seb128> infinity, but yeah, unity seems to be broken on intel video cards today
<seb128> dx is working on it
<infinity> seb128: Special.  Oh well, good thing I travel with 3 laptops, and one of the three still works. ;)
<doko> didrocks, seb128: nux is still broken on powerpc
<didrocks> doko: yeah, I pinged a week ago dx about it
<doko> as long as build failures are seen as noise ...
<doko> seb128, could you promote the eglibc and gcc-4.6 binaries (http://people.canonical.com/~ubuntu-archive/component-mismatches.txt) don't have my keys today
<seb128> doko, ok
<doko> thanks
<seb128> yw
<seb128> doko, done
<persia> infinity, Just to keep track of it, I've filed bug #819802
<ubottu> Launchpad bug 819802 in plymouth (Ubuntu) "Please refactor plymouth to remove the libdrm2 dependency when text themes are used" [Undecided,New] https://launchpad.net/bugs/819802
<infinity> persia: THanks.
<persia> Were there any others that were pointlessly obvious to you, except you didn't have time to look at them yet?
<infinity> persia: Not off the top of my head, but I'll go through the list again when I get some free time.
<persia> infinity, No special impetus: just wanted to make sure I hadn't missed something you said before.
 * infinity nods.
<micahg> Riddell: since you're still listed as having an archive day today, can you do a sync for me?
<Riddell> micahg: I could if you ask nicely
<Riddell> although I'm not doing regular archive admin for the moment
<micahg> Riddell: could you please sync goffice 0.8.17-1 from sid?
<micahg> Riddell: you might want to remove your name from here than: https://wiki.ubuntu.com/ArchiveAdministration#Archive_days
<Riddell> micahg: synced
<micahg> Riddell: thanks!
<doko> infinity: compiz/nux crashes (on x86), but at least xubuntu does work
<micahg> doko: BTW, do you have any specific interest in the binutils in universe (z80, avr)?  can I update them?
<ScottK> micahg: Why?
<ScottK> They are for archs we don't build.
<micahg> ScottK: I thought they were cross compilers
<micahg> they're built on arch: any
<ScottK> Perhaps,  I thought not, but don't mind me.
<cyphermox> mdeslaur: back about g-k-d; setcap fails with operation not permitted on the livecd
<mdeslaur> right...so file caps aren't supported on the livecd filesystem, and ubiquity just copies all the files directly to the hard disk when installing
<mdeslaur> cyphermox: if we want filecaps, we need to ask ev about adding something to ubiquity to set it after copying the files
<cyphermox> mdeslaur: I can still try to apply the commits that will let it start for now, even if it's with insecure memory
<mdeslaur> cyphermox: yes, please do...and I'll add ubiquity to the bug also
<cyphermox> ok
<stgraber> mdeslaur: I remember a session about it back at UDS Brussels. Basically the situation back then was that squashfs doesn't support them and tar doesn't either unless it's patched. An idea would have been to make dpkg handle that and then have some way to re-run that part of the package installation (ubiquity would do that)
<mdeslaur> stgraber: right...until proper filecaps are implemented all over, I think ubiquity needs to manually handle this case
<mdeslaur> ev: can I assign bug #813755 to you?
<ubottu> Launchpad bug 813755 in gnome-keyring (Ubuntu) "gnome-keyring-daemon fails to start as it can't get capabilities" [Undecided,Confirmed] https://launchpad.net/bugs/813755
<seb128> mdeslaur, cyphermox: why is that issue only showing up in oneiric?
<ev> mdeslaur: why can't the package in question call setcap in the postinst?
<mdeslaur> seb128: gnome-keyring never needed file caps before
<mdeslaur> ev: it does
<seb128> ev: that's what it does
<ev> so then why does anything need to be done in ubiquity?
<mdeslaur> ev: oh, I think my knowledge of how ubiquity works is incomplete
<mdeslaur> ev: ubiquity will actually install the package? and not copy it over from the livecd?
<ev> mdeslaur: ubiquity is a fancy version of cp
<ev> it copies from the read-only copy of the squashfs
<ev> the mounted squashfs*
<mdeslaur> ev: squashfs doesn't handle file capabilities
<seb128> ev: <mdeslaur> right...so file caps aren't supported on the livecd filesystem, and ubiquity just copies all the files directly to the hard disk when installing
<ev> ah
<ev> rubbish
<mdeslaur> +1
<mdeslaur> :)
<mdeslaur> ev: ideally, we'd have a nice solution for file capabilities, but for now, it's a single file in a single package that needs it, AFAIK
<ev> so the package in question should carry a script in /usr/lib/ubiquity/target-config to set things up properly
<ev> see jockey for an example
<cyphermox> oh, awesom
<mdeslaur> oh, cool
<cyphermox> thanks ev!
<ev> sure thing
<mdeslaur> thanks ev
<ev> no problem
<seb128> ev: do you plan an ubiquity upload?
<seb128> ev: can you drop the libcheese-gtk-dev build-depends with the next upload? we demoted cheese to get the new version to build and ubiquity is bring a ton of clutter, mx, gstreamer, etc packages on component mismatch with that build-depends
<ev> seb128: soon. I'm trying to land the pygi branch, but I'm still sorting out libtimezonemap (libmap extracted from indicator-datetime)
<ev> seb128: so is there a version of cheese in main?
<seb128> ev: no
<seb128> ev: we can discuss bringing it back but somebody will need to open mirs for that stack of universe depends and make a case for the CD space use
<ev> seb128: I'm confused. We had a conversation a few weeks ago where I said I needed it for the installer.
<seb128> ev: well, we had a depwaiting version of cheese not building for weeks so we couldn't keep it like that
<seb128> ev: somebodyhas to do the mirs and do the case for the extra CD use I'm afraid
<ev> depwaiting on mx, presumably?
<seb128> clutter-gst, clutter, mx
<seb128> we will likely need clutter and clutter-gst for other things
<seb128> (empathy, totem)
<ev> I was just going to say :)
<ev> so it's just mx then
<ev> right, will sort
<seb128> ev: another issue is that cheese use camerabin which is in one of the gstreamer universe sets
<seb128> not sure which one now
<ev> right
<seb128> so we will need to sort that in some way
<seb128> kenvandine suggested to maybe distro patch camerabin to -good as we do for others
<ev> okay
<seb128> ev: sorry about the demotion but the undefined depwaiting status was benefiting to nobody, I prefer to have clearly showing on component mismatch and have the issue tracked
<seb128> ev: we will try to get the clutter stack mir filed from the desktop side
<ev> it's okay, I entirely understand your action given the depwait
<slug> hi, i cannot seem to be able to use ccache with pbuilder, any thoughts?
<ScottK> slug: See debian bug 606687
<ubottu> Debian bug 606687 in pbuilder "ccache support fails in the face of su PATH mangling" [Normal,Open] http://bugs.debian.org/606687
<slug> ScottK: interesting. can't i just set DEBBUILDOPTS="--prepend-path=/usr/lib/ccache" ?
<cyphermox> ev: for the target-config script, I should use in-target or something and consider we're outside the installed system right?
<ev> cyphermox: correct
<cyphermox> ok, thanks
<slug> ScottK: dpkg-buildpackage: unknown option or argument --prepend-path=/usr/lib/ccache. I guess not :)
<slug> ScottK: thanks for the heads up!
<EagleScreen> take a look to this, please https://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/793792
<ubottu> Ubuntu bug 793792 in user-setup (Ubuntu) "New users in admin group cannot use policykit" [Undecided,Confirmed]
<SpamapS> slangasek: I see you have some minor changes staged for upstart.. I also have a few small changes. Alright to push them into the branch (and delay the upload until after A3 freeze?)
<kees> archive admins around? who is publishing the maverick kernel update?
<jono> wow, I am getting some serious screen tearing
<jono> is this a known issue?
<jono> I notice it particularly when using Thunderbird
<jono> this is in 11.10
<slangasek> SpamapS: yes, those changes follow the rule "suitable for the archive but not worth an upload on their own"
<SpamapS> slangasek: ok, I pushed them to the bzr tree after concluding just that. :)
<SpamapS> slangasek: of course, now we've gotten the branch out of sync ... as jhunt uploaded a fix .. but I will fix that w/ import-dsc
<slangasek> SpamapS: oh sigh :)
<SpamapS> AttributeError: 'DistributionBranch' object has no attribute 'pristine_tar_source'
<SpamapS> double sigh
<RAOF> SpamapS: Re: w-scan in the natty-proposed unapproved queue - when there's a second upload to -proposed superceding an existing upload in -proposed we want the changes file to contain the changelog for both, right? So, in this case, both -1ubuntu0.1 and -1ubuntu0.2?
<TheMuso> RAOF: I think thats what has usually happened, but don't quote me on that. I have seen proposed uploads with more than one changelog entry.
<RAOF> TheMuso: Yeah.  I know it would be correct to have both, but I don't know if our tools will break if we *don't* have both. :)
<TheMuso> Right.
<TheMuso> Can anybody tell me where I can find the patch pilot calendar? I suspect I am on this week at some point, but don't know for sure. Daniel usually sends out invites, but since he is away, and I didn't receive one, I don't know where I stand for this month.
<ajmitch> TheMuso: https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<ajmitch> linked from the PatchPilot page
<TheMuso> oh right, thanks
<Daviey> TheMuso: You'll have a fun Friday, with everyone pushing their stuff post freeze :)
<TheMuso> Daviey: Not exactly, bare in mind that my Friday is before most others, i.e since I am in Sydney, I will be dealing with the end of Thursday for those in Europe/US.
<Daviey> TheMuso: bah.
<ajmitch> with feature freeze next week, I guess there'll be a bit to get in
<Daviey> ajmitch: please don't scare me, i know how much we still need to do :)
<ajmitch> Daviey: I won't count down the seconds for you then :)
<Daviey> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<micahg> about 160 requests for upgrades still along with the unmerged stuff (with some overlap)
<Daviey> The AA queue will unleash a world of changes :/
<Daviey> ugh, i've had a sync request waiting since 2011-07-20.
<micahg> there's that too :) I hope we get normal sync runs after alpha3 again
<ajmitch> we just have to find a friendly AA
<SpamapS> RAOF: generally yes, though I prefer to avoid two uploads as it binds the two SRU's together
<micahg> if it's in unapproved, the version can be reused
<RAOF> SpamapS: In this case the second SRU is âfix the buildâ, so there's a certain amount of unavoidable tying :)
<SpamapS> micahg: there's one already in proposed, and this is a new one.
<micahg> ah
<SpamapS> For the record, I think its silly that our tools don't do this automatically every time. :-P
<SpamapS> I know that some do
<SpamapS> but not all
<micahg> -v?  supposedly bzr-builddeb has something to do it now
<SpamapS> merge-package does, I don't know about bzr bd.
<Daviey> micahg: ah, interesting.. i can throw my crappy shell script away then!
<RAOF> It'd be pretty nice to have a wrapper that checks what the current version in the archive is and adds an appropriate -v, yeah.
<micahg> idk, jelmer was using it
<Daviey> RAOF: Ready to cry? http://pb.daviey.com/OR61/
<RAOF> Daviey: Looks pretty sane to me.  You need to special case uploads to -proposed, though :)
<Daviey> RAOF: patches^D rewrite welcome
<RAOF> Well, and the -sa bit is moderately wrong :)
<SpamapS> Hrm.. upstart is missing upstream-1.3
<SpamapS> I wonder if we should back out the changes and re-run the import-dsc's to get the upstream versions sorted
<SpamapS> otherwise I think the package import will be broken forever.
<micahg> SpamapS: maybe talk to the importer folks
<SpamapS> Yeah I need to understand how it works
<Daviey> SpamapS: Unless it's borked, if a UDD commit differs from what is in the archive.. it should pop it off, and import the package from the archive.
<Daviey> so i imagine it will do the right thing.
<Daviey> But i tend to have too much confidence in stuff working :)
<SpamapS> Daviey: hrm
#ubuntu-devel 2011-08-03
<jrwren> hello, i'm trying to backport the oneric netatalk package to natty and hopefully move both to 2.2.0 final, but it does not build on natty for me. it only builds on oneric. Any C dev care to take a look?
<poolie> jrwren: pastebin the failure
<poolie> please
<jrwren> http://paste.mitechie.com/show/369/
<jrwren> but I look at that c code and the array literal looks good and complete and matches the struct definition
<poolie> huh
<poolie> i'd guess it's a version incompatibility between the C file and whichever header provides that struct
<poolie> or type
<lifeless> slangasek: https://code.launchpad.net/~lifeless/ubuntu/oneiric/apt/bug-816606/+merge/70250
<ubottu> Ubuntu bug 70250 in Launchpad itself "Support Requests difficult to mark as answered (dup-of: 3401)" [Undecided,New]
<ubottu> Ubuntu bug 3401 in Launchpad itself "Hard to discover how to close a support request" [Medium,Fix released]
<lifeless> hah, terrible parsing there ubottu
<infinity> lifeless: Depending on a keyring seems like the wrong direction to go to fix that, no?
<lifeless> infinity: I talked it over with slangasek a few days aback
<lifeless> infinity: e.g. not calling it would be sensible too :) - or handling the error
<lifeless> infinity: he suggested that as debian hard depend, hard depending was simpler and consistent.
<lifeless> infinity: in this very channel
<infinity> lifeless: Oh, I agree it's consistent, I also would call both "wrong".  But whatever, the keyring packages aren't huge.
<lifeless> infinity: I'm more worried about apt-key failing if someone has no internets.
<didrocks> good morning
<StevenK> lifeless: Or living in NZ.
<StevenK> Which is much the same thing.
<infinity> lifeless: (Out of curiosity, what as actually failing without a keyring installed?)
<infinity> s/as/is/
<lifeless> infinity: apt post-inst
<lifeless> infinity: e.g. in debootstrap
<infinity> lifeless: apt's postinst has all the keyring ops guarded.
<infinity> lifeless: Hence my question...
<lifeless> infinity: and yet
<lifeless> Setting up apt (0.8.15.4ubuntu2) ...
<lifeless> ERROR: Can't find the archive-keyring
<lifeless> Is the ubuntu-keyring package installed?
<lifeless> dpkg: error processing apt (--configure):
<lifeless>  subprocess installed post-installation script returned error exit status 1
<infinity> lifeless: I'm looking at the postinst for 0.8.15.1ubuntu2, maybe someone removed the || true...
 * infinity upgrades.
<lifeless> remove the keyring first :P
<infinity> Yeah, someone removed the || true...
<infinity> Very confused.
<infinity> Meh, whatever.  The dependency doesn't bug me that much.
<lifeless> I'm happy to propose ||true instead
<lifeless> I've requested a debdiff from https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=apt&field.package_type=ignored&field.package_type-empty-marker=1
<lifeless> to poke at the overall delta
<infinity> Well, someone rewrote that part of postinst entirely and broke it...
<infinity> There used to be a bit that tested for /etc/apt/trusted.gpg and copied /usr/share/apt/ubuntu-archive.gpg in place if you didn't have one.
<infinity> And /usr/share/apt/ubuntu-archive.gpg is from apt, not a keyring package.
<infinity> And then apt-key update was guarded with a true for extra paranoia, I guess.
<infinity> Ultimately, if people want to use apt without keyrings, I imagine we should let 'em.
<lifeless> what priority would you say the bug is ? (given it breaks debootstrapping ..)
<infinity> The current issue?  high/critical.
<infinity> And fixing it with a hard dependency to match Debian is more than fine for now.
<infinity> I just don't want to lose focus on "maybe this should get a second look".
<lifeless> I have to run out for a bit; the mp is up - I can't land (not core-dev)
<infinity> I can do it after breakfast.
<lifeless> awesome
<lifeless> though, EWHATTZAREYOUMAD? occurs to me
<infinity> I'm in Cambridge.
<lifeless> oh cool
<lifeless> verra nice, if you stay out of the hotels :P
<infinity> It would be nicer if it was Cambridge proper, and not Cambourne.
<infinity> But whatever.
<RAOF> Which archive admin wants to be a hero and unbreak nvidia (among other binary drivers) by performing the sync requested by bug #811231?  Fabulous prizes await!
<ubottu> Launchpad bug 811231 in dkms (Ubuntu) "Sync dkms 2.2.0.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/811231
<infinity> RAOF: Can you elaborate on the prizes?
<RAOF> infinity: People stop bitching about nvidia being broken!
<infinity> RAOF: They're not bitching to me, though...
<StevenK> That can be fixed.
 * infinity fires up the syncinator anyway.
<RAOF> infinity: I can cause X to randomly hang for you, if you like :)
<infinity> RAOF: Do it in a way that's both undetectably targetted at me and doesn't effect others, and I'll be impressed.
<infinity> RAOF: Blacklist removed, sync away.
<RAOF> Woot!
<lifeless> infinity: thanks
<jamespage> morning; please could an AA accept the NEW binary packages for stapler, activemq-protobuf, felix-shell-tuiÂ and activemq-activeioÂ into oneiric - thanks
<kelemengabor> hi, is there any evoution-indicator developer around who could take a look at bug 437963 ?
<ubottu> Launchpad bug 437963 in Ubuntu Translations "Untranslatable strings in Plugin manager" [Medium,Triaged] https://launchpad.net/bugs/437963
<jrwren> poolie: the header that defines that struct is also part of netatalk. it builds on oneric, but not natty. its very strange.
<seb128> ev: is usb-creator supposed to work in oneiric? out of raising and exception when formating usb sticks it fails to record the boot loader there
<ev> it is supposed to work, yes
<ev> bug please
<seb128> ok
<seb128> bug #806611 is the formating one
<ubottu> Error: Launchpad bug 806611 could not be found
<seb128> same error at least
<seb128> ev: what info would be useful for the boot loader error?
<seb128> let me try to see if it prints something on stdout to start
<ev> ~/.cache/usbcreator.log if memory serves
<seb128> ev: ok, thanks, that was helpful, it's an issue on my session
<seb128> ev: DBusException: org.freedesktop.DBus.Python.dbus.exceptions.DBusException: com.ubuntu.USBCreator.Error.NotAuthorized
<ev> ah
<seb128> ev: which in fact is "the polkit service is not running"
<ev> that'll do it :)
<seb128> ev: thanks! ;-)
<ev> sure thing
<cnd> slangasek, do you know of news on the new arm build architecture?
<cnd> how long before we can build armel packages in our ppas
<ojap> hi, where is the best place to find someone who can help me fix my first bug in ubuntu?
<and`> ojap, what's that about?
<ojap> and`: looking to fix first bug in ubuntu and wondering whether there are any specific places where I can get guidance from an experienced developer
<and`> ojap, I would suggest you to open a bug in Launchpad and provide there all the details
<and`> ojap, if it's packaging-related, feel free to move to #ubuntu-motu
<ojap> and`: I don't have a bug I want to report, I want to contribute code to existing bugs. Just wondering whether there is help available to guide me in finding suitable bugs, learning how to branch the code, etc.
<and`> ojap, add your patches to the bug reports and they'll be reviewed and eventually uploaded.
<jbicha> ojap: see http://harvest.ubuntu.com/
<jbicha> and https://wiki.ubuntu.com/Bugs/HowToFix
<and`> jbicha, thanks :)
<jbicha> or http://developer.ubuntu.com/packaging/html/ but it's still a work-in-progress
<jbicha> yes, please ask if you can't find anywhere to contribute, I'm sure we can find something you can do :-)
<ojap> thanks, I have read those links before and they are great. At the moment I am just trying to find the right bug that is suitable and that I have a chance of understanding and fixing
<ojap> jbicha: any suggestions before a beginner like me would be great, thanks
<jbicha> ojap: how much of a programmer are you and what software do you like to use?
<ojap> jbicha: i'm a student programmer and have fair experience with languages like java, c++ and web languages.
<jpds> ojap: Find a program you like, and work from there.
<jbicha> exactly, it's more rewarding to fix bugs in software you use
<jbicha> either use harvest or just look at the launchpad bugs page for something interesting
<jbicha> harvest lets you look for bitesize bugs which should be relatively simple to fix to get you started
<ojap> jbicha: thanks, have been looking through harvest and launchpad, alot of the bugs in harvest already have people working on them and finding the right bug in launchpad can take time. i'll keep looking though
<jbicha> ojap: I reported bug 820058 yesterday and it should be a very easy fix
<ubottu> Launchpad bug 820058 in ubiquity (Ubuntu) "[slideshow] Still says "Welcome to Ubuntu 11.04"" [Undecided,New] https://launchpad.net/bugs/820058
<jbicha> just to get you used to checking out the source code, finding where to fix it and then getting that fix into Ubuntu
<ojap> jbicha: that looks really great, thanks.  how the will the source code appear on my machine? (sorry if that sounds stupid!)
<jbicha> in this case I believe the correct source can be found at https://launchpad.net/ubiquity
<jbicha> so you would run bzr branch lp:ubiquity to download the source
<micahg> jbicha: I thought the slideshow is a separate source
<jbicha> yes, sorry about that, try bzr branch lp:ubuntu/ubiquity-slideshow-ubuntu
<ojap> no probs, thanks really useful
<ojap> jbicha: thanks, seeing "Branched 35 revision(s)." in terminal - could I be a pain and ask for some guidance for the next couple of stages?
<jbicha> well you've got the sourcecode right there, and it's plain text so you just look around for "Welcome to Ubuntu 11.04"
<jbicha> rgrep is a shortcut but you don't need it
<ojap> jbicha: yeah great, found the welcome.html - thanks again
<jbicha> and then if you go back to the top directory of the source code, you can run dch -e to add a changelog entry describing
<jbicha> what you did
<jbicha> sorry, dch -i
<jbicha> dch -i adds a new entry, dch -e edits the entry after you've already made it
<ojap> jbicha: while I am changing the text, I'm guessing the pictures also be updated for oneiric?
<jbicha> you don't have to worry about the pictures, they need to be updated but you'll want to talk to whoever did that for natty
<jbicha> if you want to do that
<jbicha> because we're the upstream for the slideshow, you need to make the sure that the version number is just 41 not the .0ubuntu1 stuff
<jbicha> in the changelog which is actually stored in debian/changelog by the way
<jbicha> actually contributing patches is kinda complicated, there's so many little things to understand, that's part of
<jbicha> why the new packaging guide is being written
<ojap> jbicha: ok, well I don't know who is responsible for the pictures, so I'll focus on the text. I presume I should also update the slideshows for the kubuntu, etc folders.?
<jbicha> yes, if you look at https://code.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu you can look at the source code online and see who has been making changes to it
<ojap> ok, seems Evan Dandrea  is responsible
<micahg> what do we do with SRU requests for control file description changes?  in theory they could go in if we ever had an SRU for the package, but they don't really qualify on their own
<ojap> jbicha: using the dch -i command and have updated changes, how do I get my text saved in the file?
<jbicha> ojap: I think you're about ready for the "Committing the fix" stage of https://wiki.ubuntu.com/Bugs/HowToFix
<jbicha> but you really need to do https://wiki.ubuntu.com/UbuntuDevelopment/GettingSetUp first if you haven't yet
<ScottK> micahg: I'd mark them wontfix with a comment like that.
<ojap> jbicha: yeah, completed the getting setup guide
<micahg> ScottK: yeah, but then they get closed instead of being in a pending type of queue
<ScottK> True.  There is no "Really unlikely to fix" state.
<jbicha> ojap: ok then can you commit and push your changes?
<ojap> jbicha: I presume that I don't need to test the fix before commit?
<jbicha> ojap: you should do that too, I skipped that step because I'm not sure how to test it
<micahg> ScottK: this is actually a situation where UDD could shine if we could get proper branches, we could stage a fix like this in case of an SRU
<jbicha> bzr bd will build a Ubuntu package for you to install
<ScottK> micahg: Perhaps.
<jbicha> ojap:  just run ./test-slideshow.sh
<ojap> jbicha: thanks again!
<ojap> jbicha: thanks for your time and effort, greatly appreciated!
<slangasek> cnd: no, I believe that's in IS's hands at this point
<cnd> slangasek, ok, thanks
<jbicha> ojap: one more thing, in your changelog line add (LP: #820058)
<jbicha> this tells launchpad to automatically close the bug when the package is built & released
<jbicha> you can debcommit and bzr push again
<jbicha> then propose it for merging and subscribe ubuntu-sponsors to the merge request after you submit it
<SpamapS> james_w: I have a question about package importing and diverged branches, if you have a moment.
<ojap> jbicha: noticed on this page, https://code.launchpad.net/~ojap/ubuntu/oneiric/ubiquity-slideshow-ubuntu/fix-for-820058 the recent revisions does not have a clickable link to my launchpad account, do you know how I can fix this?
<ojap> jbicha: found that I put a capital letter in the changelog, don't worry. thanks.
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<dpb_> Hello all, is there a policy in ubuntu that packages (during install) not prompt the user and instead just choose sane defaults.  Obviously, running some packages through dpkg-configure will trigger questions, but for the most part when upgrading or installing, I don't see them.  I know when I switched over from debian it was one of the things that stood out to me, but that was a while ago.
<jbicha> dpb_: debian policy is ubuntu policy basically
<maco> dpb_: i think there's a priority level set to debconf questions and we set a higher priority requirement
<dpb_> jbicha, thx, I have heard that as well.
<dpb_> maco: Thx, didn't even think about that... let me check into that.  Was there any official docs or decision on the higher policy setting?
<jbicha> oh, I misunderstood your question, listen to maco instead
<dpb_> jbicha: I wasn't really asking the question very well to begin with. :)
<maco> jbicha: there *is* an ubuntu policy manual, btw. i kinda wish it was just a diff, but its actually a rewrite...it adds a "metapackages" Section for debian/control and a few other things like that
<maco> dpb_: no idea, i think its been that way longer than ive been around here
<dpb_> maco: gotcha. Yeah, I have been using ubuntu for a while and it's something i noticed pretty quickly.
<maco> i didnt use debian til after i used ubuntu
<ScottK> maco: Actually it is a diff.
<maco> ScottK: where?
<maco> http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/  <-- what im thinking of
<ScottK> maco: diff debian-policy and ubuntu-policy
<maco> *snort*
<maco> i mean i think itd be nice if it was actually *displayed* as  diff
<maco> "here's a short list of things we do differently:"
<ScottK> I feel the same way about the packaging guide.
<ScottK> That one is, unfortunately, a rewrite.
<dpb_> maco: thx for that, let me get read and get back.  I apprecaite it.
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Adsa> Can you check this out please http://alyshia.myvi.net/opportunity.html
<Adsa> Can you check this out please http://alyshia.myvi.net/opportunity.html
<broder> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<broder> (the link is spam)
<Tm_T> he left already
 * ajmitch isn't surprised 
<broder> oh, didn't notice. bah
<ajmitch> still useful to ban for if they try & spam again
<Tm_T> well, most likely would try spam with other nick and ip
<broder> hmm...is ubottu's list of channel ops up to date?
<ion> Any IRC ops here?
<Keybuk> (in case he comes back)
<broder> thanks, Keybuk
<ScottK> broder: I suspect it is.  You might talk with cjwatson when he's around about adding some more since several of the current ones aren't particularly active.
<broder> ScottK: does #ubuntu-devel not fall under the irc council's jurisdiction?
<ajmitch> that's a tricky one
<ScottK> No.
<ScottK> AFAIK, IRCC is welcome to help out on devel channels, but they don't run them the same way they do others.
<JanC> IRC Council & Freenode Staff can act as ops here
<JanC> but that's probably set as a backup
<broder> i'm less concerned about ownership than i am about there being people to respond to issues
<broder> if IRCC can act as ops, it seems like including them in ubottu's !ops factoid would be fine
<JanC> broder: they aren't here necessarily, but you can contact them & Freenode staff in their own channels in case of emergency
<JanC> broder: "/msg chanserv access #ubuntu-devel list" will show you the people with "ops" BTW
<nhandler> IRCC and freenode staff generally only use their access in cases where named OPs are not present (or occassionally if the user in question is causing namespace/network issues).
<JanC> nhandler: that's more or less what I mean by "in case of emergency"
<JanC> (this case wasn't one)
<lifeless> infinity: should I file a follow-on bug to the apt postinst, for the further discussion?
<TheMuso> c
<hallyn> udd problem - lp:ubuntu/maverick-updates/libvirt does not exist.  How can I get it created?
<hallyn> (lp:ubuntu/lucid-updates/libvirt does exist)
<james_w> SpamapS, I have plenty of moments for you, but I'm sprinting this week
<james_w> SpamapS, perhaps drop me a mail?
<SpamapS> james_w: will do
<micahg> hallyn: file a bug against the UDD project?
<hallyn> micahg: (looking)
<hallyn> micahg: will do, thanks
#ubuntu-devel 2011-08-04
<maxb> hallyn: http://package-import.ubuntu.com/ can show you packages the importer is currently errorring on, libvirt being one of them
<maxb> In this case it looks like some sort of bug in bzr-builddeb's code
<infinity> lifeless: Nah, it's just on my list of things to informally chat with mvo about, no big deal.
<didrocks> good morning
<bambee> hi, http://paste.ubuntu.com/658502/ <-- an idea ?
<hrw> hi
<hrw> can someone maintaining networkmanager look at bug 819700 and tell me how to help?
<ubottu> Launchpad bug 819700 in network-manager-applet (Ubuntu) "NM applet does not lists networks" [Undecided,New] https://launchpad.net/bugs/819700
<debfx> bambee: could you try reinstalling virtualbox-dkms
<geser> hrw: cyphermox takes care of network-manager
<hrw> geser: thx, will wait for him to wake up
<bambee> debfx: trying
<bambee> debfx: good point, it's fixed, thanks
<tkamppeter> I am packaging CUPS 1.5.0 and the saemon segfaults. If I start it from the command line ("sudo cups -F") it does not dump core, even after "ulimit -c 9999999". How do I get a core file?
<tkamppeter> s/saemon/daemon/
<geser> tkamppeter: IIRC you had so set a value in /proc else the core dump gets routed to apport
<tkamppeter> geser, thanks, found a solution: Run the command in a root shell.
<tkamppeter> geser, did not core, what do I have to set in /proc exactly
<geser> tkamppeter: echo core > /proc/sys/kernel/core_pattern
<geser> currently it should contain a pipe to apport
<tkamppeter> geser, yes
<tkamppeter> geser, I tried your command and could not find the core, then I tried to set /tmp/core and did not ghet a core in /tmp ...
<geser> hmm
<tkamppeter> geser, switched AppArmor to complain and also does not help.
<geser> and the root shell you run "cups -F" from doesn't have a core limit set? (just to be sure)
<tkamppeter> geser, I had set "ulimit -c 9999999" there, too.
<geser> why not set it to "unlimited" in your root shell? but I guess that's not the reason why you don't get a core file
<tkamppeter> geser, thanks. Tried it now and did not work, too. Seems to be a kernel bug generally preventing to generate core files.
<geser> might one of our security features prevent it too?
<tkamppeter> geser, seems that I have to switch back to apport and create a bug report on code which was never uploaded, only to extract a core ...
<geser> urgs
<tkamppeter> geser, or is there a possibility to extract the core from /var/crash/_usr_sbin_cupsd.0.crash without sending it to Launchpad?
<geser> "apport-unpack: Unpack a report into single files (one per attribute). This is most useful for extracting the core dump." (from https://wiki.ubuntu.com/Apport)
<tkamppeter> geser, that's it. Got access to a core by that. Thank you very much.
<geser> np
<ahasenack> Spads: ping
<ahasenack> Spads: nm, wrong nick
<ahasenack> SpamapS: ping
<ahasenack> SpamapS: can you give me an update on the landscape-client lucid sru? I think it has been in proposed for a week now
<cyphermox> hrw: am here now.
<hrw> cyphermox: can we talk in 0.5h? meeting in progress
<cyphermox> sure, just ping me
<hrw> ok
<apw> cjwatson, what defines which modules are packaged up for the live initramfs used by casper ?
<kees> tkamppeter, geser: I didn't read full backscroll, but you can't get a core dump out of a proces that has changed uid. you can bypass this by setting /proc/sys/fs/suid_dumpable to "1", though, but it will leave a system rather exposed to local attacks.
<tkamppeter> kees, so better to use the apport-unpack method.
<kees> tkamppeter: well, apport won't see a core dump at all for processes that have made uid transitions, iirc
<kees> tkamppeter: but if you have a reproducible crash, you can temporarily set the flag, crash the service, let apport catch it, then restore the flag
<tkamppeter> kees, no chance, I do not get a core.
<kees> tkamppeter: hm, dunno
<infinity> apw: It's just a default initramfs-tools config, unless something's changed, so it will be "modules=most" in initramfs.conf.
<apw> infinity, ahh thanks, obvious
<infinity> apw: Following that codepath in update-initramfs is fairly self-evident, I assume :)
<infinity> apw: Are we missing anything specific, or was the question purely educational?
<apw> infinity, yeah we may be missing a new module, will go and look at it, thanks
<mdeslaur> so, because of the accidental sync, swig2.0 in universe now has a swig package that supersedes the swig1.3 swig package in main, causing some main packages to FTBFS
 * mdeslaur isn't sure how to fix it
<Laney> 1.3 was removed from Debian. Follow suit?
<mdeslaur> Laney: there are 115 reverse build depends on swig
<mdeslaur> I don't know if they need to be fixed or not
<Laney> there is a gotcha here https://bugs.launchpad.net/ubuntu/+source/swig1.3/+bug/682613/comments/5
<ubottu> Ubuntu bug 682613 in swig1.3 (Ubuntu) "Transition to swig2.0?" [Wishlist,Expired]
<SpamapS> ahasenack: yes! I will go ahead and release it today
<mdeslaur> Laney: ouch :(
<Laney> mdeslaur: indeed, but Debian apparently made the switch anyway â¦
<mdeslaur> Laney: I guess switching is the less painful solution
<Laney> you could revert
<apw> when something builds for i386, that includes the any packages as well right?  or more specifically, we always do the equivalent of dpkg-buildpackage -b on i386 and -B on everything else ... right ?
<mdeslaur> Laney: how? bump swig1.3's version to 2.0.really.1.3 or something?
<Laney> mdeslaur: it's 2.0 that's the problem, right?
<mdeslaur> Laney: yeah
<Laney> oh, hm, but the swig binary will have to increase in version
<SpamapS> ahasenack: landscape-client should show up in -updates soon
<Laney> mdeslaur: maybe do test rebuilds and decide from there
<SpamapS> I maintain one of those packages that is broken regarding swigh 1.3 vs 2.0 autoconf check..
<SpamapS> swig even
<Laney> how did Debian go ahead if it's that badly broken?
<SpamapS> Its not swig that is badly broken, but the old autoconf rules
<SpamapS> and because they have about 1.5 years left till release. :)
<Laney> exposed by changing the version though?
<Laney> the release team usually still cares about such things :-)
<maco> 2.0~really1.3 is how im used to seeing it be done
<SpamapS> Its a transition really..
<Laney> +really.., but you can't do that here
<maco> oops
<Laney> swig1.3 needs to reclaim the swig binary package, and versions can't go backwards
<SpamapS> The fix is fairly small.. I did it for gearman-interface already..
 * maco is not thinking about sort rules today
<maco> oh the number is in the name?
<Laney> both versions were coexisting for some time, with 'swig' providing the default
<Laney> that got switched in this accidental sync and broke stuff
<Laney> SpamapS: you think the transition is doable?
<SpamapS> I don't know the scope of it
<SpamapS> For my one package, it was a small patch
<mdeslaur> Laney: so, we remove the swig package from swig2.0, and rename swig1.3-1.3.40 to swig1.3-2.0+really1.3.40
<mdeslaur> well, 2.0.4+really1.3.40
<SpamapS> -  AC_PROG_SWIG(1.3.31)
<SpamapS> +  AX_PKG_SWIG(1.3.31)
<Laney> mdeslaur: right, revert swig2.0 to what it was before and bump swig1.3 to something >> the current version of swig2.0
<SpamapS> And build-depend on autoconf-archive
<SpamapS> or drop the new ax_pkg_swig.m4 in m4
<Laney> it sounds like this would break most of the swig-using packages; I don't think we can do this unless someone volunteers to lead it
<mdeslaur> Laney: you mean the transition? if we don't revert?
<SpamapS> Its tough to even find them because they don't end up Depending on swig .. its a build-dep only.
<Laney> yeah
<Laney> SpamapS: we can determine that easily enough
<mdeslaur> SpamapS: the "reverse-build-depends" script figures that out nicely
<SpamapS> I knew it existed, but never went looking for it. :)
<mdeslaur> SpamapS: it's in ubuntu-dev-tools now
<SpamapS> OUCH.. 107
<Laney> but like I said, I don't know how many of those are actually busted
<SpamapS> Could we possibly do a mass rebuild *now* ... note the ones that fail, then do the reverting?
<Laney> that would be ideal
<mdeslaur> heck, maybe we'll get lucky and they've all been fixed already in debian :P
<SpamapS> I know mine isn't, because I've been waiting for a sponsor. ;)
<SpamapS> an lazy
<SpamapS> and
<Laney> do you have one lined up?
<ahasenack> SpamapS: thanks! (re: landscape-client)
<apw> u
<czajkowski> hey just sent a message to -devel if it could be moderated I'd appreciate it, thanks.
<apw> infinity, you'll likley know this, does i386 build -B instead of -b when there are no Arch: all packages ?
<mdeslaur> Laney, SpamapS: so, who can do the test builds, and the fix, etc.?
<Laney> not me I'm afraid
<Laney> (building machine is down temporarily)
<micahg> mdeslaur, Laney, SpamapS I would suggest dropping the swig package from 2.0 and doing the version bump on 1.3, that way packages can transition if they're ready, but might want to ask the release team as suggested to be sure
<Laney> I'd just like the data
<Laney> but in the absence of that to revert
<mdeslaur> ok, I'll do it on monday if nobody gets around to it before then
<mdeslaur> slangasek: ^ any thoughts/objections?
<slangasek> mdeslaur: lacking context :)  -vv?
<slangasek> ah, fake upstream version bump on swig 1.3 to restore compatibility?
<mdeslaur> slangasek: because of the unfortunate merge, swig2.0 in universe now owns the swig package, instead of swig1.3
<slangasek> and we don't want to just carry on and fix up the regressions this introduced?
<mdeslaur> slangasek: well, that's the question...there are 115 reverse build deps...more info in bug 862613
<ubottu> Error: Launchpad bug 862613 could not be found
<mdeslaur> bug 682613
<ubottu> Launchpad bug 682613 in swig1.3 (Ubuntu) "Transition to swig2.0?" [Wishlist,Expired] https://launchpad.net/bugs/682613
 * slangasek nods
<infinity> apw: The buildds have no way of knowing in advance if there will or won't be arch:all packages, i386 always builds with -b, and other arches always with -B
<micahg> infinity: don't you mean the reverse?
<infinity> mdeslaur: The transition would (in theory) be preferrable, but yeah, only if we think it's something we can commit to doing in time.
<slangasek> mdeslaur: do we necessarily need to get swig1.3 out of the archive at the same time as fixing up the things that depend on swig?
<slangasek> or can this be a soft transition across releases?
<infinity> micahg: No.
<micahg> infinity: sorry, you're right :)
<mdeslaur> well, I don't really want to ship oneiric with 60 packages that FTBFS because of swig
<mdeslaur> I'm the security guy, remember ;)
<Laney> slangasek: it's because the 'swig' binary package (which provides the default) moved from 1.3 to 2.0
<Laney> this is what most packages BD on
<slangasek> mdeslaur: right, I was suggesting we fix up those with coordination w/ Debian; but if it's that many, yeah, probably better to revert
<Laney> so you can't really soft transition it
<slangasek> mdeslaur: also, swig2.0 is not migrating to testing in Debian because of two new RC bugs - so it's not considered releasable there
<mdeslaur> either someone takes it, and does test rebuilds and fixes them, or I revert it
<slangasek> so +1 for the mock-up version
<mdeslaur> ok, cool. thanks slangasek, Laney, infinity, micahg
<Laney> one of the rcbugs is this configure problem
<Laney> (I think)
<ryanakca> Is there an equivalent to http://snapshot.debian.org/ for Ubuntu? I'm looking for easy access to at least all binary package names of all Ubuntu releases across time, and preferably the contents of said packages across time.
<Laney> no, but that would be cool
<slangasek> ryanakca: not really; we let the launchpad librarian keep track of all that for us, but while there's a per-package history index, there's nothing that gives you a time-based index AFAIK
<infinity> Yeah, even using lplib, you'd be stuck walking source package publishing histories, I imagine.
<ryanakca> Laney: Well, I'm willing to dump the database I'll have somewhere if you'd like it.
<ryanakca> slangasek, infinity: Thanks.
<ryanakca> On a side note, should I ask in #launchpad before fetching all of this data?
<infinity> If you can DoS one of our appservers with a single lplib client, we'd be curious to know about it, I imagine.
<ryanakca> infinity: Alright ;)
<bdmurray> stgraber: is bug 819624 fixed now?
<ubottu> Launchpad bug 819624 in casper (Ubuntu Oneiric) "casper doesn't configure autologin for lightdm properly" [High,Confirmed] https://launchpad.net/bugs/819624
<Daviey> skaet: just to confirm, I am happy with the current server and cloud images for A3.
<skaet> Daviey,  thanks!
<stgraber> bdmurray: I think this particular one is. xubuntu still won't have working autologin but that's another lightdm bug (lightdm hardcodes "ubuntu" as the session, so won't start xfce)
<bdmurray> slangasek: does bug 816117 seem sru'able to lucid to you?
<ubottu> Launchpad bug 816117 in ifupdown (Ubuntu) "Files installed by ifupdown in /etc/init should be conffiles" [Medium,Triaged] https://launchpad.net/bugs/816117
<slangasek> bdmurray: yes, though I think the SRU itself will clobber any local changes the user has made in lucid, so it probably should only be SRUed if there's some other change needed to the package in lucid
<slangasek> bdmurray: I'm also surprised that he needed to edit this particular script to get his ppp working; would be best if he could file another bug report explaining why
<Keybuk> jhunt_: I'm starting the countdown
<jhunt_> Keybuk: ?
<Keybuk> you've posted the notes to upstart-devel
<Keybuk> Lennart reads upstart-devel
<jhunt_> :)
<Keybuk> so I'm going to time how long it takes him to reply
<Keybuk> in his usual style, of course
<davmor2> Keybuk: and 3.......2.........1............RANT!
<davmor2> Keybuk: you sure it's not an auto-reply?
<juliank> Keybuk: Everyone knows that systemd is better, so why are still working on it, just switch over, damnit! ?:)
<Keybuk> juliank: I imagine he'll throw something like "oh, now you're going to use cgroups; why not just use systemd?" certainly
<Keybuk> I'm not sure he'll be able to find anything in jhunt_'s mail that constitutes "a personal attack", but I'd still put money on him making that accusation in his reply
<Keybuk> perhaps instead saying things like "after all the personal attacks from the Upstart community"
<Keybuk> and I look forward to finding out what new obscure English word he's learned this week that he'll use repeatedly in his reply ;-)
<juliank> "after all the personal attacks from the Upstart community, they are now copying MY ideas,"
<Keybuk> that's not really Lennart's style
 * jhunt_ goes to polish and oil his panoply...
<tkamppeter> Can someone help me with building a package? I have problems on the linking step.
<tkamppeter> It is argyll from this PPA: https://launchpad.net/~pmjdebruijn/+archive/ppa
<tkamppeter> It builds on Natty but not on Oneiric.
<tkamppeter> I need it to build on Oneiric to include it as part of the new Color Management support.
<tkamppeter> Problem is probably the new Gold linker. all needed libraries are specified with "-l..." on the command line but the linking fails.\
<ryanakca> Is there a list of source packages that have been removed from the archive?
<ahasenack> hi guys, when does one use "+" in the version/release of a package? I'm trying to understand that
<ahasenack> I kind of understand that something called 1.1~1234 could mean "revision 1234, working towards releasing version 1.1"
<ahasenack> so that when 1.1 is finally released, it will upgrade any 1.1~revno
<ahasenack> is there a similar use case for "+"?
<ahasenack> something like "1.1+1234" which could mean "revision 1234 of the 1.1 stable branch"?
<ahasenack> since 1.1+1234 is higher than 1.1?
<slangasek> ahasenack: yes, 1.1+1234 sorts higher than 1.1 and lower than 1.1.1, so is generally suitable
<micahg> ahasenack: yeah, generally, pre-release vs post-release snapshots
<ahasenack> hmmmmm
<ahasenack> micahg: good terminology
<slangasek> (however, 1.1+1234 sorts higher than 1.1a, so care must be taken to not trip over upstream versioning conventions)
<ahasenack> I was looking at how a packaging branch revision could be added to a debian version/release in a package
<ahasenack> the recipes have this example: deb-version 1.0+{revno}-0ubuntu0+{revno:packaging}
<ahasenack> I just hit a problem because I was only using the code revision, not the packaging revision, and the packaging branch changed and the upload failed then
<slangasek> 0ubuntu0+{revno:packaging} would not be typical IME, but I don't see anything against it offhand
<ahasenack> slangasek: would you have another suggestion about how to use both revision numbers in the versioning?
<ahasenack> slangasek: considering I have one branch for the code and another branch for the debian/* parts
<slangasek> if this isn't the authoritative branch for packaging for this work, using 0+{revno:packaging} could be ambiguous and confusing
<slangasek> but other conventions give only incremental improvement in that regard
<ahasenack> ok, I would need to put my stamp in there somewhere, like ~ppa is used for ppa builds
<ScottK> Even if it is the authoritative branch, bzr revision numbers can change.
<slangasek> right, ~ppa<serial> is more typical
<ahasenack> or ~landscape in my case, I have seen some use that convention too
 * slangasek nods
<ahasenack> but in the recipe example, the packaging revision is added to the package release number, not version
<ahasenack> is there any preference regarding that?
<ahasenack> or, what about just concatenating both in the version? Like 1.0+{revno}+{revno:packaging}-0ubuntu0?
<slangasek> that implies a new upstream tarball for every packaging change
<ahasenack> ah, good point
<ahasenack> I knew there was a reason :)
<slangasek> 1.0+{revno}-0ubuntu0+<something> would be preferred
<slangasek> or 1.0+{revno}-0ubuntu1~<something>
 * Daviey write a ppa-version-o-matic in go. </jest>
<ahasenack> so, hmm
<ahasenack> 1.0+{revno}-0ubuntu0+{revno:packaging}~landscape1, so I have both revnos in there (and daily builds work), and the ~landscape identifier/stamp
<ahasenack> and the recipe will still add ~<ubuntu-release>1 to all that
<slangasek> ahasenack: it does strike me as odd to encode the bzr revno of the packaging branch in the version number, especially considering debian/changelog is conventionally maintained in the VCS so there's a bit of a circular dependency there - are you autogenerating debian/changelog?
<ahasenack> slangasek: no, the idea is to have daily builds and when we cook up a release, then populate debian/changelog with real data
<slangasek> ok
<slangasek> IMHO an auto-incrementing serial is more practical for this than encoding the packaging revno
<ahasenack> slangasek: a timestamp, then. Recipes don't have autoincrement serials
<slangasek> oh, so these recipes are for how to construct a version that doesn't itself get committed to debian/changelog on the packaging branch
<slangasek> so in that sense you are autogenerating :)
<slangasek> that's perfectly ok then
<ahasenack> slangasek: hmm, true
<ahasenack> slangasek: I mean launchpad recipes, if that wasn't clear
<slangasek> I'm afraid I know nothing about how launchpad recipes work
<ahasenack> slangasek: np, it's the versioning that always confuses me, there are several policies about that. It's one thing to read the dpkg version comparison rules, but another to see how they are being used in real life
<ahasenack> or should I say, best practices, not policies
<slangasek> yeah :)
<ahasenack> is there a doc about these best practices? Or just the policy manual? For example, the ~ppa suffix
<slangasek> I don't know of any documentation anywhere about ~ppa versioning conventions
<ahasenack> ok
<slangasek> it might exist, but I haven't read it
<ahasenack> I'll keep going, thanks a lot for your help
<slangasek> sure thing :)
<maxb> It seems to me that the ~ppa versioning convention is usually used incorrectly
<maxb> The problem seems to be that people who don't really understand dpkg versions have seized on it as the only possible way, even to the extent of using ~ as a default separator. Which it really isn't
<ahasenack> the idea was to make sure the ppa version was lower than the released one, thinking that the PPA can only be used for backports
<maxb> Ah, good
<ahasenack> is that what you mean?
<maxb> Someone has apparently redrafted https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage to remove the ~ppa sillyness
<ahasenack> ah, cool!
<ahasenack> it mentions "+" :)
<ahasenack> I will give it my full attention
<ahasenack> maxb: thanks for that
 * ahasenack -> away
<maxb> Ultimately, though, there's no substitute for just thinking about the actual version comparisons yourself, rather than following recipes
* ScottK changed the topic of #ubuntu-devel to: Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> a package in main cam suggest a package not in main?
<micahg> hallyn: yes
<hallyn> thanks
<TheMuso> oio/c
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<TheMuso> The joys of creating an account on a bugzilla instance for a project where I need to forward 1 bug to usptream.
<micahg> TheMuso: if you get a chance, could you please look at bug 820773
<ubottu> Launchpad bug 820773 in glew1.5 (Ubuntu) "glew1.5 shouldn't provide unversioned dev packages" [Medium,Confirmed] https://launchpad.net/bugs/820773
<TheMuso> micahg: Will make it the next thing on my list.
<micahg> TheMuso: great, thanks
<TheMuso> Actually, I'll do it now. I need to wait for an email for the above referred to bugzilla account.
<micahg> k, I just was hoping it could be done before the weekend to unblock libglew transitions and FTBFS (depwait)
<TheMuso> micahg: Sure.
<TheMuso> micahg: Uploaded.
<micahg> TheMuso: thanks, hopefully this time something won't break :)
<SpamapS> hrm.. looks like something has changed to make collectd FTBFS.. last time it built was Mar 31
<SpamapS> it can't seem to link to libperl
<micahg> SpamapS: new version of perl?
<SpamapS> probably
<micahg> SpamapS: it was missed in the perl5.12 transition: http://people.canonical.com/~ubuntu-archive/transitions/perl.html
<SpamapS> hmm
<SpamapS> micahg: it actually doesn't end up depending on libperl.. which is .. confusing
 * SpamapS wonders if it statically links perl
<SpamapS> 	libperl.so.5.10 => not found
<SpamapS> Interesting..
<SpamapS> the "perl" plugin does in fact link to libperl
<RAOF> SpamapS: We obviously do something special with translation-pack SRUs.  What is it?  I'd rather like to get the natty-proposed unapproved queue down below 800 :)
 * TheMuso prods mercurial to work faster... I should have asked for more verbose output when cloning...
<SpamapS> RAOF: no idea, I've never seen that either.. been meaning to ask pitti
<RAOF> A perfectly timed holiday for pitti!
<SpamapS> RAOF: I did rummage through them and find a few that weren't langpacks. :)
<micahg> SpamapS: it deps on libperl5.10
<RAOF> Yeah. :)
<SpamapS> micahg: collectd-core does not
<SpamapS> micahg: which is where the .so that depends on libperl lives
<micahg> right, but collectd does and should've shown up on the transition page
<SpamapS> FTBFS on Debian too
<SpamapS> hrm
<Keybuk> wow
<Keybuk> since when you can strace -p 1 ?
<broder> you...can?
<broder> whoa
<infinity> Not that it's usually very exciting to watch.
<lifeless> Keybuk: meep!
<Keybuk> it means you can go gdb -p 1 too
#ubuntu-devel 2011-08-05
<slangasek> twitch
<slangasek> or more importantly, apport :P
<SpamapS> hmm...
<Keybuk> Completed x11-drivers/xf86-input-cmt-0.0.1-r20 (in 0m3.9s)
<Keybuk> argh, ww
 * RAOF wonders what -input-cmt applies to.
<TheMuso> Y ay for broken java deps.
<TheMuso> What do other pilots do if they cannot build a package, fixing the build is non-trivial?
<TheMuso> package, and fixing the build is non-trivial even.
<TheMuso> I'm looking at visualvm
<RAOF> I think it depends.
<TheMuso> Well it seems that visualvm is tangled up in lots of java bits, and some or all of that appears to be broken dep wise atm.
<RAOF> I know some sponsors will just go âeh, it doesn't work, say so on the bug and move onâ.
<TheMuso> Right, I am just working out whether this is fixable... May be.
<TheMuso> Wow netbeans is huge.
<lifeless> TheMuso: massive
<TheMuso> ...or not. Netbeans FTBFS for another reason, which I wouldn't have a clue on fixing.
* NCommander changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<maum> hello
<maum> can i use touch screen on ubuntu?
<lifeless> yes
<maum> lifeless, how can I use touch device on ubuntu 11.04? there is no driver for ubuntu.
<lifeless> for user suppoer please see the #ubuntu channel. thanks
<maum> lifeless, ok
<micahg> slangasek: or StevenK, are you either of you around and available to copy something?
<slangasek> micahg: hit me
<micahg> slangasek: chromium browser from ubuntu-security-proposed to -proposed for lucid-natty
<slangasek> micahg: 13.0.782.107~r94237-0ubuntu0.10.04.1 -- is that the right version?
<micahg> slangasek: yes
<slangasek> micahg: done
<micahg> slangasek: thanks!
<slangasek> n/p
<micahg> slangasek: no, I wanted them to go to proposed :(
<micahg> slangasek: ?
<slangasek> eh shoot
<micahg> slangasek: can you fix or will that break it?
<micahg> by break it I mean prevent from publishing later
<slangasek> I don't know
<slangasek> I can at least try to remove it now, and we can bug LP folks later to manually fix it up for us?
<micahg> slangasek: k
<maum> I cannot see speaker icon from tray
<micahg> maum: support is in #ubuntu
<maum> ok
<slangasek> micahg: ok, published to proposed, deleted from lucid-security; I don't know if add+delete in a single run will let the previous version stay in place or if it's going to result in it being pulled from -security entirely, but that at least buys us a little time
<micahg> slangasek: ok, was just lucid published to -security?
<slangasek> micahg: hmm yes, because I had misread 'lucid-natty' as 'lucid-POCKET'
<slangasek> so I didn't get a chance to screw up the other two yet
<slangasek> let's do that now ;)
<micahg> slangasek: heh, ok :)
 * micahg gets to testing lucid just in case
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<micahg> slangasek: thanks, I'll find someone later if there's a problem copying to -security
<merlot> hello my ubuntu friends, I have developed a commandline c++ program that fixes a compatibility problem with microsoft mice and X windows. Where should I post this to get included in the ubuntu distribution? Secondly, how should I go about having this run on startup, through /etc/init.d?
<merlot> are the mailing lists or forums the best method for such a discussion?
<RAOF> merlot: What does this program do?  From your description it sounds like it's working around a bug which would better be fixed elsewhere?
<merlot> RAOF: I'm not sure where it fits in. I have developed a linux kernel patch as well, but I'm not sure if it belongs there. There's a couple of Microsoft mice that after being booted into windows, and then rebooted into linux, display a very bad scrolling problem. They scroll 3 or 4 times the amount they should. By using libusb-1.0.8 and wireshark, I was able to find the right codes to send to the mouse to turn off a feature in
<merlot>  the mice that cause this problem.
<RAOF> Right.  That should be a kernel patch.
<RAOF> That indicates that the kernel isn't setting the device up properly; the proper fix would be to make the kernel set the device up properly :)
<RAOF> That said, workaround programs can sometimes have their place.
<RAOF> But in this case it sounds (to my not-particularly-kernel-developer self) like it should be a fairly simple, and perfectly acceptable, kernel patch.
<merlot> I'll ask on the linux kernel mailing list. Thanks for your advice.
<merlot> you'll have to excuse me as I wrote this a few months ago and have not had time to post the code anyway. The only mouse I know that it works with is my own model, so I was thinking that it would be better to test this in userland first
<merlot> I'll submit the userland libusb code as well.
<RAOF> That would be helpful even if your specific patch doesn't get applied.
<RAOF> merlot: Have you filed a bug about this, by the way?  That's the best way to ensure that the problem doesn't get forgotten about in the fast-paced world of IRC.
<RAOF> Also, the Ubuntu kernel team can help guide you through the process of getting your patch into the kernel.
<merlot> there is a bug posted somewhere related to ubuntu or gnome, can't remember which let me dig it back up
<maum> https://answers.launchpad.net/ubuntu/+question/167005
<merlot> ROAF, I found it here: https://answers.launchpad.net/ubuntu/+source/xorg/+question/9200
<didrocks> good morning
<merlot> mornin' didrocks
<didrocks> hey merlot
<hrw> cyphermox: sorry for not appearing later yesterday. got hooked to other meetings
<jml> does Dpkg::Shlibs have browsable documentation somewhere?
<jml> google is being unhelpful
<RAOF> jml: I've always just dived into the source :/
<jml> RAOF: I guess I can do that.
<jml> ... and overcome my snobbishness against perl
<jml> RAOF: also, "always"? I'm kind of surprised that you've needed to.
<RAOF> In my experience debhelper perl seems to be reasonably same.
<infinity> That would be dpkg-dev, not debhelper.
<infinity> Or, should be...
<RAOF> Well, yeah.  But same project, so obviously dpkg-dev perl will be sane, too :)
<RAOF> jml: I wanted to stop people uploading broken mono packages, so I made dh_clideps fail the build in that case.
<infinity> It saddens me that I had to double-check that the world hadn't just gone topsy turvy.
<infinity> RAOF: Same project how? :P
<RAOF> infinity: Both uploaded to Debian!  That means they're by the same company, right? :)
 * infinity blinks.
<infinity> If my head explodes all over Terminal 3, it's your fault.
<ajmitch> such logic is astounding
<RAOF> I reserve the right to make no sense on a Friday evening.
<RAOF> And, in fact, at any other time of my, or my body's, chosing!
<infinity> Fair enough.
 * infinity finds the omission of a manpage for Dpkg::Shlibs a bit odd, now that he looks.
<infinity> Almost every other module has one.
<jml> actually, Dpkg::Shlibs::SymbolFile was what I really wanted.
<jml> that probably has no man page on account of having no documentation in the code either.
<tkamppeter> I want to merge two source packages into one, as they come from the same upstream tarball: argyll and libicc2.
<tkamppeter> The resulting binary packages will stay the same: libicc, libicc-dev, argyll, and argyll-dbg.
<tkamppeter> Problem is that the upstream tarball version is 1.3.3, but libicc is 2.12. How do I do the merge then so that updates work.
<geser> tkamppeter: the new libicc version is also 1.3.3? or does libicc still have its own upstream version?
<tkamppeter> geser, I do not know wehre the 2.12 comes from, probably it is the API version (libicc.so.2.12), which is wrong. A package must have the upstream version and as both come from the same tarball, the upstream version is 1.3.3.
<tkamppeter> Yes, the 2.12 is the API vewrsion. The lib file is /usr/lib/libicc.so.2.12.0.
<geser> but that would only affect the package naming (I'm not that firm in library packaging)
<geser> but if upstream uses now a different versioning scheme and you need to go backwards add an epoch
<tkamppeter> geser, what is the best to do here, especially important also is that Debian will want to merge it back.
<tkamppeter> geser, Upstreame has probably never advanced to 2.12 with their version number for Argyll. The 2.12 is the API version and in package naming it usually only reflected by saying "libicc2" instead of "libicc".
<geser> yes, I guess using libicc2 would be a good idea (perhaps even libicc2-12; but better ask someone with more knowledge in library packaging about this) and add an epoch for the version
<geser> it would be also a good idea to coordinate this merging with the Debian maintainer to lessen the pain when merging Debian->Ubuntu
<ScottK> bdmurray: Rather than me get in a reversion war, would you please look at Bug #745836 and see if you think listing "Use Gnumeric instead" as a workaround for the bug is a good idea.
<ubottu> Launchpad bug 745836 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in cppu::throwException()" [Medium,Confirmed] https://launchpad.net/bugs/745836
<mvo> brendand: hello! I believe your update-manager branch about the battery-msg is no longer needed, could you mark it as obsoleted please? the gtk3 port fixes it for good :)
<brendand> mvo - sure
<ahasenack> SpamapS: hi, any news on the landscape-client sru?
<ryanakca> Is there a list of source packages that have been removed from the archive?
<Laney> ryanakca: using the LP API, yes
<Laney> don't know if there is another way
<ryanakca> Laney: Would those be all the sources with the "Deleted" status?
<Laney> seems so
<Laney> you might want to restrict the pocket and/or distro_series, depending on what you want
<Laney> (all the souce_package_publishing_history records, that is)
<ryanakca> Thanks
<hallyn> i keep finding UDD trees out of date.  So I fetch the pkg from archive, bzr import-dsc, then push.  Is that wrong?
<micahg> hallyn: probably better to get the importer fixed, it'll probably fail again next time
<hallyn> micahg: http://package-import.ubuntu.com/status/qemu-kvm.html#2011-05-16%2017:12:45.463425    If I read that right, it's complaining about changes to debian/qemu-kvm.1.  If that's the case, then manually pushing it should solve that right?
<hallyn> i.e., next time it shouldn't fail again?
<micahg> hallyn: probably, but you still might want to check to see that they have a bug for that situation if it's indeed a bug
<hallyn> micahg: thanks, i'll file a bug
<SpamapS> ahasenack: landscape-client was released to lucid-updates yesterday
<ahasenack> SpamapS: thanks! I didn't see the LP email flood that normally happens, so I was wondering
<SpamapS> ahasenack: landscape-client | 11.07.1.1-0ubuntu0.10.04.0 | lucid-updates | source, amd64, i386
<ahasenack> SpamapS: \o/
<micahg> SpamapS: how can you do that?  doesn't that produce regressions on upgrade? (maverick, natty not in -proposed)
<SpamapS> micahg: we do lucid only SRU's all the time.
<SpamapS> micahg: certainly not the best way to go about things
<micahg> yes, but aren't those usually for stuff only found in Lucid?
<micahg> after maverick EOL it's certainly fine, but I would think while there's an upgrade path, regression-release issues should be minimized where possible
<SpamapS> As I said, certainly not the best way to go about things, but actually they'll just keep the lucid version on upgrade.
<SpamapS> I believe 11.07 is also supposed to arrive in -proposed soon enough.
<micahg> right which can potentially break other things or itself depending on what the package is
<mdeslaur> slangasek: mind if I merge libpng? (you TIL)
<SpamapS> ahasenack: you guys do plan to push 11.07 into maverick and natty, right?
<ahasenack> SpamapS: right, once those remaining tests are completed, hopefully sometime next week
<SpamapS> ahasenack: what additional tests? landscape-client is not in natty/maverick proposed
<ahasenack> SpamapS: right, I will only ok it once the pre-upload tests are done
<SpamapS> ah ok
<ahasenack> SpamapS: we test it throughly before allowing it to be uploaded to -proposed
<ahasenack> thoroughly
<ahasenack> SpamapS: the test matrix url is in the bug, if you are curious
<SpamapS> ahasenack: to be clear, I think I may have actually flubbed up a bit by letting it into lucid-updates before it was available for all other releases.. as michag points out.. it will cause issues for people on upgrade. So maybe next time upload them all at once, or work backward, from natty -> lucid
<ahasenack> SpamapS: hmm, really? What issues?
<ahasenack> SpamapS: like lucid people upgrading to maverick, you mean? The package won't be upgraded?
<SpamapS> ahasenack: right
<ahasenack> SpamapS: ok, I hand't thought of that, I'll speed up the testing
<hrw> cyphermox: may we talk today?
<cyphermox> hrw:  certainly
<hrw> cyphermox: cool
<hrw> cyphermox: so how can I help with this nm-applet bug?
<cyphermox> which?
<hrw> bug 819700
<ubottu> Launchpad bug 819700 in network-manager-applet (Ubuntu) "NM applet does not lists networks" [Undecided,New] https://launchpad.net/bugs/819700
<SpamapS> ahasenack: ty
<cyphermox> hrw: libappindicator fallbacks appear to be broken in that they don't properly update the menu when that gets called by nm-applet; might be an issue with the dbusmenu about-to-show signal
<cyphermox> hrw: essentially this need to be debugged at the libappindicator level I think
<hrw> cyphermox: any hints on that?
<hrw> cause now I feel that only unitypanel has working appindicator
<cyphermox> well, I'll need to dig into the fallback code, it's clearly marked as that
<cyphermox> hrw: no, xubuntu has it working too
<hrw> cyphermox: thats xubuntu/oneiric
<hrw> cyphermox: under natty it was working, broke on oneiric
<cyphermox> it depends whether whatever panel in use has indicator widgets thingy
<cyphermox> yeah
<cyphermox> I changed nm-applet so that it would update the menu when you click the icon rather than only when e.g. a new ap is discovered
<hrw> cyphermox: xfce4 indicator-plugin for panel just says 'No indicators'
<hrw> and I have nm and bt running iconless
<cyphermox> something ought to be broken there, because on my newly installed system it works and displays nm-applet and bluetooth and all
<hrw> (xfce4-indicator-plugin:5128): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget'
<hrw> (xfce4-indicator-plugin:5128): Gtk-CRITICAL **: IA__gtk_widget_set_name: assertion `GTK_IS_WIDGET (widget)' failed
<hrw> (xfce4-indicator-plugin:5128): libxfce4panel-CRITICAL **: IA__xfce_panel_plugin_add_action_widget: assertion `GTK_IS_WIDGET (widget)' failed
<hrw> http://pastebin.com/Gp9F7TQM is what I got when started nm-applet
<micahg> cyphermox: on oneiric?
<SpamapS> Hmm.. when writing an apport hook.. how can I get access to what will eventually be the bugs title?
<nigelb> bdmurray would know
<SpamapS> actually I think I found a better way which will just add the info all the time as its useful in other contexts.. :)
<SpamapS> bdmurray: whats the best way to test an apport package hook?
<SpamapS> bdmurray: break the postinst and dpkg-reconfigure the package?
<nigelb> SpamapS: wait, why?
<nigelb> SpamapS: testing is easy.
<SpamapS> I want to test its handling of postinst failures
<nigelb> oh. that. :)
<nigelb> probably :)
<cyphermox> micahg: yes, I'm on oneiric
<SpamapS> lamont: were you aware that Postfix FTBFS in oneiric?
<SpamapS> http://tech.groups.yahoo.com/group/postfix-users/message/278015
<micahg> cyphermox: is this a live CD?
<cyphermox> micahg: no?
<cyphermox> micahg: I can try things on a live cd though
<cyphermox> got xubuntu desktop amd64 already retrieved
<micahg> cyphermox: weird, the network manager applet works fine for me on oneiric
<cyphermox> micahg: yes
<cyphermox> micahg: the problem is for those who don't have the indicator widget thing for xfce or for other wms
<micahg> cyphermox: indicator widget?
<micahg> oh, I should be asking hrw :)
<cyphermox> well, whatever thing that will allow indicators to be added to a panel in the specific WM being using
<micahg> well, we have an indicator plugin that allows us to use the indicators with the xfce4-panel
<cyphermox> yes
<cyphermox> but I think one of the two available xubuntu sessions will use the old systray instead no?
<cyphermox> (and there may be other things at play here, like people actually removing some of these bits for whatever reason)
<charlie-tca> no
<charlie-tca> one of the two will be a cross between the xfce and xubuntu sessions, with most of the stuff in the panels missing
<cyphermox> in any case, nm-applet should work properly for those who can't use indicators; the fallback is clearly broken in many ways, including displaying icons for any such indicators, not just nm-applet
<cyphermox> charlie-tca: ok, thanks for the clarification
<micahg> well, the xfce4-indicator-plugin is removable as it's a recommends of xubuntu-desktop
<cyphermox> charlie-tca: but in one of those wouldn't you see stuff in the panel showing broken icons?
<charlie-tca> and it takes 12 steps listed in the alpha3 technical overview to get the right session if you pick the wrong one. too
<cyphermox> fun
<charlie-tca> yes, but I can't tell if it is because it is missing, or because it picked things xfce session should not have
<cyphermox> bah, all the icons should be there for nm-applet and bluetooth. they usually don't change
<cyphermox> if it's not showing for just those two it's definitely an issue in libappindicators, as those are the two major "applets" using that library
<charlie-tca> It is the things like indicators not working/missing, 4 of eight launchers missing, 4 workspaces instead of two, network manager applet doesn't show the connections
<cyphermox> charlie-tca: yes
<charlie-tca> which is a mixed session, it is not xfce or xubuntu
<cyphermox> ok
<charlie-tca> but if it helps... just delete the ~/.config and pick the other session to login
<cyphermox> anyway, nm-applet not showing the connections is a side effect of (xfce4-indicator-plugin missing || something broken in libappindicator)
<ScottK> SpamapS: lamont is on vacation this week.  The patch you pointed to in the bug is the one we want, so please feel free to fix it.
<jono> hi folks
<jono> is it me, or are there a stack of system settings missing?
<jono> things like the screensaver config tool
<jono> fonts
<jono> managing how often the screen dims etc
<kirkland> mvo: what would you think of adding a flag to apt-add-repository that triggers an immediate apt-get update after a successful PPA add?
<kirkland> mvo: it just seems I *always* end up apt-add-repository ppa:foo/ppa && apt-get update
<kirkland> jono: they've kinda moved around a little, i think
<jono> kirkland, that's what I thought, but big pieces are missing
<jono> for example, I can't find the screensaver and screen dimming options
<cyphermox> jono: screensaver: indeed, you can't choose your screensaver, only the settings for when to lock, etc; that's also where you set dimming
<jono> cyphermox, wow, that seems like quite a regression
<cyphermox> under the power menu thing, clikc System Settings, and under Personal you should have something called "screen"
<cyphermox> jono: reimplementing screensavers was discussed for oneiric but we haven't had time afaik
<kirkland> jono: alt-f2, and then "system settings"
<kirkland> jono: that's the best I can find, but you're right, there are config settings I can't find any more
<jono> cyphermox, so this was just dropped from the GNOME3 Control Center re-write?
<cyphermox> jono: sadly, yes
<jono> wow
<jono> thanks for the clarification
<kirkland> jono: i want to disable suspend when i close my laptop lid (I friggin hate that setting)
<cyphermox> as far as fonts go, afaict the only way is to install gnome-tweak-tool
<jono> I am amazed GNOME3 shipped like this
<jono> seems like a lot of things are missing
<cyphermox> (and gnome-tweak-tool... urkk)
<ScottK> cyphermox: Switching to KDE is another option. ;-)
<jono> :-)
<cyphermox> ScottK: indeed ;)
<cyphermox> ScottK: how's the NM plasmoid ;D
<ScottK> cyphermox: Seems to be working.
<ScottK> I only had a spare computer to run Oneiric with starting this week, but it's worked fine so far.
<cyphermox> ok
<cyphermox> I wonder if it's still far out of date from the NM api, if it is, there is still time to fix that
<ScottK> cyphermox: There's a NM09 branch that we are using.
<cyphermox> ScottK: ah, that's what I was wondering
<cyphermox> perhaps it's time I give kubuntu a honest shot again
 * charlie-tca thinks about Linus saying Xfce
 * charlie-tca knows there is a Xubuntu with Xfce, too
<Laney> a lot of that gnome 3 stuff is supposed to be coming back
<slangasek> mdeslaur: not at all
<mvo> kirkland: good idea
<kirkland> mvo: thanks!
<kirkland> mvo: you want a bug or do you want to JFDI?  :-)
<vmlinuz> anyone familiar with networkmanager-vpnc build ?
<vmlinuz> on Natty, pkg-config reports NetworkManager is 0.8.3.998
<vmlinuz> if you try to build network-manager-vpnc directly from svn, it fails to recognize NetworkManager and its libs
<vmlinuz> Requested 'NetworkManager >= 0.8.998' but version of NetworkManager is 0.8.3.998
<mvo> kirkland: a small reminder maybe on monday or a bugreport please, otherwise I will have forgotten it over the weekend, I know myself
<kirkland> mvo: bug report it is
<mvo> thanks!
 * mvo calls it a day
<vmlinuz> /usr/lib/pkgconfig/NetworkManager.pc has "Version: 0.8.3.998"
<vmlinuz> but networkmanager package is version 0.8.4~git.20110319t175609.d14809b-0ubuntu3
<vmlinuz> I'd say the bug is on the "network-manager-dev" package, right?
<dupondje> http://reports.qa.ubuntu.com/reports/sponsoring/
<dupondje> something broke ? :P
<SpamapS> ScottK: thanks. So the patch should just be in the tree right, no patchsys ?
<ScottK> Yep.  lamont puts everything in a full git tree.
#ubuntu-devel 2011-08-06
<slangasek> StevenK: dexter's packages have all been orphaned, which means yada-dropping QA uploads are now in order; do you want to do the honors on libnss-db, or shall I?
<infinity> slangasek: !!
<infinity> slangasek: Pick me!
<infinity> slangasek: If you're not planning on adopting it, I will.
<slangasek> infinity: oh, go right ahead, I'm not adopting it :)
<infinity> I very nearly hijacked it from him years ago.
<infinity> So, may as well just do it.
#ubuntu-devel 2011-08-07
<StevenK> slangasek: Ooooh! Allow me!
<infinity> StevenK: I've already ITAed it.
<StevenK> Awww
<infinity> StevenK: You're welcome to upload all his OTHER yada-ish packages. :P
<StevenK> Have they been purged of the taint yet?
<infinity> Dunno.
<infinity> Haven't looked.  nss-db was the only one I ever cared about.
<ScottK> siretart: I'm trying to rebuild performous for the boost transition, but I seem to have a libav problem: http://paste.debian.net/125421/ suggestions?
<infinity> ScottK: Missing an include, perhaps?
<micahg> ScottK: the constant name changed
<micahg> ScottK: BTW, regarding your e-mail, there's a tracker already set up for boost1.46 showing ~45 packages to go, only 2 direct dependencies
<ScottK> micahg: Thanks.  I'd forgotten about the tracker.  You don't happen to know what it changed to do you?
<ajmitch> you mean http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html ?
<ajmitch> a few of those 45 look to have built on all but armel
<ScottK> That's the one.
<ScottK> ajmitch: At least some of those are no longer buildable on armel because we just have GLES on armel, not full GL.
<RAOF> What?  We've got a full GL stack on armel.  It just won't be hardware accelerated.
<ScottK> Sorry.
<ScottK> In Qt.
<RAOF> Ah.  Makes more sense.
#ubuntu-devel 2012-07-30
<sgnb> is there an equivalent of snapshot.debian.org for Ubuntu?
<infinity> Nope.
<micahg> sgnb: no, but almost all binaries should be available on launchpad on the source package's page
<infinity> micahg: Well, to a point.  We reserve the right to reap old cruft that no longer has ties to any active publishing record.
<infinity> (But yes, most of it's still available)
<micahg> right, hence, almost :)
<infinity> One could probably do nasty DB/API walks to construct snapshots.
<infinity> I wouldn't recommend it.
<sgnb> ok
<infinity> sgnb: If you're looking for old versions of a package, micahg's pointing you in the right direction.  lp.net/ubuntu/+source/<package> will link to all the previous versions, which in turn link to all the binary builds, etc.
<infinity> sgnb: But snapshots of the archive, date-based (which is snapshot.debian.net's way cooler feature that no one uses) aren't something we provide.
<micahg> well, add a /+changelog on the end of that
<infinity> Actually, +publishinghistory
<micahg> well, either would work
<micahg> the later is probably less likely to time out
<infinity> Sure, but one of them's readable. ;)
<sgnb> infinity: well, I do use it (date-based snapshots), when I don't know in which package is the bug I'm investigating... fortunately, it's not the case this time
<infinity> sgnb: Yeah.  Like I said, it would be conceivably possible to do date-based reconstruction from LP, but not trivial.  Would be neat if someone with stupid amounts of disk space decided to do it as a third-party service.
<infinity> Actually, if they were happy with only ever providing the things we didn't purge from the librarian, they wouldn't need disk space at all, just to write an intelligent proxy/redirect shim that reconstructed history and aimed people at the right librarian entries.
<infinity> But if they want to keep history that we might/will purge, yeah, disk space.
<hrw> hello
<pitti> Good morning
<tumbleweed> infinity: I seem to remember broder doing some date-based snapshots (backed on LP)
<xclaesse> is there known Quantal bug that prevent laptop from going back from sleep?
<seb128> xclaesse, what kernel version do you use?
<xclaesse> 3.5.0-5-generic
<seb128> xclaesse, yes, it's fixed in -6
<xclaesse> seb128, awesome, thx :)
<seb128> yw!
<xclaesse> The following packages have been kept back:
<xclaesse>   cups-filters gedit gedit-common libimobiledevice-dev libnet-dns-perl
<xclaesse>   libsignon-glib-dev libsignon-glib1 linux-headers-generic linux-image-generic
<xclaesse>   signond signond-dev
<xclaesse> so it doesn't wan't to upgrade to -6 yet
<seb128> xclaesse, yeah, not sure why, you can apt-get install it manually, lot of people did it, seems to work fine
<xclaesse> k, thx
<xclaesse> seb128, btw I think gedit-plugins needs an update as well
<xclaesse> otherwise upgrading gedit will remove the plugins
<seb128> xclaesse, it does, in fact the packaging forces both to me in the same serie and there is no gedit-plugins 3.5 tarball yet, I need to check if 3.4 works with gedit 3.5 and relax the depends if it does
<xclaesse> ok
<tjaalton> did chkconfig get removed from quantal?
<tjaalton> ..without checking reverse deps
<tjaalton> ScottK: ^
<ScottK> tjaalton: It's possible I screwed up.  Suggestion on how to proceed?
<tjaalton> ScottK: i fix freeipa-client to not need chkconfig ;)
<ScottK> tjaalton: Thanks.
<tjaalton> guess that's the way to go anyway
<tjaalton> doesn't matter if it's broken on quantal for now
<ScottK> tjaalton: Any chance you could look at system-config-audit as well?
<ScottK> That seems to be the other one.
<brendand> does anyone know if there is a way with Qt to find out about the palette used by the current theme?
<tjaalton> ScottK: I might
<ScottK> tjaalton: If it turns out you can't, please let me know.
<brendand> i notice that gnome-control-center changes the color of the top button area when the theme changes. i want to do something similar
<tjaalton> ScottK: sure thing, I'll take a look at it later
<ScottK> Thanks.
<pitti> apw: hey Andy, how are you?
<pitti> apw: I noticed your kmod PPA, nice! how is that working?
<pitti> seb128: ^ FYI
<seb128> pitti, danke (talking to didrocks so I didn't get to ask on IRC)
<apw> pitti, it was working pretty well for me, i am intending on revisiting it this afternoon, as we should switch sooner rather than later.  the only thing we really holding us back was the lack of map suppoer which i have found nothing using
<pitti> apw: yeah, the text based maps are fairly obsolete
<ev> mpt: out of a small sample of 50 reports (it takes 20 minutes to run this code for that size), only 3 had the most recent version of the package and its dependencies installed at the time of the report
<apw> pitti, the other wrinkle is that if we switch versioning for module-init-tools makes backing out hard
<pitti> apw: that'd be great, then we can update udev as well
<pitti> apw: at worst we can epoch it?
<mpt> ev, wow
<apw> pitti, so its my priority to sort out the testing and recommendation today i hope
<ev> mpt: I'll do a bigger sample later, when the launchpad team isn't looking. But yeah, we have work to do :)
<pitti> apw: at some point we'll need to switch anyway, and there won't be many new versions for this any more, so an epoch shouldn't hurt too much
<pitti> apw: splendid
<apw> pitti, that takes the pressure off.  my testing so far is all positive, i'll get some more done and check its up to date with debian again
<pitti> apw: many thanks
<seb128> pitti, apw: great, thanks!
<brendand> seb128 - is the fixed accountservice package for this bug in -proposed yet? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1021293
<ubottu> Launchpad bug 1021293 in ubiquity (Ubuntu Precise) "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress]
<seb128> brendand, yes, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=account
<infinity> brendand: It's in the queue, I'll be reviewing it today.
<infinity> Although...
<infinity> seb128: Can you reupload it with -v0.6.15-2ubuntu9.1  ?
<infinity> seb128: So we get reference to the bug from the previous proposed upload too?
<infinity> Or...
<infinity> seb128: Or, I guess I can just promote 9.2 before I accept 9.3
<seb128> infinity, sure, I was thinking the new one would go in when the old one moves over to updates
<infinity> seb128: Yeah, I hadn't realised it was close to being "of age" and all properly verified and stuff.
<infinity> seb128: Since it is, I can just promote it today.
<seb128> infinity, it's not "of age", it's 4 days old
<infinity> seb128: Yes, I said close.
<seb128> ok your call
<seb128> I can reupload if you prefer
<infinity> seb128: The 9.2 upload is tiny, easily-audited, "obviously sane", and has been verified.
<infinity> seb128: Making it wait 3 more days would be pointless beaurocracy with no value.
<jamespage> mterry, do you have a moment to discuss bug 1017972 and what I'm proposing with the libunwind test suite?
<ubottu> Launchpad bug 1017972 in libunwind (Ubuntu) "[MIR] google-perftools, libunwind" [Medium,Incomplete] https://launchpad.net/bugs/1017972
<mterry> jamespage, hello sure
<jamespage> mterry, great!
<infinity> mterry: Oh hey, you're around.  I had a minor nit to pick with you. ;)
<mterry> infinity, :)  /me hides
<jamespage> mterry, OK; so I've been digging around upstream with regards to the libunwind test suite
<infinity> mterry: I don't even remember what package it was now, but if you fix an RC bug in Ubuntu and the Debian maintainer is "QA", please find a DD to just do a QA upload of the thing instead.
<mterry> jamespage, so libunwind's upstream seems silly, to have known test failures, but not skip those tests on those arches...  ;-/
<jamespage> mterry, yes - I agree - it does seem a little insane
<infinity> mterry: (Which I did for some FTBFS fix you did last week, and then synced over your fix)
<mterry> infinity, you mean rather than going the normal route of filing a bug?  you're saying just to save paperwork?
<infinity> mterry: No point filing an RC bug if anyone is allowed to upload the package (which is the definition of "maintained by QA"), so just upload.
<mterry> jamespage, so google-perftools is all sorted right?
<infinity> mterry: Or, in your case, since you're not a DD, ask someone else to. :)
<mterry> jamespage, and the plan for libunwind is to enable just amd64?
<infinity> mterry: But, sure, if you can't find someone to upload, file a bug.
<infinity> mterry: Just that "upload to Debian, sync, and never worry about the delta" is much nicer from your POV.
<mterry> infinity, filing a bug is my way of finding a DD.  :)
<jamespage> mterry - google-perftools is pending a fix of bug 1028038; at which point I can enable the test suite and its all good...
<ubottu> Launchpad bug 1028038 in eglibc (Ubuntu Precise) "sscanf always calls realloc/causes deadlock in google-perftools" [High,Triaged] https://launchpad.net/bugs/1028038
<mterry> (and, I thought, the normal way)
<jamespage> mterry, for libunwind; enabling the amd64 test suite only - with one fix, two workarounds and 2 test disabled...
<infinity> mterry: You work with a ton of DDs.  Just sayin'. ;)
<infinity> jamespage: That fix should be happening RSN.
<mterry> jamespage, well, given the craziness of upstream tests, one arch is better than none.  hopefully it can act as a sometimes-canary-in-the-coalmine
<jamespage> infinity, thats great - thanks
<mterry> jamespage, is upstream amenable to making it so that the suite skips known-failures?
<mterry> that way we could just enable the whole thing and not worry
<mterry> jamespage, (for the future, not as a blocker here)
<jamespage> mterry, I think they would be - developers appear to be a bit arch-centric upstream
<jamespage> the x86_64 guy has been pretty responsive; I note that alot of the ARM work has been done by folk at linaro
<jamespage> so I think having something in the Makefile structure that allows know issues to be ignored would probably be well received
<jamespage> mterry, I'll come up with something and proposed upstream...
<mterry> jamespage, ok cool.  But regardless, plan seems fine for MIR
<jamespage> mterry, great - thx for the feedback
<mterry> jamespage, thanks for your awesome work on this!
<jamespage> mterry, its been fun - I've not done much low level c/c++ for at least a decade
<jamespage> (had to dredge up some really old knowledge that I had forgotten)
<janimo> slangasek, thanks for the cdv reviews, I'll shortly upload a new version
<jderose> mhall119: who did you think i should pester about this? https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
<ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
<mhall119> seb128: ^^ can you look at jderose's couchdb sync request?
<jderose> mhall119: thanks :)
<seb128> mhall119, sorry, out of day, I'm at GUADEC, I will have a look tomorrow
<smoser> jodh, around?
<slangasek> janimo: sounds good :)
<janimo> slangasek, what do you think of starting with a clean changelog - a single entry - since it will be the first publically available release? I am not sure what the best practices are when moving a package from PPA or NEW to Ubuntu and when the history is not really important
<slangasek> janimo: I think condensing to a single changelog entry is generally preferred
<janimo> slangasek, great, will do that then. We'll also probably go with uploading the latest minor code drop from Intel that occured while these were in NEW
<janimo> slangasek, also -0ubuntu1 feels odd given it is unlikely these will go to debian in this form but I hear it is recommended to use ubuntu versions nonetheless
<slangasek> that would be my recommendation still, yes
<jbicha> any core dev want to sponsor ubuntu-docs upload for Precise & Quantal? bug 1019441
<ubottu> Launchpad bug 1019441 in Ubuntu Translations "Please update the ubuntu-docs Precise package with translations for 12.04.1" [High,Triaged] https://launchpad.net/bugs/1019441
<bdmurray> mterry: would you mind looking at bug 1029764?
<ubottu> Launchpad bug 1029764 in update-manager (Ubuntu) "update-manager seems to have an unnecessary recommends on gir1.2-unity-5.0" [Low,Triaged] https://launchpad.net/bugs/1029764
<mterry> bdmurray, sure
<highvoltage> tumbleweed: congratulations!
<jodh> smoser: howdi
<smoser> jodh, thanks for responding, but i've figured out the problem wasn't what i was going to bother you with
<smoser> :)
<micahg> hrm, sponsorship queue isn't refreshing
<micahg> bdmurray: ^^ do you still have access to fix this?
<bdmurray> micahg: I don't know actually
<bdmurray> micahg: it doesn't look like it
<tumbleweed> highvoltage: thanks
<jderose> for an SRU, do i propose for merging into precise or precise-updates (in my case, libav have a new package in precise-updates already)?
<slangasek> jderose: precise-updates; but because of this ambiguity, I consider best practice to skip UDD for SRUs and just send debdiffs to bug reports
<jderose> slangasek: okay, thanks. and in the changelog entry, should the distro be precise or precise-updates?
<slangasek> precise-proposed
<slangasek> :)
<jderose> ah, okay :)
<jderose> slangasek: much thanks! I'm still pretty green when it comes to this workflow, so I appreciate the help :)
<slangasek> no problem
<slangasek> jderose: btw, were you following any documentation about this?  I have an action item to clean up the recommendations around SRU workflow
<jderose> well, the thing i really needed the most help with is quilt, so i was reading this - https://wiki.ubuntu.com/PackagingGuide/PatchSystems
<jderose> i was trying to do things UDD just because i like the idea of it :P
<cnd> I'm trying to compile a program that links against libxml and it fails to link with the error: /usr/lib/x86_64-linux-gnu/libxml2.so: undefined reference to `gzopen64@ZLIB_1.2.3.3'
<cnd> I think the issue is that the gzopen64 symbol doesn't actually have the ZLIB_1.2.3.3 version on it
<cnd> I don't see a version when I use readelf -a
<cnd> I can't imagine I'm the first or only person to have seen this, so I'm not sure what I'm doing wrong
<jderose> slangasek: would you mind glancing at this debdiff, see if i did things correctly? https://bugs.launchpad.net/ubuntu/+source/libav/+bug/937561
<ubottu> Launchpad bug 937561 in libav (Ubuntu) "H264 MOV files from Canon DSLR resolution reported as 1920x1088" [Medium,In progress]
<jderose> debdiff - https://launchpadlibrarian.net/111492829/libav_0.8.3-0ubuntu0.12.04.1_to_libav_0.8.3-0ubuntu0.12.04.2.debdiff
<slangasek> sure
<cnd> nm
<cnd> I didn't actually have zlib1g-dev install
<slangasek> cnd: you shouldn't need it
<cnd> slangasek: then I'm not sure why it was failing
<slangasek> I'm not either :)
<slangasek> but libxml2.so.2 is linked against libz.so.1, which gives ld all the information it should need to traverse the lib deps and find the symbol
<Laney> IIRC some versions of zlib were busted
<Laney> did installing the -dev upgrade the shared lib too?
<cnd> Laney: oh right
<cnd> yes, it was upgraded
<slangasek> cnd: hmm, what was the previous version?
<cnd> Preparing to replace zlib1g:amd64 1:1.2.3.4.dfsg-3ubuntu4 (using .../zlib1g_1%3a1.2.7.dfsg-13_amd64.deb)
<slangasek> that implies that the shlibs / symbols for zlib1g are wrong
<slangasek> the symbols file has:
<slangasek>  gzopen64@ZLIB_1.2.3.3 1:1.2.3.3
<slangasek> (on amd64)
<slangasek> so if that's incorrect, it should really get fixed
<cnd> that's not what the lib had before I upgraded
<cnd> let me check again
<cnd> slangasek: yeah, it now has the symver on it
<cnd> so the old package I had was borked
<slangasek> well, and the old package is the one from precise
<slangasek> so it's fairly important that we get the versioned dependencies right here :)
<cnd> heh
<slangasek> though in point of fact I think the missing symbol *version* is non-fatal at runtime
<cnd> slangasek: I'm not *too* familiar
<cnd> but I would guess that if it looks for a symbol with a specific version at compile time
<cnd> then it is probably hard coded to look for that symbol
<cnd> right?
<cnd> otherwise it would only have a dependency on the symbol without the version
<slangasek> not sure I understand your question
<slangasek> note that in this case, your application is *NOT* using gzopen64; the linker is merely doing sanity-checking on the recursive dependencies of the libraries
<slangasek> and it seems to be doing it differently than ld.so itself would
<cnd> yeah, that may be
<cnd> I was thinking that: why would libxml2 depend specifically on symbol@version rather than just symbol unless it really was hard coded to use that specific symbol?
<slangasek> because that's how versioned symbols work
<cnd> ok
<slangasek> when libxml2 was built, the version of the gzopen64 symbol it linked against was ZLIB_1.2.3.3
<slangasek> so the linker encoded that information
<lifeless> memoisation FTW.
<cnd> that's not how I expected it to work, I guess
<slangasek> however, at *runtime*, ld.so will fall back on an unversioned symbol if it can't find one with version ZLIB_1.2.3.3
<slangasek> no, that's exactly how it's supposed to work
<slangasek> there appear to be two bugs
<slangasek> one is ld not knowing to fall back to the unversioned symbol
<slangasek> the other is zlib1g having the wrong versioned dependency for its versioned symbol
<slangasek> jderose: it looks like this bug is not yet fixed in quantal, which is a prerequisite for an SRU.  Could you please prepare a debdiff for that as well and I'll sponsor it in?  (The actual debdiff looks spot-on)
<jderose> slangasek: yeah, i was just working on it for quantal also... so should i attach the quantal debdiff to the same bug?
<slangasek> jderose: yes; or you can use UDD for quantal if you prefer, that's much more straightforward
<jderose> okay, i'll try that then... thanks! :)
<slangasek> i.e., UDD for quantal is more straightforward than UDD for SRU - but it's entirely your call if you prefer to use UDD or a debdiff
<jderose> gotcha
<stgraber> slangasek: we were discussing bug 1031065 with smoser over in #ubuntu-server. You might be interested by that one as it seems to be a race hitting the new overlay cloud instances pretty much systematically (haven't managed to get one booting without the bug yet...)
<ubottu> Launchpad bug 1031065 in resolvconf (Ubuntu) "/sbin/resolvconf -a depends on /run/resolvconf/interface but it may not exist" [Undecided,New] https://launchpad.net/bugs/1031065
<soren> mdz: Sorry about not replying to your e-mail. Yes, I'd be happy to chair the next meeting. I wonder, though, why it's scheduled for today? The meetings are usually fortnightly. Is there anything out of the ordinary about today?
<slangasek> stgraber, smoser: hrmm.  backing up a bit, what is causing resolvconf to be called for interfaces before udev is started?
<slangasek> stgraber, smoser: because /etc/init/resolvconf.conf is 'start on mounted MOUNTPOINT=/run', which is strictly earlier than 'start on virtual-filesystems' (udev)
<smoser> slangasek, we believe it is being run by network-interface
<stgraber> though network-interface depends on an event from upstart-udev-bridge and so depends on "starting udev"
<slangasek> smoser: yeah, that can't happen
<slangasek> smoser: not unless something else is playing silly buggers with udev
<smoser> slangasek, no silly burgers in that regarund that i'm aware of.
<smoser> here is mountall --debug output from overlay: http://paste.ubuntu.com/1120170/ , normal: /tmp/mountall-debug-normal.txt
<slangasek> smoser: I see nothing out of the ordinary there
<stgraber> slangasek: so far what I managed to confirm is that at the time the dhclient hook is called, /run/resolvconf doesn't exist yet, that the interface is brought up through network-interface.conf (I disabled networking.conf) and that the race seems to hit at every boot
<stgraber> (if it's indeed a race)
<smoser> slangasek, what is it that would guarantee network-interface.conf to not run until /run is mounted?
<slangasek> I don't suppose the udev from the initramfs is somehow still running?
<slangasek> smoser: see comment on the bug
<smoser> slangasek, i can check that.
<stgraber> smoser: looks like I managed to break that EC2 instance quite badly ;) mind killing it and giving me a fresh one? :)
<smoser> stgraber, i might hvae killed you.
<smoser> new one coming.
<smoser> stgraber, ubuntu@ec2-184-72-155-176.compute-1.amazonaws.com
<smoser> its brand new fresh.
<smoser> you'll have to install overlayroot
<smoser> and change /etc/overlayroot.conf to have 'overlayroot="tmpfs"'
<smoser> then reboot
<smoser> slangasek, to determine if "udev from initramfs is somehow still running", i can just look at pid numbers, right?
<slangasek> smoser: that should do; or else 'lsof'
<smoser> what would lsof show me?
<slangasek> smoser: if the exe of the process matches the one on the filesystem
<stgraber> slangasek, smoser: looks like my initial try was wrong, networking.conf is what's bringing eth0 online and there's no udev running at that point
<slangasek> stgraber: hmm!
<slangasek> is local-filesystems being emitted before virtual-filesystems?
<stgraber> slangasek: http://paste.ubuntu.com/1120257/
<smoser> http://paste.ubuntu.com/1120258/
<smoser> it would appear udev not still running.
<stgraber> that's the result of "ps faux" placed at the beginning of the dhclient hook
<jderose> slangasek: this okay? https://code.launchpad.net/~jderose/ubuntu/quantal/libav/fix-937561-q/+merge/117341
<slangasek> the local filesystems are certainly all mounted before the virtual mounts get done
<smoser> note, slangasek all i did was 'ps -w > /dev/.initramfs/ps-w.txt' in the initramfs and the show pids.
<slangasek> I thought mountall was supposed to not emit local-filesystems until after virtual-filesystems, though
<smoser> the man page states that explicitly, slangasek
<smoser> (man local-filesystems)
<slangasek> jderose: looks perfect
<jderose> cool, i'll learn this stuff yet :P
<slangasek> smoser: right, that must be where I got the idea ;)
<smoser> i have to run
<stgraber> [    6.714904] virtual
<stgraber> [    6.753640] local
<stgraber> so assuming my test worked, local is indeed properly emitted after virtual
<stgraber> (the above is the result of two upstart jobs, one starting on local-filesystems, the other on virtual-filesystems, each printing local or virtual to /dev/kmsg)
<slangasek> stgraber: well, virtual-filesystems and local-filesystems are signals, so there's no guaranteed ordering of the jobs that start on each ;)
<slangasek> but there *is* guaranteed ordering of jobs starting on mounted /run
 * stgraber adds a similar check for resolvconf and networking and reboots
<stgraber> [    4.598897] networking
<stgraber> [    5.016864] init: cloud-init-nonet main process (241) killed by TERM signal
<stgraber> [    5.632677] resolvconf
<stgraber> [    5.955406] virtual
<stgraber> [    5.989643] local
<stgraber> ubuntu@ip-10-202-249-151:~$ grep -r 'start networking' /etc/init/
<stgraber> /etc/init/cloud-init-nonet.conf:   start networking >/dev/null
<stgraber> smoser: ^
<stgraber> "start on mounted MOUNTPOINT=/ and stopped cloud-init-local" with clout-init-local being "start on mounted MOUNTPOINT=/"
<stgraber> so basically as soon as / is mounted, "start networking" is directly triggered by cloud-init-nonet bypassing the start condition
<slangasek> jderose: as an aside, if you add debian/changelog and your source changes at the same time, you can use 'debcommit' to get everything committed to bzr with a commit message based on debian/changelog - and with automatic bug references added to the bzr branch
<jderose> slangasek: ah, okay. but my changelog wasn't wrong, was it? I just didn't do it the best way?
<slangasek> jderose: changelog is fine, just offering a hint of a shortcut for UDD
<jderose> slangasek: i don't seem to have the 'debcommit' command (on precise)... what package provides this plugin?
<slangasek> jderose: it's a standalone command, not a bzr plugin - part of devscripts
<jderose> ah, okay... i was trynig to `bzr debcommit` :P
<slangasek> I guess it would make sense for 'bzr commit' to do the same thing under the covers if bzr-builddeb is installed... dunno if it does something like that currently
<jderose> i have builddeb installed, commit didn't seem to do anything special
<slangasek> jderose: btw, I see that Debian also has libav 0.8.3 now; I don't suppose you would be interested in merging Debian's changes into quantal?
<jderose> slangasek: sure... so i'd just start with the debian package from bzr, and then add my patch?
<slangasek> jderose: well, you would start with lp:ubuntu/libav and do a 'bzr merge lp:debian/libav' and fix it up from there
<jderose> okay, so there are ubuntu-specific changes that i need to preserve?
<slangasek> I don't know if there are or aren't ;)
<jderose> gotcha, guess i'll find out :)
<slangasek> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: slangasek
<jderose> slangasek: so merge in from debian creates some fairly crazy conflicts that i'm having a hard time understanding what to do with just yet
<jderose> slangasek: but the channel topic makes me thing you might be the person i should pester about this also - https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1022515
<jderose> :)
<ubottu> Launchpad bug 1022515 in couchdb (Ubuntu) "Please sync (sort of) couchdb 1.2.0-1 from Debian unstable" [Undecided,Confirmed]
 * slangasek grins
<slangasek> jderose: having a look at the couchdb bug; in the meantime, could you please update the description on bug #937561 to comply with https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ?
<ubottu> Launchpad bug 937561 in libav (Ubuntu Precise) "H264 MOV files from Canon DSLR resolution reported as 1920x1088" [Medium,In progress] https://launchpad.net/bugs/937561
<jderose> sure
<slangasek> smoser: so why *was* cloud-init-nonet calling 'start networking' directly?
<shbk2> hello , guys! maybe someone know what can be a reason of this http://stackoverflow.com/questions/11730181/linux-module-compilng-missed-folder-asm
 * ogra_ wonders if anyone has ever seen a kernel lock up hard once you add break=bottom to the cmdline 
<slangasek> ogra_: I've seen a system wind up with no usable console, which is kinda the same thing?
<ogra_> right, we had no proper console until very late in the initrd ... thats why i wanted to see it booting with the break statement to actually look at the initrd
<ogra_> it seems ot keep the grub gfx screen up until very late in the boot
<slangasek> right, you've probably managed to boot in a scenario that has no console in the initramfs ;)
<ogra_> and the whole thing takes up to 90sec to boot from a 90MB/s disk
<ogra_> though jibel said he has seen 3 minute boots as well on that HW
<slangasek> try setting GRUB_GFXPAYLOAD_LINUX=text ?
<ogra_> will do so tomorrow, we finished already but i plan to invest an hour into inspecting that
<slangasek> keeping the grub screen up until the drm driver takes over is by design... and it generally works except when you want to debug things happening before the drm drivers get loaded
<ogra_> that HW makes me curious ... many of my arm devices are faster
<ogra_> but looking at the specs of the components there is really no reason to be slow
<infinity> If it's taking 90s, it's probably breaking on a wait-for-root.
<infinity> And getting stuck in the "we'll just sit here for 60s twiddling our thumbs" trap.
<ogra_> wait-for-root actually only seems to take 1-2 sec in the bootchart
<infinity> My firewall does that.
<ogra_> there was a 30sec ureadahead ... so we removed ureadahead completely for a test ...
<infinity> Or is that wait-for-network?  I dunno.  Wait-for-something.
<ogra_> which didnt change anything (didnt get slower either though)
<infinity> In my case, it's because I have a driver that throws udev into an infinite loop. :P
<ogra_> yeah, my SIS based FW does that too
<ogra_> booting takes over 5min on that HW
<ogra_> but i usually dont reboot it and if it runs its fine ... its a firewall after all
<ogra_> but 90sec or more on a modern macbook pro is just laughable
<ogra_> this sprint will actually make me blog again ... so many funny things ...
<slangasek> jderose: so I'm still looking at the couchdb merge; it's a non-trivial update which is taking me a while to verify
<slangasek> jderose: your branch also doesn't appear to include an actual merge of the Debian packaging, which means I won't be using that branch directly so as not to lose the UDD branch history here
<jderose> slangasek: yeah, i know... thanks
<jderose> slangasek: so the UDD history from Ubuntu is kinda nonsense as the ubuntu package was carrying like 20k lines in debian/patches
<jderose> slangasek: and that ubuntu package is a dead end road that isn't being maintained by any canonical folks now... so in my opinion, having a low, easy to understand delta with the debian package is the important thing
<jderose> i'm trying to talk the debian maintainer into accepting this split so ubuntu can start syncing from debian, carry no ubuntu specific changes... but that hasn't happen yet
<slangasek> jderose: I agree that we want to reduce the delta; I just am not going to create a UDD branch history that doesn't reflect this being am erge :)
<jderose> slangasek: gotcha... so how should i do that? or, is there something i need to do to prepare what i have for review?
<slangasek> jderose: at this point it's a matter of me running the bzr merge here, fixing up the conflicts (in progress), and then comparing with your branch and working through any differences between the two
<jderose> slangasek: okay, thanks! sorry that i didn't do things the right way UDD-wise
<slangasek> no worries
<slangasek> jderose: so one thing I notice up to this point is the dropping of all the spidermonkey and couchio patches
<slangasek> are those merged upstream?
<jderose> yes, i believe so
<slangasek> ok cool
<slangasek> it definitely looks like most of the delta goes away just as part of a merge... it's just a bit of a manual merge to get there
<jderose> slangasek: when you're resolving big merge conflicts in UDD... how do you go about it? i'm a bit lost as to where to even start with libav :)
<slangasek> jderose: 'bzr conflicts'; pick one, look at it, figure out what the right answer is, make that change, 'bzr resolve $foo'
<slangasek> all the real complexity is in "figure out what the right answer is" ;)
<jderose> slangasek: yeah, i was hoping there was some `bzr magic-helper-gnome` command that i just didn't know about :P
<slangasek> jderose: couchio-fix-0001-replicator_redirect_atts.patch doesn't seem to be upstreamed, but otoh the source file it points at (couch_rep_httpc.erl) has disappeared.  how confident are you that dropping this isn't going to cause regressions?
<slangasek> in fact, several of these patches are in that scenario
<jderose> slangasek: very confident in that case... 1.2.0 brings a completely rewritten replicator... and that just happens to be something that i test like crazy almost daily :)
<slangasek> ok
#ubuntu-devel 2012-07-31
<jderose> slangasek: ubuntu was carrying many cherry picked patches, plus a few things that were specific to the U1 couchdb sync, AFAIK. so there was a big delta both from debian and from upstream couchdb
<slangasek> and the U1 couchdb sync is now obsolete, or implemented upstream in a different way?
<slangasek> (I know the U1 packages in Ubuntu no longer use couchdb, but I'm not sure if that makes this code entirely obsolete)
<jderose> obsolete, they turned it off
<slangasek> jderose: you've dropped debian/couchdb-bin.dirs, which creates the directory /etc/couchdb/local.d - why is this no longer needed?
<jderose> hmm
<slangasek> oh, moved to the couchdb package instead, ok
<jderose> ah, yeah
<jderose> slangasek: dpkg -L couchdb-bin - http://paste.ubuntu.com/1120544/
<slangasek> jderose: what's the reason for making /etc/couchdb owned by root instead of by couchdb?  That's certainly the usual way of doing things, but /someone/ thought it was a good idea to have it owned by couchdb in the first place, so I'd like to be sure we understand the original reasoning
<jderose> and dpgk -L couchdb - http://paste.ubuntu.com/1120546/
<slangasek> indeed, the Debian package is *still* calling 'chown -R couchdb /etc/couchdb'
<jderose> slangasek: hm, you sure about that? in one of the postinst?
<slangasek> in Debian, couchdb/postinst calls 'chown -R couchdb:couchdb /etc/couchdb'
<slangasek> couchdb 1.2.0-2
<jderose> so the /etc/couchdb/default.ini file is needed for per-user couchdb, and shouldn't be changed by the couchdb daemon
<jderose> and i didn't want to require the couchdb user to be created for the couchdb-bin package... a wanted to package it as a very clean library, so to speak
<slangasek> ok
<slangasek> I think that's a reasonable goal, but I'd rather see the Debian package fixed first to not be chowning /etc/couchdb
<slangasek> hmm, no, on second thought, let's go with it
<jderose> slangasek: so in my package, i just change the ownership on /etc/couchdb/local.ini, local.d - http://bazaar.launchpad.net/~jderose/ubuntu/quantal/couchdb/1.2.0-low-delta/view/head:/debian/couchdb.postinst
 * slangasek nods
<jderose> slangasek: much thanks... sorry... i know this was a bear to review :)
<slangasek> jderose: what tells the couchdb package to use /etc/couchdb/local.ini?
<jderose> slangasek: this is hardcoded into the /usr/bin/couchdb script, it's one of the default config files to look at
<slangasek> ok
<jderose> per user couchdb overrides this (destkopcouch does this, we do it too)
<slangasek> jderose: the previous Ubuntu package used a /var/lib/couchdb/$version directory, the new one doesn't?
<slangasek> ah no, that's also shipped in the package - ok
<jderose> root@jgd-ws:~# ls /var/lib/couchdb/
<jderose> 1.2.0
<jderose> :)
<slangasek> jderose: couchdb.postrm: /etc/couchdb/local.ini is a conffile, so you don't need to rm it
<jderose> slangasek: no even when you purge? that was in the debian package, btw, so that's why i left it in there
<jderose> *not* even when...
<slangasek> the Debian package has 'rm -rf /etc/couchdb'
<slangasek> which is different :)
<jderose> ah, gocha
<slangasek> for a conffile, dpkg takes care of the removal for you on purge
<jderose> slangasek: so you want me to remove that first then?
<jderose> okay
<slangasek> I'm fixing it up here, just letting you know
<jderose> remove the rm, that is :)
<jderose> okay
<simplew> when it will be possible to have video working in ubuntu precise? https://bugs.launchpad.net/pidgin/+bug/971867
<ubottu> Launchpad bug 971867 in pidgin (Ubuntu) "No voice call or video call possible, due to recent farsight->farstream transition" [Undecided,Confirmed]
<slangasek> jderose: sleep 3> I'm including this change for now, but the right fix is to make the init script actually synchronous... or maybe to replace it with an upstart job which is guaranteed to be synchronous by nature
<jderose> slangasek: yeah, i looked into this some, and it will require changing some pretty deep things in couchdb, from what i can tell. it's because of some issues with how erlang works
<slangasek> well, an upstart job would be fairly easy :)
<slangasek> since upstart provides real process supervision, and therefore can make sure the service has actually died before returning
<jderose> slangasek: hmm, that would be awesome... i'm upstart dumb though :)
<RAOF> It's surprisingly easy to upstartify something.
<jderose> RAOF: any good tutorials? or what are good example packages to look at?
<slangasek> in this case I suppose you'd need a 'pre-stop exec couchdb -d'... and probably some special signal handling
<RAOF> Partially because it's an actual *init system*, rather than a pile of raw shell.
<jderose> hehe :)
<RAOF> jderose: The upstart cookbook's pretty good http://upstart.ubuntu.com/cookbook/
<RAOF> But I'd just start with a random member of /etc/init/*.conf; all the ones I've looked at have been reasonably obvious what they're doing.
<jderose> okay, cool
<RAOF> It is *much* easier to write an upstart job than a sys-v init job.
<scientes> or a systemd unit for that matter ;)
<RAOF> I've not tried to write a systemd unit; is it really harder than an upstart job? I've thought they'd be of comparable difficulty.
<scientes> oh i meant systemd units are easy to write
<scientes> i've never succeeded at understanding what upstart actually does
<RAOF> It's pretty easy; you stick your start conditions into "start on", your stop conditions into "stop on" and then "exec $YOUR_DAEMON", plus possibly some options to tell upstart what to expect the daemon to do (fork, fork twice, etc).
<slangasek> jderose: have you seen this lintian warning?:
<slangasek> W: couchdb-bin: init.d-script-not-marked-as-conffile etc/init.d/couchdb-bin
<jderose> slangasek: hmm, no, i haven't... i don't think that shows up when i build on precise...
<slangasek> hmm
<slangasek> well, it's not actually in the package at all, so I wonder where it's getting that idea
<slangasek> ah, because I broke something in debian/rules
<jderose> ah, couchdb-bin.... weird
<jderose> slangasek: that's what you get for merging :P
<slangasek> nah, it was my own doing ;)
<smoser> slangasek, cloud-init start-networking ... i have ot think about that.
<smoser> it was done at SpamapS's suggestion, i know that
<slangasek> hmm
<smoser> (mainly, i certainly couldn't have made such an error)
<smoser> :)
<slangasek> SpamapS: ^^ why are you breaking everything! :)
<smoser> i believe it was to protect from a race condition
<slangasek> ironic
<jderose> slangasek: so that libav fix was just pushed to quantal-proposed so far, right? could you back this change out, cancel it for now? there is more digging i need to do
<jderose>  in working on a test case, i just discovered that this bug doesn't occur when i remove gstreamer0.10-plugins-bad... only when it's installed. so although there is an issue in libav, there is something more subtle going on from gstreamer, so i'd like to dig deeper into this before this hits quantal
<slangasek> jderose: it's been pushed to quantal, and to precise-proposed where it sits in the queue
<slangasek> do you think it's critical to back it out of quantal?
<smoser> well, slangasek a bit more info
<smoser> http://paste.ubuntu.com/1120635/
<jderose> slangasek: probably not... but there is also another part to it the mans linked to in the comments
<jderose> but i don't think it should go into precise yet, that's for sure.... there is more weirdness yet to track down :)
<jderose> but there is also another part to it *that* mans linked to in the comments
<slangasek> smoser: ok, that looks like a wrong workaround for bug #925122
<ubottu> Launchpad bug 925122 in udev (Ubuntu) "container's udevadm trigger --add affects the host" [Medium,Fix released] https://launchpad.net/bugs/925122
<slangasek> smoser: (or related bug)
<smoser> yeah, i supsected it was probably fied elsewhere.
<jocarter> jono: comments on your blog don't seem to work
<jono> jocarter, oh really?
<jono> let me check
<jono> jocarter, it looks fine to me, what is the problem?
<smoser> slangasek, thanks. stgraber thakn you for your help today too.
<jocarter> jono: all of the disqus stuff is just gone, maybe it's ad blocked or something (checking...)
<jocarter> jono: ah, it's back noe
<jono> jocarter, oh cool :-)
<jderose> slangasek: anything else you need from me on the couchdb package?
<slangasek> jderose: nope - I just needed to build it with the right options to get accepted into the archiev
<slangasek> doko_: have you seen https://code.launchpad.net/~james-page/ubuntu/quantal/icedtea-web/java7-transition/+merge/113959 ?  Should it be uploaded, or do you want to review it yourself?
<jderose> slangasek: i'll run all my unit tests against that package after it builds, let you know if i find anything. thanks again!
<slangasek> no prob - thanks for taking care of the package :)
<slangasek> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: apw
<jodh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh, apw
<bkerensa> mm
<seb128> does anyone know if there are plans to change from gnutls26 to 28 this cycle?
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh
<jodh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zul> can an archive admin please review python-django-compressor, python-django-appconf, and python-warlock it will make horizon installable again (and ill buy them a beer when I see them next)
<zul> and they have been sitting in binary-new for a while now
<jibel> stgraber, cyphermox pete updated his machine yesterday running quantal and he has lost network since then
<cyphermox> huh oh
<jibel> network-manager was in the list of packages upgraded
<cyphermox> jibel; would still need to see syslog somehow to know what's going on
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<jibel> cyphermox, ack, I'll file a bug with the logs, apparently the dnsserver is set to localhost and it doesn't work, on my machine it is set to a dns ip and it works
<cyphermox> it should always be set to 127.0.0.1; but that needs dnsmasq to start.
<jibel> cyphermox, there are 2 problems then :)
<cyphermox> no
<cyphermox> ah, I'm an idiot
<jibel> cyphermox, bug 1031350
<ubottu> Launchpad bug 1031350 in network-manager (Ubuntu) "[quantal] no network resolution after latest upgrade of network-manager" [Undecided,New] https://launchpad.net/bugs/1031350
<cyphermox> thanks
<cyphermox> jibel; how come does dnsmasq doesn't start on your system and you get the dns data in syslog? could you share your own syslog too?
<stgraber> cyphermox: wouldn't that happen if dnsmasq is simply disabled in /etc/NetworkManager/NetworkManager.conf? (just guessing)
<cyphermox> yes, that's what I want to make sure
<cyphermox> but in pete's case dnsmasq fails to start; NM should handle it gracefully and set dns in resolvconf anyway
<jibel> cyphermox, I attached my syslog
<cyphermox> jibel: exactly, your syslog shows the failover being done properly.
<cyphermox> it's for the same network... I wonder what else might be different to make one fail and not the other
<SpamapS> slangasek: what did I do? (re "breaking everything" and I think cloud-init)
<SpamapS> smoser: ^^ maybe you know?
<smoser> http://paste.ubuntu.com/1120635/
<smoser> SpamapS,  that was the fix we put in because cloud-init wasn't working inside containers (because the NIC was already up wehn init started)
<smoser> per slangasek "that looks like a wrong workaround for bug #925122"
<ubottu> Launchpad bug 925122 in udev (Ubuntu) "container's udevadm trigger --add affects the host" [Medium,Fix released] https://launchpad.net/bugs/925122
<cyphermox> jibel: fix is building right now; but for a quick fix you can see if pgraner has a file /run/resolvconf/interfaces/lo.dnsmasq; if that's there, it should be removed (and then you can click the connection in NM again to reset it)
<smoser> SpamapS, i'd have to dig some more and test, but if our fix is no longer necessary even in precise, then i'td be nice to get that update too.
<cyphermox> a reboot would fix it too.
<SpamapS> smoser: ok cool, I will standby then unless you think there's something I need to look at directly.
<smoser> nah. but I *hope* this means we can just ditch those two lines and still be happy in lxc.
<bluefoxxx> what language is dpkg primarily written in?
<cjwatson> bluefoxxx: C for the core, Perl for developer scripts
<bluefoxxx> ah.  Difficult, but not terrible.  I like C.
<jpds> bluefoxxx: https://www.ohloh.net/p/dpkg
<bluefoxxx> (I question its use for tihs particular application, but that's a daunting discussion)
<bluefoxxx> The next question:  is it more appropriate for a restricted .deb format to keep the .deb--as have various changes such as lzma2 compression etc--or to get a different format, like .sdeb?
<cjwatson> .deb already supports different compression formats
<bluefoxxx> I have been hypothesizing a deb installation mechanism by which the pre-install and post-install and the entire installation process are carried out under a non-privileged account, with sandboxing, procedurally restricting actions to (say) bash scripts (possibly with a restricted interpreter)
<cjwatson> we use different extensions for cases where the format is compatible but the policy is very substantially different
<bluefoxxx> the ideal situation is one such that you can guarantee exactly one of two things:
<cjwatson> I think for that extremely long-term project the extension is the least of your concerns ... :-)
<bluefoxxx> A)  Everything that happens during installation is known and accountable
<bluefoxxx> B)  Anything that happens during installation that could break (A) can be spotted ahead of time (just in time, even), halted, and warned about before it happens
 * cjwatson heads off to try to get home adsl working again
<jbicha> stgraber: would you be interested in sponsoring ubuntu-docs for me?
<bluefoxxx> hm
<ScottK> jbicha: dpm already hunted him down on -release.
<stgraber> jbicha: waiting for a test build to complete
<jbicha> oh cool, thanks!
<dpm> hey jbicha :)
<bluefoxxx> well my concern is that the behavioral policy of a debian package in such a situation would be SUBSTANTIALLY different
<dpm> thanks for taking care of the ubuntu-docs upload
<bluefoxxx> to the point that running a normal .deb under it may break
<bluefoxxx> (though, it may also work quite well)
<bluefoxxx> on the other hand, I want to get away from the situation where the pre-inst script is run as root and can i.e. silently modify the kernel image, setuid binaries, etc without informing the package manager of what it's up to
<bluefoxxx> mostly dpkg and rpm seem to accept that "if you install it, you assume the risk"
<bluefoxxx> which I can understand, but I'd like to not assume the position outright.
<stgraber> jbicha: https://launchpadlibrarian.net/111550998/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.6_FAILEDTOBUILD.txt.gz
<stgraber> jbicha: have fun ;)
<stgraber> (the quantal one is still running, not sure if it'll be affected too)
<jbicha> stgraber: it should build on quantal as those errors are ignored now
<stgraber> jbicha: right, quantal worked fine. I'll upload that one for now then, let me know when precise is fixed.
<dpm> jbicha, do you think you'd have time to get it to build for precise some time today? This way I could start building the language packs tomorrow, which should be ready by the 2nd Aug
<jbicha> dpm: yes, but I don't think I'll get to it for a few more hours
<dpm> jbicha, that's cool. Could you then follow-up with stgraber to sponsor the upload and with someone from the SRU team to get it to -proposed?
<jbicha> yes
<Sweetshark> doko: ping?
<dpm> excellent, thanks jbicha!
<Sweetshark> doko: it seems our (ubuntu/debian) gcc automagically makes paths relative in dependency files thus breaking nontrivial build systems (where make is called from different dirs). Is this intentional? it does not seem to happen on fedora at least ...
<xnox> Sweetshark: bug # or example?
<Sweetshark> xnox: well, a libreoffice build: the dep files generated by g++ contain a lot of paths like ../solver/... while the include paths passed to gcc are absolute.
<doko> Sweetshark, I'm not aware of any patch that would do that
<Sweetshark> xnox: I just tried to reproduce that with a minimal example, but that seemed fine. strange. I need to dig out what triggers it ...
<Sweetshark> doko: thanks.
<Sweetshark> hohum ...
 * Sweetshark has an evil suspision: ccache!
<xnox> ccache is indeed evil ;-)
<mcclurmc> i have a package which needs a different patch applied to the upstream source depending on whether the package is being built for Ubuntu or Debian
<mcclurmc> the other day, micahg recommended to me the method of having multiple series files (DEBIAN.series and UBUNTU.series)
<mcclurmc> i just pushed a source package to a ppa, but launchpad didn't apply the correct series file
<mcclurmc> is there something else I need to do to make this work?
<tumbleweed> mcclurmc: it should be series.ubuntu and series.debian IIRC
<mcclurmc> tumbleweed: does case matter?
<tumbleweed> probably
<tumbleweed> it tends to in unix
<mcclurmc> tumbleweed: ha, yes. i meant to ask, do i need upper or lower case on the vendor? this blog uses upper case: http://raphaelhertzog.com/2010/11/05/managing-distribution-specific-patches-with-a-common-source-package/
<tumbleweed> oh, no it is ubuntu.series
<mcclurmc> tumbleweed: great, thanks
<tumbleweed> I don't see upper-case there
<tumbleweed> anyway, this is covered in a comment near the bottom http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3673
<mcclurmc> hmm, where did i get the idea it was in caps? oh well, thanks for setting me straight
<infinity> TheMuso: Does anyone plan to actually maintain linux-lowlatency in precise?  It's never been rebased to keep in line with master SRUs since release.
<dobey> infinity: is there any way to just get it built from the main kernel builds? it seems to only change a couple of config options, and it would be nice to have it automatically kept in line with security fixes and such
<infinity> dobey: It adds a patch that can't reconcile with master.
<infinity> dobey: If someone changed that to a twiddlable config option, that would go a long way.
<micahg> infinity: that's done in quantal AIUI
<micahg> but it might be limited to a newer kernel
<apw> i believe we are carrying the patch still in effect, as its still separate
<apw> but the reality is its a simple job to rebase it and upload it, the hard part is making sure
<apw> it gets the testing it needs to get released.
<apw> i can show anyone on the studio team how to get their kernel up to date
<infinity> micahg: Yeah, it's still a conflicting patch in quantal.  Just easier to rebase, see Andy.
<apw> there is little point in repeatedly uploading kernles to just languish in -proposed
<micahg> apw: well, it needs to be uploaded by either the kernel team (through your special repo) or the security team (when security relevant)
<micahg> sorry, if security relevant and not going through the kernel team
<infinity> micahg: Neither of those is true.
<apw> micahg, not really we don't support it for security anyhow, so just uploading it to -proposed and it'll get there
<infinity> micahg: You or I could upload it right now.
<apw> people on non-supported things cannot expect to get -security can they ?
<micahg> infinity: yes, I know, the point is, are kernels not built against -security only when pushed there?
<micahg> apw: sure they can, they have to supply a debdiff
<micahg> IMHO, the most compelling reason to update lowlatency is for security patches
<apw> micahg, what i mean is if the security team is not supporting the package they cannot expect to add only -security pocket to their system and expect it to mean anything
<micahg> apw: why not?
<micahg> they only want security fixes, not random updates from the archive
<apw> but we arn't doing security fixes for that kernel, its not supported
<micahg> apw: right, but wouldn't they get them for free from a rebase?
<apw> yes if the kernel is updated to match the tip of our tree it would get security because our master tree has them in
<apw> but that wouldn't get them into -security
<micahg> apw: I think we could ask the ubuntustudio people to test the kernel and sign off on the update
<apw> and if they don't sign off on it who is going to do the work then
<micahg> apw: that's their problem, it's seeded for them alone, it's their responsibility
<apw> micahg, in which case they can do the rebase and upload it, or not as they see fit ?
<micahg> apw: well, if it's easy enough for the kernel team to do the initial upload, I'm sure they'd appreciate it, otherwise, yes (and in cases of security relevant updates, pass a debdiff/signed package to the security team for sponsorship)
<apw> micahg, i'll take it offline with scott and see what we can come up with
<micahg> apw: sounds good, thanks
<toabctl> jbicha, is there a reason why seahorse has still version 3.4?
<jbicha> toabctl: it's packaged, it's just waiting on bug 1030335
<ubottu> Launchpad bug 1030335 in libsecret (Ubuntu) "[MIR] libsecret" [Wishlist,Triaged] https://launchpad.net/bugs/1030335
<bdrung> BenC: i saw that you did the last uploads of ghc. do you know when 7.4.2 will hit quantal?
<toabctl> jbicha, so lp:~ubuntu-desktop/seahorse/ubuntu is no longer in use for seahorse?
<BenC> bdrung: No idea. I was told "any day" a week or two ago
<BenC> bdrung: I don't normally handle it, I was just fixing ppc
<bdrung> BenC: k, then i have to wait for Laney come back
<jbicha> toabctl: except for having a newer version we're in sync with Debian so I don't know if we'll use the desktop branch or not
<toabctl> jbicha, ok. thx
<pgraner> Rush 2112
<dobey> "missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev" <- why would this show up in lint, when python (>= 2.6.6-3) is in the Build-Depends?
<micahg> dobey: do you actually have python >= 2.6.6-3
<dobey> micahg: i would hope python 2.7 is newer than that, yes :)
<ScottK> dobey: Separate issue.
<ScottK> python and python2.7 are different packages.
<ScottK> You need python >= 2.6.6-3
<dobey> yes, and precise only has 2.7, so the python package is 2.7.3, and yes it is installed
<ScottK> Right, but you still need to specify the minimum build-dep
<dobey> eh? my question ended with "when that is listed in Build-Depends" :)
<micahg> dobey: can you pastebin the whole build depends?
<dobey>  python (>= 2.6.6-3~) | python-support (>= 0.6.4),
<tumbleweed> well, there's your problem
<micahg> hrm, no, that should be enough..
<tumbleweed> unless python-support is installed
<micahg> unless the lintian check is broke
<ScottK> Is this lintian or lintian4python?
<dobey> lint check from debuild -S
<tumbleweed> lintian should really complain about the use of alternative build-depends at all
<micahg> well, Debian ignored them, right? :)
<micahg> *ignores
<tumbleweed> AFAIK, yes
<slangasek> why should it complain?
<slangasek> they're a long-permitted technique
<dobey> well i have another package with the same build-depends that doesn't show that lint error
<tumbleweed> permitted, but not encouraged
<slangasek> I don't know what you mean by encouraged
<slangasek> it was never *dis*couraged
<dobey> well, if i didn't have a need to make it as easy as possible to build the latest version of the stuff i'm maintaining, on all supported versions of ubuntu, i'd be happy to just drop the | python-support from it. but yay, lucid.
<dobey> i guess i'll just ignore it for now
<slangasek> +1
 * micahg is glad someone reads lintian output
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Bluefoxicy> ãï¼¿ã
<Bluefoxicy> ... uh.
<Bluefoxicy> so the next version of Ubuntu is Quantum Quezacotl or sommat?
<Bluefoxicy> Then Temporal Tezcatlipoca?
<slangasek> you're thinking of Handsome Huitlacoche
#ubuntu-devel 2012-08-01
<scientes> ahh so unity-2d was also dropped caused in qt5 qtquick is moving to opengl ES 2.0
<SpamapS> dpkg: error: parsing file '/var/lib/dpkg/status' near line 26005 package 'libsdl-net1.2:i386': mixed non-coinstallable and coinstallable package instances present
<SpamapS> while dist-upgrading precise->quantal
<ScottK> Multiarch is fun.
<SpamapS> Yeah
<SpamapS> not really sure how to work around it
<SpamapS> dpkg seems basically dead in the water
<SpamapS> like, dpkg -l doesn't even work
 * SpamapS does something unholy and just removes the bad entry there
<slangasek> SpamapS: bug #1015567, I'm afraid
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [High,Triaged] https://launchpad.net/bugs/1015567
<SpamapS> slangasek: thanks, was just about to head off looking into whether or not it was a bug/known
<infinity> SpamapS: It's known, but no one's had a chance to look into a "sane" migration/fix yet.
<infinity> (I also still contend that the check is a complete joke, since it doesn't trigger in other cases that could be equally broken, so maybe just removing it would be fine)
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton
<mitya57> ScottK: hi, do you have any plans to merge our python-defaults with debian?
<mitya57> there were some important dh_python2 fixes in 2.7.3-1 and 2.7.3-2
<xnox> mpt: in quantal, in the system menu i have: "Log Out...; Suspend; Hibernate; Restart...; Switch Off..."
 * xnox manually enabled hibernate
<xnox> mpt: how come suspend/hibernate do not have '...' at the end?
<cjwatson> Don't they act immediately rather than producing a dialog?
<mpt> xnox, what cjwatson said
<xnox> cjwatson: mpt: ok.
<cjwatson> http://developer.gnome.org/hig-book/3.4/menus-design.html.en#menu-item-type-command
<mpt> "â¦" means "you're going to need to provide more input to complete the primary function of this command"
<xnox> 3.4 hig
<cjwatson> Although there is an argument from the HIG text there that Log Out and Switch Off shouldn't have â¦ either, since they only present a confirmation dialog
<cjwatson> I don't know if that wrinkle is somehow controversial
<xnox> oh... goodies. need to read it =)
<cjwatson> 3.4 was just the current link; AFAIK the ellipsisation advice has been there forever
<mpt> Yeah, we diverge from the Gnome HIG in that we make no distinction between a confirmation alert and other types of input
<mpt> (For example, the confirmation alert might have a checkbox in it like "Install updates before switching off", or might offer multiple choices like "Restart" vs. "Restart Into Windows")
<cjwatson> For reference, do we have documentation of our HIG divergences anywhere?
<mpt> I think the Gnome HIG has the "ignore confirmation alerts" guideline only because the classic Mac OS guidelines did, but even OS X doesn't
<mpt> cjwatson, no, that would be priority #2 where priority #1 is to have our own guidelines to diff between :-)
<cjwatson> Heh
<cjwatson> I know how it is
<bdrung> bdmurray: the sponsoring overview is not updated any more. do you know why?
<xnox> point of interest 3.6 libreoffice spash is weird. i liked previous one better...
<alexbligh> What is the best way to make a script run very early on (i.e. as the first thing upstart does) after remounting / read-write and before any udev/hotplug events are processed
<smoser> hm.. ok. i'm out of ideas. anyone see what is wrong here
<smoser> https://bugs.launchpad.net/ubuntu/+source/choose-mirror/+bug/1031696
<ubottu> Launchpad bug 1031696 in choose-mirror (Ubuntu) "incorrectly claims "no support for specified release"" [Undecided,New]
<smoser> alexbligh, i dont think you can accomplish that.
<smoser> udev starts on virtual-filesystems, which i do not believe depends on mounted / rw
<smoser> although when i say that it doesn'tmake much sense. sosomething must block processing of hotplug/udev events until after rw
<geser> smoser: in the second screenshot (that one from busybox) the grep isn't searching in the output from wget but in the file "Release" from the filesystem (see Release in the grep call)
<smoser> geser, well, he did both
<smoser> first one he just grepped from the file
<smoser> second he did the wget
<smoser> oh.
<smoser> no
<smoser> you're right.
<alexbligh> smoser, so if I do "start on starting udev and started virtual-filesystems" then I am going to create some form of dependency loop?
<alexbligh> udev is "start on virtual-filesystems"
<smoser> i dont know what would happen.
<alexbligh> Hmmm, in this case I can guarantee the only filesystem is the root filesystem which is initramfs and already about. mountall is just going to remount that r/w (I presume it's mountall which does the remount r/w)
<alexbligh> I don't think I can use "stopped mountall" as presumably mountall is only stopped after it has emitted all the events.
<alexbligh> (incl. the one that starts udev)
<jodh> alexbligh: lets continue this on #upstart.
<bdrung> tumbleweed: how about a u-d-t release?
<hrw> starting daemons...
<hrw> one day I will find time to learn what is ubuntu way of having daemons installed and not started on boot even after package update
<ogra_> stgraber, heh, the lightdm/gdm mail on the ltsp list is funny ... so he did all that work but still needs the same user locally ... somone should tell him that this is the actual readon for ldm to exist :)
<ogra_> *reason
<directhex> hrw, tl;dr: an entry in /etc/default/packagename along the lines of "ENABLED=0", and an init script which bails out unless ENABLED=1
<directhex> e.g. see dnsmasq
<hrw> directhex: thanks
<jodh> hrw: it's covered in a generic fashion in the Upstart Cookbook too. See http://upstart.ubuntu.com/cookbook/#pre-start and http://upstart.ubuntu.com/cookbook/#post-stop.
<stgraber> ogra_: haven't read too closely, but it sounds like he needs scotty's libpam-ssh and libnss-ssh
<ogra_> stgraber, right
<ogra_> i just find it funny how people invest a ton of work without talking to anyone before they start and then end up in the same situation all others did before them
<jocarter> ogra_: it's things like that that cause me to grind my teeth and then having the dentist telling me to stop stressing so much
<tumbleweed> bdrung: as usual, I'd like to do a pass through the bugtracker first
<ogra_> jocarter, who are *you* ?
<ogra_> *g*
<jocarter> I'm the artist previously known as highvoltage
<bdrung> tumbleweed: then go ahead. :p
<ogra_> is that a permanent change ?
<jocarter> ogra_: I think so. I tried changing away from highvoltage before but there was a lot of resistance
<jocarter> *badish*
<ogra_> lol
<jamespage> doko_, just noticed the java-common package is still installing the architecture-less symlinks for openjdk-6 -  we should probably drop those
<jamespage> (I can do that if you agree)
<xnox> jocarter: i will be calling you jo forever now.
 * xnox expects you to respond to 'jo:' pings ;-)
<NCommander> infinity: ping, do you remember what APT bugs I had to look at?
<ogra_> NCommander, just look at all of them :P
<ogra_> (and fix them indeed)
 * NCommander glares at ogra
 * xnox lines up apt bugs in alphabetical order for NCommander (while winking at ogra_)
<NCommander> xnox: [A-Z][a-z]? Or are you using an extended alphabet which has more letters :-)
<xnox> NCommander: ÐµÑÑÑ Ð¶Ðµ Ð¸ Ð´ÑÑÐ³Ð¸Ðµ Ð°Ð»ÑÐ°Ð²Ð¸ÑÑ...
<NCommander> How very cryillic of you :-)
<NCommander> *cyrillic
<xnox> ;(
<xnox> ;)
 * xnox typing fail
 * NCommander still remembers the days of fidonet and spam on DOS could be identified by blocks in Fidomail
 * NCommander suddenly feels old as hell
 * NCommander <3 ProcommPlus for DOS
 * xnox never used fidonet.....
<killown> What ubuntu team just did with the last update? it messed around with kubuntu-desktop http://bpaste.net/show/8uqye6UT9JCKGHcVgDuS/ thanks for wasting my time with this
<cjwatson> that's a bit overly aggressive
<killown> i386 devel libs is useless and I can't compile wine, other great thing I would thank for too
<cjwatson> I expect whoever made the change in question would need a significantly more complete report than that, including e.g. which Ubuntu release you're using
<xnox> killown: if I was you, I'd wait for the mirrors to catch up.
<NCommander> That looks like aptitude
<cjwatson> but cut the sarcasm, please
<cjwatson> it doesn't help anyone
<bdmurray> bdrung: the sponsoring report is a dholbach thing
<bdrung> bdmurray: he is on holiday and told me that you are able to deploy changes
<bdmurray> bdrung: I only have read access to the files there...
<shadeslayer> Daviey: ping
<bdrung> bdmurray: do you know who has access to it?
<bdmurray> bdrung: yes, dholbach
<janimo> NCommander, you're not old, you were precocious
<shadeslayer> Daviey: it seems you dropped smbfs with this merge : https://launchpad.net/ubuntu/+source/cifs-utils/2:5.4-1ubuntu1
<shadeslayer> Daviey: was it intentional? what replaces smbfs in that case
<bdrung> bdmurray: is the sponsoring script run on his private machine?
<shadeslayer> Daviey: Debian still has smbfs apparently : http://packages.debian.org/source/unstable/cifs-utils
<NCommander> janimo: somewhere, I have a box of token ring adapters, and a copy of OpenVMS for Itanium :-)
 * NCommander has had notions of wiring up a DECnet network at home
<janimo> NCommander, ok then, s/precocious/crazy/
<NCommander> :-)
<janimo> I am older than you and only know those from history books
<janimo> by which I mean IT books printed in the early 90s
<NCommander> If it weren't for the fact everything here is on VoIP, I'd stick a modem in my itanium system and wire up uucp
<NCommander> (dial-up is suprisingly useful in some of the places I go to)
<ScottK> postfix supports delivery via uucp.
<NCommander> ScottK: curious if it will handle a bangpath email
 * NCommander notes Thunderbird (used to) explode when you fed it one
<lamont> NCommander: that got turned off by default some time a go, iirc
<lamont> AS IT SHOULD
<NCommander> you don't like have addresses like ..!someisp!canonical!lamont
<lamont> NCommander: not since the late 80s
<lamont> and the lasthop was !hpda!lamont then
 * NCommander remembers HP-UX and feels slightly sick :-P
<apw> can anyone remind me where the 'update only to the next LTS' flag is for a server
<shadeslayer> apw: just use do-release-upgrade -d
<lamont> apw: d/
<shadeslayer> and it'll upgrade to precise
<lamont> bah
<lamont>  /etc/update-manager/meta-release
<apw> lamont, ahh /etc/update-manager/release-upgrades thanks for the right area
<lamont> apw: pastefail
<lamont> sorry
<apw> lamont, heh :)
<ogra_> 2706 ogra      20   0 2172m 746m  21m R  102  4.7   5938:06 compiz
<ogra_> hmpf
<ogra_> (thats an idling machine)
<ppisati> ogra_: don't oppose the progress! :)
<ogra_> haha
<jamespage> doko, do java-access-bridge and java-atk-wrapper do the same thing?
<slangasek> cjwatson: where do things sit with bug #926340? seems glatzor hasn't replied to your last proposal
<ubottu> Launchpad bug 926340 in aptdaemon (Ubuntu Precise) "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Triaged] https://launchpad.net/bugs/926340
<cjwatson> slangasek: as you say - I was waiting for him to respond
<cjwatson> looked for him on IRC this morning actually but he wasn't around
<slangasek> IME he's not very irc-catchable
<cjwatson> I'll mail him
<slangasek> ok
<xnox> cjwatson: python3-debian, any patch-queue review updates?
<cjwatson> not yet, sorry, I meant to take care of that in my holiday last week but was stymied by lack of internet
<xnox> cjwatson: ah ok. there are two patches send to you in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625509 for python2 compat
<ubottu> Debian bug 625509 in python-debian "python-debian: please port to Py3k" [Normal,Open]
<xnox> cjwatson: ok. no rush =)
<cjwatson> yeah I saw
<cjwatson> right, off homenow, but at least irc is running in screen now
<slangasek> xnox: so do you know anything about this autofs use of /etc/nsswitch.conf?
<cjwatson> not convinced about the subprocess one, I want to take a different approach there
<cjwatson> (I'd rather use universal_newlines and make it work, than give up)
<slangasek> xnox: I can't find any relevant entry points in libnss_nis, so I'm not sure what this has to do with nsswitch at all
<xnox> slangasek: no, not really. it's just that the bug is filed against older autofs5 vs newer autofs package
<xnox> and I want to test what's going on. i remember poking that code while doing the merge and fixing other bugs.
 * slangasek nods
<infinity> slangasek: The parsing code that's throwing the error is fairly easily greppable in the autofs5 source.
<infinity> slangasek: My assumption is that it's vomiting over the [WHATEVER=something] syntax
<infinity> (Oh, that assumption would be based on me not continuing to read the bug comments where adding a line "fixes" it?)
<xnox> i am confused as to what is the bug reported here.
<xnox> nsswitch.conf is valid syntax
<slangasek> yes
<xnox> auto.master seems to configured correctly and it does work for me.
<slangasek> nsswitch.conf is valid syntax, and autofs has its own wrong parser for nsswitch.conf
<xnox> what's different in the reported setup that breaks?
<xnox> hm... cause autofs expects spaces around [ ] ?
<slangasek> dunno
<xnox> slangasek: ok. thanks for that comment. now i am back to dmraid.
<slangasek> bdmurray: what put bug #488696 on your radar?
<ubottu> Launchpad bug 488696 in autofs5 (Ubuntu Precise) "syntax error in nsswitch config near [ syntax error ]" [High,Confirmed] https://launchpad.net/bugs/488696
<jdstrand> slangasek: for security support, icedtea-6-plugin should be demoted and icedtea-7-plugin promoted, correct?
<jdstrand> meh
<jdstrand> slangasek: nm
<jdstrand> sbeattie: ^
<bdmurray> slangasek: the release task nominations
<jdstrand> sbeattie: it looks like this is what icedtea-web is doing now, and thought I'd fix the component-mismatches if you tell me so
<jamespage> jdstrand, I'd +1 that - lines up with the Java 6 -> 7 transition
<jamespage> (and it was me that just switched the 'default')
<slangasek> bdmurray: ah, ok
<jdstrand> jamespage: ack
<sbeattie> jdstrand: yeah, that's correct.
<jdstrand> jamespage, sbeattie: thanks, I'll adjust
<jamespage> jdstrand, marvellous - thanks
<jdstrand> (done)
<xnox> slangasek: both mdadm and dmraid have support for isms
<xnox> s/isms/imsm/, the intel raid
<xnox> and both try to assemble them in udev/initramfs
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, smoser
<xnox> i will disable intel and ddf in mdadm for now, and will think about how to migrate from one to another...
<xnox> since there is no way to know.
<xnox> to know what the user wants.
<xnox> the device names and symlinks generated are different
<bdmurray> mterry: do you have any test case ideas for bug 818760?  I've uploaded an SRU for precise for it.
<ubottu> Launchpad bug 818760 in update-manager (Ubuntu Precise) "update-manager crashed with timeout in readline(): timed out" [High,In progress] https://launchpad.net/bugs/818760
<mterry> bdmurray, no...  I couldn't reproduce myself.  I just looked at the stacktrace and used that to fix the bug
<doko> jamespage, java-access-bridge is obsolete now
<jamespage> doko, thats what I thought looking at it; as it FTBFS I'll file a removal bug report
<doko> yes, sounds fine
<slangasek> xnox: ok, cool
<tjaalton> @pilot out, meh
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<tjaalton> bah
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<shadeslayer> I found this in germinates output : ? Unknown desktop-common package: fonts-freefont
<shadeslayer> shouldn't that be fonts-freefont-ttf ?
<shadeslayer> cjwatson: ^ bzr log says you changed this :)
<infinity> shadeslayer: Yeah, looks like a source/binary thinko.  I'll fix.
<shadeslayer> infinity: awesome
<infinity> shadeslayer: Committed.
<shadeslayer> thanks
<shadeslayer> now if someone could just tell me why smbfs was dropped ....
<infinity> shadeslayer: In edgy...?
 * shadeslayer is yet to find a reason for that
<shadeslayer> infinity: quantal
<shadeslayer> apparently Daviey did a merge and it disappeared
<infinity> Oh, the log shows it being dropped in edgy. :P
<shadeslayer> whut
<shadeslayer> infinity: it comes from cifs-utils
<shadeslayer> !info smbfs precise
<ubottu> smbfs (source: cifs-utils): Common Internet File System utilities - compatibility package. In component main, is optional. Version 2:5.1-1ubuntu1 (precise), package size 3 kB, installed size 47 kB
<shadeslayer> !info smbfs quantal
<ubottu> smbfs (source: cifs-utils): Common Internet File System utilities - compatibility package. In component main, is optional. Version 2:5.1-1ubuntu1 (quantal), package size 3 kB, installed size 47 kB
<shadeslayer> dafuq
<shadeslayer> ahh
<shadeslayer> yes, as you can see, current cifs-utils is 2:5.5 whereas ubottu reports 2:5.1
<shadeslayer> !info cifs-utils
<ubottu> cifs-utils (source: cifs-utils): Common Internet File System utilities. In component main, is optional. Version 2:5.1-1ubuntu1 (precise), package size 64 kB, installed size 176 kB
<infinity> shadeslayer: So, I see both smbfs and cifs-utils seeded...
<shadeslayer> infinity: but smbfs doesn't exist ... https://launchpad.net/ubuntu/+source/cifs-utils/2:5.5-1ubuntu1
<infinity> shadeslayer: Oh, you weren't talking about seeds anymore.  Check.
<shadeslayer> nope
<shadeslayer> infinity: I'm talking about completely missing binary packages in the archive
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620847
<ubottu> Debian bug 620847 in smbfs "Keep shipping smbfs package with smbfs wrappers?" [Normal,Fixed]
<infinity> shadeslayer: I think the answer here is "transition to using cifs-utils, and stop relying on smbmount"
<shadeslayer> got it
<shadeslayer> I guess I saw the transitional package on packages.debian.org
 * shadeslayer fixes his seeds
<infinity> shadeslayer: Fixed the samba-server seed in quantal too.
<shadeslayer> yay
<shadeslayer> infinity: uh ... wait, I don't understand, samba-server seed? 0.o
<infinity> shadeslayer: For the "samba-server" Task.  It installed smbfs, which used to pull in cifs-utils transitively.
<infinity> shadeslayer: Which obviously doesn't work anymore. :P
<shadeslayer> ahh ok
<shadeslayer> infinity: though, I'm curious as to where the samba-server task resides
<infinity> apt-get install samba-server^
<infinity> (or use tasksel)
<shadeslayer> uhh
<shadeslayer> !find samba-server quantal
<ubottu> Package/file samba-server does not exist in quantal
<infinity> It's a task, not a package.
 * shadeslayer looks
<infinity> apt-cache show samba | grep ^Task
<shadeslayer> ahhhh ok
<ogra_> hggdh, https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages?field.name_filter=linaro-boot-utils&field.status_filter=published&field.series_filter=precise
<ogra_> hggdh, http://paste.ubuntu.com/1123801/
<ogra_> hggdh, http://people.canonical.com/~ogra/uboot/
<SpamapS> slangasek: looking at the libbonobo SRU.. does this mean all the reverse deps have to be rebuilt, or just *tested* to build with the new one?
<SpamapS> $ apt-cache rdepends libbonobo2-0|wc -l
<SpamapS> 45
<stgraber> SpamapS: just tested to build
<SpamapS> ok
<slangasek> SpamapS: just tested, yes
<slangasek> stokachu: ^^ have libbonobo revdeps been build-tested now?
<mhall119> can someone take a look at https://bugs.launchpad.net/ubuntu/+bug/1031886?
<ubottu> Launchpad bug 1031886 in Ubuntu "[needs-packaging] unity-lens-help" [Undecided,New]
<mhall119> at UDS-Q, sabdfl showed interest in a help lens
<mhall119> it should already have a package
<slangasek> SpamapS: hold off on nis in -proposed please
<SpamapS> slangasek: ok. Is it broken-er than before?
<slangasek> SpamapS: there's at least one regression, bug #993291
<ubottu> Launchpad bug 993291 in nis (Ubuntu Quantal) "[SRU] package nis 3.17-32ubuntu1.2 failed to install/upgrade: invoke-rc.d: unknown initscript, /etc/init.d/nis not found." [Medium,Fix released] https://launchpad.net/bugs/993291
<slangasek> and I think there may be another one, which is what I was looking for when stumbling upon that one
<SpamapS> slangasek: should we mark bug 569757 verification-failed ?
<ubottu> Launchpad bug 569757 in nis (Ubuntu Oneiric) "NIS upstart dependency broken for lucid" [High,Fix committed] https://launchpad.net/bugs/569757
<slangasek> SpamapS: just doing so now, but wanted to make sure I got you directly to avoid any race conditions :)
<SpamapS> slangasek: consider me blocked
<slangasek> SpamapS: ok, further analysis tells me that publishing the nis SRU for lucid should be safe: https://bugs.launchpad.net/ubuntu/+source/nis/+bug/569757/comments/75
<ubottu> Launchpad bug 569757 in nis (Ubuntu Oneiric) "NIS upstart dependency broken for lucid" [High,Fix committed]
<slangasek> SpamapS: btw, the tags on that bug ended up being 'verification-done verification-done-lucid verification-needed'... what's that supposed to mean?
<slangasek> I've seen similar tag sets applied to other SRUs, but I'm not aware that the report tools do anything useful with such a combo, and AFAIK it's not documented on the SRU page
<stgraber> slangasek: I implemented verification-done-<SERIES> into sru-report a few weeks ago
<slangasek> ah
<slangasek> then shouldn't it be *just* verification-done-<SERIES>, without the verification-done tag?
<stgraber> yes
<stgraber> using both was the old way of doing it as sru-report wouldn't mark it green
<stgraber> so in the past most people would mark verification-done + verification-done-SERIES, then when accepted, the SRU team member would reset verification-done until all series were verified
<stgraber> which was rather confusing, so for bugs like that, the "right" way of doing it now should be to only use the -SERIES tag
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> what happened to firefox that's causing pdfs to now load in-browser in some horribly slow reader?
<slangasek> is this just me?
<elmo> slangasek: installing the adobe pdf reader can do that
<slangasek> not installed
<mdeslaur> slangasek: firefox now has a built-in pdf viewer
<mdeslaur> slangasek: Ã  la chrome
<bkerensa> slangasek: we integrated reading
<bkerensa> :D
<slangasek> mdeslaur: how do I turn it off?
<slangasek> this is not a feature
<bkerensa> slangasek: you cannot atm
<slangasek> argh
<bkerensa> https://bugzilla.mozilla.org/show_bug.cgi?id=752676
<ubottu> Mozilla bug 752676 in PDF Viewer "Control pdf.js and Other PDF Plugins using Application Preferences" [Normal,Verified: fixed]
<bkerensa> :D
<mdeslaur> dpkg -P firefox?
<slangasek> mdeslaur: and use what instead for the browsing?
<mdeslaur> slangasek: w3m-img! :P
<slangasek> well, pdfjs.disabled lets me disable it entirely; still doesn't let me view pdfs directly in evince, I have to save them to file now :/
<slangasek> mdeslaur: away with you, troll
<mdeslaur> lol
<mdeslaur> the retro-grouches I work with have started to rub off on me :)
<SpamapS> slangasek: re the tags on the nis SRU.. IIRC there was also a Fix Committed task for another release, so verification-done + verification-needed == purple on the SRU report
<clepto> hello, i am writing an app with quickly-pygtk-glade and i have some questions...i want to show a dialog and get the return id...
<clepto> i used the run() method
<clepto> but then i closed the dialog and try to reopen it
<clepto> and i got an emtpy window
<ogra_> clepto, see /topic ... #ubuntu-app-devel might be a better place to ask this
<clepto> thanks!
<enapupe> Hi, I'm searching for some information on how ubuntu handle multimedia keys on my keyboard, can anyone show me some directions?
<slangasek> enapupe: /usr/share/doc/udev/README.keymap.txt.gz
<enapupe> wow, now i'm 1 step ahead, ty very much slangasek !
<enapupe> now, I was abble to find this: scan code: 0xC00CD   key code: playpause  // I would like to reproduce the effect of pressing this key, is this possible?
<slangasek> enapupe: there's no good way to emulate keypresses that I know of
<enapupe> slangasek: xdotool seems to work just fine, but it wont understand the multimedia keys
<enapupe> xdotool key Alt+F4 // this works fine, prompts me to close the terminal
<enapupe> AFAIK my keyboard works as 2 eventX instances, 1 for regular keys and another to multimedia
<slangasek> yes, the problem with emulating multimedia keys is that many of them are mapped outside of the range of keycodes that can be represented in X - so they're actually bridged to the desktop via a dbus service
<enapupe> is thing something on the driver level?
<slangasek> no
<slangasek> it might be gnome-settings-daemon intercepting these directly?
<enapupe> sudo /lib/udev/keymap -i input/event5
<enapupe> scan code: 0xC00EA   key code: volumedown
<enapupe> ^C
<enapupe> this behavior answers the question?
<NCommander> Who usually handles migration of a package that's aged in proposed and is verification-done?
<stgraber> sru team
<stgraber> NCommander: on Wednesday it's SpamapS
<NCommander> SpamapS: are you around? I'd like to see highbank migrate, its verification-done and in proposed
 * NCommander fishes for a bug
<NCommander> SpamapS: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004018
<ubottu> Launchpad bug 1004018 in libdebian-installer (Ubuntu Precise) "Add highbank images" [High,Fix committed]
<SpamapS> NCommander: infinity had asked me to leave those to him.
<SpamapS> infinity: ^^ ?
<NCommander> SpamapS: ah
<SpamapS> NCommander: but yes, they appear to be ready
<mdeslaur> SpamapS: any chance you can push LP: #953922?
<NCommander> SpamapS: great, I'll nag infinity then.
<mdeslaur> SpamapS: is that one not appearing on your list, or do you guys just have a back log?
<SpamapS> mdeslaur: its there. I stopped 2 short of it. ;)
<SpamapS> totem and remmina are in front of it
<mdeslaur> SpamapS: ah, cool. thanks...I wasn't sure if I did something wrong or not.
<SpamapS> mdeslaur: no, looks good. If its small I can do a quick queue jump..
<SpamapS> mdeslaur: accepted :)
<mdeslaur> SpamapS: awesome, thanks!
<enapupe> slangasek: found a way! echoing the keything to \dev\input\event5
<slangasek> ah, interesting
<enapupe> don't ask me wtf is this keything, the weirdest string ever seen
<enapupe> i don't know what kind of encoding it is
<scientes> backslashes FTW
<enapupe> :T
<enapupe> scientes: would you believe if I say that i wrote corretly before, then deleted and typed wrong?
<enapupe> maybe is my IRC client font which makes the slashes uggly ;P
#ubuntu-devel 2012-08-02
<pitti> Good morning
<bkerensa> cyphermox: So any new info you need for Bug #972063
<ubottu> Launchpad bug 972063 in bluez (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Confirmed] https://launchpad.net/bugs/972063
<soren> No dholbach today?
<seb128> soren, he's on holidays still I think, let me check
<soren> Ok.
<didrocks> seb128: soren: he is
<soren> seb128, didrocks: Alrighty. Thanks, guyes.
<soren> guys, even.
<seb128> soren, he's not noted in the holidays calendar but I would say he's still away for a week
<didrocks> seb128: I got yesterday the confirmation he is :)
<didrocks> hence my answer
<seb128> didrocks, ok, sorry I didn't read the channel was I was looking and didn't see your answer before adding my extra comment ;-)
<didrocks> no worry ;)
<ppisati> guys, why do we make life of Skype users so hard?
<ppisati> if you tick the "start minimised in tray", close and restart Skype it looks like it's gone
<ppisati> but it's running, just it doesn't show up in tray
<seb128> tkamppeter,
<seb128> hey
<seb128> re your ghostscript upload:
<seb128> "  * debian/control: Re-added build dependency on libicc-dev, it seems that
<seb128>     it got lost by some Debian/Ubuntu merge."
<seb128> tkamppeter, it was not lost, argyll is in universe, you need a MIR for it
<wookey> can someone merge libslang2 from debian to fix lp:1028451, becausenot being able to edit anything in quantal is _really_ annoying (much as it was in debian before it got fixed there :-)
<wookey> I guess thre is an official merge-request button I should push somewhere
<seb128> wookey, hey, I will have a look
<wookey> cheers
<didrocks> doko_: hey, around?
<wooy> hi
<wooy> why would someone start patch file like this:
<wooy> --- /dev/null
<wooy> +++ real/path/here
<wooy> got it
<wooy> `diff /dev/null new.config > some.patch`
<Chipzz> wooy: noone does. I think it's the result of a diff -r where the file doesn't exist in the 1st dir
<wooy> yep, thats directory wide equivalent to the cmd above i think
<wooy> also, as it seems, using --- path and +++ path is bit fuzzy, replacing one of them with /dev/null makes the other one the only candidate, making it bit more predicable (at least to me)
<infinity> Sweetshark: Have a libreoffice upload pending?  It needs a rebuild ASAP for the libexttextcat SOVER transition.
<stgraber> arges, seb128: meeting in #ubuntu-meeting
<Sweetshark> infinity: soonish.
<infinity> Sweetshark: "ish"?
<seb128> stgraber, thanks
<infinity> Sweetshark: I'm going to upload a rebuild right now, then, if "ish" isn't "pretty close to right now".
<infinity> Sweetshark: Cause the world is uninstallable. :/
<Sweetshark> infinity: ok, pushing package to chinstrap
<infinity> Oh, a new RC.  Fun.
<infinity> Sweetshark: No changes except for the new upstream source?  (ie: no changes in debian/* ?)
<Sweetshark> infinity: minimal changes in debian IIRC
 * Sweetshark checks
<Sweetshark> infinity: so, I reenabled binfilter (otherwise libreoffice-dbg is uninstallable)
<infinity> Sweetshark: Making it not depend on it would have worked too. :P
<Sweetshark> infinity: also that package completed at https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+sourcepub/2590864/+listing-archive-extra for i386 and is far in the build for amd64. so should be reasonably safe to upload.
<apw> i assume its casper which displays the "Is connected to power" "Is connected to the internet" screen during installation
<Sweetshark> infinity: /me has a secret plan to kill stupid binfilter upstream and for good.
<Sweetshark> infinity: see https://wiki.documentfoundation.org/Development/LibreOffice4#General_changes
<infinity> Sweetshark: So, shouldn't libreoffice-dbg use the magic ${ooo-binfilter-dep}, so it ends up installable on ARM too?
<infinity> Sweetshark: Although, I guess it uses a bit |ed list anyway.  So, I'm not sure why that was ever uninstallable?
<infinity> Sweetshark: Meh.  Nevermind the binfilter annoyance.  A more verbose changelog would be nice, though, since it doesn't actually say what you changed.
<infinity> Sweetshark: http://paste.ubuntu.com/1125276/ <-- All of those changes would be nice to have mentioned.
<arges> infinity, hey any updates on http://launchpad.net/bugs/979003 AVX/FM4? Today is the last day if its going to make it in the 12.04.1 point release, if it ain't going to happen, i'll bump it to target 12.04.2 thanks
<ubottu> Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress]
<infinity> arges: Oh, it's gonna make it, if I have to bribe stgraber with cookies.  Or if I have to hurt myself to get it done today.  Or both.
<Sweetshark> infinity: next time, when I am not finalizing the package ad-hoc on your request during an engineering steering committee call discussing if rc4 is final ....
<arges> infinity, ok well before resorting to hurting youself, ping me and i'll try to help out where i can
<stgraber> infinity: when can you get it uploaded (without hurint yourself too much ;))?
<infinity> stgraber: Tonight or tomorrow, testing pending.  Handwavy and such.  If testing hates me, weekend at the latest, cause I refuse to let it drag into next week. :P
<stgraber> infinity: ok, I'll add the two bug numbers to the exception list then so I don't re-milestone these to .2 and know that they'll get fixed post-freeze time
<infinity> stgraber: I think there might be more than two.  But I'll poke you when it's all finalised.
<infinity> (It'll be obvious from the changelog anyway)
<stgraber> infinity: looks like bug 979003 is the only milestoned one (unless I missed something quickly reading through the bug list)
<ubottu> Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress] https://launchpad.net/bugs/979003
<infinity> stgraber: Oh, I have others with precise tasks that probably failed to get milestoned, but I don't see much point doing them separately, since the AVX/FMA4 bits are the hardest part, the rest is fluff.
<infinity> stgraber: I'll dig it all up for you later today as I get it happier.
<stgraber> ok, thanks
<infinity> Sweetshark: Uploaded.
<Sweetshark> infinity: awesome, thanks!
<jibel> Sweetshark, infinity FYI 1:3.6.0~rc4-0ubuntu1~ppa1 is building in the lab. i386 built fine and and it building the packages, amd64 is still running
<infinity> jibel: Well, we'll find out soon enough if the one I uploaded to the archive builds.  It can't be any worse than the current situation. :P
<dobey> is there a branch import queue status page somewhere?
<jelmer> dobey: http://code.launchpad.net/+code-imports/+machines
<dobey> jelmer: i meant for the UDD branches. merging from the debian source packages into the lp:ubuntu/foo branches
<dobey> jelmer: sorry if that wasn't clear. :)
<jelmer> dobey: ah - see http://package-import.ubuntu.com/status/
<dobey> ah, thanks
<dobey> jelmer: hrmm, i don't see ubuntuone-control-panel mentioned anywhere on that page, but the lp:ubuntu/ubuntuone-control-panel branch is out of dateâ¦
<dobey> wonder where it went :(
<jelmer> dobey: it might just be in the list of failures
<jelmer> hmm, I don't see it there either
<dobey> jelmer: right, i searched the whole page with firefox search-in-place and got nothing :)
<tkamppeter> seb128, can I MIR only libicc?
<seb128> tkamppeter, no, you can't MIR a library, libicc is shipped by argyll
<tkamppeter> seb128, I remember that I once tried to MIR argyll, but due to argyll's strange build system, which is not maintained any more and therefore cannot be MIRed into Main, too, I stopped trying to complete the MIR for argyll.
<seb128> tkamppeter, that's probably why ghostscript was not build-depends on libicc then
<seb128> tkamppeter, you might want to drop that build-depends again
<tkamppeter> seb128, for me it seems that I will return to Ghostscript's internal libicc then, having this the only internal lib of GS due to distro-unfriendlyness of Argyll.
<infinity> tkamppeter: Hrm?  If argyll wasn't pulling an old version of libtiff back into main, I fail to see what other grounds it would fail an MIR on.
<infinity> tkamppeter: Build system is a silly one, we have tons of weird build systems in main.
<infinity> tkamppeter: Ahh, I see there was some libusb issues.  That might be fixed with more recent upstream libusb in quantal?
<infinity> tkamppeter: Also, you could just keep the argyll/libicc split?
<tkamppeter> infinity, the problem of the build system is that as build dependency it also needs to get MIRed into main and the build system is not maintained upstream any more.
<tkamppeter> infinity, I am now making a new Ghostscript package using its own libicc.
<infinity> tkamppeter: Why not just keep the source split, like it was before?
<tkamppeter> infinity, if the source split is still in place I could simply MIR libicc and seb128 made the impression for me that libicc is part of the argyll source package. If it is still split off, we simply MIR libicc.
<infinity> tkamppeter: It's not split right now, but you did it once before...
<infinity> Or, so I was led to believe by bug logs. :P
<tkamppeter> infinity, was there ever reported a MIR for argyll or libicc? If yes, can you post the bug numbers here?
<Sweetshark> infinity: oh great, gcc 4.7 crapped out on i386. the same build finished here locally (though on amd64) and in the ppa at https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+build/3695349 so I would suggest to retry the build.
<infinity> https://bugs.launchpad.net/ubuntu/+source/argyll/+bug/821883
<ubottu> Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High,Invalid]
<infinity> https://bugs.launchpad.net/ubuntu/+source/libicc/+bug/824032
<ubottu> Launchpad bug 824032 in libicc (Ubuntu) "[MIR] libicc" [High,Fix released]
<infinity> Sweetshark: You had the sources split before, and libicc had a valid MIR.
<infinity> Sweetshark: Athough, libicc went back to universe after that MIR, perhaps because you never actually ended up linking to it?
<seb128> tkamppeter, ^ those lines are for you I think
<Sweetshark> huh, what? icc?
<infinity> Err..
<infinity> Sweetshark: My brain exploded.
<infinity> tkamppeter: See above. :P
 * Sweetshark gives infinity a hug and a cookie.
<infinity> Sweetshark: The build failures were intentional, don't worry about it.
<Sweetshark> infinity: ^^
<tkamppeter> infinity, so we would need to re-split libicc and then link it from Ghostscript to complete the already existing MIR?
<infinity> Sweetshark: I noticed that you'd targetted -proposed, and decided that was suboptimal. :P
<infinity> tkamppeter: Something like that, yes.
<tkamppeter> infinity, how is argyll and libiccc handled in Debian? Are they together or split?
<Sweetshark> infinity: yes, I heard whispers about it being discussed on -release. anyway, yeah, it was what was there, sorry ;)
<infinity> Sweetshark: My fault for not looking at the target.
<tkamppeter> infinity, I do not want to have it jumping forth and back because of different parties in the two distros liking one or the other version more or loosing track on certain conditions like Ghostscript.
<infinity> tkamppeter: I'm assuming together, since the current state in quantal looks like a straight sync.
<infinity> tkamppeter: In oneiric and precise, we had your split version, then someone synced overit.
<infinity> tkamppeter: You can blame RAOF, according to quantal-changes. :P
<tkamppeter> infinity, currently, I like much more the version of the two being together as they come from the same source.
<tkamppeter> infinity, I also do not want to have to work on the horrible build system of argyll.
<infinity> tkamppeter: Well, I'm still curious about this "build system MIR" thing you mention?
<infinity> tkamppeter: The only extra package argyll is trying to pull in is tiff3.
<infinity> tkamppeter: Which you should certainly fix.
<infinity> tkamppeter: But other than that, I'm not seeing the problem.
<tkamppeter> infinity, and I also do not want to maintain a distro patch replacing the build system of argyll.
<infinity> tkamppeter: Again, why do you think we need to do anything to/with the build system?
<stgraber> infinity: at least on precise, it seems to be using jam which isn't in main
<infinity> stgraber: Not in quantal.
<infinity> The only issue I see in quantal is that it needs libtiff transitioning.
<tkamppeter> infinity, main consumer of argyll is RAOF, as he maintains the bits for calibrating monitors.
<infinity> tkamppeter: Well, let's reopen the old MIR, shall we?
<infinity> I see that it now build-deps on libusb-dev
<infinity> So, the bundled libusb thing seems to be fixed.
<infinity> And it no longer uses jam.
<infinity> Or no longer build-deps on it.
<infinity> So, transition it for the new libtiff, and it's probably fine.
<tkamppeter> infinity, it need also to get transitioned for the new libusb 1.0.x as libusb 0.1.x we are fading out as it is not maintained upstream any more.
<tkamppeter> infinity, best is if RAOF does that. Can you add a comment to the reactivated bug and contact/CC/assign RAOF? Thanks.
<infinity> tkamppeter: Well, libusb-dev is in main...
<infinity> tkamppeter: Unless the whole world has transitioned, I don't see forcing others to.
<infinity> OH DEAR GOD, I PASSED -v1.2.3 WITHOUT AN EPOCH AND DIDN'T NOTICE.
<tkamppeter> infinity, so the libusb transition is not so urgent.
<infinity> adconrad@chinstrap:~/libre $ wc -l libreoffice_3.6.0~rc4-0ubuntu2_source.changes
<infinity> 4863 libreoffice_3.6.0~rc4-0ubuntu2_source.changes
 * infinity weeps.
<stgraber> infinity: well, at least we aren't missing any changelog entry ;)
<infinity> I apologise in advance to everyone who reads -changes.
<infinity> A 226k .changes is impressive, I'll give it that.
<infinity> That's probably a sign that it's time for a keyboard break and some breakfast.
<tkamppeter> infinity, can you update bug 821883? Thanks.
<ubottu> Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High,Triaged] https://launchpad.net/bugs/821883
<infinity> tkamppeter: I already reopened it.  Can give the current sources a once-over a bit later.
<infinity> tkamppeter: But without even looking, the tiff transition needs to happen, so you might want to test-build that and make sure it doesn't need patching (or fix it if it does), while I look to make sure the rest is in order.
<tkamppeter> infinity, are you core dev?
<infinity> tkamppeter: Last time I checked.
<barry> infinity: i guess you don't know about the automatic de-core-deving feature triggered on .changes > 200k?
<tkamppeter> infinity, then you could sync qpdf from Debian (to 3.0.0 final), so that we can complete the qpdf MIR.
<infinity> barry: *cough*
<infinity> tkamppeter: In experimental?
<infinity> Ahh, indeed.
<infinity> tkamppeter: Done.
<mdeslaur> barry: I think working 20 hours a day exempts infinity from that restriction :P
<barry> mdeslaur: oh, right, i forgot about the multiplier.  don't tell infinity that he gets an extra 20*60*60 k headroom.
<mdeslaur> hehe
<tkamppeter> infinity, thanks.
<tkamppeter> infinity, sorry, for having made you so much work, but the icclib dependency in ghostscript turned out to be a ghost.
<infinity> tkamppeter: ?
<tkamppeter> I did ldd on libgs.so and wondered why there is no libicc in the output. Then I asked the ghostscript upstream developers about how Ghostscript uses libicc and they told that it does not use it any more. I checked all the .c and .h files in Ghostscript's source code and none #includes the .h files of libicc. So the icclib directory in Ghostscript's original source code is a dead body.
<tkamppeter> infinity, so I will upload a Ghostscript which simply drops the libicc-dev dependency.
<tkamppeter> infinity, the Argyll MIR should be followed anyway as Argyll got more distro-friendly with the time. This should be done by RAOF as he is the main consumer of Argyll.
<toabctl> pitti, is there any progress on porting d-feet to pygi?
<infinity> tkamppeter: Well, if nothing in main needs it, there's no need for the MIR.  *shrug*
<infinity> tkamppeter: But feel free to talk to RAOF and see if he wants to follow through for other reasons.
<tkamppeter> infinity, new ghostscript uploaded.
<tkamppeter> infinity, I have added a comment to bug 821883 now.
<ubottu> Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High,Triaged] https://launchpad.net/bugs/821883
<seb128> licensing questions
<seb128> if a source as it's sources under GPL2+
<seb128> with COPYING being GPL3
<seb128> what should the debian/copyright contains?
<seb128> src/*: GPL2+
<seb128> or GPL3?
<slangasek> I would say GPL2+
<slangasek> an explicit copyright statement in the source is more authoritative than whatever license happens to be included
<seb128> slangasek, thanks, I though that the COPYING was "dictating" the tarball license
<seb128> so sources being 2+ and COPYING 3 the lot would be 3
<slangasek> well, if in doubt I think it's best to get clarification from upstream
<seb128> ok
<slangasek> but there are plenty of cases where COPYING files are included that are just a copy of the GPL, and not everything in the tarball is GPL-licensed (or GPL-compatible)
<slangasek> or cases where COPYING + COPYING.LIB are both present and nothing is LGPL licensed
<seb128> right
<seb128> well I'm not too concerned about that one, it's one of the tarballs of the ubuntu-online-account team, I was just wondering if debian/copyright should state GPL3 if that's what COPYING contains
<seb128> kenvandine said he will get them to clarify that for the next update
<slangasek> er... is Canonical upstream for this?
<slangasek> because in *that* case, the correct license is probably GPLv3 :)
<slangasek> (the default licensing policy for Canonical works)
<seb128> slangasek, yeah, that's what he will get sorted for the next upload, I was just wondering if I should block the NEWing on it
<slangasek> I wouldn't block
<seb128> great, I was going to block, thanks for the replies ;-)
<robbiew> slangasek: hey...did something weird just get uploaded in precise-proposed....I'm having issues with joining the canonical irc and my mail client started acting funny
<seb128> doh
<robbiew> I applied updates just now
<seb128> was->wasn't
<slangasek> robbiew: um... hmm
<robbiew> I know my description of the issue sucks
<slangasek> not sure we have a sane way to check for recent precise-proposed changes
<robbiew> I think it's related to secure connections or something....
 * robbiew digs
<seb128> krb5 and openssl got accepted recently
<seb128> looking at -changes
<slangasek> krb5 was a server CVE; openssl is a more likely culprit
<slangasek> right, https://lists.ubuntu.com/archives/precise-changes/2012-August/thread.html shows the recent changes
<seb128> openssl (1.0.1-4ubuntu5.4) precise-proposed; urgency=low
<seb128>   * debian/patches/lp973741.patch: Avoid segfault on legacy Intel CPUs
<seb128>     by using correct cypher. (LP: #973741)
<seb128>  
<seb128> that was yesterday
<seb128> robbiew, try downgrading that and see if that fixes it?
<robbiew> seb128: ack
<slangasek> robbiew: otherwise, /var/log/apt/history.log is the place to look to check which updates were applied on your system between "Working" and "Broken"
<robbiew> cool
<slangasek> but yeah, openssl seems likely
<robbiew> thx
<infinity> seb128 / slangasek: I'm going to drop that openssl SRU out of -proposed anyway, it's broken on !x86.
<slangasek> okely dokely
<seb128> should .pc Libs.private requirement be listed as depends of -dev binaries?
 * micahg would think not
<slangasek> IMHO no
<seb128> ok, what I though but I was unsure, thanks
 * micahg wonders what the point of listing it in the first place is (isn't the .pc file for other software to consume?)
<kenvandine> micahg, yeah, i can't see why it is there at all
<micahg> kenvandine: ah, Libs.private:  This line should list any private libraries in use. Private libraries are libraries which are not exposed through your library, but are needed in the case of static linking.
<micahg> since we don't do static linking, it's not an issue
<kenvandine> good point
<kenvandine> perhaps
<infinity> adam_g: Updated bug #973741 ... You might want to test with that slightly larger patchset (1.2->1.5) that I linked.
<ubottu> Launchpad bug 973741 in openssl (Ubuntu Precise) "[SRU] segmentation fault for all https operations in libcrypto.so.1.0.0 on 'legacy' Intel Xeon CPUs" [High,Confirmed] https://launchpad.net/bugs/973741
<infinity> adam_g: And if you have access to ARM or PPC hardware, I recommend a quick spin there too.
<slangasek> infinity, adam_g: which you should have access to via the porter machines if nothing else
<adam_g> infinity: thanks, ill try that a try on non-x86 soon
<infinity> Okay, really lunching now.
<shadeslayer> hi, I'm trying to build my own kernel using make-kpkg, but I keep hitting this issue :
<shadeslayer> dpkg-gencontrol: error: illegal package name 'linux-image-3.5.0-powersave-ARCH': character 'A' not allowed
<shadeslayer> I believe ARCH is supposed to be replaced by my architechture .. but something seems to be going wrong
<ScottK> shadeslayer: Maybe #ubuntu-kernel.
<shadeslayer> alrighty
<ogra_> hggdh, http://paste.ubuntu.com/1125837/
<slangasek> is anyone else noticing severe problems with the bandwidth to bazaar.launchpad.net  && upload.ubuntu.com today?
<lifeless> see #launchpad
<lifeless> there was a PMTUd issue, not entirely debugged, but workarounds in place now.
<slangasek> ok
<slangasek> lifeless: as of when is the workaround in place?  Because upload.ubuntu.com just failed to take a 9k upload, 4 minutes ago
<slangasek> (hung at 8k)
<elmo> slangasek: as of about 2m ago
<slangasek> ok :)
<dobey> is there a way to force a re-import of a UDD branch from the source package in the archive?
<adam_g> infinity: about to send a debdiff for a new openssl with that patch. do i use the same version of the package that was removed from -proposed (4ubuntu5.4), or bump that to 4ubuntu5.5?
<slangasek> adam_g: bump
<slangasek> once the package has been accepted, the version number can never be reused
<slangasek> robbiew: did downgrading libssl fix your bug?
<robbiew> slangasek: well...I think so...I also downgraded libssl1
<slangasek> yeah, that's the one I mean :)
<robbiew> oh..well then yes, I believe so
<slangasek> ok
<ScottK> adam_g: Was the previous accepted into -proposed or was it just in the queue.
<slangasek> ScottK: it had been accepted
<ScottK> adam_g: .5.
<ScottK> slangasek: Thanks.
<ScottK> And I guess I should have read further down in the backscroll ...
<adam_g> thanks
<ogra_> hggdh, http://paste.ubuntu.com/1125948/
<adam_g> slangasek: in that case, the debdiff should compare 5.5 and 5.3 (released), or 5.5 and 5.4 (removed)?
<slangasek> adam_g: 5.5 and 5.3
<robbiew> slangasek: fwiw...I'm not sure if it was on my end or the pMTUd issues...i guess I could re-apply the new stuff and check
<slangasek> if you still have the new stuff handy, yeah... it's gone from -proposed already :)
<shadeslayer> hmm
<shadeslayer> infinity: I'm not entirely sure, but seems like linux-headers-3.5.0-7 has a broken task as well, doesn't list kubuntu-desktop
<shadeslayer> then again, I might be wrong
<scientes> whats the reason to use deadline scheduler by default?
#ubuntu-devel 2012-08-03
<pitti> Good morning
<cc11rocks> I know Java, and am sorta learning HTML and Scala (learning it through learning the Play! Framework). Can my programming skills be used to help Ubuntu's bugs?
<ailo> infinity: Hi, we at Ubuntu Studio would like to fix bug #1029685, by merging jackd2 from debian.
<ubottu> Launchpad bug 1029685 in jackd2 (Ubuntu Quantal) "jack_control script corrupted in 1.9.8~dfsg.4+20120529git007cdc37-1ubuntu2 " [Low,Triaged] https://launchpad.net/bugs/1029685
<TheMuso> ailo: Has anybody done the merge yet, or would you like it done?
<cc11rocks> Will anyone answer my question? I believe I could possibly be of help to the dev. team
<spm> cc11rocks: in general terms, if you find a bug that interests you to fix, go for it. submit a merge proposal/patch and go find the next one. rinse and repeat.
<cc11rocks> spm : I want to know how to get started. I just found https://wiki.ubuntu.com/UbuntuDevelopment/GettingSetUp and https://wiki.ubuntu.com/Bugs/HowToFix
<cc11rocks> I have to look through the code for the problem area(s) myself,or is that done for me?
<cc11rocks> And most of it is in C, C++, JS, or what?
<spm> it depends on whatever the package in question was written in. all the above and then some, would be the answer.
<spm> https://wiki.ubuntu.com/MOTU/Contact may be of value to help; if you're looking at fixing packages
<ScottK> A lot of it depends on self motivation.
<cc11rocks> Okay, thanks
<ScottK> People are glad to help and answer questions, but a lot of us are volunteers who don't have a whole lot of spare time for this either.
<cc11rocks> if I have issues/troubles, you guys will help me or no?
<ScottK> People will help you.
<ScottK> If you're trying to contribute, people will see that an help.
<cc11rocks> Okay, thanks. I'm a HS student (4th year into computing, 1.5~2 years into programming, 6 month 100% reliant on GNU/Linux)
<cc11rocks> But I'm busy too. Taking many college classes and I have a job. No clue how much I'll be able to help out
<SpamapS> interesting.. Chrome 21.0.1180.57-r14 crashes sporadically when trying to upload images to my blog
<ScottK> Every little bit heps and everyone has to start somewhere.
<ScottK> heps/helps
<cc11rocks> Okay, thank you :)
<ailo> TheMuso: Don't think it's done yet, but yes, would like to have it done :).
<infinity> ailo: Looks like a simple enough merge.
<ailo> infinity: Yep
<infinity> ailo: I'll just knock that off right now.
<ailo> Great
<TheMuso> ailo: I can take care of it, I try and keep an eye on jack at least, because its somewhat a part of the alsa/pulse/general audio stack.
<infinity> TheMuso: Too late, but you can take the next one. :P
<TheMuso> infinity: Thanks.
 * infinity fixed up his previous patch to be more upstreamable while he's at it.
<cjwatson> janimo: Any particular reason ubuntu-archive is subscribed to bug 1025716, bug 1025719, and bug 1025720?  There seems to be no clear action for us to take on those, and when there are packages to review they'll show up in the NEW queue - we don't need to be subscribed to bugs for those
<ubottu> Launchpad bug 1025716 in Ubuntu "Package cedarview-graphics-drivers" [Undecided,New] https://launchpad.net/bugs/1025716
<ubottu> Launchpad bug 1025719 in Ubuntu "[needs-packaging] Package cedarview-vaapi-driver" [Wishlist,New] https://launchpad.net/bugs/1025719
<ubottu> Launchpad bug 1025720 in Ubuntu "Package cedarview-drm" [Undecided,In progress] https://launchpad.net/bugs/1025720
<seb128> slangasek, hey
<seb128> slangasek, I'm updating freetype, how do you make the orig tarball? just copy the 3 upstream .bz2 in a freetype-<version> dir and tar czf that?
<tumbleweed> I thought tarball-in-tarball was dying out :(
<ogra_> cjwatson, dingaling
<ogra_> cjwatson, we're fiddling with arm preseeding over here in lex., is there a way to make partman not show the waring about not being able to install to the install media ?
<ogra_> oh, seems we just found it ... (priority=critical) nevermind
<kwoot> can somebody please tell me how the gtk-bookmarks file is generated/copied upon first login so I can customize my roll-out. A link or pointer works too :-)
<kwoot> anyone? please?
<janimo> cjwatson, sorry I probably meant to subscribe the SRU team not the archive admins on those bugs and also knew that NEW is handled by archive and slipped
<cjwatson> janimo: shall I flip the subscription over to ubuntu-sru on all three, then?
<janimo> cjohnston, they are known about by slangasek and infinity so probably just unsubscribing archive is enough
<janimo> steve has been reviewing them
<cjwatson> Hm, I'll unsubscribe archive then, but I'd prefer not to assume that any one sru team member is on the hook
<cjwatson> So if it's supposed to be an sru team thing then I think I should subscribe sru
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
<smoser> if i have a file "raw-disk.img.tar.gz" which is basically 'dd if=/dev/sda of=raw-disk.img && tar -Sczf raw-disk.img.tar.gz raw-disk.img'
<smoser> what woudl be the fastest way to get that back onto the disk.
<smoser> tar -xvzf raw-disk.img.tar.gz --to-stdout | sudo dd bs=1M of=/dev/vda
<smoser> that works, but slow.
<smoser> as it is writing all the zeros that were sparsed.
<smoser> i know that alexbligh knows this
<smoser> and is probably laughing at me for finally wanting to do it.
<ogra_> smoser, in any case increase the blocksize to something more sane (4M or so at least)
<smoser> well, yeah, but even then, its just a lot of zeros
<stgraber> 1~/win 61
<stgraber> oops
<slangasek> seb128: there's a 'get-orig-source' target in debian/rules that you can use, passing ver= to specify the upstream version
<slangasek> seb128: but why is it urgent to update freetype?
<seb128> slangasek, it's not urgent but I got the merge done and it's ready to upload
<seb128> slangasek, I though it would help, it seems foundation is having an hard time to keep up with merges on Debian and updates...
<seb128> slangasek, is that reason why quantal should be behind Debian testing in versions?
<slangasek> seb128: behind testing, no, but you were asking about new upstream versions of freetype and that's what I was trying to understand
<slangasek> seb128: you're TIL on the freetype package in quantal so I'm happy for you to do the Debian merge... if you're going beyond that I'd like to know why (not to veto it, but to understand what's happening)
<seb128> slangasek, well, we had 2.4.8, Debian has 2.4.9, upstream is 2.4.10, I figured that if I updated it I could as well go to the current version
<seb128> slangasek, what's is happening? nothing special, I just don't get why we wouldn't update to the current stable, we do keep up with current versions for most sources, is that one any special?
<slangasek> seb128: well, you may recall from past discussions that freetype upstream releases do not have a good success rate at being regression-free ;)  but as I said, I'm not trying to veto anything here, just understand the reasons
<seb128> slangasek, we (desktop) also started to push our "use the current versions when it makes sense (i.e when the new versions seem to be an improvement or fixes quite some issues)"
<seb128> slangasek, http://people.canonical.com/~platform/desktop/versions.html has lot of red ;-) (that's our outdated sources for components on the CD)
<slangasek> right, is that why the plymouth bug keeps getting pings :)
<seb128> slangasek, right, robert_ancell has a strong opinion that we should actively maintain the packages we have on the CD, at least by keeping up with upstream updates when possible, he convinced me should do some efforts in this direction (though I would stay away from easy to break and hard to test stuff like plymouth)
<slangasek> yes, there's no way in hell I intend for us to tackle another plymouth merge this late in the cycle because we have no way to regression-test and nobody has pointed me to anything it's known to fix for us
<cjwatson> at least some of the Debian versions on that page are in experimental only ...
<cjwatson> (some for extremely good reasons, e.g. perl)
<seb128> cjwatson, right, currently Debian is a bit difficult to track with the freeze, some maintainer use experimental for things they would usually upload to unstable
<cjwatson> but some are very deliberate :)
<seb128> the page is just an indicator in any case, it shows up things we might not notice otherwise
<seb128> it's not a "must update everything showing up there"
<seb128> ideally we would have an easy way to add comments and all lines should be green or have a rational of why we prefer to not update
<seb128> well at least that's what we aim at for http://people.canonical.com/~platform/desktop/desktop.html (the desktop set)
<ScottK> MoM has comments, although it doesn't look at Experimental.
<jdstrand> seb128: fyi, seems there is a bug in the script: libxml2 is up to date, yet it is yellow
<seb128> ScottK, it doesn't look at upstream versions either I think?
<jdstrand> seb128: oh, actually I lied
<seb128> jdstrand, ;-)
<ScottK> seb128: True, just Debian.
<jdstrand> seb128: I didn't notice we were behind Debian. nm! :)
<seb128> jdstrand, in fact the revision we are behind fixes a CVE
<seb128> http://packages.qa.debian.org/libx/libxml2/news/20120722T130328Z.html
<seb128>    * Fix entities local buffers size problems
<seb128>    CVE-2012-2807, Closes: #679280.
<ubottu> Multiple integer overflows in libxml2, as used in Google Chrome before 20.0.1132.43, on 64-bit Linux platforms allow remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2807)
<seb128> we should maybe merge it ;-)
<seb128> jdstrand, in fact we can sync it, let me build and check it works fine and do that
<Chipzz> smoser: why did you use a tar archive in the first place? plain gzip/bzip2 would have done fine too
<slangasek> Chipzz: because there's no such thing as a sparse gzip file
<Chipzz> slangasek: oh, does tar know about sparse files then? didn't know
<slangasek> yes
<Chipzz> slangasek: but does dd produce sparse files?
<slangasek> no
<Chipzz> then there's no point regardless (assuming he used dd to create the image)
<slangasek> but it's still useful to ensure that the img, if unpacked, doesn't take forever writing zeroes
<slangasek> he didn't
<slangasek> oh, in this case maybe he did :)
<slangasek> (I was assuming this was an official cloud image, which is *not* created with dd)
<Chipzz> mkisofs etc would create sparse files?
<slangasek> but yeah, there's no good way to bypass the extraction of zeroes when it comes time to write it to a disk or any other sort of stream-based operation
<slangasek> cloud images aren't ISOs
<Chipzz> just shows how little I know :)
<utlemming> Chipzz: take a look at cloud-images.ubuntu.com
<utlemming> Chipzz: they are published as qcow2 or tar.gz files generally
<Chipzz> bit disappointing gzip doesn't know about sparse files
<Chipzz> but I suppose since it's been around that long, it's hard to extend the format
<Guest6741> :q
<slangasek> it's not disappointing at all
<slangasek> gzip is the wrong tool
<slangasek> gzip handles streams, not files
<Chipzz> bzip2 handles files if I'm not mistaken though (in the sense that bzip2 archives can be seeked)
<Chipzz> utlemming: but that doesn't say how they're created though
<slangasek> smoser: to your original question, I can't see any way to speed up the copy; you would need tools that were aware of the actual structure of the data in order to skip the sparse sections, which would mean writing a custom tool just for extracting
<utlemming> Cipzz: what do you mean by created? we use live-build to build them
<Chipzz> how the contents of the disk image were put into a file. but I'm reading up on the qcow format now
<utlemming> Chipzz: we build the images using sparse raw file as a loop device. From there, we put a filesystem on it, and then use live-build to populate it.
<utlemming> Chipzz: after that, we convert the sparse raw file to a qcow2 container
<Chipzz> I see :)
<smoser> slangasek, right. and you need to know if the zeros that are in the sparse are necessary to data
<smoser> because skipping writing to a device is going to mean reading that block later will give whatever garbage was there.
<smoser> so yeah, i dont see a really easy way.
<slangasek> smoser: that would be an interesting assumption on the part of some other software if so, since the sparse regions are by definition uninitialized
<smoser> slangasek, clearly not.
<smoser> there exist zeros in your files.
<slangasek> no... there exist uninitialized regions, which are represented as zeroes when read, by convention :-)
<smoser> and if i just ignore all zeros when i copy, and then skip them (leaving whatever was there) when i write, you've lost data.
<slangasek> if you *write* zeroes to a sparse region, it immediately ceases to be sparse
<slangasek> anyway, the conclusion stands - no shortcuts available sorry :)
<MrDHat> If i develop an app using Qt on Fedora will it work on Ubuntu?
<ScottK> It should.
<MrDHat> Do these distro have any specific api's?
<ScottK> In general if you use the standard Qt APIs it should be supportable ~everywhere.
<ScottK> Distros may add things, but it's generally better to develop portable code and only worry about O/S or distro specific stuff as a last resort.
<ogra_> hggdh, https://code.launchpad.net/~ogra/+junk/bamboo-feeder
<scientes> xubuntu-desktop depends nvidia-common WTF is this shit!
<infinity> scientes: That was very constructive feedback.
<scientes> sry
<scientes> its circular with nvidia-installer-cleanup
<scientes> and its conflicts with nvidia-common
<micahg> scientes: that's been fixed for quantal
<micahg> scientes: err...the nvidia depends has been removed I mea
<micahg> *mean
<scientes> ok, thanks
<scientes> i just didn't install that, via manual tweaking in aptitude
<Sarvatt> scientes: installing debian nvidia blob packages on ubuntu is a recipe for disaster, the packages are extremely different (nvidia-installer-cleanup isn't in ubuntu..)
<scientes> Sarvatt, nvidia broke on my hardware shortly before precise, so i have to make sure not to install it
<scientes> (the ubuntu way)
<infinity> Oh look, something is trying to pull half of KDE into main again...
<ogra_> that will make the kde'ers happy :)
<infinity> Looks like appmenu-qt grew a ton of KDE build-deps.
<micahg> Debian had some extra build dependencies that we didn't have
<infinity> "some"
<micahg> maybe they're spurious
<debfx> that package shouldn't have been synced anyway
<infinity> Blame seb.
<infinity> Who isn't around for me to yell at. :P
<micahg> right, it undoes what was done in oneiric to prevent it from pulling in Qt
<infinity> Given that the only meaningful diff is in the changelog and debian/control, I assume just reducing the build-deps again will fix it.
<micahg> infinity: I think you have to add back the shlibs override stuff to get the desired effect
<infinity> Oh, and yes, the odd abuse of dpkg-shlibdeps.
<infinity> micahg: Well, two different desired effects.
<infinity> micahg: One is about pulling QT or not, the other is about pulling KDE into main.
<micahg> the "abuse" is documented :)
<infinity> micahg: The QT thing is obsolete, I think.
<infinity> micahg: In that we used to not have QT in the desktop tasks, but now it's in all of them.
<micahg> Xubuntu doesn't have it
<infinity> (At least, all of the ones that also have appmenu-qt)
<infinity> micahg: See above. :P
<ogra_> well, once we drop unity-2d it will be gone again :P
<scientes> ^
<ogra_> (not that i have seen *any* llvmpipe tests yet)
<micahg> ogra_: no, U1
<ogra_> oh, U1 pulls in Qt ?
<infinity> Yeahp.
<micahg> ogra_: it's written in it now :P
<ogra_> oh, right because they relied on the fact that its there because of unity-2d
 * ogra_ remembers the discussion in orlando
<infinity> I have no issues with QT being on many/most of the desktops anyway.
<infinity> It's just the KDE migration mess here that's annoying.
<infinity> So, if all those build-deps are unnecessary, that's an easy fix.
 * infinity will play.
<micahg> well, if they're really unnecessary, they should be dropped in Debian as well...
<debfx> yes, they are unused
<debfx> I'll fix it in Debian
<infinity> debfx: Oh, lovely.
<infinity> debfx: That would be kdelibs-bin, kdelibs5-dev, and kde-workspace-dev?
<infinity> debfx: (Although, the libx ones may be unnecessary too)
<infinity> I think that's the first time I've used pitti's SVG rendering of component-mismatches instead of the text version.
<infinity> It really does a good job of assigning blame. :P
<debfx> yes, the ones we had in the Ubuntu package - qt4-qmake are enough
<infinity> debfx: Are you going to be uploading that to Debian nowish, so we can sync later?
<infinity> (If not, I'll temporarily fix it in Ubuntu, and we can sync over it when you fix it in Debian)
<debfx> better to fix it in Ubuntu first
<infinity> debfx: Alright, will do right now.
<infinity> debfx: For bonus points, I'll test this in a sid sbuild to make sure it's not somehow broken on Debian, and you can just copy the diff wholesale.
<debfx> hm the package also needs some build flags love
 * ogra_ grumbles in xnox' direction ... seems our pandas suddenly go into an endless loop trying to configure raid
<ogra_> and funnily there isnt even a "go back" option as d-i usually has
<slangasek> using which installer?
<ogra_> d-i
<ogra_> the screen just has yes and no ...
<ogra_> selecting no gets the same screen back up ...
<ogra_> and we're not brave enough to try "yes" :P
<slangasek> quantal?
<ogra_> yup
<infinity> debfx: Uploaded to Ubuntu, and it's all good on sid too, with this diff: http://paste.ubuntu.com/1127941/
<slangasek> what's the exact wording?
<ogra_> hehe, sweet ...
<hggdh> here it is: http://pastebin.ubuntu.com/1127944/
<ogra_> paste coming
 * ogra_ loves our new setup here 
<hggdh> paste above :-)
<slangasek> why are you afraid to choose "Yes"? :)
<infinity> Well, "yes" seems to imply they're then going to configure some RAID, which they may not have wanted.
<infinity> Seems like some odd flowcharting.
<slangasek> I don't know how they got to this prompt
<slangasek> but the worst case with "yes" is that you have to reboot and start over
<slangasek> anyway, I have no idea why you'd be landing at this screen without explicitly selecting raid
<slangasek> (or preseeding it)
<ogra_> well, we're not actually "afraid" its a test system that gets installed over and over anyway ...
<infinity> Though, <no> just repeating the question doesn't seem helpful.  Should probably go back to partman...
<ogra_> though getting this screen is weird, i definiteyl did several installs on this same disk today already
<slangasek> I also don't see that this is xnox's doing
<ogra_> without seeing this message (completely preseeded automatic install, it shouldnt even ask .... we use priority=critical)
<ogra_> infinity, xactly
<slangasek> he's uploaded partman-lvm, but not partman-md
<ogra_> we just had the disk here ... looks normal (std partitioning as defined in the preseed and used in the installations before)
<slangasek> is it reproducible if you reboot?
<ogra_> great, "yes" then gets us to "create a MD device"
<ogra_> but at least there is a go back button now
<ogra_> slangasek, well, not rebooted yet, hggdh is still inspecting from a d-i shell
<slangasek> I think you should reboot
<slangasek> if you can't reproduce it, blame cosmic rays and move on
<ogra_> heh, ok
<hggdh> I am a firm believer in cosmic rays
<debfx> infinity: unfortunately the git repository permissions are wrong so I can't push it
<ogra_> the bad thing is that this device is supposed to install unattended
<infinity> debfx: Well, it's not world-ending in Debian anyway, so when it gets fixed, it gets fixed.
<ogra_> if it hangs like that someone will have to touch it manually
<ogra_> restarting the install (will take 10min until the bamboo-feeder dd'ed the image to sd and rebooted)
<hggdh> d-i started
<ogra_> hmm, this time the partitioner sits at "scanning disks" ... and doesnt seem to move ....
<ogra_> ah, just took a while
<hggdh> cosmic rays
<ogra_> slangasek, ^^^
<ogra_> but its still bad for fully automated installs indeed
<hggdh> and there is still the no way to cancel the raid install
<slangasek> what's still bad?
<ogra_> slangasek, that there can be a case where it asks
<slangasek> a one-time nonreproducible failure really could be a flipped bit somewhere
<hggdh> well, this is actually another problem, and I will try to repeat
<hggdh> (at home)
<ogra_> which will make the whole thing sit there until someone comes and logs in via serial to release it ....
<ogra_> not really helpful for unattented installs ...
<slangasek> well, file a bug against the atmosphere
<hggdh> :-)
<ogra_> LOL
<slangasek> it shouldn't let these ions through to mess up our code :)
<hggdh> slangasek: actually, I agree that going to raid was cosmic rays. What I want to check is if there is, or not, a way to cancel the raid commit
<ogra_> was probably a lack of bamboo in the bamboo-feeder, i guess we need to make sure there is always enough for all pandas
<slangasek> yeah, that part could be a real bug
<hggdh> thanks, folks, we have to disconnect for the shuttle
 * ogra_ packs his toys
 * slangasek waves
#ubuntu-devel 2012-08-04
<Maiz_en_Heces> hi
<Maiz_en_Heces> anybody here?
<slangasek> generally
<Maiz_en_Heces> okay I swear that this has nothing to do with melting niggers or anything perverted
<Maiz_en_Heces> but I have this ap that analyzes photos of diarrhea
<Maiz_en_Heces> and suggests recipes for human consumption
<slangasek> !op Maiz_en_Heces
<Maiz_en_Heces> and sex acts wot involve with it
<slangasek> hmm, what's that command again
<Maiz_en_Heces> how do I add it to Ubuntu's repository?
<slangasek> !ops Maiz_en_Heces
<slangasek> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<Maiz_en_Heces> ooooo
<Maiz_en_Heces> fucking channel emergency
<Maiz_en_Heces> I am trying to get help for my diarrhea foto ap
<Maiz_en_Heces> and you fuckers act like this is the fucking starship enterprise!
<Maiz_en_Heces> booop booop boop
<Maiz_en_Heces> emergency!
<Hobbsee_> !staff
<ubottu> Hey Christel, Corey, Dave2, Fuchs, Gary, Martinp23, Myrtti, Pricey, VorTechS, jayne, marienz, nalioth, niko, nhandler, rob, dax, stew, tomaw, I could use a bit of your time :)
<Maiz_en_Heces> scotty  warp factor 7
<Maiz_en_Heces> sulu 30 degrees starboard
<Maiz_en_Heces> arm photon torpedos
<Maiz_en_Heces> ohhh what a fucking channel emergency
<Maiz_en_Heces> now can I get some help in here
<Maiz_en_Heces> or are you guys going to act like a bunch of faggot trekkies in your mom's basement?
<Maiz_en_Heces> oh  here is captain kirk
<Maiz_en_Heces> taking charge
<Maiz_en_Heces> fuck you jkekkonen
<Hobbsee_> jkekkonen: yes plesae
 * Hobbsee_ curses irssi into the middle of next millenium
<jkekkonen> awww
<Tm_T> I clearly need to reduce the manual work involved on using ircc powah
<Hobbsee> Tm_T: agreed :)
<Hobbsee> and I need to have working configs here, too
<Tm_T> Hobbsee: you have aliases sorted? if not, I can share mine (:
<slangasek> well, I'm simply impressed that !ops managed to summon people who weren't even on the channel at the time ;)
<Hobbsee> Tm_T: cheers, but I think I found the issue
<Hobbsee> slangasek: I got a summon across the house :)
<StevenK> slangasek: That was my fault. :-)
<slangasek> heh
<Tm_T> slangasek: jkekkonen is my evil incarnation, maybe that explains some parts
<Hobbsee> Tm_T: whatever happened to autobleh.pl?  Is it now replaced by ban?
<nigelb> StevenK: Magical summons!
<chu> Tm_T: Mind looking in #ubuntu-server? :p
<Tm_T> Hobbsee: I never used it so I don't know
<Hobbsee> Tm_T: ah, OK
<Tm_T> chu: he's on several other channels too, ignore, and he most likely won't bother at all
<chu> Tm_T: Yeah, but just on the watch (he was initially redirected here after going on about it in #ubuntu too)
<Tm_T> aye, been watching some time now
<chu> Good :)
<slangasek> seriously?  Someone directed him here?  Gee thanks :-P
<Tm_T> slangasek: love must be shared (;
<slangasek> is there a reason he shouldn't be preemptively banned from the remaining #ubuntu-* channels?  Ubuntu folks being the helpful sort, someone is liable to respond to him
<Tm_T> slangasek: we don't tend to preemptively ban except very extreme cases
<Tm_T> or spam waves
<Tm_T> noone's responding to him so he's not doing anything
 * slangasek shrugs. ok
<Tm_T> no bans needed, no escalation (and reward for him) and everybody wins expect him (:
<Tm_T> bans are easy to dodge anyway
<Kalidarn> hey guys could someone take a look at this bug 750437
<ubottu> Launchpad bug 750437 in fglrx-installer (Ubuntu) "fglrx hard lockup on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/750437
<Kalidarn> its been confirmed, its causing major problems, kernel panics, etc.
<Kalidarn> a solution has been found, that is to not use the ubuntu driver, but rather the out-of-kernel one which is more up to date.
<Kalidarn> (which is also confirmed to be a solution by multiple users)
<Kalidarn> #40 which was me discovered the newest drivers fixed the kernel panics, and it has been confirmed by #44 and #45
<Kalidarn> given that ubuntu 12.04 is an LTS version with 5Y support it would be terrible to see this problem plague ATI/AMD users for the next 5 years.
<Kalidarn> the bug is hardly new either, it effects 62 people and was opened on 2011-04-04 after being reported in the forums on the April 3rd, 2011
<Kalidarn> there's also 2 duplicate bugs, its kind of a bit shit it's hung around like a bad smell for this long
<Kalidarn> if there's some reason nothing has been done about it could someone please say so inside the bug so we have a bit of an update.
<kalxas> hi
<kalxas> I am trying to follow https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations for 12.04
<kalxas> I have managed to change the live session user name as described
<kalxas> but I fail to do so with the password and the background image
<kalxas> I am working on this: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_debug.sh
<kalxas> lines 126-144
<kalxas> any ideas?
<shadeslayer> cjwatson: ping
<shadeslayer> cjwatson: I've been trying to build the kubuntu live ISO via live build bit it keeps pulling in unity-2d for some reason and then fails to build the live ISO because unity-2d-common has a postinst script that uses gconf2 which has not been pulled in
<shadeslayer> s/bit/but/
<shadeslayer> what I don't get is .. why is unity-2d-common even pulled in
 * ogra_ wonders if you use the right seeds
<shadeslayer> ogra_: I'm using the default seeds
<shadeslayer> infact, I'm using the examples from livecd-rootfs
<ogra_> for kubuntu-desktop ?
<shadeslayer> yes
<ogra_> well, we also use livecd-rootfs to pull the configs in place, you probably need to have that too
 * ogra_ never tried to build locally since we switched to live-build
<shadeslayer> ogra_: I have that :)
<shadeslayer> that's what I'm using
<shadeslayer> plus : SEEDMIRROR=http://people.canonical.com/~ubuntu-archive/seeds/
<shadeslayer> is what I have in auto/config
<shadeslayer> ogra_: http://paste.ubuntu.com/1128981/
<ogra_> whats the cmdline you use ?
<shadeslayer> ogra_:  sudo -E PROJECT=kubuntu SUITE=quantal ARCH=i386 lb build
<ogra_> i wonder if PROJECT shouldnt be kubuntu-desktop
<shadeslayer> the config file says kubuntu|kubuntu-dvd
<ogra_> k
<shadeslayer> ogra_: http://paste.ubuntu.com/1128989/
<shadeslayer> I've started another clean build to make sure it's not a problem with the command I ran earlier ( I exported the vars earlier and used sudo -E lb build )
<shadeslayer> gah
<shadeslayer> still pulling in unity-2d-common
<shadeslayer> ogra_: http://paste.ubuntu.com/1128999/
<ogra_> well, tat doesnt have a single kde package
<shadeslayer> ogra_: it does, kdelibs
<ogra_> well ...
<ogra_> looks a bit like the config isnt applied or so
<shadeslayer> as well as libkdeui and some other libkde packages
<ogra_> have a look at livecd.sh from livecd-rootfs
<shadeslayer> oh ok
 * shadeslayer looks
<cjwatson> Er, nobody maintains that any more
<shadeslayer> heh
<cjwatson> shadeslayer: Make sure you passed the right environment when running lb config as well as lb build
<shadeslayer> cjwatson: yeah, looking at lb config
<ogra_> (or better at BuildLiveCD)
<shadeslayer> grepping for kubuntu-desktop on config didn't turn up anything earlier
<cjwatson> kubuntu-desktop would be wrong
<ogra_> right, i was mislead there
<cjwatson> anyway, busy now, sorry
<shadeslayer> cjwatson: no no, I mean, grepping for kubuntu-desktop in the config *folder*
<shadeslayer> sure
 * shadeslayer will keep experimenting
<cjwatson> make sure to run lb clean if you're changing the config
<shadeslayer> yep, I do that :)
<cjwatson> actually not sure clean removes the config directory, check
<shadeslayer> no it doesn't
<ogra_> BuildLiveCD does that before running live-build it seems
<ogra_> $LINUX32 sudo chroot ${DIR%/./*} sh -c "cd /${DIR#*/./} && rm -rf auto && mkdir -p auto && for f in config build clean; do ln -s /usr/shar
<ogra_> e/livecd-rootfs/live-build/auto/\$f auto/; done" >> ${LOG} 2>&1 || true
<ogra_> and then
<ogra_> $LINUX32 sudo chroot ${DIR%/./*} sh -c "cd /${DIR#*/./} && lb clean --purge" >> ${LOG} 2>&1 || true
<shadeslayer> weird
<shadeslayer> I see : rm -rf config
<shadeslayer> in auto/clean
<ogra_> COMMAND="PROJECT=${FS} SUBPROJECT=${SUBPROJECT} ARCH=${ARCH} SUBARCH=${SUBARCH} lb build"
<ogra_> and that seems to be the actual build command
<shadeslayer> what if I don't define a subproject and a subarch?
<shadeslayer> ( and it's *still* pulling in unity :| )
<shadeslayer> ogra_: any ideas what variables are needed to run BuildLiveCD properly?
<bipul> hi shadeslayer
<shadeslayer> hi bipul
<bipul> shadeslayer,  pm
<shadeslayer> ok
<cjohnston> micahg: what ever happened to getting the Chromium PPA's back up and going?
<infinity> TheMuso: Where's the MIR for liblouis?
<infinity> TheMuso: (You made it a gnome-orca build-dep, but it's in universe)
#ubuntu-devel 2012-08-05
<olebarrera> I was looking for a bit of understanding using jscal
<olebarrera> it seems I am not getting button events in my code and I was wondering if someone could point me in the right direction
<olebarrera> http://pastebin.com/xAWuAW88
<olebarrera> no takers
<olebarrera> never mind it seems lsub -v seemed to work
<olebarrera> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/500834
<ubottu> Launchpad bug 500834 in linux (Ubuntu) "CH joysticks not working" [Undecided,Incomplete]
<olebarrera> ok it seems I have a work around
<olebarrera> I use these joysticks all the time for things any suggestions on how to programatically make it work when its plugged in
<Chipzz> olebarrera: I don't know what jscal is offhand, but it sounds like a web library
<olebarrera> its just a tool to calibrate the joystick
<Chipzz> olebarrera: there are no takers because a) if it is, that would be app development (not even), and that is very much off-topic here (cfr topic), and b) it's weekend, and all the devs are absent
<olebarrera> well I was not so concerned with the calibration just why the events from the driver where not being seen
<olebarrera> <Chipzz> thanks for the feedback
<Chipzz> olebarrera: also a small suggestion: make it clearer what the question is about asap (ie in your first few sentences), so ppl know what you're talking about
<Chipzz> I just read the first couple of sentences of what you typed
<olebarrera> Its been a long time since I used IRC
<olebarrera> I figure I would give it a shot cause I was stuck
<Chipzz> the same could be said about RL conversations though
<Chipzz> if you want ppls attention, draw it as quick as possible
<olebarrera> Yes sir this is true,
<Chipzz> no sir needed :)
<olebarrera> Do you know much about the events provided by the driver
<Chipzz> afraid not
<olebarrera> joydev is the module loaded
<olebarrera> well thanks for the feedback it seems I am getting output from the code after running lsub -v
<Chipzz> you *could* try to ask on #ubuntu-kernel, although I'm not sure how on-topic it would be there
<olebarrera> I will check with the kernel dev internal on monday see if they have a fix
<Chipzz> but if you ask there, make sure to make it clear from the start joystick events are not getting through, and keep in mind it's weekend for the ppl there too
<olebarrera> I will also read up on IRC comms again so as not to offend
<Chipzz> offend.. heh :)
<Chipzz> reading the channel topic before talking is always a good idea :)
<Chipzz> but at least you're making an effort it looks ;)
<olebarrera> thanks have a nice night
<Chipzz> you too :)
<micahg> cjohnston: when I'm done with my current project, shall I add you to the list of people who want to help maintain it?
<wzssyqa> how to bump kernel abi?
<goddard> how can I intergrate the ubuntu colors in a menu toolbar in qt?
<cjohnston> micahg: sure
<codemaniac> hello world
<codemaniac> can i use a debian box as a ubuntu development platform ?
<codemaniac> installing all the development toolbox in the mentined debian box ?
<penguin42> codemaniac: Have a look at pbuilder
<codemaniac> thanks penguin42
<kalxas> hi all
<kalxas> I am trying to follow https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations for 12.04
<kalxas> I have managed to change the live session user name as described
<kalxas> but I fail to do so with the password and the background image
<kalxas> I am working on this: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot.sh
<kalxas> any ideas?
<TheMuso> infinity: It used to be in main.
<TheMuso> infinity: But was dropped due to no python 3 support at the time when Orca was switched to python 3.
<scientes> whats the rules on python shebangs and python versions?
<scientes> does something that only works with python2 have to use /usr/bin/python2 ?
<scientes> (and can python 3 provide /usr/bin/python)
#ubuntu-devel 2013-07-29
<pitti> doko_: ./configure has an --enable-numpy option, so it looks like it just relies on p-numpy-dbg already depending on p-numpy
<pitti> Good morning
<dholbach> good morning
<didrocks> cjwatson: FYI, killed the cache on lillypilly
<didrocks> slangasek: FYI, settings with system update published, in -proposed right now
<slangasek> didrocks: sw33t \o/
 * ogra_ hopes we'll soon get Mir and lightdm so we can finally switch to ti 
<ogra_> *it
<ogra_> (it = system updates)
<slangasek> ogra_: how are Mir+lightdm related to this?
<ogra_> slangasek, missing logind blocks a lot of features
<slangasek> ogra_: "a lot of features" but not image-based updates AFAIK
<ogra_> and logind integration will only come with lightdm ... which sill only come with Mir
<ogra_> slangasek, no, but properly working click packages without hacks :)
<slangasek> ah, fair
<ogra_> if we woould just switch we would have to ship with developer mode enabled by default .... which defeats the purpose
<ogra_> it is MIr+lightdm -> system images  -> system partitions .... DONE :)
<slangasek> ogra_: it doesn't defeat the purpose; it still improves code consolidation even if we're not able to turn it on by default yet
<slangasek> we won't block delivering system updates on Mir+lightdm
<ogra_> hmm
<mpt> ev, had you noticed the error rate graph has gone blank?
<ev> mpt: yes. We're had to suspend the existing database and move to a new one. We'll merge the two once everything is settled, but until then the only data on errors.u.c is from Thursday onward
<ev> I'll send out an annoucement to ~error-tracker-access
<mpt> ev, how long will the merging take?
<ev> mpt: I don't have an accurate estimate for that. We're not out of the woods on fixing the old database.
<mpt> ev, in that case, maybe put a notice on the front page itself, not just on a mailing list
<ev> will do
<mpt> :)
<ev> seb128, Laney: if either of you have time for a small merge: https://code.launchpad.net/~ev/ubuntu-system-settings/automatic-error-reporting/+merge/177348
<Laney> ev: sure
<Laney> ev: did you do anything about polkit prompting in 0.9?
<ev> Laney: it's on my todo list for today
<Laney> cool
<ev> Could I have the eyes of another core dev on this one: https://code.launchpad.net/~ev/ubuntu-seeds/ubuntu-touch.saucy-error-reporting/+merge/177363 (adds whoopsie and apport to Touch)
<xnox> ev: what is /etc/apport/autoreport a config-file, a conf-file, or a stamp?
<ev> xnox: stamp
<xnox> ev: syntatically the merge proposal looks correct =)
<ev> whoop :)
<infinity> I'm trying to decide if we want the new shiny dpkg or if the changeset scares the crap out of me and I should wait for a week or so for it to cook in Debian.
<jpds> infinity: Both.
<infinity> Heh.
<infinity> Yeah, there are definitely things in here we want (potentially even need), but I think I'll let it simmer a bit.
<ogra_> infinity, the future is click anyway, just leave it idle :P
<cjwatson> Click doesn't replace dpkg </knee-jerk>
 * mitya57 wants xz compression by default (new dpkg has it)
<xnox> infinity: i wanted xz by default since Maverick =)
<infinity> Heh, yeah, I know a few people are waiting for that. :P
<infinity> I'm also happy about the dpkg-shlibdeps/LD_LIBRARY_PATH changes, though that won't be useful until debhelper changes to match.
<Mirv> "On the upload and publication side, we made upload processing run every
<Mirv> minute rather than every five minutes" - hurray!
<infinity> It's always the little things that make people happy. :)
<pitti> jibel: ah, the new libgphoto breaks umockdev's autopkgtest; the reason why this wasn't caught in -proposed is that umockdev doesn't directly depend on libgphoto2, but on gphoto2 which then depends on libgphoto2, right?
<pitti> jibel: i. e. we only consider direct dependencies, not transitive ones?
<cjwatson> pitti: it's true that we only currently consider direct dependencies
<pitti> cjwatson: ok, thanks for confirming
<pitti> it's not a biggie in this case, I just want to understand what's going oin
<pitti> on
<infinity> Do we plan at some point to do away with the public/private mess on excuses and actually give people without Canonical QA VPN access the ability to see tests in progress?
<infinity> I'm always suspicious that "running" actually means "broken".
<infinity> Especially in the case of things like the linux test that's been running all weekend. :P
<infinity> pitti, jibel, cjwatson: ^
<cjwatson> I'd love to but don't have the power.
<pitti> infinity: I'm afraid I don't know; that's a question for retoaded and the lab admins
<infinity> Sure, I was more curious if you knew of such a plan, not if you were going to execute it. :)
<cjwatson> And yes, that does appear to mean "broken".
<cjwatson> ld: final link failed: No space left on device
<pitti> infinity: we should at least allow everyone in Canonical (especially the release team) VPN access
<infinity> Okay, same failure as always.
<infinity> cjwatson: I've hinted past that one, as I always do.
<cjwatson> But you can see that on the public instance too.
<cjwatson> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-linux/ARCH=amd64,label=adt/70/console
<infinity> cjwatson: Wondering if the "running" eglibc and quagga ones are equally broken.
<pitti> and I don't think it's particularly restricted, it's mostly just asking for it AFAIK
<cjwatson> infinity: eglibc appears to be genuinely in its test suite.
<pitti> there is not currently a running quagga test
<pitti> there *is* a running eglibc test
<infinity> cjwatson: Kay, so eglibc is just slow.  Check. :P
<cjwatson> quagga finished fairly recently so maybe it'll catch up next run.
<cjwatson> Though, an hour ago
<rickspencer3> hey hey
<rickspencer3> starting again
<cjwatson> infinity: I think there are still some bugs in adt-britney collect.  They're hard for me to interpret
<rickspencer3> oops, wrong channel ;)
<pitti> hey rickspencer3
<rickspencer3> hi pitti
<infinity> Sure, no rush, this is conveniently all slotting into the time while armhf is building, as engineered.
<infinity> rickspencer3: Guten Tag und Schtuff.
<rickspencer3> hi infinity
<rickspencer3> I'm actually on the IoM atm
<rickspencer3> but, yeah
<rickspencer3> das is dein sprint
<infinity> I don't speak Manx, you'll have to suffer with faux German.
<pitti> hm, the failing autopkgtest is actually right -- gphoto2 --auto-detect indeed does pollute stderr with tons of libusbx output
<pitti> why do we have libusb debugging on by default now?
 * pitti digs
<infinity> cjwatson: I was, frankly, pretty shocked to see only 19 tests spin out of the eglibc upload anyway.  Either our test coverage is awful, or we're not doing a good job finding rdeps.
<infinity> cjwatson: (Well, I know our coverage is awful, but I didn't think it was THAT bad)
<pitti> infinity: I guess that might again be due to not doing transitive deps?
<infinity> pitti: Transitive shouldn't really matter here.  Everything and its dog depends on libc6.
<cjwatson> infinity: Does seem a bit low.
<infinity> pitti: (At least, every C and C++ project, that is)
<infinity> Maybe all our tests are in python projects. :P
<pitti> we do have a lot of GI and python stuff, but we should have way more than 19 C-ish tests
<cjwatson> Certainly a lot of them are
<pitti> infinity: "Jenkins Fixed - saucy-adt-eglibc 42"
<pitti> infinity: thanks!
<infinity> pitti: \o/
<infinity> pitti: I was holding my breath, waiting for it to pass.
<infinity> cjwatson: Yeah, I think the collection on quagga is "stuck".  eglibc went from running to passed, but quagga's still running.
<cjwatson> infinity: I think it sometimes gets confused when different architectures' results come in at enough-different times, but I'm not sure
<cjwatson> Hoping jibel can investigate
<pitti> didrocks: as oneconf is one of the two broken tests that currently block pygobject: are you still interested in this in the least, or should I just drop the XS-Testsuite: for the time being?
<jibel> last run of quagga 0.99.22.1-1ubuntu1 passed, I haven't yet investigated why it is still marked running
<smoser> hey.. http://paste.ubuntu.com/5925348/
<smoser> anyone have a better way to get "time that /sbin/init was started"
<smoser> as that pastebin doens't make any sense to me. it seems like static-network-up-emitted was created before init was started
<smoser> by .15 seconds.
<stgraber> smoser: static-network-up is emitted right after ifupdown returns which usually means right after ntpdate was called and updated the system time
<smoser> bah
<smoser> so if i have ntpdate installed
<smoser> i can't trust timestmaps on files
<slangasek> smoser: "time that /sbin/init was started" - do what ps does when walking /proc?
<stgraber> you can trust them after ntpdate ran, but anything before that may have an incaccurate timestamp
<smoser> funny. but you can't realistically know when ntpdate ran.
<stgraber> (unless you look at the kernel log buffer which uses ms since kernel startup as timestamp)
<smoser> yeah, but the info i'm interested in isnt there.
<smoser> slangasek, what time in ps were you talking aobut?
<pitti> jibel, cjwatson: hm, so my libgphoto2 fix is now held by the failing gvfs, but the Debian sync that broke it in the first place went through even though gvfs was already failing at that time
<smoser> duh. start_time.
<smoser> hah.
<pitti> jibel: do we perhaps not cover all rdepends sometimes?
<pitti> or was that overwritten by u-release somehow?
<slangasek> smoser: yep :)  I don't see offhand where in /proc that comes from, but the ps source would say
<smoser> oh well.
<smoser> so maybe i'll explain problem and see if others could give better way to solve.
<smoser> i'm looking to  just print a report of certain events and when they occurred. and then ideally map that to a utc timestamp, and want at least millisecond level granularity.
<smoser> the events i'm looking for are at least "kernel load time", "init executed", "network up", and then some from cloud-init. cloud-init log has timestamps that i can get at.
<slangasek> smoser: you could also examine what bootchart does; it knows when we switch from initramfs to rootfs, etc
<kirkland> smoser: you could cross reference with dmesg, which has microsecond granularity since boot;  find a couple of common events and then map/reduce those together
<smoser> but not if those events are not in dmesg.
<smoser> hm.. so nothing "easy". well, thanks for thoughts.
<mterry> slangasek, regarding the MIR email, if there are multiple teams subscribed to a bug, how does errors.ubuntu.com know which is the "owning" team?  (you intimated it has such a concept)
<roaksoax> mterry: o/! So to speed up things, we do have WI's to write dep8 tests for all the cluster stuff, and will definitely work on enabling the crmsh ones, but it is not something I'm can take care of right now
<mterry> roaksoax, are the WIs for 13.10 timeframe?
<roaksoax> mterry: yes
<mterry> roaksoax, k
<infinity> gdb Depends: gdbserver seems suboptimal...
<slangasek> mterry: shared ownership, which is valid and allowed :)
<slangasek> mterry: so it shows up on the list for earch team
<mterry> roaksoax, I created a bug for tracking purposes, and assigned you.  Feel free to reassign
<slangasek> each
<mterry> slangasek, ah OK.  :)
<roaksoax> mterry: awesome! thanks!
<doko> TheMuso, ping about #1196967
<jbicha> Riddell: could we get a rebuild of kdeplasma-addons for the ibus transition?
<Riddell> jbicha: yeah can do
<infinity> Riddell: I was just about to commit and upload, don't sweat it.
<Riddell> infinity: thanks
<infinity> (Well, after a test build)
<smoser> i'd like someone's thoughts on https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1206164
<ubottu> Ubuntu bug 1206164 in ntp (Ubuntu) "/etc/network/if-up.d/ntpdate does not detach correctly" [Undecided,New]
<ev> uhm, is it intentional that the running application in Touch consumes all the input, regardless of its state? If launch the gallery app, then do a kill -STOP $(pidof gallery-app), I have no way out (until I kill with -CONT)
<ev> taking this to the appropriate channel
<didrocks> pitti: barry introduced those tests as AP tests, it seems they never passed, I don't have the time to fix them TBH so dropping seems good
<didrocks> pitti: I should find why this new ugettext crash thoughâ¦
<barry> pitti, didrocks which tests?
<didrocks> barry: the oneconf autopkg tests, pitti told they never passed
<barry> didrocks: darn
<barry> didrocks, pitti let me try that locally
<didrocks> barry: thanks!
<mhall119> kenvandine: want to package Poppler 0.24 for me?
<mhall119> pretty please?
<seb128> mhall119, I'm doing poppler packaging, why do you need it?
<mhall119> seb128: the docviewer core apps wants to start using it for PDFs
<seb128> mhall119, they need the new version?
<mhall119> seb128: didn't want to ping you, since it's after-hours
<mhall119> seb128: yeah, because it has the Qt5 support
<seb128> mhall119, nice!
<seb128> mhall119, oh, they turned that serie stable, yeah, no problem to update
<mhall119> cool
<seb128> mhall119, I can look at that tomorrow
<mhall119> thanks seb128!
<seb128> yw
<Laney> transition time? :-)
<infinity> Oh joy, I just *love* poppler transitions.
<kenvandine> seb128, thanks... glad you can do that for mhall119 :)
<Laney> That's why they gave you the +1-maint crown. :P
<seb128> Laney, looks like another of those ;-)
 * kenvandine has compiled this plugin soooo many times on the phone... this time has to be the one!
<infinity> kenvandine: I think you just jinxed it.
<kenvandine> hehe
<infinity> kenvandine: This is the build where you phone bursts into song, starts twirling around on your desk, and then sets itself on fire.
<infinity> s/you/your/
<kenvandine> nope, it worked :)
<infinity> Yeah, or that.
<infinity> I always get those two outcomes mixed up.
<kenvandine> seb128, i have it displaying those services from the SIM :)
<kenvandine> infinity, hehe :)
<seb128> kenvandine, \o/
 * kenvandine should have never tried exposing the QMap to QML... that is a disaster
<seb128> kenvandine, did you end up wrapping the qt api?
<kenvandine> yeah
<ogra_> oh oh ... all your secrets exposed
<seb128> kenvandine, do you add that to qtsystems?
<Laney> the SIM services stuff in phone?
<seb128> Laney, yes
<Laney> that's exciting
<kenvandine> seb128, no...
<Laney> I didn't know we had some API for that already
<kenvandine> private plugin in system-settings
<seb128> Laney, ofono has one and qt bindings
<kenvandine> Laney, ofono-qt has it
<Laney> nice
<Laney> go go settings which work
<seb128> kenvandine, that wfm, but ideally we would add it to qtsystems, since they already have a ofono wrapper and that's where we get the imei etc
<seb128> Laney, speaking of which I've moved the ringtone etc settings to the shared schemas, if you approve the mr today I can make system settings and phone app use those keys tomorrow
<seb128> hint hint hint ;-)
<Laney> seb128: OK, I can do a schema one but not qml stuff now
<kenvandine> seb128, are we already patching qtsystems?
<Laney> upstream it?
<kenvandine> Laney, of course :)
<Laney> :P
<kenvandine> but i am wondering what our current delta is
<seb128> kenvandine, we don't have one, but loicm is assigned work to a platform backend for Ubuntu afaik
<seb128> kenvandine, check with pat maybe
<seb128> or Mirv might know
<kenvandine> seb128, oh, qtsystems5 wraps the ofono dbus API
<kenvandine> not libofono-qt
<kenvandine> that seems suboptimal
<kenvandine> ls
<Laney> . ..
<kenvandine> whoops :)
<seb128> kenvandine, yeah, well it works... ;-)
<chiluk> Daviey jdstrand   can I get some SRU love on  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1179781 ?
<ubottu> Ubuntu bug 1179781 in curl (Ubuntu) "If-Modfied-Since undhandled case causes apt lists corruption with https repositories" [Undecided,In progress]
<chiluk> comments #4 and #5 have debdiffs waiting for upload.
<Daviey> chiluk: if nobody beats me, i'll take a look tomorrow morning.  Too tired to look now.
<chiluk> awesome thanks..
<chiluk> Daviey you were the patch pilot for today right?
<chiluk> I'll add you on copy just in case
<smoser> anyone python3 friendly have ideas ?
<smoser> http://paste.ubuntu.com/5926783/
<cjwatson> smoser: You haven't set func to anything - no set_defaults calls
<cjwatson> Perhaps that's relevant?
<Snow-Man> argh.  ipv6 down *again*? :(
<cjwatson> Snow-Man: If this is about a Canonical service, I doubt most people in this channel will have a clue how to help.  #canonical-sysadmin is more likely to stand a chance.
#ubuntu-devel 2013-07-30
<pitti> barry: any luck with oneconf?
<pitti> Good morning
<dholbach> good morning
<pitti> who maintains bzr these days?
<dholbach> pitti, asomething did a few uploads to Debian and we synced/merged from there AFAIK
<pitti> its test_gpg.py bits fail with "pgmeError: (7, 150, u'Invalid crypto engine')", I guess that needs some actual domain knowledge
<pitti> jelmer: ^ would you have an idea why this happens?
<geser> pitti: see also bug #1196253 (same error message) but no solution
<ubottu> bug 1196253 in nautilus-dropbox (Ubuntu) "can't install nautilus-dropbox: GpgmeError: Invalid crypto engine" [Undecided,Confirmed] https://launchpad.net/bugs/1196253
<pitti> geser: right, dholbach pointed that out, too; so that smells like a bug/missing dependency of libgpgme
<pitti> could be fallout from https://launchpad.net/ubuntu/+source/gpgme1.0/1.4.2-0.1ubuntu2
<geser> pitti: sounds very likely as the build log contains: "GnuPG path:      /usr/bin/gpg2". And if then gnupg2 is not installed it could produce the error you see (did you have gnupg2 installed or not?)
<pitti> geser: not sure, some dependency might pull it in
<pitti> geser: which build log did you look at?
<geser> pitti: https://launchpadlibrarian.net/143289079/buildlog_ubuntu-saucy-amd64.gpgme1.0_1.4.2-0.1ubuntu2_UPLOADING.txt.gz
<pitti> geser: oh, build-depends gnupg2
<geser> it was from "GPGME v1.4.2 has been configured as follows:" after the configure run
<pitti> so we'll need to flip that as well
<geser> looks like the gnupg version (gnupg or gnupg2) has to match in build-depends and depends
<pitti> geser: hah, I get the same error when calling "seahorse"
<pitti> so nice, this pointed out an actual regression then
<pitti> seb128: ^ FYI, in case you stumble over a searhorse bug that it doesn't show gpg any more
<seb128> pitti, thanks
<pitti> seb128: do we actually need the "gnupg | gnupg2"? seems we can only build it against either
<Laney> wasn't it a dep chain thing?
<pitti> ah, KDE once added gpg2 support
<pitti> it might actually be enought to add back a gnupg build dep to support both, I'll try that now
<pitti> http://launchpadlibrarian.net/24055413/gpgme1.0_1.1.8-2ubuntu1_1.1.8-2ubuntu2.diff.gz
<pitti> was the original change
<seb128> pitti, I don't really know, that was there before I touched that stack
<pitti> seb128: right, I think I know what to do
<seb128> pitti, good
<pitti> jelmer: unping, I uplaoded a fixed gpgme1.0
<pitti> barry: FYI, I uploaded oneconf with dropping the XS-Testsuite header, so that this will stop being run in jenkins and block propagation
<jdoles> Why doesn't this demo work on Ubuntu? https://github.com/juneym/php-gettext-demo (clone it, follow the instructions, which involve only generating a locale, and run php index.php).
<sladen> jdoles: it's quite broad; a bit like "why doesn't my computer work".  What is the specific command you run that fails, and the specific error message you get when you run that command (the reason to lead you to believe that it is not working as intended)
<sladen> jdoles: with that, the best is to search for the same error message, and if not found to find a report in Launchpad, so that people who know the software in question can have a look
<jdoles> sladen: it's like 10 lines of code...
<jdoles> sladen: and I didn't write it.
<jdoles> sladen: I do think it *should* work.
<jdoles> sladen: it's *trivial* to reproduce.
<jdoles> sladen: it takes like 1 whole minute.
<jdoles> sladen: so, you could have reproduced it 4 times already.
<jdoles> sladen: and I just verified that it does work on Debian Wheezy.
<pitti> Laney: can you please do the magic to allow oneconf 0.3.4 to propagate? I remove its broken autopkgtest
<Laney> pitti: still needs hitting in that case?
<jdoles> Is there anyone remotely intelligent here?
<Laney> pitti: (will do, but it'd be good to get that bug fixed)
<sladen> jdoles: yes, what makes you believe that /it is not working/
<jdoles> sladen: I run it and I see no translation.
<sladen> jdoles: riiight
<jdoles> sladen: I do the same on Debian and it does.
<cjwatson> jdoles: Works fine provided you follow the instructions on the page to generate the locales
<jdoles> cjwatson: that's what you say.
<jdoles> cjwatson: I did follow the instructions.
<cjwatson> jdoles: Because I just tested it ...
<jdoles> cjwatson: on Ubuntu 12.04 LTS?
<cjwatson> (Note that you need to generate en_US.UTF-8 as well)
<jdoles> cjwatson: I already had that one.
<cjwatson> Happy to try that but you'll need to wait a moment.
<Laney> pitti: (done)
<jdoles> sladen: can you also perhaps keep your arrogant mouth shut? You have not _at_all_ proven to have any problem solving capability.
<cjwatson> jdoles: It's also possible that you have LC_ALL set in your environment, which would override LC_MESSAGES.
<jdoles> cjwatson: no, that's not possible.
<cjwatson> jdoles: (However, please stop being abusive.)
<jdoles> cjwatson: because I unset LC_ALL.
<sladen> jdoles: having replicated that on 12.04.2, I /don't/ get translationed messages with the default config
<pitti> Laney: thanks
<jdoles> sladen: so, that would mean you are seeing the same bug.
<cjwatson> jdoles: Works for me on precise.
<cjwatson> jdoles: Proof: http://paste.ubuntu.com/5928494/
<cjwatson> That's an entirely clean precise environment
<sladen> jdoles: concur.  Remember that context is needed; when code runs (executes) it may not be immediately apparent what is different to normal.  The crucial information here is that a japanese message should be appearing
<jdoles> cjwatson: I think the main problem is that it also silently fails.
<jdoles> cjwatson: but that is more of a PHP problem and not related to packaging.
<cjwatson> Well, the C-level gettext interface is a bit like that; it prefers issuing untranslated text rather than errors.
<jdoles> A rather stupid design.
<cjwatson> No, it makes sense for its problem domain.
<jdoles> It should log to a file when there is a problem.
<cjwatson> Packages are often only partially translated.
<jdoles> Or to some socket or configurable.
<cjwatson> It's still not remotely clear what's happening in your case.  strace might help.
<jdoles> Silently failing is a design flaw for any component.
<sladen> not necessarily if you are a webpage generator
<cjwatson> setlocale does produce errors, which no doubt it's possible to get PHP's gettext interface to not ignore.
<sladen> (however a choice of when to error is something that would be better raised with the authors of PHP)
<jdoles> cjwatson: strace shows useful information.
<cjwatson> Can you share it?
<jdoles> Now it works :/
<jdoles> Let me see whether I do know the cause now.
<jdoles> If so, there is a dependency error in Ubuntu packaging.
<sladen> jdoles: did you apt-get install php-gettext ?
<sladen> jdoles: (I did this, and found no change)
<slangasek> if he hadn't, php should've given errors immediately about undeclared functions
<jdoles> sladen: yes, I did, but that doesn't make a difference.
<jdoles> It does work now, but I don't recall me doing anything which should have caused that.
<cjwatson> I slightly question whether this can be a dependency error given that my paste shows it working in a clean chroot with nothing beyond php5-cli (and, admittedly, git); but perhaps details will help
<jdoles> I did do apt-get install php-gettext and removed it again.
<cjwatson> php-gettext was not installed in my environment at any point
<jdoles> Before that command it didn't work, after the installation it did, and after the removal it also did.
<jdoles> cjwatson: I think we will never know what caused it.
<cjwatson> My best suggestion is to try to reproduce in a clean environment, perhaps by iteratively bringing such a thing closer to your real environment.
<sladen> now I
<slangasek> ah; yes, the php-gettext package bypasses C gettext, yuck
<cjwatson> mk-sbuild + schroot + overlayfs makes throwaway chroots pretty trivial to use.
<jdoles> cjwatson: how fast does that command run and does it cache downloads?
<jdoles> cjwatson: (and on what hardware)
<cjwatson> mk-sbuild runs debootstrap under the hood, so it takes a while depending on your connection.  Downloads can be cached by setting up schroot to mount a persistent filesystem location onto /var/cache/apt/archives/ inside the chroot, although I think most people don't bother and just use either a local mirror or an apt proxy.
<cjwatson> I ran the command I pasted while talking to you so you can infer it only takes minutes.  Reasonable laptop, nothing special, doesn't particularly take much out of the host hardware.
<cjwatson> (mk-sbuild only needs to be run once for a given release/architecture combination, and then you just occasionally update it with sbuild-update.)
<sladen> right,   LANGUAGE="" php index.php  works; anything else doesn't
<cjwatson> LANGUAGE overrides LC_MESSAGES, as documented by gettext
<cjwatson> Indeed, LANGUAGE even overrides LC_ALL for the purposes of the messages category
<sladen> jdoles:  set | grep LANGUAGE
<sladen> which I presume is coming from /etc/default/locale
<sladen> which I have dated 2011-12-15 (ie. early in the development cycle).  cjwatson: is that not now set on later installs?
<slangasek> well, the above test was with a chroot that wouldn't have used the installer
<cjwatson> Whether it's set depends on the details of the installation.
<cjwatson> In any case, if you want to override LC_MESSAGES and guarantee that to be effective then in general you must unset LC_ALL and LANGUAGE.
<cjwatson> So I'd class that as a bug in this demo script.
<cjwatson> Even if it happens, by luck, to work in some environments.
 * slangasek nods
<infinity> I'd say that script assumes your server runs in C.
<infinity> Which isn't an unfair assumption, but still not a safe one.
<sladen> jdoles: I've pushed a fixed version to github, and sent a pull request:  https://github.com/juneym/php-gettext-demo/pull/1
<pitti> ev: does whoopsie write a log file by default? I can't find one in /var/log/
<pitti> ev: I have two crash reports with .upload tags, but they apparently don't get uploaded
<sladen> cjwatson: done, with added --author kudos
<cjwatson> ta
<pitti> ev: I stopped whoopsie, and ran "sudo CRASH_DB_URL=https://daisy.ubuntu.com whoopsie -f", but that's also not picking up the two *.crash/*.upload files?
<pitti> ev: oh, it actually does pick them up, just doesn't tell me about them
<pitti> cjwatson, jibel: how can adt-britney be poked to reconsider pygobject? the failing oneconf test was removed (in the archive and private jenkins); does it need to be removed from the public jenkins instance first (that needs retoaded), or does it just need a nudge?
<cjwatson> Public Jenkins instance doesn't matter.
<cjwatson> Not sure what the most-correct way to deal with the rest is (we could force it, but maybe that isn't optimal).  Needs jibel
<pitti> cjwatson: I guess I could just reupload the package, I was just curious whether there's a cheaper way
<pitti> cjwatson: thanks, will ask jibel
<cjwatson> Certainly don't reupload
<jibel> pitti, no really cheap way, I can resubmit a test manually to avoid an upload
<cjwatson> *A* cheaper way is to have a member of ~ubuntu-release force it, but on general principles I'd prefer to see if it's fixable in the code
<cjwatson> jibel: There's no test to resubmit
<cjwatson> Since this is a matter of a test being removed and adt-britney incorrectly not noticing
<pitti> jibel: all rdepends tests succeeded except oneconf, whose test just got removed (that's in saucy now)
<jibel> ah right, that'd mean forcing a pass on oneconf or removing the entry from the history
<Mirv> is it intentional https://lists.ubuntu.com/archives/saucy-changes/2013-July/thread.html seems stalled since last week's Monday?
<Laney> no, but known
<cjwatson> jibel: adt-britney can't detect that it no longer has an XS-Testsuite: autopkgtest?
<ev> pitti: it's not very verbose by default, but what logging it does goes into /var/log/upstart/whoopsie.log
<cjwatson> jibel: I don't mind forcing the odd one, but this has happened a couple of times now so chances are we'll miss some
<ev> pitti: feel free to add and commit any additional log statements you
<ev> ned
<ev> need even
<pitti> jibel: I guess it needs some brain surgery in its state files?
<pitti> ev: that just says "Using lock path: /var/lock/whoopsie/lock", nothign about uploading or checking files?
<cjwatson> jibel: If you can suggest where I need to perform surgery, I can attempt it
<ev> pitti: hmm, it *should* be logging more than that. whoopsie.c has a nonzero number of printf statements in it.
<ev> so maybe it hasn't actually processed them for some reason
<jibel> cjwatson, you can remove the line "oneconf 0.3.3 FAIL pygobject 3.9.5-0ubuntu1" from proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/work/results.history
<cjwatson> jibel: Done, thanks
<cjwatson> (Oops, p-m was running, hopefully I didn't confuse it)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<cjwatson> $ head -n1 /home/ubuntu-archive/proposed-migration/var/data-b2/output/Delta
<cjwatson> pygobject 3.9.5-0ubuntu1
<cjwatson> evidently not too badly
<cjwatson> pitti: done
<cjwatson> jibel: thanks
<darkxst> dholbach, are you able to look at gjs update on NEW queue?
<dholbach> darkxst, I'm sorry, I'm not an archive admin
<dholbach> but somebody of these folks (https://launchpad.net/~ubuntu-archive/+members) might be able to help you out
<darkxst> dholbach, ok
<infinity> I'll give it a jab.
<darkxst> infinity, thanks
<infinity> darkxst: No plan for libgjs to actually get a real SOVER? :P
<infinity> Package: libgjs0d
<infinity> Replaces: libgjs0, libgjs0a, libgjs0b, libgjs0c
<infinity> -rw-r--r-- root/root    209784 2013-07-30 00:40 ./usr/lib/libgjs.so.0.0.0
<infinity> This seems to be a house of cards.
<infinity> But, a well-established one, at least.
<infinity> darkxst: Accepted.  If you can ever convince upstream to use sane so versions, that would be nice.
<darkxst> infinity, I was just following the tradition (from debian)
<infinity> darkxst: Yeah, I'm not arguing you were doing anything wrong there (nor has Debian, really, this sort of abuse is what an SOVER of 0 is meant for), but it still would be nice if people just versioned the library. :P
<infinity> darkxst: Of course, that depends on how many rdeps it has.  If it's always simple and painless to transition, maybe no one really cares.
<StevenK> infinity: Library releases are for OCD people. Just ask mplayer.
<darkxst> infinity, I suppose the gnome guys don't bother, since your not reallly meant to mix n match releases in their eyes
<infinity> darkxst: I'd say "that's not excuse for making partial upgrades--and upgrading in general--harder", but I know what distros most of upstream GNOME run, and "upgrading" is still a confusing concept for them. ;)
<infinity> s/that's not/that's no/
<infinity> darkxst: Anyhow, in this particular case, it's a bit of a "meh".  This has clearly worked in the past, and will continue to work.  It just need a full transition, and it's a bit of a burden on apt's resolver if it needs to upgrade that library and all its rdeps in one block, but it's not rocket surgery.
<darkxst> infinity, right. though try convince upstream of that ;)
<pitti> cjwatson: cheers!
<jdoles> cjwatson: gettext can't switch language in a multi-threaded way, can it? (only one language per process) Do you know something which can do that?
<jdoles> cjwatson: the advantage of using gettext is that there are lots of translation tools available, but if one can only switch 'domain' instead of language, that's not going to help anything.
<Mirv> oh dear, precise doesn't support Build-Depends-Indep similarly to quantal and forwards
<Mirv> not a big problem for this one package, but for 20 packages with next Qt update it might pose a bit of hindrance to have things differently for precise
<cjwatson> jdoles: There's a uselocale function which supposedly can be used instead of setlocale to set a per-thread locale (undocumented in manpages or the libc info documentation, but see http://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html).  I've never used it myself since I avoid threads like the plague.
<jdoles> cjwatson: why do you avoid threads like the plague? Don't you trust yourself or don't you trust everyone else?
<cjwatson> jdoles: I'm not sure I trust anyone, including myself, to reason correctly about some of the worse corners of threads.  Event-driven programming is much easier to reason about.
<jdoles> cjwatson: event-driven being message passing?
<cjwatson> Message passing is a bit more specific.
<cjwatson> For a typical Internet server, the event-driven model usually centres around a poll loop or similar, and you then make sure that the response to each event uses only non-blocking I/O.
<cjwatson> You probably have one worker process per CPU core so that you make effective use of the hardware.
<cjwatson> For example, nginx works this way.  (I've never worked on nginx directly, but I've worked on things with similar architectures.)
<jdoles> cjwatson: I get about 10Krequests/sec and I am not sure what I am saturating, but it's certainly not the CPU.
<rbasak> http://www.kegel.com/c10k.html for a pretty good summary of concurrent I/O techniques
<cjwatson> requests/sec is a poor measure; concurrent connections is a much better one.
<jdoles> cjwatson: how many of those should I get for reasonable performance?
<jdoles> I can get -n 10000 -c 10000, but when I do that with more, it breaks.
<jdoles> Perhaps lack of memory.
<cjwatson> Ten years ago (when I was last working on this stuff full-time) I'd have considered anything that couldn't do thousands of concurrent connections not-fit-for-purpose.
<cjwatson> I'd hope things have moved on since then.
<cjwatson> Saturating memory would be pretty terrible.  Obviously it depends what you're doing but nginx claims on the order of 2.5MB of RAM per 10000 connections.
<cjwatson> Usually the limit on decent event-driven servers winds up being the event source they're using, so select vs. poll vs. /dev/epoll etc.
<jdoles> cjwatson: in this case it is nginx that was falling over.
<jdoles> cjwatson: 768 worker_connections are not enough
<cjwatson> With a threaded server I'd expect the scheduler to run into trouble first, assuming you'd managed to write a program that never does anything wrong with the POSIX threads API.
<jdoles> I will increase that limit.
<cjwatson> jdoles: Well, like I say, I haven't worked on nginx directly.  I'm talking about the model.
<dholbach> jcastro, is https://code.launchpad.net/~tribaal/ubuntu/saucy/juju-core/add-bash-completion/+merge/177287 something that should go into juju upstream instead?
<cjwatson> (I worked on Zeus back in the dawn of time.  Sadly proprietary and now apparently mostly discontinued though.)
<jdoles> cjwatson: do you think this is reasonable? http://paste.kde.org/p9d351457/
<jdoles> cjwatson: ab -n 100000 -c 10000 <url>
<jdoles> There are no failed requests, just some really slow ones.
<jcastro> dholbach: yea I believe so, should I get someone upstream to check it out?
<jdoles> Twitter talked about 22MB/s it seems I am pushing more than that here on one machine.
<cjwatson> jdoles: It certainly used to be that ab itself started running into problems before good-enough servers did.
<cjwatson> Like I say it's been a decade.
<cjwatson> (My memory of the history is that Zeus wrote ab and contributed it to the Apache project; but then they had several more improvements internally that I don't think were ever released.  There are some other tools like siege that I think used to be better.)
<dholbach_> jcastro, is https://code.launchpad.net/~tribaal/ubuntu/saucy/juju-core/add-bash-completion/+merge/177287 something that should go into juju upstream instead?
<jcastro> dholbach: I believe so
<dholbach> jcastro, can you find somebody to get it upstream? :)
<jcastro> dholbach: what's the next step, have someone upstream review it or do I need assign something to someone in launchpad or ?
<dholbach> jcastro, just ask around if they want to add it there and if they do, I'll ask for this MP to be closed
<jcastro> got it, thanks
<dholbach> seb128, looks like https://code.launchpad.net/~adam-stokes/ubuntu-seeds/ubuntu.saucy/+merge/177469 would add sosreport to desktop recommends - is this what you'd want?
<seb128> dholbach, I would prefer not adding new python2 code to the default installation ... any way that could be ported to python3?
<seb128> stokachu, ^
<dholbach> ScottK, Riddell: I just had a look at https://code.launchpad.net/~ari-tczew/ubuntu/saucy/networkmanagement/lp-1205545/+merge/177297 and it looks good to me - I just wanted to confirm if http://paste.ubuntu.com/5929192/ (debdiff of the resulting .deb files) looks OK to you too?
<dholbach> it looks like the header files should not have been included in the shipped package in the first place, right?
 * Riddell looks
<Riddell> dholbach: the libraries have different so name versions presumably it was build on a different version of kdelibs, if the packaging doesn't care about that then it looks good to me
<dholbach> Riddell, at least it builds fine for me
<Riddell> dholbach: yeah go ahead then thanks
<dholbach> rock and roll
<dholbach> thanks!
<JackYu> barry, hi, do you have more comments on the bugs (bug #1203931 and bug #1203958) I filed?
<ubottu> bug 1203931 in UbuntuKylin "[needs-packaging] unity-china-video-scope" [Critical,In progress] https://launchpad.net/bugs/1203931
<ubottu> bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,In progress] https://launchpad.net/bugs/1203958
<barry> JackYu: i'm sorry, i'm totally slammed with other work right now.  can you ping me again in a couple of days? ;)
<barry> JackYu: or maybe ping dholbach if he's still patch piloting
<dholbach> I'm not a scope expert, so somebody from the desktop team would be good - I can do a general packaging review though
<seb128> dholbach, there is nothing else than packaging review to do there
<dholbach> ok
<dholbach> I'll check them out in a bit
<seb128> dholbach, I would appreciate if you sponsor them, so I can review them in NEW for the Kylin guys
<seb128> dholbach, if I sponsor I can't do NEW review as well
<dholbach> sure sure
<JackYu> barry, dholbach, seb128, thanks:)
<JackYu> dholbach, if you have any feedback or suggestion, please let me know.
<dholbach> will do
<JackYu> :)
<dholbach> JackYu, seb128: video looks good - uploading
<dholbach> JackYu, seb128: photo needs a bit of work
<seb128> dholbach, thanks
<JackYu> dholbach, thanks, we will improve  photo according to your comments asap.
<dobey> jbicha: the removal of *.omf is because there's no more scrollkeeper?
<jbicha> dobey: I don't know all the details but scrollkeeper is unnecessary these days
<dobey> jbicha: right. just want to understand why the omf is deleted. does the new stuff not use the omf files?
<jbicha> right
<dobey> ok
<jbicha> scrollkeeper was before my time so I'm honestly not even sure what it was used for
<dobey> it was the help docs indexing stuff
 * dobey would happily just get rid of the "help" docs for most apps anyway
<dholbach> JackYu, seb128: so I run into http://paste.ubuntu.com/5929456/ - it seems like the tarball in bug 1203958 has a debian/ directory included already
<ubottu> bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,In progress] https://launchpad.net/bugs/1203958
<dholbach> so I think I don't need to use lp:~jingjing20061278/unity-china-photo-scope/unity-china-photo-scope.pkg for packaging, right?
<dholbach> I tried to debug the build in a number of ways, but didn't succeed yet
<dholbach> the setup.py uses a local build_i18n_ext.py script which I'm a bit unsure about
<dholbach> ./build_i18n_ext.py and ./setup.py both seem to use python2, while the rest of the code uses python3
<dholbach> also it looks like Architecture should be "all" and not "any"
<JackYu> dholbach, let me check.
<infinity> pitti: I've probably asked you this before, but does your optipng magic parallelise at all?
<infinity> pitti: With all our buildds being multi-core, and that part of the build taking forever, it would be nice if it did...
<dholbach> JackYu, seb128: I'll add my findings to the bug report
<dholbach> unfortunately I'm not able to fix it :-/
<dholbach> I tried to compare with a bunch of other packages using "--with translations,python3"
<dholbach> but I still was unable to fix it
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> ok
<seb128> dholbach, thanks for the help/reviews
<pitti> infinity: no it doesn't at the moment; that would mean splitting into (up to) parallel=N processes within the wrapped dpkg-deb, right?
<JackYu> dholbach, thank you. we will debug it and ping you tomorrow  (it's middle night here:)).
<infinity> pitti: Or something, yeah.  Though, I guess dh_builddeb itself can parallelize, if one runs dh --parallel, so maybe that's the real answer.
<dholbach> ok - all the bes then! :)
<infinity> pitti: Oh, but that doesn't help on sources with a single massive binary package full of PNGs.
<pitti> infinity: indeed, dh_builddeb already forks off dpkg-builddeb N times
<pitti> infinity: oh arg, I know why
<pitti> bug 893826
<ubottu> bug 893826 in qt4-x11 (Ubuntu Precise) "symlinked docs are different between architectures, depending on dpkg-deb package order" [High,Fix released] https://launchpad.net/bugs/893826
<pitti> infinity: we actually override dh_builddeb to avoid exactly this
<infinity> pitti: Oh, that actually works in our favour here.
<infinity> pitti: Cause we then have control over this and don't have to balance "maybe it's parallel" with "maybe it's not" and try not to starve our CPUs.
<pitti> infinity: so if we want to parallelize, we need a more clever way to predict which symlink will be done where
<pitti> infinity: or save the original parallel value and fork off processes ourselves
<infinity> pitti: We can just always assume we're serially processing debs when we get to dpkg-deb --build, and then use DEB_BUILD_OPTIONS=parallel to fork more optipng bits.
<pitti> infinity: right, the dh_builddeb wrapper could export something based on the original $D_B_O
 * infinity grabs the mangler source to see how mangled it is these days.
 * pitti waves good night
<infinity> pitti: Toodles.
<gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html could just be closed
<gQuigs> for example: xserver-xorg-video-openchrome, gnome-power-manager and moon (moonlight)
<gQuigs> one other (unrelated) question:  Will saucy stay on being synced from Weezy?   While Saucy+1 LTS will be based on Jesse?
<jtaylor> saucy is synced from debian unstable
<jtaylor> same with saucy+1
<jtaylor> though at this stage automatic syncs are disabled but manual syncs still possible
<jtaylor> gQuigs: ^
<gQuigs> jtaylor: I was told to check this page to see what it is derived from: https://launchpad.net/ubuntu/saucy
<gQuigs> which says Wheezy..  is it just wrong?
<jtaylor> I'd say its wrong, wheezy is based on a state almost a year old while saucy is still very similar to current debian unstable
<sarnold> is it possible to sync from debian experimental? or must packages migrate to unstable or testing first?
<jtaylor> its possible, if there is a good reason
<jtaylor> its common during debian freeze where experimental is used as unstable replacement, but now you shouldn't in general
<gQuigs> hmm.. I can't find anything synced to saucy yet...
<jtaylor> as experimental is again used for what its named
<sarnold> ahh, makes sense..
<gQuigs> but raring looks to be definitely based on Wheezy (and it was testing at the time)
<jtaylor> gQuigs: what are you looking at?
<gQuigs> http://packages.debian.org/search?keywords=squid3+&searchon=names&suite=all&section=all  vs http://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=squid3
<gQuigs> same thing with puppet (for raring)
<jtaylor> that has a ubuntu diff, so its needs manual merging
<jtaylor> it was updated atwo eeks ago but its still stuck in proposed
<jtaylor> https://launchpad.net/ubuntu/+source/squid3
<seb128> sarnold, what do you want to get synced?
<roaksoax> mterry: howdy! any ideas why crmsh has not been promoted to main?
<sarnold> seb128: pdns; the powerdns team is thinking of treating 3.3 as a LTS themselves, so I think it'd be nice to have in saucy before 14.04 LTS.. http://packages.debian.org/experimental/pdns-server
<mterry> roaksoax, looking
<seb128> sarnold, do you know why it's in experimental and not unstable?
<sarnold> (though I doubt the powerdns guys intend six years of support)
<gQuigs> oh ok, so when puppet eventually autosyncs, puppet 3.2.1 should be pulled from debian unstable?  (https://launchpad.net/ubuntu/+source/puppet)
<sarnold> seb128: no. the debian maintainer is not too pleased with ubuntu as a whole, so I've decided to not push his buttons any further by asking :)
<mterry> roaksoax, I just think it hasn't happened yet.  Maybe poke an archive admin
<jtaylor> gQuigs: puppet is up to date in saucy
<roaksoax> mterry: will do! thanks!
<sarnold> seb128: I believe there is conf.d/ style changes in configuration though, I believe that caused a fair amount of extra effort.
<seb128> sarnold, ok, there is a good chance it lands in unstable before the next LTS, we can wait for a bit (or just sync if somebody is looking after it)...
<sarnold> seb128: cool, thanks :)
<gQuigs> jtaylor: damn, sorry - you are right;  package.u.com failed me :/
<jtaylor> gQuigs: launchpad and the debian pts are better sources of information
<jtaylor> protip: bind a keyword search to http://packages.qa.debian.org/common/index.html?src=%s
 * SpamapS updates aging "on dev release since maverick" box to saucy wondering "will this be the upgrade that kills it?"
<doko> slomo__, seb128: I hate gst-plugins ...
<doko> why is libgstreamer-plugins-base0.10-dev built form gst-plugins, and not from gstreamer itself?
<seb128> doko, because gstreamer is a framework and the plugins are optional/different sources?
<doko> seb128, yes, but the plugins comes with a rat tail of dependencies
<seb128> doko, base not much, but the other ones do...
<doko> different question, how do I build plugins-base as a DEB_STAGE=stage1 build without these deps?
<doko> my problem is libtheora, and maybe gnomegvfs
<doko> so being able to build without these two would be good
<seb128> I don't know about gst to answer that...
<doko> seb128, so slomo__ ?
<seb128> yes
<slomo__> doko: just disable those plugins then, remove from build deps and remove the two files from debian/*.install
<Laney> doko: you might like --disable-external too
<doko> Laney, how do I tell cdbs not to build a certain package?
<Taggg> hi, can anyone tell me the proper branch to propose this fix be merged into? https://code.launchpad.net/~mar-kolya/ubuntu/raring/acpid/fix-for-1184831
<Taggg> i'm not sure if i should propose merge into raring, saucy, or something else?
<sarnold> Taggg: I believe the usual approach is to propose to devel first to make sure the bug doesn't come back in the future :)
<Taggg> sarnold: would that be this? https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/acpid/saucy
<Taggg> sarnold: i'm not too familiar with the series/milestone terminology
<sarnold> Taggg: yes, that looks correct
<Taggg> sarnold: great thanks! one more question: how long do merge requests typically take to go through?
<sarnold> Taggg: hrm, dunno, but patch pilots do look at the backlog of patches daily to move things along
<cjwatson> gQuigs: Trust me, it's definitely synced from unstable, as was raring - I operate the auto-sync.  Launchpad's derivation information is wrong because it was hard to make it correct, but it's also basically irrelevant.
<Taggg> sarnold: so what's the difference between proposing a merge into raring and raring-proposed?
<Taggg> sarnold: is raring-proposed for bigger more-disruptive changes?
<cjwatson> Stable releases aren't for disruptive changes at all.  Virtually all changes belong in saucy, the current development series
<sarnold> Taggg: yes, raring-proposed is used for Stable Release Updates -- people who have reported bugs can find the fixes in the -proposed area, test them out, and mark the validation in the bug a success or failure
<cjwatson> raring* is only for things following https://wiki.ubuntu.com/StableReleaseUpdates
<Taggg> sarnold, cjwatson: great thanks! yeah i'm not doing an SRU, haha, so saucy it is :)
<doko> Laney, works! now how to teach cdbs ...
<cjwatson> wg 27
<cjwatson> sorry
#ubuntu-devel 2013-07-31
<pitti> Good morning
<dholbach> good morning
<jibel> pitti, about gvfs, I found that a test has been requested for gvfs_1.17.2-0ubuntu3 when libgphoto2 2.4.14-2.1 has been synced
<jibel> pitti, but no trace of a test when gvfs itself has been uploaded, i'll continue to investigate
<pitti> jibel: well, don't waste too much time on it
<pitti> jibel: I was just curious as this is pretty much exactly the kind of regression that we want to keep out
<jibel> pitti, I suspect it is not limited to gvfs
<pitti> jibel: infinity seemed to have a case yesterday where a new eglibc only triggered 19 rdepends, that also seemed a bit low
<pitti> not sure whether this is related somehow
<pitti> but if you say that a test had been requested on the libgphoto2 sync, then it's something else
<pitti> infinity: hm, what does that want to tell me? https://launchpadlibrarian.net/146278424/buildlog_ubuntu-saucy-amd64.sane-backends_1.0.23-0ubuntu3_FAILEDTOBUILD.txt.gz
<pitti> infinity: some error in the PPA chroot's .sbuildrc?
<doko> Laney, any idea why gtk+3.0 is built sequentially?
<JackYu> dholbach, morning, we updated a new tarball at bug #1203958, would you please take a look?
<ubottu> bug 1203958 in UbuntuKylin "[needs-packaging] unity-china-photo-scope" [Critical,In progress] https://launchpad.net/bugs/1203958
<dholbach> JackYu, taking a look
<dholbach> JackYu, I commented on the bug report
<pitti> jibel: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ back to green \o/
<Laney> pitti: I wonder if unblock implies forcing the tests
<Laney> gvfs was unblocked during the freeze
<pitti> jibel: ^
<Laney> more a cjwatson question I'd guess
<pitti> Laney: they indeed did coincide, perhaps that's it
<pitti> but I thought unblocking would just mean "remove the block in the ~u-release branch", not actively pushing stuff
<Laney> unblocks override blocks, so we tend to add them specifically
<Noskcaj> roaksoax, PING
<pitti> Laney: oh, I misinterpreted that as "got unblocked after the freeze", sorry
<Laney> ah
<Laney> I mean the 'unblock' hint type - I wouldn't be surprised if that overrode test failures
<Laney> p.s. good work on fixing that
<pitti> Laney: very plausibly, yes
<pitti> jibel: ^ so, don't waste time on investigating this (yet)
<JackYu> dholbach, updated:).
<pitti> tkamppeter: ah, it seems you are somewhat attached to flphoto?
<pitti> tkamppeter: do you know if there is a patch anywhere to build it against libgphoto 2.5? I looked around (fedora, suse, etc.), but fedora never had it, suse dropped it, and upstream disappeared
<pitti> tkamppeter: otherwise, would you be very sorry if we removed it? shotwell should by and large replace it
<dholbach> JackYu, uploading
<JackYu> dholbach, great, thanks a lot:)
<dholbach> anytime :)
<doko> pitti, jibel: looking at the python2.7 test failures on i386 ...
<doko> the test_curses test did fail to start early this week, however we had no python related changes. wasn't this the time when the new autopkgtest was enabled?
<cjwatson> Laney: unblock doesn't force tests
<pitti> doko: it's around the same time, yes, but that doesn't change how std{in,out,err} or the VMs look like; these were mostly fixes around error handling and wrong dependencies
<doko> pitti, no change in the redirection handling?
<pitti> no
<doko> but why did it start failing?
<pitti> doko: my first bet would be on https://launchpad.net/ubuntu/+source/ncurses/5.9+20130608-1ubuntu1
<pitti> that's quite a large change
<pitti> doko: and presumably that python2.7 run was triggered due to the new ncurses, as it landed at that very time?
<pitti> I guess it wasn't held back because someone marked python2.7's autopkgtest as 'known broken', as it had failed for a while
 * pitti looks into the override branch
<didrocks> doko: hey, (not related) do you think that some part of boost needs to be rebuilt/there is a mismatch? I got https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz during the day and still get it
<didrocks> sil2100: if you have time and finished the daily release activity, can you look about that (Mir related) please ^?
<pitti> might be a victim of the same problem that allowed the new libgphoto2 sync to get in despite it breaking reverse dependencies
<doko> didrocks, ahh, the mpi split package ... but isn't mir in main?
<didrocks> doko: not yet, there is MIR for Mir, but not in main for now
<sil2100> didrocks: will do!
<didrocks> thanks sil2100 ;)
<didrocks> sil2100: if you find changes in the rdepends (as apparently doko did some), maybe the MIR for Mir needs to be updated as well
<seb128> JackYu, hey, did you see my NEW review comments bug?
<Laney> cjwatson: OK then, not sure why gvfs passed here - http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2013-07-23/03:57:03.log
<Laney> the timing matches up with ScottK's unblock, AFAICS
<JackYu> seb128, not yet. Where can I got it?
<didrocks> doko: so, what's up? how can you fix it? mind giving a little bit more info? ;)
<seb128> JackYu, https://bugs.launchpad.net/bugs/1206613
<ubottu> Ubuntu bug 1206613 in unity-china-video-scope (Ubuntu) "comments from NEW review" [Undecided,New]
<seb128> JackYu, it would be nice if you subscribed to the packages you work on, so you get email for bugs filed on those
<JackYu> seb128, I see, thanks:). It seems that I overlooked the bug email...
<seb128> JackYu, you're welcome, and no worry, I'm just pointing it, in case
<JackYu> seb128, got it, we will improve it in the next release:).
<seb128> thanks
<tkamppeter> pitti, no problem to drop it, it was one of Mike Sweet's hobby projects. He did not do anything on it for years. The highlight of it was nice printing functionality, especially for more than 1 photo on a sheet and it was the only program which did automatic crop-to-fit to make a photo filling the whole page (or a given rectangle with an aspect ration not necessarily equal to the photo's).
<pitti> tkamppeter: http://www.easysw.com/~mike/flphoto/ doesn't even exist any more, it just times out ..
<tkamppeter> pitti, perhaps we simply drop it.
<pitti> tkamppeter: ok, thanks for confirming
<tkamppeter> pitti, easysw.com is history. Mike has no private servers any more. CUPS is coming from Apple now. Anything needed for CUPS but dropped by Apple is coming from me (OpenPrinting).
<pitti> tkamppeter: ok, that explains why other distros dropped the package
<pete-woods> pitti: resuming over here then
<pete-woods> pitti: I only modify the source - and it's a new patch - I'll just check if it's fixed in 2.37
<pitti> pete-woods: I think it'd be better to update glibmm2.4 to 2.37.4 to match our glib version
<pitti> pete-woods: if it's fixed there, of course
<cjwatson> Laney: Hard to tell from this point, unfortunately :-(
<cjwatson> Laney: But I did look over the unblock code and AFAICS it only does anything to blocks
<pitti> pete-woods: if not, let's update anyway (as other API certainly changed) and apply your patch on top
<pete-woods> pitti: that sounds reasonable to me! :)
<cjwatson> Laney: That is, block is "set update_candidate to False unless we find a matching unblock", rather than unblock going through and setting update_candidate to True which might indeed do more than intended if that were the way it worked
<doko> pitti, but the autopkgtest did run before ncurses was in the archive
<cjwatson> pitti: sane-backends> that's a known problem where Xen builders occasionally lose their mind and scribble over bits of the filesystem.  It's pretty scary but we don't know what causes it ...  For now the fix is generally to get ops to reset the slave
<infinity> pitti: Which host was that on?
<infinity> pitti: (Linking to builds is much friendlier than build logs)
<doko> pitti, looking at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/ I have a hard time to see why this is marked as failed. all tests succeed ...
<pete-woods> pitti: from looking at the git repo now, it seems like I patched a generated file, so the patch works on the source tarball, but it's not going to apply upstream
<pete-woods> lots of macro magic about _WRAP_CTOR
<cjwatson> doko: I think you're being confused by Jenkins' terribly confusing UI
<cjwatson> doko: Don't look at the log under "Last Successful Artifacts"
<infinity> cjwatson: s/reset the slave/rebuild the slave/
<cjwatson> doko: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/27/artifact/results/log is the last failure log
<cjwatson> infinity: *nod*
<infinity> cjwatson: Did anyone hunt down which guest it was and have it rebuilt?
<cjwatson> 1 test failed:
<cjwatson>     test_curses
<cjwatson> infinity: No, I tried but by the time I got to pitti's PPA he'd already retried it on another host
<doko> cjwatson, I did look at https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastSuccessfulBuild/artifact/results/log
<cjwatson> doko: The key in that URL is "lastSuccessfulBuild" :-)
<cjwatson> doko: Like I say, Jenkins' UI tends to lead you to the wrong place
<doko> argh
<cjwatson> doko: You need to follow the "Last build" link
<cjwatson> i.e. https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python3.3/ARCH=amd64,label=adt/lastBuild/
<doko> got it
<infinity> cjwatson: Looks like chindi05.  *disables*
<cjwatson> infinity: Ta
<doko> slangasek, how did you get samba uploaded? I get an error unpacking the unmodified source ...
<seb128> JackYu, dholbach: unity-china-photo-scope accepted to saucy
<dholbach> yeehaw!
<seb128> ;-)
<JackYu> seb128, wow, great!
<pitti> infinity: I've encountered it on several, but I retried them; they worked the second time
<infinity> pitti: Yeah, cause they hit a different host.  I had to go hunt down the broken one.
<pitti> doko: I think that's just time zone confusion
<pitti> pete-woods: it's not fixed in 2.7.4?
<pitti> infinity: the builder name isn't in the log anywhere? sorry then, I'll tell you the next time it happens
<infinity> pitti: The builder name is in the log when sbuild starts.  Which it couldn't because of this bug. :P
<pitti> infinity: argh :)
<infinity> pitti: Arguably, I should slap it at the top of the log too.  Would be handy.
<cjwatson> infinity: Totally
<cjwatson> infinity: Do we have the build URL at that stage
<cjwatson> ?
<pitti> seb128: so https://launchpad.net/~pitti/+archive/ppa/+packages is complete (we'll remove flphoto), I tested upgrades, and that gphoto2, gphotofs, and shotwell still work fine
<seb128> pitti, great, do you want to give it a try as well?
<seb128> want *me* to*
<pitti> seb128: si tu veux, bien sÃ»r :)
<infinity> cjwatson: I'm not sure that we ever do, that's not something the slave needs to know.
<seb128> pitti, ok, je le fais
<pete-woods> pitti: nope, same problem there - the problem is that the ctor methods are auto-generated, and don't delegate to the C-based ctor methods
<pete-woods> pitti: so they miss out on the initialisation from there
<cjwatson> infinity: Thought not
<pete-woods> pitti: the same problem has been worked around in the class dbusmessage
<pitti> pete-woods: ok; probably best to discuss that with Murray (upstream), he should be online and he knows better how this is (auto)generated
<pitti> seb128: FYI, I forgot to add a ~ppa suffix, so while the PPA has libgphoto2 - 2.5.2-0ubuntu1.1 I'll actually upload libgphoto2 - 2.5.2-0ubuntu1
<seb128> pitti, ok
<pitti> seb128: dist-upgrade should remove libgphoto2-2 libgphoto2-port0 and install libgphoto2-6 libgphoto2-port10
<pitti> seb128: hm, upgrade worked fine in a schroot, but not on my desktop; investigating
<seb128> pitti, http://paste.ubuntu.com/5932256/ for me
<seb128> pitti, seems fine, out of the libsane-dev to be removed
<pitti> seb128: hm, seems I missed the libsane-dev dep
<seb128> well I don't need it but it seems buggy
<pitti> hm, in my uploaded source it is correct
<pitti> seb128: I wonder why it doesn't just upgrade it; might be the same problem that I'm seeing
<pitti> seb128: probably the unversioned Breaks: is too strong and it confuses apt
<seb128> could be
<pitti> seb128: the libgphoto2 packaging is a mess, but I don't want to divert too far from Debian
<seb128> pitti, also it removed libgphoto2-2-dev and didn't install libgphoto2-6-dev instead
<seb128> is that wanted?
<pitti> seb128: that's kind of expected; we could add a transitional package for -dev, not sure whether we should bother
<pitti> seb128: ok, hold on for a bit, I'll try a new version
<infinity> pitti: Does an unversioned Breaks even make sense?  It's effectively a Conflict at that point.
<pitti> infinity: yes, but I thought Breaks: were slightly friendlier to apt as it can remove the package after the broken one gets unpacked
<seb128> pitti, oh, I upgraded to do runtime testing ... those -dev issues seem fine to me
<pitti> infinity: but I'll drop the breaks and just keep the Replaces:, that ought to be enough (testing now)
<infinity> pitti: Well, if the goal is to force the other package off the system, Replaces alone won't do it, it'll just overwrite some files. :P
<pitti> it shouldn't actually break the old library, it just overwrites some READMEs
<pitti> infinity: yes, that's the goal
<sil2100> doko: hi! I'd like to do a re-poke about the libboost-mpi issue we got during Mir building
<infinity> pitti: But for overwrites, you *should* use Breaks/Replaces, to guarantee correct ordering, so files don't get lost.  But, they should be versioned.
<sil2100> doko: could you give us some info about what could be wrong that it's not installable?
<pitti> I installed gvfs, shotwell, and gphoto2 into a schroot and dist-upgraded to the PPA without a problem, but on my real desktop apt wants to hold back gphoto2 rather
<infinity> pitti: Unless both packages will always ship those files, in which case, someone's doing something wrong.
<sil2100> doko: (along with libboost-mpi-python-dev and libboost-graph-parallel-dev)
<pitti> infinity: so that means I'll keep the old names as transitional packages and keep them empty
<pitti> I was hoping to avoid that, but *shrug*
<infinity> sil2100: boost-mpi/boost just got uploaded/built, were you just running into arch skew?  Which build?
<sil2100> infinity: hi! Ok, so I'm running amd64 and I'm encountering the same issue as in the logs - so, after doing update, apt-get install libboost-all-dev cannot install libboost-graph-parallel-dev libboost-mpi-dev and libboost-mpi-python-dev - we got the same here:
<sil2100> infinity: https://launchpadlibrarian.net/146284943/buildlog_ubuntu-saucy-i386.mir_0.0.8%2B13.10.20130731.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<sil2100> infinity: so it's i386
<sil2100> infinity: does it mean libboost-all-dev has invalid deps now?
<sil2100> Due to the switch?
<infinity> What "switch"?
<pete-woods> pitti: I have managed to make a patch that will apply upstream now - do you know what room / server I will find Murray in?
<infinity> sil2100: If you retry that build, it should be fine.
<infinity> sil2100: At least on i386/amd64.  ppc and arm are still building the new boost.
<pitti> pete-woods: he's "murrayc" in #gnome-hackers on irc.gnome.rog
<pitti> pete-woods: .org
<sil2100> infinity: hm, it will? Since I just did update and apt-get install --simulate libboost-all-dev on my system and get the same error - but maybe my mirror is outdated?
<infinity> sil2100: I just tried it here and it was fine.  *shrug*
<sil2100> Well, I'm using the polish mirror, so I guess it could be this
<sil2100> Let me try a re-run
<pitti> seb128: ok, got a clean upgrade now
<pete-woods> pitti: thanks!
<sil2100> didrocks: ok, so anyway we'll have to wait for armhf mir at least until boost finished building there
<didrocks> infinity: I retried it this morning, but maybe too early?
<didrocks> sil2100: keep me posted ;)
<sil2100> didrocks: it's building now \o/
<pitti> seb128: tried again with gvfs (file-like browsing), gphoto2, and shotwell, WFM
<sil2100> didrocks: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4839926
<sil2100> didrocks: so I'll re-try i386 as well
<didrocks> sil2100: sweetnesssssss! :)
<seb128> pitti, works fine for me as well
<pitti> seb128: gvfs' GPhoto test will need an update for the new ioctls, I'll do that
<seb128> thanks
<cjwatson> sil2100: The builds use the hidden master archive; everything, including archive.ubuntu.com, is potentially outdated relative to that :-)
<pitti> seb128: ok, so ready for saucy?
<seb128> pitti, seems so! UPLOAD ;-)
<pitti> seb128: (-proposed)
<seb128> it's transitions' week
<seb128> (new poppler, new libgphoto, ...)
<sil2100> ;D
<Laney> mmm transitions
<slangasek> doko: that's a behavior change in patch; the new version of samba in Debian unstable is fixed
<doko> slangasek, when you sync/merge it, could you update the config.* files too?
<slangasek> doko: I don't expect to have time to do that merge any time soon, fwiw - so maybe it's better to file a bug
<didrocks> sil2100: so, from the MIR for Mir standpoint, no additional package is needed? (if boost was splitted?)
<doko> slangasek, ahh, still in NEW
<slangasek> doko: hmm, what's in new?
<doko> slangasek, 4. but I see there is -2 in debian. will check it ...
<slangasek> right, I meant 3.6.16-2 only
<sil2100> didrocks: hm, doesn't look like it, I'm looking at the diffs but I don't even see any splitting going on
<didrocks> sil2100: ok, not sure what doko meant by "the mpi split package"
<xnox> sil2100: didrocks: we only split the default boot version. Do you want to use a newer boost?
<sil2100> didrocks: no idea as well, but boost 1.53.0-4ubuntu1  was released long ago an ubuntu2 and ubuntu3 only added --disable-long-double --without-context
<didrocks> xnox: mir is using default boost and tries to install libboost-all-dev
<didrocks> (and the -dev deps on libboost-program-options-dev)
<xnox> didrocks: libbost-all-dev is in universe, as that depends on mpi portion. Depend on individual libboost-foo-dev that your package actually needs.
<infinity> I'm failing to see how any of those things are problems...
<infinity> Except for the -all-dev, yes, which no one should build-dep on.
<sil2100> Interesting
<didrocks> infinity: do you think what the mir-team should deps on?
<infinity> That's like a build-dep on "lib*-dev" because you don't know what you actually use. :P
<infinity> didrocks: I think they should build-dep on what they link with.
<sil2100> didrocks: I guess that we need to consider talking to the mir team about that
<didrocks> sil2100: yeah, see my pings on #ubuntu-mir ;)
<sil2100> oh!
<infinity> xnox: I suppose if you wanted to be nice to the lazy, you could provide a libboost-all-main-dev, but I tend to agree people should actually figure out what they need and only use that anyway.
<didrocks> infinity: that's obvious, I would just hope I wouldn't have to be the one again figuring that out for them and being taken in hostage because of that transition
<xnox> infinity: meh, that would diverge from debian.... plus we may or may not move some boost portions to universe even if they are build  from the main package, if nothing depends on them.....
<didrocks> so let's try to figure that out with them
<infinity> didrocks: There is no transition here... boost has always been split like this.
<infinity> didrocks: The transition is that they've moved from building in universe to main. :P
<infinity> xnox: Fair point.
<doko> infinity, let's introduce pattern dependencies for the mir team =)
<infinity> doko: Depends: stripes\nSuggests: polkadots\nConflicts: plaid?
<Laney> siretart: do you have plans for libav 9 in saucy?
<xnox> sil2100: didrocks: doko: infinity: so mir will bring in boost chrono & regex, but both of those are build from the main src-package already, so it's just binary move. https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804
<infinity> Laney: Yeah, we're going to start the transition Very Soon.
<infinity> xnox: Sure, binary moves are no big deal, we deal with them all the time.
<Laney> infinity: Neat.
<slangasek> xnox: MIRs only care about source packages, not binaries... as long as the source is in main, the binaries will be in main as long as something else in main needs them to be
<xnox> slangasek: ok.
<slangasek> but mpi is obviously still a problem
<xnox> slangasek: in progress being solved https://code.launchpad.net/~xnox/mir/boost-split/+merge/177804
<slangasek> xnox: excellent :)
<ev> anyone know a good example of a project using dbus-test-runner offhand? apt-cache rdepends is of no help, and I imagine build-rdepends isn't needed often enough to warrant the implementation
<jbicha> ev: did you try  reverse-depends -b dbus-test-runner
<ev> dammit. Thanks jbicha.
<jbicha> ev: in whoopsie-preferences, is the "Send a report automatically for login problems" box still supposed to be insensitive?
<ev> jbicha: yes - we haven't implemented that yet. I thought we started hiding it though?
 * ev digs
<jbicha> ev: when it was in a-l-m, I had to hide it "harder" https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/activity-log-manager/saucy/view/head:/debian/patches/01_really_hide_automatic_reports.patch
<ev> jbicha: it still is in a-l-m
<ev> whoopsie-preferences is a dbus service and library for communicating with said dbus service that controls /etc/default/whoopsie, /etc/apport/autoreport, and the whoopsie upstart job
<xnox> slangasek: if and when you have time to review =) https://code.launchpad.net/~xnox/ubuntu/saucy/mountall/btrfs/+merge/177822
<pete-woods> pitti: hi again, so now that bug has been fixed upstream, I've backported the patch to the version we have in saucy
<pitti> pete-woods: nice, that was fast
<pete-woods> pitti: should I still submit a bug / patch for that off the current version we have?
<pitti> pete-woods: I think it'd be better to update it to 2.37.4 and apply it on top of it
<pitti> to match our glib
<pitti> pete-woods: so no need for you to backport
<pitti> pete-woods: (in terms of changing the code to apply to the older version)
<pete-woods> pitti: I don't think that it'll be 2.37.4 - looking in the git tree that has already been tagged
<pitti> pete-woods: we still need to add the patch to the package, of course
<pitti> pete-woods: so a bug "please update" with a pointer to the patch (gnome git) is fine
<pitti> pete-woods: unless you want to do the update yourself, of course
<seb128> pitti, pete-woods: I can do the glibmm update today if you want ... what's the patch to include?
<pete-woods> pitti: oh, that's cool - I thought we'd be waiting on "full" releases
<pitti> seb128: I guess https://git.gnome.org/browse/glibmm/commit/?id=23823fdf3a54ed3851b8
<pete-woods> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=705199
<ubottu> Gnome bug 705199 in giomm "Cannot construct MenuItem - warning, no property named "label"" [Normal,Resolved: fixed]
<pitti> pete-woods: depends on how urgent it is, but if you block on it we can cherry-pick the patch
<robert_ancell> slangasek, bug 1206897
<ubottu> bug 1206897 in systemd (Ubuntu) "logind fails to work, falling back to ConsoleKit when /run/users already exists" [Undecided,New] https://launchpad.net/bugs/1206897
<seb128> pitti, pete-woods: if I do the update I can as well include the patch with it
<pete-woods> pitti: well, the world won't end, but it is blocking me atm :)
<seb128> pete-woods, pitti: I'm going to backport it, no worry
<pete-woods> seb128: that would be awesome! :)
<slangasek> xnox: why should we special-case btrfs in mountall?  Why should we not demand that the btrfs-tools provides the standard interfaces, like fsck.btrfs?
<slangasek> xnox: also, why is "major zero" a correct means of detecting "this is a filesystem we should skip checking"?
<xnox> slangasek: because due to (a) intrisic features of btrfs, it does not need fsck on each mount (b) deficiencies of fsck.btrfs of not able to run on read-only mounts.
<xnox> slangasek: i didn't find a definite explanation of what "major zero" mean and which fs have "major zero", but that's the check used now in chroot.sh (debian sysvinit) and there are references of similar used on fedora.
<slangasek> xnox: which is to say: btrfs devs are playing silly buggers with the standard fsck interfaces and people are letting them get away with it
<xnox> slangasek: imho, ideally i'd want all btrfs filesystems specify fs_passno 0 in fstab. But nobody seems to be doing that at the moment.
<slangasek> right, but why wouldn't we fix *that* bug in Ubuntu?  (installer + update handling)
<xnox> slangasek: do we ever modify /etc/fstab post install?
<slangasek> sure
<slangasek> we did for migration to UUID-based mounting
<xnox> cause, I still have ntrfs-3g patch to accept obsolete aliased option name for wubi, unless that's because we can't access/modify fstab....
<slangasek> we certainly can modify fstab
<slangasek> it needs to be done carefully
<slangasek> seb128, pitti: have you guys noticed that this week, lid close events are not being handled correctly?  It's a frequently-reported problem here at the sprint, that only just regressed
<seb128> slangasek, was that the "upower hangs in libusbx code"?
<seb128> or is that something different?
<slangasek> I see there was a upower update, but I can't make that line up with when I started seeing the bug
<slangasek> seb128: I don't know
<slangasek> is there a bug report about this?
<seb128> slangasek, I synced the libusbx fix from aurel32 this morning, would be good to see if that's still happening with the update/an upower restart
<slangasek> upower doesn't seem to be hung for me
<seb128> slangasek, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988
<ubottu> Debian bug 717988 in libusb-1.0-0 "libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)" [Important,Fixed]
<infinity> slangasek: My lid close was failing and then after an upgrade, stopped failing again.
<infinity> slangasek: So, either it was fixed, or it's wildly intermittent and hard to reproduce.
<seb128> slangasek, gdb to upowerd and "t a a bt"?
<slangasek> seb128: upgrading libusb-1.0-0 now to check
<seb128> slangasek, you can easily reproduce? if you are in buggy state, having the bt before killing upowerd would be useful still
<slangasek> bah, why is update-manager broken again?
<slangasek> seb128: sure, trivial to reproduce; I'll pastebin the gdb bt
<slangasek> seb128: http://paste.ubuntu.com/5932741/
<seb128> slangasek, yep, locked in libusb code
<slangasek> why does apt-get dist-upgrade against saucy want to remove ubuntu-desktop? :P
<slangasek> did someone force something inappropriate through proposed-migration?
<seb128> slangasek, don't use saucy-proposed?
<slangasek> I don't
<seb128> hum
<seb128> can you pastebin that as well? ;-)
<slangasek> http://paste.ubuntu.com/5932747/
<seb128> slangasek, your upower issue is almost for sure the one fixed by the new libusbx I synced earlier, let me know if the update works for you
<slangasek> yes, will do
<seb128> slangasek, https://launchpad.net/ubuntu/+source/libgphoto2
<seb128> slangasek, apt-cache policy libgphoto2-2 ?
<seb128> slangasek, or shotwell
<seb128> slangasek, you are sure you don't use pitti's ppa or something?
<seb128> slangasek, the new gphoto/gvfs/shotwell are still in proposed (and in pitti's ppa)
<stokachu> seb128: ive got a branch going to port sosreport over to python3 but it is still a ways away
<slangasek> seb128: so, upower was definitely hung; I had 0% battery life and didn't know it, so the laptop shut down in the middle of the upgrade ;P
<slangasek> libgphoto2-2:
<slangasek> libgphoto2-2:
<slangasek>   Installed: 2.4.14-2.3ubuntu2
<slangasek>   Candidate: 2.4.14-2.3ubuntu2
<slangasek> seb128: ^^ that's in saucy, not in a ppa or proposed
<seb128> slangasek, which is your pastebin listing it as "to update"?
<seb128> slangasek, you confirmed the dist-upgrade?
<slangasek> seb128: right, I apparently do have a ppa of pitti's enabled though
<seb128> slangasek, having shotwell in that dist-upgrade doesn't make sense
<slangasek> seb128: I did an apt-get upgrade instead
<slangasek> shotwell was "to be removed"
<seb128> slangasek, right, but shotwell-common to update
<slangasek> well, I don't know why I have pitti's ppa enabled /anyway/, so disabled now
<seb128> slangasek, which doesn't make sense, https://launchpad.net/distros/ubuntu/+source/shotwell ... the current version is in saucy since july 12
<seb128> slangasek, pitti prepared the gphoto transition in his ppa, I'm pretty sure that's the issue you hit
 * StevenK beats seb128 with the deprecated URL stick
<seb128> slangasek, you probably had it from logind testing back then
<seb128> StevenK, seems so, I never bothered changing my firefox alias it seems
<StevenK> seb128: I can't see us removing it because it's mostly cheap, but still ... :-)
<seb128> StevenK, well, I didn't notice, I just do "lpurl <source>"  in my firefox and end up on the new url through the redirect
 * xnox seems to be back online.
<pitti> slangasek, seb128: re; was in meeting, reading scrollback
<pitti> slangasek: upower is almost certainly bug 1203655 which is supposed to be fixed with latest usbx
<ubottu> bug 1203655 in libusbx (Ubuntu) "Hangs in pthread_join in libusb_exit" [High,Fix released] https://launchpad.net/bugs/1203655
<seb128> pitti, yeah, that was it, slangasek got a stacktrace
<pitti> slangasek: yes, libgphoto in my PPA is slightly broken, the version I uploaded to -proposed fixes the Breaks: and the upgrade
<pitti> seb128, slangasek: logind testing was a different PPA though
<seb128> ok, maybe he had it for another reason
<pitti> would anyone know why libgphoto2 doesn't appear on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
<pitti> it should still cause some uninstallability
<stokachu> seb128: or would it be possible to just have sosreport seeded on the cloud-image?
<pitti> (some NBS packages)
<Laney> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libgphoto2
<slangasek> seb128: post-reboot, pre-upgrade, the no-action-on-lid-close problem is not reproducible for me; but I'll restart upower and watch for the problem to resurface
<Laney> Not considered -> not on _output yet
<pitti> Laney: ah, it's first (build+tests) -> excuses, and then installability -> output?
<pitti> Laney: (besides, the jenkins test finished over an hour ago0
<seb128> slangasek, great, let me know how it goes
<pitti> Laney: I'm just anxious that it doesn't propagate now
<Laney> something like that, yeah
<pitti> Laney: thanks
<seb128> stokachu, sorry, I skipped your first message in the backlog ... cloud-image: it's not my call, but as said I would prefer not other python2 users on the desktop image, since we are aiming at dropping python2 from the image
<stokachu> seb128: ok thats cool
<seb128> pitti, "autopkgtest for gvfs 1.17.2-0ubuntu3: RUNNING (Jenkins: public, private) " ... you better check with cjwatson/jibel if there is an issue there
<seb128> pitti, it might be that the test hit an issue and is stucked as RUNNING on that side
<Laney> Not sure about the path results take from jenkins back to proposed-migration
<seb128> wouldn't be the first time
<stokachu> seb128: the previous msg was i have a branch for python3 its just a ways away
<Laney> it'll go to FAIL anyway, won't it? :-)
<pitti> seb128: it's not stuck, I checked https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/ and http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-gvfs/
<pitti> but maybe it just didn't hit another britney run yet
<stokachu> does anyone know who manages the cloud-image seed?
<pitti> anyway, for now it needs to stay in -proposed until I sort out the failing gvfs test
<seb128> pitti, well, it seems that sometime the status doesn't go back to britney correctly, that's what I meant by "stucked"
<seb128> pitti, e.g excuse keeps showing things are RUNNING when they are not
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<ogra_> stokachu, i'd guess smoser (not sure though)
<stokachu> ogra_: ok thanks ill try him and see
<pitti> seb128: right
<doko> Riddell, ScottK: do you know if there are any architecture specific things in qt4-x11? and if yes, where?
<mbiebl> slangasek: a hung upower sounds very familiar
<xnox> slangasek: btrfs returns invalid major number (zero) since a single pair is not enough for btrfs, due to possible multiple drives/subvolumes. But yeah, sounds like a fragile interface.
<mbiebl> I've been experiencing that quite a few times in the last weeks
<pitti> mbiebl: yes, the libusbx one, already sorted out
<mbiebl> pitti: ah, perfect
<mbiebl> pitti: what was the problems (do you have a bug number?)
<pitti> mbiebl: http://packages.qa.debian.org/libu/libusbx/news/20130730T171814Z.html
<seb128> mbiebl, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988
<ubottu> Debian bug 717988 in libusb-1.0-0 "libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)" [Important,Fixed]
<pitti> mbiebl: bug 1203655
<ubottu> bug 1203655 in libusbx (Ubuntu) "Hangs in pthread_join in libusb_exit" [High,Fix released] https://launchpad.net/bugs/1203655
<seb128> pitti, pete-woods: https://launchpad.net/ubuntu/+source/glibmm2.4/2.37.4-0ubuntu1
<mbiebl> pitti: thanks
<pete-woods> seb128: seriously, this is really really appreciated, thanks! :D
<seb128> pete-woods, yw ;-)
<seb128> shrug, build failed
<seb128> "Gio::Resolver::lookup_by_name() threw exception: Error resolving 'www.google.com': Name or service not known"
<pitti> in the test?
<seb128> pitti, https://launchpadlibrarian.net/146315371/buildlog_ubuntu-saucy-i386.glibmm2.4_2.37.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> pitti, yes, in the tests
<seb128> pitti, I guess I can just drop 	giomm_tls_client/test			from check_PROGRAMS in tests/Makefile.am
<seb128> pitti, or do you have a better suggestion?
<pitti> seb128: no, sounds good to me; we don't have network access in buildds
<slangasek> seb128: bug reproduced again; up-to-date libusb-1.0-0 on disk and in memory
<seb128> :-(
<seb128> slangasek, can you get a bt of upowerd and pastebin it?
<Riddell> doko: there's various bits for arm in debian/rules
<seb128> slangasek, dpkg -l | grep libusb-1.0-0
<slangasek> http://paste.ubuntu.com/5932893/
<Riddell> doko: and some bits for arm and powerpc in debian/control
<slangasek> version 2:1.0.16-2
<Riddell> doko: there's a few .asm assembler files
<pitti> hm, that's still the same pthread_join thingy
<seb128> slangasek, :-(
<seb128> slangasek, you are confident you restarted upowerd with the new libusb?
<seb128> I guess aurel32's fix isn't enough then :-(
<slangasek> seb128: lsof | grep DEL, etc. etc
<slangasek> (so yes, I checked)
<seb128> slangasek, can you follow up on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717988 saying you still have the issue,
<ubottu> Debian bug 717988 in libusb-1.0-0 "libusb-1.0-0: upowerd deadlocks in libusb (maybe related to suspend/resume)" [Important,Fixed]
<seb128> ?
<slangasek> seb128: ok - you want it on the Debian bug, not in LP?
<seb128> slangasek, well, you can update the lp bug as well, but it's a direct sync from Debian and nobody on our side has experience on that lib afaik
<seb128> slangasek, aurel32 is responsive and tried to fix the issue one, we should at least let him know it's not fixed
<seb128> once*
<tseliot> slangasek: can you have a look at bug 1198942 when you have the time, please?
<ubottu> bug 1198942 in nvidia-prime (Ubuntu) "Hybrid Graphics and general enablement for fglrx and nvidia in Precise for 12.04.3" [High,In progress] https://launchpad.net/bugs/1198942
<jdstrand> mterry: hey. fyi https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1203589/comments/7
<ubottu> Ubuntu bug 1203589 in ust (Ubuntu) "[MIR] ust" [Undecided,Triaged]
<mterry> jdstrand, ah, OK.  Missed that
<jdstrand> np
<dobey> pitti, jibel: with autopkgtest, does build-needed also result in any tests in override_dh_auto_test: in debian/rules for example, being run?
<cjwatson> dobey: If and only if an ordinary package build would run them
<dobey> cjwatson: is there any way a normal package build wouldn't run them (outside of failing to build before it got to that point)?
<cjwatson> dobey: Some packages choose not to run dh_auto_test in all cases; it's within the control of debian/rules.  It would normally be fairly obvious in debian/rules if it were avoiding running tests though.
<cjwatson> If it's just using dh in the ordinary way then it'd run them
<xnox> dobey: if DEB_BUILD_OPTIONS=nocheck is set, then unit-tests are prevented from running.
 * xnox is not sure if autopkgtest enables that or not.
<cjwatson> It does not
<pete-woods> seb128: it looks like the tls_client test tries to connect to https://www.google.com, and I'm guessing our build servers intentionally can't connect to the internet (https://launchpadlibrarian.net/146315233/buildlog_ubuntu-saucy-amd64.glibmm2.4_2.37.4-0ubuntu1_FAILEDTOBUILD.txt.gz)
<dobey> indeed. thanks
<slangasek> pete-woods: correct; internet access is not allowed as part of a package build
<infinity> (Nor external DNS resolution, as one can see from that build log)
<seb128> pete-woods, https://launchpad.net/ubuntu/+source/glibmm2.4/2.37.4-0ubuntu2
<slangasek> tseliot: so I'm sprinting this week, it might be better to hand that off to another SRU team member
<pete-woods> seb128: way ahead of me! :p
<seb128> pete-woods, ;-)
<tseliot> slangasek: oh, ok no problem
<javierl> hello, does anyone have a link to instructions to debug netinstaller?, it stops at the repo index download with no apparent reason, using linuz/initrd.gz from precise-updates
<cjwatson> javierl: Actually stops (with an error), or is just very slow?
<cjwatson> javierl: There's a change going through QA at the moment to speed it up drastically ...
<javierl> cjwatson: it could probably is slow, I've not waited more that 5 min on that stage, I abort the installation process.., however it shouldn't wait more that 5 minutes to get repos index, I wanted to boot in debug mode to see what was happening
<cjwatson> javierl: It's probably bug 1067934.
<ubottu> bug 1067934 in net-retriever (Ubuntu Precise) "spends 10+ minutes deduplicating Package lists" [High,Fix committed] https://launchpad.net/bugs/1067934
<cjwatson> javierl: There's a precise-proposed image linked from there.
<javierl>  cjwatson I'm gonna try the proposed update and comment there, thanks!
<cjwatson> javierl: There's DEBCONF_DEBUG=developer, but it's unlikely to be of any use in this case since there's no debugging emitted in the relevant code
<cjwatson> javierl: The best debugging available here is simply to switch to tty4 (Alt-F4) and see what's at the end of the log
<cjwatson> But you might as well just try the precise-proposed image first, rather than repeating debugging that's been done :)
<seiflotfy_> seb128: around?
<seb128> seiflotfy_, yes but otp...
<doko> tkamppeter, pitti: https://launchpadlibrarian.net/146228947/buildlog_ubuntu-saucy-i386.cups-filters_1.0.34-3build1_FAILEDTOBUILD.txt.gz
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tkamppeter> doko, this is already known: https://bugs.linuxfoundation.org/show_bug.cgi?id=1144
<ubottu> bugs.linuxfoundation.org bug 1144 in cups-filters "Build fails with Poppler 0.24.0" [Major,New]
<doko> tkamppeter, you misunderstand. this is about the cyclic b-d
<stokachu> could I get someone to approve a series nomination for bug 1069570 for maas package
<ubottu> bug 1069570 in maas (Ubuntu) "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [High,In progress] https://launchpad.net/bugs/1069570
<stokachu> also to remove the nomination for isc-dhcp
<infinity> stokachu: Which series?
<stokachu> infinity: so my fix only applies to the dhcp within maas, but i created nominations for both isc-dhcp and maas
<infinity> stokachu: You don't have to nominate for saucy, it's the current devel release...
<stokachu> infinity: oh
<stokachu> infinity: then i guess both of them :D
<infinity> That wasn't very clear.
<stokachu> yea, sorry, if you could clear the saucy nominations for isc-dhcp and maas that'd be great
<stokachu> infinity: actually, you know what, im going to mark this invalid and create a new issue for this fix
<stokachu> so not to confuse whats already fixed in isc-dhcp
<infinity> stokachu: *smirk*... Kay.
<stokachu> infinity: thanks :)
 * infinity presses some buttons just to get the nominations out of searches.
<stokachu> infinity: haha thanks
<infinity> stokachu: For future reference, there's 0 point in creating tasks for devel releases, since an upload to devel will close the non-targetted "master" task.
<stokachu> infinity: ah ok, wasn't sure how that worked
<infinity> stokachu: Furthermore, due to launchpad being a bit silly, if you target something to saucy, it defers the master task to the saucy task instead and, on new series opening, you get no t-series task.  Which sucks if you never got around to fixing it in saucy. ;)
<infinity> stokachu: So, just say no to devel series tasks.
<stokachu> infinity: hah i will remember to do that from now on
<infinity> We probably should just disallow nominating to active series'.
<Noskcaj> roaksoax, kirkland: can you link me your PyPi accounts so i can add you as owners of testdrive?
<kirkland> Noskcaj: 'kirkland'
<roaksoax> Noskcaj: i'll create one and let you know
<Noskcaj> kirkland, added as owner.
<kirkland> Noskcaj: cheers mate
<Noskcaj> kirkland, can you add to your release script a function to update the version in setup.py?
<kirkland> Noskcaj: sure
<kirkland> Noskcaj: let me check, I thought I did...
<kirkland> if [ -f setup.py ]; then
<kirkland>         sed -i "s/version='$MAJOR.$MINOR'/version='$MAJOR.$nextminor'/" setup.py
<kirkland> fi
<kirkland> Noskcaj: it's in there
<Noskcaj> kirkland, It must have broke then. I had to manually change it from 3.10 to 3.22
<kirkland> Noskcaj: ah, right, I bet it didn't match 3.10
<kirkland> Noskcaj: because that was too out of date;  it'll work on the next run, I bet
<Noskcaj> ok, cool
<stokachu> roaksoax: you around?
<roaksoax> stokachu: not really... :-)  whats up?
<stokachu> roaksoax: hey, was just curious when you get some time to have a look at a maas bug with a fix
<stokachu> bug 1207102
<ubottu> bug 1207102 in maas (Ubuntu) "Set PXE class lease expiration to 30 seconds" [Undecided,New] https://launchpad.net/bugs/1207102
<roaksoax> stokachu: is this for precise?
<stokachu> saucy
<roaksoax> stokachu: ok can ypou assign me or subscribe me to the bug. though is this related to multiple duplicated entries of a node? or many leases for a node?
<stokachu> roaksoax: i believe its related to duplication or the nodes not being ready when adding to dns
<roaksoax> stokachu that was fixed on isc-dhcp side though...
<stokachu> roaksoax: that didnt actually fix this issue
<stokachu> something about the leases not being expired quick enough when adding multiple nods
<stokachu> nodes*
<roaksoax> uhmm ok. ill have a look tomorrpw cause im EOD already. Just assign it to me please :-)
<stokachu> roaksoax: ok will do.. i have the fix attached just need it uploaded/verified
<roaksoax> ok cool thanks!
<Noskcaj> kirkland, one other thing, why doesn't the testdrive bzr branch or the .orig include the translations?
<kirkland> Noskcaj: no idea -- I have always sucked at getting po and debian packages and Launchpad translations integrated
<kirkland> Noskcaj: it would be great if y'all figure that out
<Noskcaj> kirkland, I'll look into it when i get home from school
<stokachu> shouldnt https://wiki.ubuntu.com/SimpleSbuild#Local_packages for chroot-setup-commands be /repo/prep.sh since its running within the chroot?
<stokachu> barry: ^
<barry> stokachu: what can i tell ya.  if it ain't broke, don't fix it. ;)
<stokachu> barry: it breaks for me
<stokachu> :)
<cjwatson> barry: It might happen to work for you because your schroot profile bind-mounts your home directory
<barry> stokachu: oh!  well, tbh, i don't think i've done local packages since at least raring.  it's possible that something's changed since then
<barry> cjwatson: yep, that's it
<cjwatson> But that isn't guaranteed and isn't true for all profiles
<cjwatson> So I'd agree with stokachu's suggested change if it tests out
<barry> stokachu: cjwatson is right, i'm sure.  it's a wiki - fix it! :)
<stokachu> so after i added the line to sbuild/fstab i had to change the chroot-setup-commands to use /repo/prep.sh
<stokachu> barry: i just wanted to make sure im not crazy before editing it
<barry> stokachu: no time to test it here, but cjwatson's comment makes sense.  if it works for you, go for it
<cjwatson> chroot-setup-commands is indeed executed chrooted, so I think it makes sense to use guaranteed-to-be-inside-chroot paths
<stokachu> ok cool ill update the wiki cjwatson/barry
<barry> stokachu, cjwatson thanks.  i've made the change locally so i'll double check the next time i do a build
<stokachu> barry: sounds good man, thanks!
#ubuntu-devel 2013-08-01
<pitti> Good morning
<pitti> dobey: as cjwatson says, "build-needed" does a complete normal package build without any DEB_BUILD_OPTIONS
<Snow-Man> pitti: just fyi, I'm all over #718460 already. :)
<pitti> Snow-Man: oh, nice! thanks
<Snow-Man> yea, np.
<Snow-Man> a fix should be in our next point release.
<pitti> mbiebl, slangasek: oh, http://packages.qa.debian.org/libu/libusbx/news/20130731T190350Z.html -- I'm syncing that now
<mbiebl> pitti: I already have that version :-/
<mbiebl> pitti: I'm not sure if it's the upower deadlock though
<mbiebl> since upower -d now works just fine
<pitti> mbiebl: ah, so at least libusbx was fixed for good?
<mbiebl> well, not sure
<mbiebl> dbus-send --print-reply             --system             --dest=org.freedesktop.UPower             /org/freedesktop/UPower             org.freedesktop.UPower.Suspend
<mbiebl> Error org.freedesktop.UPower.GeneralError: Sleep has already been requested and is pending
<pitti> upower does that if the previous resume failed, do you have anything in pm-suspend.log?
<mbiebl> might be a different issue
<mbiebl> I get that after the first suspend
<mbiebl> the missing Resuming signal also means
<mbiebl> that NM doesn't properly wake up
<Snow-Man> pitti: patch committed & pushed
<pitti> Snow-Man: cheers
<dholbach> good morning
<slangasek> pitti: sync> thanks; will test as soon as it's out of -proposed
<seb128> hum
<seb128> what's the right place to ask for morphis to be banned the time for the join/part flood to stop?
<seb128> there is an IRC op channel? (I don't remember the details)
<Laney> #ubuntu-irc iirc
<seb128> Laney, thanks, asked there
<slangasek> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says autopkgtest for upower 0.9.21-1 is running; following the link to jenkins says it finished hours ago after 2 minutes; where is this stuck?
<pitti> (same for gvfs test)
<pitti> I had several of those yesterday evening, they cleared up over night
<pitti> but somewhere there's a huge propagation delay, much more than just the publisher delay
<pitti> jibel: ^
<pitti> seb128: oh, libgphoto and its rdepends tail are just being propagated
<pitti> mah, how did we *ever* deal with transitions without our staging magic
<seb128> pitti, did the jenkins status finally update?
<pitti> seb128: mostly, yes; it still considers the upower test running, but the gphoto related ones are done
<seb128> pitti, are you sure it's going through?
<pitti> seb128: I got an "accepted" for wine1.4, and excuses says "valid candidate"
<seb128> pitti, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt lists "    * i386: ia32-libs-multiarch"
<pitti> not sure why it would promote wine first without the libraries
<pitti> oh-uh
<pitti> bug!
<seb128> pitti, weird, output has it as FAILED, maybe the next refresh
<pitti> that means wine1.4 in saucy is now broken
<pitti> seb128: ia32-libs? isn't that a thing from the distant past??
<pitti> oh dear, why do we still have that package
<seb128> pitti, it's still in the archive...
<slangasek> pitti: it's a transitional metapackage now
<pitti> we had that in precise already
<xnox> -multiarch does cross-arch build-dependencies, and i don't think britney does not consider cross-arch/multi-arch dependencies...
<pitti> so I guess we can kill it, as we don't support upgrades with skipping LTSes?
<slangasek> pitti: so if you want to kill it, ok with me :)
<pitti> so it's "fix" (trivial) or kill, does anyone see a reason to keep it?
 * seb128 hands pitti a sword
<pitti> no rdepends on i386 and amd64
<seb128> killit!
<pitti> $ remove-package -m 'obsolete transitional package' ia32-libs
 * pitti sheds a tear
<pitti> I'm honored
<seb128> ;-)
<pitti> I'm still baffled why britney propagated wine1.4; it clearly depends on libgphoto2-6, so is uninstallable in saucy without also promoting libgphoto2
<pitti> or maybe, /me checks
<pitti> indeed, seems with the rebuild it lots its binary dep, although configure confirmed gphoto support
<pitti> no, I mis-looked; it does depend on libgphoto2-6 (>= 2.4.10.1)
<seb128> pitti, that's weird ... britney bug?
<Riddell> steveire: were you not going to add plasma to upstart-xsessions?
<Riddell> wait not steveire
<Riddell> didrocks: were you not going to add plasma to upstart-xsessions?
<didrocks> Riddell: hum? what? wrong ping again? ;)
<didrocks> I don't remember of that discussion at all, so I'm either senile either there are some confusion
<Riddell> hmm, someone else
<Riddell> must check logs
<Laney> probably stgraber
<Laney> you should just file an MP :-)
<Riddell> stgraber: were you not going to add plasma to upstart-xsessions?
<seb128> pitti, great, britney is happy, libgphoto moving to saucy release this time
<seb128> libusbx less happy though, it's still written as "autopkgtest for upower 0.9.21-1: RUNNING "
<seb128> when the test finished to run for hours
<debfx> Riddell: https://launchpad.net/ubuntu/+source/kde-workspace/4:4.10.3-0ubuntu4 ?
<Riddell> debfx: also needs added to /etc/upstart-xsessions
<debfx> ah, right
<seb128> cjwatson, jibel: any of you around? can you help with update_excuses having libusbx stucked on "autopkgtest for upower 0.9.21-1: RUNNING" when the test finished running for some hours?
<jibel> seb128, looking
<seb128> jibel, thanks
<stgraber> Riddell: yes, I was. I was waiting for all the flavours to finish testing their desktop session under upstart, I think everyone did but Lubuntu, so I'll ping Julien about it and then switch it on for everyone
<Riddell> stgraber: remind me again of the advantage?
<xnox> Riddell: you can open terminal, type $ stop, to logout desktop session =) should work with new neon/framework5 =)
<Riddell> that'll be handy, frameworks 5 makes it hard to leave
<stgraber> Riddell: main advantage is that any other upstart job written for the ubuntu desktop will magically work for you too, it also makes some advanced desktop scripting easier for some users (you can have offlineimap start when network-manager is connected and you have a usb stick plugged in, ...)
<stgraber> Riddell: upstart also enforces a clean parent/child relationship, so processes that double-fork for some reason will keep the upstart user session as their parent and not be moved to pid1
<stgraber> Riddell: so logout tends to be quite a bit cleaner (as everything under upstart gets killed leaving no processes behind)
<slangasek> right, so pulseaudio won't evade capture ;)
<unixpro1970> the problem with upstart is when a process forks more 3 or more times,  it has a problem tracking the correct process.
<unixpro1970> 3 or more
<cjwatson> slangasek,seb128: Yeah, this is all in adt-britney and is really something jibel needs to look at - we can force it if need be but would be better if it were fixed properly
<slangasek> ack
<xnox> unixpro1970: in user-session, we use prctl and set PR_SET_CHILD_SUBREAPER, thus we guard _all_ user session processes to be parented to user session upstart at most.
<xnox> unixpro1970: nothing should need to fork more than three times, and that's easy to avoid and test, when create upstart jobs....
<cjwatson> cjwatson@lillypilly:/home/ubuntu-archive/proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64$ cat archive/2013/08/01/saucy_i386_upower_20130801-053229.result; echo
<cjwatson> saucy i386 upower 0.9.21-1 PASS libusbx 2:1.0.16-3 pm-utils 1.4.1-11 systemd 1:204-0ubuntu7 libplist 1.8-2 gobject-introspection 1.37.4-0ubuntu3 dbus 1.6.12-0ubuntu2 glib2.0 2.37.3-1ubuntu2 eglibc 2.17-91ubuntu1 policykit-1 0.105-3ubuntu2 upower 0.9.21-1 libimobiledevice 1.1.4-1ubuntu6 dbus-glib 0.100.2-1
<cjwatson> cjwatson@lillypilly:/home/ubuntu-archive/proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64$ ls -l saucy-proposed_amd64_upower
<cjwatson> -rw-rw-r-- 1 ubuntu-archive ubuntu_archive 810 Aug  1 05:27 saucy-proposed_amd64_upower
<cjwatson> cjwatson@lillypilly:/home/ubuntu-archive/proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64$ cat saucy-proposed_amd64_upower; echo
<cjwatson> {"status": {"i386": "RUNNING", "amd64": "RUNNING", "all": "RUNNING"}, "package": "upower", "depends": {"libglib2.0-0": "2.37.3-1ubuntu2", "pm-utils": "1.4.1-11", "libdbus-glib-1-dev": "0.100.2-1", "gir1.2-upowerglib-1.0": "0.9.21-1", "libc6": "2.17-91ubuntu1", "libdbus-1-3": "1.6.12-0ubuntu2", "libdbus-glib-1-2": "0.100.2-1", "libimobiledevice3": "1.1.4-1ubuntu6", "udev": "204-0ubuntu7", "libpolkit-gobject-1-0": ...
<cjwatson> ... "0.105-3ubuntu2", "multiarch-support": "2.17-91ubuntu1", "libplist1": "1.8-2", "gir1.2-glib-2.0": "1.37.4-0ubuntu3", "libupower-glib1": "0.9.21-1", "systemd-services": "204-0ubuntu7", "libusb-1.0-0": "2:1.0.16-3", "libgudev-1.0-0": "1:204-0ubuntu7", "dbus": "1.6.12-0ubuntu2", "libglib2.0-dev": "2.37.3-1ubuntu2"}, "version": "0.9.21-1", "release": "saucy", "causes": {"libusbx": "2:1.0.16-3"}}
<cjwatson> So it's gathered the reason but then somehow failed to aggregate it, AFAICS
<cjwatson> s/reason/result/
<unixpro1970> @xnox - is this prctl functionality available on v3.0 or v3.2 kernels with upstart?
<udevbot> Error: "xnox" is not a valid command.
<unixpro1970> xnox - is this prctl functionality available on v3.0 or v3.2 kernels with upstart?
<seb128> cjwatson, not sure how to read that, is the RUNNING in those file correct or buggy?
<seb128> jibel, did you see any problem? still looking at it?
<slangasek> unixpro1970: no; why do you care about that?  upstart user sessions weren't introduced until Ubuntu 13.04.
<xnox> unixpro1970: no, since 3.4. thus precise with quantal hwe stack, or quantal and up.
<cjwatson> seb128: buggy
<unixpro1970> Good to know, thanks
<jibel> seb128, aggregation failed because version of the package tested was a version behind what has been requested.
<jibel> seb128, in that case the version of libusbx to test was libusbx 2:1.0.16-3 but the version available during the test was libusbx 2:1.0.16-2
<jibel> I'll add a waiting period until all the requirements are met before starting the tests
<cjwatson> Hm, I thought you had direct ftpmaster access now
<cjwatson> Is that not quite done yet?
<jibel> cjwatson, it is not done yet
<cjwatson> Aha
<seb128> jibel, ok, can you retry it with the current version?
<ogra_> hmm, no hallyn
 * ogra_ wonders if we have other lxc experts beyond hallyn and stgraber 
<jibel> seb128, done, there should be no invalid "running" tests left on excuses
<ogra_> i'm trying to get run-parts to work in an lxc hook script ... but kind of dont get it to work
<seb128> jibel, thanks
<dholbach> barry, happy birthday! :)
<rbasak> What's our policy for considering sponsoring a sync request after debian import freeze? Would we expect requestors to have a specific reason, or is it fine to do it if it seems reasonable?
<rbasak> Eg. bug 1206932. New minor upstream release, Debian has synced and made some other changes. Seem reasonable?
<ubottu> bug 1206932 in tomcat7 (Ubuntu) "Sync tomcat7 7.0.42-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1206932
<rbasak> Normally I'd have a specific reason for a sync, or be familiar enough with a package that I know the implications, so I'm wondering what people do from the other side of the table.
<xnox> rbasak: my threshold is low: no pointless uploads. This one is new upstream release (e.g. not just cosmetic packaging changes) & fixes a bug 1092548. So i'd try to sync it / sponsor sync, if it builds on saucy etc.
<ubottu> bug 1092548 in tomcat7 (Ubuntu) "dependency to tomcat-native is too weak (no version for libtcnative-1 specified)" [High,Confirmed] https://launchpad.net/bugs/1092548
<rbasak> xnox: OK, I'll build test and sponsor if it works then. Thanks!
<xnox> rbasak: also I'd do syncs that get packages in sync (e.g. ubuntu has -2ubuntu1 upload, debian does -3 with our -2ubuntu1 changes, I'd sync it, to not forget / allow further [auto-]syncs in the future)
<rbasak> ack
<rbasak> Oh, it seems that I can't upload tomcat7. Not sure why - it's only seeded in ubuntu-server.
<rbasak> cjwatson: ^^ would you like me to continue poking you about packages which are obviously server but ubuntu-server-dev can't upload, or should I be doing something else about these?
<cjwatson> rbasak: I expect it's low down the dependency stack.  And yes, contacting me is fine.  It's in the ubuntu-server package set now.
<rbasak> cjwatson: thank you!
<ogra_> ev, when you seeded apport and whoopsie, did you take into account the we disable recommends on touch images ?
<ev> ah, I had not
<ogra_> i just installed it manually and saw there was a recommends in the list ... not sure if we need it though
<ev> ogra_: it shouldn't need apport-symptoms or policykit
<ev> well, we have the latter regardless
<ogra_> k
<ogra_> yeah, a lot other stuff needs PK
<ev> thanks for the heads up though
<ev> that's the kind of thing that will crop up in other places, I'm sure
<ogra_> yeah, its awful
<ogra_> but i doubt we'lll get it sorted before 13.10 ... i'll add a blueprint for 14.04 though
<dobey> kenvandine, mardy: so will UOA on the phone be the samea s UOA on regular Ubuntu, for 13.10?
<kenvandine> dobey, yes
<dobey> kenvandine: is it already?
<mardy> deryck: the configuration UI will be different, but under the UI skin it's the same thing
<kenvandine> dobey, yup
<kenvandine> just different UI
<mardy> deryck: sorry, that was meant for dobey :-) ^
<stokachu> no patch pilots today?
<stokachu> jodh: would you mind taking another look at bug 1121874?
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu Raring) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<jodh> stokachu: ok, commented.
<stokachu> jodh: how does that work with the apparmor load?
 * stokachu needs to research apparmor more
<jodh> stokachu: ? init(5) documents the apparmor stanzas mdeslaur added.
<stokachu> ok ill take a look at that
<stokachu> jodh: so this hooks into audit for error reporting?
<xnox> stokachu: jodh: apparmor load works in saucy and up, but not in precise -> raring.
<stokachu> xnox: ok
<stokachu> im trying to find some documentation about apparmor load, do you guys have any reference links handy?
<jdstrand> stokachu: there isn't much to it. use something like: "apparmor load /etc/apparmor.d/usr.sbin.cupsd" (man 5 init)
<jdstrand> stokachu: use that in the upstart job instead of the apparmor-profile-load that we've traditionally used
<stokachu> ok ill look into that now
<doko> seb128, jbicha: hmm, libgtk3-common depends on d-conf, and d-conf b-d's on libgtk-3-dev ...
<jbicha> doko: you can build dconf without the editor and that should avoid the need for the GTK dependency https://git.gnome.org/browse/dconf/tree/configure.ac#n55
<doko> jbicha, thanks. why are all the gtk build not parallel?
<doko> jbicha, why is the doc build always enabled?
<jbicha> doko: honestly I don't really do much with gtk's packaging; it's quite a bit more complicated that the average gnome package
<Laney> come and ask in #debian-gnome
<doko> Laney, https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1207029
<ubottu> Ubuntu bug 1207029 in gtk+3.0 (Ubuntu) "more efficient builds and support for staged builds" [Undecided,New]
<doko> feel free to forward
<doko> hrm, are parallel builds with cdbs just broken?
<xnox> doko: they work, via magic cdbs variables.
<doko> xnox, tell me more ...
<xnox> doko: http://youtu.be/aXlnMveRt-Y?t=22s
<xnox> 1sec =)
<xnox> doko: DEB_BUILD_PARALLEL, if set, allow activating parallel builds in certain classes (makefile, automake, perlmodule, qmake, cmake, and scons classes use build commands supporting parallel builds). CDBS then uses DEB_PARALLEL_JOBS to know how many builds to launch (which defaults to parallel= parameter in DEB_BUILD_OPTIONS, but can be overridden).
<xnox> doko: "DEB_BUILD_PARALLEL = yes" should do it....
 * cjwatson is reminded of Joey's "surface" way of thinking about cdbs vs. dh
<doko> xnox, thanks. and bad gtk / gstreamer maintainers ...
<xnox> cjwatson: hm? what was that =)
<cjwatson> Pages 43-45 of http://joeyh.name/talks/debhelper/debhelper-slides.pdf
<doko> xnox, just got your reply before your URL did end =)
<doko> and the gtk builds speed up ...
<xnox> cjwatson: i think cdbs visible surface is under-estimated because it doesn't include optional team cdbs addons.....
<xnox> cjwatson: otherwise, very cool presentation =)
<cjwatson> xnox: Probably would be unfair given that he was promoting dh; I think it's reasonable to consider even just the bare surface
<cjwatson> (Of course there are plenty of dh addons too)
<utlemming> any guys from launchapd around? I can't seem to do a code checkout: http://paste.ubuntu.com/5937001/
<xnox> utlemming: i think smoser need to push some revisions if he can.... or something got rebased thus that branch is borked now.
<smoser> xnox, me having to push some revisions doesn't make any sense.
<smoser> if i pushed them they'd be there.
<smoser> if i diddn't how would it know about them to complain?
<smoser> i admit to being baffled, and assume that is something i did, and even admit to having more than one knock down fight with the importer
<smoser> and admit that it beats me
<smoser> but i dont know how to fix
<xnox> smoser: bzr got upset with stacked branches, it seems like lp:ubuntu/precise/cloud-init references smoser@ubuntu.com-20130118151237-7jeas9368k0vdy84 in it's history, previously it was part of the stacked-on branch, but now that commit is gone from the base branch and launchpad doesn't have it anymore.
<xnox> or something like that.
<smoser> xnox, so any ideas on how such a thing woudl be fixed.
<smoser> how would i know if that is in my histor?
<xnox> utlemming: I guess you want to use: bzr branch lp:~smoser/ubuntu/precise/cloud-init/sru
<utlemming> xnox: thanks...
<cjwatson> utlemming: Honestly: just fetch the source package.
<cjwatson> Unless you actually really want to fight with this.
<smoser> well i'd personall liek for it to not suck.
<xnox> smoser: if you have a shared bzr repo and/or precise branches locally. you should check if you have that revision locally. e.g. $ bzr log -rrevid:smoser@ubuntu.com-20130118151237-7jeas9368k0vdy84 and then try to push it.....
<utlemming> cjwatson: lol....sure
<smoser> i do.
<smoser> where would i "share" ?
<cjwatson> (Yes, it's a bug, but since Launchpad had its maintenance team forcibly hacked down to minimal size, it's kind of hard to support all this stuff)
<xnox> smoser: there were hidden commands to upload stuff to repositories.
 * xnox tries to recall
<smoser> xnox, so i just did:
<smoser> bzr branch -r smoser@ubuntu.com-20130118151237-7jeas9368k0vdy84 precise.sru xfoo
<smoser> cd xfoo
<smoser> so i can presumably bzr push that somewhere ?
<xnox> smoser: can you try $ bzr push lp:ubuntu/precise/cloud-init it should take some time to figure out that it needs it & should pick it up. Unless it wont...
 * xnox looks for the other command to upload ghosts.
<xnox> utlemming: actually does branching work if you disable launchpad plugin that checks version history?!
<xnox> utlemming: bzr branch --no-plugins https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/cloud-init/precise             <- works
<xnox> smoser: never-mind, it's the launchpad bzr plugin that walks too far to get the revision history and check if things are up to date. The branch in question is actually fine.
<cjwatson> Ha.  Fancy UI gets us into trouble again
<smoser> fixed!
<utlemming> xnox: yup, I'm getting what I expect now
<smoser> for lp:ubuntu/precise/cloud-init
<utlemming> xnox: with disabling the plugins
<xnox> smoser: ship it! =)
<smoser> agreed
<smoser> hm..
<smoser> xnox,
<xnox> Hmm... can't find robru anywhere
<smoser> now in trying to push a -proposed
<smoser> $ bzr push lp:ubuntu/precise-proposed/cloud-init
<smoser> bzr: ERROR: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', '<Fault -1: "Unexpected Zope exception: TypeError: (\'Could not adapt\', <SuiteSourcePackage ubuntu/precise-proposed/cloud-init>, <InterfaceClass lp.code.interfaces.branchtarget.IBranchTarget>)">')
<xnox> smoser: that's correct. -proposed doesn't exist yet.
<smoser> so how do i create it?
<xnox> smoser: by uploading a package.
<cjwatson> SRU workflow for UDD was never nice.  You need to push to a personal namespace.
<smoser> well, there have been 5 preivous uploads there.
<xnox> smoser: oh.
<cjwatson> lp:~smoser/ubuntu/precise-proposed/cloud-init/blah
<smoser> cjwatson, really? how does it work then ?
<smoser> i've seen other things that i bzr branch'd
<smoser> i think
<cjwatson> Maybe it works if the importer hasn't been broken.
<xnox> smoser: importer fails, because of tag missmatches
<xnox> smoser: so cloud-init branches are stale: http://package-import.ubuntu.com/status/cloud-init.html#2012-07-04 20:18:13.838295
<xnox> utlemming: lp:ubuntu/*/cloud-init are out of date. use $ pull-lp-source cloud-init precise
<smoser> so how would we fix that mismatch ?
<smoser> can't i just push override the thing?
<xnox> smoser: that's what causes the missmatch. udd stores old tag revids in sql database, when they don't match what's in lp:ubuntu/package udd throws a hizzy fit
<xnox> smoser: lp:udd =)
<smoser> xnox, http://paste.ubuntu.com/5937102/
<smoser> that is what it doesn't like.
<xnox> smoser: pull-lp-source cloud-init 0.6.2-0ubuntu1 doesn't have that file either. Plus it's evil to do that with 3.0 (quilt) format, as the branch no longer follows udd convention of patches applied.
<smoser> xnox, right.
<smoser> its when i was fighting the importer
<smoser> i gave up at some point.
<smoser> i relaly think its silly to revision control .pc
<smoser> but i gave up fighting a robot over that.
<xnox> it's kind of like slangasek using git-bzr to push packages into lp:ubuntu/* with empty directories, which git ignored yet package had and bzr noticed /o\
 * xnox all your .pc are belong to us
<xnox> smoser: i can purge all branches, and make udd reimport them, but all human commits/pushes will be forgotten.
<xnox> smoser: but branches will become up-to-date based on package history.
<smoser> xnox, i'm actually fine with that. if it works.
<smoser> as long as it wont cause issue with lp:cloud-init
<smoser> concern is if they have staked branch history or something.
<xnox> smoser: nah, udd only can access lp:ubuntu/* branches and they do not share history with lp:$projects at all.
<smoser> xnox, then do it.
<smoser> i'd happily , *very happily* let the import robot win
<dobey> kenvandine: is there a trivial (simple) example of simply requesting credentials for a service, from UOA?
<kenvandine> http://developer.ubuntu.com/resources/technologies/online-accounts/for-application-developers/
<kenvandine> dobey, ^^
<kenvandine> dobey, there is also a QML example in accounts-qml-module
<dobey> python is what i wanted. but that isn't exactly trivial :)
<smoser> xnox, can you / did you kick that importer ?
<Noskcaj> kirkland, i think the best option for testdrive translations is to re-make the .pot and start from scratch
<kirkland> Noskcaj: okay -- then I agree!
 * kirkland is clueless on translations
<Noskcaj> kirkland, We currently have three ones, all with outdated .pot files. the bzr branch, the launchpad translations and the .orig release
<kirkland> Noskcaj: okay;  wouldn't it be best to use LP translations?
<Noskcaj> kirkland, yes, and we still would
<kirkland> Noskcaj: cool
<Noskcaj> kirkland, it seems i'm worse at making .pot files than you.
<kirkland> Noskcaj: do you need anything else from me, at this point, to proceed?
<Noskcaj> I'll continue trying to get this working. I'll need to be part of lp:~testdrive to finish it though
<kirkland> okay
<kirkland> Noskcaj: remind me of your lp id?
<Noskcaj> ~noskcaj
<kirkland> Noskcaj: okay, added
<Noskcaj> thanks
<kirkland> Noskcaj: please continue to run any code merges through roaksoax and I
<Noskcaj> of course
<kirkland> Noskcaj: thanks
<dobey> does autopkgtest get run on armhf for anything?
<gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html could just be closed
<gQuigs>  for example: xserver-xorg-video-openchrome, gnome-power-manager and moon (moonlight)
<xnox> dobey: no. only i386/amd64. armhf tests are setup and operated separately by pes, e.g. autopilot tests.
<xnox> smoser: cloud-init is still running.
<xnox> smoser: http://package-import.ubuntu.com/status/
<dobey> oh ok
<smoser> xnox, thank you.
<Noskcaj> kirkland, worrying thing i just found in testdrive; we've been translating most lines twice, the testdrive-gtk file is redundant
<Noskcaj10> kirkland, roaksoax: any idea what's causing http://paste.ubuntu.com/5937932/
#ubuntu-devel 2013-08-02
<pitti> Good morning
<pitti> ev: good morning
<pitti> ev: WDYT about http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/data/whoopsie-upload-all ?
<pitti> ev: this skips all the hooks and UnreportableReason stuff (as daisy doesn't care about that anyway, right?)
<pitti> ev: it's a completely noninteractive script which we can run after e. g. CI/autopilot tests on the phone (or elsewhere) to upload everything to whoopsie, but not to LP or any other crash DB
<pitti> (plars and gema were asking for that specifically for phone CI testing)
<pitti> ev: this collects package+os+gdb stuff; anything else missing?
<rickspencer3> hi msm
<rickspencer3> oops, wrong channel ;)
<ev> pitti: having a look now
<seb128> jibel, hey, do you if the firefox autopilot tests hit an infrastructure issue?
<seb128> jibel, seems they hit a timeout
<seb128> http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-firefox/ARCH=amd64,label=adt/102/
<seb128> jibel, the gtk+3.0 on update_excuse seems buggy as well
<seb128> it lists itself, and it lists other tests as RUNNING when they are done for hours
<seb128> jibel, same issue than yesterday of picking the wrong version?
<jibel> seb128, I am not sure it is infrastructure or maybe a test is firewalled, but they hang starting with saucy.
<seb128> chrisccoulson, ^
<jibel> seb128, it's on my list for next week before holidays
<jibel> seb128, I'll unblock gtk+3
<seb128> jibel, thanks ... and thanks
<chrisccoulson> seb128, jibel, i can't reproduce it here. and from looking at the log, it doesn't look like it even gets to the point of starting the test harness
<seb128> jibel, and we need you, they shouldn't let you go in holidays :p
<ev> pitti: syntactically it looks fine, but I'm not clear on the motivation for this over using something like apport-noui, which seems to do much the same thing?
<ev> pitti: oh, is it because you don't want to go through Launchpad and don't want jenkins to tear down the machine state before whoopsie has had a chance to upload?
<jibel> ev, correct.
<ev> cool, looks good to me then
<pitti> ev: right
<pitti> ev: we also found a funny corner case with apport-noui yesterday
<pitti> ev: when running it on a powerd crash, -noui does nothing as it would ask a "this uses non-disto libraries; are you sure that you want to send this?" questino which -no-ui answers as "no"
<ev> oh?
<pitti> ev: this reduced script avoids this and send everything
<ev> yikes
<ev> any thoughts on how we can resolve that, short of flipping the default to "yes"?
<pitti> I'm not sure that we do want to resolve that in general
<ev> ah right
<pitti> all the UnreportableReason stuff are things that we don't want to see on LP
<pitti> they make (some) sense on errors.u.c. by way of sheer mass, but individual Unreportable reports are just noise
<pitti> as whoopsie-upload-all does not upload to anything but whoopsie, we can send those
<pitti> ev: ^ I think that's what you intend, right?
<ev> so that brings up an interesting point. Should we kill the Launchpad path for apport-noui, given that there's no sense in launching a browser for those? :)
<pitti> ev: also, if whoopsie creates an .uploaded, it's really "done", so the testbed can disappear in the next second? or does it still do communication after that?
<pitti> ev: so apport-noui would essentially do process_report()?
<ev> yes
<ev> (just checking on your whoopsie question)
<ev> pitti: yes, whoopsie is done when the .uploaded file exists
<ev> core file upload and all
<pitti> ev: great, thanks for verifying
<jibel> chrisccoulson, wrt firefox tests, from the logs inside the VM, the session doesn't even start
<jibel> ** (gnome-session:10322): CRITICAL **: We failed, but the fail whale is dead. Sorry....
<jibel> http://paste.ubuntu.com/5939469/
<chrisccoulson> jibel, ah, interesting
<jibel> and the test is blocked on the following processes http://paste.ubuntu.com/5939474/
<chrisccoulson> jibel, thanks. are there any messages from any other session components?
<jibel> chrisccoulson, nothing else. On my machine running saucy, xfvb-run dies the same way when executed directly and the same arguments then FF tests
<jibel> than
<jibel> s/xvfb-run/gnome-session/
<chrisccoulson> jibel, yeah, i'd expect that to be the case, unless you run it from inside the test script (which sets up a home directory and test session configuration)
<jibel> chrisccoulson, is there any other information I can collect from the testing env?
<chrisccoulson> jibel, not sure at the moment, just trying to think of things that might make it fail
<chrisccoulson> jibel, it might help to run gnome-session with the --debug option
<jibel> pitti, ev I tried whoopsie-upload-all on a phone with 2 crash files (powerd and gallery-app) and after 700s it is still waiting for .uploaded files
<jibel> pitti, ev where should I look to find why it is not uploading them?
<pitti> I asked ev about that yesterday, unfortuantely whoopsie is not very talkative
<ev> jibel: is whoopsie running?
<ev> yes, let's fix that now
 * ev works on a branch to be more verbose
<jibel> ev, yes it is running
<pitti> ev: w-u-a actually fails if pidof whoopsie fails
<pitti> so it should at least discover that case quickly
<ev> jibel: so I've seen a weird bug on my nexus where whoopsie doesn't seem to be using its inotify watch initially. calling restart whoopsie fixes this for me
<ev> jibel: can you give that a try and let me know?
<ev> pitti: *nods*
<jibel> ev, restart whoopsie fixed it
<ev> jibel: okay, that one is going up a few pegs on the todo list
<pitti> something wrong with inotify on the phone?
<infinity> xnox: Can you merge vtk?
<xnox> infinity: yes.
<ev> pitti: only initially. The whoopsie that spawns from the upstart job at boot doesn't seem to be paying attention to /var/crash, but if you restart it, it's fine
<xnox> infinity: Can you denew tcl8.6 for me please?
<infinity> xnox: Sure.
<SuperLag> Are there any Launchpad admins in here?
<SuperLag> or am I asking in the wrong place?
<xnox> SuperLag: it's best to just ask a question, then we can answer and redirect you.....
<xnox> s/and/or/
<SuperLag> trying to consolidate email under one account, and I forgot I'd actually registered two addresses
<SuperLag> (on Launchpad, that is)
<ev> pitti: so I'm just realising that whoopsie is super quiet because it relies on upstart's logging, but that means in its daemon mode that you only get the messages it prints to stderr before the fork and privilege drop. As mentioned above, fixing :)
<cjwatson> SuperLag: You want #launchpad
<infinity> SuperLag: https://help.launchpad.net/YourAccount/Merging
<infinity> SuperLag: (And what cjwatson said)
<pitti> ev: I tried yesterday to just run it in the foreground, but that also didn't say anything
<xnox> ev: run in foreground, and instead of forking, do sigstop yourself & in the upstart job do "expect stop", upstart will send sigcont and will consider whoopsie as started.
<xnox> ev: you might want to call sigstop if a command line option is present, or if there is UPSTART_JOB environment variable and/or somesuch.
<SuperLag> cjwatson: infinity: thank you. Much appreciated.
<cjwatson> doko: I noticed the separate dh-python package just hit unstable.  Do we want it in saucy, and/or does it need a new python3-defaults first?
<cjwatson> Likewise I wonder if anyone cares about having dh-golang in saucy
<doko> cjwatson, I'll have to look at python3-defaults. dh-golang sure, will be universe anyway
<Daviey> ooo, i had not seen dh-golang .. That sounds interesting.
<doko> no, it's not that interesting, and because juju shoves everything into one package, it doesn't help either
<Daviey> ugh
<cjwatson> Likewise golang-godebiancontrol-dev golang-mux-dev golang-pq-dev golang-pty-dev?
<cjwatson> I assume from the package names that those are still static linking, but having some patterns for Go packaging outside golang itself seems like a step forward
<davmor2> seb128: on saucy if you let the system lock the lightdm password unlock screen seems to look like gnome rather than Ubuntu is that a bug or deliberate, do you happen to know?
<doko> cjwatson, sure, won't hurt
<seb128> davmor2, it's likely an environment problem due to the upstart user session
<seb128> we have similar problems with indicators
<seb128> XDG_CURRENT_DESKTOP is not correctly set
<davmor2> seb128: that would probably explain it
<smoser> xnox, http://package-import.ubuntu.com/status/cloud-init.html#2013-08-01%2022:12:33.994912 ?
<smoser> is that just retriable ?
<xnox> smoser: no idea. i'll poke lp folks about it.
<smoser> thank you. 401 error on launchpad access.
<jdstrand> tyhicks: hey, mardy and I were chatting a bit about online accounts. he will be able to handle confined apps fine, as well as unconfined (he'll add 'unconfined' as allowed on account creation-- I asked him to talk to you about that)
<jdstrand> tyhicks: but there is a small corner case that may or may not be interesting
<jdstrand> tyhicks: apparmor-easyprof-ubuntu provided an 'unconfined' template for special circumstances when a click package should not be confined (note to app developers, using this for your app will almost certainly result in the upload being rejected)
<jdstrand> tyhicks: these unconfined apps label will still be of the normal form since it is generated via the click apparmor hook: appname_name_version
<jdstrand> tyhicks: which means that they won't match the preseeded 'unconfined' label mardy is using. I don't think this is actually a problem though (and may be a feature): these unconfined click packages will be prompted just like any other click pacakge
<jdstrand> tyhicks: I don't think there is anything to do, but I wanted to at least mention it
<jdstrand> tyhicks: change of subject: here is an updated ubuntu-unity-hud abstraction: http://paste.ubuntu.com/5940168/
<jdstrand> mardy: I was looking at friends-app to test online accounts. it is accessing ~/.config/libaccounts-glib/accounts.db directly
<jdstrand> mardy: I'm thinking it is trying to see which accounts are available. shouldn't this be happening over dbus? is friends-app doing it wrong?
<tsdgeos> anyone knows why intalling wine1.4 in saucy wants to remove ia32-libs?
<cjwatson> It probably depends on the proper multiarch versions instead
<cjwatson> ia32-libs is obsolete
<cjwatson> We explicitly made sure everything in it was replaced by multiarch versions
<tsdgeos> cjwatson: not sure i understand that :D
<tsdgeos> cjwatson: fwiw it also wants to uninstall ia32-libs-multiarch:i386
<cjwatson> Fairly sure that's obsolete too
<cjwatson> I can't tell by piecemeal reports whether what it wants to do is correct.  pastebin the whole output
<tsdgeos> sure
<cjwatson> But we deleted ia32-libs entirely in saucy
<cjwatson> Wine shouldn't need it or ia32-libs-multiarch any more
<tsdgeos> so one has to install libs one by one to get 32 bit deps?
<xnox> tsdgeos: didn't it migrate without it's libs or something
<jdstrand> tyhicks: please use this instead: http://paste.ubuntu.com/5940216/
 * xnox looks up
<cjwatson> tsdgeos: No, wine1.4 already depends on the libraries it needs
<cjwatson> ia32-libs was an unmaintainable horror.  It is not coming back
<tsdgeos> cjwatson: sure, i mean if e.g. i have a non .deb game
<tsdgeos> cjwatson: sure, makes sense to me, always found it weird we shoved all the stuff in there
<cjwatson> tsdgeos: You might have to install the odd library to support it, but that's just the same as if you got a 64-bit non-.deb game
<tsdgeos> yep
<jdstrand> mardy: right, so if I give access to @{HOME}/.config/libaccounts*/*db, then friends-app works. if I take it away, it does not. It doesn't use the DBus interfaces you mentioned
<tsdgeos> cjwatson: wasn't complaining
<tsdgeos> cjwatson: http://paste.ubuntu.com/5940223/
<cjwatson> weird> indeed, ia32-libs was always intended to be a transitional measure - it was just transitional for longer than anyone involved hoped
<tsdgeos> so removes some gphotos but then install some others
<jdstrand> mardy: I guess it is doing it wrong. account-console seems to be doing the same fwiw (I could only get 'list' to do anything meaningful)
<tsdgeos> if the ia32libs is correct
<tsdgeos> doesn't look that bad
<cjwatson> Looks fine to me
<tsdgeos> tx :-)
<cjwatson> I suspect a dist-upgrade would have done the gphoto stuff even without wine
<cjwatson> You might not want to remove the "automatically installed and no longer required" stuff until you confirm that any other unpackaged 32-bit binaries you have lying around don't need those
<ev> I don't suppose anyone has some free time for code review? https://code.launchpad.net/~ev/whoopsie/android-serial/+merge/178306 opinions definitely welcome on what we use to form the system identifier on Android
<ev> trying to get as much hardware-static data in there as possible, to reduce the risk of collision
<xnox> ev: wasn't there system-settings already listing IMEI and something else. Cause on the phone / sim capable devices IMEI is usually more unique.... (excluding usb-SIM dongles that is)
<xnox> IMEI is suppose to be unique in the world.
<ev> xnox: investigating, but do feel free to update the MP with those comments
<xnox> ev: you might want to fetch a Nexus4 in the office to test.
<ev> oh yes, my nexus 7 isn't going to have that, is it? :D
<xnox> ev: there is grouperg with sim cards, but i guess you have a wifi only model =)
<slangasek> ev: so I'm strongly opposed to using hybris for something like this
<ev> slangasek: oh?
<slangasek> we should only be relying on the android layer for critical bits that must be done through android
<slangasek> is this possibly exposed in /sys
<slangasek> ?
<ev> interestingly, grepping through /sys ends up rebooting my nexus
<xnox> ev: reboot works \o/
<ev> it does show /sys/devices/platform/grouper_misc/grouper_chipid and /sys/devices/virtual/android_usb/android0/iSerial before it goes down
<ev> but those will vary from device to device, obviously
 * slangasek nods
<slangasek> but there may be a suitable kernel-level abstraction?
<xnox> ev: ideally ubuntu-system-settings would expose those numbers that you can use.... but then again whoopsie can't just depend on system-settings (especially if system-settings is the one that crashes....)
<ev> xnox: ubuntu-system-settings gets them from the same place
<ev> the about page uses hybris' property_get
<ev> slangasek: possibly; I'll have a look
<slangasek> sure... but ubuntu-system-settings should provide some settings-querying interface that's not hybris
<slangasek> it may not be there yet, but in that case it's a bug in u-s-s that should be filed
<ev> slangasek: would you mind updating the MP with your thoughts on why hybris is bad for this?
<slangasek> ev: can't do it this moment, I'll try to remember :)
<ev> slangasek: *nods* thanks
<semiosis> fyi, packages in the us-east-1 ec2 mirror are not passing signature validation. https://forums.aws.amazon.com/thread.jspa?threadID=131469
<semiosis> i just switched to us.archive.ubuntu.com and everything works now
<semiosis> if this isn't the right place to report this, please forgive me, where should I go?
<xnox> semiosis: not sure who manages ec2 mirrors, but you can also try #ubuntu-mirrors channel which is usually where mirror network is co-ordinated.
<semiosis> great, thanks!
<dobey> barry, doko: any chance one of you could get twisted-py3 updated to 13.1.0 ? and maybe plain twisted too?
<cjwatson> doko: Should I retry https://launchpad.net/ubuntu/+source/gcc-snapshot/20130731-1ubuntu1/+build/4841314 ?  Looks like the builder lost its mind.
<cjwatson> kirkland: Looks like you dropped doko's 1.4-0ubuntu2 change from anerd.  Do you think you could restore it so that the new version can migrate from -proposed?
<cjwatson> (bug 1139188)
<ubottu> bug 1139188 in anerd (Ubuntu) "Unsatisfiable dependency on powerpc" [High,New] https://launchpad.net/bugs/1139188
<cjwatson> mterry,jdstrand: If I promote ust (bug 1203589) for mir, I guess I should leave the bug open for a security review?
<ubottu> bug 1203589 in ust (Ubuntu) "[MIR] ust" [Undecided,Triaged] https://launchpad.net/bugs/1203589
<mterry> cjwatson, yes, I assume that's easiest for jdstrand
<cjwatson> mesa is dep-wait on mir, so now seems like a reasonable point for me to start promotions
<cjwatson> For some value of "now" that means "over the next day or so".
<seb128> cjwatson, mterry, jdstrand: I think didrocks&co were counting on stuff not being promoted/building before monday ... but he asked Laney to put a britney lock in case that's happening
<cjwatson> seb128: do you know why?
<cjwatson> and surely this doesn't go for mir's dependencies?
<seb128> <didrocks> Laney: xorg-server with Mir support is coming
<seb128>  well, it's already build-depending
<seb128>  but apparently, the version set is tomorrow's Mir version
<cjwatson> I see Laney didn't know either, judging by his comment in the hints file
<seb128> <didrocks> (which should be blocked through the week-end anyway as Mir is in universe, not promoted yet)
<seb128>  but as the Mir MIR was acked
<seb128>  maybe someone will promote during the week-end
<kirkland> cjohnston: doh, sure, I never saw a merge or anything from doko
<seb128> cjwatson, ^ that's what didrocks said
<Laney> they don't want the xorg-server to migrate over the weekend
<cjwatson> seb128: Eh, so that makes no sense
<cjwatson> If it dep-waits on a newer version, it'll keep dep-waiting
<seb128> well, until mir daily land tomorrow
<seb128> when nobody is around
<seb128> I think it was just being on the paranoid side
<seb128> and not wanting those stuff to hit saucy on saturday
<seb128> in case there is an issue and nobody around
<cjwatson> OK, so this doesn't apply to mir's dependencies
<seb128> right
<seb128> I think didrocks just didn't want the new xorg/drivers to hit saucy while they are not around
<seb128> I don't get why they uploaded those today though, if they didn't want them to land, but I can't reply to that one either
<cjwatson> No, indeed.  It's extra cognitive load for anyone trying to move -proposed along.
<seb128> I *think* they aimed at having it done today, and noticed the wrong mir depends
<seb128> by which time it was getting late to be able to get it in today
<seb128> and didrocks decided to back out
<seb128> just my theory...
<d4m> Seeing bad signature errors on ubuntu repos on ec2 and s3, any maintainers here?
<cjwatson> Probably just a race - I expect it'll go away shortly
<d4m> cjwatson: load issue?
<cjwatson> No, the update process for mirrors is unfortunately not totally atomic
<cjwatson> So you can get unlucky
<d4m> cjwatson: Oh, really?  ok.
<cjwatson> And get Release and Release.gpg out of sync
<d4m> cjwatson: Ah, that is exactly what I am seeing.
<cjwatson> It generally clears up the next time the mirror updates
<d4m> cjwatson: What is the update interval?
<cjwatson> No idea, sorry
<cjwatson> The master updates several times an hour, but mirrors rather less so
<d4m> I c, ty
<cjwatson> Master looks fine, anyway
<doko> dobey, sorry, not planned
<doko> cjwatson, given back
<seb128> cjwatson, oh, I just remembered I had a click question for you ... I went over the system settings with lool, and he suggested that computing the size of click packages (e.g their installed size + owned datas) should probably be service provided by click itself ... was that discussed before?
<seb128> cjwatson, is that a bug report/mailing list/irc/... topic?
<xnox> d4m: being looked into on #ubuntu-mirrors
<seb128> cjwatson, his point is that several part of the systems will need that info (at least the settings and the installer app) so it would make sense to have a common implementation
<d4m> xnox: ty
<seb128> stgraber, around?
<kirkland> cjwatson: done;  uploaded
<stgraber> seb128: kinda, what's up?
<seb128> stgraber, I emailed the phone list and CCed you, no hurry, it's about device reset/factory reset
<seb128> stgraber, lool suggested that it might be close enough of what the system image was doing to add the feature there
<seb128> stgraber, I wanted to get your opinion on that ... but we can discuss next week
<stgraber> seb128: right, factory reset is basically a two lines file to dump in /cache/recovery/ubuntu_command, then call reboot -f recovery
<stgraber> seb128: should be trivial for barry to add this as a flag or dbus API call
<seb128> stgraber, excellent!
<seb128> stgraber, thanks
<barry> stgraber, seb128 please file a bug with all necessary info.  you're right it probably wouldn't be difficult.
<seb128> barry, thanks, I'll do that
<dobey> kenvandine: hrmm, a small discrepency between the online-accounts docs, and the real world. docs say "/usr/share/accounts/service-types/" but folder name is "service_types"
<dobey> also, _ is evil
<_ogra_> _ isnt evil ...
<_ogra_> _  gives you wings on IRC !
<sarnold> haha
<__barry__> if single underscores are good, double underscores are better
<ogra_> streched wings !
<dobey> python nerd.
 * __barry__ is a magic attribute
 * ogra_ calls barry A380 from now on :)
<barry> ogra_: you calling me an airbus?!
<ogra_> you had big wings :)
<xnox> barry: whatever, 737-800 series =)
<seb128> barry, stgraber: https://bugs.launchpad.net/ubuntu-system-image/+bug/1207860
<ubottu> Launchpad bug 1207860 in Ubuntu system image "having a factory reset option would be nice" [Undecided,New]
 * ogra_ bets nobody wants to be called dreamliner
<dobey> xnox: surely you mean 767 or 777. 737 is pretty small :)
<barry> stgraber: what's the "two line file"?  can you fill that in on the bug?
<dobey> kenvandine: also, is there API docs for the online accounts stuff that's in 13.10, anywhere?
<dobey> also, why does http://developer.ubuntu.com/resources/platform/api/ still list 11.10 (which is EOL), but doesn't list 13.04?
<stgraber> barry: actually, just one: format data
<barry> stgraber: thanks
<kenvandine> dobey, use the docs in libaccounts-glib-doc
<kenvandine> i don't think the online ones have been updated in ages...
<dobey> are those posted anywhere on-line?
<kenvandine> i guess not
<kenvandine> the API docs on d.u.c come from the packages
<kenvandine> but i guess those aren't automatically updated
<dobey> are there no docs for the qt5 lib?
<kenvandine> dobey, not in the package
<kenvandine> but i think they could be generated
<dobey> kenvandine: in normal ubuntu 13.10, are the web page views supposed to pop up in an external window currently?
<kenvandine> you mean in a browser?
<kenvandine> it should be embedded in g-c-c
<dobey> no, it's not a browser
<kenvandine> oh
<dobey> it's jut a window with the widget
<dobey> it is webkit, but it's in a separate window
<kenvandine> right...
<dobey> i guess because they are qml, and g-c-c isn't?
<kenvandine> yeah
<kenvandine> what are you working on?
<dobey> is that known/being fixed?
<dobey> i'm just looking at what we can do for u1 with regards to UOA, so i can tell ralsina/etc if it's a good/bad idea to move to UOA for it :)
<kenvandine> that will be designed after we switch to MIR on the phone
<kenvandine> s/designed/changed/
<kenvandine> it'll get embedded
<kenvandine> but we don't have xembed available
<kenvandine> so this is a temporary solution until we can rely on mir to do that
<dobey> right. i presume GtkSocket/plug will work differently on mir
<dobey> is mir going to be the default on non-phone too?
<kenvandine> for the desktop we can still use g-c-c
<kenvandine> for now
<dobey> (so many announcements lately i can't remember them all)
<kenvandine> which does xembed
<dobey> well right
<kenvandine> i don't recall either :)
<dobey> so how will mir on the phone have any impact on what g-c-c does?
<dobey> kenvandine: is "emapthy-accounts-plugin" a built-in thing or something?
<psusi> cjwatson, just wanted to ping you again about the parted upload, and also my dm application ( pretty sure you said at one point you'd sponsor me )
<doko> since the last kernel update my wireless is so unstable
<Noskcaj> kirkland, can you review https://code.launchpad.net/~noskcaj/testdrive/enable-translations ?
<mcs-seattle> Hi. Am I in the right place to help with hardware integration for Ubuntu?
<mcs-seattle> I am a developer and I'd like to know the best way to help.
<dobey> mcs-seattle: what do you mean by "hardware integration" exactly?
<mcs-seattle> dobey: Hardware integration meaning supporting new laptops on the market. I have a new one and I would like to get my hands dirty.
<dobey> mcs-seattle: #ubuntu-kernel might be a good place for you to discuss issues and bugs in then. if you want to fix kernel issues that's the best place to hang out. this channel is more for general development of the set of packages which make up ubuntu as a whole
<mcs-seattle> dobey: Thanks. I was referred here by #ubuntu. I'll jump into #ubuntu-kernel -- thanks for pointing me in the right direction.
<dobey> sure
<doko> infinity, is it intended to apply all the eglibc patches for archs that we don't have?
#ubuntu-devel 2013-08-03
<infinity> doko: Yes, lowers the maintenance burden and bizarre bug delta between us and Debian.  Is there a specific patch causing issues, or just a general concern that one might>
<infinity> doko: ?
<hyperair> does anyone know where nagios dumps its apache configs?
<GridCubexmir> hello, how are yeh, where should i ask a few things abour mir :)
<GridCubexmir> im running an xmir/xubuntu test
<jdoles> Why is boost packaged in the way that it is on LTS? libboost-locale1.48-dev has no associated debug package.
<jdoles> libboost-dbg does exist, but it doesn't include locale...
<jdoles> All in all, it seems like a total failure.
<infinity> jdoles: http://ddebs.ubuntu.com/pool/universe/b/boost1.48/ might help.
<infinity> jdoles: How or why the -dbg package is mangled or broken is another question, and I'm not sure, but the ddebs might be correct at least.
<infinity> jdoles: Also, libboost-1.48-dbg might do better than libboost-dbg (which depends on 1.46)?
<jdoles> infinity: what line do I need to have in sources.list in order for those to be visible in Synaptic?
<jdoles> infinity: I already have a couple of them.
<jdoles> infinity: e.g. deb http://ddebs.ubuntu.com precise-updates main restricted universe multiverse
<infinity> jdoles: That would do it, yes.  Though, as I pointed our, your problem could just be a version mismatch.  You said you were using libboost-locale1.48-dev but libboost-dbg.  1.48 versus 1.46
<infinity> s/our/out/
<jdoles> infinity: I don't care which version is used.
<jdoles> infinity: all I am interested in is dbg packages for libboost-locale1.48-dev.
<jdoles> infinity: and in such a way that they are visible in Synaptic.
<infinity> ...
<infinity> Which wouldn't be in libboost-dbg, because it's version 1.46.
<jdoles> infinity: that's why I installed libboost-locale1.48-dev.
<infinity> So you want libboost1.48-dbg
<jdoles> infinity: and then found out there was no dbg package...
<jdoles> infinity: and then asked here.
<jdoles> infinity: I thought that part was clear.
<infinity> jdoles: It was clear, yes.  And then I went version hunting after I gave the ddeb advice and realised that "libboost-dbg" depends on version 1.46, and libboost-locale1.48-dev is (obviously) 1.48
<infinity> jdoles: So, again, try installing libboost1.48-dbg
<jdoles> infinity: thanks
#ubuntu-devel 2013-08-04
<phillw>  Hi good people, is apt-get easy link for such areas as https://help.ubuntu.com/community/RestrictedFormats going to be made working again, or do we need to remove it from the wiki pages and use the terminal command only?
<xnox> GridCube: see #ubuntu-mir, but note that most people are away during weekend.
<xnox> jdoles: just precise-updates is not enough, you should have precise, precise-security as well.
<GridCube> xnox, :) thanks, i found it yesterday and got the answer i needed, there is no support for multiple monitors so far
<xnox> GridCube: there are bugs open and it's work in progress. I am waiting for it as well.
<jdoles> xnox: I have those too.
 * xnox is confused about zsh FTBFS
<jdoles> xnox: do you know where a fastcgi application started by Apache2 has its current working directory?
<xnox> jdoles: hm.... not really, no. Why are you asking me? =) i'm not really fastcgi nor apache2 expert.
<jdoles>  I think I will just have to redesign the application then, if nobody can tell me this.
<xnox> jdoles: what application?!
<cjwatson> jdoles: Arrange for it to hang around for long enough that you can inspect the running process, and then look at /proc/PROCESS-ID/cwd
<cjwatson> Or indeed just have it print out /proc/$$/cwd or the equivalent in whatever language is involved
<cjwatson> print out> I mean print the target of that symlink
<jdoles> xnox: it's a question which is not dependent on the application.
<jdoles> cjwatson: thank you.
<jdoles> cjwatson: pwdx should be implemented with that.
<jdoles> cjwatson: because your solution works in an environment where pwdx doesn't.
<cjwatson> pwdx *is* implemented with that
<cjwatson> (I just checked)
<jdoles> cjwatson: that's odd.
<cjwatson> There's no other way to get the working directory of another process, as far as I know
<jdoles> cjwatson: pwdx: invalid process id: 12341
<cjwatson> Then that process doesn't exist, so you're calling it wrong ...
<jdoles> cjwatson: no, because file /proc/12341/cwd does work.
<cjwatson> Dunno.  strace it to find out
 * cjwatson has to go attend to baby
<jdoles> cjwatson: it's not locale independent.
<jdoles> cjwatson: I don't think the locale should matter this much at least, and as such it's a bug.
<cjwatson> jdoles: Where's the locale-dependency?  (That said I can't say I even knew about pwdx before you mentioned it; seems like a niche tool)
<lifeless> cjwatson: remember me mentioning a failed GPT grub environment? I held of filing until I upgraded to R, in case it was fixed. It wasn't.... https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1208268
<ubottu> Launchpad bug 1208268 in grub2 (Ubuntu) "grub not recognising my GPT+mdadm+lvm layout" [Undecided,New]
<lifeless> cjwatson: if you could let me know what info you need to reproduce, I'll add it in asap
#ubuntu-devel 2014-07-28
<pitti> Good morning
<pitti> smoser: thanks, will sort out the autopkgtest bug today
<wasaby> hi guys. just dropping by to ask about crypt(3) blowfish support in libc6. before i make a feature request on launchpad i'd just like to know whether there is a particular reason for it not being supported or is it simply because nobody cares :)
<dholbach> good morning
<mvo_> jibel: good morning, did you had a chance to test the upgrade with https://launchpad.net/~mvo/+archive/ubuntu/lp1347721 yet?
<jibel> mvo_, not yet. on my list for today when the machine is a bit less busy and responds to ssh
<mvo_> jibel: thanks
<pitti> jodh: hey James, how are you?
<pitti> jodh: so what can we do about bug 1346337? it's blocking the new systemd version
<ubottu> bug 1346337 in upstart (Ubuntu) "test_util_check_env "cgroup sandbox" test fails with cgmanager installed" [Undecided,New] https://launchpad.net/bugs/1346337
<tsdgeos> is wine installable for you in utopic?
<cjwatson> tsdgeos: It would be more helpful to state the error you're seeing
<cjwatson> Also what architecture you're using
<tsdgeos> cjwatson: http://paste.ubuntu.com/7883421/ amd64
<cjwatson> tsdgeos: Have you disabled multiarch?
<tsdgeos> i *think* it may be because of this
<cjwatson> dpkg --print-foreign-architectures
<tsdgeos> cjwatson: http://paste.ubuntu.com/7883423/
<tsdgeos> cjwatson: http://paste.ubuntu.com/7883425/
<cjwatson> Looks like some of the libraries that are common between KDE and Wine aren't Multi-Arch: same, judging from 7883423
<cjwatson> So that will have to be fixed before you can coinstall those two systems
<tsdgeos> this used to work :/
<tsdgeos> i don't even know what is libroar :D
<cjwatson> I can fix dnprogs today at least
<tsdgeos> roaraudio sound server
<tsdgeos> :D
<tsdgeos> seems to be an openal dependency
<tsdgeos> cjwatson: who should i bug about this? open a bug? (not sure i understood your "I can fix dnprogs today at least" tbh)
<cjwatson> tsdgeos: there are already bugs for this in Debian, by the looks of things, so it should really be sorted out there
<tsdgeos> cjwatson: do you have a bugnumber/url?
<cjwatson> tsdgeos: dnprogs is the source package that builds libdnet, and I'm going to convert it to multiarch in Debian which unblocks part of this
<cjwatson> tsdgeos: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756032 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755846
<ubottu> Debian bug 756032 in libdnet "libdnet: should be multiarch because apparently roaraudio wants it for some unfathomable reason" [Wishlist,Open]
<ubottu> Debian bug 755846 in libroar2 "libroar2: no multiarch possible" [Serious,Open]
<tsdgeos> cjwatson: thanks :)
<cjwatson> tsdgeos: oh and also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755935, which the bug states is in progress
<ubottu> Debian bug 755935 in src:openslp-dfsg "openslp-dfsg: Add multi-arch support" [Wishlist,Open]
<pitti> jodh: cheers!
<pitti> infinity, arges, bdmurray: can I ask any of you to review/accept the postgresql microrelease SRUs? (lucid/precise/trusty) people keep pinging..
<infinity> pitti: Ask me again in an hour when I'm awake? ;)
<pitti> infinity: heh, sleep well until then!
<xnox> mvo_: i've sent you, some of your code from 2012 for review =) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756287
<ubottu> Debian bug 756287 in apt-utils "apt-utils: Allow to generate contents only" [Normal,Open]
<mvo_> xnox: heh :) thanks!
<xnox> mvo_: i do have questions about cachedbs in apt-ftparchive, since there are some vague comments that dists/bin/src caches are incompatible with contents ones, hence in launchpad at the moment contents and Packages/Sources generation is separated and doesn't share caches.
<mvo_> xnox: hm, that sounds like a bug if thats the case, does infinity or someone else knows more here?
<xnox> is that actually true? how to validate that? (e.g. are cache structures / format published somewhere)
<xnox> mvo_: right, well, it's vague comments from the past, in the launchpad code base.
<mvo_> xnox: hm, maybe we can find out via bzr blame who wrote it so that we can find out more :) ?
<xnox> Jeroen Vermeulen <jeroen.vermeulen@canonical.com>
<mvo_> xnox: hm, he should still be around to ask
<xnox> mvo_: well, let me dig the code a bit more.
<mvo_> ok
<smoser> pitti, i think that maybe /etc/environment might be required.
<smoser> honestly, as you invoke that with env -i.
<smoser> whatever you invoke will have no PATH if you dont get it from /etc/environment.
<smoser> the reality is that most likely /etc/environment *will* exist, but in the case where it doesn't, somethings probably going to fail later.
<pitti> smoser: couldn't PATH be set in some bash profile or PAM environment?
<pitti> smoser: right, but then it will fail with something like "command not found", not some unintelligible gibberish within adt-run
<smoser> well i dont think ti would get set. i dont think that ends up going through the bash login that gets all that set up.
<pitti> smoser: anyway, by and large I agree that /etc/environment is a must; but who knows who will test that with strange VMs :)
<smoser> maybe it does. and yeah, thats how it would normally get setup, but i suspect you were doing what you were doing for a while.
<smoser> and fwiw, i'd still set LANG=C
<smoser> so you dont get those silly messages
<pitti> smoser: that's already handled; unless you run with --leave-lang, it sets LANG=C.UTF-8
<smoser> about lang not set, but you are more knolwedgeable than i about how lang is supposed to work.
<smoser> i dont think it is.
<smoser> you run :
<smoser>  env -i
<smoser> which will clear LANG such.
<pitti> smoser: yes; Testbed.execute() sets some extra environment
<pitti> such as LANG, or (for mode "install") DEBIAN_FRONTEND and friends
<smoser> ok. i'll trust you.
<pitti> smoser: the LANG handling is test case'd already, just running LXC without /e/e or /e/d/locale wasn't
<smoser> one random thing... when i do subprocesses, from shell or python, i always use long options where available.
<smoser> http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=15faea
<smoser> when i see 'sudo -E' there
<smoser> i have to 'man sudo' to see what thta means.
<smoser> but sudo --preserv-env
<smoser> i dont have to man
<smoser> as i said, random comment. feel free to ignore
<pitti> ah, sure
<smoser> thanks for taking a look.
<pitti> no, good point, but that'll take some grepping
<xnox> "You have 1 day to reopen this bug or I will make a new one."
<xnox> sounds a legit threat! =)
<highvoltage> I'm shaking in my space booties
<wasaby> so this is how ubuntu devs treat bugs :)
<wasaby> with ignorance
<wasaby> why fix bugs when you can just dismiss them with no consideration
<xnox> wasaby: i'm sorry, but I don't follow. Can you elaborate? Above quote was not from an ubuntu developer, but rather a bug reporter. Instead of providing justification for particular request, reporter said that.
<Laney> bdmurray: could you look at my email about the nautilus sru please?
<hallyn> good morning - could someone please take a look at the new qemu-user-binfmt binary package in utopic-proposed?  I assume a button needs to be hit to accept it for qemu to be promoted to utopic-release...
<smoser> cjwatson, https://lists.ubuntu.com/archives/ubuntu-cloud/2014-July/000969.html
<smoser> is that true? that i simply cannot reliably have a 2Tb partition and grub2 booting mbr ?
<xnox> bios grub. UEFI will boot fine.
<xnox> smoser: i totally hit that when I made a 2TB intel matrix raid-0 device from two 1TB drives and was puzzled as to why it's only bootable in UEFI mode =)
<smoser> well, i can't just use uefi though.
<xnox> smoser: stand-alone /boot partition also works, I believe.
<smoser> right. and in start of the disk.
<smoser> we've not done that before.
<xnox> smoser: anywhere in the first 1TB =)
<cjwatson> smoser: I know of no such limitation in GRUB
<smoser> just to avoid the unnecessary complexity.
<xnox> cjwatson: hu? hm.
<smoser> i agree with xnox. hm.
<smoser> ok. so some background on how this is put together:
<cjwatson> smoser: You should use GPT, obviously, but even with MBR you should be able to address anything up to 2TB in GRUB, modulo BIOS limits.  I'd want a citation for this alleged limitation
<cjwatson> OK, please don't make me understand the whole thing just now, doing other things :)
<smoser>  * cloud-image is ~ 1.4G image. cloud provider truncates it to larger size, say 2TB.
<cjwatson> I suggest just asking Patrick to provide more information on this limitation that he claims exists
<smoser> ok. fair enough.
<cjwatson> Because if it exists and isn't just a BIOS bug (those certainly exist ...), we'd consider it a bug
<xnox> smoser: well, we know the bootloader and the system, thin-provision 2 TB and install ubuntu onto it with qemu.
<xnox> smoser: naturally 2TB+ is beyond MBR limit, and thus would require GPT.
 * xnox tries that.
<smoser> right. and for 14.04, it will properly resize it to only 2TB.
<cjwatson> Right, if it were actually slightly over 2TiB then you'd have a problem
<cjwatson> But if it's 2TB in lying-disk-manufacturer-units, then it should be comfortably under the real limit
<smoser> hm.. ok. well i'll give a quick try to reproduce.
<xnox> =)))))))))) lovely manufacturer units ;-)
<cjwatson> hallyn: no button should be needed
<cjwatson> hallyn: you're stuck in the libav/gnutls28/etc. transition.  please wait
<hallyn> cjwatson: oh - phew.  thanks.
<pitti> hey hallyn, how are you?
<hallyn> pitti: (on a call, few more mins)
<pitti> hallyn: I noticed that the last cgmanager upload in ubuntu diverted from Debian; are these session upstart enablements safe for Debian and will go there, too?
<pitti> hallyn: no hurry at all
<xnox> they are upstream and will be in the next release.
<hallyn> pitti: right, like xnox said, they're upstream.  I will sync from debian to utopic soon, but am waiting on slangasek to sponsor the 0.28-3...  that should be in prettu good shape
<hallyn> actually i should probably release 0.29 soon
<pitti> ah, nice
<pitti> hallyn: I can help out with Debian sponsoring too, if needed
<hallyn> but i'd first like to have sarnold review my new cgm :)
<hallyn> sarnold: \o
<hallyn> pitti: that'd be great;  it's at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.28-3.dsc .  mainly fixes a bunch of bugs in my initscrfipts,
<hallyn> but my sysvinit-foo is weak,
<hallyn> so some good "this sucks bc (x)" feedback won't go amiss
<hallyn> now, my btrfs-ioctl-foo is weak too, so back to that :(
<pitti> hallyn: oh, mbiebl_ was busy filing reports (thanks Michael for catching all those!)
<hallyn> pitti: yup, those should all be addressed
<pitti> hallyn: followed up with some pointers which hopefully help
 * pitti waves good night
<hallyn> pitti: thanks - good night
<LocutusOfBorg1> can anybody please sponsor?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/wxwidgets3.0/+bug/1349498
<ubottu> Ubuntu bug 1349498 in wxwidgets3.0 (Ubuntu) "please merge wxwidgets from debian" [Undecided,New]
<LocutusOfBorg1> I think this will become a serious bug tomorrow
<LocutusOfBorg1> because of this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752733
<ubottu> Debian bug 752733 in g++-4.9 "g++-4.9: PR61214 breaks packages linking against wxWidgets" [Normal,Open]
<LocutusOfBorg1> and the gcc-4.9 default (doko is planning to upload tomorrow the default)
<doko> LocutusOfBorg1, delaying. we should sync after 4.9 is the default, and check if the workaround is still needed
<LocutusOfBorg1> ok wonderful
<LocutusOfBorg1> thanks for caring ;)
<bdmurray> xnox: could you have a look at bug 1291434?
<ubottu> bug 1291434 in grub2 (Ubuntu) "GRUB_CMDLINE_LINUX_DEFAULT contains duplicate options" [Undecided,Confirmed] https://launchpad.net/bugs/1291434
<xnox> bdmurray: i have noticed that. But I was going to consult cjwatson as to how grub.d snippets should be extending options.
<xnox> bdmurray: cause imho, I'm not doing anything wrong, yet cmdline over-expands too much at update-grub time.
<xnox> Sweetshark: do you have libreoffice rebuild?
<cjwatson> xnox: I'm preparing it now, since it should just be no-change I think
<xnox> cjwatson: all of the silly little libs renamed their .pc files.
<cjwatson> Oh seriously?
<Sweetshark> xnox: for utopic?
<cjwatson> Sweetshark: yes
<xnox> cjwatson: and e.g. libwpd-stream-0.9 is gone.
<xnox> cjwatson: yeah, they encode version number in the pc file name, for what it seems like no reason. E.g. libwpg-0.2 -> libwpg-0.3
<cjwatson> Sweetshark: it's got implicated in a massive transition that's holding back half of utopic and blocking nearly everything, which we need to fix before alpha-2 freezes
<cjwatson> libcdr, libwpd, libwpg, and libwps are the connection points
<cjwatson> xnox: presumably it's an API change as well as an ABI change
<Sweetshark> well, I have a 4.3.0~rc4 build which should become final upstream in a few days. Im currently still testbuilding it on armhf ...
<cjwatson> Do we *have* to have this with a new libreoffice upstream as well?
<cjwatson> This is already horrendously complicated
<cjwatson> It would be far preferable to keep the changes as minimal as possible ...
<cjwatson> And "a few days" means after alpha-2, which further diminishes the probability of ever finishing this transition, and in particular probably eliminates the chance of landing it before phone RTM forks
<xnox> yeah, ideally we'd do distro-patch / rebuild of the current libreoffice.
<Sweetshark> cjwatson: whatever you prefer. I just always a bit weary of fixing up details on a e.g. 4.2.x build on utopic, when 4.3.0 comes along a few days after and we never see or need the 4.2.x tweaks again.
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt <- search for the first two occurrences of "Trying easy from autohinter" and you'll see why I'm trying to keep the complexity down
<Sweetshark> cjwatson: urgh
<cjwatson> Sweetshark: I understand the sentiment, but I think if we try to wait for 4.3.0 here then we'll be doomed
<Sweetshark> cjwatson: agree :/
<cjwatson> Ah, and indeed now it's just the first occurrence o fthat
<cjwatson> *of that
<cjwatson> The problem is basically that every time it takes us a few days to fix things, another transition gets itself tangled in the hairball
<Sweetshark> cjwatson: you may find me bitching about the libwp{s,d,g} madness earlier today in the backlog
<xnox> Sweetshark: yeap, we are on that atm.
<cjwatson> Sweetshark: not in this channel, I guess
<Sweetshark> cjwatson: eh, right, twas in -desktop, I guess.
<cjwatson> Well, if there's anything you can do before we run out of day, it would be greatly appreciated.  I know that's rather a lot to ask in the case of libreoffice
<cjwatson> But the a2 freeze is late tomorrow
<bdmurray> doko: are you planning on uploading gdb to trusty-proposed?
<doko> bdmurray, I can do that. are you planning to do the testing? ;-P
<xnox> cjwatson: and like, i totally trust that nothing will be broken once everything migrates =)
<Sweetshark> cjwatson: since you dont want LO4.3.0 in this mess, what exactly do you want "anything" to be? A no-change upload of libreoffice? Can do, but cant really do much testing of that before throwing it over the fence. So its fire-n-forget anyway.
<xnox> Sweetshark: yeap, we want that. Apart from we know that no-change, will FTBFS most likely.
<xnox> Sweetshark: so yeah, no-change rebuild / minimal amount of changes to get it build in utopic-proposed and throw it over.
<bdmurray> doko: if there are good test cases then yeah
<Sweetshark> xnox: were is the expectation of FTBFS coming from?
<doko> ok, preparing ...
<Sweetshark> xnox: other than "its libreoffice and we just changed ~all the world below it, that cant work"?
<xnox> Sweetshark: e.g. libwpg-dev, pkg-config name changed from libwpg-0.2 to libwpg-0.3
<xnox> ditto libwpd-dev libvisio-dev libwps-dev
<xnox> i think.
<Sweetshark> xnox: hmmm, that shouldnt harm per se. And if it does, I can just throw in an internal copy of libwpX etc. to get this transition over the hill, using the proper system version again later.
<Sweetshark> xnox: thats just a oneline change.
 * Sweetshark tries.
 * Sweetshark originally had other plan for this evening.
<xnox> Sweetshark: cool. Yeah, that would work as well. Basically, we don't want anything to depend on the old abi packages... either by building against new stuff or using local copy et.al.
<cjwatson> xnox,Sweetshark: hm, another idea, if we can fix everything else then perhaps I can tell proposed-migration to ignore the NBS problem in the case of libreoffice
<cjwatson> which would save having to fix that in a tearing hurry
<cjwatson> then you could wait for 4.3.0
<alexbligh1> Any ideas why packages.ubuntu.com is still showing pre 14.04.1 packages?
<cjwatson> it's not ideal but it would be workable - proposed-migration is strict about NBS by default but it doesn't absolutely *have* to be
<Sweetshark> cjwatson: sounds good to me.
<Sweetshark> FWIW LO4.2.4 is FTBFS in proposed right now.
<Sweetshark> cjwatson: ... and "fixing stuff in a hurry" never mixed well with a 3KLOC ./debian/rules file (which generates a ./debian/control file).
<achiang> hallyn: dumb question, but is it expected that i can run an armhf container hosted on an amd64 (trusty) machine?
<hallyn> achiang: I'm not sure.  I think yhou'll need qemu-user for that
<alexbligh1> achiang, https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/
<alexbligh1> achiang, trusty being left as an exercise for the reader ...
<stgraber> alexbligh1: also mentioned here: https://www.stgraber.org/2013/12/23/lxc-1-0-some-more-advanced-container-usage/
<achiang> thanks, reading now
<hallyn> yes but do those address armhf on arm64?
<hallyn> oh, i misread :)
<Sweetshark> cjwatson, xnox: so with http://pastebin.com/7fZK0bmW and a "./debian/rules control" call, "dpkg-buildpackage -B" gets through ./configure. That is most likely all that is needed to fix the FTBFS for 4.2.4.
<hallyn> sorry, i thought you wanted to run on arm64.  WHO NAMES THESE
<hallyn> achiang: for that you dont' even need to do anythign special;  install qemu-user-static and add '-a armhf' to the container template args.  but, guess your'e reading the blogs, so excellent
<Sweetshark> cjwatson: as such, I would suggest to just go for it now with the transition and fix it up quickly then -- should be low risk as a/ LibreOffice 4.3.0~rc4 already finished building in -proposed and b/ LibreOffice 4.2.4 should be trivial to fix with the patch above.
<achiang> hallyn: stgraber: ah, i was using -t download instead of -t ubuntu
<achiang> perhaps that is why i was tripping over issues
<Sweetshark> cjwatson, xnox: So, Ill not prepare an upload of 4.2.4 (hey, I dont have any uploader rights anyway) as discussed and will make this end of day in 10 minutes unless there is loud protest. ;)
<stgraber> achiang: ah yeah, -t download just grabs an armhf (or whatever arch you pass) image from the server but this image won't run unless your kernel knows how to run arm code (so armhf, armel or arm64 box). You could manually copy qemu-user-static over to it though which should do the trick.
<achiang> stgraber: how would i do that? attempting to start the container doesn't work
<stgraber> achiang: it's actually a bit of a bug that -t download lists architectures that your system doesn't support, but figuring out a way to filter those in a distro-independent way and supporting all crazy piece of hardware out there is kinda hard...
<achiang> $ lxc-start -n ubuntu-sdk-armhf
<achiang> lxc_container: invalid sequence number 1. expected 4
<achiang> lxc_container: failed to spawn 'ubuntu-sdk-armhf'
<achiang> (that was my earlier issue)
<stgraber> achiang: copying /usr/bin/qemu-arm-static to rootfs/usr/bin/qemu-arm-static would help a bit, though IIRC there are a bunch more tricks you need to do in there (which the ubuntu template does for you) such as enabling multi-arch and then install the host-arch version of upstart, mountall, isc-dhcp-client and iproute2
<achiang> stgraber: ok. i'll just use -t ubuntu then. :)
<achiang> sigh
<achiang> no i won't.
<achiang> http://pastebin.ubuntu.com/7887191/
 * achiang will poke at this later, feeling a bit sick atm so need to go /away
<stgraber> achiang: hmm, is lxc-create getting called as root and are you doing that directly on the host or within an existing unprivileged container?
<davmor2> bdmurray: hey dude, on the phone if you click on previous errors it seems to take you to a blank errors.ubuntu.com page, is this a known bug?
<danilos> heya all, I am trying to build ubuntu-keyboard (lp:~danilo/ubuntu-keyboard/serbian-layout, though the same happens with trunk) on my trusty install using "sbuild", but I am hitting a missing dependency (https://launchpad.net/ubuntu/+source/platform-api/2.1.0+14.10.20140721-0ubuntu1/+build/6202467 seems to be the problem); any suggestions on what to do or how to test this (I've got an up-to-date utopic on my nexus 4 fwiw) before even att
<danilos> empting to propose a merge?
<danilos> uhm, that was the wrong link, I am building for armhf
<danilos> which seems to be built correctly, so I am clearly doing something wrong
<danilos> it seems I was missing utopic-proposed in my chroot, let's try with that
<xnox> Sweetshark: thanks a lot! I'll tend to that. Bug given how busy buildds are, proposed migrations output will be very cryptic for a while.
<achiang> stgraber: no, calling lxc-create as user, directly on host
<sarnold> hallyn: -new- cgm? I thought I just reviewed it? :) heh
<hallyn> sarnold: i wrote it in C, so it wouldn't have to depend on the dbus package
<hallyn> so it could go in with cgmanager, maybe even into /bin (so that sysvinit script can call it to verify cgmangae rhas started)
<sarnold> hallyn: ahh, nice. did you re-implement the APIs you were using already or are they new too?
<sarnold> hallyn: .. and did you quash that NULL+0-length bug you found in NIH? :)
<hallyn> sarnold: no no, same apis
<hallyn> lemme think.  I worked around it somehow.
<hallyn> oh yeah, I detect the false error from libnih and decdie whether it's a real error or not;  return empty list myself if not.
<sarnold> hallyn: ahh :)
<bdmurray> infinity: could you have a look at bug 1348200 and bug 1348198?
<ubottu> bug 1348200 in flash-kernel (Ubuntu) "Globalscale Mirabox support" [Undecided,New] https://launchpad.net/bugs/1348200
<ubottu> bug 1348198 in flash-kernel (Ubuntu) "SolidRun CuBox-i support" [Undecided,New] https://launchpad.net/bugs/1348198
<infinity> bdmurray: I can, but (probably) not today, working on ARM stuff for trusty.
<infinity> I assume those are utopic-only.
<bdmurray> infinity: no rush, I just was notified of them today
<slangasek> infinity, bdmurray: snort at bug #1348198; should probably be fixed with a merge from Debian
<ubottu> bug 1348198 in flash-kernel (Ubuntu) "SolidRun CuBox-i support" [Undecided,New] https://launchpad.net/bugs/1348198
<infinity> slangasek: We're well overdue for a two-way merge of f-k.
<saiarcot895> What is the advantage of the scaling stack builders?
<cjwatson> saiarcot895: They're running a trusty base system rather than hardy; and our sysadmins can scale them out horizontally (i.e. add more builders) nearly trivially
<saiarcot895> cjwatson: oh, woohoo!
<cjwatson> (The former is to some extent an artificially created situation, in that we could have put effort into upgrading the existing setup rather than developing scalingstack; but the latter makes a big difference)
<cjwatson> saiarcot895: Also, the underlying system is much less fragile, and we expect builders to die a whole lot less
<cjwatson> saiarcot895: And it will be much easier to upgrade them to new versions of launchpad-buildd; with the old system, that was a fairly terrifying process which could turn into a full-day job if the slightest thing went slightly wrong
<cjwatson> saiarcot895: With the new system, it's a matter of building a new base image and then new builds just pick it up
<saiarcot895> cjwatson: ah, ok. I was wondering about that. So when X comes out, the builders will be on the latest version and have the latest build tools
<cjwatson> Should be much easier to do that, certainly; we won't necessarily do it right away
<cjwatson> It only matters for stuff that comes from the host, but that includes the kernel, launchpad-buildd, bzr-builder (for recipes), and suchlike
#ubuntu-devel 2014-07-29
<cjwatson> pitti: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-kde-runtime/ARCH=i386,label=adt/45/console - we could really use "apt-get update || { sleep 15; apt-get update; }" or something in the adt setup
<hallyn> xnox: hey, late in your tz, so probably not, but...  are you around?
<pitti> cjwatson: curious, adt-run is already using that in most places (we talked about it a few months ago); apparently I forgot one place, I'll have a look
<pitti> Good morning
<pitti> slangasek: hey Steve!
<pitti> slangasek: do you think it's ok to upload the sysvinit to -proposed and keep it there with a block-proposed bug? that way we can already run all the testing against it
<pitti> slangasek: it's a relatively harmless effective change, after all
<pitti> cjwatson: oh -- that log already *does* retry, and the second apt-get update succeeds; the BADSIG is bug 1345877
<ubottu> bug 1345877 in ubuntu-archive-publishing "Invalid GPG signature http://ddebs.ubuntu.com/dists/trusty/Release.gpg" [Undecided,Confirmed] https://launchpad.net/bugs/1345877
<slangasek> pitti: I'd rather not deliberately put stuff into -proposed that we don't expect to get out immediately
<slangasek> pitti: but I guess it's your call
<pitti> slangasek: ah, I postponed it as the other day you said that there are some things you didn't like in the new versino, and you wanted to review
<pitti> slangasek: also, I don't want to land it in traincon-0
<pitti> cjwatson: ah no, the badsig is from the main archive, not from ddebs; so I guess this is a case where apt-get update failed twice in a row :/
<slangasek> pitti: correct, I want to review the merge before it goes in, on account of some vexing upstream changes
<pitti> slangasek: ok, then I won't upload it for now
<slangasek> (and it's easier for me to review it than to give an accounting of all the things that have recently been wrong with sysvinit maintenance in Debian)
<doko> pitti, jibel: could you restart the plv8 and pgagent autopkg tests? seem to be qemu issues
<pitti> doko: no, pgagent is an actual bug; I just uploaded the transition to 9.4 to Debian, will auto-sync
<doko> gwenview did fail before tpp
<doko> ahh, ok
<pitti> doko: plv8 as well, there's something wrong with the transition (it tries to pull in 9.3)
<doko> well, blocking gcc-4.9 ...
<pitti> doko: it's on my list for today, too
<doko> Riddell, can you or #kubuntu have a look at the gwenview autopkg test failure?
<dholbach> good morning
<doko> dobey, ubuntu-sso-client ping, could you have a look at the autopkg test failure?
<pitti> doko: ah, the fixed plv8 is still stuck in Debian binNEW
<pitti> doko: I'll do an Ubuntu upload to unblock
<cjwatson> pitti: oh, right, ugh.  ok
<cjwatson> doko: I already applied a force-badtest hint to gwenview; no idea why it's still showing there
<cjwatson> oh, p-m can only take one hint for any given package
<cjwatson> doko: once everything else is fixed, tell me and I'll force-skiptest gcc-4.9
<pitti> doko: plv8 is good now; I just removed the NBS, it should promote in the next cycle; (and unblock gcc)
<doko> pitti, cjwatson: that leaves gcc-4.9 with pgagent (which will be synced from debian soonish), and gwenview
<pitti> as the gwenview regression was introduced with 4:4.13.90-0ubuntu1 in -proposed, we could also just remove that package from -proposed
<cjwatson> pitti: no
<cjwatson> pitti: we've seen failures with earlier versions too; also please don't do anything to interfere with the megatransition
<cjwatson> pitti: ScottK has already forwarded it upstream, and we think the failures are ignorable for now
<cjwatson> hence my hint
<pitti> ack
<pitti> wrt. history, http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-gwenview/20/ was an infrastructure problem, otherwise http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-gwenview/? looks fairly stable (pass/fail)
<cjwatson> oh, maybe the alleged failures with earlier versions are just adt-britney being confused
<pitti> but override WFM, it's clearly not a gcc regressino in this case
<cjwatson> notice how update_excuses says "autopkgtest for gwenview 4:4.13.2-0ubuntu2: Regression" in places
<pitti> indeed; looks like it says the release version number there instead of the proposed version?
<cjwatson> I guess the cause is wrong in the various control files, but argh that stuff hurts my brain
<cjwatson> doko,pitti: ok, so I've hinted "force-skiptest gcc-4.9/4.9.1-3ubuntu2"
<pitti> not a biggie right now either way
<pitti> cjwatson: thanks
<pitti> if it's any urgent, you can also skip the pgagent test; I suppose it'll still be a few hours until it gets imported and synced
<cjwatson> "force-skiptest" skips all tests hung off a given upload
<cjwatson> "force-badtest" skips just tests for a given failing package
<pitti> ah
<cjwatson> So in this case I meant to say "everything done, ignorable, or being fixed"
<cjwatson> And none of it caused by gcc in any event, as far as I understand it
<mlankhorst> cjwatson: fglrx won't be available for some time when I release xorg-server 1.16, in that case could fglrx be temporarily dropped or something?
<seb128> shouldn't we hold on 1.16 until all drivers are ready instead?
<cjwatson> mlankhorst: that seems questionable given that it's widely-used
<cjwatson> mlankhorst: but seems that needs wider discussion rather than just asking me, a non-fglrx user :)
<mlankhorst> there's radeon still available as alternative
<seb128> -1 for letting users down this way
<seb128> we decided some cycle ago to not do that anymore no?
<mlankhorst> but we won't receive upgrades for radeon until very near final release :/
<mlankhorst> and flipping the whole xorg-server near release sounds like a  bad idea, while some of the other changes are definitely needed
<seb128> needed for what?
<seb128> well, you should talk to other teams, maybe email ubuntu-devel@ with the plan and why we need the update even if we don't have all drivers
<mlankhorst> I have mailed a CFT to ubuntu-devel@
<cjwatson> Riddell: Can we slow down the KDE uploads for a bit?  I think libav might just have landed if not for the gwenview upload just now
<cjwatson> argh, which is dep-wait
<cjwatson> on something not uploaded yet!
<cjwatson> tempted to remove that and copy the old one back
<xnox> well, anything that would make britney transition things or give us a sensible list of things to fix is good.
<cjwatson> xnox: I've got a sensible list and it says "gwenview"
<cjwatson> libav migrating!
<rbasak> \o/
<cjwatson> publisher on manual to ensure that all the copies go in one batch
<cjwatson> publisher on auto
<mlankhorst> cjwatson: what about a solution where we upload xorg-server and all the packages to -proposed near feature freeze, and keep it there until the next fglrx release, hopefully in a week or 2 later?
<cjwatson> I guess that's one option but be careful of things that might end up blocked on that
<cjwatson> honestly I'd rather not be the decision-maker here - I'm going to have a lot to do with phone RTM
<mlankhorst> well not requiring a FFe for xorg-server would be ok with me too
<pitti> mlankhorst: so perhaps testing from a PPA would be better for now? (FWIW, I have no idea how important the fglrx driver is these days -- back then, radon worked just fine for me, but it's been years since I had something non-intel)
<pitti> radeon even
<mlankhorst> pitti: we have a ppa, but that doesn't get NEARLY as much testing as the archive does..
<mlankhorst> I'll be lucky to get 10 people testing..
<pitti> xorg-edgers how how that was called?
<pitti> mlankhorst: OOI, in which regards is fglrx better than radeon these days?
<mlankhorst> no idea, I tend to use radeon more. presumably fglrx has some features radeon lacks
<pitti> I mean, if it doesn't work on some hardware, that's a good reason to not break utopic; if it's just marginally slower or eating a bit more power, temporarily dropping it seems just fine to me
<pitti> (assuming that it automatically falls back to radeon)
<pitti> comparing the vendor/product ID lists might help there?
<mlankhorst> not really, mostly newer HW works minus radeon bugs
<mlankhorst> it's just that the latest might not, no idea tbh
<rbasak> Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752796, it looks like a Perl 5.20 transition is due to hit sid on 12 August.
<ubottu> Debian bug 752796 in nginx "nginx: hardcodes /usr/lib/perl5" [Serious,Open]
<rbasak> That's before our feature freeze. Are we going to take that?
<rbasak> I'm wondering whether to cherry-pick the fix for nginx that is in VCS but not uploaded to unstable yet.
<mdeslaur> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<mlankhorst> pitti: oh and without xorg-server radeon will actually work worse, because it will lack the glamor updates
<mvo_> jibel: can you confirm in the lap or on your test vm (when you have a moment) that #1347964 is no longer appearing?
<jibel> mvo_, without any specific repo?
<rbasak> pitti: the 'current specification' link from http://dep.debian.net/deps/dep8/ is broken.
<mvo_> jibel: yeah, it should be fixed in the main repo already
<mvo_> jibel: fingers crossed :)
<jibel> mvo_, upgrade in progress ...
<mvo_> jibel: you rock
<juliank> slangasek: Is the patch debian/patches/gcc46-compatibility for gnu-efi still needed (what's the reason for building with gcc 4.6 these days?) or can this be synced from unstable to the new upstream release now?
<juliank> If it can be dropped, a "syncpackage -s juliank gnu-efi" would be nice
<pitti> rbasak: yeah, I fixed it in svn a few weeks ago and asked for updating it, but that didn't happen yet :/
<rbasak> No worries
<doko> jamespage, maven fun in proposed ... libcommons-logging-java and tomcat8 ...
<jamespage> doko, joy joy
<doko> can you have a look? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<doko> objenesis?
<jamespage> doko, not right now - dealing with some other things today
<jamespage> doko, as we doing tomcat8 for main this cycle?
<jamespage> are we rather
<doko> jamespage, you tell me ...
 * jamespage thinks
<doko> zul better should subscribe ubuntu-mir when filing MIR's ...
<xnox> doko: should i make 3.5 default for llvm-default on ppc64el only? or should I instead fix powerpc build failure and work out if/when/can we switch to 3.5 by default?
 * xnox looks at release schedule.
<doko> xnox, I'd say make it the default on all architectures after checking that mesa is fine with it
<xnox> doko: ack. this also means fixing powerpc build then.
<doko> dholbach, you sponsored python-wsme, hangs now in component mismatches ... please file the 30 MIR which are required, or drop the build deps ...
<dholbach> Noskcaj, ^
<dholbach> doko, I followed up on the sponsoring bug - thanks - I thought I had checked all the build-deps and verified they were in main
<dholbach> I must have missed something
<dobey> doko: re: ubuntu-sso-client, do you have a link? i didn't get any e-mail about it failing
<doko> dobey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<doko> tvoss|lunch, can you take care about https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1349834 ?
<ubottu> Ubuntu bug 1349834 in libjsoncpp (Ubuntu) "[MIR] flask-script and libjsoncpp (b-d's for net-cpp)" [Undecided,Incomplete]
<dholbach> doko, I reopened the bug as well
<dobey> sigh, why is squid not starting
<apachelogger> mardy: heya, any chance of getting a new signon upload for utopic? we are currently porting kde-accounts and it appears as though the cmake config installed by the current package has a bit of a divergent name from what is in git (namely SignOnQtConfig.cmake vs. SignOnQt5Config.cmake)
<jibel> mvo_, upgrade from 12.04.4 desktop + Trusty HWE stack -> Trusty is successful on amd64
 * jibel hugs mvo_
 * mvo_ hugs jibel
<mvo_> thanks for confirming
<tvoss> doko, on my list
<cjwatson> rbasak: perl 5.20> I'm considering it if the rest of -proposed is quiet enough at that point
<rbasak> cjwatson: OK, thanks. I didn't cherry-pick it for now, but the patch (for nginx) is there for us to grab if we need it.
<arges> jamespage: hello. I see ceph/nova are in teh trusty review queue. Is it alright if I review these and potentially accept into proposed? I don't want to mess up any plans you already have
<dholbach> shadeslayer, ready for the hangout in ~1h?
<shadeslayer> yep
 * shadeslayer is excited and nervous
 * dholbach hugs shadeslayer
<dholbach> all will be fine :)
<shadeslayer> :D
<doko> component-mismatches-proposed is frustrating ...
<bzoltan> mitya57:  ping
<bzoltan> mitya57:  I would need a friendly licensed maintainer who could review and approve an MR from us against the QtCreator packaging branch: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtcreator. The patch is rather simple -> https://code.launchpad.net/~zeller-benjamin/kubuntu-packaging/qtcreator-ubuntudevice-qmlprojects/+merge/228665 It enables ubuntu devices to be Run targets for QML apps.
<hallyn> pitti: do i understand right that cgmanger will start so long as there is a sysv init job but no systemd job;  and if i create a cgmanager.service disabled by default, then it won't start?
 * hallyn tries
<doko> apw, infinity, ogasawara: I assume we need a MIR for  linux-exynos5 ?
<pitti> hallyn: yes, but the init.d and unit names need to be identical
<hallyn> can do - thanks
<jamespage> arges, +1 please go ahead
<arges> jamespage: ok cool. thanks
<infinity> doko: No.
<infinity> doko: It shouldn't be in main.
<infinity> doko: component-mismatches is lying to you.
<arges> tinoco: jamespage : one concern of the nova upload are if bugs 1219658, 1267191 are fixed in the utopic version of nova (its not entirely clear)
<ubottu> bug 1267191 in nova (Ubuntu) " openstack-nova-compute service fails with - libvirtError: internal error: CPU feature `avx' specified more than once" [Undecided,New] https://launchpad.net/bugs/1267191
<ubottu> bug 1219658 in nova (Ubuntu) "Wrong image size using rbd backend for libvirt" [Undecided,In progress] https://launchpad.net/bugs/1219658
<jamespage> arges, lemme check
<tinoco> arges: checking
<hallyn> pitti: sorr, one more q - is there a .target representing "virtual filesystems (i.e. proc and sys) are mounted" ?
<hallyn> local-fs is probably too much / too late;  oh, but maybe fine for cgmanager under systemd, as it's not needed for init there, duh
 * xnox loves C++11 static_assert
<xnox> __linux is not defined, ftw! =)
<pitti> hallyn: that's already defined by basic.target, unless you specify DefaultDependencies=no all units can rely on those
<tinoco> arges: rbd issue is applied
<tinoco> checking other
<tinoco> arges: other fix (cpu feature) is included but in a different source file (test_libvirt* changed to test_config)
<tinoco> arges: i would say both are already applied to utopic nova-2014.2~2
<hallyn> pitti: I want it to start as early as possible
<pitti> hallyn: so not depending on anything will do that
<pitti> hallyn: see man systemd.special: "Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic
<hallyn> pitti: sys and proc will still be mounted?
<pitti>            initialization necessary for general purpose daemons."
<pitti> hallyn: I suppose you want all those
<hallyn> the systemd manpages are hard to find :)  not found on my sid or trusty systems;  /me goes to manapges.ubuntu.com
<pitti> err?
<hallyn> still not
<pitti> "man systemd.special"
<pitti> oh, on utopic
<hallyn> No manual entry for systemd.special
<pitti> yes, we didn't have systemd on trusty
<hallyn> yeah my utopic system is dead
<hallyn> but also not found on unstable
<hallyn> oh no, there it is
<hallyn> didn't find dh_systemd_enable though
<pitti> that's the dh-systemd build dep
<hallyn> ok cool, so now i just need to figure out how to do some scripting before the service starts
<pitti> hallyn: you can do stuff in ExecStartPre=
<pitti> (man systemd.service for daemons, man systemd.unit for fields which apply to all units)
<hallyn> pitti: thx
<arges> tinoco: ok
<doko> Noskcaj, dholbach: MIR's for jquery needed (or better get rid off this b-d)
<dholbach> doko, that's for python-wsme?
<doko> dholbach, no, that's a separate sync you sponsored
<doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<dholbach> doko, sorry, which package was that?
<doko> jquery
<dholbach> huh?
<dholbach> I can't see it here: https://launchpad.net/ubuntu/+source/jquery
<doko> dholbach, https://launchpad.net/ubuntu/+source/jquery/1.7.2+dfsg-3ubuntu1
<dholbach> ah, I was just surprised, because you said "sync" - let me take a second look
<doko> sorry, merge
<hallyn> pitti: is there a way for a ExecStartPre to tell systemd to simply skip this service (contingnet on output of the command)?  like exit 2 or something?  I don't see it in the manpage
<arges> tinoco: where is the testcase for bug 1219658 ?
<ubottu> bug 1219658 in nova (Ubuntu) "Wrong image size using rbd backend for libvirt" [Undecided,In progress] https://launchpad.net/bugs/1219658
<tinoco> arges: i changed description for "to be provided". i'll create my own tests. bugs were cloned from fedora. i put them together for a ppa (large install) and relied on real tests (fixed both bugs).
<xnox> doko: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1349907
<ubottu> Ubuntu bug 1349907 in gcc-4.9 (Ubuntu) "gcc, powerpc with C++11 standard does not define __linux" [Undecided,New]
<xnox> doko: looks like that's the root cause for llvm-3.5/powerpc build failure, and affects debian and ubuntu. And also looks like complete obscure.
<arges> tinoco: can you describe the test case in that SRU section ? it doesn't have to be a script, but some explainination of what steps are required to see the issue
<tinoco> arges: will do. gimme some minutes, i'll get back to you on this
<doko> xnox, please use __linux__
<xnox> doko: sure, but __linux and linux is defined on all other arches, and with a default standard on powerpc.
<doko> xnox, and?
<xnox> doko: any preference for __linux__ vs __linux preference? I personally see __linux used for the first time.
<doko> <doko> xnox, please use __linux__
<xnox> doko: and? -> well it causes FTBFS on powerpc of other packages, and it's not clear to me weather gcc-4.9 with C11 standard enabled is backwards incompatible here on powerpc only, or wether all code is wrong.
<xnox> doko: why is __linux defined at other standards, and on other arches including C11 standard level?
<xnox> right, I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
<ubottu> gcc.gnu.org bug 28314 in target "cpp: x86/powerpc inconsistency for the __linux macro" [Normal,New]
<xnox> which is good enough reference for me.
<xnox> doko: which looks like reported by you =)
<mitya57> bzoltan1: approved
<xnox> thanks a lot!
<doko> xnox, yes, and I won't change it on the package level
<xnox> doko: excellent.
<doko> xnox, what is problem fixing llvm?
<xnox> doko: no problem, wrote a patch, test building and will submit upstream.
<xnox> (and upload into ubuntu)
<mdeslaur> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tinoco> arges: changed 1267191 [testcase]. could you please tell bugs 1319710 and 1303536 they are a duplicate of 1267191 ? I keep getting timeouts to mark them duplicate.
<ubottu> bug 1319710 in OpenStack Compute (nova) "Live-migration failed with OpenStack Icehouse and Ubuntu 12.04 " [Undecided,New] https://launchpad.net/bugs/1319710
<ubottu> bug 1303536 in OpenStack Compute (nova) "Live migration fails. XML error: CPU feature `wdt' specified more than once" [Medium,Fix released] https://launchpad.net/bugs/1303536
<arges> tinoco: technically they aren't targeted to ubuntu/nova, so we don't really need to mark them duplicates
<tinoco> arges: ah ok, perfect
<tinoco> checking the rbd testcase (it will be the same as the previous bug since it is a fix to a regression patch)
<arges> tinoco: ok can you update that too please
<tinoco> ok
<tinoco> arges: done.
<dholbach> doko, followed up on the merge proposal - thanks
<tinoco> arges: i think both are ok now, let me know if you need anything else on this. tks!
<arges> tinoco: ok one more thing... did you change the urgency= field in the changelog?
<tinoco> checking
<arges> or rather why did you do it
<tinoco> urgency=high
<tinoco> there were some outages because of these... P1 bug was created to provide fix
<arges> why was it changed from urgency=medium?
<tinoco> i had to provide this fix in few hours to avoid outage
<arges> tinoco: i don't think that translates to updating the changelog urgency field
<rbasak> Is it just me, or has dch's default changed recently or something?
<rbasak> I've seen much more variance in the urgency field recently
<xnox> default is medium these days.
<xnox> used to be low.
<xnox> makes zilch of a difference. (like +/- a couple of build score points, in build queuing in ubuntu)
<arges> tinoco: anyway yea shouldn't make any difference editing that field. no need to modify it now
<tinoco> arges: ok, tks chris
<xnox> tinoco: yeah, but that field is not the semantic meaning you are guessing it has =)
 * xnox ponders why i like yoda speak
<tinoco> xnox: yep. totally agree now. tks guys
<arges> tinoco: np thanks for the fix, its been accepted
<mpt> ev, any progress on the database migration?
<tinoco> arges: great, updating here. tks!
<ev> mpt: the priority had to be dropped as IS just had to pick up a big project. We're working to make sure we don't put the existing data at risk as this gets put on hold.
<rbasak> caribou or arges: please could you take a look at https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/1349031? Is this a botched merge?
<ubottu> Ubuntu bug 1349031 in backuppc (Ubuntu) "ping6 is not configurable over web ui" [Wishlist,New]
<arges> rbasak: i know caribou is away on holiday. and i'm trying to remember this one...
<arges> rbasak: looking at the diff i don't see 'ping6' or 'ipv6' or anything of that sort
<rbasak> arges: http://paste.ubuntu.com/7896530/ is what I see
<rbasak> That's debdiff backuppc_3.3.0-1.dsc backuppc_3.3.0-1ubuntu1.dsc|pastebinit
<arges> ok i was looking at http://launchpadlibrarian.net/162543633/backuppc_3.2.1-4ubuntu2_3.3.0-1ubuntu1.diff.gz
<rbasak> Yeah that diff is against the previous Ubuntu package.
<arges> yup yup. ok
<arges> so that merge added functionality; why do you think it was botched?
<shadeslayer> ev: https://errors.ubuntu.com/?user=kubuntu-bugs&period=month still doesn't work
<arges> added the ping6 functionality
<ev> shadeslayer: bdmurray just arranged for a deployment containing that change
<ev> should be up soon
<shadeslayer> thx :)
<rbasak> arges: it's not mentioned on the changelog
<rbasak> arges: it looks to me (superficially, anyway) that Debian or upstream changed something about it, and what Ubuntu had before got carried forward, instead of taking upstream changes.
<arges> rbasak: yup which is why the diff from the previous ubuntu version doesn't show that change. its a specific ubuntu patch somewhere
<rbasak> arges: right, but were upstream changes in this area considered for this merge? The missing changelog entry suggests not.
<rbasak> arges: are we sure that this cannot just be dropped?
<rbasak> arges: because I see no mention of an addition of anything to do with ping6 in the previous changelog.
<rbasak> arges: say for example that there was a bug, and upstream fixed it. If we carry forward what we had before, then we'll exclude that.
<rbasak> arges: that seems to be the simplest explanation to me (at a cursory glance). Either that or a delta was introduced and I haven't found it documented anywhere.
<bdmurray> ev: i think it has landed but the cronjob may not have run yet
<arges> rbasak: so I'm not sure with this. I would look at the full changelog to see if this is documented anyway (in the Ubuntu version or Debian version). And if not try dropped it and test to see if we have the same functionality and it fixes that bug
<bdmurray> ev, shadeslayer: it runs once a day so should work tomorrow
<shadeslayer> bdmurray: thx
<sarnold> Trevinho: smells like a duplicate of something else recently: 1349953
<sarnold> Trevinho: and another instance of the password going into a previously active client: 1349961
<doko> zul, commented on python-keystonemiddleware. there are a lot more missing MIR's
<zul> doko:  thanks
<Noskcaj> ScottK, Could you help me with python-wsme's component missmatches?
<Noskcaj> A few releases ago the debian maintainer added build-depends on a few things in universe, which got dropped without a changelog entry when you merged it. I have since had the package synced, and now i can't get the package to build from source because of some tarball strangeness
#ubuntu-devel 2014-07-30
<Muchachao> hi guys
<ScottK> Noskcaj: I didn't merge it.  I did a mistaken sync.
<saiarcot895> Are the official armhf Ubuntu builders running on native hardware or is it emulated?
<slangasek> juliank: has bug #753682 been *properly* fixed now?
<ubottu> bug 753449 in branding-ubuntu (Ubuntu) "duplicate for #753682 package branding-ubuntu 0.5 failed to install/upgrade: trying to overwrite '/usr/share/gnome-games/quadrapassel/pixmaps/quadrapassel.svg', which is also in package quadrapassel 1:2.32.1-0ubuntu3" [High,Fix released] https://launchpad.net/bugs/753449
<slangasek> juliank: I have a staged merge of gnu-efi, but was waiting for resolution of this bug
<pitti> Good morning
<pitti> RAOF: hey Chris
<pitti> RAOF: do you have 5 mins to review/accept the postgresql SRUs (lucid/precise/trusty)? people keep pinging
<RAOF> pitti: Howdie.
<dholbach> good morning
<dholbach> Noskcaj, can you please take a look at jquery, python-wsme and libgtop2 is still unresolved as well
<Noskcaj> dholbach, I've looked at wsme, will get to the others soon
<dholbach> thanks Noskcaj
<Noskcaj> wsme breaks trying to debuild -S for me, and we should have had those depends since three versions ago
<Noskcaj> The old delta was more than i realised
<zyga> good morning
<dholbach> Noskcaj, what's breaking?
<dholbach> Noskcaj, the problem with the (build)depends is that some are in main and some are in universe - so if we want them in main, we need to follow https://wiki.ubuntu.com/MainInclusionProcess and maintain them in main
<Noskcaj> dholbach, It says a heap of files have been modified, no matter what i do
<Noskcaj> I understand the problem (have done MIRs before), i've not got time to really look into it till school tomorrow ;)
<dholbach> ok... I was just commenting on "we should have had those depends since three versions ago" :)
<dholbach> Noskcaj, if you get -3 from from proposed and install all (new) build-deps, "debuild -S -us -uc" should work
<pitti> hey jodh, good morning
<jodh> pitti: hi
<rbasak> jamespage: is anyone taking care of the haproxy component mismatch?
<rbasak> Maybe just delegate haproxy-doc to universe?
<rbasak> relegate
<jamespage> rbasak: not that I am aware of
<jamespage> rbasak: its a new js depends right?
<flexiondotorg> cjwatson, Can you tell me where I can find the code (file/library) that actually masters the official sanctioned Ubuntu flavour isos?
<cjwatson> flexiondotorg: lp:ubuntu-cdimage is the top level
<flexiondotorg> I had a quick grep of lp:ubuntu-cdimage
<flexiondotorg> File?
<cjwatson> etc/crontab
<cjwatson> I'm not going to walk you through it file by file, but you can trace it from there
<cjwatson> It calls out to Launchpad to build live filesystems (squashfs, etc.)
<rbasak> jamespage: yeah, but looks like it's only for haproxy-doc.
<rbasak> Unless I missed something.
<cjwatson> The top level of that is in lp:launchpad-buildd, basically lpbuildd/livefs.py
<flexiondotorg> What does it use to make the iso mkisofs or xorriso?
<flexiondotorg> I'm just looking for how it is invoked.
<cjwatson> xorriso nowadays
<cjwatson> that stuff is in the debian-cd branch linked from configs/devel in lp:ubuntu-cdimage
<flexiondotorg> cjwatson, Thanks.
<cjwatson> CONF.sh, tools/boot/utopic/*
<jamespage> rbasak: indeed it is only the docs
<rbasak> jamespage: so, docs to universe? I can't see anyone wanting that in production anyway.
<jamespage> rbasak:sure
<pitti> mlankhorst: do you have a wiki page/spreadsheet/similar where you collect feedback for the new X.org in the PPA?
<pitti> mlankhorst: I just upgraded/rebooted, and so far unity, video, glxgears, external  monitor are fine, I don't notice any difference
<mlankhorst> pitti: I'm asking for emails for now, easiest way :P
<pitti> mlankhorst: ack, I'll mail you on Friday or so, when I've run them for some time
<cjwatson> jibel,pitti: I don't suppose it would be possible to get an extra autopkgtest executor or two?  The queues seem to have been backed up somewhat of late
<pitti> cjwatson: it would be much more helpful if qemu wouldn't freeze all the time with current guest kernels :/
<pitti> the current retry-o-mania after wasting an hour or so is a nuisance
<jibel> the timeout is 50min when the kernel upgrade freezes :(
<pitti> cjwatson: not sure if we can easily get more hardware in the lab; a better option would be to switch to using HP cloud instances, vila is currently working on that (not in the context of -proposed testing, but it's not too different)
<pitti> jibel: it's not just kernel upgrades, I've seen it on other dist-upgrades to proposed, to
<pitti> o
<cjwatson> OK, well thought it was worth asking
<pitti> jibel: or at least I thought I did
<jibel> pitti, we could decrease install timeout
<pitti> jibel: 20 or 30 mins would certainly do, too; but large packages like libo certainly take some time to fetch/download/install their deps
<pitti> jibel: we could try with 20, and if we see "honest" timeouts with that, we'll increase again?
<jibel> pitti, 20 min sounds good. LO fails all the time anyway. maybe the kernel itself will be a problem.
<pitti> jibel: I suppose it happens with the kernel upgrade as they are particualrly big or have lots of files (linux-headers); it doesn't even get to rebooting the VM, so I think it's rather dying on I/O errors?
<pitti> jibel: no, kernel should be fine; build timeout is 100.000 s
<pitti> jibel: --timeout-install is just for dist-upgrade to -proposed and installing the test deps
<pitti> jibel: btw, the other day I tried to reproduce that locally, but I never saw qemu freeze
<pitti> jibel: it downloads the -proposed bits, reboots to the -proposed kernel, and happily goes on
<pitti> jibel: http://paste.ubuntu.com/7903813/ ?
<flexiondotorg> cjwatson, Other than the slightly different xorriso configuration for amd64+mac iso, is there anything significantly different in the iso contents?
<doko_> Sweetsha1k, https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 needs a MIR
<ubottu> Ubuntu bug 1349859 in libixion (Ubuntu) "[MIR] libixion (b-d of libixion)" [Undecided,Incomplete]
<Sweetsha1k> doko_: should that read "libixion (b-d of libreoffice)"? otherwise that subject doesnt make too much sense to me ...
<doko_> Sweetsha1k, no, liborcus, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<cjwatson> flexiondotorg: http://askubuntu.com/a/40480/3228
<Sweetsha1k> doko_: ah, ok. It starts to make sense now. ;)
<jibel> pitti, +1
<pitti> jibel: committed; can you roll this out, s'il te plaÃ®t ?
<jibel> pitti, done, I also disabled 'set -x' at the end of the script to stop polluting the console with a list of packages
<om26er> Hi! I was not able to find ubuntu's packaging branch for accountsservice, can anyone link please ?
<om26er> the one i found is 2 years old https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/accountsservice/utopic
<pitti> xnox: is bug 1320534 still an issue for you? I've used schroots for weeks under systemd
<ubottu> bug 1320534 in schroot (Ubuntu) "sbuild fails under systemd-boot" [Undecided,New] https://launchpad.net/bugs/1320534
<xnox> pitti: well, i just removed /dev/shm mount.
<xnox> pitti: do you have /dev/shm in your sbuild/schroot under systemd?
 * xnox does clean run test.
<pitti> I wouldn't know why not, but let me try again
<xnox> om26er: use source package + debdiff workflow $ pull-lp-source accountsservice, modify / add new changelog entry, generate source package and debdiff the two *.dsc, attach a patch to a bug report on launchpad.
<xnox> om26er: there are pleaora of packages that are not available as branches.
<pitti> jibel: oh, I'm just dist-upgrading a local VM: unpacking linux-headers indeed takes awfully long and pretty much kills the VM
<xnox> om26er: what specifically do you want to modify in accountsservice?
<pitti> jibel: but that's without an overlay on memory but onto the actual disk
<om26er> xnox, I want to backport this fix https://bugs.freedesktop.org/show_bug.cgi?id=78279
<ubottu> Freedesktop bug 78279 in general "Make accountsservice polkit policy work for non-local admin users" [Normal,Resolved: fixed]
<om26er> xnox, It allows me to write to accountsservice over ssh, right now its not allowed.
<xnox> om26er: well, create a debdiff as per above and open a bug on launchpad (if there isn't one already) and attach patch to it.
<om26er> xnox, I will propose to the ubuntu's source branch, which I assume is the same ?
<xnox> om26er: no, there is no source branch for ubuntu that matches the archive.
<xnox> om26er: archive is authoratative, please create a patch on the bug report.
<om26er> xnox, aah, ok, I will attach the debdiff then
<doko> tseliot, are you aware of https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.96.1 ?
<xnox> om26er: both patches and branches end up in the same sponsors review queue.
<om26er> xnox, I'll try with a patch pilot to get it landed early.
<pitti> xnox: oh, /dev/shm is not bind-mounted by default, I see; I now booted systemd, uncommented /dev/shm/ from /etc/schroot/default/fstab, now I have /dev/shm/ in my sid schroot
<pitti> tmpfs on /var/lib/schroot/mount/utopic-amd64-8e585e3f-4774-431e-87d8-f0afdb607c60/dev/shm type tmpfs (rw,nosuid,nodev)
<tseliot> doko: err... I hadn't noticed. pitti ^ ImportError: No module named 'aptdaemon.pkutils'
<tseliot> pitti: does it look familiar? https://launchpadlibrarian.net/177412602/buildlog_ubuntu-utopic-amd64.ubuntu-drivers-common_1%3A0.2.96.1_FAILEDTOBUILD.txt.gz
<pitti> tseliot: no, not at all; supposedly something in aptdaemon changed?
<tseliot> it seems like it
<xnox> pitti: hm, not /etc/schroot/default/fstab, but rather it is the default in /etc/schroot/sbuild/fstab and it's not a bindmount but a fresh tmpfs.
<xnox> pitti: and mounting/creating a tmpfs fails when booted under systemd.
<xnox> tmpfs           /dev/shm        tmpfs   defaults        0       0
<pitti> xnox: ah, that's different then; /me tests that
<pitti> xnox: how do I tell a schroot to use the sbuild profile?
<doko> who is currently caring about qtbase-opensource-src ? needs a merge from Debian
<xnox> doko: that would be Mirv i think.
<doko> not online
<pitti> xnox: err sorry, above line is already a tmpfs mount, not a bind mount
<pitti> xnox: so sbuild would automatically use the "sbuild" profile, while "schroot" would use "defualt"?
<xnox> doko: oh, qt4? probably ScottK, Mirv, Riddell, or myself...
<doko> no, qtbase-opensource-src
<ScottK> xnox: That's Qt5.
<ScottK> Or mitya57
<xnox> pitti: i'm fuzzy as to how the profiles are selected =) but yeah, changes to sbuild thingy make sbuild use those options.
<xnox> pitti: hence on the bug report, i've attached the failed sbuild log
<pitti> xnox: ah, there's a profile= option for chroot.d/*
<pitti> xnox: ok, now I get it
<xnox> doko: what specifically needs merging? there is a point release jump there....
<doko> xnox, yes, the point release. there are a lot of dep-waits
<xnox> *sigh* ok.
<pitti> xnox: hah, mystery solved. Followed up
<tseliot> doko, pitti: aptdaemon.pkcompat seems to be a little broken: http://pastebin.ubuntu.com/7904535/
<doko> barry, could you provide the MIR's for LP: #1349832 ?
<ubottu> Launchpad bug 1349832 in python-virtualenv (Ubuntu) "[MIR] dependencies for python3.4-venv" [Undecided,Incomplete] https://launchpad.net/bugs/1349832
<xnox> pitti: so..... mk-sbuild should be fixed? or should add /dev bind-mount to sbuild profile?
<xnox> ... or both?
<pitti> xnox: I suppose the symlink is a consequence of https://wiki.debian.org/ReleaseGoals/RunDirectory
<pitti> xnox: you could change your sbuild fstab to bind-mount /run/shm instead
<pitti> xnox: or just rbind-mount the whole /dev/
<pitti> /dev/shm/ isn't in /etc/schroot/sbuild/fstab by default, so I don't see how to fix the package
<pitti> perhaps adding a commented-out bind mount if that's a common case?
<xnox> pitti: why does it work when booted with upstart?
<xnox> pitti: is /run/shm missing?
<xnox> pitti: is /run/shm missing? under systemd that is?
<pitti> jdstrand: (really you this time :) ) I'd like to do bug 1341083; as ufw is also in Debian (but older), how wuold you like to handle this? I upload to Ubuntu and when you update Debian you take the Ubuntu package? or submit someplace else?
<ubottu> bug 1341083 in ufw (Ubuntu) "ufw needs systemd unit or init.d script" [Medium,Triaged] https://launchpad.net/bugs/1341083
<doko> barry, xnox: wait, why was python3-venv seeded?
<pitti> xnox: under systemd /dev/shm/ is the actual mount, and /run/shm doesn't exist (in git a symlink to /dev/shm/ was added)
<doko> we really don't want pip in main
<pitti> xnox: but in general stuff uses /dev/shm/, and /run/shm/ should be phased out
<xnox> doko: did i over-seed it?! =)
<pitti> where "stuff" is really just "libc"
 * xnox checks
<xnox> pitti: and breaking everyones existing sbuild chroots setup with mk-sbuild =)
<xnox> pitti: is symlink to /dev/shm in systemd in utopic-proposed?
<pitti> xnox: why everyone's?
<jdstrand> pitti: if you file a Debian bug and point to the Ubuntu bug, that would be good
<pitti> xnox: no, not yet; if it helps I can cherry-pick that, but AFAICS this wouldn't change this bug
<pitti> jdstrand: do you want me to just upload (after testing, of course), or a MP?
<jdstrand> pitti: I can also do the upload to Ubuntu if there is a debdiff
<xnox> pitti: for the past 5 years or so mk-sbuild was recommended and preffered way to setup sbuild chroots advertised to all developers. I understand that you probably set them up some old-school way =)
<jdstrand> pitti: an mp would be fine
<pitti> xnox: yes, that's what I use as well
<xnox> pitti: horum.
<pitti> xnox: but /dev/shm/ isn't in sbuild/fstab by default, so I wonder why this breaks everyone's setups?
<cjwatson> I've been using mk-sbuild and deleting the profile=sbuild bit for some time :)
<pitti> yeah, me too
<jdstrand> pitti: I would like to examine the unit file, both for my own edification and to make sure I understanding what it is doing
<xnox> pitti: i'm confused a little. let me try something out here.
<pitti> jdstrand: ack; I'll just attach it to the Ubuntu bug then?
<jdstrand> pitti: sound sperfect
<pitti> jdstrand: cheers
<jdstrand> typo notwithstanding :)
<jdstrand> pitti: thanks!
<pitti> jdstrand: I suppose the Debian package has an init.d script, so it's not that important there; but a native unit is still nicer
<jdstrand> pitti: it does-- there is logic in debian/rules on which to use
<pitti> jdstrand: ah, we should install the init.d script in either case though, for proper LSB dependencies
<pitti> otherwise a sysvinit script could never depend on ufw (not sure whether that has a practical meaning, but still)
<jdstrand> pitti: that handling is many years old, so I don't doubt it should be fixed, especially in light of recent changes
<doko> xnox, removed
<doko> bdmurray, cjwatson, slangasek: please subscribe foundations to python-idna and python3-dateutil bug reports
<cjwatson> doko,bdmurray,slangasek: done
<barry> doko, xnox didn't know it was seeded.  all straightened out now?
 * barry sees it was via email
<doko> barry, yes
<tvoss> pitti hey there
<om26er> xnox, looks good https://launchpadlibrarian.net/181062108/debdiff.patch ?
<om26er> attached to https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1349813
<ubottu> Ubuntu bug 1349813 in accountsservice (Ubuntu) "[org.freedesktop.Accounts.Error.PermissionDenied: Not authorized] While trying to change a ringtone" [Undecided,In progress]
<doko> tvoss, any update on LP: #1349834 ?
<ubottu> Launchpad bug 1349834 in libjsoncpp (Ubuntu) "[MIR] flask-script and libjsoncpp (b-d's for net-cpp)" [Undecided,Incomplete] https://launchpad.net/bugs/1349834
<tvoss> doko, haven't gotten to it, yet. I plan on patching out those build-deps from net-cpp
<xnox> om26er: looks good, assigned for pitti to review =)
<pitti> jdstrand: attached, working well now and the packaging got quite a bit simpler
<pitti> tvoss: hello
<jdstrand> pitti: thanks! :)
<om26er> xnox, thanks.
<pitti> om26er, xnox: yes, LGTM
<tvoss> pitti, un-"hello there" :)
<pitti> tvoss: /me undoes the warm handshake and hug then, too!
 * tvoss still hugs pitti
<tseliot> pitti: I have a one line patch for aptdaemon which fixes the issue http://paste.ubuntu.com/7904992/
<tseliot> pitti: shall I proceed with the upload? Do I have to update some bzr tree after that?
<pitti> tseliot: oh, nice! please upload, I can commit that to Vcs-Bzr:
<tseliot> pitti: yes, please. I'll take care of the upload, you'll deal with bzr
<pitti> tseliot: yep, will grab the diff from LP; thanks!
<doko> jamespage, LP: #1346056 probably needs some server love
<ubottu> Launchpad bug 1346056 in python-wsme (Ubuntu) "Please fix component mismatch introduced through sync python-wsme of 0.6-3 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/1346056
<jamespage> doko, ack
<tseliot> pitti: ok, aptdaemon_1.1.1+bzr973-1ubuntu4 is in. We'll also have to rebuild ubuntu-drivers-common
<doko> jamespage, infinity: about the jquery, ... libv8-3.14 component mismatches ... do we want this in main?
<jamespage> doko, v8 is a nack from the security team
<jamespage> so no
<juliank> tseliot: Wow, something's gone wrong somewhere. There's no aptdaemon_1.1.1+bzr973-1 in Debian, why is there an aptdaemon_1.1.1+bzr973-1ubuntu4 in Ubuntu?
<tseliot> juliank: I'm not really sure, all I know is that aptdaemon_1.1.1+bzr973-1ubuntu3 was breaking ubuntu-drivers-common
<juliank> Does not matter much, not going to package a bzr snapshot in Debian anyway.
<tseliot> juliank: mvo seems to be the uploader of 1.1.1+bzr970-1ubuntu1
<juliank> But apparently mvo mixed up 0ubuntu1 and 1ubuntu1
<juliank> slangasek: I asked you yesterday already: Do you still need gcc 4.6 & GNU_EFI_USE_MS_ABI support for gnu-efi (what for?) or can this be dropped, and the package synced from unstable?
<pitti> xnox: would you mind filing a Debian bug for bug 1326327 and CC: pkg-systemd-maintainers@lists.alioth.debian.org ?
<ubottu> bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327
<juliank> And if anyone here is interested in elilo, go and take it over in Debian or it will be removed.
<cjwatson> I don't think anyone here cares about elilo
<xnox> juliank: why not just take the patch into debian? the reasoning is entirely valid.
<xnox> juliank: http://launchpadlibrarian.net/151318291/gnu-efi_3.0u%2Bdebian-1ubuntu1_3.0u%2Bdebian-1ubuntu2.diff.gz
<cjwatson> (any more)
<juliank> xnox: I don't see the point in that patch. And I don't know if it even works anymore in 3.0v
<xnox> juliank: cjwatson: we do care about building shim on precise though, and that patch was backported all the way back to precise.
<cjwatson> sure, I was talking about elilo not gnu-efi
<xnox> cjwatson: ah, noticed now. sorry.
<xnox> juliank: but to answer (what for?) ->  to build src:shim on precise (12.04) which has gcc-4.6 as the default toolchain.
<juliank> xnox: That makes sense for precise then, but for utopic?
<xnox> juliank: at the time we had to backport everything to precise. I don't know if we will continue to backport e.g. gnu-efi to precise, if shim changes.
<xnox> juliank: anyway, i think that gcc-4.6 should be supported by gnu-efi, at least because of mac os =)
<xnox> juliank: and not cause a static compile time #error =)
<xnox> and because of 12.04 still being used for another 3 years.
<juliank> xnox: But I'm not sure it works, and I don't want to risk breaking things. gnu-efi was broken in unstable for a long time already because it used stub va_* functions. Now I switched it to use gcc builtins which is the only thing that works.
<xnox> juliank: please do not sync, and override/drop changes in ubuntu =) and update package as you see fit in Debian.
<xnox> juliank: and the patch we carry is not useless in ubuntu.
<xnox> pitti: If we were playing chess, I'd now say "check" ;-) bug 1320534 updated
<ubottu> bug 1320534 in systemd (Ubuntu) "systemd does not honor Ubuntu default mountpoints (as listed in /lib/init/fstab by upstart/mountall)" [Undecided,Confirmed] https://launchpad.net/bugs/1320534
<doko> zul, LP: #1349500 please remove the six code
<ubottu> Launchpad bug 1349500 in python-retrying (Ubuntu) "[MIR] python-retrying" [High,Incomplete] https://launchpad.net/bugs/1349500
<zul> doko:  ack
<doko> bdmurray, cjwatson, slangasek: please subscribe foundations to libisocodes bug reports
<arges> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<cjwatson> doko,bdmurray,slangasek: done.  thanks for going through these
<pitti> hallyn: FYI, I just created https://github.com/lxc/lxc/pull/285 to unbreak LXC under systemd
<doko> dobey, any update on ubuntu-sso-client?
<pitti> hallyn: do you think it's ok to upload that to utopic? I'd also like to add a systemd unit to set up the lxc bridge and load the AA policies, so that LXC works OOTB
<hallyn> pitti: loks fine to me
<hallyn> pitti: merged into git.  Do you want to push it to utopic?
<pitti> hallyn: ah cool, thanks!
<pitti> hallyn: yes; as I said, if you don't mind I'd like to add an lxc-net script with the guts of /etc/init/lxc-net.conf and create a systemd unit for this
<hallyn> pitti: yup, that'd be awesome
<pitti> bug 1312532 FTR
<hallyn> then I'll ake a look at it and learn a thing or two
<ubottu> bug 1312532 in lxc (Ubuntu) "[systemd] Factorize lxcbr0 setup and use it for all init systems" [Low,Confirmed] https://launchpad.net/bugs/1312532
<hallyn> fwiw I created a pair of cgmanager .service files yesterday.  seemed to be working <shrug>
<pitti> hallyn: ah, gretat
<pitti> great, even
<pitti> hallyn: I had to stop cgmanager under systemd as it breaks LXC
<hallyn> how does it do that?
<pitti> http://paste.ubuntu.com/7905528/
<hallyn> but yeah the systemd job is disabled by default so should help there
<pitti> hallyn: well, I suppose it's not actually cgmanager's fault, but LXC trying to talk to cgmanager when systemd does the cgroup management or so (I don't know the details)
<pitti> hallyn: indeed, yes
<hallyn> huh
<hallyn> pitti: 0.28-2 also was missing the patch which made cgmanager remount it's / private,
<hallyn> so you ended up with extra cgroup mounts on th system.
<hallyn> so 0.28-3 should be a huge improvement all-around under sytemd
<pitti> cool, looking forward to it
<pitti> and plusgood for getting in sync with Debian, eases bug fixing all aronud
 * hallyn is gonna have to disable the touchpad on this laptop.  it's huge!  why does eveyrone thing I want huge phones and huge touchpads?
<pitti> hallyn: +1
<hallyn> pitti: plusungood for burning bridges along the way :(
<pitti> hallyn: you mean like the heated discussions at plumber's about who wants to own the cgroup management?
<pitti> *sheesh*, these happen all the time, and IIRC that still was still surprisingly technical
<pitti> xnox: thanks for clarifying bug 1320534, sorry for closing prematurely
<ubottu> bug 1320534 in ubuntu-dev-tools (Ubuntu) "missing /run/shm backwards compat symlink" [Undecided,Confirmed] https://launchpad.net/bugs/1320534
<xnox> pitti: hm, now i can't find where does mk-sbuild get /run/shm from.
<pitti> xnox: I'm honestly not aware that I ever changed the "sbuild" profile fstab, so I never ran into that
<pitti> xnox: how do you mean? isn't mountall creating /run/shm?
<dobey> doko: i didn't get a chance to poke at it yet. i think i would probably just disable the tests at this point, i don't have time to debug squid. and my plate is full with getting things done for the phone beta :-/
<xnox> pitti: let me ask the question properly.
<pitti> xnox: oh, in my sid schroot /run/shm is an empty dir, so I figure debootstrap?
<doko> dobey, ok, if I upload doing just that?
<xnox> pitti: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674755#53 mbiebl syas that ubuntu-dev-tools should be fixed to use /dev/shm instead. But i see nothing in mk-sbuild that fiddles with /run/shm vs /dev/shm.
<ubottu> Debian bug 674755 in systemd "systemd: tmpfs inconsistencies (/run/lock, /run/shm, /tmp)" [Normal,Open]
<LocutusOfBorg1> simple question, is gsoap blocking the virtualbox migration, right?
<xnox> pitti: unless it's copying host settings, we change init, new host != container, caboom.
<dobey> doko: sure
<cjwatson> LocutusOfBorg1: the blocker there is gridsite
<LocutusOfBorg1> I see
<LocutusOfBorg1> interesting, the debian rebuild was successful
<xnox> pitti: so in my newly created mk-sbuild utopic, on utopic. shm is a symlink to /run/shm. What made it so?
<slangasek> juliank: yes, and I asked you in response whether Debian bug #753682 has been properly fixed
<ubottu> Debian bug 753682 in gnu-efi "gnu-efi: Undefined va_copy, causes gummiboot to FTBFS" [Serious,Fixed] http://bugs.debian.org/753682
<xnox> slangasek: not gonna update gnu-efi in precise? =)
<slangasek> juliank: in my last merge I was still maintaining compatibility with gcc-4.6 because precise uses it, and we've had to update gnu-efi wholesale in SRU before in support of shim
<slangasek> juliank: so I think we should keep that patch as the only delta for now; I'm otherwise happy to update gnu-efi as soon as #753682 is properly fixed (which I'll verify by rebuild-testing the gnu-efi revdeps like shim)
<pitti> xnox: good question; perhaps some sysvinit postinst?
<hallyn> wgrant: hey, do you have a strategy for typing on your t440s without moving the mouse around?  The "disable touchpad while typing" doesn't sem to be working
<xnox> pitti: horum.
<xnox> pitti: infinity what makes /dev/shm a symlink to /run/shm?
<wgrant> hallyn: I always disable that option, since I manage to not touch the touchpad while typing.
<wgrant> hallyn: But indeed, it seems to not work. Odd.
<hallyn> I guess my ogre hands aren't dainty enough or something :)
<xnox> pitti: initscripts.postinst ?
<pitti> xnox: bingo
<xnox> pitti: does your merge address that mess? =)
<pitti> xnox: hm, that creates the dirs, but not the symlinks
<juliank> slangasek: You did? I did not notice that
<slangasek> juliank: ok, lost to scrollback then :)
<slangasek> juliank: or I was talking to a ghost due to my IRC proxy lying to me about your presence ;)
<xnox> pitti: it totally does.
<pitti> xnox: I must be blind then; I only see mkdirs
<om26er> arges, Hi!
<arges> om26er: hi
<juliank> slangasek: Yeah, must be a ghost. The last thing I have received from you before today was on Dec 18
<xnox> pitti: if the 38 states state machine detects, RUNACTION LINKRUN or LINKDEV, either /run/shm is symlinked to /dev/shm, or /dev/shm is symlinked to /run/shm
<xnox> pitti: grep for "compat_link"
<juliank> that is, the last thing you wrote and mentioned juliank
<pitti> xnox: yes, that's defined, but nothing is using it
<om26er> arges, since you are the pilot, can you land my change ?
<om26er> bug 1349813
<ubottu> bug 1349813 in accountsservice (Ubuntu) "[org.freedesktop.Accounts.Error.PermissionDenied: Not authorized] While trying to change a ringtone" [Undecided,In progress] https://launchpad.net/bugs/1349813
<pitti> xnox: ooh, silly me!
<pitti> Version: 2.88dsf-53.2ubuntu1
<pitti> xnox: I have my proposed merge installed
<juliank> slangasek: And yes, that bug is properly fixed in 3.0v-5. I replaced all the va_* stuff in efistdarg.h with definitions using gcc builtins
<arges> om26er: looking
<pitti> xnox: was looking again in my utopic chroot, and that indeed does all that
<juliank> That's the only way to get it working with -nostdinc
<xnox> pitti: =))))))))
<pitti> xnox: so I guess that makes it a "yes" :)
<pitti>  xnox | pitti: does your merge address that mess? =)
<xnox> \o/
<xnox> pitti: so, when are we landing that?
<pitti> xnox: as soon as someone sends enough beer to slangasek to review my merge
<xnox> slangasek: we want pitti's merge to stop us from going on witch-hunts of insanity =)
<pitti> . o O { why don't we have a font for U+1F37A BEER MUG ? }
<slangasek> juliank: perfect, thanks
<slangasek> pitti: on the list for this week :)
<pitti> slangasek: you are speaking about creating a glyph for BEER MUG, of course
<slangasek> naturally
<arges> om26er: i noticed that no bug was mentioned in the changelog entry (i'm adding the one you posted)
<om26er> arges, oops! forgot about that.
<kentb> Hi, I'm looking for sponsorship on a package upgrade if anyone has some time to look at it.  Thanks!  https://bugs.launchpad.net/ubuntu/+source/sblim-sfcb/+bug/1335907
<ubottu> Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New]
<arges> om26er: ok sponsored for utopic!
<om26er> arges, wow, thanks
<shadeslayer> chrisccoulson: ping
<shadeslayer> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1274605
<ubottu> Ubuntu bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,Confirmed]
<shadeslayer> could someone *please* look at that
<LocutusOfBorg1> cjwatson, https://github.com/bagder/curl/commit/5fcef972b289bdc7f3dbd7a55a5ada0460b74b2d
<LocutusOfBorg1> this seems to be the problem, right?
<LocutusOfBorg1> I still don't catch if it a mistake or not, but should be the source of the problem of gridsite
<cjwatson> ah, interesting.  I'd be inclined to change gridsite to just use the new names
<LocutusOfBorg1> and the problem is in curl 7.37.1, the debian rebuild happened before, so we didn't get a build failure in debian
<LocutusOfBorg1> maybe curl made a mistake
<cjwatson> well, it failed to provide compatibility, true
<cjwatson> I guess I could backport that commit
<LocutusOfBorg1> what?
<LocutusOfBorg1> this is the commit that introduced the build failure...
<LocutusOfBorg1> AFAICS
<LocutusOfBorg1> I'm dropping a line on that commit
<pitti> hallyn: would something like http://paste.ubuntu.com/7905830/ be acceptable for upstream?
<cjwatson> LocutusOfBorg1: oh, gridsite and curl are trying to define mutually recursive includes, I see
<LocutusOfBorg1> yes
<cjwatson> which would be because CURLOPT_WRITEDATA is now a real symbol rather than a #define
<LocutusOfBorg1> I still don't get it
<LocutusOfBorg1> curl.h has
<LocutusOfBorg1> #define CURLOPT_FILE CURLOPT_WRITEDATA /* name changed in 7.9.7 */
<LocutusOfBorg1> and it is included before the define
<LocutusOfBorg1> htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)
<LocutusOfBorg1>  #define CURLOPT_WRITEDATA CURLOPT_FILE
<cjwatson> it's a real symbol rather than a #define, so gridsite's #ifndef fires
<cjwatson> because CURLOPT_WRITEDATA isn't #defined, it's an actual proper symbol now
<LocutusOfBorg1> oh yes
<LocutusOfBorg1> I missed the ifndef
<LocutusOfBorg1> anyway, if you got the problem I think my work is done ;) if you want I can try to fix it, I would like to see gsoap finish its transition
<hallyn> pitti: there's not some systemd-network-ish way that it would be properly done for the .service files?
<cjwatson> LocutusOfBorg1: I've got it, thanks
<hallyn> i think the patch is fine (apart from a /usr/share/lxc/$script sourcing /etc/default - i dont' know if that breaks some standards.  and you know how i love an drespect standards)
<cjwatson> I did the rest of the transition a day or two ago
<LocutusOfBorg1> yes I see, thanks to you :)
<LocutusOfBorg1> BTW thanks for the buildd stack migration
<cjwatson> mostly not me :) but yeah it's pretty cool
<cjwatson> so much less hassle
<LocutusOfBorg1> after 6 years I can start build on armhf packages depending from haskell suite
<cjwatson> surprised that didn't work before.  did it hate the hardy kernel?
<LocutusOfBorg1> don't know
<LocutusOfBorg1> something like haskell-blabla-0b15202 is not coinstallable with haskell-blabla2-f212
<LocutusOfBorg1> something like a bad haskell transition
<cjwatson> nothing to do with scalingstack then
<cjwatson> it's using the very same chroots
<LocutusOfBorg1> why is it working now?
<LocutusOfBorg1> I was wondering something qemu related
<cjwatson> what series are you building these against?
<cjwatson> no, installability won't be affected by qemu
<LocutusOfBorg1> ok let me see one thing
<LocutusOfBorg1> BTW I got already two segmentation fault in gcc
<LocutusOfBorg1> https://launchpadlibrarian.net/181061819/buildlog_ubuntu-trusty-armhf.boinc_7.4.0~nightly1~~git20140730%2Br21925~r184~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
<LocutusOfBorg1> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<LocutusOfBorg1> Segmentation fault (core dumped)
<LocutusOfBorg1> since the upgrade
<LocutusOfBorg1> the second one is here
<LocutusOfBorg1> https://launchpadlibrarian.net/181036546/buildlog_ubuntu-utopic-armhf.hedgewars_0.9.21~alpha~7716~ubuntu14.10.1_FAILEDTOBUILD.txt.gz
<LocutusOfBorg1> you see, now the installation part has been successful
<LocutusOfBorg1> (I'll try to search a build log with the failure)
<cjwatson> I'm sure the segfault was fixed by the kernel/qemu upgrade, yes
<cjwatson> oh, that's since the upgrade?
<cjwatson> well, did that fail before as well?
<LocutusOfBorg1> no
<LocutusOfBorg1> never
<cjwatson> in general we can't fix qemu failures
<cjwatson> at best we can escalate them
<cjwatson> but qemu-user is fundamentally pretty unreliable - if it works, celebrate, if not, sorry
<LocutusOfBorg1> btw the uninstallability problem of haskell stack was only with ppa builders
<cjwatson> don't believe that :)
<LocutusOfBorg1> https://launchpadlibrarian.net/132287908/buildlog_ubuntu-quantal-armhf.hedgewars_0.9.18-0.2~ubuntu12.10.1~ppa1_FAILEDTOBUILD.txt.gz
<cjwatson> LocutusOfBorg1: with -proposed disabled, it's possible that you were unlucky and hit a brief period when it was broken in utopic
<cjwatson> LocutusOfBorg1: oh come on you're seriously comparing quantal to utopic? :)
<cjwatson> it was probably just uninstallable in quantal
<cjwatson> since that predates proposed-migration, it would not at all surprise me
<cjwatson> but quantal isn't worth investigating now
<LocutusOfBorg1> https://launchpadlibrarian.net/140105253/buildlog_ubuntu-saucy-armhf.hedgewars_0.9.18-0.3~saucy1_FAILEDTOBUILD.txt.gz
<LocutusOfBorg1> I can try to rebuild a package, let me reproduce
<cjwatson> oh, wait, there's a qemu failure there, it's not package-level uninstallability
<cjwatson> qemu: Unsupported syscall: 257
<cjwatson> ghc: timer_create: Function not implemented
<cjwatson> right, so I believe that is one of the set of things fixed by the upgrade
<cjwatson> good, that makes sense now
<LocutusOfBorg1> yes, there was a bug against it
<LocutusOfBorg1> https://bugs.launchpad.net/qemu/+bug/1042388
<ubottu> Ubuntu bug 1042388 in qemu (Ubuntu) "qemu: Unsupported syscall: 257 (timer_create)" [Undecided,Triaged]
<cjwatson> anyway, it's great that that's fixed, but armhf virtual PPAs are still basically best-effort
<LocutusOfBorg1> I think it can be closed now
<LocutusOfBorg1> cjwatson, I'm not complaining ;)
<cjwatson> I don't know whether that deals with the problem pitti had in that bug trail, so reluctant to close
<LocutusOfBorg1> last thing, with the new format 0.4 {debupstream} isn't working anymore? deprecated?
<cjwatson> LocutusOfBorg1: do you have a link to a recipe build where that fails?
<cjwatson> LocutusOfBorg1: 0.4 didn't work *at all* before the upgrade
<LocutusOfBorg1> yes
<LocutusOfBorg1> https://launchpadlibrarian.net/181034312/buildlog.txt.gz
<LocutusOfBorg1> bzr: ERROR: bzrlib.errors.BzrCommandError: Invalid deb-version: {debupstream}~7716~ubuntu14.10.1: Invalid version string '{debupstream}~7716~ubuntu14.10.1'
<cjwatson> LocutusOfBorg1: odd, looks like that should work.  I can't investigate fully now, but please file a bug against launchpad-buildd
<xnox> we never upgraded launchpad to 0.4 recipes
<xnox> it needs newer something rather, that it doesn't have.
<cjwatson> xnox: yes we did
<cjwatson> xnox: on Monday
<xnox> i'm so out of date =)
<cjwatson> scalingstack brought us lots of shiny
<xnox> oh, we are on scaling stack now?! =)
<xnox> awesome.
<cjwatson> yup
<smoser> hey..
<cjwatson> it actually works and the builders have stopped falling over every ten minutes
<smoser>  there no equivalent to /etc/udev/rules.d/70-persistent-net.rules for block devices
<smoser> is that correct ?
<smoser> i know i could do things based on disk id or path with udev and guarantee links or something to the kernel device name in /dev
<xnox> jodh: we should try building procenv and upstart in virtualised ppas, as they should be awesome shiny now, instead of acient xen kernels.
<smoser> but is there anything that could explicitly guarantee that 'sda' was the name given to some block device and 'sdb' was to another.
 * LocutusOfBorg1 opens a bug report
<pitti> hallyn: re (sorry, was out for supermarket); this is the preparation for writing units which also call lxc.net
<pitti> hallyn: I don't know about systemd-network in particular, but it's very simple, and we don't want to build it in Debian/Ubuntu for now
<LocutusOfBorg1> https://bugs.launchpad.net/launchpad-buildd/+bug/1350430 cjwatson :)
<ubottu> Ubuntu bug 1350430 in launchpad-buildd "{debupstream} not recognised by format 0.4" [Undecided,New]
<doko> seb128, gtk+3.0 unconditionall build-depends on mir, which is not avail on powerpc and ppc64el
<seb128> doko, good observation
<Laney> wait
<Laney> since when?
<seb128> Laney, since robert_ancell uploaded the Mir backend earlier today
<doko> 3.12.2-0ubuntu5
<jodh> xnox: I've already got a virt build of procenv: https://code.launchpad.net/~jamesodhunt/+recipe/procenv-daily. Odd that it's set to build daily but hasn't since the 5th though.
<Laney> seems subideal
<seb128> indeed
<seb128> that's a bug
<seb128> those happen ;-)
<seb128> let me have a look, it's probably easy to change
<seb128> Laney, ^ or did you start looking (don't want to dup work)
<Laney> no you can, this laptop is too crappy to build gtk reasonably
<seb128> k
<Laney> patch headers would be welcomed too at the same time
<seb128> noted
<Laney> ty
<seb128> Laney, how is the hackfest btw? ;-)
<Laney> not enough power!
<Laney> but yeah, pleasant, there's quite a few people still here
<pitti> slangasek: ah, so I'm not objecting to building systemd-sysv, I just seemed to remember that the other day you said you don't want it yet; but that was probably in the trusty time frame
<LocutusOfBorg1> wow
<LocutusOfBorg1> the new buildd stack makes the build get stuck
<LocutusOfBorg1> https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439
<xnox> jodh: it builds daily, if there was any change in all the involved branches.
<xnox> jodh: this is not travis-ci =)
<infinity> 509 upgraded, 24 newly installed, 0 to remove and 0 not upgraded.
<infinity> Need to get 468 MB of archives.
<infinity> It's always pleasant to see a massive transition finally go through.
<infinity> cjwatson: Congrats.
<xnox> jodh: you can cron API to push "build now" for you =)
<jodh> xnox: thus, it should be labelled "built daily on change", not "built daily" since it's currently misleading :)
<jodh> xnox: regardless, you are right - we now see 3.13.0-32-generic in uname! :)
<cjwatson> LocutusOfBorg1: you know that #launchpad is the right place to ask about PPA builder problems, right?
<LocutusOfBorg1> cjwatson, now I know ;)
<LocutusOfBorg1> thanks
<cjwatson> infinity: only took weeks
<xnox> jodh: wow launchpad build on virt PPAs =)
<xnox> jodh: ehm upstart that is =)
<xnox> jodh: we should probably bump numbers in the recipes.
<jodh> xnox: omg green ticks everywhere! :-)
 * jodh thinks green ticks are better than red leeches :)
<xnox> cjwatson: it feels like double Christmas!
<hallyn> pitti: looks good then
<zul> doko:  done
<slangasek> pitti: right, could have been in trusty :)
<doko> zul, https://launchpadlibrarian.net/181072252/buildlog_ubuntu-utopic-i386.python-retrying_1.2.1-1ubuntu1_UPLOADING.txt.gz
<doko> no dependencies on python{,3}-six
<doko> echo six > requirements.txt
<doko> zul: swift autopkg test fails
<zul> doko:  ack
<hallyn> jodh: wgrant: aha!
<hallyn> syndaemon in unity is called with -t, which doesn't stop mouse movement.  dropping that flag fixes it
<hallyn> now i can type
<hallyn> pitti: so were you going to push that apparmor fix for lxc for systemd to utopic yourself?
<doko> zul: ??? http://launchpadlibrarian.net/181073883/python-retrying_1.2.1-1ubuntu1_1.2.1-1ubuntu2.diff.gz
<zul> doko:  crap sorry about this
<doko> xnox, did you already look at llvm-defaults?
<roadmr> mitya57: about bug 1349927, Would you agree to setting this bug as a duplicate of bug 1295835? I can also move it to qtchooser if it makes more sense.
<ubottu> bug 1349927 in qtdeclarative-opensource-src (Ubuntu) "qmlscene doesn't work on 14.04 and 14.04.1 without installing qt5-default" [Undecided,Invalid] https://launchpad.net/bugs/1349927
<ubottu> bug 1295835 in qtchooser (Ubuntu) "qtchooser should have a fallback mechanism (for version AND architecture)" [Critical,Triaged] https://launchpad.net/bugs/1295835
<arges> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> xnox: hey, were you going to remove the Essential: yes flag from init, then?
<slangasek> xnox: or maybe you've already done so and it's waiting in utopic-proposed?
<mitya57> roadmr: feel free to mark as duplicate
<roadmr> mitya57: thanks
<slangasek> barry: hi, are you aware of bug #1349478?  it's a top crasher on the phones currently
<ubottu> bug 1349478 in system-image (Ubuntu) "/usr/sbin/system-image-dbus:sqlite3.OperationalError:_check_for_update:emit_signal:UpdateAvailableStatus:__init__:__enter__:_cursor" [Undecided,New] https://launchpad.net/bugs/1349478
<barry> nope haven't seen that one yet
<slangasek> barry: can I assign it to you?
<barry> slangasek: already done :)
<slangasek> cheers
<barry> slangasek: i think this is the one that ogra_ pointed me to yesterday.  it can only happen if the directory /var/lib/system-image doesn't exist or has bogus perms.  which makes sense in the testing environment, but not on live devices (nothing changed here).  well, i guess something changed if this is happening on installed devices.
<Noskcaj> doko, Thanks for fixing jquery
<slangasek> barry: I don't know if the submissions are from installed devices or not - there are plenty of test environments proportional to installed devices right now :)
<barry> slangasek: true :)  i'm almost positive this is related to LP: #1301995 which fixed this for log files when run as non-root
<ubottu> Launchpad bug 1301995 in Ubuntu system image "system-image can't open its log file if not run as root" [High,Fix released] https://launchpad.net/bugs/1301995
<barry> guess where it's run as non-root?
<slangasek> barry: well, "from the apport hook", but I'm not sure if that's the answer you were looking for :)
<barry> slangasek: nope ;)
<barry> anyway, should be an easy fix.  i'll try to swing around to it asap
<Noskcaj> infinity, Could you merge wxwidgets3.0 soon please? I've got a merge waiting on it
<Unit193> Howdy.  So is there a specific date that tasksel updates Ubuntu tasks from seeds?  Or would I have to poke someon/Colin about that?
<doko> mlankhorst, online?
<arges> hallyn: do we use q35 machine type much for qemu/tools that use qemu in ubuntu?
<hallyn> q35?
<hallyn> i think qemu64 used to be the default.  haven't heard of q35 i dn't think
<arges> hallyn: yea machine type q35 vs i440fx (which seems to be the default for most tools virt-install/uvtool)
<hallyn> oh.  yeah, I don't think we do
<arges> <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
<hallyn> jamespage: smoser: do you kno wof any places where we use q35 (on purpose) machine type under qemu?
<arges> ok
<hallyn> arges: why do you ask?
<arges> hallyn:  trying to get virt-test working with Ubuntu, and it runs each test on i440fx and on q35
<arges> didn't know how widely used q35 was; since it doubles the tests
<smoser> hallyn, no. only if by default.
<hallyn> feh, seems i've not enabled kvm in the bios
<arges> well regardless if i440fx is default and most people use it we'll start there.
<hallyn> sounds good
<k1l_> hi there, since we got a lot of users complaining they are not prompted for the LTS -> LTS upgrade from 12.04 to 14.04 can someone tell me when the LTS upgrade path will be opened?
<asomething> Is there a script  to do a rebuild of a list of reverse dependencies in a ppa?
<doko> xnox, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756564  any idea about that?
<ubottu> Debian bug 756564 in cmake "cmake's FindFLTK module proposes static libs for linking" [Important,Open]
<xnox> doko: yes, i've seen that happen when libraries are either split badly (e.g. /lib /usr/lib and or multiarch symlinks are broken and/or non-existant) and then cmake goes south and does "statically link everything" which usually fails and fails the builds or worse succeeds the builds =(
<xnox> doko: i'll look into it tomorrow.
<xnox> slangasek: done, stuck in alpha2 block.
<xnox> doko: i do have llvm-defaults locally, but haven't uploaded it yet. Would be stuck in alpha2 block I think, and I haven't rebuilding everything yet.
<xnox> i wonder how long it takes a panda to build ghc =)
<xnox> or maybe llvm 3.5 is hung ;-)
<xnox> doko: what specifically breaks? as cmake FindFLTK should find /usr/lib/fltk/FLTKConfig.cmake, include it direct and get all the shared and static paths.
<xnox> doko: i'll experiment more locally here, but do you have example cmake using package that uses FLTK and doesn't get shared FLTK?
#ubuntu-devel 2014-07-31
<xnox> doko_: no point in updating llvm-defaults to 3.5, clamav builds, mesa fails. There are also others that fail with 3.5 - creduce & beignet
<xnox> i'll finish up building things tomorrow & will file bugs.
<hallyn> infinity: a 2.1 rc (very rc) is building in ppa:serge-hallyn/virt .   based on not-yet-released debian experimental package
<infinity> hallyn: Awesome, thanks.
<infinity> Oh, not that that builds for ppc.  But I can copy that and see what happens.
 * infinity does so.
<Unit193> cjwatson: Hello, is there a specific trigger for when you update tasksel from the seeds, or does someone have to poke you/request a merge?
<infinity> hallyn: Building for all arches at https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+packages if you're curious how that goes.
<infinity> doko_:
<infinity> Unpacking gnat-4.9 (4.9.1-1ubuntu2) over (4.9.0-1ubuntu5) ...
<infinity> dpkg: error processing archive /var/cache/apt/archives/gnat-4.9_4.9.1-1ubuntu2_ppc64el.deb (--unpack):
<infinity>  trying to overwrite '/usr/share/doc/gnat-4.9-base/test-summary.gz', which is also in package gnat-4.9-base 4.9.0-1ubuntu5
<infinity> doko_: ^
<cjwatson> Unit193: when I feel like it, basically
<cjwatson> Unit193: don't bother preparing a merge request if it's just an automatic update though
<cjwatson> Unit193: but it's 3am here and I generally like to think about the changes and make sure they're sane, so mail me?
<Unit193> cjwatson: Cool, OK.  Yeah, figured that would be a little useless.  I don't suppose that'll be soon?  Yeah.  3AM can be troublesome at times.
<cjwatson> it can be soon, but I'll need a reminder
<Unit193> A random poke later on IRC good enough or do you want that email?
<cjwatson> Unit193: as you like
<cjwatson> Unit193: but if you want an IRC poke to be effective it'll need to be vaguely within UK working hours :)
<Unit193> cjwatson: Got it, will do.  Thanks!
<pitti> hallyn: yes, I will, but I'm still working on the systemd units to start lxc.net and call the apparmor commands
<pitti> Good morning
<sarnold> pitti: wow, this seems early even for you :)
<pitti> sarnold: yeah, can't sleep any more; darn hayfever
<sarnold> pitti: ugh, sorry to hear it :(
<infinity> hallyn: So, it at least built on ppc64el.  Testing will come later.
<infinity> 19:31 < benh> hrm
<infinity> 19:31 < benh> W: Failed to fetch
<infinity> gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_trusty-updates_main_binary-ppc64el_Packages
<infinity>               Hash Sum mismatch
<infinity> 19:31 < benh> been going on for a while today
<infinity> pitti: ^
<infinity> pitti: Did you break something, or is that pilot error on Ben's part?
<pitti> infinity: I'm sure it's a ddeb-retriever issue again :/
<pitti> although I'm not sure how
<pitti> that Packages is from July 18, Release is from July 22, and it does have the wrong md5
 * pitti sends flowers to apt-ftparchive
<hallyn> infinity: awesome
<doko> xnox, http://people.canonical.com/~doko/tigervnc_1.3.1+X1.15.0-0ubuntu1.dsc
<doko> cjwatson, barry: seeding system-image causes some component mismatches, including python-pip again, which we were trying to avoid. is this really necessary?
<dholbach> good morning
<pitti> hallyn: hm, did you disable github pull requests for LXC? I can't send them any more, the button is disabled
<pitti> hallyn: I sub'ed to the ML now and went through the git-send-email exercise, including greylisting and all that fun *ugh* :)
<cjwatson> doko: yes it is really necessary, can you ignore it for now please and we'll sort out the seeds later (maybe move it to a different collection or something)?
<doko> cjwatson, ok
<xnox> doko: omg! why are you touching that beast?! =)
<doko> xnox, I'm not, just looking at component mismatches
<doko> or what is the context?
<xnox> doko: tigervnc =)
<xnox> doko: it tries hard to statically link against a self-included copy.... =)
<xnox> (embedded copy of code)
<doko> xnox, no, it is using the system one
<doko> xnox, http://paste.ubuntu.com/7912543/  using the system one
<xnox> doko: i have a crude patch.....
<xnox> find_package(FLTK) should find and define fltk_images_shared & fltk_shared, but it doesn't.... But we know the libraries are available from the global location.... so we can override it.
<xnox> http://paste.ubuntu.com/7912575/
<xnox> that gives me http://paste.ubuntu.com/7912581/
<doko> ahh, good, will go from there
<pitti> xnox: sorry, I already asked you about bug 1326327 (forward with CC'ing pkg-systemd) yesterday, but I think I didn't see your reply
<ubottu> bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327
<xnox> pitti: arrrr. there is nothing to apply in debian for ti.
<xnox> pitti: we had an ubuntu delta to drop, which is what that bug was about.
<pitti> xnox: oh, pirate speak day today? :-)
<LocutusOfBorg1> sorry which bits are missing for libpcap?
<LocutusOfBorg1> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> xnox: ah! nice
<LocutusOfBorg1> I don't see any, but still in proposed
<xnox> pitti: and it's unrelated to the other bug that i don't agree with, but affects both debian & ubuntu
<infinity> LocutusOfBorg1: "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<xnox> pitti: let me verify things though before closing it, that i did fix it right.
<infinity> LocutusOfBorg1: In other words, patience until after Alpha2.
<pitti> xnox: that patch isn't applied in current utopic FTR
<xnox> pitti: yeah, so e.g. looking at cgmanager_0.27-0ubuntu8_amd64.deb it has no postrm witch has "update-rc.d cgmanager remove"
 * xnox checks debian
<pitti> xnox: ah, I see it now in https://patches.ubuntu.com/d/debhelper/debhelper_9.20140613ubuntu1.patch
<xnox> yeah, and debian does generate "update-rc.d cgmanager remove" at purge.
<pitti> xnox: so, your patch LGTM
<xnox> we need both upstart-preinst & update-rc.d removal.
<k1l> hi: when will the LTS 12.04 to LTS 14.04 upgrade path be opened? we got masses on users in #ubuntu complainin they waited for the .1 release and still cant upgrade. is there a timetable for that?
<xnox> k1l: it's been open for a long while =) but there are bugs preventing upgrades, thus we have update-manager in precise-proposed to resolve that.
<xnox> k1l: once that is published in precise-updates and people install it, more people will get upgrade notifications and etc.
<pitti> xnox: will you upload, or want me to test with a cgmanager rebuild and upload?
<k1l> http://changelogs.ubuntu.com/meta-release-lts still says no trusty
<xnox> pitti: i think i need to reorder things, since $script is overriden by the preinst-upstart-compatibility.
<xnox> k1l: that's a bit odd.
<xnox> bdmurray: as per k1l above, have 12.04 -> 14.04 upgrades been enabled or are they waiting on update-manager fixes?
<LocutusOfBorg1> thanks infinity I read about the alpha, indeed, sorry I though there was a line on update_output too
<cjwatson> LocutusOfBorg1: update_output only reports on things that haven't been filtered out by individual-package checks at the previous update_excuses stage
<LocutusOfBorg1> ok thanks, fair enough
<TJ-> xnox: It's in meta-release-lts-proposed ... I guessed it was waiting on the 12.04 promotion of upgrade-manager-core from -proposed
<xnox> TJ-: yeah, i see that. But I have no idea what's the difference between meta-release-lts and meta-release-lts-proposed....
<LocutusOfBorg1> cjwatson, can I take a look at debian #755327 ? I don't know how to properly fix, but I can give you a debdiff
<ubottu> Debian bug 755327 in src:gridsite "gridsite: FTBFS: htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)" [Serious,Open] http://bugs.debian.org/755327
<cjwatson> LocutusOfBorg1: I already fixed that this morning
<LocutusOfBorg1> oh wonderful
<LocutusOfBorg1> :)
<xnox> pitti: actually with patch from the bug, it all looks correct and sensible.
<cjwatson> reload the bug :)
<LocutusOfBorg1> I was stuch in a gstreamer build with some spare time ;)
<LocutusOfBorg1> no NMU in delayed?
<xnox> pitti: uploaded.
<xnox> pitti: it is relatively harmless though, as any insserv invocation removes stale symlinks.
<cjwatson> LocutusOfBorg1: *shrug* might do that later, no rush
<LocutusOfBorg1> anyway, they fixed upstream with a slightly different patch https://github.com/CESNET/gridsite/commit/2124d471f9fc1eed4bf5893ed2701350357c01af
<cjwatson> LocutusOfBorg1: I'm busy this morning
<cjwatson> LocutusOfBorg1: feel free to pass a reference to the Debian bug
<LocutusOfBorg1> ack
<cjwatson> sure, that's fine too, just not something I felt entitled to do as a downstream
<pitti> xnox: ah, good; thanks!
<LocutusOfBorg1> yes, I'll prepare a debdiff with the upstream cherry-picked commit, I'm sure the debian maintainer will be happy to apply :)
<pitti> apw: do you still have bug 1329056?
<apw> lp: #1329056?
<apw> pitti, i do, but i realise that the fixes xnox tried for me didn't work because i have the WIP initramfs-tools on that machine, so all bets are off
<apw> i will try and get that downgraded
<pitti> apw: hm, mup failure?
<pitti> apw: oh, how would that affect lightdm?
<pitti> ubottu: <poke>
<pitti> apply resuscitation to ubottu
<Laney> #ubuntu-bots IIRC
<xnox> doko: found the bug in cmake-data FindFLTK -> it does everything to consider static FLTK only.
<Unit193> It takes a bit to sync up, has many channels to join.  ubottu that is.
<pitti> Laney: oh, it just sent me a privmsg complaining about <poke>
<pitti> bug 1329056
<ubottu> bug 1329056 in lightdm (Ubuntu) "lightdm does not start under systemd" [Undecided,Incomplete] https://launchpad.net/bugs/1329056
<pitti> \o/
<Laney> aha
<jamespage> pitti, cjwatson: would the foundations team considering owning pm-utils? its currently subscribed to by the server team but pretty much every bug I've touched this morning is a laptop suspend/resume problem of some description
<apw> pitti, the conjecture is that the main issue is that the systemd stuff doesn't work if you have encrypted stuff in your initramfs, and plymouth ends up there; and i have that inadvertantly
<cjwatson> jamespage: it's thematically appropriate but I don't know if we have any relevant experts
<apw> pitti, due to bugs in initramfs-tools, which xnox has fixed in the older version
<pitti> apw: ah, that's easy enough to test; installin "cryptsetup" should do that, right?
<xnox> apw: horum.
<apw> pitti, well no, it is meant to be bright enough to only do it if your actual root is special
<xnox> pitti: well, my cryptsetup hooks are modified to not include themself, if one doesn't have encrypted root.
<xnox> apw: did i actually upload that path fix, or not?! =)
<pitti> apw: oh, is that new? in the past we only installed cryptsetup-bin by defualt, and cryptsetup only if you actually use encrypted root
<pitti> apw: anyway, easy enough to check by the contents of the initramfs
<apw> xnox, though it if was fixed in cryptsetup i don't think my initrafms-tools would account for it
 * apw lets xnox figure out if he uploaded it or not :)
<xnox> pitti: so with https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu1 or better, encrypted root should work with systemd and systemd should be asking password via plymouth password ask.
<xnox> pitti: except it won't.
<xnox> pitti: cause our initramfs would ask for that....
<xnox> pitti: with that plymouth and a non-root encrypted fs, systemd should ask password for it via plymouth.
<pitti> apw: so, merely installing cryptsetup does get the plymouth bits into initramfs
<xnox> pitti: if that's the case, that's broken =(
<xnox> it's not meant to.
<pitti> well, that's how it always has behaved, hence my question about whether that changed recenlty
<pitti> but anyway, lightdm comes up
<apw> yeah i am a special snow-flake here for sure, it is somehow local to me
<apw> so i'd say not worry too heartily about it for now
<pitti> apw: AFAIR "sudo systemctl start lightdm" still worked for you, it was just not started automatically, right?
<pitti> apw: Im' worried because that doesn't sound initramfs-ish, much rather some locally modified sysvinit or /etc/default/ or whatever conffile
<LocutusOfBorg1> cjwatson, debdiff attached to the bug report and uploaded on mentors
<cjwatson> LocutusOfBorg1: ok, will leave it to the maintainer
<apw> pitti, it does start indeed when i incant as you say
<pitti> jamespage: in practice I do most of the uploads, but the whole concept of pm-utils quirks is a thing of the past; also, most of its bug reports shouldn't even be against it but the kernel, so bug reports are a lost cause :/
<Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742600 looks like it'd have problems with systemd-shim.
<ubottu> Debian bug 742600 in cryptsetup "cryptsetup: add support for systemd to askpass" [Wishlist,Open]
<pitti> apw: display manager startup is rather delicate, due to the various layers of configuratino that Debian piled up (enabling/disabling units, enabling/disabling syvinit files, default files, /etc/X11/default-display-manager, etc. -- lots of things that can go wrong
<pitti> apw: so, when you have a few mins, please ping me, and we can check and compare all these
<xnox> Unit193: not sure why it would, and we don't use askpass by default in ubuntu. We use plymouth ask-pass, as we require plymouth on all products.
<apw> pitti, ack will do shortly
<jamespage> pitti, I noticed your uploads
<tseliot> pitti: I restarted a build of ubuntu-drivers-common on amd64 and it went well. I've just restarted builds for all the remaining architectures, so there's no need for a reupload
<pitti> tseliot: right, for an FTBFS retrying the build is sufficient; thanks
<xnox> doko: with this https://launchpad.net/ubuntu/+source/plymouth/0.9.0-0ubuntu1 tigervnc just builds fine, and uses shared libraries.
<pitti> dpm: sorry, still no new export on https://translations.launchpad.net/ubuntu/utopic/+language-packs -- I figure something went wrong in LP?
 * pitti gazes at wgrant (yes, I know, everyone is, sorry :/)
<dpm> argh
<dpm> wgrant, do you know if the utopic translations export was cancelled for some reason? It was scheduled to start on Tuesday, but we cannot see it in https://translations.launchpad.net/ubuntu/utopic/+language-packs yet
<wgrant> dpm, pitti: Let me see.
<wgrant> I see no failures, weird.
<wgrant> I'll check deeper logs.
<dpm> thanks wgrant
<wgrant> Ah, I lie, I had just moved it to another folder.
<wgrant> It failed for the normal reason.
<wgrant> dpm: Is it particularly urgent? I can't reasonably kick one off before Monday without suspending some other fairly critical maintenance tasks.
<dpm> wgrant, I think Monday should be fine - pitti?
<pitti> dpm: sure, WFM; thanks wgrant!
<wgrant> dpm, pitti: The failures and concurrency limitations should hopefully go away with the new DB servers, fingers crossed.
<wgrant> Sorry about this.
<dpm> wgrant, that's good to know, thanks
<barry> doko: do you know what in system-image is pulling in pip?  it's not a direct Depends of si.
<doko> barry, see component-mismatches-proposed
<barry> doko: build depends
<xnox> barry: is that for unit tests? can it be moved into autopackage tests? (autopackage tests have universe enabled, even for packages in main)
<barry> xnox: not sure it's really appropriate for ap.  there's no ui and tons of dbus.  even so, it's probably a lot of work
<xnox> barry: it saves us from having pip pulled into main. Drop build-depends -> move to debian/tests/control depends and run that the same way things are currently run.
<xnox> barry: we do that for a lot of test suites which have dependencies beyond main, e.g. automake's full test-suite is only run as an autopackagetest.
<xnox> because it wants like all javas, haskells, fortrans and etc.
<barry> xnox: maybe.  seems like an unfortunate systemic problem really.
<barry> i mean, what's the point of having support for build-time tests if you can't use them? ;/
<barry> plus, they're not exactly the same environments, so in theory it could miss problems
<xnox> barry: they should be.
<xnox> barry: there are years old plans to abolish main/universe splits, have single archive and declare "depends" closed set, such that one can use universe build-deps. Worst thing is like boost, where I have two identical source packages: one to build most things in main, and one to build universe build-depends portions.
<barry> xnox: makes sense to me :)
<xnox> barry: how environments are different? it's still asserted that the test-suite is run before the binaries hit release pocket & autopackage test can have smaller stray dependencies than you'd have at build-time.
<xnox> barry: e.g. you can choose to not install build-essential, whereas on buildds it will always be there.
<tseliot> pitti: any ideas how I can support both systemd and upstart in nvidia-prime (LP: #1312255)? Are there any examples I can look at?
<ubottu> Launchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [Undecided,Triaged] https://launchpad.net/bugs/1312255
<barry> xnox: do autopkgtests prevent internet access by default?
<xnox> barry: mostly yes.
<xnox> barry: you have e.g. access to archive.ubuntu.com, but for further protection exporting a bad proxy helps.
<barry> xnox: right.  see, build-time tests (esp. with --buildsystem=pybuild) takes care of this for you automatically.  without this, it's easy to accidentally add a silent dependency that gets satisfied by pypi but not the archive.  this is just one example that comes to mind.  but i know in the past i've had issues where i tried to run the full s-i test suite in dep8 too, and got different results.  also, think about local reproduction -
<barry> with build-time tests, you can very accurately reproduce -- and debug! -- locally any failures.  you can do it with dep8, but it's more difficult and there's more variability (e.g. which virtualization do you use, etc.)
<xnox> barry: i'm telling you for autopackage test to do ./debian/rules test
<xnox> barry: and execute dh_auto_test --buildsystem=pybuild
<xnox> barry: but skip that bit, if python-pip is not available.
<xnox> (or well ./debian/rules override_dh_auto_test most likely)
<didrocks> barry: xnox: hey, a python2/3 question for you guys. So, I'm updating argcomplete for supporting both. There are some binary helpers that can work for both. I separated them in a different packages and have it depending on python2-argcomplete | python3-argcomplete flavors.
<barry> xnox: i've no doubt it can be made to work, but just saying it seems like a clumsy workaround for an artificial problem.  but anyway, i'll keep pondering it.  ultimately i think you're right, we need to abolish the split, esp. for build depends
<didrocks> however dh_python change the interpreter /usr/bin/env python to /usr/bin/python
<didrocks> so not really sure how I can have it working with both, so that you don't need to always install python-argcomplete
<barry> didrocks: it's the right thing to do.  devs should use /u/b/e but installed scripts should always use /u/b/python{,3}
<xnox> didrocks: i wish there was "#!/usr/bin/python2or3" which did the right thing =)
<didrocks> barry: yeah, so how do we do this? seems silly that if you install python3-argcomplete, you have to install python2-argcomplete for the helpers :)
<barry> xnox: yeah, that's come up many times.  i've even done a little hacking on a solution to that.  it's subtly tricky!
<didrocks> xnox: right! :)
<barry> didrocks: don't forget, anything with a shebang can be explicitly invoked too, e.g. $ python3 /usr/bin/mypy3shebangedfoo
<barry> er
<barry> $ python3 /usr/bin/mypy2shebangedfoo
<didrocks> barry: well, it's an end-user toolâ¦
<didrocks> not sure we'll ask them to
<barry> didrocks: the usual solution - not saying it's ideal - is to lay down /usr/bin/helper and /usr/bin/helper3 where almost literally the only difference is the shebang
<didrocks> yeah, not really nice
<barry> didrocks: and that can be very easy if you arrange your code where most of the logic lives in the library.  and in fact, using setuptools tricks, you don't even need to write the cli script (let it be generated)
<didrocks> that's the way other packages are doing it?
<didrocks> barry: it's not my code actually
<barry> didrocks: yep.  e.g. gunicorn, which i've recently been adding py3 archive support for (upstream supports py3)
<didrocks> (and yeah, I let it being generated)
<barry> so, in the gunicorn bpkg you get /usr/bin/gunicorn and in the gunicorn3 bpkg you get /usr/bin/gunicorn3
<didrocks> barry: ah, so, there is some magical trick in debian/rules to have a second version the python shebang?
 * didrocks apt-get source
<barry> didrocks: not in archive yet.  hang on, i'll get you the github url
<didrocks> seems like the perfect timing then :p
<barry> didrocks: indeed, the only way you could have done better is if you'd pinged me last night. :)  https://github.com/warsaw/pkg-gunicorn/tree/py3
<didrocks> barry: heh ;)
 * didrocks looks
<barry> didrocks: with a well-behaved setup.py and setuptools, the right scripts will be generated.  the trick you'll see in that package just have to shuffling the /usr/bin stuff around into the right binary package.  ping me if you have questions!
<didrocks> barry: so, I see that you mv the binary nameâ¦ I'm unsure how this helper dh_python3 to put the correct shebang
<barry> didrocks: in gunicorn `$python setup.py install` - which gets run by the build system (set DH_VERBOSE=1 for details) - is the thing that generates the correct shebang.  you can also add an `override_dh_python3: dh_python3 --shebang /usr/bin/python3` rule if you need to (man dh_python3 - i might have the wrong switch name)
<didrocks> barry: oh, perfect, so yeah, will do this then
<barry> didrocks: *gunicorn -> setuptools compatible setup.py based project
<didrocks> thanks a lot
<didrocks> yeah ;)
<barry> didrocks: yw!
<barry> :)
<xnox> barry: i have a tricky question for you =) how to run unit tests for metapackages under both python2 and python3?
<barry> xnox: "tricky" or "trick"? :)
<xnox> barry: cause for python2, i need the __init__.py with resource thing in-place and for python3 it must be removed (and the .pyc as well). And from a single tree that supports both python2 and python3 I have no idea how to do it?
<xnox> barry: apart from what i do now.... "rm __init__.py*; run python3 tests; bzr revert __init__.py"
<barry> ew
<xnox> barry: and that's just pure upstream with setuptools -> no debian packaging / pybuild, nothing else....
<barry> xnox: not sure what "the resource thing" is, but is the presence of the __init__.py the problem, or the contents of that file?
<barry> xnox: which project is this?
<hallyn> pitti: uh, no.  lxc gets tons of git pull requests.  maybe github was having an outage?
<barry> contents of file are easily hacked around with a sys.version_info test guard
<xnox> barry: either or i believe. Since presence of __init__.py makes it not an implicit metapackage in python3.
<barry> xnox: ah, you mean a namespace package (in python parlance)
<xnox> barry: it's lazr.* stuff. E.g. i want to run lazr.restfulclient test suite in $PWD against system lazr.uri, yet with __init__.py present locally system-wide lazr.restfulclient ends up being tested.... =(
<barry> xnox: i think i get what you mean.  yeah, unfortunately, there's no way afaik atm to fake not having an __init__.py to get a namespace package under py3, but a quasi-ns package under py3
<barry> *py2
<xnox> barry: which one of the two py3s was meant to be py2?
<barry> xnox: oops, sorry, the last one :)
<xnox> barry: i was thinking doing a build, and post-build under py3 force rm init.py? or like add it in post python2?
<barry> xnox: okay, so "tricky" :)  i can't think of anything off the top of my head.  i've run into this with my flufl.* packages, but never really dug deep to figure it out.  it's worth some experimentation though
<xnox> barry: can i force skip __init__.py copy/bytecompile/install under a given python version?
<xnox> barry: at the moment it looks like i should use autopackagetests =) as everything is installed globally and tested correctly ;-)
<barry> xnox: skipping bytecomp won't help.  seems like you'd like to be able to put an exception in there to "tell" py3 to treat the __init__.py as if it doesn't exist
<barry> xnox: yeah.  there should be a way at least to ensure you're not testing system packages.  i'd need to think more on it
<barry> and futz around with code
<xnox> barry: shall i prepare an example and throw it into ppa? or is the problem space well understood?
<xnox> barry: i think i should be overriding pythonpath, excluding systempath, yet including the things i want, and use relative imports.
<barry> xnox: i think i understand the problem, but maybe a bug report would be useful?  if so, subscribe me and i can dig into it when i have a little more time
<xnox> ack.
<barry> xnox: cheers
<kentb> hello, I've got a couple of packages that need sponsor review:  https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1349920 (SRU).  Supposedly a fix has been uploaded into debian for the same thing, but, I haven't seen it land yet.
<ubottu> Ubuntu bug 1349920 in The Dell-poweredge project "ledmon does not work in Ubuntu 14.04" [High,In progress]
<kentb> other one is:  https://launchpad.net/bugs/1335907
<ubottu> Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New]
<pitti> hallyn: perhaps; I read the "how to contribute" section and went the git patch email mail as advertised  then
<pitti> tseliot: it needs an init.d script or systemd unit which is equivalent to the upstart job
<tseliot> pitti: and some detection code too, so that it won't try to install the upstart job. This is the part I don't know how to handle
<pitti> tseliot: just looking at the job
<hallyn> pitti: i prefer email so good with me :)
<pitti> tseliot: so I recommend factoring out the rather complicated "script" section into /usr/share/nvidia-prime/nvidia-prime-start (or similar) shell script, and then calling that from the upstart job and systemd unit
<pitti> tseliot: oh, writing to the upstart log looks a bit odd, does that actually work?
<pitti> tseliot: if upstart has an open fd to the log at that time, wouldn't that just fail?
<tseliot> pitti: it's always worked AFAIK
<pitti> tseliot: but this is a message which should be on the screen anyway, so echo
<pitti> that way it'll land in the upstart log the proper way, or in systemd's journal with systemd
<pitti> tseliot: hm, where does /usr/bin/start-nvidia-persistenced come from? not from nvidia-prime apparently?
<tseliot> pitti: start-nvidia-persistenced comes from the drivers. Maybe that's what's causing the failure: http://paste.ubuntu.com/7915250/
<pitti> tseliot: eek, what is that?
<tseliot> pitti: unfortunately I have to delay the daemon or it will fail to start on boot
<pitti> tseliot: is that start-nvidia-persistenced?
<tseliot> pitti: yes
<tseliot> a bit of a hack, I know
<pitti> tseliot: ok; so nvidia-prime doesn't have a dependency to ensure start-nvidia-persistenced is there
<pitti> tseliot: would't that upstart job better belong into whatever actually provides nvidia-persistenced?
<tseliot> pitti: the drivers depend (recommend) nvidia-prime
<pitti> tseliot: and what reacts to bbswitch-ready?
<tseliot> pitti: the drivers provide nvidia-persistenced and the script
<tseliot> pitti: the drivers have the nvidia-persistenced.conf job that starts on bbswitch-ready
<pitti> tseliot: so perhaps nvidia-prime.upstart should not be "start on starting lightdm" but actually on something like "bbswitch is ready" (for whatever that is, an uevent, or something in /sys appearing  plus sleep 10)
<pitti> tseliot: so why does http://paste.ubuntu.com/7915250/ need to be a separate script, instead of just being in the .upstart?
<pitti> tseliot: what's the actual condition that needs to be satisfied here? the bbswitch module being loaded?
<tseliot> pitti: I wrote that last December but, IIRC there were race conditions (I don't remember exactly where atm)
<tseliot> pitti: bbswitch, and (I think) X, and proper X driver initialisation
<highvoltage> ~,
<pitti> tseliot: so like start on started lightdm and device-added SUBSYSTEM=graphics DEVPATH=bbswitch* (I'm making up the subsystem and the env match)
<pitti> tseliot: and this could then go directly into whatever reacts on bbswitch-ready? would that work?
<barry> didrocks: \o/ python-argcomplete (0.8.1-0ubuntu1) utopic; urgency=medium
<didrocks> barry: heh, yeah! ;)
<didrocks> barry: speaking of whichâ¦
<didrocks> barry: I see this interesting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748404 :)
<ubottu> Debian bug 748404 in wnpp "ITP: cov-core -- plugin core for use by pytest-cov, nose-cov and nose2-cov" [Wishlist,Fixed]
<pitti> tseliot: no idea what the bbswitch module does; an udevadm info --export dump might be insightful
<barry> didrocks: yep!  are you using it?
<didrocks> barry: right! ;)
<didrocks> in my virtualenv for now
<didrocks> I just need to backport it to trusty in my ppa (as I need to support trusty and I want to run my nose tests on it as well)
<didrocks> so, yeah, some hours won :)
<barry> awesome.  yes, i have a long-lived branch to add coverage to s-i.  still having problems collecting coverage data from dbus activated subprocesses tho
<barry> didrocks: :)
<tseliot> pitti: I'm not sure if that's enough but I can definitely try.
<didrocks> barry: I "just" have subprocess :p
<didrocks> barry: my docker tests are not trapped by the coverage, but I'm not asking for that much, subprocess support is already awesome :)
<barry> didrocks: yep, coverage should handle that although there's some inconsistent docs on the subject.  i think my problem is dbus :/
<didrocks> yeah, I guess can be something similar than my docker issue (when I ssh to a local container)
<didrocks> I see how hard it can be to track, even with the bindmount
<pitti> tseliot: anyway, it'll be much easier if http://paste.ubuntu.com/7915250/ isn't its own script (and not in $PATH), but part of the upstart/systemd job; but of course even better to find the actual startup condition :)
<tseliot> pitti: yes, I think I can make it much simpler now, thanks to some recent changes in the gpu-manager
<pitti> hallyn: oh BTW, not sure how notifications work, I reviewed the new cgmanager on mentors
<hallyn> pitti: oh no.
 * hallyn goes to look
<pitti> hallyn: ah, so IRC ping it is :)
<pitti> hallyn: so wrt. LXC, if I pretend cgmanager isn't started on boot (which is fixed in your new version), lxc-start-ephemeral works OOTB now
<pitti> hallyn: curiously lxc-start isn't, and fails with lots of apparmor denials on changing mount points to "private"
<pitti> hallyn: so the policy fix from yesterday is incomplete; I don't really have a good idea what the essential difference is between l-s-ephemeral and l-s, I'll keep digging
<didrocks> barry: works perfectly on trusty, muchas gracias :)
<barry> didrocks: \o/
<hallyn> pitti: i'd ping sarnold or jjohansen.  maybe there is a 'rbind' or 'rslave' option you can add to the policy
<pitti> hallyn: do you know, does /etc/apparmor.d/abstractions/lxc/start-container still apply to lxc-start? or does that need to go into /etc/apparmor.d/abstractions/lxc/container-base or similar?
<stgraber> pitti: lxc-start executes under the start-container profile, lxc-start-ephemeral (because it's a python script), doesn't
<hallyn> pitti: start-container applies during lxc-start, then switches to container-base when init is executed
<stgraber> lxc-autostart will also skip the start-container profile for similar reasons
<stgraber> maybe it's something we should fix :)
<hallyn> stgraber: we *could* have lxc-start-ephemeral manually move itself into the start-container profile
<pitti> stgraber: shouldn't you be on holiday? (but thanks, of course!)
<stgraber> hallyn: yeah, I actually wonder if symlinking the lxc-start profile to usr.bin.lxc-start-ephemeral would do the trick
<pitti> somehow this morning I got into a situation where lxc-start worked
<stgraber> pitti: nope, I'm back since Monday
<pitti> after I ran start-ephemeral, or some apparmor profile load commands, or something
<pitti> but I don't remember any more how
<pitti> hallyn: so that apparmor fix from yesterday definitively worked for some situation, but apparently I was in that "special" one ^
<pitti> stgraber: ah, did you have a good time?
<stgraber> jdstrand, jjohansen: hey, so can I have a profile for say usr.bin.lxc-start-ephemeral if that binary is actually a python script or would that only work if the profile was against the interpreter itself (not an option in this case)
<stgraber> pitti: yep, was nice, got lucky with the weather too, thanks!
<jjohansen> stgraber: you can have a profile against the script
<hallyn> stgraber: i may have to look into setting the t440s back and getting a mac :(
<jjohansen> stgraber: however if the script is started via the interpreter eg.  bash myscript.sh, then you either need to just confine the interpreter or have the interpreter do a change_profile for the script
<jjohansen> stgraber: basically any script that is started by binfmt_misc should work with kernel based profile attachment
<stgraber> jjohansen: ah great, I'll send a patchset upstream then, thanks!
<pitti> smoser: btw, http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=83172c8d - thanks for pointing out, it's a good habit to get into
<smoser> cool.
<pitti> apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=4405 comm="lxc-start" flags="rw, slave"
<pitti> jjohansen, jdstrand: so I tried to allow this ^ with this: mount options=(rw, slave) -> /,
<pitti> but that doesn't work; neither does mount options in (rw, slave) -> /,
<pitti> do you happen to have an idea what's wrong? just specifying "mount," makes it work, but that's of course way too lose
<pitti> or does that need some stracing to find out the particular mount() call it's trying to do?
<pitti> the corresponding lxc error message is "Permission denied - Failed to make / rslave" (quite expected, but for completeness)
<hallyn> pitti: uh, so,
<hallyn> pitti: what about patching systemd to not do MS_SHARED? :)
<hallyn> it'll also break containers wrt ip netns
<pitti> hallyn: big pain point :/
<pitti> this has been discussed a lot in the past year or so, and it's highly annoying
<pitti> rock (backwards compat with older releases) <-> hard place (break compatibility with stuff that expects shared by default)
<jjohansen> pitti hrmm, at a first pass that seems like it should work. Its possible there is a bug around rbind and MS_REC
 * jjohansen will have to poke
<pitti> jjohansen: the odd thing is, this line used to work, but not on current utopic
<jjohansen> pitti: oh! hrmmm, its possible something change in mount under us
<hallyn> 3.16 regresses in several ways :(  /proc also is mounted nobody:nogroup
<pitti> jjohansen: do you have an idea how I can relax this restriction a bit to see when it starts working? I tried "mount options=(rw, rslave) ** -> **", but that doesn't work either (not sure if that's valid)
<jjohansen> pitti: mount options=(rw, slave),
<hallyn> pitti: 2 questions,
<pitti> [pid  6584] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied)
<hallyn> 1. are we sure that 'Type=simple' will always be the default?
<pitti> ^ strace
<pitti> hallyn: yes; but feel free to keep it in there, it really doesn't matter much; that was mostly for simplifying the file
<hallyn> 2. should i hae dh_systemd_enable at top of that block and then the --nostart at bottom?  or only one call to dh_systemd_enable
<pitti> jjohansen: "mount options=(rw, rslave)" still fails
<hallyn> i mean, --no-enable
<pitti> hallyn: in general you call dh_systemd_enable $OPTIONS; dh_installinit $OPTIONS; dh_systemd_start $OPTIONS
<pitti> hallyn: i. e. all three with the same $OPTIONS
<jjohansen> pitti: this is current utopic kernel, and utopic userspace
<hallyn> pitti: yuck
<jjohansen> pitti: can you open a bug
<pitti> hallyn: I hope some day this will all move into dh_installinit
<hallyn> pitti: but so if i don't want dh_systemd_start, do i just put one call to dh_systemd_enable --no-enable at the top?
<pitti> jjohansen: sure; I'll test with the trusty kernel to ensure it's an acutal regression; I just wanted to check that this syntax is supposed to work
<pitti> hallyn: yes; but I still think it's safer to call dh_systemd_enable too; that stuff syncs up with the sysv stuff etc.
<jjohansen> pitti: it looks good to me
<pitti> jjohansen: thanks; so I'll do some kernel version bisection
<hallyn> pitti: not groking.  http://paste.ubuntu.com/7915722/ ?
<pitti> hallyn: something like http://paste.ubuntu.com/7915733/
<pitti> hallyn: sorry, with --no-enable for dh_systemd_enable
<hallyn> pitti: yuck again
<pitti> hallyn: yeah; as I said, it shuold really be in dh_installinit, but isn't yet
<hallyn> pitti: thanks.  i'll push another version in a min
<pitti> thus it's like dh_installinit_before and dh_installinit_after
<pitti> hallyn: oh, I think you can actually leave out dh_systemd_start (sorry for being confusing, I just read the docs again)
<pitti> "dh_systemd_start is a debhelper program that is responsible for starting/stopping or restarting systemd unit files in
<pitti>        case no corresponding sysv init script is available."
<pitti> but cgmanager does have an init script
<hallyn> pitti: as for the start-stop-daemon return values, that was cut-pasted from skeleton, but what you say makes sense so i'll change it
<pitti> hallyn: so: http://paste.ubuntu.com/7915761/
<hallyn> ok
<pitti> hallyn: oh, really? there might be some subtle semantics I missed, but "2" generally means "already runing", and that shoudl count as success, no?
<hallyn> pitti: the comments said 1 means already rnning, 2 means error <shrug>
<pitti> hallyn: right, or that way around
<pitti> hallyn: but it looked like it would return 2 if s-s-d returned 1
<pitti> (or vice versa)
<hallyn> pitti: i suppose it was racy, but it first checked with --test to see if it was already running, reutrned 1 if so;  then returned 2 on any start error
<hallyn> so long as start-stop-daemon does in fact always return 2 on error, then your way is better
<pitti> hallyn: ah, so that would have sorted out the "already running" case
<hallyn> well, races aside
<hallyn> actually in that case ssd will return 0
<pitti> hallyn: so for stop, --oknodo already deals with the "already running" case, and will then return 0
<hallyn> and ssd says it exits 3 on error
<hallyn> is it ok for the init scrip tto return 3?
<pitti> it also works for start, but not sure if it's ok to use it there, or whether you are supposed to return 1
<pitti> init.d scripts are also a big mess
<hallyn> so you think still use $?
 * pitti looks at http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
 * hallyn reboots to enable kvm, biam
<pitti> hallyn: so what the do_start() action returns to the "main" section of the init.d script is largely an implementation detail
<pitti> hallyn: the init.d script jsut needs to exit with 0 when it's already running/already stopped
<pitti> jjohansen: hm, so I tried the trusty kernel now (3.13.0-32) and also 3.15.0-6, and they both fail in the same way
<pitti> jjohansen: so not a regression then
<jjohansen> pitti: okay, thanks. can you strace the command that is failing
<pitti> [pid  8228] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied)
<pitti> lxc-start: Permission denied - Failed to make / rslave
<pitti> jjohansen: yes; ^ (see above)
<pitti> jjohansen: many similar ones, like
<pitti> mount(NULL, "/dev/pts", NULL, MS_SLAVE, NULL) = -1 EACCES
<pitti> i. e. for all mount points
<pitti> (which is the translation of rslave, I figure)
<jjohansen> pitti: and you tried
<jjohansen>   mount options in (rw, rslave),
<pitti> jjohansen: I tried with =, let me try again with in and no path
<pitti> jjohansen: same error
<pitti> jjohansen: same with (rw, slave)
<jjohansen> pitti: hrmmm, okay. I'll look into it, do we have a bug # for this yet?
<pitti> jjohansen: I'll file one now; it's a bit hard to reproduce, it requires a number of fixes to the lxc systemd scripts; but I think it can be reproduced under upstart with mounting everyhting as MS_SHARED before lxc-start, I'll look into that
<pitti> (it's not systemd specific, just specific to the default sharing)
<jjohansen> pitti: uhm, have you tried
<jjohansen>   mount options in (rw, rslave, rshared),
<pitti>   mount options in (rw, slave, rslave, shared, rshared),
<pitti> failed
 * jjohansen add wi to identify which flag a match is failing
<jjohansen> pitti: okay
<pitti>   mount -> /,
<pitti> fails as well
<pitti> the only thing that works so far is just "mount,"
<jjohansen> pitti: hrmmm, okay
<hallyn> pitti: new version pushed to mentors.  (no ack msg from mentors yet though)
<pitti>   mount -> **,
<pitti> jjohansen: ooh, that works
<pitti>   mount options in (rw, slave, rslave, shared, rshared) -> **,
<pitti> that doesn't
<pitti> hallyn: ack; will do tomorrow morning, getting late here
<jjohansen> pitti: is the message still info="failed flags match"?
<pitti> hallyn: thanks! (required some patience..)
<pitti> type=1400 audit(1406825689.899:812): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=9893 comm="lxc-start" flags="rw, slave"
<pitti> jjohansen: yes
<jjohansen> okay
<pitti> jjohansen: ack, very easy to reproduce under upstart with "sudo mount --make-rshared /", so I'll include that in the bug report
<jjohansen> oh nice, I like easy reproducers
<pitti> yes, who doesn't :)
<hallyn> pitti: ok - i'm going to test here under sysvinit and systemd, then maybe beg slangasek to push it (assuming it's working)
<pitti> jjohansen: bug 1350947, I hope the reproducer is clear enough
<ubottu> bug 1350947 in linux (Ubuntu) "apparmor: no working rule to allow making a mount private" [Undecided,New] https://launchpad.net/bugs/1350947
<pitti> jjohansen: at least with the start/reload/cleanup commands one can iterate/test very fast (< 1 s)
<jjohansen> pitti: thanks
<pitti> jjohansen: I filed it against linux, might also be a bug in appamor, of course (parser or so); I'll leave that to you
<jjohansen> ack
<pitti> jjohansen: thanks in advance!
 * pitti waves  good night
<popey> where should I filed a bug in the live 14.10 environment? (the initial boot menu has a "Back..." option which seems not to be needed, and is broken)
<roadmr> popey: https://launchpad.net/ubuntu-cdimage maybe? (I'm not sure though)
<bdmurray> doko: could you have a look at bug 1351018?
<ubottu> bug 1351018 in gdb (Ubuntu) "issues debugging program threads on 12.04" [Undecided,New] https://launchpad.net/bugs/1351018
<doko> bdmurray, sure, probably not tomorrow, will need to fix the gcc-4.9 cross compilers
<doko> bdmurray, I assume this is seen in utopic (7.8) too?
<bdmurray> doko: I haven't backported that version to precise
#ubuntu-devel 2014-08-01
<pitti> hallyn: thanks for teh lxc patch reviews; for those which you "acked-by"'ed, is there anything further for me to do, or will you just git am them to trunk? (they don't have particular dependencies on each other)
<pitti> hallyn: cgmanager uploaded to Debian, thanks! But I have a question about integrating the remaining Ubuntu delta in https://mentors.debian.net/package/cgmanager
<pitti> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> halfie: I also uploaded an Ubuntu merge
<pitti> halfie: sorry, tab error; I meant hallyn
<dholbach> good morning
<ptman> Hi! Is there a reason why http://changelogs.ubuntu.com/meta-release-lts doesn't advertise trusty? I thought do-release-upgrade should suggest trusty after 14.04.1 is released
<ptman> I can't view the bug reports related to https://code.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu
<sarnold> ptman: I heard there was a pretty severe upgrade bug ...
<pitti> hey dholbach
<pitti> infinity: does this make sense? https://code.launchpad.net/~braiampe/ubuntu/trusty/overlay-scrollbar/fix-for-1262022/+merge/218899
<ptman> sarnold, that would be a valid reason. Where should I be able to find out more?
<pitti> infinity: i. e. does an Arch: all package really need to be marked as M-A: foreign to satisfy non-native arch dependencies?
<pitti> infinity: that sounds wrong for arch: all, that should be implicit?
<dholbach> hey pitti
<sarnold> ptman: hmmm, this says 'fix released', maybe this wasn't the reason after all: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1347964
<ubottu> Ubuntu bug 1347964 in ubuntu-release-upgrader (Ubuntu Trusty) "Precise w/Trusty HWE -> Trusty release upgrade fails : ubuntu-desktop fails to configure" [High,Fix released]
<dholbach> Noskcaj, looks like doko fixed jquery
<dholbach> Noskcaj, did you have a chance to look at python-wsme or libgtop2?
<Tribaal> Hi all, silly question - my updated pacakge was pushed into trusty-proposed a while back (good), but I don't understand what it takes to land in the "real" archives. Could somebody shed light on the process?
<sarnold> Tribaal: you might find it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Tribaal> sarnold: nope, not on there
<sarnold> oh, trusty, not utopic.. probably wrong place..
<RAOF> Tribaal: It needs to be tested to work, marked as such, and then one of the SRU team will release it on the regular sweeps.
<Tribaal> oh no sorry
 * Tribaal blames coffee
<Tribaal> I tested trusty, but it should have landed in *utopic*
<Tribaal> nevermind :/
<LocutusOfBorg1> pitti,
<LocutusOfBorg1> sorry for bothering
<pitti> hey LocutusOfBorg1
<Tribaal> RAOF: so, it might actually make sense to backport the package that is in utopic now to trusty. Where should I start for an SRU?
<LocutusOfBorg1> Hi, did you notice the build failure of libvncserver?
<RAOF> Tribaal: https://wiki.ubuntu.com/StableReleaseUpdates ?
<LocutusOfBorg1> thanks for the other merges BTW
<pitti> LocutusOfBorg1: err yes, just saw the FTBFS mail coming in; apparently some uninstallability in -proposed?
<Tribaal> RAOF: thanks :)
<LocutusOfBorg1> pitti, the new package build-conflicts with libpng12
<LocutusOfBorg1> because it wrongly links png stuff when available
<LocutusOfBorg1> the problem is that I cannot reproduce on a clean pbuilder-dist utopic environment
<Tribaal> ah, maybe I should target trusty-proposed instead
 * Tribaal is a bit confused as to where the bits should ideally go
<LocutusOfBorg1> BTW I don't know why the hell the debian people but a build conflict on png instead of a simple "--without-png" in rules
<pitti> LocutusOfBorg1: so perhaps we should do that ^ ?
<LocutusOfBorg1> don't know pitti
<LocutusOfBorg1> I should talk with jcristau and luca about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725480
<ubottu> Debian bug 725480 in libvncserver "libvncserver: don't link against libpng" [Normal,Fixed]
<LocutusOfBorg1> I'm working on the package, will report back
<pitti> LocutusOfBorg1: right, so if there's a --without-png and that works, that seems better than a build-conflicts
<pitti> LocutusOfBorg1: cheers!
<pitti> LocutusOfBorg1: should be easy to check, it shouldn't generate a libpng dependency
<LocutusOfBorg1> yes I'm already doing that ;)
<LocutusOfBorg1> I removed the conflict, rebuilding
<LocutusOfBorg1> yes, ldd shows a libjpeg
<LocutusOfBorg1> rebuilding with the autoconf flag
<Tribaal> RAOF: so apparently an SRU is not what is appropriate in this case. Is it possible to put a package in -proposed instead? What is the policy there? (Sorry, I'm a new contributor as you can tell)
<RAOF> Tribaal: -proposed is the staging ground that we test things to go into -updates. You might be looking for backports?
<Tribaal> RAOF: ah, yes, probably
<infinity> pitti: It's not implicit for arch:all, no.  arch:all is implicitly mapped to the native arch for sane backward compatibility.
<pitti> infinity: hm; strange; why wouldn't it satisfy a dependency of e. g. an :i386 on amd64 to an arch:all package?
<pitti> it seems weird having to change all arch:all packages for that
<infinity> pitti: There were Good Reasons, but I can't think of that they are right now.
<infinity> pitti: slangasek probably remembers better, he drove a lot of this.
<pitti> infinity: ok, thanks; so this is good to sponsor (to utopic for now)
<infinity> pitti: I didn't read the MP, but if the reasoning otherwise makes sense, and the syntax is correct, sure.  If there's an all->any->all sort of chain in play, one needs to make sure that whatever combinations can be installed will actually make sense and work.
<pitti> ah, https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
<pitti> infinity: argh, can't sponsor; daily PS landing..
<Noskcaj> dholbach, I can't get wsme to work locally still, and i think it's best to wait for debian for libgtop2
<dholbach> Noskcaj, can't get to work in which way?
<Noskcaj> dholbach, http://paste.ubuntu.com/7921912/
<dholbach> Noskcaj, as I said yesterday: install all the build deps first, then start with -3 - it should work
<dholbach> if you don't have the build-deps, it'll try to download them
<dholbach> which will then look like a diff to be applied
<Laney> pitti: hey, can you moderate u-d-a?
<pitti> Laney: doing
<doko> ricotz, https://launchpad.net/ubuntu/+source/cogl/1.18.2-1/+build/6176965 please fix, this is a regression, please use dh-autoreconf
<pitti> Laney: congrats for alpha-2!
<Laney> cheers
<Laney> I hacked $TZ to make it happen on the correct day. ;-)
<doko> LocutusOfBorg1, libvncserver ftbfs on all archs
<pitti> see IRC scrollback 1.5 hours ago, he's on it
<pitti> Laney: yup, blame it on me for slow moderation :)
<LocutusOfBorg1> doko, ready above
<LocutusOfBorg1> :)
<LocutusOfBorg1> s/ready/read
<doko> ahh, thanks
<LocutusOfBorg1> I subscribed you to lp 1349386
<ubottu> Launchpad bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed] https://launchpad.net/bugs/1349386
<LocutusOfBorg1> since it is your patch :)
<LocutusOfBorg1> you can still take the first one and upload if you care ;)
<LocutusOfBorg1> there is also a git commit waiting for upload on debian, so maybe fixing first there is better, but I don't know, it is up to you
<pitti> LocutusOfBorg1: ah, https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/1349386/comments/6 looks good, thanks; will upload
<ubottu> Ubuntu bug 1349386 in libvncserver (Ubuntu) "please merge libvncserver from debian" [Undecided,Fix committed]
<pitti> LocutusOfBorg1: we can still sync later (much appreciated)
<pitti> LocutusOfBorg1: err, shouldn't --without-png be appended to dh_auto_configure insted of to dh?
 * pitti does that
<pitti> LocutusOfBorg1: uploaded with that change, thanks!
<LocutusOfBorg1> yes pitti that was a mistake
<LocutusOfBorg1> damn copy paste
<doko> pitti, this test result looks ok to me: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-gem2deb/ARCH=amd64,label=adt/
<pitti> doko: it's timing out; supposedly the new version is trying to download something from the network, or is just stuck in an infinite loop or something?
<pitti> doko: the unit tests succeeded, but the first integration test is stuck
 * pitti runs it locally
<pitti> doko: works locally, so I suppose it's trying to download stuff from the internet?
<doko> ahh
<doko> well, it's gem2deb ...
<doko> mitya57, want to have a look at a sphinx issue? https://launchpad.net/ubuntu/+source/heat/2014.2~b2-0ubuntu1/+build/6212253
<pitti> stgraber: I have a question for you in bug 1346734
<ubottu> bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734
<darkxst> pitti, hey, what are the systemd plans for this cycle? sticking with 208?
<pitti> darkxst: no, I hope 214 will land soon in Debian, then I'll update Ubuntu too
<pitti> darkxst: but I want to stay in sync with Debian
<pitti> i. e. same version (not literally the same source package)
<darkxst> pitti, ok that would be good, can't build any gnome until we have 210+
<darkxst> I fear everything is just broken again now ;(
<darkxst> pitti, though I did have 214 running from unit's packages, its pretty broken since the cgmanager/shim changes landed
<pitti> darkxst: oh, how's that?
<pitti> darkxst: 208 and 214 shouldn't be fundamentally different wrt. cgroups handling?
<darkxst> pitti, I see lots of cgroups failed, file not found messages
<darkxst> and drm fails
<darkxst> lightdm loads, but not mouse/keyboard ;(
<pitti> darkxst: oh, wait -- you probably still have cgmanager 0.27-0ubuntu8
<pitti> darkxst: try 0.28-3ubuntu1 (landed in utopic today)
<pitti> darkxst: that stops running cgmanager under systemd (indeed they fight)
<darkxst> pitti, could be mirror lag
<pitti> darkxst: yes, it really was just a few hours ago
<pitti> darkxst: in the meantime, try if "sudo /etc/init.d/cgmanager stop" helps
<pitti> darkxst: that's needed for e. g. making LXC work, too
<darkxst> pitti, I can't even get to a working VT or ssh
<pitti> darkxst: hmm; that sounds more like the symptom of having systemd 204 with cgmanager
<pitti> i. e. bug 1342586
<ubottu> bug 1342586 in systemd (Ubuntu) "[utopic] [proposed] cgmanager breaks lightdm login" [High,Fix released] https://launchpad.net/bugs/1342586
<darkxst> pitti, no 204
<darkxst> 208 works, 214 breaks
<darkxst> I see cgmanager update on mirror now, will try that
<darkxst> pitti, boom! I am in ;)
<pitti> darkxst: \o/
<pitti> @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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<didrocks> stupid question, but with a local sbuild installation, is there any hook to log inside the chroot on build failure?
<didrocks> google isn't my friend :/
<xnox> didrocks: yes.
<xnox> didrocks: you can set the option to preserve chroot session on build failures, and then use schroot to enter that session id
<didrocks> xnox: that would be perfect! do you have a handy pointer to that option?
<xnox> didrocks:        --purge-session=purge-mode
<xnox>               Purge the schroot session following a build.  This is useful in conjunction with the --purge-build and --purge-deps options when using snapshot chroots, since
<xnox>               by default the snapshot will be deleted.  Possible values are always (default), never, and successful.
<xnox> didrocks: so i think you want "--purge-session=successful", and then list sessions in chroot (and or look up the session UUID from the failed buildlog) and enter it with schroot.
<didrocks> xnox: let give me it a try :)
 * xnox assumes you are using snapshots of some kind (overlayfs, lvm, btrfs...)
<didrocks> yep
<xnox> barry`: i've re-ported lazr.authentication to python3, cause i didn't notice your port. I think it's mostly equivalent, apart from your port being more resiliant to accepting either bytes or strings in the middleware.
<xnox> barry`: or maybe not, cause e.g. i think autorization header is always string, yet in your code it's assumed to be bytes. Not sure.
<xnox> barry`: and i wouldn't want distribute to be commited =)
<didrocks> xnox: looking good! thanks a bunch :)
<pitti> infinity: I'm stunned by bug 1351295 -- I can't see how this makes sense; does that ring a bell per chance?
<ubottu> bug 1351295 in initramfs-tools (Ubuntu) "Boot fails if /sbin/init is an absolute symlink" [Undecided,In progress] https://launchpad.net/bugs/1351295
 * dholbach hugs pitti
 * pitti hugs dholback
<stgraber> pitti: hi
<pitti> salut stgraber, Ã§a va ?
<stgraber> pitti: oui, trÃ¨s bien et toi?
<pitti> stgraber: je vais bien aussi, merci; mais j'attends avec impatience le week-end :)
<stgraber> :)
<highvoltage> bon week-end Ã  tous
<pitti> stgraber: so I have a question for you in bug 1346734
<ubottu> bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1346734
<hallyn> pitti: stgraber normally applies the patchset after it's fully acked.
<pitti> hallyn: ah, thanks; so nothing left to do for me for those
<pitti> hallyn: I sent a fixed patch for the missing "git add", and had some questions about the first one
<stgraber> pitti: ah right, I saw your patches but since hallyn asked for some changes I didn't push them yet. I'll look at the mailing-list in a bit and process what's there.
<stgraber> pitti: I also plan to tag alpha2 early next week (Monday or Tuesday) so unless you're in a big hurry, you'll get the change in the distro then
<pitti> stgraber: that sounds perfect
<pitti> stgraber: there's still bug 1350947 (but that has an easy workaround) anyway
<ubottu> bug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [Undecided,Triaged] https://launchpad.net/bugs/1350947
<pitti> stgraber: but I'm not in such a hurry; I have my changes to trunk installed locally, so I'm a happy camper :)
<hallyn> yeah that one has to wait on apparmor iiuc right?
<pitti> hallyn: not sure whether it's in the parser (appamor) or in the kernel, but either way; jjohansen kindly said he'd look into it
<pitti> hallyn: but for testing it's an one-line addition to the policy (I put the workaround in the bug)
<hallyn> pitti: reagrding the apparmor load patch,
<pitti> so doesn't block development/testing
<pitti> hallyn: btw, new cgmanager working well; you also made darkxst happy :)
<hallyn> hm, i guess it's ok.  it'll just do nothing if that prog doesn't exist
<hallyn> pitti: I don't know who that is, but thanks :)
<pitti> hallyn: ah, if you want to keep that in the distro for now, that's ok for me
<hallyn> no, it' sok, i just wanted to make sure it won't break fedora etc
<pitti> hallyn: once we have systemd 210+, we can probably just replace that with an ApparmorProfile= in the .service
<pitti> hallyn: there's probably a more elegant way for Fedora ^
<hallyn> 210+ has apparmor suport built-in?
<pitti> yes, apparently
<pitti> profile loading
<pitti> hallyn: but anyway, it's all protected by test's, and no apparmor (by default at least) on Fedora, so I believe it should be reasonably safe
<hallyn> so i'm back on my 4 year old sony.  it's like an old, i dunno, what do you put on, an old shoe?  and old glove?  my idioms fail me
<stgraber> pitti: can you send your sign-off for the batch?
<stgraber> (unless I missed it)
<mdeslaur> pitti, hallyn: systemd only has profile _switching_, not loading...we need to create a proper apparmor parser library so we can get systemd to load apparmor profiles properly at boot
<michagogo> pitti: thanks!
<xnox> mdeslaur: and upstart?
<xnox> mdeslaur: is that switching only as well?
<mdeslaur> xnox: upstart has loading, and switching
<xnox> mdeslaur: excellent. I wonder if I can do archive wide massacare of /lib/init/apparmor-profile-load usage
<xnox> =)
<mdeslaur> xnox: but we call the parser in upstart, and it was made clear on the systemd list that we shouldn't do that, but link to a library
<hallyn> mdeslaur: and does someone have time to do that?
<pitti> stgraber: you mean self sign-off all the patches and re-send them all?
<pitti> mdeslaur: ah, thanks; so we'll still need that script
<mdeslaur> hallyn: we know we need to do it soon...it's planned, we just haven't gotten to it yet
<pitti> michagogo: err - you're welcome (for whatever :) )
<michagogo> pitti: 1314616
<stgraber> pitti: or just reply to Serge's last e-mail asking for a single sign-off for the whole series
<pitti> michagogo: ah :)
<pitti> stgraber: ok; I never understood the purpose of Author: having to sign off himself, but sure :)
<xnox> pitti: it's a declaration that you own copyright, and/or have appropriate permission to open source it.
<stgraber> pitti: it means that you confirm you have the right to give that to the project (as in, your employer allows you to)
<xnox> *snap* =)
<pitti> I'm sure sabdfl doesn't mind me contributing to LXC :)
<xnox> pitti: without consulting colicitor first?! =)))))) https://code.launchpad.net/~harmoney/upstart/manpage-fixes/+merge/20878
<xnox> ( i loved that merge proposal comments )
<pitti> hallyn: replied to both now
<pitti> xnox: colic.. WHAT? get a room!
 * pitti hugs xnox, TGIF
<pitti> xnox: oh argh; yay bureaucracy
<xnox> pitti: i mean a lawyer =)
<xnox> pitti: TGIF - T.G.I. Friday's?!
<xnox> pitti: re: systemd-sysv, can't it just install real files and do dpkg-divert and not conflict with upstart?
<pitti> hallyn: ooh, sorry, I understand now
<xnox> pitti: imho, at the moment we want to be able to install systemd-sysv and be able to uninstall it to go back to upstart.
<pitti> hallyn: git-email converts Author: to the email From:; I'm too used to attaching patches to mails, instead of sending ptaches *as* mails
<pitti> see, I can even learn stuff on a Friday afternoon!
 * pitti needs an ice cream now to cool down his brain after this enormous exercise (and also go for some errands)
<xnox> pitti: as i new comer to VCS systems - git was my first one ever. And it all made sense until I was asked to setup mta for the first time and somehow learn that the "format-patch" thing it generates doubles up as an email was a complete mystery to me.
<pitti> wow, you are young!
<hallyn> heh
<hallyn> pitti: regarding full paths, my point was precisely that by pulling a part of the init script into a script elsewhere on the system, you're encouraging use by something other init, where paths are *not* sanitized.
<hallyn> of course all setuid-root binaries *should* be sanitiziing paths, but this is a favorite exploit in capture-the-flag contests at least :)
<tseliot> pitti: thinking of nvidia-persistenced, I think I've found a udev rule that could work to start the nvidia-persistenced daemon. I also have to stop the daemon using udev. Is there a recommended way to do it?
<barry> bdmurray: ping me when you're online
<bdmurray> barry: I'm online
<tseliot> pitti: never mind, problem solved
<jpds> $ sudo apt-get install rtpproxy
<jpds> $ grep DAEMON /etc/init.d/rtpproxy
<jpds> DAEMON=/usr/sbin/$NAME
<jpds> $ ls -l /usr/sbin/rtpproxy
<jpds> ls: cannot access /usr/sbin/rtpproxy: No such file or directory
<jpds> Ah, quality.
<stgraber> barry: system-image-cli is missing a depend on python3-dbus and python3-xdg
<barry> stgraber: dang.  i think both should be added to system-image-common.  i can do that for 2.3.2 which is in the citrain now
<stgraber> barry: do you ever still test system-image-cli without udm?
<stgraber> barry: I'm testing an ubuntu core image with system-image and it appears to hang on downloading the indices
<barry> stgraber: no.  it's currently non-functional without udm.  i have a stalled branch that adds an asyncio internal downloader alternative but haven't had time to finish that yet
<barry> stgraber: and yes, there are occasional "weird" things happening with udm ;)
<stgraber> barry: hmm, ok, it's going to become pretty critical seeing how we need this to make progress on the ubuntu core system image stuff
<stgraber> slangasek, jodh_: ^
<stgraber> hmm, hold on, udm is actually installed
<stgraber> (which we probably don't want in this case, but still, things should kinda work then...)
<slangasek> yes... using udm for server images may not make the most sense, but it should be functional for a first cut :)
<stgraber> yeah, trying to figure out why it doesn't... no errors in the log...
<stgraber> ok, so the target dir didn't exist (we need to set this to something else than /android/cache/recovery ...), creating it and killing udm did the trick
<barry> stgraber: oh jeez, i just got a crash of udm doing a local test build of si 2.3.2.  this is after this morning's dist-upgrade
<barry> so i think that's a new problem
<barry> (existing known problems w/o resolution: it occasionally downloads files to the wrong place, and there are intermittent timeouts)
<barry> looks like the crash was in passing a pause signal to udm
<slangasek> pitti: fwiw these dependencies on upstart can mostly be dropped not because the packages support systemd as an alternative, but because they're versioned deps that are no-ops post-14.04
<jcastro> is `do-release-upgrade` from 12.04 supposed to prompt for 14.04.1 yet?
<jcastro> aka. did we flip the switch?
<TJ-> jcastro: I think the update to meta-release-lts has been delayed by a 12.04 update-manager bug-fix in precise-proposed
<TJ-> jcastro: Not 100% since no-one has admitted responsibility for a finger on the switch :)
<jcastro> TJ, thanks
<ventura> i wish to deploy deb packages to my ppa, however i need that during the install processes the 'terms of service' be displayed to the user
<ventura> how is it done according to ubuntu policies? preinst scripts?
<dobey> what are you packaging that would require a terms of service be displayed at install time?
<dobey> and do you have a commercial support contract on launchpad? because its terms do not allow you to put non-redistributable software in a PPA unless you have a commercial agreement and own the rights to that software
<ventura> for example, a oracle java 7. if i wish to create a debian package of it.
<ventura> 1. does is respect launchpad terms?
<rww> Oracle Java isn't allowed in Launchpad.
<rww> Oracle changed the licensing terms, so...
<ventura> rww: uhm
<rww> I think webupd8 has a PPA which packages it similar to Flash where they download it from Oracle's site, though
<rww> (i.e., there's no actual Oracle property in the PPA)
<dobey> ventura: yeah, you can't ship the binaries, oracle's license doesn't allow redistribution
<ventura> dobey, oracle was an example. however the point is extremely valid, thus i have to read if the terms of the binaries i wish to ship allow it too.
<ventura> rww++
<ventura> dobey++
<dobey> ventura: if you don't have a commercial agreement with launchpad, and own the rights to the code, you can't put the binaries on launchpad. and there are almost no proprietary things that allow binary redistribution
<dobey> if you want to make proprietary things installable, you're going to have to do it by writing an open source installer app and shipping that and/or doing an install in the same way that the flash plug-in does
<ventura> dobey: thx
<xnox> ev: slangasek: why do we care about getting the same whoopsie id across re-installs? Full reinstall -> new encornation thus should be new id.
<xnox> it doesn't affect any stats, as we only count active/relecently seen ids, and reinstalled machine with new id, is one for one trade.
<xnox> we should use file cache / machine-id, and only if all fails doing the mac/imei guessing.
<xnox> (i.e. stateless case)
<xnox> it's not scalable that all launched emulators with same MAC and same IMEI have same whoopsie id.
<xnox> root vs non-root user has different whoopsie ids =)
<slangasek> xnox: we do care about being able to identify a device across reinstalls, for associating on errors.ubuntu.com
<xnox> slangasek: no, we don't. =)
<xnox> slangasek: i do factory reset, and sell my phone. I don't expect for new user to see my crashes =)
<xnox> slangasek: and we have changed ID implementation at least 3 times now, and thus broke machine association.
<xnox> (for typical machines)
<xnox> using /etc/machine-id or even /var/lib/dbus/machine-id would have preserved association.
<slangasek> xnox: there are reasons to prefer they not be visible, but for testing, where the device will be regularly reinstalled, not having a persistent id that they can use for locating the device is problematic
<slangasek> now, if we were to use machine-id as the basis, maybe the answer would be for the test environment to update that id
<xnox> slangasek: testing things should set CRASH_DB_IDENTIFIER environment variable, which can be passed e.g. on kernel command line.
<xnox> slangasek: which overrides internal whoopsie identifier generator.
<xnox> , if that fails and we have a machine-id, i think that should be used.
<slangasek> editing the kernel commandline is hardly the most convenient interface on the phone
<xnox> and only last case scenario - completly read-only stateless system -> use the generator.
<xnox> slangasek: then we should extend both upstart and systemd units to source the /etc/default/whoopsie such that one can specify ID there.
<xnox> slangasek: is that file RW on the phone?
<xnox> (i'm not sure the current state of affairs around how to enable/disable it)
<slangasek> no, it's not, and there's no particular reason to put it in that file
<xnox> ack.
<xnox> slangasek: well, i need to introduce a stable / persistant storage for the id, make it world readable, and make sure it's used by default.
<slangasek> I'd rather we modify /etc/machine-id as part of the provisioning and make whoopsie honor that, than push it anywhere else
<xnox> IMHO it's redicilous that whoopsie_identifier_generate() call is returning different value for root and non-root user.
<slangasek> hah, does it?
#ubuntu-devel 2014-08-02
<xnox> Chipaca: please use /etc/machine-id, anything else is broken.
<slangasek> xnox: nack
<slangasek> /etc/machine-id is *also* broken
<slangasek> it's *the same on every device*
<Chipaca> xnox: for what?
<xnox> slangasek: WHAT?!
<slangasek> you're jumping the gun slightly :P
<slangasek> xnox: it's in the base image, how would it have been made unique?
<xnox> slangasek: /etc/machine-id must not be the same =
<slangasek> that's nice ;)
<xnox> Chipaca: push & unique identification.....
<xnox> slangasek: let me check livefs image to see if all /etc/machine-ids are the same on all ubuntus....
<xnox> (ditto dbus ids)
<slangasek> dbus ID is handled
<slangasek> /etc/machine-id is a neologism
<xnox> slangasek: /var/lib/dbus/machine-id should be a symlink to /etc/machine-id in the new world order....
<slangasek> all these opinions
<slangasek> fwiw mine are in sync, but it's not a symlink
<slangasek> and I don't see what creates /etc/machine-id
<xnox> slangasek: ok. i have one task to fix, i should focus on that =))))
<xnox> *sigh* /etc/machine-id is on the livefs image....
<slangasek> ok.  what creates it?
<xnox> slangasek: looking at the source code systemd-ish something does it.
<slangasek> just because systemd upstream has defined this as an interface for a unique ID in no way means we've started supporting it as such
<xnox> systemd-machine-id-setup
<slangasek> we still have /var/lib/dbus/machine-id as uniqueu
<xnox> it uses dbus/machine-id as seed, if there was one.
<slangasek> xnox: so in the long term, the installer / live-builder should be updated to handle /etc/machine-id specially, just as /var/lib/dbus/machine-id is currently handled.  In the near term, /etc/machine-id is an irrelevant and unsupported interface. :)
<xnox> slangasek: bug against cdimage project?
<slangasek> xnox: I still have no idea what is meant to be creating /etc/machine-id, 'systemd-machine-id-setup' isn't part of either the boot scripts or the maintainer scripts
<slangasek> xnox: yes
<xnox> slangasek: installer is suppose to call systemd-machine-id-setup, otherwise, i guess first caller triggers it's creation....
<slangasek> what's the "first caller"?
<slangasek> do you mean the first thing that queries the machine ID?
<xnox> systemd-firstboot.service , but of course /me is friday trolling
<xnox> i'm guessing logind session.
<xnox> or same as dbus-uuigen. I'll trace that later. No clue yet, where/how it ends up generated on ubuntu.
<juliank> I'd recommend to ask systemd guys or look at more recent systemd code. Given all that booting without /etc stuff they're doing, they probably have newer versions generate that if it is missing
<juliank> Might make sense to copy that then
<hallyn> xnox: uh oh, i notice that the 0.28-3ubuntu1 cgmanager upstart job has the post-start "initctl ... || true" in exec instead of inside script.  Needs an update?
<xnox> hallyn: no, why?
<hallyn> oh, i thought there was talk last week of || true not working in a exec
<hallyn> if not, excellent
<xnox> hallyn: exec -> single line; script / end-script -> multi-line
<xnox> hallyn: if upstart spots any special / shell characters in the exec line it runs it through a shell.
<xnox> hallyn: i'd like to see it to believe it =) we have extensive tests to make sure e.g. "exec daemond --bar $ARGS" ends up called through a shell.
<xnox> to do all the shell variable expansions and magic.
<hallyn> xnox: right, i thought in particular "exec somethingorother || true" was what wasn't going to work.  happy to learn i'm wrong.  (had not tested)
<calebjosue> i was recommended to join this channel for purposes of knowing where to start with open source projects
<xnox> hallyn: hm.... I'm scratching my head now.
<xnox> slangasek: hallyn: This fails to start $ echo "pre-start exec false || true" > ~/.config/upstart/hallyn.conf; start hallyn
<xnox> but it should.....
<slangasek> xnox: eh? why should that successfully start instead of being a parse error?
<slangasek> xnox: 'pre-start exec false || true' says "exec() false with the arguments '||' and 'true'"
<slangasek> so technically not a parse error, but certainly returns non-zero and should fail
<xnox> slangasek: "Any special  characters, e.g. quotes or `$' specified will result in the entire command being passed to a shell for expansion." imho || is special
<slangasek> xnox: upstart does its own shell parsing of variables on the exec commandline; I don't see any reason '||' should be regarded as special
<xnox> hallyn: i am wrong, and cgmanager jobs need fixing.
<xnox> slangasek: about whoopsie id being different for non-root users -> Bug #1351519
<ubottu> bug 1351519 in whoopsie (Ubuntu) "/sys/class/dmi/id/product_uuid is not world readable" [Undecided,New] https://launchpad.net/bugs/1351519
<slangasek> xnox: ok; that's one reason why the generated id should be cached to the filesystem
<xnox> slangasek: and then make whoopsie file recoverable errors upon itself when generated id doesn't match cached one?! =)
<slangasek> ...
 * xnox is still friday trolling
<xnox> slangasek: e.g. tedg files recoverable errors against upstart, when something rather in url-dispatcher (tedg) can't read an sql database....
<slangasek> yes, one wonders at your choice of leisure activities
<xnox> slangasek: i'd rather tedg stop spaming us =)
<slangasek> xnox: I've filed a bug against url-dispatcher for this
<slangasek> bug #1350536
<ubottu> bug 1350536 in url-dispatcher (Ubuntu) "url-dispatcher report_recoverable_problem() handler triggers reports filed against upstart" [Undecided,New] https://launchpad.net/bugs/1350536
<xnox> slangasek: number? i'll fix it, cause i believe we shouldn't be generating errors on continues basis. All error reports must be exceptional, not a norm.
<slangasek> well, my bug report was about the errors being misfiled
<slangasek> which is separate from whether there's a bug in url-dispatcher /triggering/ the problem report
<hallyn> xnox: ok, thx, i'll push a fix (but not right now, laptop overheating)
<hallyn> xnox: slangasek: so how many upstartu sers do we think we have in debian?  should the upstart job fix for cgmanager go to debian or just to utopic?
<slangasek> is there some reason to *not* fix it in Debian? to do otherwise means you get to maintain a delta
<xnox> hallyn: all cgmanager updates should go to debain, and just sync to ubuntu.
<xnox> (e.g. that's how a lot of core packages are maintained e.g. grub2 is synced from debian, all uploads go into debian)
<hallyn> xnox: yeah pitti had made an ubuntu delta this morning, but i do think it can a go to debian
<hallyn> i.e. it was a delta that was introduced while 0.28-3 was going into debian, and it failed ot make it into that package (i didn't track them all sufficiently)
<hallyn> unfortunately going through debian adds a delay
<slangasek> hallyn: yes, but it's not something that should be a delta between the two distros over the long term
<hallyn> slangasek: no, not at all - it's just a delta bc i failed to put it into 0.28-3
<xnox> Folks please tell me:
<xnox> $ adb shell cat /sys/class/android_usb/android0/iSerial
<xnox> Need some sample data, to validate a hypothesis =)
<ScottK> zul: Please use build1 not ubuntu1 when you're doing no change rebuilds of packages that don't have an Ubuntu diff already.
<Noskcaj> Could someone please work on porting ubuntu-system-settings, powerd, and indicator-power to upower 0.99 soon?
<Noskcaj> Laney, Since you show up in the changelogs a bit do you know if anyone's working on ^
<slangasek> Noskcaj: why is porting required at all?  Shouldn't upower be a stable interface already?
<Noskcaj> slangasek, The new (late last year) release of upower drops the suspend API, the SONAME, and changes part of the dbus interface, as well as a few other things.
<slangasek> "drops the suspend API" in favor of what?
<Noskcaj> gnome, and soon xfce and kde, needs upower 0.99 to function
<Noskcaj> slangasek, systemd/logind
<slangasek> ok
<Noskcaj> bug 1330037
<ubottu> bug 1330037 in xfce4-settings (Ubuntu) "upower 0.99 transition" [Undecided,In progress] https://launchpad.net/bugs/1330037
<slangasek> and do you know that powerd actually requires porting for any of these changes, vs. a straight rebuild?
<slangasek> (ditto u-s-s and indicator-power)
<Noskcaj> powerd failed to build last i tried, i'll rebuild those three with their current versions today
<Noskcaj> (ditto u-s-s and indicator-power)
<Noskcaj> crap
<Noskcaj> https://launchpadlibrarian.net/177594528/buildlog_ubuntu-utopic-amd64.powerd_0.15%2B14.10.20140612-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
<slangasek> hmm, ok then
<slangasek> I'm guessing that for powerd porting you might want sforshee
<Noskcaj> powerd is still failing  porting you
<Noskcaj> https://launchpad.net/~noskcaj/+archive/ubuntu/upower/+build/6235759/+files/buildlog_ubuntu-utopic-amd64.powerd_0.16%2B14.10.20140707-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
<Noskcaj> Why does hexchat copy anything i select :(
<Noskcaj> indicator-power does build fine, but it probable needs some testing, as it does depend on upower
 * slangasek nods
<Noskcaj> u-s-s https://launchpad.net/~noskcaj/+archive/ubuntu/upower/+build/6235765/+files/buildlog_ubuntu-utopic-amd64.ubuntu-system-settings_0.3%2B14.10.20140801.2-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz
<slangasek> note that, due to the upcoming release-to-manufacturer milestone for Ubuntu Phone, it's likely to at least be a week before anyone is willing to work on this for utopic (basically because we aren't going to want to pull upower 0.99 into the RTM archive)
<Noskcaj> ok
<Noskcaj> pitti, Any progress on python-dbusmock upower?
<Noskcaj> And once this is done, we get the fun of bluez5
#ubuntu-devel 2014-08-03
<Kalinda> !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
<infinity> Kalinda: Some context on that would be nice?
<infinity> Excellent.
<slangasek> infinity: perhaps we should remove that bot command and redirect people to using the regression-update tag on bug reports
<ScottK> That trigger has come in handy in the past.  I don't recall it being abused before.
<ScottK> I wouldn't change it based on one time.
<michagogo> https://launchpad.net/ubuntu/+announcements seems to be outdated...
<_nedR> Hello i am trying to compile gnome-control-center for ubuntu precise  but ./configure keeps complaining that "Package requirements (gtk+-3.0 >= 3.3. 5 glib-2.0 >= 2.31.0  gthread-2.0 gio-2.0 gio-unix-2.0 gsettings-desktop-schemas >= 3.0.2 libnotify >= 0.7.3 gnome-desktop-3.0 fontconfig) were not met: No package 'gnome-desktop-3.0' found"
<_nedR> https://code.launchpad.net/ubuntu/precise/+source/gnome-control-center
<_nedR> I can't find gnome-desktop-3.0 package.. anyone know solution
<infinity> slangasek: The real-time nature of IRC is handy, if people happen to be around.  Doesn't mean people shouldn't ALSO tag bugs.  Anywhere that documents one should probably reference the other.
<juliank> Is there any chance to get some more device IDs added to libmtp in trusty? utopic also needs some updates first, though
<juliank> MTP is annoying.
<ScottK> juliank: Sure.  I think that's a reasonable thing to SRU.
<juliank> ScottK: Yeah, and because it's only data, so there should be no regressions at all.
<ScottK> Yes and support for new hardware is something we do try to support.
#ubuntu-devel 2015-07-27
<FAalbers2> Hello, How do I receive packages from Wily instead of Trusty ? I need newer version of openocd and Trusty is set to 0.7.0 instead of the latest 0.9.0
<rect> Hi all, I am interested in working on the ubuntu-multi-computer experience
<rect> It's 2015 and there is still unnecessary general friction when using more than one machine, in terms of synchronizing data and configuration
<rect> Right now my thought about how to do this is around establishing separation of "data" and "system/configuration",  and using declarative system configuration languages to compile provision systems
<FAalbers2> Hello, How do I receive packages from Wily instead of Trusty ? I need newer version of openocd and Trusty is set to 0.7.0 instead of the latest 0.9.0
<rect> I have a little writeup demonstrating a proof of concept of the first aspect here, which is the separation/divorce of the "storage" of data and the "application" of data
<rect> I would really appreciate some feedback on the concept!
<rect> http://nbviewer.ipython.org/github/andrewjchen/andrewathome/blob/master/andrew%40home.ipynb
<dholbach> good morning
<Laney> siretart: I'm going to do it so we can get some stuff migrated
<Laney> Guess we should transition off libav completely though?
<ricotz> Laney, yes, libav needs to go away
<Laney> ricotz: did Debian do it yet?
<Laney> is it API compatible?
<ricotz> Laney, https://release.debian.org/transitions/html/ffmpeg-libav.html
<ricotz> and it is compatible in most cases
<Laney> maybe someone could take the lead. ;)
<flexiondotorg> Laney, dholbach May I request a little bit of sponsoring please?
<flexiondotorg> I'd like the ubuntu-mate meta packages tasks updating please.
<flexiondotorg> Laney, dholbach And the following two package updates:
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1476616
<ubottu> Launchpad bug 1476616 in ubuntu-mate-settings (Ubuntu) " ubuntu-mate-settings 0.4.7 release [debdiff attached]" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1476611
<ubottu> Launchpad bug 1476611 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 0.4.11 new nelease [debdiff attached]" [Undecided,New]
<dholbach> flexiondotorg, sorry, I'm a bit busy right now
<flexiondotorg> dholbach, OK.
<Laney> flexiondotorg: Sponsoring this afternoon
<flexiondotorg> Laney, Cheers.
<Laney> infinity: http://paste.ubuntu.com/11947918/
<Laney> @pilot in
<Laney> hmm
<Laney> dholbach: know where the bot is? :)
<dholbach> Laney, hum
<dholbach> pinged folks in #ubuntu-irc
<Laney> cheers
<Laney> I thought it was IS for some reason
<dholbach> Laney, better now?
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> dholbach: feels good!
 * Laney does some warm up stretches
<dholbach> yeeehaw :)
<doko> tumbleweed, https://launchpadlibrarian.net/212703834/buildlog_ubuntu-wily-amd64.pyzmq_14.4.1-0ubuntu4_BUILDING.txt.gz
<doko> however I don't see any b-d for greenlet and cffi
<doko> jtaylor, ^^^
<doko> tumbleweed, did you file bug reports for the cffi backend split?
<bb11> hi! anyone can tell me which tool is used to build alternate installer / ubuntu-server images? apparently it's not debian-cd as this package is in universe and lacks ubuntu-specific settings
<tumbleweed> doko: not yet.
<infinity> bb11: It is a very old forked version of debian-cd
<infinity> bb11: https://code.launchpad.net/~ubuntu-cdimage/
<tumbleweed> doko: partly because I'm not ready for them yet. I just want them to start using pre-compiled 1.x style bindings
<doko> tumbleweed, sure, but you get build failures when the extension is missing for -dbg packages
<roaksoax> infinity: howdy! how can I check what bugs are yet to be verified for an SRU to go through?
<bb11> infinity: excellent, just what I needed :)
<bb11> thank you
<infinity> roaksoax: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<roaksoax> infinity: thanks!
<flexiondotorg> infinity, May I ask a favour? Please could you update the ubuntu-mate seeds/tasks?
<tumbleweed> doko: that's not what that bug is. That's a 3.5 porting bug I think
<tumbleweed> doko: pyzmq previously used cffi only on pypy (which requires no build-deps)
<tumbleweed> but it looks like it wants to use cffi on 3.5 too
<doko> ahh
<doko> anyway, have a fix
<tumbleweed> I don't know *why* it wants to use cffi on 3.5, that would require looking at the source :)
<infinity> flexiondotorg: Bit busy right now, but if you ask again in a few hours...
<flexiondotorg> infinity, OK
<flexiondotorg> Laney, Thanks for the sponsoring.
<dholbach> hey seb128, do you know why ubuntu-desktop-next depends on grub-efi-amd64-signed?
<seb128> dholbach, to be able to have signed boot
<seb128> dholbach, is that an issue?
<dholbach> seb128, I installed ubuntu-desktop-next this morning to play around with a unity8 session every now and then, it removed my grub-pc underneath me and broke boot with me just noticing it when I rebooted earlier
<seb128> urg
<seb128> dholbach, ubuntu-desktop-next is not supposed to be installed, it's the base for the snappy personal image
<dholbach> people are going to install it if it's in the archive :)
<seb128> you probably wanted unity8-desktop-session-mir
<seb128> dholbach, you can use the same logic for grub-efi-amd64-signed
<dholbach> unity8-desktop-session-mir installs less packages than ubuntu-desktop-next
<seb128> it's in the archive
<seb128> people are going to install it
<dholbach> mh
<ogra_> dholbach, size doesnt matter ... ask your GF !
<dholbach> ogra_, you're such a troll
<ogra_> lol
<Laney> O_O
<seb128> dholbach, anyway, unsure why grub-efi-amd64-signed is breaking boot
<Laney> how is -efi installed for desktop?
<dholbach> seb128, I'm not going to argue either way, I just didn't expect a *ubuntu*-desktop* package to lock me out of my laptop
<seb128> dholbach, yeah, me neither, sorry about that :-/
<dholbach> like... I could've installed kubuntu-desktop or lubuntu-desktop
<Laney> I guess conditionally by ubiquity maybe?
<dholbach> anyway... I just wanted to let you guys know
<seb128> dholbach, those are not -next :p
<seb128> dholbach, thanks, maybe worth opening a bug
<seb128> I don't know grub much
 * dholbach starts considering carreer outside IT
<seb128> what is grub-efi-amd64-signed made for?
<infinity> seb128: For secure boot systems.  Though, it should do no harm on any EFI system.
<seb128> what about non efi systems?
<infinity> For non-EFI, it's slightly less useful. :P
<seb128> is what happened to dholbach expected?
<infinity> Yes, it's why we don't ship grub-efi-amd64-signed (or bootloaders at all) in any desktop metapackage.
<gQuigs> I think this should be a quick fix (I have a patch posted), and will save us livecd space - https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1452472
<ubottu> Launchpad bug 1452472 in ubuntu-meta (Ubuntu Wily) "Drop gstreamer0.10 recommends in WW" [Undecided,New]
<infinity> Bootloaders are mutually exclusive, so installing one that doesn't work tends to remove the one that does.
 * gQuigs is also hoping to drop gstreamer0.10 to universe this cycle
<seb128> "fun"
<seb128> dholbach, sorry about that :-/
<infinity> seb128: I'm guessing someone added it to desktop-next to mirror how we build livefses with *-live, but that should really be either hacked in livecd-rootfs, or part of a "desktop-next-live" instead.
<seb128> infinity, you guess right
<dholbach> seb128, I'm glad I found the issue and hopefully not somebody else :)
<seb128> dholbach, I hope you manage to fix your machine
<dholbach> yeah, took an hour because I had to download a live cd, etc, but that's fine
<seb128> good
<Laney> gQuigs: We generate that package by modifying lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily desktop, not by editing it directly
<gQuigs> Laney: oh, I'll redo a patch/merge proposal on that
<Laney> gQuigs: Cheers. Seems like a good idea to me - didn't notice that we got there with dropping everything off the CD.
<Davidk> Hi there! My friend and I have decided to make our own remastered version of Ubuntu GNOME. However, we ran into some trouble and I was wondering if anyone could help. We unpacked the OS with squashfs, made our little modifications, then repacked it and burned the ISO onto a disk. However, when we try to start the OS, we get an error message
<Davidk> "(initramfs) Unable to find a medium containing a live file system"
<gQuigs> Laney: yup, it's just been pidgin for a while, posted a new patch to the bugf
<Laney> gQuigs: Can you link a bzr branch instead? It'll have better metadata that way
<gQuigs> Laney: propose branch for merging ?
<Laney> nah
<Laney> in general yes, but since I'm looking already, not necessary
<infinity> gQuigs: Ahh, nice catch.  Thanks for that.
<gQuigs> Laney: I think I did that right, https://code.launchpad.net/~bryanquigley/+junk/gst0.10_ubuntu
<Laney> gQuigs: Ta
<Laney> let's see what breaks...
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs Laney
<Davidk> Can anyone that's on possibly help me with an issue I'm having while trying to boot from a disk?
<Davidk> There were slight modifications made
<Davidk> Unpacked and packed via squashfs
<Davidk> It says that no live media can be found
<cyphermox> Davidk: did you rename the file in any way?
<cyphermox> Davidk: if you're booting from a hard disk you may also need to pass live-installer/net-image=/path/to/the/squashfs_file to tell the installer where to get the squashfs
<cyphermox> see http://www.michaelm.info/blog/?p=1378
<Davidk> cyphermox: no, no names were changed, as well as no paths
<Davidk> And the error is "(initramfs) Unable to find a medium containing a live file system"
<dragos> hello i just win an ubuntu competition
<dragos> i just remaster an ubuntu but when i click on live it asks for an username and an password. oh and btw i used remastersys for it
<cyphermox> Davidk: if you specify live-installer/net-image I bet it's going to work
<Davidk> cyphermox: okay, I will give it a shot
<dragos> help
<cyphermox> dragos: Davidk: for support, you should go to #ubuntu
<Davidk> cyphermox: Will do as well if your solution does not work. But thank you so much for your assistance
<cyphermox> no worries
<Davidk> And I did in Ubuntu GNOME, as this is GNOME
<Davidk> But they didn't have a solution unfortunately :/
<cyphermox> this is a typical issue on custom installs, the location of net-image needs to be specified if it's not on the cd
<Davidk> Ahhh I see. I'll do it and recompile, tho that may take a while. It's my friends' and my first attempt at this so, all help is really and truly appreciated
<cyphermox> you don't need to recompile anything for that
<cyphermox> as you boot, you should be able to either use F6 to open up the ocmmand-line and add it there, or edit the grub menu entry
<Davidk> Ooh that is perfect, thank you!
<cyphermox> (well, for testing that it fixes your problem, anyway... to make it permanent you'll need to add it to preseed)
<Davidk> Gotcha
<dragos> some dude banned me from #ubuntu for no reasion
<hjd> Hi, I've two questions; I'm curious why Ubuntu seem to use a different jpeg library than Debian (libjpeg8 vs libjpeg-turbo)? Secondly, even though it doesn't seem to be on the sync blacklist (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt), why does libjpeg9-dev seem to be missing and causing build problems for yoshimi (https://launchpadlibrarian.net/210424457/buildlog_ubuntu-wily-amd64.yoshimi_1.3.5.1-2_BUILDING.txt.gz)?
<doko> infinity, please could you merge dpkg?
<infinity> doko: Yes.
<doko> robert_ancell, please update glibmm2.4 in silo 16
<robert_ancell> doko, ok
<doko> robert_ancell, btw, are you connected for this stack with Debian?
<robert_ancell> ?
<doko> apparently no
<infinity> Or he doesn't speak doko English. ;)
<doko> I'm asking for the library renaming
<doko> infinity, when do you merge dpkg?
<infinity> robert_ancell: I think he meant "do you maintain any of these package in Debian too"?
<infinity> doko: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<infinity> doko: Merged, just testing a bit before I copy.
<robert_ancell> no, I don't maintain glibmm in Debian.
<doko> ta
<robert_ancell> doko, which library renaming are you referring to?
<doko> robert_ancell, could you rename the package according to the proposed naming scheme?
<doko> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
<doko> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791050
<ubottu> Debian bug 791050 in src:glibmm2.4 "glibmm2.4: library transition may be needed when GCC 5 is the default" [Important,Open]
<robert_ancell> doko, I can have a look at that
<doko> and so on for the whole stack. your tech lead requested it
<robert_ancell> doko, seb128 requested it?
<doko> yes
<doko> see backlog
<jderose> is anyone aware of what bug is causing the 14.04.3 64bit desktop daily ISOs to fail the automated testing? when I try running the pending ISO, the installer seems broken (wont launch at all)
<infinity> jderose: I'm not aware of such a bug, but I suppose I probably should be. :P
<infinity> jderose: Is it only an issue with automated/preseeded testing, or does it fail to be useful when manually booted/driven too?
<jderose> infinity: i was just curious if there was an LP bug out there already so i can poke around, try to help :)
<jderose> infinity: fails when trying to manually boot into it... although thus far i've only run it under kvm, so might not be an issue on real hardware
<infinity> jderose: Hrm.  Kay.  I'll grab a daily and see how it behaves for me after dinner.
<jderose> infinity: cool, let me know where i can help :)
<infinity> jderose: You can help by fixing all the bugs!
<doko> robert_ancell, copying is not good enough, we can't copy the binaries into -proposed using the same version number
<jderose> infinity: another possible hint... i noticed that ubuntu gnome 14.04.3 64bit daily has passed the automated testing. maybe it's just not running as many tests, but seemed a little suspicious
<jderose> infinity: just tried on physical hardware... broken there too
<infinity> jderose: Fun.  Alright.  Like I said, I'll look after dinner.
<infinity> jdstrand: Hrm.  So, what's the failure you're seeing?  I'm seeing no boot menu (weird), then straight to a blank desktop (probably a symptom of the first thing)
#ubuntu-devel 2015-07-28
<pitti> Good morning!
<pitti> Laney: in the light of bug 1478623 I guess it's prudent to set a force-badtest udisks2?
<ubottu> bug 1478623 in linux (Ubuntu) "Kernel oops - blk_update_request: I/O error when running udisks2 force_test_removal test" [Undecided,Confirmed] https://launchpad.net/bugs/1478623
<infinity> pitti: Probably, yeah.
<pitti> # kernel regression: https://launchpad.net/bugs/1478623
<ubottu> Launchpad bug 1478623 in linux (Ubuntu) "Kernel oops - blk_update_request: I/O error when running udisks2 force_test_removal test" [Undecided,Confirmed]
<pitti> force-badtest udisks2/2.1.6-1
<pitti> infinity: ^ do these two lines look correct for the hints file?
<pitti> (still not very acquainted with them, thus double-checking)
<infinity> pitti: Assuming the version is correct, sure.
<pitti> ack, committed
<pitti> that should unblock glib2.0
<infinity> And gtk.
<infinity> And a few other things.
<hyperair> why does a dropped wifi connection lead to chromium losing connection to its main instance and attempting to open a new one?
<dholbach> good morning
<flexiondotorg> dholbach, ubuntu-mate-artwork 0.4.11 is currently sitting in wily-proposed. Can you move it to release?
<dholbach> no
<dholbach> that's done automatically, using this process: https://wiki.ubuntu.com/ProposedMigration
<flexiondotorg> dholbach, OK. Thanks.
<Laney> pitti: hiya - I thought you might want to upload and just skip that one
<Laney> and WB!
<pitti> Laney: thanks!
<pitti> Laney: see scrollback, I pushed a hint for udisks2 now
<Laney> yes I see
<Laney> but perhaps it would be good to instead run the rest of the testsuite minus that one
<Laney> did you have a good holiday? :)
<pitti> Laney: yes, it was very recreative; although quite exhausting to climb the mountains with a trekking bike and lots of luggage :) (but we made it!)
<pitti> Laney: ah, skipping that test on i386, could do that too
<pitti> Laney: apart from the bugs you filed, how did the cloud stuff hold up?
<pitti> Laney: did you have to do a lot of manual juggling?
<Laney> pitti: Not so much - quite a few stuck instances but it wasn't generally apparent to me what had happened
<Laney> I didn't analyse all of the tmpfails though
<pitti> Laney: ah, I'll do that again this week; I got them to zero before I left
<pitti> indeed, there are a few now
<Laney> oh, even more since I looked (yesterday?)
<Laney> pitti: debci's test-deps diff was very useful in filing that udisks2 bug
<Laney> it basically fingered kernel or glib
<pitti> Laney: indeed, I really like that
<pitti> infinity: FYI, I fixed your linux hint (sorry for touching your file)
<ogra_> hmpf
<ogra_> infinity, didnt you say fan doesnt use dnsmasq anymore ? seems it still installs it
<ogra_> apw, ^^^
<ogra_> (it makes the snappy images fail if i dont add the user manually, but i want to be sure it is correct to add it)
<apw> ogra_, it should use dnsmasq-base not dnsmasq
<ogra_> ok, then the user creation is fine, thanks
 * ogra_ adds
<apw> ogra_, thanks
<doko> infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7730303
<doko> seb128, was the glibmm2.4 package converted with your script, or done by hand?
<seb128> doko, I'm poking around doing a script and used it for testing
<doko> seb128, missing conflicts and replaces
<seb128> doko, oh, good point, thanks ;-)
<doko> I'm collecting all explicit transitions at https://wiki.ubuntu.com/GCC5
<doko> seb128, and extra points for identifying that libsigc++ needs a bump too, and then adjusting the b-d in glibmm2.4 ;)
<cjwatson> doko: are you asking infinity that because of the bogus dep-wait?
<doko> cjwatson, yes
<cjwatson> doko: then I don't know why you're asking infinity, because that's a Launchpad team thing, and it'll be fixed in the next launchpad-buildd rollout
<cjwatson> (it's my fault)
<doko> ahh, ok
<doko> when is it scheduled?
<cjwatson> doko: not scheduled yet, hopefully soon.  but you have no reason to be waiting for it - if you know the deps are satisfied, just retry manually
<cjwatson> doko: I mean, the only difference in this case would be that the build would fail rather than dep-wait
<cjwatson> so you'd have to retry anyway
<doko> ok, something different too, investigating
<doko> The following packages have unmet dependencies:
<doko>  sbuild-build-depends-unity-scope-click-dummy : Depends: libunity-scopes-dev (>= 0.6.7~) but it is not going to be installed
<cjwatson> doko: yes, that means the build-dependency is uninstallable for some reason, apt doesn't say why
<cjwatson> (perhaps uninstallable in combination with other build-deps)
<cjwatson> Logan: apologies for the exceptionally cryptic failure from gem2deb.  The problem was that ruby2.2 was in universe; I've moved it to main, which should help.
<cjwatson> Logan: however, gem2deb is still going to run into several problems in Launchpad with support for the new build profiles syntax.  We should get these sorted out soonish ...
<doko> xnox, infinity: https://bugs.launchpad.net/bugs/1348954
<ubottu> Launchpad bug 1348954 in python3-stdlib-extensions (Ubuntu Trusty) "update Python3 for trusty" [Undecided,Confirmed]
<doko> the (apparently) only Python3 related change seems to be from https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1326707
<ubottu> Launchpad bug 1326707 in ubiquity (Ubuntu) "Ubiquity does't start, hangs in "/usr/lib/ubiquity/bin/ubiquity", line 426, in acquire_lock, test_debconf.stdout.readline()" [Critical,Fix released]
<doko> wondering if backporting this to trusty would help
<ogra_> cjwatson, do our non native armhf PPAs still use qemu-user-static ?
 * ogra_ tries to re-vivie rootstock for local image building and runs into reallyy weird dependency issues on armhf
<ogra_> *re-vive
<cjwatson> ogra_: Yes
<cjwatson> ogra_: Assuming you mean our virtualised armhf builders
<ogra_> yeah
<ogra_> hmm, then the issue must be on my side
<ogra_> (assuming someone would have noticed if they fail to bootstrap :) )
<cjwatson> Well, the chroots are only refreshed periodically.
<cjwatson> But livefs builds would catch a bootstrap failure.
<ogra_> yeah, and you your surely notice if python3 isnt installable :)
<ogra_> http://paste.ubuntu.com/11953230/
<ogra_> (happens with -updates in the sources.list as well)
<cjwatson> Hard to guess from that; you'll have to do the usual drilling down you need to do to get a sensible error out of apt.
<ogra_> oh, verbosity in debootstrap helps a little :)
<ogra_> I: Configuring ureadahead...
<ogra_> W: Failure while configuring base packages.  This will be re-attempted up to five times.
<ogra_> W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/python3_3.4.3-1_armhf.deb is at fault)
<ogra_> i guess thats it
<cjwatson> What does the log say about python3?
<ogra_> Selecting previously unselected package python3.
<ogra_> dpkg: regarding .../python3_3.4.3-1_armhf.deb containing python3, pre-dependency problem:
<ogra_>  python3 pre-depends on python3-minimal (= 3.4.3-1)
<ogra_>   python3-minimal is not installed.
<ogra_> hmm, wow ... running qemu-debootstrap manually doesnt expose that issue
<ogra_> oh, it does ... it was just slower
<cjwatson> ogra_: Can you pastebin the whole log?
<ogra_> http://paste.ubuntu.com/11953401/
<ogra_> (exited with ctrl-c )
<ogra_> host is trusty if that has any influence
<soee> guys in available drivers we have nvidia-346 but there is no such driver version on nvidia'a site: http://www.nvidia.com/object/unix.html any idea why ?
<cjwatson> ogra_: All the "package not in database" warnings are suggestive; that seems to indicate that setup_available isn't working for some reason, which would prevent debootstrap's Pre-Depends resolution from working
<ogra_> hmm, could that be realted to using wilys debootstrap on trusty (i wouldnt know why)
<cjwatson> ogra_: I wouldn't have thought so ... could you pastebin </path/to/chroot>/var/lib/dpkg/available ?
<ogra_> cjwatson, empty
<ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -lh test/var/lib/dpkg/available
<ogra_> -rw-r--r-- 1 root root 0 Jul 28 14:42 test/var/lib/dpkg/available
<ogra_> i used: sudo qemu-debootstrap --arch armhf vivid test http://localhost:9999/ubuntu-ports ... (happens also without package proxy) ... nothing fancy
<cjwatson> ogra_: I'll have a look locally
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1450980 also - I suspect this is something specific to the qemu path in some way
<ubottu> Launchpad bug 1450980 in debootstrap (Ubuntu) "Python 3.4.3 package fails to install with deboostrap on armhf" [High,Confirmed]
<ogra_> oooh, since may already !
<ogra_> thanks !
 * ogra_ adds --variant=minbase for now ... 
<ogra_> hmm
<ogra_> though ... why dont i just use an ubuntu-core tarball for the outer chroot
 * ogra_ will ponder over that a little :)
<ogra_> cjwatson, just to confirm, --variant=minbase helps indeed
<cjwatson> ogra_: Ah, I see the bug
<ogra_> yay
<cjwatson> ogra_: https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=e24e4b006736734e20cc66398099b94dd4e5cb90
<cjwatson> (tested, works)
<ogra_> whee !
<cjwatson> I've uploaded that to unstable, can sync it later
<ogra_> yeah, i dont mind to use minbase for the outer chroot (and the inner ones dont expose it interestingly .... probably because not --foreign)
<cjwatson> this bug is entirely about --foreign
<ogra_> yep
<ogra_> thanks for the quick fix !!
<cjwatson> np
<smoser> hey. anyone seen anything like this: http://paste.ubuntu.com/11953680/
<smoser> when i install (dpkg -i) a cloud-init deb, i get quite a long pause after
<smoser>  cloud-config.target is a disabled or a static unit, not starting it.
<smoser> the install of that took 30 seconds!
<smoser> the long time is on a wait for /var/lib/dpkg/info/cloud-init.postinst
<smoser> maybe this is what slangasek alluded to? i think my services are getting started or re-started on dpkg -i.
<smoser> probably something i've done wrong in my packaging..
<smoser> any cluees ?
<smoser> hey, wondering how someone would suggest fixing https://bugs.launchpad.net/curtin/+bug/1477795
<ubottu> Launchpad bug 1477795 in curtin "fix tox with dependency on python-parted" [Undecided,New]
<smoser> basically i want to run tox, but python-parted nto available in tox.
<smoser> er.. not available in pypi/
<doko> seb128, slangasek : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756
<ubottu> Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open]
<seb128> doko, thanks
<teward> has anyone seen firefox crashes in the latest kernel on 14.04?  Firefox crashes randomly since a couple updates ago, nothing conclusive in Firefox, but it seems i'm not the only one impacted...
<infinity> pitti: "fixed"?
<pitti> infinity: bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/
<infinity> ogra_: It doesn't use dnsmasq, it uses dnsmasq-base, very different.
<ogra_> infinity, yeah, i only needed to know if the user creation is needed, all fixed now
<infinity> pitti: Oh, no, it was force-skiptest intentionally to get linux itself in.
<infinity> pitti: But yeah, until we fix that broken apparmor test, it should *also* be badtest. :P
<pitti> infinity: doesn't badtest imply skiptest?
<infinity> pitti: badtest is for a specific package/version test.  skiptest is to skip *all* tests on a package/version's migration.
<infinity> pitti: linux wasn't the only test stopping linux from migrating.
<pitti> infinity: ah, ok
<jderose> infinity: today's 14.04.3 64bit desktop ISO is installing swimmingly... do i have you to thank for that? :)
<infinity> pitti: And the other failures are valid failures in their own right (ie: badtesting a test that is holding a package in proposed correctly is, well, bad)
<infinity> jderose: By "today's", do you mean .1?
<infinity> jderose: Cause I'd expect .2 to have regressed again, and if it hasn't, I'll be SUPER CONFUSED.
<jderose> infinity: er, well what ever "current" is pointing to, sha1sum 5f03d86340d83dce4418a12409051914b5c03ae0
<infinity> jderose: That's .1 indeed.
<infinity> jderose: So, yeah.  You won't be happy with the reason, though, since you were one of the people asking for a new python. :P
<jderose> infinity: what was the issue, btw?
<infinity> jderose: New python3.4 broke ubiquity.  That .1 build is a one-off with only python rolled back.
<jderose> gotcha, thanks
<infinity> Oh, but doko may have found a ubiquity cherry-pick to fix it.
<doko> infinity, see backlog, proposing a backport for ubiquity
<infinity> doko: I can test that a bit later.
<infinity> doko: Thanks!
<infinity> doko: The description (hand on PIPE to debconf-communicate) definitely looks like the regression I'm seeing on the ISOs, so this is promising.
<infinity> doko: I didn't think to go looking in bzr because I didn't expect 3.4.0 -> 3.4.3 to have this sort of behaviour change, though.
<infinity> doko: What are the odds of this negatively affecting other packages?
<doko> infinity, odds ... well, had the test rebuild of trusty main without seeing any issues
<doko> and I uploaded a new package to fix a regression in the tests, introduced by an openssl security update
<smoser> is it known that http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server does not seem to be refreshing
<smoser> ?
<smoser> footer shows:  Thursday, 09. July 2015 03:47 UTC
<rbasak> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html is the same
<rbasak> I was going to file an RT but haven't yet.
<smoser> rbasak, do you want to / could you do that ?
<rbasak> ack
<dobey> slangasek, infinity: either of you around and got a couple minutes to answer some packaging questions?
<infinity> dobey: Depends on the complexity of the question(s).
<dobey> infinity: so, we are writing some go code now, and we are making use of some tools, which we currently need to pull into our source tree, build locally, and run from there, to process coverage reports and such. i'm thinking it would be better to have these tools packaged in the archive, and we just build-dep on them.
<dobey> infinity: however, these tools have no upstream release tarballs as such, and are basically unversioned (outside of git commit hashes). so i'm wondering what the best practice would be to package such things as debs
<infinity> dobey: Cut an upstream tarball, call it version 0.$date, mention the commit hash you checked out in debian/changelog, and how the tarball is created in debian/README.source, bonus points for a get-orig-source target in debian/rules that does the work for you, so you don't have to do it by hand every time.
<dobey> hmm, ok. thanks
<infinity> dobey: And, for the love of FSM, exclude .git when building the tarball. ;)
<dobey> yeah. i wish git had an "export" command that worked like bzr does
<infinity> dobey: git-archive(1)
<infinity> Because using "export" like bzr, svn, and cvs would have been not hipster enough.
<infinity> dobey: Is this going to be one of those "build twice, once with coverage bigs enabled, once not, then test" cases?
<dobey> infinity: nah, go coverage seems to be smart enough to not need that at least
<infinity> dobey: If so, then you're also looking at, yes, making these build-deps and then, of course, the side-effect that you might need MIRs.
<infinity> dobey: If it can be done post-build without rebuilding, you could do it as dep-8 tests, which might be more pleasant.
<infinity> We allow dep-8 in main to depend on universe, since it's not about things being self-contained at build time anymore.
<dobey> well, we need coverage during the builds for the things using it, because CI train doesn't handle dep-8 for getting the coverage
<dobey> so yeah, we'll probably need some MIRs for stuff at some point
<infinity> dobey: Fair.  Well, packaged beats embedded in each source anyway, so you're on the path of lesser evil.
<dobey> yeah
<infinity> dobey: If upstream does have version numbers, of course, just not tarball releases, amend my 0.$date recommendation with $version.$date or whatever.
<infinity> dobey: Key being that you need $date there because lolgit.  Hashes don't sort. :)
<dobey> yeah. my experience with github though is that people don't tend to do version numbers, especially for things written with go
<dobey> one tends to be lucky if they even document licenseing and copyright info
<infinity> dobey: Yeah, my experience with the github world has been pretty rough.
<infinity> dobey: The licensing thing being my biggest complaint.  There seems to be this view that "it's on teh internets, so it's clearly all free, so who cares", and it's going to bite someone, really hard.  I'm just waiting for that car-sized other shoe to drop.
<dobey> yeah
<infinity> dobey: Pretty much all my other "github style development" complaints stem from the licensing thing, I suspect.  No one thinks it's a big deal to give you a binary without exact matching source, or embed random source without provenance, etc, etc, if they don't care that there might be a license preventing such silliness.
<dobey> yeah
<infinity> dobey: I'm not the GPL's biggest fan, but I will admit that it accidentally led to some very sane development practices as a nice side effect.
<infinity> Well, probably not accidentally.  I'm sure that was half the point, and "freedom" was the excuse.  Either way, it worked out for a decade or two.
<dobey> yeah, the "anything using this code, must be relaesed under the same license" license, is a good way to tell people that their code is under your license
<infinity> And now a whole new generation seems intent on learning all the same lessons again by making all the same mistakes again. :(
<dobey> yeah, this new found "lets deploy static binaries everywhere" thing is not likely to end nicely
<infinity> It works great for people who have the infrastructure in place to do it properly.
<infinity> Which is, basically, Google.  And Facebook.  And pretty much nobody else who thinks they're being clever by trying to do it the same way.
<dobey> yeah
<infinity> Google's infra is very much designed to deal with that in a sane way, though.  A line changes, the world rebuilds, re-tests, and redeploys.
<infinity> Which is a far cry from the "throw a blow in docker and ignore it" crowd.
<infinity> s/blow/blob/
<dobey> i'm sure they tend to have more vetting of licenses for "opern source" things they throw in their infrastructure
<dobey> versus the "ooh i found this code on github and didn't read anything and just threw it in docker" types
<infinity> They read licences very carefully, yes. :P
<infinity> So they can weed out ones that the don't love to bits (like AGPL).
<infinity> s/the /they /
<infinity> Cause it turns out that building your prorietary web empire on the AGPL might not be ideal.
<dobey> yeah
<dobey> i've dealt with agpl enough in my life already :)
<dobey> hrmm, is there a decent way to get the timestamp of the last commit in a remote repository with git?
<dobey> my search-fu isn't turning up any useful info so far
<infinity> git show | grep ^Date, but there must be something less icky.
<dobey> i guess i can't do "git log" on a remote repo though?
<infinity> dobey: Not sure why remote matters, I assume your first step is a shallow clone, so you have the bits locally to tarball from.
<jtaylor> looking through .git/FETCH_HEAD might work
<jtaylor> after a fetch
<jtaylor> if you have a specific branch in mind just FETCH_HEAD
<dobey> well i was trying to avoid cloning; git archive supports archiving from the remote it seems
<infinity> Ahh.
<dobey> i guess i might have to write a bit more shell to clone and then make the tarball though, so i can get the useful bits of info about the repo
<dobey> or just create a bzr import on lp, and then just use bzr to do it
<jtaylor> oh without a local clone
<jtaylor> if the repo is on github you could use svn ;)
<dobey> hmm, i guess that's true
<infinity> Just clone. :P
<infinity> It's not world-ending.
<infinity> dobey: --depth might help with bandwidth concerns.
<jtaylor> --mirror should avoid the local checkout if disk is the problem :)
<dobey> yeah, but i was just trying to be clever by comparing timestamps for creating new tarballs
<dobey> no, storage and bandwidth aren't a concern really; just trying for clever optimizations :)
<infinity> dobey: Doesn't look like there's a way to view remote history (without a web viewer that does it for you or some such)
<dobey> yeah, that's what i'm finding too
<infinity> dobey: So your best speed optimisation would be clone --depth=1 --bare, and then archive from there.
<infinity> dobey: Or skip --bare and archive, and just let it do the HEAD checkout and run tar yourself.
<infinity> Gets you the same result.
<dobey> i guess i'll have to clone. idea was to make the tarball timestamp match the last commit, rather than just time(NULL)
<dobey> well, and to implement the watch rule to check for a new version
<infinity> $ date +%s -d "$(git show | grep ^Date | sed -e 's/^Date: *//' -e 's/ *+.*//')"
<infinity> 1432924833
<infinity> I hate myself a little bit for that.
<jtaylor> isn't there some pretty command for timestamp?
<dobey> anyway, gotta run now. i'll look at building a couple packages later
<dobey> haha
<dobey> git log -1 --prety=format:%cd ?
<jtaylor> %at: author date, UNIX timestamp
<infinity> ct
<infinity> git log -1 --date=short --pretty=format:%cd
<infinity> That comes out almost usable.
<dobey> but nothing to give 20150725103456 style
<infinity> Anyhow, too much time.
<infinity> .. spent on this.
<dobey> yeah, time for me to go anyway.
<dobey> later :)
<dobey> thanks again infinity
#ubuntu-devel 2015-07-29
<pitti> Good morning
<pitti> stgraber: did you see that LXC's autopkgtest started failing? new kernel or so? (Operation not permitted - overlayfs: error mounting /home/lxcunpriv/.local/share/lxc/c1/rootfs)
<infinity> pitti: That's a kernel bug, fixed in proposed.
<pitti> ah! /me re-runs the test thene
<pitti> yesterday it was still failing
<pitti> ah good, http://autopkgtest.ubuntu.com/packages/l/lxc/wily/i386/ ran with -3.3 and succeeds
<infinity> pitti: Any idea when mvo usually gets in?
<pitti> infinity: he used to start early too (around nowish), but TBH I haven't tracked him recently
<infinity> pitti: I thought you Germans all knew each other. :P
<pitti> there's only some 80 million of us, how could we not :)
<infinity> Exactly.
<infinity> pitti: Hey look, lxc passed.  Yay.
<pitti> \o/
<infinity> stgraber: Ignore pitti, all resolved with the new kernel.
<pitti> infinity: since my conversation with apw yesterday I have a WI to make LXC triggered by new kernels
<pitti> now I know where that came from :)
<infinity> Now I just need an apt wizard to sort out https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1479207
<ubottu> Launchpad bug 1479207 in apt (Ubuntu Trusty) "Never-MarkAuto-Sections not working correctly" [Critical,New]
<infinity> pitti: That could be solved by me getting around to that dpkg-source patch (oops), and us adding the kernel to lxc's test deps, I suppose.
<infinity> pitti: It's a slight lie, but it would do the trick without extra string and glue.
<pitti> yeah, that would be more elegant
<pitti> it would also greatly help the DKMS case
<infinity> pitti: Yeah, DKMS is a special beast.  Since I consider it a critical bug if a dkms *binary* package depends on kernel headers, but having those deps in the test deps would be fine.
<infinity> Which reminds me, I need to fix an SRU to remove a header dep that accidentally got added.  Whee.
<infinity> pitti: Do test deps use dpkg-style [arch] parsing?
<infinity> pitti: So I can have foo [amd64], bar [powerpc]?
<pitti> yes
<infinity> Excellent.
 * infinity goes to fix blktap-dkms with some violence.
<pitti> anything that libdpkg-perl can parse/resolve
<pitti> i. e. arches, multi-arch tags, and since recently also build profiles
<infinity> Not sure build-profiles make sense for autopkgtest deps, but yay anyway.
<pitti> for their build deps
<pitti> debian bug 787093
<ubottu> Debian bug 787093 in autopkgtest "autopkgtest: dpkg-deb chokes with build profiles in Build-Depends:" [Normal,Fixed] http://bugs.debian.org/787093
<infinity> Err, wat?
<infinity> pitti: Where does http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-blktap-dkms/lastBuild/ARCH=amd64,label=adt/ come from?
<infinity> pitti: The package itself doesn't have a debian/tests
<infinity> pitti: Manually created job, I guess?  That would explain why your new infra didn't run it, only the old one did.
<pitti> infinity: autodep8 rather, I figure
<pitti> infinity: we test perl, ruby, and dkms packages with a synthesized debian/tests/ from autodep8
<pitti> infinity: but indeed the old infra didn't auto-create these either, hmm; let me look
<pitti> infinity: ah, it did, sorry
<pitti> there's a special hack in adt-britney for DKMS
<pitti> right, that needs to be taught to britney
<pitti> (I have a work item for that)
<infinity> pitti: It's not a very special hack, that's literally the only dkms package that ran a test on the last kernel upload. :P
<pitti> yeah, it has never been working very well :)
<infinity> pitti: More bizarely, your new infra ran a *different* test that the old one didn't...
<pitti> open-iscsi?
<infinity> pitti: See excuses for linux.  Old infra: blktap/linux/glibc, New infra: open-iscsi/linux/glibc
<infinity> pitti: Yeah.  Wut? :)
<pitti> infinity: yeah, it seems britney's own reverse dependency map catches more things
<infinity> Ahh.
<infinity> Well, if it's universally catching more, that sounds good to me.
<pitti> e. g. alternatives
<pitti> just not sure why open-iscsi is being triggered in particular
<pitti> oh, the udeb perhaps?
<infinity> Could be.
<infinity> britney likes udebs, but most home-grown revdep parsers would ignore debian-installer/* because oops.
<infinity> pitti: Hrm.  autopkgtest results in trusty are getting dangerously close to useful.
<pitti> eek, how can we fix that? :-)
<infinity> pitti: Probably need to sit down and comb through current failures and smear some blame around between packages, tests, and infrastructure.
<infinity> pitti: Or, as you're imlpying, just make everything fail again. :P
<infinity> checking for x86_64-linux-gnu-gcc... no
<infinity> pitti: Do the debci trusty images not have build-essential?
<infinity> pitti: Would explain why libreoffice works in the old infra and not your shiny new one.
<pitti> infinity: ah, they indeed don't; that was a custom hack I added to the jenkins job
 * pitti adds WI
<pitti> infinity: thanks for pointing out
<dholbach> good morning
<infinity> pitti: You ate mvo, didn't you?  That's why you weren't willing to commit to his whereabouts.
<pitti> *munch* *munch*
<sidi> Should -dev packages for libraries on Debian/Ubuntu contain the .so? If so, what should the original lib package contain?
<ogra_> infinity, it is because telegram is the new email ... he only sent his "where is michael" to the team via telegram ;)
<ogra_> (he it out for two weeks)
<ogra_> *is
<pitti> IMs are not a replacement for email :)
<ogra_> pitti, and hangouts are not a replacement for IRC :P
<pitti> correct :)
<ogra_> (sadly not everyone thinks so )
<infinity> ogra_: Two weeks?  Erk.  That's... Not going to end well for my point release.
 * ogra_ checks again before telling lies
<ogra_> yeah, back on monday 10th ... from US TZ
<ogra_> (at a sprint then)
<infinity> Whee.
<pitti> rbasak: do you know, is there a PPA for juju 1.23 with systemd support?
 * pitti would like to use juju-local again
<rbasak> pitti: https://launchpad.net/~juju/+archive/stable
<rbasak> pitti: 1.24.3 is there and has systemd support.
<pitti> ah, nice!
<pitti> OOI, what's holding it back?
<pitti> i. e. should it not be installed yet because of known regressions or so?
<rbasak> There are some reported regressions that they haven't confirmed yet, but I think they only affect big production use
<rbasak> I'm pushing to get to the point where they don't release upstream unless they consider it OK to upload to Ubuntu too (including Trusty) but they're not quite at this stage yet.
<rbasak> So right now they release with a "please don't upload to Ubuntu" caveat, which isn't great.
<pitti> ok; I don't use juju for anything on my laptop (only from wendigo for devops), so there isn't that much to break for me :)
<rbasak> AIUI, for juju-local then 1.24.3 is fine.
<pitti> rbasak: I'll try that, thanks!
<seb128> doko, hey
<seb128> doko, in which case do we need to update build-depends for the gcc transition?
<seb128> do we need to make sure rename packages build with gcc5?
<seb128> through some b-d
<doko> no, assume that it's the default
<seb128> k
<doko> probably for Debian, but buildd admins assured me they would update the chroots when I pull the trigger
<seb128> works for me, thanks
<doko> the other thing which might be nice would be updated b-d's for c++ b-d's
<pitti> Laney: FYI, I fixed packages.json, e. g. http://autopkgtest.ubuntu.com/data/status/wily/i386/packages.json
<pitti> Laney: useful for checking for tmpfail, etc.
<seb128> doko, I uploaded a first batch to 039 from the script, going for lunch now and going to continue after, I would appreciate if you had a look just in case there is something wrong or that you would recommend changing
<doko> seb128, k, maybe a review before upload would be nice?
<seb128> doko, I did review those manually before upload
<seb128> they look fine to me, but just in case I'm forgetting something
<doko> do you rename -dbg packages too?
<seb128> good point, no I didn't, should we?
<seb128> bbiab
<doko> seb128,  gflags (2.1.2-2ubuntu1~gcc5.1ubuntu1)  -> .1.2-2ubuntu1
<pitti> Laney: and Brandon is working on https://wiki.debian.org/debci/mockups?action=AttachFile&do=view&target=tmpfail_list.png which is much nicer :)
<doko> seb128, google-glog (0.3.4-0ubuntu2~gcc5) -> 0.3.4-0ubuntu2
<doko> using the ~gcc5 version for no-change uploads only
<doko> seb128, pangomm just fails because glibmm needs a rebuild for the renamed libsigc++
<doko> and I should get doxygen working again ...
<Laney> pitti: nice, so e.g. "GET http://autopkgtest.ubuntu.com/data/status/wily/i386/packages.json | jq '.[] | select (.status == "tmpfail") | .package'" works
<pitti> Laney: oh, I wasn't aware of jq, thanks
<Laney> it's useful as a pretty printer too, if you call it as 'jq .'
<pitti> rbasak: hm, juju boostrap works, but juju deploy cs:rabbitmq-server creates a STOPPED juju-trusty-lxc-template which never starts, and the new "1" instance stays pending  forever
<pitti> juju-agent-martin-local.service and juju-db-martin-local.service are running, though
<pitti> I see a neverending stream of mongod authenticate requests (no errors, though)
<rbasak> pitti: sorry, that's beyond me now (apart from seeting if I can reproduce and filing a bug). Try in #juju maybe?
<pitti> rbasak: ack, will do
<pitti> I'll give it some more time before that
<rbasak> pitti: 1.24.4 is in rc at the moment I think. Might be worth trying that (though I was under the impression that changes did not affect juju-local). Note though that you have to tweak your configuration to run an rc though.
<pitti> rbasak: ah, there's actually some progress; I guess bootstrapping the first container just took a while
<rbasak> pitti: https://bugs.launchpad.net/juju-core/+bug/1478232 maybe? There has been talk about performance issues.
<ubottu> Launchpad bug 1478232 in juju-core 1.24 "juju 1.24 poor performance" [High,Triaged]
<pitti> doesn't sound like that, the martin-local-1 machine just never comes up (lxc-attaching, it doesn't ifup eth0)
<seb128> doko, thanks for the version hint, wasn't glib rebuilt in silo 016?
<doko> seb128, yes, but using the not renamed libsigc++
<seb128> doko, I see, fixing it
<tseliot> Laney: hi, do you mind if I assign my new merge request to you? It's about this previous merge request, only this time I wrote it, and it doesn't block: https://code.launchpad.net/~timchen119/unity-settings-daemon/unity-settings-daemon.1471708.trusty/+merge/264163
<tseliot> (the new merge request is not there yet)
<seb128> doko, slangasek, why is libpinyin in the 016 ppa while it's not on https://people.debian.org/~doko/logs/gcc5-20150701/ and doesn't have c++ symbols?
<doko> seb128, slangasek uploaded everything with a dependency on libstdc++6 which is on the touch image. but you see that it kept the dependency on libstdc++6 (>= 4.1.1), so no new symbols are introduced
<seb128> doko, k
<doko> tjaalton, mesa ping ...
<doko> libxatracker2 mesa-vdpau-drivers libgl1-mesa-dri needs renaming, however I know that we have a lot of dependencies on ibgl1-mesa-dri
<caribou> Q: when doing an SRU for a debian native package, should we use quilt to change the package or modify the source directly ?
<caribou> (ifenslave in that context)
<rbasak> I would modify the source directly
<rbasak> quilt would be nice but if there's no mechanism in place for that already then it seems quite invasive to put that in (whether for an SRU or just an Ubuntu delta in the dev release). But I'm not on the SRU team.
<smoser> pitti, (or since rbasak last talked, he probably knows anyway)
<smoser> in dep-8, can i do an upgrade test at all?
<smoser>  install version A
<smoser>  do something
<smoser>  upgrade
<smoser>  do something else (verify that my data is still present)
<pitti> smoser: sure, your test can call apt-get or dpkg, whatever it likes
<Laney> tseliot: request a review from me in addition to the default team please
<pitti> smoser: the main restriction is that you need to be able to get the old version A from somewhere
<tseliot> Laney: ok, thanks
<smoser> pitti, right. so in the case where it is in -updates , and my new upload is in somewhere else, thats easy enough
<doko> seb128, could you keep https://wiki.ubuntu.com/GCC5 up to date?
<seb128> doko, yeah, I planned to do that at the end at the afternoon to avoid editing it every 5 minutes
<doko> ok
<doko> working on ptlib
<tjaalton> doko: renaming why?
<doko> tjaalton, nm, just needs a rebuild for the renamed libllvm2.6
<tjaalton> ah
<pitti> smoser: could you please boot wolfe-08 again? I foolishly powered this off, I thought I was still in a container on it
<smoser> silly pitti
<smoser> :)
<smoser> will do
<pitti> smoser: thanks!
<smoser> system up, pitti
<smoser> ok, now up.
<pitti> smoser: I'm back in, thanks
<tseliot> Laney: ok, I've just made two merge requests: https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-trusty/+merge/266249 and https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-wily/+merge/266248
<Laney> tseliot: ok, thanks, will try to look soon
<tseliot> Laney: thanks
<Laney> tseliot: upstream bug still welcomed btw :)
<doko> working on protobuf
<tseliot> Laney: I mentioned that in the commit: https://bugs.launchpad.net/oem-priority/+bug/1471708
<ubottu> Launchpad bug 1471708 in unity-settings-daemon (Ubuntu) "SRU: For skylake system, u-s-d cause a black screen when resume from S3 via Lid Close" [High,In progress]
<Laney> tseliot: I mean at intel(?)
<tseliot> Laney: oh, that. I'll file one. These changes really improve my touch screen mapping code from last year, so it will be good to have them regardless of when/whether the upstream bug is fixed
<Laney> tseliot: Sure, just would be good to get to a place where it always works ;)
<Laney> anyway, noted down to review
<tseliot> Laney: I obviously agree ;)
<pitti> seb128, doko: what can I do tomorrow morning to help with the gcc-5 bits?
<pitti> seb128, doko: is that "fix FTBFSes in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages"? or is there a different TODO list/tracker?
<seb128> doko, pitti, I'm done for today/updating the wiki, those are the packages that remain on the list doko gave me yesterday
<seb128> http://paste.ubuntu.com/11960809/
<seb128> pitti, ^ you might look at some of those, doing renames
<seb128> see https://wiki.ubuntu.com/GCC5
<doko> pitti, 16 is waiting on tvoss
<seb128> we use silo 039 for those renames to not make 016 not installable
<pitti> ah, ok
<doko> pitti, you could create transition trackers for the packages in the wiki page
<pitti> infinity: trusty testbeds now install b-e, libo is now back to PASS
<pitti> doko: ah, I've never done that, (1) do we have docs for that, and (2) is that needed for small transitions?
<doko> Laney, ^^^
<pitti> ok, I need to leave for basketball, I'll talk to you tomorrow morning I guess
<doko> pitti, or else seb128 could send you his script, and you continue with the renaming
<seb128> doko, there is only some ~10 remaining and they are a bit less standard/more complicate packages mostly, which might not work well with the script
<doko> ok
<seb128> I think we can do those manually
<pitti> so would looking at the FTBFS in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages be a good start?
<doko> pitti, then there is https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
<doko> ordered by libstdc++ dependency lvel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756
<ubottu> Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open]
<pitti> ok, I'll look at what seb128 did in 039 and look at FTBFS, or just wait until you get online tomorrow morning
 * pitti gotta run, thanks!
<seb128> pitti, have fun!
<seb128> doko, pitti, I've updated https://wiki.ubuntu.com/GCC5 with the renames I did today
<mitya57> jtaylor, can you please look at ipython autopkgtests regression? https://jenkins.qa.ubuntu.com/job/wily-adt-ipython/lastBuild/ARCH=amd64,label=adt/consoleFull
<mitya57> it breaks some stuff like sphinx or pygments from migrating
<doko> seb128, did you reupload pcre3?
<doko> ahh, no
<jtaylor> mitya57: looks like a regression in python3.5 itself
<jtaylor> hitting a notimplemented error during a normal import
<jtaylor> I'll try upstream ipython with 3.5 later
<seb128> doko, oh, sorry, I did but I got a rejected email apparently, it was on your list and I didn't notice you had it uploaded
<mitya57> jtaylor, thanks
<doko> xnox, T - 2
<Laney> doko: make the script output them or something
<Laney> it doesn't seem feasible to create this by hand
<ScottK> Laney: For some reason I seem to still be getting the DMB meeting wiki page diffs even though I'm not personally subscribed to the page.  I guess there's something else I forgot to unsubscribe from.  Do you know what that might be?
<chiluk> hey infinity, slangasek, https://bugs.launchpad.net/ubuntu/+source/targetcli/+bug/1479424  ... I'm not sure what happens when it's pretty obvious a package isn't installable.  What do you guys recommend we do?  I'm thinking remove packages from archives altogether.
<ubottu> Launchpad bug 1479424 in targetcli (Ubuntu) "Failure to install lio-utils on fresh cloud-image" [Undecided,New]
<ScottK> Laney: nvm.  I think I figured it out.
<infinity> chiluk: When packages are buggy, the usual thing to do is to fix them.
<infinity> chiluk: And given that your test case is precise, removal isn't an option anyway.
<ari-tczew> how to force package to built with --std=c++11 ?
<chiluk> yeah that's what I figured.
<chiluk> infinity..  it looks like lio-utils has been deprecated upstream.. and afaik that's due to changes in newer kernels.
<chiluk> which is part of the reason lio-utils is failing to be installable.
<infinity> ari-tczew: CXXFLAGS += --std=c++11 ?
<infinity> ari-tczew: Or the moral equivalent thereof for whatever build system.
<chiluk> infinity, also lio-utils doesn't show up in popcon at all..
<infinity> chiluk: popcon is a pretty bad way to determine if something should be removed from the archive.
<chiluk> infinity, this package never should have gotten passed any kind of testing.
<infinity> chiluk: Dead upstream is a better way, for sure.
<infinity> chiluk: Also, "removed from Debian" is compelling.  You should have led with that.
<chiluk> yeah it's deprecated in favor of targetcli which is deprecated in favor of tgt... iscsi is a steaming pile..
<chiluk> infinity, I hadn't checked.
<infinity> chiluk: targetcli, however, is still in Debian, so I question your linking the two together.
<chiluk> targetcli in ubuntu has a dependency on lio-utils.
<ari-tczew> infinity: I guess "export CXXFLAGS += --std=c++11" should works in debian/rules, right?
<ari-tczew> or better withour export
<infinity> chiluk: I assume that dependency you speak of isn't there in wily.
<chiluk> infinit so maybe that dependency shouldn't be there.
<ari-tczew> without*
<infinity> chiluk: It's not 2012 anymore.
<chiluk> infinity, are you saying you don't like supporting things for 5 years?
<infinity> chiluk: I'm saying that we're not *removing* it from any stable releases, so come up with a better solution for precise.
<infinity> chiluk: For wily, lio-utils is dropped from Debian, and we should do the same.  And targetcli doesn't depend on it.
<chiluk> ok that's useful info.
<chiluk> I'm still recommending that users of targetcli or lio-utils move to tgt.
<chiluk> and i think I will leave it at that.
<chiluk> since removal is not an option.. and it was likely deprecated because of incompatibility with the new 3.2 kernel!
<infinity> Err.  It was already removed from wily.
<infinity> Even better.
<chiluk> well great.
<chiluk> thanks infinity
<infinity> chiluk: Anyhow, you can have your precise tasks, if someone decides to fix it properly in precise. :P
<doko> Laney, seb is the script writer, but I assume we want at least some for the big transitions
<doko> robert_ancell, about the gnome mm stack, please see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages
<doko> could you have a look at pangomm? if you decide to update to new upstream version, please do it in this ppa, and not anymore in the archive
<doko> ohh, and the ppa has a debpendency on the landing16 ppa
<doko> infinity, do you have an update about the ubiquity issue?
<robert_ancell> doko, ok
<infinity> doko: The cherry-pick fixed it, yes.  Should have followed up to the python bug.
<infinity> doko: Doing that now.
<robert_ancell> doko, I'm fixing atkmm too
<robert_ancell> doko, I notice scim half built - it seems to be a temporary issue with the GTK+ packages. Any reason not to retry the failed builds?
<doko> robert_ancell, mir needs a rebuild first, working on it
<mwhudson> is logging in to the wiki expected to work currently?
<RAOF_hates_all_c> Hm. All my Ubuntu entries disappeared from my grub menu, and now Windows is holding my laptop hostage.
<RAOF_hates_all_c> It is literally impossible for me exit Windows without disassembling my laptop and yanking the battery.
<infinity> RAOF_hates_all_c: That seems suboptimal.
<infinity> RAOF_hates_all_c: Can't boot to USB?
<RAOF_hates_all_c> Can't reboot.
<infinity> RAOF_hates_all_c: ...?
<RAOF_hates_all_c> Windows isn't speaking to either the keyboard or the touchpad, and the power button causes it to suspend.
<infinity> RAOF_hates_all_c: Even holding the power button for $absurdly_long_time?
<RAOF_hates_all_c> *Before* the 5 second "oh, you really really want to turn off" threshold of the firmware kicks in.
<infinity> RAOF_hates_all_c: Plug in a USB keyboard and see if Windows likes that one better than the builtin PS/2 device?
<infinity> (also, wow, good job on getting windows to hate your builtin keyboard)
#ubuntu-devel 2015-07-30
<RAOF_hates_all_c> Yeah! It was during an automatic upgrade, too.
<RAOF_hates_all_c> So everything was working, and then the keyboard and mouse stopped responding to anything.
<infinity> RAOF_hates_all_c: Maybe it upgraded the PS/2 driver and blew up on rescan.
<infinity> RAOF_hates_all_c: If so, the USB keyboard trick might work.
<RAOF_hates_all_c> That's my current theory, yes.
<infinity> *handwavy*
<RAOF_hates_all_c> Alternatively, I can wait for it to drop from suspend to hibernate and then boot from USB.
<RAOF_hates_all_c> But maybe I can be bothered to find a USB keyboard...
<RAOF_hates_all_c> So much effort, though!
<RAOF_hates_all_c> Much more enjoyable to bitch on IRC using $BACKUP_LAPTOP
<infinity> Hah.
<infinity> USB mouse might be easier? :P
<RAOF_hates_all_c> I'm not sure I could find one of those, actually.
<mwhudson> rdp?
<infinity> Either one should get you to a reboot button.
<sarnold> any chance you've got an sshd running on it?
<infinity> mwhudson: rdp implies either (a) it's always open (I'd assume not) or (b) he has input devices to turn it on.
<lifeless> RAOF_hates_all_c: what if you toggle it on and while its resuming you'r still doing the 5 second hold of death ?
<mwhudson> true
<infinity> RAOF_hates_all_c: Alternately, maybe you hit a magic Fn+F combo that swapped internal/external input (or, the driver "toggled" that for you), and hammering Fn and all your function keys will fix it? :)
<RAOF_hates_all_c> lifeless wins!
<lifeless> \o/
<lifeless> thank you, thank you, I take requests.
<infinity> RAOF_hates_all_c: Next step: uninstall Windows.
<lifeless> mwhudson: wiki login in suspiciously slow but worked
<lifeless> mwhudson: just had to be awesomely patient, if you mean w.u.c
<mwhudson> lifeless: yeah i think something got restarted, i'm in now
<RAOF_hates_all_c> Woot!
<RAOF_hates_all_c> The laptop boots *much* better when a kernel is installed.
<infinity> RAOF_hates_all_c: Kernels are overrated.
<pitti> Good morning
<dholbach> good morning
<pitti> seb128: so it seems you already fixed all the FTBFS in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages ?
<LocutusOfBorg1> hi folks, what happened to the Debian automatic import?
<LocutusOfBorg1> I see many packages that hasn't been syncd
<infinity> LocutusOfBorg1: cjwatson noticed it was a bit broken last night before he went to bed, I imagine he'll poke at it this morning to see why.
<infinity> pitti: Can I get you to look at the apt SRU in trusty?  It's point-release crticial.
<pitti> infinity: yup
<infinity> pitti: Explanation of the patch can be gotten from reading between the lines in the referenced Debian bug.  Ish.
<LocutusOfBorg1> infinity, thanks, I saw the breakage right now
<infinity> pitti: It's tested here and works.
<LocutusOfBorg1> http://packages.debian.org/changelogs/pool/main/p/python-3to2/python-3to2_1.1.1-1/changelog.txt: HTTP Error 404: Not Found
<LocutusOfBorg1> http://metadata.ftp-master.debian.org/changelogs/main/p/python-3to2/python-3to2_1.1.1-1_changelog
<LocutusOfBorg1> this seems to be the right link now
<pitti> infinity: ah, not fixed for wily yet either?
<infinity> pitti: No, I'll do wily, vivid (and I suspect precise too, haven't tested there yet) Soon(tm), but the clock's ticking on 14.04.3, so that gets love first.
<pitti> infinity: ack
<infinity> pitti: I think that single line has been changed in apt about 5 times in the last 6 months.  I suspect it's going to wear out soon.
<LocutusOfBorg1> can anybody please kick of python3-3to2 from the archive?
<pitti> seb128, doko: So, I'll start weeding through https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org until/unless you give me something more urgent?
<LocutusOfBorg1> the new binary in python-3to2 has that binary now
<infinity> pitti: Hopefully (until David decides to rewrite the whole autoremove feature), this is the last fix. :P
<pitti> infinity: famous last words
<infinity> pitti: Yeah, seriously.
<infinity> pitti: I'm beginning to wish I hadn't reported the first bug that started this all.
<infinity> pitti: Once this builds, I get to apply still more hacks to livecd-rootfs in my PPA, test build all the point release livefses AGAIN, and then, I think, we're set.  With a week to spare.
<infinity> Fingers crossed.
<seb128> pitti, wfm
<pitti> wgrant: argh, I screwed up!
<pitti> wgrant: seems my britney changes have some bug that caused a lot of stuff on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html to migrate
<pitti> wgrant: but have test failures
<pitti> wgrant: I'll start investigating, but it might be that we need some Launchpad magic for reverting this :/
<wgrant> pitti: When did this happen?
<wgrant> Do you have an example package?
<pitti> wgrant: some 20 mins ago
<pitti> wgrant: the first one on the page, for example
<pitti> for most it's probably okay, as we have a couple of broken tests
<pitti> wgrant: I'll go through the "valid candidate"s now and compile a list of stuff that we need to revert/handle
<wgrant> cjwatson: ^^ fyi
<wgrant> pitti: This shouldn't require any particular LP magic, though.
<wgrant> pitti: Reverting packages is possible, I think there might even be a script to do it.
<pitti> wgrant: yeah, hopefully; just a warning
<wgrant> It is ugly, though.
<infinity> It's possible, but please don't unless absolutely necessary.
<wgrant> It would be easier if they weren't published.
<wgrant> Which they're not, it seems
<infinity> Since you need to check rdeps, make sure you're not making life worse, plus you've left users who upgraded high and dry.
<wgrant> So we could stop the publisher and delete them before they supersede the old ones, if we decide to do that in the next minute or so
<pitti> e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pycurl
<pitti> this is again a case where the migration was premature, but harmless
<infinity> pitti: Go through the list of premature promotions and make some value judgements.
<pitti> infinity: it doesn't migrate uninstallable/FTBFS stuff, just test regressions, so it shoudln't cause new uninstallability
<infinity> pitti: In most cases, I think we'll probably just want to live with it.
<pitti> infinity: yep, that's what I'm doing now
<pitti> right
<infinity> pitti: No, I meant that reverting could cause breakage. :P
<pitti> in particular, python3-defaults has not been promoted yet (adding 3.5 as supported version)
<infinity> pitti: Promotion should be fine, except for the part where we ignored tests.  But, hey, we used to do that for every package.
<infinity> pitti: I assume you've reverted or fixed your britney oops?
<pitti> infinity: I reverted britney, yes
<lifeless> pitti: that sounds *so* wrong
<pitti> I don't yet have any idea why this happened, and I want to go through the current promotions before looking at that
<infinity> .me nods.
 * infinity too.
<pitti> sorry about the mess -- here's to writing tests that don't prevent breakage :/
 * lifeless raises the glass
<pitti> *clink*
<infinity> pitti: It's the classic QA governance dilemma, who tests the testsuite?
<pitti> Riddell: see ^ -- a lot of KDE 5.10 -> 5.12 just landed in wily because the kdelibs4support test regression got ignored
<pitti> Riddell: where on a scale of "intended -- okay -- OMGrevert" is that?
<pitti> (the kdelibs4support test regression happenend much earlier, FTR, in 5.10 already)
<Riddell> mm, I've not made any changes recently
<Riddell> pitti: which ignore is that?
<pitti> Riddell: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html e. g. the topmost entry
<pitti> Riddell: or solid, kitemviews, etc.
<lifeless> infinity: the test test suite suite
<lifeless> infinity: actually more seriously, depends on known unknowns or unknown unknowns.
<pitti> that was definitively an unknown unknown
<infinity> Riddell: The kdelibs4support regression looks like one failing test.  Shouldn't be hard to hunt.  If I were you, I'd just let pitti's screwup go and enjoy the free promotions (and find the test failure).
<doko> pitti, the list is fine, maybe give those packages in main priority
<pitti> doko: ack, good idea (will continue after the britney SNAFU)
<infinity> pitti: Also, still no browser-friendly content headers before switching to the new shiny? :(
<pitti> Riddell: my main question to you is whether you are fine with 5.12 landing in wily now
<Riddell> pitti: yes I'm all for it
<pitti> infinity: I spent like an hour on that, there's no effing way to do that :(
<pitti> (I sent a summary to bug 1474271)
<ubottu> bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged] https://launchpad.net/bugs/1474271
<pitti> Riddell: ok, thanks
<infinity> pitti: Humor me, what happens if you serve/link it as foo.txt.gz?
<infinity> pitti: Depending on the httpd in play, it might decide to do all the right things for you at that point.
<pitti> infinity: I actually tried all combinations of *.txt.gz, *.gz, Content-Type:, and Content-Encoding:
<infinity> pitti: Hrmph.  Kay.
<pitti> infinity: the httpd is swift in this case
<pitti> we could store the logs uncompressed, but they'll get quite a bit larger then
<infinity> pitti: I could "fix" it with a transparent apache sitting in front, but pretty sure there's got to be a cleaner way. :P
<pitti> yeah, the bug is still on my list, but less important -- opening in gedit works okayish
<wgrant> pitti: Hm, Content-Encoding: gzip should work fine
<wgrant> pitti: We totally don't do this in Launchpad:
<wgrant>     if filename.endswith('txt.gz'):
<wgrant>         encoding = 'gzip'
<infinity> pitti: FWIW, LP's correctly-behaving logs are Content-Encoding: x-gzip
<wgrant>         mimetype = 'text/plain; charset=utf-8'
<wgrant> Hahahahaha "correctly-behaving"
<pitti> slangasek: to confirm, promoting the no-change rebuilds for 3.5 are "harmless" (although unintended), so I don't think we need to revert those, right?
<infinity> wgrant: Correct, per my browser. ;)
<pitti> wgrant: yes, I did set Content-Encoding:, but swift doesn't send it or the browser doesn't take it into account
<infinity> wgrant: Curious that you push encoding=gzip, but twisted insisted in x-ifying it.
<pitti> wgrant: see https://bugs.launchpad.net/auto-package-testing/+bug/1474271/comments/1
<ubottu> Launchpad bug 1474271 in Auto Package Testing "fix MIME type of log.gz" [Medium,Triaged]
<pitti> so with "Content-Type: text/plain; charset=UTF-8" and the ignored COntent-Encoding, you see the gzipped garbage inline
<wgrant> pitti: Ah, I guess Swift could well realise that what you're doing is completely wrong.
<infinity> So, I'm talking to an apache here, not "swift".  Is that a proxy, or do you have some control over that apache and its config?
<infinity> Oh, I assume you'd have no control yourself, since it seems to be a shared prodstack resource.  Hrm.
<infinity> pitti: Did you revert the attempt to set Content-Type, etc?
<pitti> slangasek, infinity: so I went through all the promotions; it's basically KDE 5.12 (already cleared with Riddell), a bunch of python 3.5 no-change rebuilds, some packages whose tests now succeed on the new infra (a lot was blocked on sqlalchemy), and some harmless updates; I didn't import the test regressions from the new r-base, as they come from debian and nobody looks at those anyway, so we now
<pitti> consider those as "always failed"
<pitti> so I think by and large we are okay
<pitti> *phew*
<pitti> curiously test regressions are holding up *some* package updates, but not most of them; I'll chase that bug now
<pitti> wgrant, cjwatson: ^ panic mode off
<pitti> infinity: right, it's ProdStack's swift; this might be RT matter, but I think this is by and large a browser problem that it ignores Content-Encoding:.
<pitti> infinity: I never rolled this out as it didn't work
<pitti> slangasek, infinity: pretty much the only "questionable" promotion that I found is https://launchpad.net/ubuntu/+source/python-setuptools/18.0.1-1
<infinity> pitti: Browser's don't ignore content-encoding though...
<infinity> pitti: So, I'd be curious to see the bits you tried, or play myself a bit.
<pitti> that or python3-defualts broke tox, python-html2text, and ipython; but I suspect that it's the py3.5 transition,  checking logs
<infinity> pitti: Seems a bit broken if setuptools was breaking as-installed tests.  Would be more likely to cause build failures, no?
<infinity> pitti: Odds are it wasn't to blame.
<pitti> yeah, the logs of those look like it was py3.5, not setuptools
<pitti> so, I think by and large I was lucky in my screwup
<infinity> Yay luck.
 * pitti exhales and lowers blood pressure again
<LocutusOfBorg1> python3.5 broke some gl stuff
<LocutusOfBorg1> http://paste.ubuntu.com/11965059/
<LocutusOfBorg1> can anbody please englight me for this?
<LocutusOfBorg1>  from OpenGL.GL import * works on python3 but not on python3.5
<LocutusOfBorg1> leading to a build failure for python-pyqtgraph
<LocutusOfBorg1> I would like to help for the transition if possible
<pitti> presumably it needs a rebuild to build against 3.4 and 3.5
<pitti> ah sorry, no -- looks like this actually needs to be fixed in source
<LocutusOfBorg1> pitti, who needs to be fixed?
<pitti> OpenGL.GL apparently
<LocutusOfBorg1> mmm ok, that was my though
<LocutusOfBorg1> thanks
<LocutusOfBorg1> python-qt4 (4.11.4+dfsg-1build2) wily; urgency=medium
<LocutusOfBorg1>   * No-change rebuild to fix damaged filename caused by dh-python3 bug
<LocutusOfBorg1> Laney, ^^^ is that fixing my issue?
<Laney> LocutusOfBorg1: I doubt it
<LocutusOfBorg1> me too :(
<doko> seb128, now working on double-conversion
<seb128> doko, k
<doko> seb128, when will Mirv be back?
<seb128> doko, no idea, ask bzoltan
<seb128> he's in the sdk team, I didn't even know he was not around this week
<doko> ahh, no desktop
<seb128> no :-)
<seb128> hum
<seb128> https://errors.ubuntu.com/problem/2e928d043cd548a5933dfc25b2ea162446c277ef
<seb128> how come we have so many wily users getting python3.5 as default
<seb128> are they using wily-proposed?
<infinity> seb128: proposed still prefers 3.4
<seb128> infinity, what would make 3.5 be preferred?
<seb128> I doubt that many users changed their default manually...
<infinity> seb128: Other than changing the symlink, I can't imagine how people would get 3.5 as the default 3.
<seb128> weird
<infinity> ProcCmdline 	
<infinity> /usr/bin/python3.5 /usr/bin/onboard
<infinity> Is onboard calling 3.5 directly?
<infinity> Yes.  Yes it is.
<infinity> WTF.
<infinity> onboard (1.1.1-0ubuntu2) wily; urgency=medium
<infinity>   * No-change rebuild for python3.5 transition
<infinity> Apparently a no-change rebuild changed the interpreter.
<infinity> Thanks, crappy build system.
<seb128> weird, it doesn't have a python3.5 depends and running "onboard" here works without error
<infinity> seb128: Which version do you have installed?
<seb128> ii  onboard                                               1.1.1-0ubuntu2                                          i386         Simple On-screen Keyboard
<seb128> maybe it's amd64 specific
<infinity> seb128: 1.1.1-0ubuntu2 depends python3.5 here, and has a 3.5 shebang.
<seb128> my i386 binary has python3.4
<seb128> yeah
<seb128> i386 built with 3.4
<infinity> seb128: More complicated than that, actually.
<infinity> seb128: Looks like it's a race.  It builds all supported versions, then installs them all to the same path.
<infinity> seb128: Depending on which order that happens in make, you get 3.4 or 3.5
<seb128> fun
<infinity> seb128: Both are wrong, of course, it should just use a python3 shebang, otherwise building the modules for both versions is pointless. :P
<infinity> I don't know enough about distutils and setup.py magic to know how to fix this braindeath.
<infinity> The trivial fix would just be to re-install onboard and onboard-settings after setup.py install, since the versions in the source have the right shebang.
<infinity> But if this shebang-mangling is a common setuptools thing, I wonder how many other packages are broken/breaking?
<doko> seb128, working on wxwidgets. if you don't have time, maybe pitti could help with some packages?
<seb128> doko, yeah, that would be welcome
<seb128> I'm having a day off tomorrow and I'm trying to wrap up some other things today
<doko> seb128, ok, then please could you attach the diffs to the open debian reports?
<seb128> doko, yes, going to do that today
<infinity> doko: Is it a setuptools bug that build_scripts/install_scripts is setting the shebang to the exact python version instead of python3?
<infinity> doko: That doesn't seem right, and I don't think this particular package is doing anything special to make it do that.
<infinity>     scripts = ['onboard', 'onboard-settings'],
<infinity> It just has that in setup.py, and setuptools is doing the evil thing.
<infinity> Err, distutils.
<infinity> Not awake.
<infinity> doko: distutils, I mean, not setuptools.  4am brain.
<doko> infinity, which package?
<infinity> doko: onboard
<infinity> doko: It's getting a shebang of /usr/bin/python3.4 or python3.5, depending on what it's built with, and racy luck.
<infinity> doko: Neither seem correct, I'd assume it should just by python3?
<infinity> s/by/be/
<mgedmin> the "modern" way of installing python scripts is to use setup(entry_ponts={'console_scripts': ['foo=package.module:main_function', ...]})
<mgedmin> but I don't know what sort of shebang gets used in that case
<doko> infinity, that's expected, afaik. the packaging should be aware of it. not sure if dh-python normalises the shebang
<infinity> doko: It certainly doesn't seem to, or this bug wouldn't be in the binaries.
<infinity> Though, the part where it has a --no-shebang-rewrite option sort of implies it tries to.  Weird.
 * infinity tests a fix.
<cjwatson> I remember having to take great care in the germinate packaging to avoid that problem
<cjwatson> https://git.launchpad.net/germinate/tree/debian/rules
<cjwatson> (Though that isn't using the new pybuild hotness)
<infinity> cjwatson: I just applied a simple dh_python3 --shebang=/usr/bin/python3 hammer.
<infinity> cjwatson: Seems to have done the trick.
 * cjwatson nods
<cjwatson> That may not have existed when I was doing that
<cjwatson> python 2.7.3-1, python3 3.2.3-1 - so quite probably not
<pitti> seb128: which ones are you working on and want to pass on?
<infinity> seb128: onboard fix uploaded.
<pitti> seb128: (sorry, still getting into the gcc transition business, I don't know much about it yet)
<pitti> infinity: FYI, Laney is converting existing logs, so e. g. http://autopkgtest.ubuntu.com/packages/d/d-conf/trusty/amd64/ are clickable too now
<doko> pitti, forwarding you a list
<doko> see, what already is built in 39
<infinity> pitti: Snazzy.
<infinity> pitti: Glad you got it sorted.  I almost typed "we", but all I did was run your test case and point out that it works. :P
<pitti> doko: ok; so everything in silo-16 which needs a rename should go into silo-39?
<doko> pitti, yes. I'm working now on tinyxml2
<pitti> doko: most packages from your list are already done, it seems?
<doko> pitti, well, seb128 said around 10 would be missing
<pitti> seb128: do you have a list of remaining ones?
<pitti> .. which neither you or doko are working on?
<doko> look what already is in 39
<pitti> otherwise, if that gets in teh way too much, I'll go on with checking the debian bugs
<pitti> seb128, doko: ok, e. g. capnproto, cwidget, exiv2 aren't done; either of you working on those?
<doko> no
<pitti> so, I'll take exiv2, migrate it, and send the patch to Debian
<doko> google-perftools too, wxwidgets,
<doko> openbabel (not on the list)
<doko> musicbrainz5 (take it from experimental). the last two are needed by kubuntu
<infinity> doko: Debian imports seem vaguely happy now, python3.4 synced.
<doko> just got the email, thanks
<pitti> seb128: e. g. your cppunit change should go to debian bug 791013, right?
<ubottu> Debian bug 791013 in src:cppunit "cppunit: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791013
<pitti> or is there somethign about "our" transition which doesn't apply to Debian somehow?
<cjwatson> infinity: oh good
<doko> infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7732860
<doko> is this 3.5 related?
<infinity> doko: Hrm?
<doko> wild guess, didn't see that one before
<infinity> /Â«BUILDDIRÂ»/unity-scopes-shell-0.5.4+15.10.20150707/src/scope-harness/matcher/category-list-matcher.cpp:121:54: error: call of overloaded 'move(unity::scopeharness::matcher::CategoryMatcher&)' is ambiguous
<infinity> Just looks like a stricter compiler to me.
<infinity> doko: Or did you paste the wrong URL?
<doko> ohh, I was irritated by the ImportError: messages
<infinity> doko: Oh, all the importerror stuff could indeed be python shebang badness somewhere.
<pitti> doko, seb128: OK, so I still don't understand this -- cppunit got renamed, but nm -D from the old and renamed library look identical -- why did that need a rename?
<pitti> I thought we only need to do that if the symbols don't match
<doko> pitti, most likely I saw a build failure with the not renamed one, likely be triggered by template instantiations
<doko> resulting in link failures
<pitti> oh, nevermind -- I diffed 1.13.2-2build1 against 1.13.2-2ubuntu1~gcc5
<pitti> now I diffed 1.13.2 against 1.13.2-2ubuntu1~gcc5 and the syms are different
<doko> heh
<doko> so maybe start with exiv2, then strigi
<pitti> i. e. the -build1 ones were no-change rebuilds which were then broken because they changed ABI
 * pitti is still trying to understand this, having zero C++ knowledge
<pitti> ok, but that makes sense now
<pitti> doko: yep
<pitti> doko: i. e. upload exiv2, then upload no-change rebuilds of all reverse deps of it?
<cjwatson> doko,infinity: https://rt.admin.canonical.com/Ticket/Display.html?id=83461 should avoid that mirroring failure mode in future
<doko> pitti, no, no no-change rebuilds yet
<infinity> cjwatson: Ta.
<pitti> doko: ok
<infinity> cjwatson: Did we ever revisit using incoming/debian-buildd to import faster?
<cjwatson> no no no no no no no no no no no no no change rebuilds
<pitti> doko: and is not forwarding the changes to the debian bugs a mere omission, or intended?
<cjwatson> infinity: it's still buried somewhere in my mental to-do list; needs verification that things aren't going to melt if incoming rewinds
<doko> pitti, the plan is to copy these renamed libs to -proposed, then have a first go rebuilding things. because we can't rebuild everything for each transition, so we'll start transitions first, then do a first test rebuild
<doko> nowatson?
<doko> pitti, my changes are forwarded. seb128 wants to do this today
<pitti> doko: ack, so intended
<infinity> cjwatson: Is UNACCEPT still a thing ftp-master considers a valid action?
<cjwatson> We don't want to assume that it isn't.
<cjwatson> I think it still occasionally happens once in a blue moon.
<infinity> cjwatson: I suppose we could invent machinery to block something in proposed until it's "really" in unstable, and delete on unaccept, but that would be much tighter integration than we have today.  And probably serious overengineering.
<cjwatson> infinity: Oh, the concern was more just making sure that gina doesn't melt.
<cjwatson> infinity: I wasn't thinking about auto-syncing from incoming.  Just making it available for manual syncs in emergencies would generally be good enough, and doesn't require that kind of overengineering since if it's manual then somebody is responsible for it.
<infinity> cjwatson: Ahh.
<cjwatson> But I need to spend some time understanding gina enough to be comfortable with this ...
<infinity> cjwatson: Yeah, if '-d incoming' worked, that would already be a huge win.
<infinity> cjwatson: From dak's POV, incoming isn't actually a different suite, mind you, it's in unstable the moment it's accepted, but I guess since we're importing from Packages files, not the dak db, we can fudge it however we like.
<cjwatson> We could stuff it into debian/sid, but I think that might be harder
<infinity> A partial debian/incoming seems reasonable to me. (or $suite-incoming, if you want completeness)
<infinity> Though, the latter sort of implies giving debian series' pockets, which I'm not sure we've ever bothered doing, have we?
<infinity> I guess it doesn't have to imply that, sid-incoming can just be a whole new series.
<cjwatson> Hm, it's true that it'd be a lot of series, and we don't have arbitrarily named pockets, the best we could do is stuff into unstable-proposed
<cjwatson> Which might not be entirely terrible modelling
<cjwatson> Err, debian/sid-proposed that is
<cjwatson> There's also things like buildd-testing-proposed-updates though
<infinity> Yeah, p-u is what would actually model to proposed, if we were being pedantic.
<cjwatson> We don't import p-u right now
<infinity> buildd/unstable really is a part of unstable, it's just unpublished on ftpmaster.
<infinity> Bit it's unstable according to the DB.
<cjwatson> We could merge them, that's not impossible
<infinity> THat would more correctly match dak ls / rmadison's view of the world.
<pitti> doko: forwarded to debian bug 791030 and reassigned to release.d.o (I trust that this is still the right thing to do -- seems a bit odd as the maintainer will stop seeing it?)
<ubottu> Debian bug 791030 in release.debian.org "exiv2: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791030
<doko> pitti, hmm ... anyway, I think most of these will be done by NMU's ... but maybe just attach the patch for now (but don't change it back)
<pitti> doko: ok, I'll attach the patch for strigi then without reassigning (I don't have an opinion on that, I'm just thinking aloud to avoid errors on the first one that I do :) )
<doko> no, makes sense
<doko> pitti, working myself on wxwidgets
<pitti> but yeah, a big swamp of NMUs sounds easier than getting 200 maintainers to dput around the same time
<StevenK> Synchronize watches ... okay, everyone hit enter on 3. 1 ... 2 ... 3!
<cjwatson> reminds me of a vintage #debian-devel topic
<cjwatson> OPN: more fun than a 200-user ytalk session on auric
<seb128> infinity, thanks
<seb128> pitti, no, not working on gcc5 things atm, I'm having tomorrow off and I'm trying to clean out some other things today before
<pitti> seb128: ack
<StevenK> Oh god, ytalk
<seb128> pitti, unsure what list doko gave you, but some don't need rename
<seb128> like poppler or syncevolution
<seb128> like if there are no changed symbols in the public abi there is no need for a rename
<pitti> seb128: because they don't change public symbols
<pitti> yep
<seb128> right
<seb128> pitti, you can look at logs in https://people.debian.org/~doko/logs/gcc5-20150701/
<pitti> W: libsearchclient0v5: package-name-doesnt-match-sonames libsearchclient0
<seb128> pitti, if they have a C11XX symbols section
<pitti> that's expected, right?
<pitti> seb128: yep, got that
<seb128> pitti, yes
<seb128> the warning is normal I think
<pitti> i. e. we don't want to fiddle with the soname because we have the Conflicts:/Replaces:?
<seb128> correct
<seb128> soname change are more complex and an upstream thing
 * pitti uploads strigi and sends it to Debian
<doko> I should document that we can remove the conflict/replaces with the next soname bump
<pitti> seb128: imagemagick (8:6.8.9.9-5build2) shoudl have been ubuntu1 I take it?
<pitti> well, let's hope that the next debian upload will include this
<seb128> pitti, yes
<pitti> seb128: do you have a list of packages which don't need to be converted? (like poppler, which I removed from my local one, but I'm sure there's more)
<pitti> doko, seb128: so your list minus the ones in the PPA is http://pad.ubuntu.com/gcc-5-transition
<pitti> that might have stuff that you already work on or which were already checked to not require a rename -- please update or put your name on what you work on?
<pitti> grabbing capnproto then
<seb128> pitti, the list I pastebined you yesterday was that
<seb128> pitti, http://paste.ubuntu.com/11960809/
<seb128> was the remaining from doko list
<pitti> seb128: ah, those *do* need renames, all others don't?
<seb128> I should have noted the ones that don't need transition, let me clean out those on the etherpad
<seb128> pitti, correct
<seb128> pitti, well, those need transition or to be checked
<pitti> ack, pad updated
<seb128> it's the initial list - the ones done - the ones that I checked and don't need to be done
<seb128> danke
 * pitti grabs cwidget then
<doko> working on guichan
<pitti> doko: marked on pad
<doko> pitti, the snappy package has nothing to do with snappy ;)
<doko> working on jack2d
<LocutusOfBorg1> is there any reason for python-3to2 migration failure? I see from update_excuses "missing build on", but it is an arch:all package
<LocutusOfBorg1> or maybe I should just wait some little more
<cjwatson> LocutusOfBorg1: You need to be more patient.
<cjwatson> LocutusOfBorg1: That proposed-migration run started before the built binaries had published.
<LocutusOfBorg1> I'm wondering if the old python3-3to2 that belongs to a different package might be a problem
<cjwatson> LocutusOfBorg1: Shouldn't be.
<LocutusOfBorg1> thanks
<LocutusOfBorg1> Unit193, ok to upload ext-pack on experimental?
<pitti> doko: cwidget doesn't have a Debian bug report; shoudl I create one, or am I missing something and it shouldn't have? (aptitude is the only reverse dep)
<doko> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792681
<ubottu> Debian bug 792681 in src:cwidget "cwidget ftbfs with GCC 5" [Normal,Open]
<pitti> doko: ah, thanks
<seb128> doko, pitti, should those bugs/patches be usertaged "origin-ubuntu wily ubuntu-patch"?
<seb128> or isn't that a thing anymore?
<pitti> seb128: it still exists AFAIK, so can't hurt
<doko> seb128, maybe, but you can't file new bugs with more than one user/usertag. that's why I usually omit those
<pitti> oh? I thought I've done this several times
<seb128> doko, you can
<seb128> "Usertags: origin-ubuntu wily ubuntu-patch" works
<seb128> in mails sent to submit@b.d.o
<pitti> like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777521
<ubottu> Debian bug 777521 in pgsql-asn1oid "pgsql-asn1oid: Test regression with PostgreSQL 9.4.1 due to invalid \set ECHO" [Normal,Open]
<cjwatson> Right, but not more than one user/(list-of-usertags) pair
<gema> do we have britney running on ubuntu packages? can anyone give me the link to it?
<pitti> several User/Usertags: pairs
<cjwatson> gema: http://people.canonical.com/~ubuntu-archive/proposed-migration/
<gema> cjwatson: thanks!
<doko> maybe this works now, but I was bitten in the past by it not seeing my filed bug reports
<cjwatson> pitti: I'm reasonably sure only some of those are parsed
<pitti> maybe only the last one hten
<cjwatson> my reading of http://git.donarmstrong.com/?p=debbugs.git;a=blob;f=scripts/process;h=4c38000121c02e388828aee0374672c5d0abe7a5;hb=HEAD#l686 suggests that you only get one
<cjwatson> probably only the last, indeed
<doko> seb128: hmm, not sure if Robert's "fix" to build everything in the gnome mm stack with -std=c++11 is the correct solution ... see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+build/7739358
<doko> seb128, pitti: do you have a list of packages which didn't need renaming? most likely they need a rebuild
<pitti> doko: so far only libcaca from me (on the pad)
<doko> ok, copying
<pitti> and I know poppler and syncevolution from seb128, but he said he found more
<pitti> I couldn't check libept yet, this is utterly broken
<doko> Riddell, do you have updated kde4libs and phonon packages which I could use in my ppa?
<doko> copied poppler
<Riddell> doko: for gcc 5? I've not looked at that for kdelibs or phonon
 * Riddell asks santa
<pitti> doko: http://paste.ubuntu.com/11966920/ is for libusermetricsinput1 -> this does not need a transition, right? (still need to check the other libs from libusermetrics, but checking that I understood it)
<seb128> doko, yeah, unsure either
<doko> no, looks good. only references to libstdc++
<pitti> doko: ok, thanks; libusermetricsoutput1 is completely identical (except for offsets), so marking on pad
 * pitti wonders why Debian BTS complains about "user/usertag" in Control: stanzas, but they work fine with "bts"
<cjwatson> pitti: because service is a bit more stateful than process
<cjwatson> I mean that's not really a *reason*, but it's an excuse :)
<pitti> cjwatson: oh, so Control: are handled by something *different* than -control@ mails?
<seb128> doko, pitti, sorry I didn't note down the ones that don't need transition, I just deleted them from my list. I think it was at least "packagekit poppler pulseaudio syncevolution"
<pitti> seb128: noted these down in the pad
<pitti> -T _ZN12osgAnimation10StatAction4initEPN3osg5StatsERKSsRKNS1_5Vec3fEffRKNS1_5Vec4fE
<pitti> +T _ZN12osgAnimation10StatAction4initEPN3osg5StatsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS1_5Vec3fEffRKNS1_5Vec4fE
<pitti> hm, that is a symbol change, isn't it?
<doko> yes
 * pitti renames libopenscenegraph100 then; libopenthreads20 doesn't change symbols and thus can stay
<cjwatson> pitti: IIRC, but it has been a long time
<doko> pitti, cwidget has a patch in the silo16 ppa
<pitti> doko: ah, thanks
<pitti> I'll finish openscenegraph, then it's meeting time anyway
<pitti> wgrant: I just requested a full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs ; could you please launch this manually so that infinity gets fresh trusty packs in time for the point release?
<pitti> wgrant: or rather, I would request it if the page wouldn't keep timing out; but I'll keep trying
<pitti> wgrant: hm, do you have some other magic to get a full export that circumvents the timeout?
<pitti> wgrant: ah, I think I caught a lucky spot :)
<doko> can I tell apt to skip downloading translation files? always get hashsum mismatches
<pitti> echo "Acquire::Languages \"none\";" > "$root"/etc/apt/apt.conf.d/90nolanguages
<pitti> doko: ^
<pitti> doko: ah, you probably don't need the $root bit
<doko> thanks
<bdmurray> infinity: are we discussing bug 1471903 here?
<ubottu> bug 1471903 in livecd-rootfs (Ubuntu) "-updates, -security missing from apt lists" [High,In progress] https://launchpad.net/bugs/1471903
<infinity> bdmurray: Sure.
<infinity> bdmurray: So, originally, the patch would have been about saving some image space from having useless data on it.
<infinity> bdmurray: Clearly, the data is less useless to you than it was to us back then.
<infinity> bdmurray: And images have grown in size.
<infinity> bdmurray: So, it might be that this isn't even worth discussing and we should just revert the patch.
<bdmurray> infinity: you'd also mentioned that apt-get update is running during the installer but that doesn't work in off-line installs...
<infinity> bdmurray: It's run when not offline.
<infinity> bdmurray: Heck, the installer is so clever it even replaces itself if a newer version exists.
<infinity> bdmurray: So, yeah, that machinery would totally thwart your attempt to get valid origins for things on the livefs that have had SRUs since.  Like, say, kernels.
<bdmurray> infinity: So if there isn't a downside I think it is just worth reverting.
<infinity> bdmurray: Anyhow, the updates lists are smallish, I'm fine with just including them.
<infinity> bdmurray: No point in security being there, since updates carries all security updates as well.
<infinity> bdmurray: And proposed should probably be there if it's in sources.list, but otherwise not.
<infinity> bdmurray: I'll look at the current state of things.
<bdmurray> infinity: okay, thanks!
<doko> pitti, working on tagcoll2
<pitti> doko: do the errors in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/f/foolscap/20150728_124422@/log.gz tell anything to you? foolscap got broken by the new twisted
<pitti> doko: (the new twisted accidentally migrated this morning)
<pitti> doko: I can reupload the previous 0.14 twisted and re-upload 0.15 to wily-proposed to restore the previous situation, unless you have a better idea
<doko> pitti, well, do we care about foolscap? look at their "twisted-compat" patches ...
<doko> jtaylor, ^^^
<pitti> I'll run the test in Debian and report it there then; ci.debian.net didn't yet get around to running it with 0.15
<pitti> doko: ack, so ignore for now?
<doko> https://github.com/warner/foolscap/commit/d09495f36ad77b26bf450efa0ca2ac025a7b43ba
<pitti> doko: oh, cool! thanks
<pitti> I'll test/cherry-pick that and send a patch to debian then
<pitti> ... tomorrow, EOD now
<doko> infinity, slangasek: could one of you merge dh-exec?
<doko> $ dpkg -c ../libept1.4.12_1.0.13ubuntu1_amd64.deb |grep DEB
<doko> lrwxrwxrwx root/root         0 2015-07-30 16:40 ./usr/lib/libept.so.1.0.5.4.16 -> ${DEB_HOST_MULTIARCH}/libept.so.1.aptpkg4.16
<infinity> doko: Merge it with what?
<infinity> doko: The latest is in proposed.
<doko> infinity, dep-wait
<infinity> Evidently it wants a package we don't have for some reason...
<infinity> Oh, it's FTBFS.
<infinity> Hah.
<cjwatson> and also will need an MIR
<infinity> The MIR should be trivial, since it's a build tool.
<infinity> But lol for a testsuite failing its own testsuite.
<cjwatson> that looks like potentially something like a shell syntax difference
<cjwatson> maybe?
<slangasek> infinity: have a look at libtest-requiresinternet-perl :P
<infinity> slangasek: I can infer what I'd see just from your instruction to look.
<slangasek> pitti, infinity: moving discussion here.  regarding the p-m event this morning, I don't think it's at all a given that these python3.5 rebuilds should have been let through.  There were test failures higher up the stack in packages that did *not* require rebuilds for python3.5, and which are not shown in the list of tests associated to python3-defaults; and there were no-change rebuilds that I uplo
<slangasek> aded, that were for pre-existing packages that ...
<slangasek> ... nevertheless had outstanding test failures in -proposed.  It may be too late to roll this back now, but I think there should be some deeper analysis of the skipped failures
<slangasek> wow, hello split
<infinity> cjwatson: Curious, it passes in a quick local attempt.
<cjwatson> infinity: throw back against the wall?
<infinity> cjwatson: It's been hitting the wall since vivid, last attempt three days ago.
<infinity> cjwatson: I think I might need to dig deeper. :P
<cjwatson> odd
<infinity> slangasek: I didn't see the full list of copies from the fallout.  I was trusting pitti's assertion that the failures he saw didn't seem to be particularly problematic, but I didn't do much/any investigation myself.
<slangasek> infinity: sure.  do we think it is too late to roll this back?
<infinity> slangasek: I'd rather investigate than roll back.  Unwinding everything that might depend on things we're rolling back doesn't sound fun.
<infinity> slangasek: And unpromoting *everything* since the event would be the only way to really ensure that, which sounds kinda disruptive.
<slangasek> infinity: right, so for the record I've been investigating said regressions for a week and was not to the bottom of them all yet
<infinity> cjwatson: Huh.  And works in a local sbuild too.  Curiouser and curiouser.
<infinity> slangasek: Is there a list of these?  I can help go through some.
<doko> infinity, updated libept in silo16. if you fix it, please in the silo. but it doesn't look critical
<slangasek> infinity: http://people.canonical.com/~vorlon/excuses-broken-autopkgtest.html
<infinity> slangasek: Also, did you see my onboard upload on top of your rebuild?  That's a class of bug you might want to look out for in the python transition. :/
<slangasek> infinity: no; onboard is the source package name?
<infinity> slangasek: Yeah.
<slangasek> infinity: so far the only thing I *know* is a regression that snuck into wily here was ipython
<infinity> slangasek: Do we have the matching output.txt from that run?  "valid candidate" in excuses didn't necessarily mean it promoted.
<slangasek> infinity: ehhh why is --shebang needed?  isn't this supposed to be default behavior of dh_python3 for programs?
<infinity> slangasek: If it's mean to be the default, it doesn't seem to be.
<slangasek> infinity: it doesn't look like I do have it, unless it's archived on snakefruit somewhere.  but you can cross-check the versions against the archive
<infinity> slangasek: And what was super fun was that we got python3.4 on one arch and python3.5 on another.  Both wrong, of course, but 3.5 blew up rather nicely.
<slangasek> sqlite3 appears to have regressed r-cran-rsqlite
<infinity> slangasek: Okay, so the good(ish) news on ipython is that it didn't regress on python3.4, it's only broken with 3.5, which might be because of the half-done transition, or might be because something's actually broken.
<slangasek> infinity: it's because something's actually broken.
<infinity> slangasek: But until python3-defaults points to 3.5, it's fine.
<slangasek> infinity: and when python3-defaults points to 3.5, this will not block it
<infinity> slangasek: And a python3-defaults upload will retrigger ipython tests, which would block it.
<slangasek> infinity: nope; there already was a python3-defaults upload, ipython is not in the reverse-dep list
<infinity> It... Sure is.
<infinity> If the infrastructure is failing to parse that, that's a bug.
<infinity> Maybe because it's a python3:any dep...
<slangasek> ok
<slangasek> pitti: ^^ can p-m be fixed to get ipython into the autopkgtest list for python3-defaults? :)
<infinity> pitti: Or, more to the point, why isn't it? :P
<infinity> pitti: I'm guessing a failure to parse :any deps.  Maybe?
<cjwatson> Probably because it's running on a system with a python-apt that predates :any
<cjwatson> is my guess anyway
<cjwatson> I'd suggest what I did for LP recently, that is, switch to using python-debian for parse_depends type things on the grounds that it's way easier to upgrade
<cjwatson> although that may be tricky here since it's using apt.Cache
<cjwatson> though ... apt_pkg.parse_depends("foo:any") seems to roughly DTRT on snakefruit so maybe I'm wrong
<infinity> Perhaps there's somewhere in the pipe where one can just 's/:.*//' and be done with it?
<cjwatson> you're gonna need to handle build profiles too
<slangasek> pitti: I also have in my notes that python-numpy was blocked by a pyresample test regression... and pyresample is not shown as having been tested for python-numpy
<cjwatson> which are a bit harder, just dumping <.* doesn't tend to go so well
<infinity> Right, yet another argument for me getting to the apt/dpkg/python-apt trusty SRUs and precise-cat backports, I geuss. :/
<slangasek> and that one appears to be a straight binary dependency from python-resample on python-numpy, no :any handling involved
<infinity> The lack of sorting in those lists is driving me mad.
<infinity> slangasek: I don't see any successes in pyresample's history, so I'm not sure about regressions there...
<infinity> slangasek: The new version just built, though, so maybe it'll be happy.
<infinity> slangasek: Oh, was pyresample the one you were talking about magically starting to fail in wily when it was fine in vivid?
<infinity> Ahh, indeed it was.
<slangasek> infinity: yes, but regardless it's a problem that pyresample isn't showing as tested for python-numpy
<infinity> slangasek: Indeed.
<pitti> infinity, slangasek: foolscap is the one regression that I saw and that we moderately care about that was affected by letting twisted in
<pitti> infinity, slangasek: http://people.canonical.com/~pitti/tmp/excuses.html was the run from this morning
<pitti> :any deps> snakefruit runs precise, might indeed have a too old python-apt for :any; I'll create a bug to see if we can work around it
<juliank> What is mvo doing?
<juliank> Haven't seen him recently
<pitti> bug 1479922
<ubottu> bug 1479922 in Auto Package Testing "doesn't consider :any reverse dependencies" [Undecided,New] https://launchpad.net/bugs/1479922
<pitti> juliank: I've heard he's on vacation
<juliank> :(
<slangasek> pitti: thanks.  did you also see the comment above about pyresample not being tested for python-numpy?
<juliank> but thanks, pitti
<pitti> yep (reading backscroll from top to bottom)
<pitti> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pyresample looks like an ordinary FTBFS, same as this morning (http://people.canonical.com/~pitti/tmp/excuses.html#pyresample
<pitti> slangasek: http://people.canonical.com/~pitti/tmp/excuses.html#python-numpy was blocked by pytables
<slangasek> pitti: yes, but the set of *tested* packages is still wrong
<slangasek> why was pyresample not tested?
<slangasek> the fact that python-numpy /happened/ to get blocked by another failure is not comforting
<pitti> ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/wily/2015-07-30/00:12:32.html.gz had pyresample for numpy indeed
<pitti> conversely, the old infra didn't test pyorbital, the new one does
<pitti> tracked as bug 1479926
<ubottu> bug 1479926 in Auto Package Testing "python-numpy does not trigger pyresample" [Undecided,New] https://launchpad.net/bugs/1479926
<hallyn> infinity: having a duh moment.  merging a release from debian.  do i use debuild -S -sa -v<priori-ubuntu-version> to include the debian changelog entry in .changes?
<pitti> hallyn: yes, please
<hallyn> pitti: thanks.
<bdmurray> jamespage_: is bug 1479496 supposed to be fixed in Wily and In Progress in Vivid?
<ubottu> bug 1479496 in python-neutronclient (Ubuntu Wily) "[SRU] python-neutronclient 1:2.3.11 + long request URI's don't work with Kilo" [High,In progress] https://launchpad.net/bugs/1479496
<mitya57> Can some archive admin please look at lp: #1465703?
<ubottu> Launchpad bug 1465703 in unity-mail (Ubuntu) "Please remove unity-mail from the archive" [Undecided,New] https://launchpad.net/bugs/1465703
<mitya57> Laney, thanks a lot for fixing ipython! :)
<cjwatson> mitya57: done
<mitya57> cjwatson, thanks
<mitya57> jtaylor, unping because Iain fixed it
<doko> infinity, could you have a look? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+sourcepub/5267655/+listing-archive-extra  built fine before
<doko> not that we would need that on ppc64el, but it fails with -O0, so maybe something wrong in qt5, or because it's built using -O3?
<teward> stupid generic question, but where can I obtain a copy of the gcc5 stuff to testbuild packages via it, to determine if there's broken stuff in some of my code?
<sarnold> teward: hopefully useful: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-July/001143.html -- do ko has already done rebuilds and published results :)
<teward> sarnold: rebuilds of the entire repositories?
<teward> or only things with direct depends
<sarnold> teward: I think everything
<teward> ack
<teward> i think you know which packages i'm interested in xD
<teward> and a few private nonpublished ones're also on my radar :P
<kees> stgraber: say... I'm following instructions for unpriv lxc at https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-unpriv on vivid. I have some questions... if you have a moment?
#ubuntu-devel 2015-07-31
<doko> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+sourcepub/5267908/+listing-archive-extra
<doko> Laney, slangasek: apparently introduced by new gstreamer
<synthor> heya
<synthor> anyone knows about this one: https://twitter.com/temasek71/status/626688248841023488 ?
<synthor> i'm sitting here since hours asking myself why cyanogenmod build fails with broken pipes
<synthor> tested my memory modules
<synthor> and then i find a twitter post, reboot the old kernel and the build runs through
<synthor> 3.13.0-59 doesn't compile,  3.13.0-58 does
<sarnold> synthor: can you reproduce on a current kernel?
<synthor> not atm, i rebooted -58 and now the cyanogenmod build runs through for an hour or so
<synthor> later i can, of course
<pitti> Good morning
<pitti> slangasek: gosh, what a shameful britney bug; reproduced in a test case and fixed now
<jamespage> bdmurray, wily has a sufficently new version that it already contains the fix for that bug
<pitti> infinity, slangasek: ah! http://anonscm.debian.org/cgit/debian-release/britney2.git/commit/?id=b9f6417351 introduces :any dependencies
<pitti> hm, but we have that already
<stgraber> kees: I'm in Europe this week, might be easier to chat next week when I'm back in north america :)
<infinity> pitti: I don't think britney itself has issues with :any for migration/installability checks.
<pitti> infinity: the reverse dep calculation does
<pitti> I fixed it now
<pitti> infinity: http://bazaar.launchpad.net/~pitti/britney/britney2-ubuntu-swiftresults/revision/464 ?
<infinity> pitti: Hrm.  Curious.  What would that have affected other than autopkgtest triggers, I wonder?
<infinity> pitti: If it was horribly broken, you'd think we'd have noticed.
<pitti> infinity: well, it just didn't consider a Depends: python:any in rdepends, so any installability check etc. would ignore this
<infinity> pitti: installability checks use forward deps, not revdeps.
<infinity> pitti: Perhaps it might have tripped up the autohinter occasionally.
<pitti> RDEPENDS is also being used in doop_source(), is that not used for installability checks?
<pitti> in _check_packages() too
<pitti> so I figure what *could* happen now is that this change now causes britney to hold back packages that it previously didn't
<infinity> Dunno.  I'd have to read a lot more, I'm just pondering how it wasn't obviously broken (and it wasn't), given the numeber of things with foo:any deps.
<pitti> hopefully this is actually justified in most cases, but if it's wrong, then it would err on the safe side, wouldn't it?
<infinity> Anyhow, regardless, your patch seems safe and obvious enough.
<pitti> is there any other suffix than :any?
<infinity> :native
<pitti> a split(':')[0] might be more appropriate
<infinity> Although, wait.  Tell me the output from the thing you patched doesn't get fed to the bits Colin fixed?
<infinity> Cause then they'd suddenly be wrong.
<infinity> Since his stuff explicitly only allows an :any dep on things that are M-A:allowed (as the spec requires).
<infinity> If you strip :any before you get to that check, then you're regressing that.
<pitti> register_reverse() actually happens after that (cjwatson changed read_sources(),  which calls register_reverse near the end)
<pitti> infinity: ipython doesn't have M-A: allowed
<pitti> python does
<infinity> pitti: No, python does.
<infinity> You can only dep on foo:any if foo is M-A:allowed
<pitti> ah no, not even read_sources, but get_dependency_solvers()
<pitti> but a package without M-A: can have a Depends: foo:any, no?
<infinity> pitti: Sure.  The point is that for installability checks, you need the full dep, a stripped version is a lie.
<pitti> anyway, the above commit does not actually filter them out for the "packages" maps calculation, only in the subsequent installability test
<pitti> yes, http://bazaar.launchpad.net/~pitti/britney/britney2-ubuntu-swiftresults/revision/464 does not modify the DEPENDS field
<pitti> but when reading the DEPENDS field (which includes the :any) it currenlty tests whether that value is a known package
<pitti> but "python:any" is not a package name
<pitti> so in the dict lookup it must strip the :any suffix
<pitti> of course packages[DEPENDS] should continue to have the :any suffix (and I'm not changing that)
<infinity> pitti: Mmkay.
<pitti> I'll send a Debian bug about that too
<pitti> infinity: you don't happen to know the Debian britney2-tests suite? I'm getting http://paste.ubuntu.com/11971566/
<infinity> pitti: Not sure how to make the testsuite go.
<pitti> it doesn't cover ":any" stuff right now
<infinity> pitti: Do we trigger on rbuilddeps too or just rdeps, I can never remember?
<pitti> infinity: so far (in old and new infra) only on rdeps
<infinity> I guess just rdeps, or we'd have a lot more tests running.
<infinity> pitti: Anyhow, if rbuilddeps were ever in the cards, you'd have to worry about both :any and :native
<pitti> ENOTENOUGHHORSEPOWER
<pitti> we don't even trigger autodep8 tests ATM, for the same reason
<infinity> :native is unique to build-deps (it doesn't make sense for deps, since "native" is the default assumption anyway).
<pitti> infinity: if there's only these two, I think  split(':')[0] is better -- ':' can't ever occur in a package name, so stripping off all qualifiers for the package dict lookup seems safer
<infinity> pitti: Yeah, that's what I did in the old-skool sbuild fork, since I didn't care about supporting cross-building. :P
<infinity> pitti: Made life much simpler to just ignore M-A and pretend it wasn't a thing.
<pitti> well, britney should take it into account
<infinity> britney's meant to be growing actual MA support soon anyway.
<infinity> Which means cross-arch deps without hacks.
<infinity> Which I still think is a mistake, but we'll see if people abuse it. :P
<infinity> Right now, we have exactly one cross-arch dep, I think (wine64->wine32), and I think that's about the right number.
<infinity> Oh, and build-essential-$arch->libc:$arch.  So, two.
<infinity> s/libc/libc-dev/
<dholbach> good morning
<pitti> infinity: ah, got the tests to work, still all pass
<pitti> forwarded to Debian bug 794194
<ubottu> Debian bug 794194 in release.debian.org "britney: Strip off Multi-Arch qualifiers in reverse dependency calculation" [Normal,Open] http://bugs.debian.org/794194
<Laney> doko: fixing it, thx for noticing
<Laney> doko: shall I just upload to 39 or wily or what?
<doko> Laney, fixing in gstreamer, or thumbnailer?
<Laney> thumbnailer?
<Laney> you mean tp-qt5, and it's there
<doko> Laney, yes, 39 would be fine.
<pitti> sbeattie: FYI, new apparmor seems to break content-hub: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apparmor
<jjohansen> pitti: do you know what kernel that was run on?
<sbeattie> pitti: yeah, I haven't dug into it yet, need to dig out the bits to reproduce it.
<doko> Laney, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+build/7741720  new gnome components?
<pitti> sbeattie: ack, just wanted to make sure you're aware, as email notification isn't very effective for these
<Laney> doko: sec, on the phone
<pitti> jjohansen: https://jenkins.qa.ubuntu.com/job/wily-adt-content-hub/lastBuild/ARCH=amd64,label=adt/artifact/results/testbed-packages/*view*/ says 4.1.0-3.3
<jjohansen> pitti: I asked because the kernel team is rolling out the 4.2 rebase it is possible that could cause some regressions as well
<jjohansen> pitti: thanks
<pitti> I should start referring to the new system on http://autopkgtest.ubuntu.com/packages/c/content-hub/wily/amd64/ :)
<pitti> jjohansen: so, there ^ you can look at the debci log
<pitti> you see in the "base system diff" that the kernel did not change, but apparmor changed from 2.9 to 2.10
<pitti> (also, python3.4, but that's most probably not the cause)
<jjohansen> got it
<pitti> this is a much more useful view than the old jenkins stuff
<pitti> sbeattie: please let me know if you have trouble reproducing it (using adt-run etc.)
 * pitti runs it locally for fun
<pitti> and yay for tests which just say "FAIL" without saying what/why
<pitti> adt-run --apt-pocket=proposed -U content-hub --- qemu adt-wily-amd64-cloud.img
<pitti> sbeattie: ^ reproduces locally; I suggest running with -s to get a shell after the failure
<Laney> doko: why gnome?
<Laney> doko: this is a touch component
<doko> Laney, why not? it was a question
<Laney> well if you have a reason then I want to know so that I can see it :)
<doko> Laney, please could you merge the new glibmm2.4 into silo 39?
<doko> seb128 isn't yet here
<Laney> i.e. if it's something I might be able to fix easily
<Laney> umm
<Laney> you mean 2.45.41.is.2.44.0-0ubuntu1?
<doko> probably, the ppa page says: glibmm2.4 - 2.45.41-0ubuntu3~gcc5.2 (Newer version available)
<Laney> is it reapplying this diff https://launchpadlibrarian.net/213023058/glibmm2.4_2.45.41-0ubuntu1_2.45.41-0ubuntu3%7Egcc5.2.diff.gz ?
<doko> yes, looks ok
<Laney> ok, will do
<doko> and then could you stop uploading stuff for 4-6 hours, which is in the ppa?
<Laney> I know you want to push it today, won't upload anything :)
<Laney> maybe mail -devel to tell everyone else
<cjwatson> doko: do you want auto-sync disabled now then?
<doko> Laney, sent
<doko> cjwatson, yes, would be good
<cjwatson> doko: done
<caribou> I'm looking for a sponsor for the merge of rsyslog (Bug: #1464201)
<ubottu> bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1464201
<caribou> I'm returning from vacation near feature freeze so I'd like to see this one in Wily so it gets shaken out before our next LTS
<Laney> doko: glibmm2.4 merged
<doko> Laney, ta, and I had to do a glib-networking rebuild in the ppa
<doko> renamed libproxy
<Laney> doko: will you NMU these renames?
<doko> Laney, nmu where?
<Laney> unstable
<doko> surely not all, need to write an email first ... want to call for "adopt a library transition"
<pitti> Laney: hmm, still stunned about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-system-settings-online-accounts/20150731_085942@/log.gz
<pitti> Laney: it looks like cloud-init isn't done yet at this point and the host name is still "ubuntu", i. e. it didn't get around to updating it yet
<Laney> pitti: it's happening through multiple retries?
<pitti> but we wait until /var/lib/cloud/instance/boot-finished exists, so it should be done
<Laney> why should that be package specific?
<pitti> Laney: http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/wily/amd64/ (and i386) failed four times in a row yesterday
<pitti> Laney: but if I run it manually on teh worker it succeeds
<pitti> Laney: yeah, no idea
<pitti> (package specific)
<pitti> I suppose it isn't really, as it happened to other runs too
<Laney> could just be unlucky
<Laney> you mean if you run the same adt-run command it works?
<pitti> e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/r/ruby-rails-assets-jquery-textchange/20150730_165419@/log.gz
<pitti> right
<pitti> it fails fast, as adjusting the apt sources (from --apt-pocket=proposed) is pretty much the first thing it does
<pitti> I'm running a loop with /home/ubuntu/autopkgtest/tests/testpkg-simple/ (which is very quick), to see whether I can hit it
<pitti> Laney: just wondering if you happen to have an idea abou that
<pitti>     if ! timeout 30m $SSH 'while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep 1; done'; then
<pitti> I don't see what's wrong with that
<Laney> why do you think that's the problem?
<Laney> isn't it that this hostname error causes sudo to fail?
<pitti> the sudo error points out that /etc/hostname is "ubuntu", not the correct host name yet
<pitti> or cloud-init fails, but then it shuoldn't create /var/lib/cloud/instance/boot-finished
<Laney> pitti: maybe some clue on the console?
<pitti> Laney: I guess my first step will be to make it fail with 16 instead of 20, and then think how the ssh setup script can do nova console-log only in such failure cases
<pitti> meh, restarted it again, failed again; so at least it's moderately reproducible
<synthor> is a kernel-dev here?
<pitti> that's a trick question -- better just ask your actual question
<pitti> synthor: ^
<synthor> the latest 14.04 kernel 3.13.0-59 causes segfaults
<synthor> 3.13.0-58 seems to be fine
<synthor> Jul 31 16:17:52 prosyn kernel: [11720.503201] ld[28708]: segfault at bae6b2d0 ip 00000000bae6b2d0 sp 00000000ea4e7d80 error 14 in ld-2.19.so[2b55bae6a000+23000]
<synthor> while compiling cyanogenmod
<synthor> if no segfault occurs, it'll create broken pipes
<synthor> rebooting the old kernel, everything runs fin
<synthor> e
<pitti> synthor: can you please report this as a bug, with the complete dmesg and reproducer?
<pitti> if possible, attach just a single ld command with pre-compiled object files that triggers this, as "build cyanogenmod" is not a very tractable (and well-defined) reproducer
<synthor> i'll check the makefiles for the command which triggers the bug
<pitti> synthor: if building doesn't show the full command line, but uses "quiet" output, running "make V=1" often helps
<pitti> then, if you can reproduce the crash with just running the single ld that it runs -> win
<synthor> clang: error: unable to execute command: Segmentation fault (core dumped)
<bdmurray> pitti: is there any reason the security SRU of apport, version 2.14.1-0ubuntu3.11, would be producing less informative crashes about /sbin/ip from iproute2?
<synthor> hard to track it down....those android makefile-system is just a monster ^^
<synthor> i greped the calls, but now i have to look which programs they're callin
<pitti> bdmurray: /bin/ip is not a suid/sgid program, behaviour for "normal" 755 executables shouldn't have changed
<pitti> bdmurray: i. e. I don't see a reason
<bdmurray> pitti: Could it be called another program?
<pitti> bdmurray: what does "less informative" mean here? the security update would cause suid/sgid programs to not get a report at all, or a root owned one, i. e. you wouldn't get a bug report unless a user is an admin
<pitti> is it that?
<pitti> the update doesn't have any impact on the quality of stack traces if you mean that
<bdmurray> pitti: The reports for iproute2 are incomplete - particularly missing StacktraceAddressSignature
<bdmurray> pitti: example here https://errors.ubuntu.com/oops/1b8c3c20-3607-11e5-89c7-fa163e525ba7
<pitti> bdmurray: do we have a core dump for those? maybe it's truncated or even 0 bytes?
<doko> slangasek, ready to pull the trigger? and start the copy?
<pitti> go, gcc, go!
<bdmurray> pitti: no, we don't ask for a coredump if there is no SAS and its not on armhf
<doko> started the copy now ...
 * Laney hears the screams of britney from here
<ogra_> teach her how to sing then !
<pitti> Laney: hah!
 * Laney hopes that this is a eureka moment hah
<pitti> Laney: http://paste.ubuntu.com/11973890/
<Laney> hahaha
<pitti> I thought POSIX would allow up to 255 chars
<pitti> cloud-init seems to think differently
<Laney> seems to be passing through an error from hostname?
<pitti> actually not c-i, it's hostname itself
<doko> copy is finished
<pitti> Laney: it seems the limit is 64 chars
<Laney> why didn't this happen when you ran it yourself?
<bdmurray> pitti: so no ideas about iproute2 crashes other than truncated crashes?
<pitti> Laney: I used --name adt-test, to avoid interfering with the running tests; silly me :)
<Laney> hehe
<pitti> bdmurray: no, I'm afraid; I tried "ip route & killall -SEGV ip" in a loop, but that's too slow to crash it; I figure one had to re-compile ip to force a crash and see what happens
<bdmurray> pitti: I used "ip monitor" and got a good crash
<pitti> Laney: that also explains ruby-rails-assets-markdown-it-diaspora-mention and the other funny long one :)
<pitti> "ones"
<Laney> is it always setting the machine name to the instance name?
<Laney> can't think that the hostname matters so much, unless I'm missing something
<pitti> yeah, would probably be even better to just hardcode it to "ubuntu"
<pitti> this seems to be the default, maybe c-i has some "hostname:" option
<Laney> looks like it does
<pitti> smoser: ^ it seems the host name defaults to the cloud instance name given to nova boot; is there a c-i option to change it? (nothing in http://cloudinit.readthedocs.org/en/latest/topics/examples.html)
<pitti> ChangeLog: - added cloud-config option 'hostname' for setting hostname
<pitti> ah!
<smoser> pitti,  you can also do 'manage_etc_hosts: localhost'
<smoser> which will make sudo not cry at you "unknown host" business.
<pitti> ah, instead of "true"?
<pitti> I have "manage_etc_hosts: true"
<pitti> for exactly that reason
<smoser> ah. maybe thats right. let me read doc that is there.
<pitti> smoser: but if I give my instance a very long name, it'll overflow hostname's 64 char limit
<pitti> smoser: I don't need that, just "adt" or so is enough as hostname; I just want to be able to identify my cloud instances from "outside"
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L447
<pitti> cool, "hostname: adt" works fine
<pitti> thanks smoser
<smoser> for identifying them, if you launched them on openstack, you can provide that hostname at launch time
<smoser> in fact you're required to provide one.
<pitti> I didn't explicitly give one, it just seemed to default to the name of "nova boot"
<smoser> ah. ok. i thought that nova boot required one.
<smoser> nova boot --key-name=brickies --flavor=m1.small --image=b9a4cbd6-82ae-4d53-8231-dc956aca100d smoser-hostname
<pitti> smoser: right, it does
<pitti> smoser: but my name is e. g. adt-wily-amd64-ubuntu-system-settings-online-accounts-20150731-150456
<pitti> and that causes http://paste.ubuntu.com/11973890/
<smoser> ah.
<pitti> Laney: ok, fixed and retrying tests
<pitti> and with that, good weekend everyone!
<Laney> pitti: prima! schÃ¶nes Wochenende!
#ubuntu-devel 2015-08-01
 * xnox ponders how nuts is wily at the moment.
<Unit193> Are you referring to the golang transition about to begin, python3 transition, or gcc5 transition? ;)
<infinity> xnox: wily is fine.  wily-proposed, on the other hand, might be a bit lolz.
<infinity> mitya57: It seems you lost track of #1157421 a long time ago.  Did you want to fix that SRU or just backport the trusty version (assuming it builds with all << trusty kernels)?
<siretart> Laney: I'd say drop libav completely, if dropping the -dev packages help in the interim, I have no objections
<MegaManSec> Will Ubuntu be going back to the regular glibc soon?
<ogra_> ogra@styx:~/apps$ apt-cache show libc-bin|grep ^Source
<ogra_> Source: glibc
<ogra_> MegaManSec, ^^
<ogra_> (thats on 15.04
<ogra_> )
<MegaManSec> great
<MegaManSec> patches will not occur on eglibc anymore?
<ogra_> i dont think so ...
<ogra_> (well, for the LTS releases that use it they will)
<MegaManSec> Hmm, ok. development for eglibc within ubuntu seems to be dead
<MegaManSec> so I guess it doesn't really matter.
<MegaManSec> oh also, does ubuntu have an open repo. for its development stuff? such as their (now old) eglibc?
<Laney> siretart: Needs a transition doing, like Debian's, I guess
<infinity> MegaManSec: We weren't upstream for eglibc, I'm not sure what made you think we are.  Like any other ubuntu package, though, you can get the source via "apt-get source eglibc" on the release you're using.
<infinity> MegaManSec: That said, eglibc was a pretty lightweight fork of glibc, many of the patches I carried in the package were directly from glibc git, you're better off treating them as the same thing.
<mitya57> infinity: Actually I know nothing about blktap-dkms, and don't remember why I started looking at it back then.
<infinity> mitya57: Heh.  Check.
<infinity> Well, we should probably fix that SRU.  Though, hopefully all the people who cared found another solution by now. :P
<mitya57> It will be nice if someone else can look at that, otherwise I'll do it later (I'm on semi-VAC these days).
<infinity> mitya57: I just noticed because I'd done wily/vivid/trusty uploads and was scouring for bugs.  And there was the ancient precise SRU failed and sad.
<mitya57> Also I didn't get much feedback on the version in my PPA (I believe the package is still there)
<mitya57> It will be nice if someone else tests it :)
<siretart> Laney: the transition in debian is already done
<siretart> Laney: more or less: https://release.debian.org/transitions/html/ffmpeg-libav.html
#ubuntu-devel 2015-08-02
<MegaManSec> infinity: ubuntu/debian made specific patches, though.
<MegaManSec> http://git.net/debian-glibc/txt5w0qWtefJS.txt This was never in the original glibc, or eglibc code.
<MegaManSec> well, I don't think it was in eglibc. Atleast, it's not still in the eglibc code.
<MegaManSec> Zz.. It is.. I don't know why I had the idea that it wasn't in the stock eglibc code.. http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/resolv/res_libc.c?r1=8608&r2=9102&pathrev=9102 Apologies. -- Anyways, the issue at hand is eglibc specific, which seems to only concern Debian/Ubuntu. However, development for eglibc is dead, and the bug is still present in the latest LTS distro.
<MegaManSec> (the bug I'm referencing is https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1432378). I think a quick fix would be to move the `static time_t last_mtime` into the res_state resp, and then set last_mtime inside the res_init(). Or, just change undo the patch.
<ubottu> Launchpad bug 1432378 in glibc (Ubuntu) "libresolv res_init() does not correctly inititalize internals " [Undecided,Confirmed]
<octoquad> Hi. I'm trying to split the syncevolution package to provide a sync-evolution-provider-goa package (see https://bugs.launchpad.net/ubuntu/+source/syncevolution/+bug/1406200). The end result works, but I'm struggling to create a debdiff for it, could some one assist me with this? I assume I'm missing one vital step as the debdiff only generates the changelog entry for the new version, no patch information is in it. Thanks
<ubottu> Launchpad bug 1406200 in Ubuntu GNOME "Add support for GOA in Syncevolution to make it work with Ubuntu-Gnome (Vivid)" [Medium,In progress]
<Noskcaj> octoquad, If you're diffing the .dsc, it should show the patch too
<octoquad> Thanks Noskcaj, I only see the dch -i entry in the diff. I'm not sure if I was suppose to use quilt or edit-patch prior to dch -i. I couldn't find any documentation on this procedure either.
<Noskcaj> What other changes are you doing?
<octoquad> All i'm doing is creating a in new package in debian/control based of an existing entry (UOA), then creating a new .install file to provide the .so. That's the only thing I'm doing.
<Noskcaj> If the files exist, they should appear in the debdiff
<Noskcaj> Have you ran debuild since doing the changes?
<octoquad> yes, using debuild -S
<octoquad> Let me try again, and I'll share the steps I used on pastebin.
<octoquad> Quick question, should I run debuild before or after dch -i?
<Noskcaj> dch -i adds a new changelog entry, debuild builds the source. So you can run debuild as much as you want, but you do need to run it after you update the changelog
<octoquad> Ok, so if I don't do dch -i first, then I get "signfile syncevolution_1.5-0ubuntu4.dsc Ken VanDine <ken.vandine@canonical.com>"
<octoquad> secret key not available
<Noskcaj> Because then debuild thinks that you're ken and want to sign the .dsc file
<octoquad> OK, so i've now added a changelog entry and it builds fine. Would this be a problem "W: syncevolution source: out-of-date-standards-version 3.9.5 (current is 3.9.6)"?
<octoquad> Noskcaj, this is what I end up with: http://pastebin.com/LvEwBt0y
<octoquad> I'm also getting "dpkg-source: warning: failed to verify signature on /path/to/syncevolution_1.5-0ubuntu5.dsc" which is the new dsc file I generated with my own GPG key
<Noskcaj> The standards-version is a semi-useless debian thing, so you can ignore that
<octoquad> ah ok, thanks
<Noskcaj> What files are you debdiffing?
<octoquad> debdiff syncevolution_1.5-0ubuntu4.dsc syncevolution_1.5-0ubuntu5.dsc > syncevolution_1.5-0ubuntu5.debdiff
<Noskcaj> ok, have you done that since building the package with the changes added?
<octoquad> which one, the binary package (sbuild) or source package (debuild -S)?
<Noskcaj> source should be enough
<Noskcaj> Are you sure you're pointing it at the right .dsc files?
<octoquad> Yes. I just started afresh while chatting to you. I grabbed it with dget.
<octoquad> busy building with sbuild at the moment although it normally results in the same thing for the debdiff as well
<xnox> infinity: did you rename all the -dev libraries....
<xnox> doing boost transitions, and i'm a bit iffy rebuilding things with -dev packages.
<xnox> slangasek: could you please rebuild ubuntu-touch-meta again? s/boost1.55-dev/boost-1.58-dev/
<xnox> pushed bzr branch, but germinate shouts at me that my "debootstrap is older"
<ari-tczew> xnox: have you seen my email about sync zabbix?
<xnox> ari-tczew: i will let you think about it for a little while. imho your email was a bit pointless =)
<octoquad> Noskcaj, darkxst assisted me with it and is now working. Thanks for trying to help me, I appreciate it.
<octoquad> Noskcaj, turns out I did the dch -i after instead of before I started with changes.
<octoquad> slangasek, do I create debdiff for syncevolution on ubuntu/wily-proposed/syncevolution or ubuntu/syncevolution for bug #1406200?
<ubottu> bug 1406200 in Ubuntu GNOME "Add support for GOA in Syncevolution to make it work with Ubuntu Gnome" [Medium,In progress] https://launchpad.net/bugs/1406200
<octoquad> I see you did some changes an hour ago.
<teward> probably the wrong channel but does anyone know what version of grub is needed to get Win10 support?
<slangasek> octoquad: bug #1406200 - you would always want your diff to be against the latest, so wily-proposed
<ubottu> bug 1406200 in Ubuntu GNOME "Add support for GOA in Syncevolution to make it work with Ubuntu Gnome" [Medium,In progress] https://launchpad.net/bugs/1406200
<slangasek> xnox: ubuntu-touch-meta - so I actually had some problems regenerating it at all, the update dropped libjsoncpp0 but failed to add libjsoncpp0v5 for me so I wound up applying the update manually - I'm not sure if there's a problem with it not wanting to pull from -proposed?
<cjwatson> slangasek: that's generally been true of *-meta - you could try setting "dists: wily wily-proposed" in update.cfg temporarily, though check the output carefully if you do
<slangasek> cjwatson: check, thanks for the hint
<slangasek> ScottK: hi, so I rebuild pyqt5 in wily for the python3-all-dev change, but it turns out it still shows up on the transition tracker (http://people.canonical.com/~ubuntu-archive/transitions/html/python3.3-5.html) because it links against libpython3.4.  Do you prefer replacing python3-all-dev with python3-dev, or to figure out how to support both libpython3.4 and libpython3.5?
<slangasek> (strange, why do my fingers always say rebuild instead of rebuilt?)
<ScottK> slangasek: IIRC it only matters for the qtdesigner plugin, which is only supported for the default python.
<ScottK> So I'd ignore it and then do the rebuild once 3.5 is default.
<slangasek> ScottK: ok - sounds like an argument for ignoring this wrt the transition, and keep - check
<ScottK> mitya57: ^^^ please double check that.
<infinity> slangasek: "the update dropped libjsoncpp0 but failed to add libjsoncpp0v5" <-- That sort of sounds like the ideal outcome for a metapackage, no?
<infinity> slangasek: Having libraries directly depended on by a meta is generally a bug, not a feature.
<slangasek> infinity: the metapackage in question is ubuntu-sdk-libs.
<infinity> slangasek: Oh, fair enough. :)
<mwhudson> um
<mwhudson> can i really not install gcc-multilib at the same time as e.g. gcc-aarch64-linux-gnu
#ubuntu-devel 2016-08-01
<ahoneybun> LocutusOfBorg: could we get a LP request on this: https://launchpadlibrarian.net/276000721/trojita_0.7.0+git20160728-0ubuntu1~ubuntu16.04~ppa1.dsc
<ahoneybun> tsimonq2 of Lubuntu might want it as well
<jbicha> ahoneybun: I think it would be best if you filed a needs-packaging bug for that since it's not in Debian or Ubuntu
<ahoneybun> it's packaged
<ahoneybun> it's in that ppa
<jbicha> right, but it needs to go through the new queue
<jbicha> and it's often faster to get it in Ubuntu if you can find someone (like the Debian Qt team) to sponsor it into Debian first
<ahoneybun> this sponsor thing is hold hundreds of uploads we have
<ahoneybun> *holding
<jbicha> if your packages were in sync with Debian, then a lot of the work would get done through autosync
<jbicha> I've considered syncing qt/kde stuff but then I see that you're trying to maintain the packages in git which I don't have write access to
<jbicha> but many times there aren't any real differences in the Kubuntu packages
<ahoneybun> jbicha: we have to get sponsored to upload new versions to the archive
<ahoneybun> for this there are
<ahoneybun> we need to upload them to get Plasma 5.7.2 out
<ahoneybun> Qt 5.6.1 is needed for 5.7
<ahoneybun> Plasma
<ahoneybun> we need a MOTU to come into #kubuntu-devel
<ahoneybun> we have no one to upload atm
<tsimonq2> ahoneybun: how so?
<ahoneybun> the trojita email client
 * tsimonq2 checks if it's in the LXQt metapackage
<tsimonq2> ahoneybun: that's our plan in the blueprints but the blueprint is marked as blocked and it's not in the metapackage, I'll ask Julien, but otherwise \o/
<ahoneybun> tsimonq2: clive has it built for xenial and yakkety in his ppa
<tsimonq2> ahoneybun: great :)
<tsimonq2> ahoneybun: is it not in the Ubuntu archive? :O
<ahoneybun> nope guess not
<Mirv> pitti: morning. could I get all-proposed for https://requests.ci-train.ubuntu.com/static/britney/ticket-1712/landing-070-yakkety/excuses.html and https://requests.ci-train.ubuntu.com/static/britney/ticket-1715/landing-080-yakkety/excuses.html , and restart of seemingly stuck "Test in progress" tests at https://requests.ci-train.ubuntu.com/static/britney/ticket-1715/landing-080-xenial/excuses.html ?
<cpaelzer> good morning
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.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 precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv, mterry
<pitti> Good morning
<tsimonq2> o/ pitti, how are you? :)
<pitti> I'm great, thanks! last two days before summer vacation :)
<tsimonq2> pitti: less than a month until the end of summer vacation and my first day of high school
<tsimonq2> :D
<pitti> that's still lots of of time to do stuff!
<tsimonq2> it is! :)
<pitti> Mirv: done
<pitti> Mirv: btw, when that happens while I'm away, please ask L_aney, i_nfinity, s_eb128, d_idrocks, or s_langasek to run something like "retry-autopkgtest-regressions -s yakkety --ci-train-silo 080 --ci-train-ticket 1715 --all-proposed" on snakefruit
<pitti> or --state RUNNING
<tsimonq2> pitti: you acutally pinged Steve, he gets pinged on his last name too I think :P
<pitti> well, I tried to be quiet :)
<tsimonq2> :)
<Mirv> pitti: noted and much appreciated!
<Mirv> tedg: hi! could you take care of the click upload asked for in bug #1496292 so that we could unblock many things in yakkety? tsimonq2 / LXQt folks would appreciate among else :)
<ubottu> bug 1496292 in packagekit (Ubuntu) "Needs to be ported to packagekit 1" [High,Confirmed] https://launchpad.net/bugs/1496292
<tsimonq2> yeah, lubutnu-qt-desktop can't be installed without it
<acheronuk> nor can plasma-discover
<tsimonq2> so the Kubuntu folks might appreciate it too :)
<cpaelzer> ntp has issues exporting their code history https://github.com/ntp-project/ntp/issues/15
<cpaelzer> via its archive I can only get full releases, where patches are obviously mangled together
<cpaelzer> the next "best" (not) option is to check their bitkeeper
<cpaelzer> but for obvious reasons I have none, and I even fail to get one setup for my personal account if I would
<cpaelzer> so if one still has a dusty but working bk setup please ping me as I'm trying to get a fix referred from a ntp bug for an SUR
<Unit193> Can't just look http://bk1.ntp.org/ntp-stable/?DATE=-6M..&PAGE=changes ?
<cpaelzer> That will do, thanks Unit193
<cpaelzer> I was looking for alternatives already - that is one that works - Thanks!
<LocutusOfBorg> do anybody have any update about qt5 migration?
<cpaelzer> mdeslaur: I come by ntp for a functional SRU anyway atm - there are quite a few CVEs reported - I wanted to discuss if I should include some in your opinion
<cpaelzer> mdeslaur: sorry to bother you but according to the changelog you were the last to add CVE fixes to the package
<cpaelzer> mdeslaur: looking at http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities CVE-2016-4957 is high, CVE-2015-5300 is only medium but seems very easy to backport
<ubottu> ntpd in NTP before 4.2.8p8 allows remote attackers to cause a denial of service (daemon crash) via a crypto-NAK packet.  NOTE: this vulnerability exists because of an incorrect fix for CVE-2016-1547. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4957)
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5300)
<cpaelzer> mdeslaur: there are several more at medium, but well that is why I ask you or other security Team members to let me know
<LocutusOfBorg> I think #ubuntu-hardened is the best place to discuss ntp CVEs :)
<cpaelzer> will do so on top, thanks LocutusOfBorg
<LocutusOfBorg> probably all security Ubuntu folks follow here too, but hardened is better because of low messages numbers
<cpaelzer> yeah I agree, I can leave the message "out there" as long as I test my SRU
<cpaelzer> pitti: filed the nplan bugs and notified a few IBMers that I really want to pass that spec (it is more their than my job after all) :-)
<cpaelzer> pitti: thanks for the feedback
<andyrock> seb128: https://code.launchpad.net/~azzar1/nautilus/higidpi-desktop-view-margins/+merge/301621
<andyrock> i also proposed a fix upstream
<LocutusOfBorg> pitti, hi, do you have two seconds to look at runit package?
<LocutusOfBorg> should we drop the upstart integration?
<LocutusOfBorg> to merge the current debian package I should have to create a new runit-upstart package, and maybe it is time to stop that?
<Laney> andyrock: I can push those upstream if you want
<Son_Goku> what problem does netplan solve that wicked doesn't already solve?
<Son_Goku> https://github.com/openSUSE/wicked
<Odd_Bloke> Son_Goku: My understand of netplan is that it's declarative config that's used to configure existing networking things; I wouldn't expect there to be a daemon running.
<Odd_Bloke> Son_Goku: But I don't know a great deal about netplan. :)
<Son_Goku> wicked works pretty similarly to netplan in that it essentially obsoletes old style configuration
<Son_Goku> but wicked's configuration can be validated, since it's XML
<Son_Goku> but critically, because configuration is offered via D-Bus, you can have an arbitrary input mechanism for it
<Son_Goku> the daemon is completely optional
<Son_Goku> alternatively, NetworkManager itself is an alternative mechanism to old-style networking
<Son_Goku> though I wonder if the reason this is such a problem is because Debian-based distributions' /etc/network/interfaces isn't well-supported in NM
<Son_Goku> NetworkManager can read /etc/sysconfig/network-scripts/ifcfg-* files (which are INI style declarative files) or its own keyfile format
<Son_Goku> in Fedora, for example, NetworkManager is preconfigured through ifcfg scripts
<Son_Goku> err, ifcfg-* files
<Son_Goku> I guess my question is, what problem is netplan trying to solve?
<Son_Goku> that no other solution hasn't already done
<xnox> pitti, see Son_Goku ^ above to discuss netplan vs wicked
<Son_Goku> maybe I'm just used to how things work in Fedora and Mageia, but it seems weird that centralized configuration is a problem
<Son_Goku> admittedly, in Fedora, we use NetworkManager everywhere (even on Server) since recent versions of NetworkManager have become quite lightweight
<Son_Goku> and it supports a large variety of use cases
<Son_Goku> the SUSE guys opted to create wicked to solve their problems, and I think that partially has to do with YaST
<xnox> i think many years ago we did try wicked and connman for the netbook remix project, but that was literarly years ago.
<xnox> on ubuntu side we have our own legacies to deal with =) there is ifupdown, there is networkd, there is networkmanager, and debian is trying for ifupdown2 (non starter for us, as it's in python), and then there is a lot of cloud/container configs.
<Son_Goku> xnox, I think you're thinking of wicd
<Son_Goku> which I do recall you using for Ubuntu Netbook
<xnox> Son_Goku, probably.
<xnox> never mind then =)
<xnox> in general i think we want to go with networkd in most cases, but it's config is crap. And whenever one wants WiFi or 3G/LTE or even hotplug usb one is better off with networkmanager.
<Son_Goku> I'm surprised no one wrote a networkd config backend for NM yet
<Son_Goku> that would allow you to seamlessly use both
<xnox> and then there is a bunch of mid-higher level things to expose too, w.r.t. system containers networking (e.g. lxd / openvz size) and nested networking (juju namespaces)
<Son_Goku> right
<Son_Goku> the latest NetworkManager releases have been focused on dealing with those problems specifically
<Son_Goku> hell, with NM 1.2, I was able to migrate to using NetworkManager to maintain my container networking
<xnox> but networkmanager is well, crap =) -> not official stance, but just my personal opinion. But it is the best we have for Wifi & 3G/LTE.
<Son_Goku> what's wrong with NM?
<Son_Goku> I know people have bitched about NetworkManager in the past, but the latest releases have been pretty solid
<xnox> dhcp / dns, i've been on weird networks where it did not do the right thing, and one ends up shooting oneself in the foot. I'm sure if i used nmcli and/or dbus api to the spawned dhcp daemon I would know what to do. Also it is quite a bit heavy, I had partially booting systems where nm wouldn't start leaving me without network.
<xnox> these days I find iproute2 an excellent network configuration manager =)))))
<xnox> with iproute2 i could finally start to comprehend a little bit as to what is going on =)
<xnox> but i am just a basic user. not a sysadmin at all.
<infinity> Son_Goku: Personally, any time anyone tells me that a config file in XML is a *good* thing, I run away.  And that's coming from someone who finds ISC config files readable.
<Son_Goku> I didn't say it's good for humans
<Son_Goku> and even I don't manipulate the XML by hand myself
<infinity> Then you'd immediately stop the conversation for most old Debian hacks.
<infinity> "run a thing to spit out a config" isn't our style. :P
<infinity> (Same reason people like me also hate virt-manager)
<xnox> i have seen libxml segfault in a stable release =)
<seb128> Laney, if you want to handle nautilus please do
<infinity> Son_Goku: Anyhow, the real answer to your question is that nplan probably doesn't solve a problem that hasn't been solved, it just solves it differently.  Yay, diversity.
<infinity> And my experiences with networking on Fedora/RH have never been pleasant on complex setups...
<Son_Goku> oddly enough, I've had the opposite experience
<infinity> That's how anecdotes go. ;)
<Son_Goku> complex networking using the ifcfg* files has been considerably easier than network/interfaces :)
<infinity> ifcfg looks easier on the surface, but it seems amazingly racey or something, cause I have machines that seem to want to only have a network on 2/3 boots, etc.
<infinity> But that's backend implentation, of course, not the syntax's fault.
<infinity> As for syntax, meh.  We happen to have a man at the helm who loves yaml.
<infinity> Which I'm sure you noticed at the snappy sprint. :P
<Son_Goku> yeah, I did :)
<infinity> Son_Goku: I'm somewhat biased, because I happened to be part of the hallway conversation that became the spec for nplan, but I do like the concept of "this only handles config, and hands off to backends", since placing all your eggs in a networkd or networkmanager basket is just asking for more work down the road to make $daemon support your use-case.
<Son_Goku> yeah
<Son_Goku> well, that's part of the reason why I like the ifcfg-* scripts
<Son_Goku> err files
<Son_Goku> because they are supported by multiple network management tools
<infinity> Yup, but the odds of them ever showing up in a Debian derivative are slim.
<infinity> If pitti can sell Debian on nplan, then we're back to a "half the world does it this way, and the other half another way" thing, and that's not awful.
<Son_Goku> doesn't take much for them to show up
<infinity> (Oddly, that's one of the reasons I wished Debian would have gone with upstart, just to keep competition alive and upstreams on their toes :P)
<infinity> But Debian developers seems blissfully unaware that they (or their derivatives) run on more than half the Linux machines in the world and they have a lot more power than they think.
<infinity> Son_Goku: By "show up", I meant in the default install, of course.  Debian ships all sorts of options, because that's the sort of place they are.
<Son_Goku> well, at least in NetworkManager, it's a configure argument away to support the ifcfg-* files
<infinity> I guess I have to amend that "more than half the Linux machines" with "(not counting Android)" these days.
<Son_Goku> as NM itself supports multiple config backends
<Son_Goku> I don't really see a reason why configuration needs to be done differently everywhere :/
<infinity> Oddly, Android may have finally given us all a reason to call classic distros "GNU/Linux" and RMS wins.
<Son_Goku> especially for something as critical as networking
<infinity> If we assume the "GNU" means glibc. :P
<infinity> Son_Goku: I never saw why it needed to be different everywhere either, but I could never talk RedHat into the beauty of interfaces(5).
<infinity> Son_Goku: And, at the end of the day, that's the attitude we have to contend with that leads to NIH in distros (and it's sometimes a good thing, sometimes not).  Broadly, the RHish and Debianish camps have their own ways to do lots of things, and when someone says "we should all do it the same way", they're really saying "we should all do it the way I prefer".
<infinity> Son_Goku: Which doesn't sell well.
<infinity> Son_Goku: It's the duck army and the bunny army.
 * Son_Goku shrugs
<infinity> http://i.imgur.com/GBxqls0.png
<Son_Goku> infinity, I gave up quite a long time ago on persuading people on things like this
<Son_Goku> nowadays, I just ask about it, present technical counterpoints, and hope for the best
 * infinity nods.
<infinity> Mostly, I just sit here and grumble about having to learn a new thing after 15+ years, but hopefully I'll survive the turmoil.
<Son_Goku> haha
<xnox> infinity, https://lh5.googleusercontent.com/-MV7R08WGNZY/UTIAf39b-3I/AAAAAAAANJo/uLxr73--TRA/w497-h373/gb.gif -> duck/bunny armies playing ingress
<xnox> Son_Goku, infinity: it does sound like we are still in this situation https://xkcd.com/927/
<xnox> caption needs updating with usb-C and thunderbolt
<xnox> infinity, sbuild regular resolver fails to resolve libicu-dev (> 57) when building with experimental enabled (as created with $ mk-sbuild experimental) --build-dep-resolver=aptitude "fixes" this and correctly pulls in libicu from experimental. I recall you have previously said that one doesn't really need aptitude resolver, is there a way to selectively pull build-deps from experimental, when needed, with sbuild using apt resolver? or do i need to
<xnox> fiddle with pinning?
 * xnox believes mk-sbuild should have done the right thing for experimental distro to work with apt resolver
<infinity> xnox: You'd need to pin experimental to 500, but then it won't be selective.
<xnox> In http://aerostitch.github.io/linux_and_unix/debian/sbuild_with_experimental_distribution.html
<infinity> xnox: ie: this is what our buildds do for backports:
<infinity> $ cat etc/apt/preferences.d/backports
<infinity> Package: *
<infinity> Pin: release a=*-backports
<infinity> Pin-Priority: 500
<xnox> it is pinned: 900 -> unstable; 800 -> experimental. I wonder if it makes the build-deps selective or not.
 * xnox ponders if i want selective experimental, or all-in-one / all-you-can eat deal
<xnox> right.
<Mirv> pitti: is it that if I rerun https://requests.ci-train.ubuntu.com/static/britney/ticket-1712/landing-070-yakkety/excuses.html it's again without proposed? could you rerun them all again with proposed? earlier today there was some gtk related breakage in proposed.
<pitti> Mirv: oh, is that gtk3 uninstallability fixed now?
<Mirv> pitti: yes it'd look like that to me, Laney's upload fixed it. among else my https://launchpad.net/ubuntu/+source/uim/1:1.8.6+gh20160630.0.c408e95-1build1 now built.
<pitti> Mirv: yes, the retry links don't use all-proposed
<pitti> Mirv: retried
<Mirv> ok thank you again
<pitti> no problem; /me retries the apport build as well
<LocutusOfBorg> something is broken in yakkety, but I can't figure out what
<LocutusOfBorg> dh: error: 'hardening' flag found but 'hardening-wrapper' not installed: No such file or directory
<LocutusOfBorg> isn't picked up by debhelper?
<infinity> LocutusOfBorg: That's from dpkg, actually.  And not exactly new.
<infinity> Potentially code we should rip out at some point, though.
<LocutusOfBorg> but is a bug in dpkg or not?
<infinity> LocutusOfBorg: It might be a bug, it's not new in yakkety.
<infinity> It comes from when we supported hardening options and Debian didn't.  I should tear that all out, I think.
<infinity> Right after 14.04.5 flies.
<infinity> Or maybe while.
<LocutusOfBorg> BTW anybody will merge dpkg?
<LocutusOfBorg> I can provide a debdiff if I have somebody looking at it :)
<infinity> LocutusOfBorg: I merge it.
* Mirv changed the topic of #ubuntu-devel to: Xenial (16.04.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 precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<LocutusOfBorg> <3
<Mirv> I hope mterry won't mind me ending his 5-day patch pilot
<infinity> LocutusOfBorg: I prefer to let it cook in Debian, unless there's a killer feature we need.
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.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 precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs Mirv 
<mhall119> Mirv: ping
<Mirv> mhall119: eodish pong
 * Mirv hugs the pilot hugger
<mhall119> Mirv: tomorrow then, or when you have time, can you provide some help to #kubuntu-devel in getting packages udpated/added to the archives for 16.10?
<mhall119> they've been really struggling since the Ubuntu Developers on that team left
<Mirv> mhall119: I've uploaded around 120 packages from them, I think they're mostly happy and I'm waiting mostly for them to assess the autopkgtest situation so that they can advice release team..
<Mirv> mhall119: the whole KDE Frameworks 5.24 and Plasma 5.7 is in yakkety-proposed now
<mhall119> Mirv: ah, thank you so much, I hasn't skimmed the scrollback
<Mirv> no problem
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<sil2100> o/
 * Snow-Man wonders where he can buy CDs of those Dave Matthews Band cover band from.
<Snow-Man> s/those/this/
<otto> When will the dmb meeting begin?
<rbasak> otto: it's in #ubuntu-meeting. It's already going. We went past you in the agenda, but we can go round again for you if you can join now please?
<Saviq> pitti, hey, can you please restart all of unity8 tests in https://requests.ci-train.ubuntu.com/static/britney/ticket-1575/landing-073-yakkety/excuses.html with all-proposed, Qt's not migrated still
<pitti> Saviq: done
<Saviq> pitti, thank you
<seb128> cjwatson, hey, unsure if you are still around but I tried to build a snap on launchpad (https://code.launchpad.net/~ubuntu-desktop/+snap/ghex-udt/+build/2261) and the build is failing on "git.gnome.org: Name or service not known", am I doing something wrong?
<dobey> is building snaps allowed to access the internet?
<dannf> jgrimm: i can test that it doesn't crash on arm64, but not sure if that's sufficient to call it "verified". i'll test & leave a comment though.
<kyrofa> dobey, indeed, but only on snapcraft's pull step
<kyrofa> seb128, could that be the issue?
<seb128> kyrofa, dunno, my snapcraft.yaml is normal I think?
<seb128> http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/snapcraft.yaml
<seb128> kyrofa,
<seb128>   ghex:
<seb128>     plugin: autotools
<seb128>     source: git://git.gnome.org/ghex
<kyrofa> seb128, ah, I wonder if the proxy isn't letting git:// through
<kyrofa> seb128, indeed, the yaml looks fine. But that doesn't mean the build system isn't doing something like that (e.g. mysql will download boost when building)
<kyrofa> seb128, but no, the log looks good
<kyrofa> seb128, does git.gnome.org support cloning over http, perhaps? Might try that
<seb128> kyrofa, yeah, I'm going to try that, thanks for the suggestion
<kyrofa> Sure thing
<jgrimm> thanks dannf
#ubuntu-devel 2016-08-02
<pitti> Good morning
<sarnold> good morning pitti :) sure sign that it's time to be done working, hehe
<sarnold> that was a nice networking email, certainly a lot to take in in one go..
<pitti> hey sarnold
<pitti> sarnold: the netplan stuff?
<pitti> infinity: would you mind marking https://launchpad.net/ubuntu/wily as obsolete?
<pitti> cjwatson: ^ I think that's the reason for the ddeb-retriever spam
<infinity> pitti: Not yet.
<infinity> pitti: I'm doing some removals first.
<infinity> pitti: I'll sort it out in the morning.
<pitti> infinity: thanks
<Saviq> pitti, morning, I know I'm becoming a bore, but could you please have a look at autopkgtest results here https://requests.ci-train.ubuntu.com/#/ticket/1575 - it seems some of the runs have disappeared - the two regressions in yakkety need a restart with all-proposed
<pitti> Saviq: done
<Saviq> pitti, thank you, glad it doesn't take you too long - any idea why the disappearing runs?
<pitti> Saviq: might still be bug 1588566 -- this keeps getting pushed down my todo list, sorry
<ubottu> bug 1588566 in Auto Package Testing "autopkgtest results go missing for a long time after the test completes" [Undecided,In progress] https://launchpad.net/bugs/1588566
<Saviq> ack
<tjaalton> did the installer create a separate /boot at some point in the history?
<tjaalton> by default
<pitti> with some scenarios, like lvm or encrypted root
<pitti> or presumably zfs now, as AFAIK you cannot boot from that yet
<tjaalton> seems to work fine :)
<tjaalton> anyway, trying to "argue" with a friend who's pissed because /boot is "always" too small
<tjaalton> when upgrading
<pitti> because we do a bad job at removing old kernels?
<tjaalton> yeah
<pitti> my wife's stock 14.04 install has the same problem, for some reason the auto-removal doesn't work
<pitti> so no size of /boot will ever be large enough for that, the root cause is our kernel inflation
<tjaalton> right
<sarnold> pitti: yeah, netplan :) very ambitious :)
<tjaalton> this is a desktop machine, probably installed with the alternate-installer at some point in the history
<tjaalton> yeah, the installer gives the impression that lvm is more flexible, when in fact it causes issues like this :)
<doko> xnox, please could you merge netcfg (and fix the GCC 6 build issue)?
<doko> coreycb, please could you fix the python-taskflow ftbfs?
<Saviq> pitti, what do we do with missing s390x deps https://requests.ci-train.ubuntu.com/static/britney/ticket-1575/landing-073-yakkety/excuses.html ? Mirv mentioned you discussed this with robru yesterday?
<xnox> Saviq, I thought it should be available, no?
<Saviq> xnox, it's the upstart removal fallout I believe
<xnox> oh, ok. yeah, cause package is available.
<xnox> doko, ack
<pitti> Saviq: I suppose we need to remove ubuntu-system-settings/s390x?
<pitti> Saviq: err, there are no ubuntu-system-settings s390x binaries in Ubuntu
<pitti> I suppose the PPA builds it for some reason
<Saviq> pitti, we might need to, if there's no other way, but that will be a gift that keeps on givin'... don't we have a plan to break this dependency chain somewhere?
<Saviq> pitti, probably because it doesn't have a build-dep on anything that's not on s390x any more...
<rockyh> hi!
<rockyh> I would like to report an apparent mismatch between some outputs in w, who and uptime commands
<rockyh> this is my situation: http://paste.ubuntu.com/21877593/
<pitti> Saviq: but it also was not built in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+packages on s390s
<pitti> Saviq: I think yesterday's problem was that there was some stale s390x binary in some PPA; robru cleaned it up for a different case
<rockyh> both w and uptime indicate 5 users; but w lists just 2 users
<rockyh> and who does the same
<Saviq> pitti, looks built https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6764432/+listing-archive-extra ?
<pitti> not sure what exactly he did
<rockyh> (my system is Xubuntu 14.04)
<rockyh> (the commands give the same results when launched with or without sudo)
<pitti> Saviq: argh yes, I looked at the vivid build, sorry
<Saviq> pitti, so yeah, if it's not in yakkety, can you please remove the PPA build for s390x and I'll work to add a B-D to ubuntu-system-settings to prevent it from building on s390x
<pitti> Saviq: done
<Saviq> pitti, thanks
<pitti> I retried unity8 against all of -proposed in ubuntu several times, doesn't help
<pitti> the qmlui tests keep being broken
<Laney> pitti: that is apparently https://launchpad.net/bugs/1607686
<ubottu> Launchpad bug 1607686 in unity8 (Ubuntu) "testWizard and testShellWithPin crashes on yakkety-proposed with Qt 5.6.1" [High,In progress]
<pitti> Laney: ah, thanks
<Mirv> pitti: yep unity8 should be fixed soon, then I'd just need a word from Kubuntu people that they are ok overriding their remaining failures (functionally no-one has complained about anything, even though people are running it)
<Mirv> it'd be nice to get forward with the proposed migration
<coreycb> doko, sure I'll take a look
<coreycb> doko, I'm not seeing a python-taskflow ftbfs. did you mean python-eventlet?
<doko> coreycb, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160705-gcc6-yakkety.html
<coreycb> doko, gotcha, thanks
<doko> coreycb, but let me retry ...
<coreycb> doko, I just hit the same errors on amd64.  I'll work on fixing that up.
<sveinse> Is this the spot to ask packaing questions? I'm trying to package a cmake based library. However dpkg-gensymbols complains about new symbols appearing, such as "_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED0Ev@Base 2.1.2". I suppose there is a dep missing, and I tried googling it, but without any results. Is this known to anyone here?
<rbasak> sveinse: see dpkg-gensymbols.
<sveinse> rbasak: Yes. I have no clue thou if I can simply add it to the debian/*.symbols file without any side effects. Should I?
<jbicha> pitti: update_excuses stopped updating again
<rockyh> sorry if before I wrote in the middle of another discussion. Now I retry to expose my problem
<rockyh> I am running a Xubuntu 14.04 system. I found some mismatches between the number of "users" printed in the output of "uptime" and the *actual* number of users locally connected to the system
<rockyh> here I pasted the outputs I got: http://paste.ubuntu.com/21877593/
<rockyh> as you can see, both w and uptime indicate that 5 users are connected, but both w and who show just 2 users
<rockyh> and there are actually 2 users: one who made a login from the GUI, and one from ssh
<rockyh> I didn't use nor screen neither tmux
<rockyh> thanks to the help of users in the #ubuntu channel, Ubuntu 16.04 seems to behave in a different way. So I would like to ask: why is there this mismatch?
<rockyh> (I mean that probably in Ubuntu 16.04 both w and who would have correctly shown 5 user logins)
<rockyh> there can be some errors in the implementation of uptime in *ubuntu 14.04?
<Odd_Bloke> rockyh: This is still really a question for #ubuntu; could you re-join there and we can discuss it?
<rockyh> Odd_Bloke: they suggested me to write here
<rockyh> Odd_Bloke: anyway, sure, I just re-joined #ubuntu
<Laney> looks like britney is crashing
<zaytsev> doko: hello, thought i would ask here instead of empty #ubuntu-toolchain -> llvm-3.8 has recently landed in trusty-updates, but it seems that openmp is not in?
<zaytsev> doko: when i try to compile anything with omp.h & -fopenmp it fails, and there is no libomp-dev like in xenial present
<doko> zaytsev, please ask tjaalton about llvm in trusty
<zaytsev> doko: thank you! tjaalton ^^^ any comments? thanks!
<zaytsev> tjaalton: i see in rules you left the following in - --with-clang-default-openmp-runtime=libomp - but libomp hasn't been backported / nowhere to be found :-/
<tjaalton> zaytsev: ok, need to drop that then
<Laney> pitti: did you change anything in britney today?
<zaytsev> tjaalton: means we ain't gonna get omp? fair enough... i'll turn off omp for llvm on our trusty boxes then.
<tjaalton> zaytsev: it's backported only for hwe lts stack (mesa)
<zaytsev> tjaalton: sure, i understand. still.. do you think maybe hadcoding libgomp as a default runtime could work?
<tjaalton> no idea
<LocutusOfBorg> oh britney, why you so sad?
<mterry> Laney, I may have a hack for unity-greeter's prompt box.   Doesn't seem to work for the session chooser, but looking at that next
<Laney> mterry: !!!!
<Laney> hacks are good at this stage
<mterry> Laney, it basically sets the prompt box's "resize_mode", which is a deprecated value.  And if that deprecated value is set, gtk skips the new resize logic patch you linked
<Laney> "might introduce obscure bugs if used"
<Laney> haha
<Laney> so you have to queue a resize yourself manually or something?
<mterry> Laney, no... I'm settingn the resize_mode to "immediate" and it seems to work without other changes
<mterry> Laney, one line hack so far -- but session chooser may be another thing
<pitti> Laney, jbicha: eek, thanks for pointing out; fixed
<pitti> Laney: yes, I did an upstream update to fix the missing architecture build excuses in the HTML
<Laney> pitti: I already fixed it
<Laney> hopefully
<Laney> it's copying stuff now
<Laney> oh, you force pushed over that
<pitti> Laney: sorry, mid-air collision
<Laney> it wasn't mid air - that was pushed and already running
<pitti> I fixed the iteration over block-bugs
<Laney> same
<Laney> oh well
<pitti> it's the one thing we don't test, as we don't have a mock for Launchpad -- I guess it's time to write one
<Laney> suggest pull before push next time
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html just updated
<pitti> Laney: yeah, sorry, that was too quick
<Laney> pitti: you can just supply a Blocks file for testing?
<Laney> pitti: also, can you make the runner script run git reset -q please?
<Laney> ubuntu-archive's mailbox is getting spammed :)
<pitti> sure
<Laney> would do it, but EPERM
<pitti> Laney: done
<Laney> danke!
<Laney> mterry: I filed bug #1608908 earler, btw
<ubottu> bug 1608908 in unity-greeter (Ubuntu) "Some UI elements are invisible with GTK 3.20" [Undecided,New] https://launchpad.net/bugs/1608908
<Laney> nothing new in there, but a place to hang your fixes
<Laney> :)
<mterry> k
<ricotz> doko, hi, please take a look at the patch changes https://paste.debian.net/plain/786589
<pitti> Laney: I did a round of cleaning up on all the armhf and s390x boxes, and refreshed the armhf lxd ones as well; should hopefully hold up until end of next week :)
<pitti> Laney: i. e. on armhf lxc sometimes leaks containers, or lxc-start/lxc-stop gets stuck etc., but it's ok to pile up a few of those
<semiosis> infinity: hello & good morning!  any movement on bug 1605795 since we last spoke?  just checking in :)
<ubottu> bug 1605795 in livecd-rootfs (Ubuntu) "[SRU] livecd-rootfs ubuntu-cpc vagrant image builder" [Undecided,Confirmed] https://launchpad.net/bugs/1605795
<semiosis> Odd_Bloke: ^^
<Laney> pitti: ah, nice - how do you see the lxd stuff?
<Laney> I'm on the controller
 * Laney hasn't used that before
<pitti> Laney: it's autopkgtest-lxd-worker/0
<pitti> Laney: instead of cloud-worker
<Laney> pitti: you just kill the workers in the same way?
<pitti> Laney: yes, other than that they use a remote lxd instead of ssh they are the same
<Laney> ok
<Laney> I thought you were saying you went a poked lxd directly
<pitti> check "lxc remote list" and e. g. "lxc list lxd-armhf-236:
<pitti> Laney: the remotes are still horribly brittle  though, so I don't actually expect this to get much work done
<pitti> Laney: so this is still an experiment
<Laney> but you still have the static lxc ones, so that should be okay
<pitti> right
 * pitti waves good bye, holiday o'clock -- see you all in two weeks!
<Laney> see you pitti, have fun!
<pitti> thanks!
 * pitti disconnects from the hive, argh
<slangasek> infinity, kees, stgraber: TB meeting?
<stgraber> slangasek: thanks for the reminder
<infinity> slangasek: Ungh.  A little timezone challenged this morning.
<mterry> Laney, so...  I have a fix for the prompt & the session list.  But after going into the session list and back out again, there is a tiny visual glitch when switching between users.  I'm inclined to not care about that.  Haven't had luck fixing it yet.  Might just push as-is, especially if gtk3.20 is about to land
<Laney> mterry: That's fine, it sounds small enough to deal with later if necessary
<Laney> thanks a bunch for figuring it out
<mterry> Laney, uploaded in -proposed already
<mterry> you're welcome!  didn't want people to yell at me for a broken unity-greeter  :P
<Laney> GTK's blocked on an MIR and one or two other uploads anyway, but yeah :)
<mterry> working on that MIR right now
 * Laney remembers to subscribe the team
<Laney> I unsubscribed it when I un-MIRed
<jbicha> Laney: did you see that vte is stuck in proposed because pcre2 is in universe?
<jbicha> Laney: but it looks like the dependency isn't even used now https://git.gnome.org/browse/vte/commit/?h=vte-0-44&id=ce94be
<Laney> jbicha: nope
<jbicha> yeah, it builds fine without pcre2
<Laney> I know, it's just new API
<Laney> need to turn it off in gnome-terminal too
<jbicha> Laney: could you do a no-change rebuild of webkit2gtk for gtk 3.20?
<Laney> it's on the list
<Laney> guess I could do it now though
<Laney> jbicha: I did it
<Laney> now before you give me any additional work, goodnight!
<Laney> :)
<jbicha> Laney: see ya :)
#ubuntu-devel 2016-08-03
<xnox> bdmurray, https://news.ycombinator.com/item?id=10262719 ScyllaDB: Drop-in replacement for Cassandra that claims to be 10x faster (scylladb.com)
<xnox> do we need/want that for the whoopsie / daisy stuff?
<xnox> http://blog.octo.com/en/scylladb-vs-cassandra-towards-a-new-myth/
<mwhudson> i don't understand the process for making network config changes via netplan after boot
<mwhudson> you edit files in /etc/netplan, run /lib/netplan/generate... and restart something?
<mwhudson> systemctl try-restart systemd-networkd.service i guess
<mwhudson> slangasek: does this sound right? ^
<slangasek> mwhudson: I was under the impression you didn't need to restart networkd because it would read its config dynamically, but ICBW
<mwhudson> oh ok
<mwhudson> that would seem kinda un-systemd, but certainly useful
<sarnold> it'd suck to coordinate changes to N interfaces that way though; you'd have to stage them all outside the directory and move them in in one go, and hope to hell that you could win the race..
<mwhudson> google suggests that you have to restart it
<Unit193> systemd is not dynamic, you have to manually reload for it to pickup changes to service files.  Chances of it re-reading here would be minimal.
<cpaelzer> good morning
<tjaalton> mardy: ping? is mesa in xenial-proposed now good for arm64?
<tjaalton> mardy: because I need to start another sru asap
<mardy> tjaalton: hi! I'm not sure how to test it...
<mardy> tjaalton: the issue was found when trying to build some package on the citrain
<mardy> tjaalton: I wonder, should I make a citrain request just to test this?
<tjaalton> mardy: perhaps?
<mardy> tjaalton: uh... and how can I tell the citrain to pull from xenial-proposed?
<mardy> sil2100: any idea? ^
<tjaalton> sil2100: speaking of which, xorg-server in xenial needs verification
<ginggs> dholbach: around?
<dholbach> ginggs, yes
<sil2100> mardy: hey! All citrain silos by default use -proposed
<sil2100> tjaalton: ok, I can verify our part there, thanks for the reminder
<tjaalton> sil2100: excellent, thanks
<mardy> sil2100, tjaalton: ok, so I'll prepare a silo to test it
 * LocutusOfBorg just uploaded sbuild in yakkety, lets see how many things broke!
<tjaalton> hum, deleted a preinstalled windows partition and now booting xenial takes 60s extra
<infinity> tjaalton: ... wat?
<tjaalton> well, it's been bugging me for a while on this machine.. uefi, installed ubuntu, deleted (corrupted) win8 install and recovery partitions, and now booting up takes quite a while. there's a 60s timeout somewhere
<seb128> is that partition still listed in fstab?
<tjaalton> tried creating new partitions on them, next I'll put an fs there
<tjaalton> no
<seb128> tjaalton, go to grub, edit boot line to include systemd.debug-shell to the kernel cmdline, boot, ctrl-alt-f9 and systemctl status
<seb128> that should tell you what jos is waiting
<seb128> likely timeouting on a mount unit
<seb128> but unsure where it's coming from if it's not fstab
<tjaalton> ok, thx
<seb128> yw
<seb128> jos->job
<tjaalton> the shell started after lightdm was up
<seb128> tjaalton, the shell?
<tjaalton> debug shell, vt9 was empty until too late
<seb128> like you couldn't go to vt9 during that 1 min hang?
<seb128> weird :-/
<tjaalton> I'll try again
<seb128> tjaalton, try to systemd-analyze blame ?
<ogra_> doesnt that just print "pitti" all the time ? :P
<seb128> good that he's on holidays ;-)
<tjaalton> that's git blame :)
<ogra_> (sometimes "lennart" if it is an upstream issue )
<tjaalton> blame shows apparmor on the top with ~1.5s
<tjaalton> state is degraded, three failed units
<seb128> which ones?
<LocutusOfBorg> mdeslaur hi, willing to sponsor a curl merge?
<LocutusOfBorg> or anybody else
<mdeslaur> LocutusOfBorg: sure
<LocutusOfBorg> thanks, grabbing it now from incoming
<LocutusOfBorg> lots of cve fixes
<LocutusOfBorg> " Drop dependencies not in main:"
<LocutusOfBorg> is that still needed after the universe archive reorg?
 * LocutusOfBorg is not sure anymore
<rbasak> The change is that you can build depend on stuff in universe.
<rbasak> THere is no change to the rules about binary dependencies.
<LocutusOfBorg> so, while I can pull from universe on B-D, I can't runtime-depend on it
<LocutusOfBorg> right?
<rbasak> Right. Though this means that you could split and add a binary package that lives in universe and then depends on stuff in universe. That wasn't possible before.
<LocutusOfBorg> thanks
<LocutusOfBorg> I re-enabled stunnel4, but the openssh removal is still needed
<LocutusOfBorg> mdeslaur, https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/6772977/+listing-archive-extra :)
<LocutusOfBorg> I hope that dsc is ok for you?
<LocutusOfBorg> or mdeslaur there is also an openssl merge FYU
<LocutusOfBorg> FYI
<LocutusOfBorg> https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/6765471/+listing-archive-extra
<tjaalton> seb128: how do I tell?
<tjaalton> systemctl status doesn't show
<tjaalton> ah, just systemctl
<seb128> tjaalton, systemctl list-units --failed
<mdeslaur> LocutusOfBorg: looking at curl now, thanks
<LocutusOfBorg> thanks to you
<tjaalton> seb128: ok, systemd-modules-load.service, the other two were for nfs mounts
<tjaalton> and no wifi before login
<seb128> tjaalton, what does systemctl status -l systemd-modules-load.service says?
<tjaalton> main process exited... failure
<tjaalton> [    9.723679] mei_me 0000:00:16.0: wait hw ready failed
<tjaalton> could be related
<tjaalton> nope
<mdeslaur> LocutusOfBorg: curl uploaded, thanks
<mdeslaur> LocutusOfBorg: I'll take a look at the openssl merge in a few days, I need to get the fips patches tested
<LocutusOfBorg> thanks mdeslaur I admit I'm not 100% sure about it
<LocutusOfBorg> but there is an open merge bug where I explained my worries
<smoser> anyone else seen errors in sbuild environment due to http://stackoverflow.com/questions/6033599/oserror-38-errno-38-with-multiprocessing ?
<smoser> i'm running flake8 (python3 -m flake8)
<smoser> and getting a stack trace due to http://paste.ubuntu.com/22042094/
<smoser> oh. i see.
<smoser> i had /dev/shm commented out because of bug 1438942
<ubottu> bug 1438942 in schroot (Debian) "Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots" [Unknown,New] https://launchpad.net/bugs/1438942
<rharper> hallyn: around ? wanted to chat about SRU for  https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1541902 ; looking at the debdiff.  it's a bump to 2.6 (merge from debian) and then the upstream patch
<ubottu> Error: Could not gather data from Launchpad for bug #1541902 (https://launchpad.net/bugs/1541902). The error has been logged
<hallyn> rharper: sru into xenial?
<rharper> yeah
<rharper> that's where they ultimately want it; so we likely need to push it into yakkety first, and then SRU the bump and merge, right ?
<rharper> this is the GPU stuff for ppc64
<Mirv> I finally have my Chromebook (CYAN) booting yakkety from its internal hard drive. things that don't work are keyboard (need to use external), touchscreen and sound.
<juliank> something is still wrong with apport tests, the new apt upload brought it from failures=1,errors=8 to failures=1,errrors=1 - but I have exactly no idea why the same code works those 7 tests now, but fails in one...
<juliank> Mmh, I should have apport's testsuite fixed now, so APT should go in tomorrow
#ubuntu-devel 2016-08-04
<cpaelzer> good morning
<mardy> Mirv: hi! Do you understand what is the problem here? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-067/yakkety/amd64/u/unity8/20160803_115255@/log.gz
<mardy> sil2100: or do you? ^
<sam_yan> Hi,In ubuntu14.04,which daemon or modules is used to apply the ima(integrity measurement architecture)?
<Mirv> mardy: you'll need to either ask QA to be ok with yakkety failures (assuming xenial/vivid green) or archive admins to rerun yakkety tests with --all-proposed. this should be unneeded possibly later today if/when we get unity8 landing greenlighted, get unity8 autopkgtests to pass and get 200+ source packages to migrate to release pocket
<Mirv> (and if there is still any problem with the landing, I'll beg release team again to let u8 pass so that the big migration can stop annoying people)
<mardy> Mirv: I'm not in a hurry; can you please ping me later, if/when it's time to retry?
<Mirv> mardy: I fear it'll be very late today, if it happens today.
<Mirv> QA has not yet started revalidating the rebuilt silo
<mardy> Mirv: ok, nw, I'll check tomorrow morning then
<Mirv> and autopkgtest + migration infra will take hours
<Mirv> ok
<Guest58264> hi guys
<zokko> why CONFIG_UEVENT_HELPER=y
<zokko> is not enabled in 4.7/
<jtaylor> zokko: there is no 4.7 in ubuntu
<jtaylor> it enabled in 4.4 which we have
<zokko> jtaylor: i'm talking about http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/
<zokko> it's almost ready, but im interested why ueventhelper is disabled?
<jtaylor> ask in #ubuntu-kernel my guess is mainline uses a different configuration than ubuntu
<zokko> in 4.2 it's enabled by default: root@s42260:~# grep UEVENT /boot/config-4.2.0-42-generic
<zokko> CONFIG_UEVENT_HELPER=y
<LocutusOfBorg> can anybody please retry curl/systemd autopkgtestsuite?
<LocutusOfBorg> or better, ignore the test since it seems to be an unrelated issue
<juliank> LocutusOfBorg: I can retry it
<juliank> and I did
<juliank> oh dear, Laney did as well, now it runs twice...
 * juliank is waiting for the apport tests to finally start running on i386 or amd64
<Laney> oh yeah
<Laney> I forgot to say
<Laney> DISASTER!
<Laney> juliank: ah nice, you're fixing apport?
<juliank> Laney: Yeah, I want to get the apt upload migrating now before I sync the new upstream release
<juliank> Laney: It's only test suite bugs
<juliank> The apport test suite is complicated too look at with each test case being run individually
<Laney> mmm
<juliank> I wonder if it could use python-apt's test_all.py script, that imports all test classes and then runs them. Which means you only have one summary at the end of all tests
<juliank> and all errors at the end
<Laney> apport/amd64 looks suspicious
<Laney> ah no
<Laney> it is moving
<juliank> Laney: It had some quota issues in the first try and now tries again
<LocutusOfBorg> but the test is failing since a lot of time (new systemd seems to have broken it)
<LocutusOfBorg> maybe just ignore?
<Laney> no
<Laney> it's being fixed, see above
<LocutusOfBorg> oh you are talking about that, thanks
<Laney> unless you mean the curl one
<LocutusOfBorg> yes, I mean the curl one
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/s/systemd/yakkety/ppc64el/
<LocutusOfBorg> seems that the test broke a while ago
<Laney> meh, pitti force-skiptested it
<LocutusOfBorg> I have wild guessed it too, because systemd migrated already
<LocutusOfBorg> isn't force-skiptest something persistent?
<Laney> not if it gets removed
<LocutusOfBorg> but why, the test is not fixed
<LocutusOfBorg> :(
<Laney> seems like a mistake
<Laney> do you want to file a bug?
<LocutusOfBorg> against systemd?
<Laney> yeah
<LocutusOfBorg> "please fix testsuite" or "please skiptest"?
<Laney> erm
<Laney> I would usually start by assuming the testsuite is finding a real bug
<LocutusOfBorg> "please investigate ppc64el test failure"
<LocutusOfBorg> :)
<Laney> sure
<LocutusOfBorg> but for now can we skip once more and see curl migrate?
<LocutusOfBorg> I would like to have the CVE fixes in
<Laney> curl is in
<LocutusOfBorg> <3
<juliank> If we're lucky, we'll get socks5 proxy support in APT soon, and built-in tor support
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1609740
<ubottu> Launchpad bug 1609740 in systemd (Ubuntu) "please investigate ppc64el networkd-test.py failure" [High,New]
<Laney> LocutusOfBorg: merci
<juliank> apport:i386 passed test!
<juliank> Soon it should pick up amd64 results and migrate
<Laney> aieeeeeeee
<LocutusOfBorg> merci a toi
<LocutusOfBorg> Laney, I was going to assign pitti, but I don't see him here, maybe he is on VAC
<LocutusOfBorg> I'm happy you did it :)
<Laney> email works
<Laney> hopefully
<piet> in what group does a user have to be in order for the LTS-upgrade notification to show up and actually allow to update the system?
<piet> the notification just wreaked havoc in a mid-large ubuntu workstation cluster used by users that should never be able to trigger system-updates
<seb128> LocutusOfBorg, he's on VAC since yesterday yes
<seb128> LocutusOfBorg, you better don't block/count on it and find somebody else
<Laney> It's not blocking anything
<LocutusOfBorg> I actually don't have a real issue
<LocutusOfBorg> exactly
<seb128> k, no need to write emails either then ;-)
<Laney> Launchpad wrote the email
<seb128> but yeah, I was just pointing out he's out
<seb128> no need to be picky on the words I used
<Laney> just saying, nothing to worry about
<seb128> k, well I was not going to worry, I don't even know what you are talking about
<seb128> he asked if pitti was maybe on VAC
<seb128> I replied to that
<seb128> end of the story
<juliank> Laney: It migrated. APT to follow soon, hopefully
<Laney> juliank: Good work!
<Laney> now I can retry the gtk one
<juliank> Laney: Might want to wait a bit until apport binaries have been published
<Laney> yes
<juliank> This was amazing: 4 APT uploads, 1 python-apt, and 2 apport
<juliank> I actually have a apt 1.3~pre2ubuntu5 built too, but I'm going to skip this, as I uploaded a new upstream release containing the stuff which I'll sync then
<Laney> using your new powers for good?
<Laney> + env["APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE"] = "1"
<Laney> lalala
<juliank> Laney: Yeah, there will be a proper deprecation python warning soon
<juliank> or something harsher
<juliank> Laney: I'm giving up for now. I wanted to retry the apport for apt tests now that apport -0ubuntu4 is published, but it still tests against 2.20.3-0ubuntu2 ...
<Laney> juliank: Still not published out
<Laney> juliank: I'm watching rmadison
 * juliank only sees launchpad seeing published since 24 mins
<juliank> But right, rmadison says it's still in -proposed
<Laney> I think Launchpad marks everything at the start of the publisher, but it's not really available to consumers until later on
<Laney> and if rmadison shows then it's definitely available on ftpmaster
<juliank> So annoying...
<Laney> Send a shipment of hamsters to Launchpad HQ
<juliank> Laney: Looking at apt-rpm and thinking about merging that into apt is more annoying, though!
<Laney> you're crazy
<juliank> The initial version being based on 0.5.5 and the latest on 0.5.15
<Laney> bleh
<Laney> juliank: If you see it happen before me, please hit the apport test on gtk too
 * Laney goes to lunch
<juliank> Aye, aye!
<LocutusOfBorg> doko, why not syncing boost-defaults in ubuntu?
<LocutusOfBorg> xnox, ^^
<xnox> LocutusOfBorg, because doko didn't know better =)
<xnox> will fix with my upload
<LocutusOfBorg> <3
<xnox> later, there are fixes to be made.
<LocutusOfBorg> I see some changes in the debdiff
<LocutusOfBorg> a package disappeared
<LocutusOfBorg> and create-boost-defaults-control.py shouldn't point to BoostVersion('1.61.0')?
<juliank> Laney: hitting it now
<juliank> This might take some time ....
<LocutusOfBorg> xnox, FYI, I pinged the maintainers for cufflinks zegrapher deal.ii, they are the only three packages depending on boost1.60 in Debian, I think you might want to remove it, right?
<xnox> LocutusOfBorg, sure, but there is a lot of work to do still to e.g. remove boost1.58
<xnox> it will sort itself out
<LocutusOfBorg> xnox, it is easier to remove 1.60 than 1.58
<LocutusOfBorg> at least in Debian
<LocutusOfBorg> for 1.58 we need the transition to finish
<juliank> Laney: All tests seem to have run now, let's wait and see what the next excuses update says
<ScottK> rbasak: It would be nice if someone would investigate the postfix test regressions in Ubuntu.  I suspect it's more likely issues with the tests than the package, but in either case, I'd be glad to incorporate any needed changes in Debian (the tests have never worked on Debian infrastructure for reasons I haven't figured out, so it's not a 'regression' there).
<juliank> Mmh, I tried SRUing apt/xenial via "syncpackage -V 1.2.14 -r xenial-updates apt" but have not received anything from LP yet. Is -r xenial-updates wrong?
<juliank> It definitely shows the real target version number
<Laney> juliank: xenial-proposed
<Laney> but yes, it did work: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<Laney> You don't get mail for syncs that go to queues, unfortunately
<juliank> Laney: OK. I also tried -proposed, but it showed "current version 1.2.10ubuntu1", not "current version 1.2.12~ubuntu16.04.1" as -updates did. In the end, all probably get remapped anyway, but this seemed safer...
<juliank> Laney: But it's listed in a different pocket than the others :/
<juliank> weird stuff
<Laney> juliank: Yes, it's going to be rejected - I guess the tool doesn't look at -updates first for syncs to -proposed
<Laney> syncing for SRUs is pretty unusual
<Laney> you should re-sync to proposed
<juliank> Laney: Doing so
<juliank> Laney: That's the last sync from Debian. I can do future SRUs via PPA sync as infinity wanted or via direct uploads.
<Laney> 04/08 15:44:14 -queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.12~ubuntu16.04.1 => 1.2.14] (core) (sync)
<Laney> queuebot is smarter than syncpackage
<rbasak> ScottK: I wasn't aware. I'll make a note for us to take a look, thanks.
<ScottK> Thanks.
<rbasak> We're sprinting next week, so I'm not sure if we'll get to it before we're back though.
<rbasak> I'll certainly bring it up.
<ScottK> OK.
<hallyn> rharper: sorry (you didn't call me out and I forgot about this until this morning) - yeah, yakkety has to come first for the qemu sru
<juliank> Laney: The advantage of the PPA being that I can test the stuff more properly before actually uploading it to the archive
<hallyn> rharper: and where is the fix?
<rharper> hallyn: heh, I'm trying to extract just the ddw patches from your deb in the ubuntu-virt ppa
<hallyn> oh, right.
<rharper> the ddw package had a bump to 2.6 + cherry pick
<Laney> juliank: and run the autopkgtests against it, in theory
<juliank> Laney: yep
<rharper> things have moved;  I'm somewhat nervous about bumping qemu from 2.5 to 2.6 in xenial just for DDW
<hallyn> rharper: what do you mean by "thinkgs have moved" ?
<hallyn> s/k//
<rbasak> hallyn, rharper: FYI, I uploaded a minor qemu SRU to the Xenial queue earlier.
<rbasak> (for nacc)
<hallyn> yeah saw the email
<rharper> just the base version of the packages , your patch against 2.5-1ubuntu12 (which isn't in xenial at all), it has a 2.5-1ubuntu10.2
<hallyn> rharper's is a much bigger deal so i think we wait for yours to clear rather than combine them :)
<hallyn> ok, i thought you meant the code has changed a lot.  i've not really compared.
<rharper> no
<rharper> just some rebasing of the patches is needed
<rharper> if you have a pointer to the upstream patchset you cherry picked, then I can just go grab that and look to do the rebase
<hallyn> ok.  it's worth thinking about which we think might be more stable long term, if either
<hallyn> i don't want in 4 months to be asked to upgrade xenial to 2.7 bc of some other feature, that's setting a bad precedent
<rharper> I need to poke the openstack folks, maybe coreycb or jamespage would know if cloud-archive is going to pull in 2.6 or 2.7
<rharper> hallyn: exactly
<rharper> if yakkety is going to get 2.7
<hallyn> bah, that's irrelevant :)
<rharper> then instead of bumping to 2.6 + ddw now
<hallyn> yakkety is a flash in the pan
<rharper> hallyn: my point was around testing
<hallyn> gotcha
<rharper> I'd rather have the same versions under test
<hallyn> there have been a few qmeu-img regressions reported, i can't recall offhand - were those against xenial or yakkety?
<jamespage> rharper, no plans to rev qemu or libvirt in newton UCA unless I have to
<jamespage> i.e. it will be the shipped Xenial release versions by default
<rharper> ok
<rharper> so 2.5 for now
<rharper> hrm =(
<rharper> only this DDW asking for newer bits;  I suspect getting just the DDW fixes for ppc64 won't easily backport to 2.5; hallyn did you look at that or just move up to make the patches import easily /
<hallyn> the latter
<rharper> y
<hallyn> so how badly does someone want these patches in x, and why
<LocutusOfBorg> sad builders?
<rharper> gpu pass-through on power is unusable
<rharper> performance-wise
<rharper> they attempted for FFE for X, but the upstream patches weren't ready
<rharper> didn't land till may IIRC
<hallyn> are the ppl requestiong the feature the ones who did the upstream patch?
<rharper> yeah, IBM
<hallyn> they haven't provided patches against 2.5 for us right?  seems like a reasonable request for us to make
<rharper> yeah
<rharper> heh, well, we can ask
<hallyn> all right so if you want to build+test i'll back yo uup on that, but in my opinion you should simply say "if you want it in x give us a simple, backported patchset for 2.5 as it is in x"
<hallyn> (whether or not you can do that will of course depend on the pressure they're causing for you :)
<hallyn> gotta skeedaddle - ttyl
<rharper> I'll through in the request for patches for now;  given that we don't have anything else yet pushing for 2.6 or 2.7 into X; I'd rather not bump base version in X without good reason (and testing)
<rharper> hallyn: thanks!
<seb128> doko, hey, is there any toolchain or such package that got bigger in yakkety? trying to figure out why the iso is 1.7G now when it was 1.5G in xenial
<doko> seb128, cc1/lto1 are not yet stripped in y
<seb128> doko, would that account for that much difference?
<jbicha> doko: for bug 1609215, I gave you the output of bzr diff but there were file renames which appear to not be applied with patch -p0
<ubottu> bug 1609215 in grilo-plugins (Ubuntu) "Merge grilo-plugins 0.3.2-1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1609215
<doko> jbicha, hmm, usually these should be part of a debdiff?
<jbicha> doko: I don't know, I just pushed a packaging-only branch to https://code.launchpad.net/~jbicha/grilo/update-to-grilo-0.3/ if you want to try that instead
<jbicha> maybe patch doesn't recognize bzr mv so I would have been better off just removing the old file and adding the new one
<bdmurray> cyphermox: is bug 1604499 verified or just not v-failed?
<ubottu> bug 1604499 in grub2-signed (Ubuntu Xenial) "include loopback and squash4 modules in EFI binary" [Undecided,Fix committed] https://launchpad.net/bugs/1604499
<rharper> hallyn: well, yuck;  the ddw device is a property only on machinc type 2.6 for ppc
<doko> jbicha, could you have a look at the freerdp ftbfs?
<cyphermox> bdmurray: fully verified.
<bdmurray> cyphermox: could you add a comment about the verification?
<cyphermox> I thought I did
<cyphermox> ah oops
<cyphermox> bdmurray: done
<rharper> hallyn: so, the ubuntu-machine types patch we carry only -$release values for the x86 pc-i440fx machine type;  if we bring back ddw device into 2.5, then we'd need a pseries-2.5-16.04 (alias to pseries-2.5) and pseries-2.5.16.04.1 (with ddw)
<hallyn> rharper: pseries-specific, <shrug>
<rharper> heh
<rharper> it's not yet a problem due to the number of users doing live migration on ppc64
<hallyn> ugh    "One of the main differences is that all access to your secret key will be handled through gpg-agent, which should be automatically launched as needed.
<rharper> hallyn: the libvirt secrets stuff ? or something else
<hallyn> the new gpg which is becoming the default in debian
<hallyn> (the gpg agent sucks a bit of battery ,and i'm a miser)
<rharper> I see
<bdmurray> nacc: Your qemu upload for LP: #1490611 seems to have been superseded by a security update
<ubottu> Launchpad bug 1490611 in qemu (Ubuntu Xenial) "Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid" [Medium,In progress] https://launchpad.net/bugs/1490611
<nacc> bdmurray: ah ok, i'll review
<rbasak> Ah, just seen this. I commented on the bug thinking that you won't have seen the queue reject email.
<nacc> rbasak: yep, i won't have :)
<nacc> rbasak: bdmurray: updated debdiff just attached
<tvoss> xnox, you around?
<tvoss> xnox, if so: https://launchpad.net/ubuntu/+source/gtest
<tvoss> xnox, sorry: https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/1609989
<ubottu> Launchpad bug 1609989 in gtest (Ubuntu) "Undefined behavior "member call on null pointer of type 'const struct ResultHolder'"" [Critical,New]
<tvoss> xnox, with gcc-6 in y, using gtest/gmock segfaults when mocking functions returning void
<tvoss> xnox, would you be able to take a look at the proposed solutions?
<tvoss> doko, ^
<sarnold> xnox: you ping-timed-out moments after tvoss asked if you could look at https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/1609989
<ubottu> Launchpad bug 1609989 in gtest (Ubuntu) "Undefined behavior "member call on null pointer of type 'const struct ResultHolder'"" [Critical,New]
<sarnold> man there sure are a lot of these "triggers looping" bug reports :( https://bugs.launchpad.net/ubuntu/+source/ca-certificates
<Unit193> Everything is just so loopy. :(
<sarnold> yes :(
#ubuntu-devel 2016-08-05
<xnox> sarnold, thanks my vps with irc bouncer had a hickup
<yellabs-r2> hello , good morning
<yellabs-r2> this is just a quick flyby , i guess its known that zenity is broken on ubuntu 16.04 ?
<yellabs-r2> it spits out an error message : Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
<sarnold> please file bugs, what's obvious to users may not be obvious to us
<yellabs-r2> i think its an debian issue ( or zenity )
<yellabs-r2> there are lots of file bugs ,  and i know your time is precious
<yellabs-r2> you can test and see it yourself
<yellabs-r2> open terminal and type zenity --info ( if you have a ubuntu desktop )
<RAOF> yellabs-r2: That's not actually an error; what is the problem you're seeing?
<sarnold> that's the thing, i, personally, have no idea what zenity -is- :) if you a file a bug, someone who knows what it is might see the bug :)
<yellabs-r2> Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
<yellabs-r2> try zenity --info from terminal ( on ubuntu desktop 16.04 or up )
<yellabs-r2> sarnold , i understand ;)
<RAOF> yellabs-r2: Again, that's not actually an error :)
<Unit193> sarnold: IIRC, makes shiny GUI dialog boxes pretty easily.
<RAOF> yellabs-r2: That's a warning, which is entirely harmless.
<sarnold> Unit193: oh, like whiptail but .. with gtk dialogs :)
<yellabs-r2> its not nice to see , when running a script , can we avoid such warning ?
<RAOF> yellabs-r2: You could patch zenity to not use a GtkDialog.
<yellabs-r2> okey i will do that, thanks for your time
<yellabs-r2> keep up the good work !
<tvoss> xnox, o/
<jtaylor> hm does clang++ work for anyone in xenial?
<jtaylor> it seems to search for stuff in the wrong folders
<juliank> doko: Could APT or qapt (?) be having a tiny ABI break on ppc64el and s390x? I synced apt 1.3~pre4 yesterday, and now the libqapt tests fail with abi-compliance-checker exiting with 6. Ideas?
<juliank> I do see some symbol changes in APT;  but with all the templates involved, that's not out of the ordinary
<doko> juliank, see https://lists.debian.org/debian-release/2016/08/msg00038.html, you probably hit https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00314.html when using template member functions.
<ubottu> gcc.gnu.org bug 2016 in rtl-optimization "-O _AND_ -funroll_all_loops causes segfaults on PPC" [Normal,Resolved: fixed]
<doko> if yes, then please do an abi bump
<juliank> doko: AFAICT from dpkg-gensymbols, there are no missing cxx11 symbols. The only cxx11 mentioned in the negative string is part of __cxx11::basic_string
<doko> juliank, it's not about missing symbols, it's about a missing __cxx11 in some symbols
<Laney> juliank: do you know about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/a/apport/20160805_024013@/log.gz ?
<juliank> doko: Yes, I'm looking at it
<juliank> ehm, Laney
<Laney> <3
<Laney> or â¥ if you prefer
<juliank> Laney: It might be related to Dir::State::Status not being absolute /var/lib/dpkg/status anymore, but being automatically detected dependening on Dir::State
 * juliank wonders how much ~pre4 will break
<juliank> Laney: But on the other hand, the python-apt rootdir option already sets that itself...
<juliank> So I'm a bit confused
<juliank> Laney: Do you have a way to run the apport autopkgtest locally (I have not set up autopkgtest yet, and am basically doing blind test suite fixing ...) - It might be as simple as https://paste.ubuntu.com/22292870/
 * juliank would have run the test directly, but they require root
<juliank> Hmm, it seems I can easily build that test environ
<tsdgeos> guys, i'm getting "GPG error: http://security.ubuntu.com/ubuntu yakkety-security InRelease: At least one invalid signature was encountered."
<tsdgeos> is that known or something?
<tsdgeos> or am i being hijacked in my dns/http traffic?
<Laney> juliank: I usually use "adt-buildvm-ubuntu-cloud -r yakkety" to make a qemuable image you can pass to adt
<Laney> probably pitti would tell me that's the 2014 way of doing it, but he's not here ...
<juliank> Laney: I tried that and it severely hangs my machine :/
<juliank> Let's try again without chrome running...
<juliank> Laney: It seems autopkgtest qemu uses up a lot of space in /tmp, thus leading to memory pressure, as that's a tmpfs
<Laney> does it respect TMPDIR?
<LocutusOfBorg> jtaylor, for some particular projects it is not working
<LocutusOfBorg> you are right
<LocutusOfBorg> but in general, it works
<LocutusOfBorg> and BTW you didn't say version and project
<Laney> I actually used to do that the other way around, set TMPDIR to a tmpfs somewhere else as for me /tmp is not one but I've got enough ram
<Laney> I never checked it didn't leak stuff into /tmp though
<juliank> Laney: It creates some overlay in tmp, I hope I fixed that now
<Laney> you can also use schroot, but not sure if that's good enough for apport
<juliank> Laney: I'm setting up an lxc in parallel
<Laney> mardy: hey... any idea what this "Web Authentication for Google" webview I started getting this morning is about? :)
<Laney> unity7 yakkety
<jtaylor> LocutusOfBorg: I mean a simple file containing only main and including cstdio
<jtaylor> LocutusOfBorg: or finding libstdc++
<jtaylor> though I'm on an upgraded system so the folders might be a bit messier than they should
<LocutusOfBorg> bug clang version?
<LocutusOfBorg> s/bug/but
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1372062
<ubottu> Launchpad bug 1372062 in llvm-toolchain-3.5 (Ubuntu) "Some LLVM 3.5 headers are in wrong paths and different from llvm-3.5 installed from sources." [Undecided,Confirmed]
<Laney> juliank: I've got a VM where it fails if you want access
<jtaylor> LocutusOfBorg: 3.8
<LocutusOfBorg> oh :(
<LocutusOfBorg> from updates?
<jtaylor> yes
<juliank> Laney: autopkgtest works now, setup is a bit annoying, though ...
<Laney> I only did the vm thing, that's easy enough
<mardy> Laney: could be that both the access token and refresh token have expired
<mardy> Laney: if you log in, please pay attention to which app is requesting access in the google webview
<Laney> mardy: I mean that it's just a dialog asking for my credentials, but it doesn't tell me why it wants them
<Laney> you think I should log in?
<mardy> Laney: no, wait
<mardy> Laney: can you reproduce it at will?
<Laney> well, it happened the two times I've logged in today
<Laney> I think I set some environment variables for signon-ui debugging before
<mardy> Laney: can you paste the syslog somewhere?
<Laney> mardy: is 'grep signon' okay?
<Laney> mardy: https://paste.debian.net/787027
<mardy> Laney: should be ok, yes
<mardy> Laney: unfortunately the signond log doesn't tell me much about who the requestor is... do you know of a way to set an environment variable which will be visible to processes auto-started by dbus?
<Laney> mardy: sure, I can stuff something into systemd
<juliank> Laney: I uninstalled libpam-tmpdir and can now run autopkgtests in schroot - much faster than qemu :D
<mardy> Laney: this would help: SSOUI_LOGGING_LEVEL=2
<Laney> mardy: https://paste.ubuntu.com/22298856/ is that more useful?
<mardy> Laney: and you have the same dialog visible?
<Laney> yep
<mardy> Laney: and xkill tells you that's signon-ui? can you also check the pid please?
<Laney> mardy: what process needs that env var
<Laney> ?
<Laney> signond didn't get killed when I logged out so it doesn't have it
<mardy> Laney: signon-ui
<Laney> it's definitely signon-ui
<Laney> and the window's process has the environment variable set
<mardy> Laney: pid 7936?
<Laney> 17220
<mardy> uh
<Laney> not mentioned in syslog at all
<Laney> but that's the pid of signon-ui
<mardy> Laney: do you also have another signon-ui as pid 7936?
<Laney> that's the dbus-daemon
<mardy> ah right
<Laney> aha
<Laney> that makes sense
<juliank> Laney: Fixed in -0ubuntu5
<juliank> Now there's only the weird abi-compliance-checker issue in qapt to be fixed
<juliank> Unfortunately, there is no output at all
<juliank> which makes it hard to debug what exactly it is complaining about...
<doko> juliank, maybe wait for xnox, there are similar issues, e,g, in gnupgpp autopkg tests
<xnox> well acc is easy enough to run by hand.
<juliank> doko: Mmh, OK. AFAICS, it errors out when dumping the ABI, not when comparing it...
<xnox> i guess it should be more verbose.
<juliank> That is, "abi-compliance-checker -q -l libqapt-dev -v1 3.0.2-0ubuntu3 -dump debian/libqapt-dev.acc -dump-path debian/libqapt-dev/usr/lib/s390x-linux-gnu/dh-acc/libqapt-dev_3.0.2-0ubuntu3.abi.tar.gz returned exit code 6"
<Laney> juliank: why the host's status file?
<mardy> Laney: it's very weird, the only request signon-ui gets (grep for queryDialog in the log) is for a web-based authentication, and that's handled opening an oxide webview, not a username/password dialog
<juliank> Laney: Well, the chroot has no status file, and that was the previous default for Dir::State::Status, so it's the obvious fix to return it to old APT defaults where it worked ...
<juliank> Laney: I don't know enough about apport to know why it uses the host status file there, but I guess it does not matter anyway.
<juliank> Laney: Once pitti reappears he can rebuild it however he wants :D
<xnox> tvoss, where are you hitting the issue? as far as i can tell we don't ship gmock in ubuntu archive....
<xnox> and gtest package in ubuntu doessn't gmock
<tvoss> xnox, sorry, it's google-mock and an upgrade this morning brought in a fixed google-mock to y
<tvoss> xnox, sorry for looking into it, let me mark the bug as invalid
<tvoss> the one against gtest that is
<xnox> ah
<xnox> well, it needs changing from gtest to google-mock
<xnox> i'll fix that up
<xnox> everything changed names upstream now
<juliank> xnox: The problem with running acc manually is that it only fails on ppc64el and s390x
<juliank> xnox: ...
<xnox> lol =)
 * xnox shall fix that
<xnox> tvoss, can't fix gtest cause that fails with g++-6, even upstream.
 * xnox should suggest to smr to package googletest as a new source package with new googletest and googlemock combined
<xnox> tvoss, Laney fixed everything already?! =) so i should ignore this
<xnox> tvoss, now i understand what you mean.
<Laney> xnox: wat
<Laney> mardy: it is a webview
<Laney> sorry, I must have forgotten to say that
<Laney> xnox: the maintainer of google-mock emailed me asking if I wanted to become the maintainer after I NMUed it
<Laney> "erm, thanks but no thanks"
<mardy> Laney: ah, ok, then it's called from pid 8346
<Laney> mardy: e-d-s
<mardy> Laney: and if you log in, google should tell you the name of the app authenticating
<xnox> Laney, well google-mock and gtest got merged into googletest upstream, and gtest is maintainer by smr.
<xnox> I'd happy to take the lot into pkg-boost team =)
<Laney> xnox: lalala
<Laney> you go do that
<xnox> and give Fredrik access rights
 * Laney doesn't want to maintain more weird things
 * juliank is also in the process of porting APT from the archaic 1998 build system to cmake ...
<Laney> mardy: so the problem is that e-d-s requesting authentication doesn't tell me that until after I authenticate
<Laney> so I don't know why I'm giving my password
<mardy> Laney: but did it appear out of nowhere? usually these requests get queued and an OSD notification is sent
<Laney> the webview appears when I log in
<Laney> there might be an OSD too, but those are transient
<Laney> I didn't notice
<Laney> and I definitely did see the notifications before, but never this dialog
<Laney> so something changed
<mardy> Laney: anyway it's wrong, this screen should not appear; you should see a notification, then once you open system-settings -> online-accounts, it would tell you that the google account needs authentication
<mardy> Laney: so please file a bug
<Laney> okay
<mardy> Laney: maybe the OSD cannot be sent (maybe the D-Bus service is not up yet?)
<Laney> who wins the bug?
<mardy> Laney: signon-ui
<Laney> signon-ui for now
<Laney> thanks for the help!
<mardy> Laney: the fact that it appears at login also hints that it might be because the OSD is not up yet
<Laney> notify-osd is D-Bus activated
<mardy> mmmm
<Laney> could be that the API call fails or something
<Laney> is the dialog a fallback in that casE?
<mardy> Laney: can you just dismiss that dialog, and see if reappears some minutes later?
<Laney> mardy: in fact it comes back straight away
<Laney> !!!
<mardy> Laney: it makes you feel loved, doesn't it?
<mardy> ;-)
<mardy> Laney: yes, it's a fallback: http://bazaar.launchpad.net/~online-accounts/signon-ui/trunk/view/head:/src/request.cpp#L133
<mardy> Laney: in our case windowId() == 0, so skip those two ifs
<Laney> fun
<Laney> but I don't see "Error dispatching to indicator" in the log
<mardy> Laney: maybe findAccount() fails, line 244
<Laney> mmm
<mardy> Laney: can you please paste the output of "account-console list" and then "account-console show <id of the google account>"?
<mardy> Laney: if you have more than one google account, please show all
<mardy> the value of parameters[SSOUI_KEY_IDENTITY] is 102, according to your logs
<Laney> mardy: ok, I can see which one is 102
<Laney> I should blanke out the ClientSecret right?
<Laney> blank*
<Laney> mardy: bug #1610206 has it all
<ubottu> bug 1610206 in signon-ui (Ubuntu) ""Web authentication for Google" WebView appears on login" [Undecided,New] https://launchpad.net/bugs/1610206
<mardy> Laney: thanks, looking...
<mardy> Laney: weird, the account seems all right...
<mardy> Laney: given that you can reproduce it easily, could you please keep a dbus-monitor running?
<mardy> Laney: if you have the dialog open right now, please just cancel it and let it reappear
<Laney> mardy: oh god it didn't come back
<mardy> Laney: might be that e-d-s retries just once
<Laney> I closed it like 5 times before
<Laney> maybe they had stacked up
<Laney> i'll leave it running and see if it appears
<Laney> going to be a big dbus log
<mardy> ok
<doko> tvoss, is https://launchpad.net/ubuntu/+source/qtgrilo/0.0.20130610-0ubuntu4 still needed, or is this cruft?
<xnox> juliank, doko, Mirv: http://paste.ubuntu.com/22303251/
<juliank> eww
<juliank> that looks nasty
<xnox> hm, why is gcc used, instead of g++
<tvoss> doko, I don't know, Mirv ^
<xnox> gcc or g++ don't make a difference
<xnox> juliank, Mirv - drop, reproducible with just "include <atomic>"
<Mirv> doko: tvoss: I believe qtgrilo is cruft, at least it's not on images. CC: sil2100
<Mirv> and qtgrilo is not surely the only package that should be removed. I have for example bug #1606531 which includes reminders-app, no longer published to archives.
<ubottu> bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531
<Mirv> not familiar with xnox's problem
<doko> Mirv,  sil2100: https://bugs.launchpad.net/ubuntu/+source/qtgrilo/+bug/1610219
<ubottu> Launchpad bug 1610219 in qtgrilo (Ubuntu) "demote qtgrilo, not compatible with grilo-0.3" [Undecided,New]
<doko> Mirv, hmm, I don't see any of these packages in nbs ...
<xnox> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220
<ubottu> Launchpad bug 1610220 in gcc-6 (Ubuntu) "atomic header cannot be compiled into translation unit with -fkeep-inline-functions" [Undecided,New]
<xnox> regression in gcc-6 since gcc 5.4
<Mirv> doko: they are in yakkety-proposed at the moment, the sources like qtquickcontrols-opensource-src and qtdeclarative-opensource-src
<sil2100> grilo grilo, hmm, yeah, need to look into that but I guess it's not a thing anymore
<Laney> zap it
<jbicha> http://reqorts.qa.ubuntu.com/reports/sponsoring/ is up-to-date but the subpages like motu.html are 2 weeks old
<seb128> doko, thanks for sponsoring those totem/rhythmbox updates, do you plan to merge in the vcs as well?
<seb128> slangasek, just a fyi I fixed the samba build on yakkety (and I'm going to backport a bugfix for a gvfs/cpu use issue)
<slangasek> seb128: ok, IIRC I did that merge to un-break the gnutls delta, so do what you need to :)
<seb128> slangasek, the issue was a buggy ldb merge, once that fixed samba builds
<seb128> anyway sorted out
<seb128> I was just letting you know in case you still had it on some todolist
<slangasek> seb128: nope, I summarily deleted all of the lp emails telling me about the build failures caused by people hitting the retry button ;-)
<seb128> hehe
<nacc> bdmurray: as to the phasing of my virt-manager update; afaict, two of the errors are not new in my version (https://errors.ubuntu.com/problem/d742c4e2a061c34261f126539298c430d849d96d and https://errors.ubuntu.com/problem/28048ddac92361b73296c899966474adfef41982). One is new (https://errors.ubuntu.com/problem/00ae98e11d3c5f53ee5e58adb9811d3132176af4), but I'm not sure how my change could lead to that,
<nacc> as functionally it only changes virtinst.
<bdmurray> nacc: okay, looking
<nacc> bdmurray: thanks, I'm reviewing the new one in more depth, but it seems unrelated to me.
<cyphermox> juliank: is there a code branch in LP for the ubuntu diff for apt? or do you just upload directly?
<juliank> cyphermox: There is no apt diff anymore (again), that was just some temporary direct uploads to try to get the autopkgtests working again.
<juliank> cyphermox: I initially only planned one upload, but things got a bit out of control ...
 * juliank hought: oh hey, I pull the tarball and just apply my diffs, and upload; and everything will start working
<nacc> bdmurray: ah and the new report was a fresh install; so may be a false positive?
<juliank> cyphermox: why do you ask?
<bdmurray> nacc: Okay, I've overridden the increased rate so it should continue phasing.
<nacc> bdmurray: thank you very much
<cyphermox> juliank: I'd like to get code review for a change to the apport magic for failed package installs
<cyphermox> juliank: somehow it doesn't feel like it applies to Debian so much
<bdmurray> cyphermox: which magic?
<juliank> cyphermox: I see. Well, we still keep it all in one place
<juliank> cyphermox: Feel free to open a pull request for https://github.com/Debian/apt, https://github.com/julian-klode/apt ; or send a patch
<cyphermox> bdmurray: making sure we can get the proper /var/log/apt/term.log when package installs fail in the uniquity environment
<bdmurray> cyphermox: is that part of apt?
<juliank> I can merge pull requests *really* fast
<cyphermox> yeah, the code that writes the apport report is directly in apt
 * bdmurray rereads package install fails in ubiquity
<juliank> cyphermox: I plan for a new APT release next week (final 1.3 pre-release)
<juliank> That will get a ton of crazy installation ordering changes...
<juliank> Huge potential to reduce issues and improve speed
<juliank> and socks5 proxy support
<juliank> and tor support
<juliank> (not that I did any of those)
<cyphermox> bdmurray: basically, we noticed that some shim-signed failures to install in the live image would include the live session's /var/log/apt/term.log rather than the one in /target... at least that's how things look to me, given that there are important bits missing
<cyphermox> juliank: essentially: http://paste.ubuntu.com/22330893/
<cyphermox> it's very crude :)
<juliank> Yes. very.
<cyphermox> :)
<juliank> cyphermox: But looks OK. Put it in a git commit and push it somewhere/open a pull request/send in an email
<cyphermox> ack
<cyphermox> I'm going to do a bit more testing on it and send you a pull request
<nacc> slangasek: i've gotten some feedback that dep3changelog using 'Closes LP: #' is not correct (that it's intended for Debian bugs only). Given you wrote dep3changelog, do you have a strong opinion?
<slangasek> nacc: feedback from whom?
<nacc> slangasek: rbasak mostly :)
<slangasek> and "intended for Debian bugs only" - what part?
<nacc> slangasek: i think rbasak means that 'Closes' generally is for Debian bugs only? So 'Closes LP: #...' is confusing? Rather than just using 'LP: #...' or '(LP: #...)'
<slangasek> ok
<slangasek> so the only part I think is confusing is that we currently write 'Closes: LP: ####'
<slangasek> the extra colon looks weird
<slangasek> but 'Closes LP: ####' has always been in use, even if not by everyone
<nacc> slangasek: and actually dep3changelog for only a lpbug doesn't insert the extra colon
<slangasek> ah? then I think it all works as intended ;)
<nacc> https://code.launchpad.net/~nacc/ubuntu/+source/qemu/+git/qemu/+merge/300114, the diff comments, is specifically what I mean
<nacc> he's mentioned it a few times elsewhere as well
<nacc> just trying to be correct and consistent
<rbasak> Hmm. I've never seen "Closes: LP:" nor "Closes LP:" used before. But if slangasek says it's normal, then I suppose that's OK :)
<nacc> rbasak: sorry, i should probably have directed that to you -- I was just reviewing what dep3changelog did internally and realized slangasek owned it
<rbasak> I favour tight consistency though. Easier to ramp up newcomers then.
<rbasak> nacc: np. I didn't realise that was coming from a tool.
<nacc> rbasak: agreed. I just think using a tool is the most consistent (to me)
<nacc> rbasak: because now, I don't handwrite my changelog entries from my patches, i just run `dep3changelog` on the patches
<rbasak> Agreed - if it needs fixing, the tool should be fixed. Otherwise using its default output should always be OK. I just didn't know about the tool, and had never seen that style used anywhere else.
<rbasak> I would prefer a single style to be agreed upon as the standard to teach newcomers, and then have every tool use it.
<nacc> 100% agreed
<jbicha> it's more common to omit the Closes for LP bugs
<juliank> What's goingon in -fstack-protector-strong?
<juliank> https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/1608744
<ubottu> Launchpad bug 1608744 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.59-2: ndiswrapper kernel module failed to build" [Undecided,New]
<juliank> stupid copy paste pasted wrong thing ...
<juliank> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
<juliank> gcc: error: unrecognized command line option â-fstack-protector-strongâ
<juliank> Ah, I see. Somehow the system compiles the module for the kernel with gcc 4.8
<juliank> but that's trusty, so it makes sense
<Unit193> In the firefox changelog: remove ebian/patches/webapprt-support-for-langpacks.patch  I was amused. :)
<nacc> rbasak: i wonder if at least part of the solution to LP: #1597414 is to just trust the publishing history unconditionally. If it says the version goes backward, let it, but warn?
<ubottu> Launchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/1597414
<nacc> or maybe we could add a flag?
#ubuntu-devel 2016-08-06
<pkern> Why do we enforce the MOTU/core-dev split on backports?
<ari-tczew> hello
<ari-tczew> can we drop in yakkety the changes such like: "Rename library packages for g++5 ABI transition." ?
<ricotz> happyaron, hi, this gcc-6 problem with sunpinyin might interest you https://paste.debian.net/plain/787187
<happyaron> ricotz: got it
<happyaron> ty
<ricotz> happyaron, alright -- https://launchpadlibrarian.net/277433622/sunpinyin_2.0.3+git20140127-4_2.0.3+git20140127-4+elementary0.5.1.diff.gz
<happyaron> even better, thanks again!
<ScottK> pkern: IIRC because of the way LP permissions work.
<happyaron> ricotz: uploaded to Debian
<pkern> ScottK: It's pretty frustrating. I'm not sure what the proper way would be except subscribing -sponsors and hope. Is there a patch pilot for -sponsors? Or would they just ignore -backports?
<ScottK> They'd probably ignore backports.
<ScottK> I'm really not involved in Ubuntu anymore, so I don't have any suggestions.
#ubuntu-devel 2016-08-07
<juliank> OK, so I'm currently building in launchpad translation support into the apt package (cmake branch) as that was broken for some time.
<juliank> The idea is to create the per-domain POT files in launchpad/${domain}.pot somewhere in the build directory
<juliank> Those are special files just for launchpad: Compared to the normal per-domain POT files, they contain a header (the normal POT files do not as that makes the build unreproducible)
<juliank> Ah, strip-nondeterminism already strips it away for us, so I can just add headers ...
<pkern> ScottK: Could I ask you to sponsor it? ;)
<ScottK> Maybe later, but not now.
<pkern> Laney: Actually you uploaded apache2 to trusty-backports. Fancy sponsoring a security fix for it?
<sveinse> How do I prevent dh_clean from cleaning a directory? That is, the -Xdir/ options does so, but how do I permanently set an option to dh_clean from within the debian/ directory?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1610714 => How to get this into xenial? :)
<ubottu> Launchpad bug 1610714 in poppler (Ubuntu) "Evince crashes with _cairo_gstate_set_dash" [Undecided,New]
<jbicha> dupondje: https://wiki.ubuntu.com/StableReleaseUpdates
<cjwatson> sveinse: debian/clean
<dupondje> ok, added the needed info to https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1610714 :)
<ubottu> Launchpad bug 1610714 in poppler (Ubuntu) "Evince crashes with _cairo_gstate_set_dash" [Undecided,New]
<dupondje> dunno who can give it some love now :)
<sveinse> cjwatson: The docs tells med debian/clean is the exact opposite: it specifies what extra dirs to clean, not what to omit from cleaning, doesn't it?
<cjwatson> sveinse: Er, sorry, yes, brain failure.  In that case there is no way to do what you are asking for; it is usual to just add an override_dh_clean target that runs dh_clean -Xdir/.
#ubuntu-devel 2017-07-31
<ackk> hi, can anyone advise on how to debug this issue: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1697450 ?
<ubottu> Launchpad bug 1697450 in ubiquity (Ubuntu) "Installer freezes at session startup" [Undecided,New]
<ackk> it's actually not an ubiquity-specifc problem
<ackk> *specific
<chipcha> hello at all
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<jbicha> slangasek: should we set python3.6 as the only supported python3 version for artful now?
<slangasek> jbicha: I defer to mwhudson who is managing this transition.  Is there urgency?
<jbicha> mwhudson deferred to you or doko when I asked him :)
<jbicha> no urgency, but I assume we won't be providing python3.5 at all by the time artful is released?
<slangasek> correct
<jbicha> most of python3.5's rdepends now are because it's still 'supported'
<slangasek> "now are" what?
<jbicha> because python3.5 is supported, some packages have dependencies on both python3.5 and python3.6 when they are built
<jbicha> I think that's all of 'reverse-depends src:python3.5' except for a couple packages that FTBFS
<nacc> dannf: are you still working on LP: #1676884 in debian?
<ubottu> Launchpad bug 1676884 in makedumpfile (Ubuntu) "kdump-tools uses the wrong crashkernel command line parameter in ppc64le" [High,New] https://launchpad.net/bugs/1676884
<dannf> nacc: i've proposed a fix for it, but it hasn't been merged yet
<dannf> nacc: at least, the kdump-tools bit
<nacc> dannf: ok, wasn't sure how active you were on it, i just got pinged by the submitter on status
<xnox> juliank, apt without unatteded-upgrades --download-only flag is useless for us. Whilst apt update is happening randomly, the heavy download all the debs is still staggered with upgrade at 6am.
<xnox> juliank, because apt-get --download-only is not the default
<xnox> and --download-only is missing.
<xnox> and --download-only is missing from unattened-upgrades
<juliank> xnox: Yeah, we need to SRU that as well.
<juliank> But then we're done
<xnox> but is it in debian, or ubuntu? i don't see where/when download only mode in unattened upgrade was intorduced.
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863911
<ubottu> Debian bug 863911 in unattended-upgrades "unattended-upgrades: Needs a --download-only mode" [Important,Open]
<juliank> No, it's not, apparently mvo is really busy. I should pick the commits and upload it myself
<juliank> It's in the git
<xnox> is this the only bit that is needed? https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 ?
<xnox> we'd love to keep this minimal, if we must ship it by thursday.
<juliank> No, we also need the test suite fix rbalint made
<xnox> cause e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=863911;filename=unattended-upgrade.diff;msg=5 is reviewable by slangasek / infinity
<xnox> juliank, can you point to where that is? which git repository?
<xnox> or rbasak
<xnox> unping
<xnox> rbasak, unping
<xnox> rbalint, ping ^
<juliank> That's it: https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91 https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6
<juliank> I mentioned these commits a week ago ... ;)
<xnox> good you =)
<juliank> xnox: In any case, it would be good to coordinate with rbalint so we don't end up with conflicting uploads ;)
<juliank> he's working on bug 1690980
<ubottu> bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
<xnox> yeah i know.
<juliank> ok
<juliank> xnox: Apparently mvo tagged a new u-u release (0.94) 3 days ago, but did not upload it.
<juliank> Slightly odd
<rbalint> juliank, xnox: yes, i'm wondering why mvo did not upload it yet
<rbalint> juliank, xnox: bdmurray said he would give u-u another round of tests for LP: #1690980
<ubottu> Launchpad bug 1690980 in OEM Priority Project "unattended-upgrades does not block shutdown of system, as it is designed to" [Critical,Triaged] https://launchpad.net/bugs/1690980
<xnox> juliank, rbalint - i would consider upload /just/ the download-only bits, without the rest of the u-u bits for shutdowns etc.
<cjwatson> stgraber: A week or two ago you posted a buildd-chroot-to-LXD-image conversion script, which has been very useful to me, thanks - I'm attempting to integrate it into launchpad-buildd.  However, I'm running into difficulty because the chroot doesn't have any networking tools, so AFAICS the network is never brought up inside the container and there's no way to do so.  Did you get the chroot to ...
<cjwatson> ... the point of having working networking?
<juliank> xnox: I agree
<rbalint> xnox, juliank: i pinged mvo via email
<stgraber> cjwatson: yeah, I don't believe I did anything with the network in there after I go the script going.
<cjwatson> It's not totally obvious to me what the best way to proceed is :-(
<rbalint> xnox, juliank: i would wait for a few hours
<bdmurray> rbalint: I will do the test soon
<cjwatson> infinity: ^- are you aware of this "make at least some builds use containers rather than chroots" project, and do you have any thoughts about handling it from the chroot management point of view?  It just suddenly got a lot more complicated if we're going to have to munge the chroots in non-trivial ways to make them work as containers.
<rbalint> bdmurray: thanks!
<stgraber> cjwatson: printf "lxc.network.0.ipv4=10.204.119.2/24\nlxc.network.0.ipv4.gateway=10.204.119.1" | lxc config set test-xenial raw.lxc -
<infinity> cjwatson: Err, no.  I'm not aware of this, and why is this happening?
<bdmurray> rbalint: given that the fix for the bug will be SRU'ed can you add the test case we discussed on friday to the bug description?
<cjwatson> infinity: basically in order to be able to use snaps as build-dependencies for other snaps.  get slangasek to fill you in :)
<cjwatson> stgraber: hm, interesting.  how would I pick those addresses?
<infinity> cjwatson: Could someone maybe fix snapd to work in chroots?
<stgraber> cjwatson: that's a bit of a workaround because LXD doesn't usually let you pre-configure the network namespace (as it's very rarely a good idea), but in this case it's probably your best bet short of adding a bunch of stuff to the chroot
<infinity> Sort of a long-standing bug anyway.
<stgraber> cjwatson: just needs to be an address in whatever subnet lxdbr0 is using. You can configure lxdbr0 with a fixed subnet to make that easier
<cjwatson> infinity: that's a pretty big ask
<rbalint> bdmurray: sure
<infinity> cjwatson: So is converting the buildd setup to use containers.
<cjwatson> infinity: I have that mostly done
<cjwatson> apart from this roadblock that I discovered at the eleventh hour
<infinity> cjwatson: It also just leaves a bad taste in my mouth to add even more stuff to build-essential.
<cjwatson> yeah, I'd prefer to avoid that
<infinity> cjwatson: (I mean, not actually build-essential, but "build-cruft")
<infinity> cjwatson: And if you're running in full containers with networking and systemd, that's what you get.
<cjwatson> if stgraber's gadget works then maybe we can still use basically identical root images
<cjwatson> stgraber: heh, "lxd init --auto" in this container apparently gave me an IPv6-only lxdbr0 ...
<slangasek> infinity: running any services in chroots is a no-go in systemd land
<cjwatson> slangasek: the chroots already ship a policy-rc.d that disables nearly everything
<cjwatson> so assuming that works properly in a lxd/systemd context ...
<infinity> It does.
<cjwatson> (that's a slight tangent, but relevant to the question you asked the other day)
<slangasek> cjwatson: yes; my point is that you *can't* run systemd in a chroot, so "make snapd run in a chroot" is very much not a snapd issue
<infinity> slangasek: I suppose I could argue it's a snapd issue for implementing everything it does as systemd jobs, but... :P
<infinity> The very notion that I can't install snaps in a chroot has always rubbed me the wrong way.  Seems like a step backward.
<stgraber> cjwatson: yeah, I'm assuming you're doing all that with LXD 2.0.x rather than the backport (which makes sense). LXD 2.0.x is a bit more annoying to configure due to not having the nice "lxc network XYZ" commands. You likely just want to replace /etc/default/lxd-bridge with some static version of the config, then bounce the lxd-bridge service.
<infinity> cjwatson: Anyhow, if container-based buildds become the new hotness, I might look at further optimising by making the root image a squash instead of a tarball, and we can just mount it instead of unpacking.
<infinity> cjwatson: Though, I suppose we need to keep both methods alive and well or we have some large hurdles for new arch bootstrapping for that inevitable "we never thought we'd have another, but there it is" port.
<cjwatson> infinity: Right, I'm making it switchable
<cjwatson> infinity: Not least because I don't want to change .deb builds (yet, anyway)
<infinity> Actually, I take that back.  I could make a chroot-based sbuild use a squash base trivially too.  So maybe I'll look into that later.
<infinity> (or schroot, given your low prio pending MP)
<cjwatson> infinity: The tarball is useful here because we need to munge it a little bit for LXD.  http://paste.ubuntu.com/25119707/ was stgraber's prototype of this
<infinity> cjwatson: I could be blind, but I'm missing the bit where that changes anything.
<infinity> Oh.  I see.
<infinity> So, the hardlink thing would just go away if it was a filesystem instead of a tarball.
<cjwatson> infinity: metadata insertion too
<infinity> Then you'd just have the metadata thing, which I'd kinda like to hope can live beside an image instead of in it.
<infinity> Cause didn't we have a mandate for a "one true rootfs", it would seem silly for that to have to have LXD stuff in it.
<infinity> But also, we could just build it that way if we had to.
<cjwatson> infinity: and although it's not in that prototype, so far I've in practice needed to insert /etc/{hosts,hostname,resolv.conf} into the image rather than applying it just after starting things up the way we do for chroots (can't do lxc file push until after lxc start, and lxc start does things that look at those files)
<cjwatson> oh wait, actually lxc file push does work as long as I do it after lxc init, never mind that bit
<stgraber> I was about to say :)
<stgraber> infinity: yeah, I'm only stuffing the metadata in the tarball because I needed to repack it anyway
<stgraber> infinity: LXD does support taking two tarballs, one which is the rootfs and another that's the metadata bits, but it needs the rootfs tarball to contain the rootfs at its root (which the build chroots don't)
<infinity> stgraber: Sure, that's fixable.
<infinity> stgraber: Though, as I said, I was tossing around s/tgz/squash/ as an opimisation.
<infinity> optimisation, too.
<infinity> Typing is hard.
<cjwatson> I'd be happy to make launchpad-buildd tolerate either ./ or chroot-autobuild/ if we were planning to change the chroots to match.
<infinity> Yeah, that's a trivial change.
<cjwatson> I'm tearing all that stuff apart and putting it together differently anyway
<infinity> The only reason it's the way it is is Kinnison originally did it that way, and I didn't strip the leading component because I prefer things to not vomit on my FS when I unpack them.
<infinity> Though I did ubuntu-core^Wubuntu-base without a leading path, cause it's The Right Way to do a rootfs.
<cjwatson> (sbuild-launchpad-chroot might want pre-adjustment too, though.)
<cjwatson> Though stgraber's munger doesn't change it to be without a leading path - it changes it to have a leading rootfs/
<cjwatson> Unless that's different in the two-tarball case.
<infinity> Huh, indeed it does.  That's odd.
<infinity> "Guys, you shouldn't hardcode leading paths, cause I hardcode different leading... Oh."
<stgraber> haha, no. LXD either takes a single tarball with metadata and rootfs mixed, in which case the rootfs must be under "rootfs/". Or it takes two tarballs, one with the metadata and the other with the rootfs at its root.
<rbalint> bdmurray: the plan is back-porting the whole u-u package, not just the targeted fix thus there will be a new bug for that
<stgraber> that second format is what we used for the cloud-images for example and what you'd want to use if you want to avoid repacking
<cjwatson> ah right
<bdmurray> rbalint: ah, got it
<infinity> stgraber: Probably a few years late to question the design, but rather than "/metadata and /rootfs/<realstuff>", why not "/<realstuff> and /var/lib/lxd-init/metadata", so it didn't need the leading component?
<stgraber> infinity: that'd be putting a file in the container root filesystem which the container user wouldn't otherwise need to see
<stgraber> infinity: also, some of our images don't have such a thing as /var :)
<infinity> stgraber: Sure.
<infinity> stgraber: /lib/lxc-init/poop then. :P
<infinity> stgraber: But yeah, I get the urge to make it pristine and poop-free.
<infinity> Ever absentmindedly scratch at a limb and, a bit later, look down and realise you're bleeding profusely?
<stgraber> it's also possible that someone would publish an image which contains confidential information in the image metadata that needs to be used by the host when creating the container but shouldn't be visible to the user inside the container
<infinity> Yeah, me neither...
<infinity> (AFK)
<slangasek> infinity the leper
<slangasek> nacc: does LP: #1700826 have your ack on behalf of server team?  dannf raised all the MPs, but I haven't seen an acknowledgement from the server team that this is wanted on server-ship so I'm not merging it with my core-dev hat
<ubottu> Launchpad bug 1700826 in ubuntu-meta (Ubuntu Zesty) "please include numactl on the ubuntu-server iso" [Undecided,In progress] https://launchpad.net/bugs/1700826
<nacc> slangasek: let me double-check with the team tmrw AM
<mwhudson> jbicha, slangasek, doko: the only reason to not de-support python3.5 would be any entanglement with other transitions i guess
<mwhudson> i presume it would be much easier than the "support 3.6" transition
<slangasek> mwhudson: in general, the dropping of python3.5 from python3-all* should not entangle anything else and you just get small self-contained transitions of individual dependency trees as they get rebuilt
<slangasek> and then eventually we sweep up the remainder with some no-change rebuilds so that we can rip out python3.5
<mwhudson> slangasek: so we should aim to do that before feature freeze?
<slangasek> mwhudson: yes - and from my side I know of no blockers for doing it immediately, given that 3.5+3.6 has migrated to artful
<mwhudson> slangasek: ok, sounds like something i can get on with during my intermittent availability
<slangasek> mwhudson: you may want to double-check with doko to be extra-sure there aren't known entanglements I'm overlooking, since gcc is impending
<mwhudson> slangasek: start with the python3-defaults update, then gradually work through the things preventing it migrating?
<mwhudson> slangasek: ok
<slangasek> mwhudson: there should in fact be nothing that prevents it from migrating, IIUC
<mwhudson> oh right yes
<mwhudson> just things preventing us removing python3.5
<slangasek> even things that had a versioned runtime dep on python3-something (<< 3.6) have already been resolved, so yeah
#ubuntu-devel 2017-08-01
<Mirv> tsimonq2: btw if you wondered why there was some unneeded patches not in series files, that happened sometimes since I used a lot of automation like http://pastebin.ubuntu.com/25218283/ which might have added files for the upload that I was actually not committing to git :)
<Mirv> if there was uncommitted cruft locally
<Mirv> tsimonq2: anyway, really nice to see silo 2819! :)
<Mirv> if I had so called free time, I'd start to be really happy to help but life is way too busy these days
<tsimonq2> Mirv: Hey! :)
<tsimonq2> Mirv: Yeah, just waiting on some package removals and we can land it :D
<tsimonq2> I mean, the silo in and of itself *should* be ready to land. It just won't migrate from -proposed...
<Mirv> "just" :D it'll be interesting to see if the migration will need some hinting this time or not. I'll gladly stare at update_output.txt with you.
<Mirv> it's still painful to remember to Qt 5.6 migration
<tsimonq2> hehehehe :)
<tsimonq2> Mirv: yeah it might take some beating into submission to get through :P
<tsimonq2> Mirv: Any suggestions, suggestions, and patches are more than welcome :)
<tsimonq2> That's redundant. :P
<tsimonq2> suggestions, help, patches, that's three words that make sense :P
<Mirv> tsimonq2: from the PPA you're missing AFAIK at least gammaray (qtbase-abi), musescore (qtbase-abi) rebuilds
<Mirv> checked with artful they still have those deps
<tsimonq2> Mirv: Thank you
<tsimonq2> Mirv: Do you still have permissions to copy packages there? I'm not a Core Developer and I've just been poking my usual (Core Developer) victim^Msponsor ;)
<Mirv> tsimonq2: sure, I'm as core developer as before, just with much less time for Ubuntu ;)
<tsimonq2> Mirv: Sure ;)
<Mirv> tsimonq2: both uploaded, gammaray is something that often requires newer upstream version though
<tsimonq2> Mirv: Oh, thanks. :)
<tsimonq2> Mirv: I'm working on an updated telegram-desktop now
<tsimonq2> Mirv: ... so build-essential being uninstallable made those builds fail ... what
<tsimonq2> At least my Telegram build
 * tsimonq2 retries
<tsimonq2> Mirv: gammaray is FTBFS because we forgot to adjust the reverse dependencies for qt3d-assimpsceneio-plugin to the new package name
<tsimonq2> Luckily this was caught early, I'll try to take care of it in my PPA
<Mirv> tsimonq2: ok. I uploaded gammaray ~2 with that fixed. meanwhile musescore has some other problem you should look into at some point.
<Mirv> (gammaray also seems to have another problem)
<tsimonq2> Mirv: Sure.
<tsimonq2> Mirv: Also, thanks :)
<Mirv> you're welcome!
<sil2100> Mirv: \o/
<Mirv> sil2100: o/
<tsimonq2> Could someone from the SRU team please review bug 1641912?
<ubottu> bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912
<sil2100> tsimonq2: I could take a look in some moments
<tsimonq2> sil2100: Thanks :)
<rbalint> xnox, juliank: mvo did not reply but i think sponsoring the tagged u-u 0.94 would be better than another nmu we have to integrate
<xnox> rbalint, 0.94 into debian, or ubuntu, or both?
<juliank> rbalint: The commits needed for the download-only stuff so far are already cherry-picked in artful, zesty, and xenial
<xnox> juliank, however, that is only half of the critical story. we have other clients waiting for the rest of rbalint's fixes.
<juliank> I think mvo probably had a reason not to upload 0.94
<juliank> true
<rbalint> juliank, xnox: maybe he was waiting for test results, maybe he just does not have time
<xnox> ogra, does mvo do irc these days at all?
<xnox> see ^^^^^
<juliank> Well, you can just upload 0.94~ubuntu1 or something in either case and sync 0.94 when mvo uploads it to Debian or whatever
<rbalint> xnox: to debian, then we can sync it
<ogra> xnox, if he is not on vacation (or molten because of the heat) he does, yes
<ogra> (i think the first one is true atm )
<juliank> Just do the ~ubuntu dance for 0.94, I don't think it's particularly nice to just upload it to Debian without mvo knowing
<juliank> It's also a day faster this way
<juliank> :D
<xnox> juliank, checkout https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1707880 i hate dh_systemd_start
<ubottu> Launchpad bug 1707880 in debhelper (Ubuntu Zesty) "newly installed additional units are not started on upgrade" [Undecided,New]
<rbalint> juliank: not for me, i can upload to debian only yet :-\
<juliank> xnox: But that's a more general bug really, then
<juliank> rbalint: Well, but others can :)
<xnox> juliank, sure but i don't see how this can be fixed in dh-systemd itself. unless it injects things into preinst to detect new units that do get installed....
<rbalint> juliank: if someone uploads 0.94~ubuntu1 to artful please note that the fix for LP: #1649709 is not included because i think it is not a bug and not forwarded it upstream
<ubottu> Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically" [Medium,Fix released] https://launchpad.net/bugs/1649709
<xnox> rbalint, what do you mean, it's not a bug?! =)
<rbalint> xnox: i just fixed the description of  LP: #1649709
<ubottu> Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically on development release" [Medium,Fix released] https://launchpad.net/bugs/1649709
<xnox> rbalint, but:
<xnox> / This option will controls whether the development release of Ubuntu will be
<xnox> / upgraded automatically.
<xnox> Unattended-Upgrade::DevRelease "false";
<xnox> it got fixed by setting DevRelease to false, no?
<xnox> (such that unattended upgrades does not upgrade on dev series)
<rbalint> xnox: it is essentially removing u-u
<xnox> yeah....
<xnox> it has a sour taste to it.
<rbalint> so the fix is redundant
<xnox> and dev series, kind of, have to upgrade.
<xnox> i guess we need to reopen that bug, and mark it as won't-fix or opinion, if we are reverting it.
<rbalint> yes, but was waiting for bdmurray to comment first
<infinity> xnox, rbalint: I disagree with both of you, it seems.
<infinity> The claim that "users will get no upgrades" is BS.  update-manager still gives them upgrades.
<infinity> But unattended-upgrades in a devel series, no matter how careful we are, has much more potential for breakage than in a stable series.
<infinity> I suspect most devel series users want to be present, at the console, when upgrades happen.
 * ogra wouldnt mind a present at the console when updates happen :)
<infinity> xnox, rbalint: I could maybe see a halfway argument, where unattended-upgrades on a devel series defaulted to download-only, so that you have seeded your cache when update-manager (or a manual apt-get run) is invoked.
<infinity> Though, even then, with the churn of devel, you might end up downloading twice as many things as you ultimately install.
<xnox> infinity, i believe the bdmurray's fix disables the download of updates as well.
<infinity> xnox: Sure.  Not super relevant, mind you.  Like I said, that "halfway" compromise might be a bad idea anyway.  It's not uncommon under heavy development for the same package to update 4 times in a week.  I don't want to download all 4 just to install the last one if I upgrade weekly.
<infinity> Anyhow, I would contend that daily upgrading the devel series noninteractively is not what most devel users want.  There's a reason people screamed when that bug fix went in and it started happening.
<infinity> And "just remove the package, then" is a cop-out because I don't want to install test devel media and then have to make it non-standard just to get it to not mess with me.
<juliank> xnox: that's true, but I guess it should really detect "new" units and start them
<juliank> Having to add hacks to every package that adds a systemd unit seems weird
<xnox> infinity, and we cannot enable just o=beautiful-security suite, as it does really need o=beautiful and o=beautiful-security.
<infinity> xnox: Yes... And?
<xnox> infinity, or would it work fine for u-a against o=beautiful-security to pull in new deps from o=beutiful?
<xnox> without configuring u-a to install from o=beatiful?
<infinity> xnox: No.  The whole reason this started happening is because we had to add the release pocket to get new deps from security.
<xnox> ack.
<infinity> xnox: I don't think returning to the "yay, devel series upgrades behind your back daily" behaviour is sane.
<infinity> xnox: People disliked it.  A lot.  For very good reasons.
<bdrung_work> rbasak, regarding http://cloud-images.ubuntu.com/daily/streams/v1/ â is this file format documented somewhere? which tools are available for it? I found python-simplestreams, but this doesn't really fit my needs.
<juliank> Or well, I guess try-restart could check if the unit has ever been started, and if not (and it's enabled), start it
<xnox> right, they are not supported either way; and they should dist-upgrade; and it's best they dist-upgrade interactively; and u-a only does upgrade hence for devel it should really not do anything non-interactive.
<rbasak> smoser: ^
<rbasak> bdrung_work: there are CLI tools in simplestreams. What do you need, exactly?
<xnox> juliank, something like that. I guess i need to forward this to debian BTS proper.
<bdrung_work> rbasak, i want to query the stream information and extract the latest cloud images and their download location
<juliank> xnox: But that must have been a problem when we first added apt-daily.timer, and nobody noticed that
<rbasak> bdrung_work: python/python3-simplestreams can do that. In what way does it not fit your needs?
<bdrung_work> so that i can compare the versions with the versions that I have (and an option to download them)
<bdrung_work> rbasak, maybe i haven't found the function. is there some function/class that I can give a url (like http://cloud-images.ubuntu.com/releases/) and get the dict (gpg checked) back?
<smoser> bdrung_work, usquery or image-status at https://github.com/smoser/talk-simplestreams/tree/master/bin are the closest thing to that.  there is also sstream-mirror.
<rbasak> bdrung_work: also  "sstream-query http://cloud-images.ubuntu.com/releases/" does that, so you could start by looking at that implementation.
<bdrung_work> okay. i will look at sstream-query
<rbasak> bdrung_work: some documentation of the data model: http://bazaar.launchpad.net/~simplestreams-dev/simplestreams/trunk/view/head:/doc/README
<bdrung_work> and got a traceback: http://paste.debian.net/979190/
<smoser> bdrung_work, http://paste.ubuntu.com/25219664/
<rbasak> bdrung_work: do you have ubuntu-cloudimage-keyring installed?
<bdrung_work> no
<smoser> right. you need that or need to add the cloud images keyring to your gpg keyring
<bdrung_work> a nicer error message would be nice
<rbasak> Agreed.
<smoser> agreed.
<smoser> bdrung_work, you can also hit it over https and skip gpg if you wanted.
<smoser> sstream-query http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json
<smoser> the client in lxc does metadata over https and data over http if possible falling back to data over https
<juliank> Do we want to keep apt-transport-https for artful? We can either drop it now, or keep it around for a release? If we want to keep it, should (can) we at least move the binary to universe?
 * juliank vaguely recalls some binaries being in different components than their source packages, but not sure if src main and bin universe, other way around, or both
<juliank> Ah it's mentioned as "Binary only demotions to universe" in https://wiki.ubuntu.com/ArchiveAdministration#Component_Mismatches_and_Changing_Overrides
<infinity> juliank: I'd rather see it dropped and have apt Provides/Conflicts/Replaces apt-transport-https for a smooth transition.
<infinity> juliank: I mean, if it's a 100% replacement now.
<elopio> Hello! Can somebody please approve snapcraft in -proposed? I want to finish the testing tonight.
<nacc> slangasek: server team acks LP: #1700826
<ubottu> Launchpad bug 1700826 in ubuntu-meta (Ubuntu Zesty) "please include numactl on the ubuntu-server iso" [Undecided,In progress] https://launchpad.net/bugs/1700826
<nacc> dannf: --^ but with 16.04.3 frozen, it is going to miss that ISO
<slangasek> nacc: will someone on server team also do the merge/
<nacc> slangasek: i can do that today, yeah
<dannf> nacc: ok, thx (and bummer). do you know if it will start appearing in the xenial dailies shortly after 16.04.3?
<nacc> dannf: i don't know --^ that's a good question for infinity / slangasek
<slangasek> nacc, dannf: it would
<dannf> cool, that's probably good enough for my needs. ta!
<elopio> slangasek: sorry, RAOF is not around and I'm not sure who to ping today instead. Can you help us accepting snapcraft to proposed?
<infinity> slangasek, dannf: If you approve and merge that today, I'm not against it magically appearing on the .3 ISOs iff I have a reason to re-spin.  But, if today's images end up being final, obviously you missed the boat.
<infinity> (Well, it would also need a copy-to-updates/pomote-to-main dance)
<slangasek> infinity: ack. Meanwhile, TB meeting?
<slangasek> (you're chair)
<infinity> slangasek: Which is why I was there two minutes ago. :P
<slangasek> but didn't start the meeting ;)
<rbasak> nacc: ^ FYI
<nacc> rbasak: yep, i saw, thanks
<nacc> infinity: good to know, i plan on merging after our meeting, but yeah, will need AA help to copy/promote.
<nacc> slangasek: infinity: fwiw, seeds updated
<nacc> slangasek: still needs the pocket copy & promotion, though
<slangasek> nacc: doing
<nacc> slangasek: thanks!
<nacc> dannf: --^ fyi
<dannf> nacc, slangasek : thanks!
<slangasek> nacc, dannf: done
<nacc> slangasek: excellent, thanks
<slangasek> elopio: looks like me dragging my feet to respond has paid off, and sergiusens_ has gotten apw to look at it now ;P
<apw> slangasek, heh, thanks
<elopio> slangasek: works for me :)
<sergiusens_> slangasek: oh, I didn't mean to do that, I didn't even care to look in #ubuntu-devel and since I didn't see elopio ping anyone on #ubuntu-release and a p w was around I thought I just ping him
<slangasek> sergiusens: hey, it all works out great for me, so... :)
<juliank> infinity: The idea of keeping it is to provide one release cycle of detecting any unknown issues and having a fallback in such a case, really
<juliank> in 6 months we can then say: nobody missed it in the current release, so let's drop it :D
<juliank> The question is: Is it still pulled in by seeds / in main?
<juliank> If so, that should be fixed first
 * juliank does not have an artful chroot atm
<xnox> slangasek, in an unpriviledged container (lxd default) everything appears to have CAP_IPC_LOCK capability, yet it does not work, as mlockall() returns ENOMEM which means - trying to lock more than permitted.
<xnox> thus causing iscsid.service to fail to start.
<xnox> should iscsid.service run in lxd container? should it ignore failure to lock memory in an unpriviledged container?
<xnox> or should the Pre checks check if locking memory actually works?
<sarnold> xnox: btw "unprivileged"  -- fewer 'd's :)
<sarnold> I'd think failure to lock memory would be a warning at worst
<xnox> sarnold, tah. also thanks for an opinion.
<nacc> sarnold: the problem is if iscsid is your root disk
<nacc> sarnold: then getting swapped out might mean you lose your root disk :)
<sarnold> oh, it's client-side thing?
<nacc> sarnold: and i believe the granularity of iscsid is ... not great
<xnox> nacc, not going to be the case for unpriviledged container. and also, what else can it do?
<xnox> sarnold, yes client.
<nacc> xnox: yeah, i agree, it's probably ok to ignore in unpriv. containers
<nacc> xnox: that's just the intention of the code in iscsid (for sarnold's point)
<xnox> so iff we are in a container, and failed to lock memory continue.
<xnox> but do hard fail if we are not in a container.
<xnox> sarnold, is it normal that unpriviledged container has capsh --print things listed in current and bounding set that do not work.
<sarnold> xnox: I don't know containers real well but I think that's the conclusion I've come to before
<xnox> it would make it much easier if the unprivileged containers did not have cap_sys_ipc and cap_sys_audit_read
<nacc> xnox: i assume this is for LP: #1576341 ?
<ubottu> Launchpad bug 1576341 in snapd (Ubuntu) "systemd in degraded state on startup in LXD containers" [Undecided,New] https://launchpad.net/bugs/1576341
<xnox> it would make it much easier if the unprivileged containers did not have cap_sys_ipc_lock and cap_sys_audit_read
<nacc> xnox: yeah, it's confusing as to what is "real" caps and what is not
<xnox> nacc, partially. that one is fixed now with https://github.com/systemd/systemd/pull/6503/files systemd would hard fail on not able to do setpriority()
<xnox> despite having cap_sys_nice
<sarnold> I still think that a warning would be best. "Warning: Don't put swap on iscsi devices due to risk of deadlock." maybe no swap. maybe swap on local disk.
<xnox> but i now have iscsid.service and systemd-journald-audit.socket still to do.
<sarnold> doing something brutal in either of those two cases would be mean.
<nacc> xnox: i thought artful-proposed version of open-iscsi has the fixes
<nacc> xnox: which is stuck due to a test regression (on my todo)
<nacc> xnox: at least, that was my last comment in the bug -- i've not re-tested recently :)
<nacc> xnox: with the fix actually coming from rbalint and incorporated into the most recent merge
<xnox> oooh
<slangasek> xnox: I don't think any service that asks for locked memory should ignore that failure
<xnox> i like that condition in that patch from rbalint
<xnox>  private-users to check whether we are running in a user namespace... hm but that is not true.
<nacc> xnox: yeah, it's pretty clean with that (or at least a bit cleaner than the generic condition)
<xnox> cause e.g. priviledged containers, is still has user namespace, it's just ultimately container root is mapped to host root i think.
<xnox> let me check that.
<xnox> no actually that does the right thing it seems.
<nacc> xnox: yeah, in my testing it seemed to work, but i'll admit to trusting rbalint as well :)
<xnox> # systemctl is-system-running
<xnox> running
<xnox> win =)
<nacc> xnox: nice
<xnox> and https://github.com/systemd/systemd/pull/6508/files
<nacc> xnox: cool, that makes sense based upon the conclusion in the other LP bug (LP: #1457054)
<ubottu> Launchpad bug 1457054 in systemd (Ubuntu Wily) "journal is broken in unprivileged LXC and nspawn containers" [Medium,Fix released] https://launchpad.net/bugs/1457054
<xnox> now i need to figure out why the new system crashes amd64/i386 VMs, and fails to reboot 5 times in a row on s390x.
<infinity> juliank: Keeping it for artful might be reasonable if you'd like people to have a fallback, but I'd like to see the forced P/C/R migration before the 18.04 release then.  If enough data can be gathered to determine it's definitely no longer necessary or useful.
#ubuntu-devel 2017-08-02
<fossfreedom_> hi all - anyone around who can have a look at a couple of patches I'm proposing on behalf of Ubuntu Budgie please? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1703690
<ubottu> Launchpad bug 1703690 in gnome-screensaver (Ubuntu) "Add support for Budgie Desktop using GNOME Screensaver" [Undecided,In progress]
<tsimonq2> sil2100: Hi there, I've fixed bug 1641912, if you could take a look again, that would be wonderful. :)
<ubottu> bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912
<sil2100> tsimonq2: sure thing! Looking much better now, should be able to take care of this in around ~15 minutes
<tsimonq2> sil2100: Excellent :)
<Laibsch> Can a kind soul please help me understand what is going on in bug 991471?  I don't know udisks2 enough and it seems at least I have another disk monitoring daemon running somehow (udev-based?)
<ubottu> bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471
<smoser> bdrung_work, http://paste.ubuntu.com/25226575/ <-- that is probably enough to get you what you're after
<smoser> it doesnt do the download for you, but gets you probably what you're after before downloading.
<bdrung_work> that's a good starting point
<popey> cyphermox or xnox can you help with hanging ubiquity hanging on my laptop while booted from ubuntu 17.10 usb stick to upgrade 16.04 install.
<popey> It seems to have hung during "Removing conflicting operating system files", and isn't doing anything
<popey> http://paste.ubuntu.com/25226720/ - copy and pasted that out of the ubiquity window
<xnox> popey, we don't really support "upgrade with ubiquity" path. But I am assuming you are testing things, and found a bug, which we may be able to fix.
<xnox> currently supported paths are for 16.04 -> 17.04 upgrade + upgrade from 17.04->devel(17.10)
<popey> if we dont support it, we should remove it
<xnox> we will support it from 16.04->18.04
<popey> oh, okay
<popey> i see
<xnox> just not _during_ devel.
<popey> ok, I'll nuke it then.
<xnox> popey, but most likely you found something we will need to fix.
<popey> what debug info do i need to file for the bug report?
<xnox> popey, could you first dump the logs for me?
<popey> sure thing
<xnox> popey, either $ ubuntu-bug ubiquity -> whilst that is running or copy/attach/publish
<xnox> /var/log/* /var/log/installer/*
<xnox> from the live system, and/or the installed system.
<popey> doing
<xnox> tah
<xnox> popey, also that log is very helpful. I'm drowning in the snapd and gtk pointless messages without seeing anything useful *sigh*
<xnox> it smells like a lot of things are emitting loads of warnings, no idea if any are actually relevant / critical.
<xnox> or as in caused the failure you have.
<popey> the "send problem report to the developers" seems to be taking an age
<popey> haha, it's waiting for me, but has a mouse spinner making me think it's busy :)
<popey> lulz
<xnox> popey, we try hard for people to give up submitting bug reports?! =)
<popey> xnox: bug 1708182 - anything you need before I nuke this laptop?
<ubottu> bug 1708182 in ubiquity (Ubuntu) "Ubiquity hung when upgrading to artful from 16.04" [Undecided,New] https://launchpad.net/bugs/1708182
<cyphermox> could this be some upgrade of GLib breaking things hard?
<cyphermox> oh, but no, nevermind
<cyphermox> upgrading from a live CD there should be no reason for whatever happens on the target filesystem to hang ubiquity.
<popey> so it's not hung in the process-locked-up sense, but hung in the its-doing-nothing sense
<cyphermox> ok
<cyphermox> even so, seems to me like it's mostly just a replace-files job (when you simplify things to the spherical cows level) and you're running things in an unaffected environment
<cyphermox> popey: I'll look at your bug later :)
<popey> ok, any more logs you think you mihght need, or does the bug have it all?
<cyphermox> oh, that's interesting
<cyphermox> it's hung much earlier than I expected
<cyphermox> popey: I think it has all I need
<bdmurray> tjaalton: What does this mean? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati-hwe-16.04/+bug/1707884/comments/7
<ubottu> Launchpad bug 1707884 in xserver-xorg-video-ati-hwe-16.04 (Ubuntu) "GTK3 tooltips are corrupted after latest update" [High,Confirmed]
<cyphermox> partman blew up for some reason
<ogra> so not in the in the "grep -q popey /target/etc/passwd && sleep 1000000000" ?
<ogra> :)
<popey> my password is neopi :Ã¾
<ogra> touche !
<popey> cyphermox: ok, thanks. nuke time! :D
 * cyphermox replaces that popey grep with ogra next
<ogra> :P
<nacc> xnox: fyi, i see why the open-iscsi tests are failing, it's actually because of the systemd change (open-iscsi won't start unless it needs to now (condition failed for there being configured iscsi nodes)), working on a fix for it
<nacc> smoser: --^
<bdmurray> tjaalton: I suspect the real problem is you haven't created an apport package hook for xserver-xorg-video-ati-hwe-16.04 this would live in xdiagnose not apport.
<smoser> nacc, cool thank you.
<jbicha> is it ok if I merge base-files from Debian?
<jbicha> I want to get the MPLs in common-licenses and I suppose deriving from buster is more accurate now too
<infinity> jbicha: It's not a trivial merge.  I have it on my TODO for later this week.
<jbicha> ok, thanks
<xnox> stgraber, tyhicks, pitti: https://github.com/systemd/systemd/issues/6519 systemd-journald-audit.socket comes up degraded in the default lxd container on ubuntu. It fails at bind() with EPERM due to apparmor deny from the host. Systemd already does mariad of checks and is sensitive to having audit capability (such lxd container does) and ability to open audit socket (also passes as ok).
<xnox> should something filter out audit capability for the guest?
<xnox> should apparmor deny _opening_ the fd?
<xnox> my naive attempt to add ConditionVirtualization=!private-users -> meaning do not start systemd-jounrnald-audit.socket got reverted upstream, as this is not a user-namespace issue per-se.
<tjaalton> bdmurray: yep, i'll fix that for xenial, and prpbably move the apport stuff from xdiagnose to xorg
<xnox> here systemd checks for EPERM to open a NETLINK_AUDIT socket https://github.com/systemd/systemd/blob/master/src/basic/audit-util.c#L88
<xnox> maybe jdstrand ^^^^^
<stgraber> xnox: so, right now root in an unprivileged container can't access the audit log. But audit namespacing is being worked on and this will eventually work, so dropping the capability or denying it at the apparmor level seems wrong to me.
<xnox> right. but is it reasonable to get EPERM on bind() instead of earlier on fd creation with socket()? what good is an audit socket fd, which one will not be able to bind()?
<stgraber> you'd have to ask whoever wrote the kernel code for that :)
<xnox> ROLF
<xnox> is it kernel that is giving me EPERM, or apparmor. I got the impression it is apparmor.
<xnox> (and I guess /first/ as in without apparmor, kernel would have EPERMed the bind too)
<stgraber> should be the kernel, I don't think we restrict any of the socket stuff for containers
<stgraber> lxc config set container-name raw.lxc lxc.aa_profile=unconfined && lxc restart container-name
<stgraber> that way you won't have apparmor applied at all
<xnox> nspawn does seccomp filter of NETLINK_AUDIT.
<xnox> I have a lot of
<xnox> [2957842.913010] audit: type=1400 audit(1501692226.648:2259): apparmor="DENIED" operation="file_lock" profile="lxd-normal_</var/lib/lxd>" pid=13199 comm="(t-daemon)" family="unix" sock_type="dgram" protocol=0 addr=none
<xnox> but i have no idea if this is related or not.
<xnox> oh, actually red herring - wrong sock_type, no? audit sockets should netlink sock_type or some such?!
<stgraber> hmm, that looks like apparmor being a bit confused indeed, but shouldn't be related since that's family=unix
<xnox> stgraber, hypothetically something unpriviledged could open audit socket, pass it to something priviledged, for the priviledged to bind it.
<xnox> but it sounds so wrong for something priviledged, to be binding something unpriviledged. Sounds like a great backdoor.
<xnox> stgraber, so i'm guessing if i say "please seccomp filter-out audit socket in lxd by default because of this one silly cosmetic issue with one thing?" you will simply say "no?" right?
<xnox> cause i'm inclined to simply carry the patch ConditionVirtualisation=!private-users in the distro for now, to not start audit socket in containers.
<xnox> despite it being rejected upstream.
<stgraber> xnox: yeah, also, liblxc doesn't yet have argument filtering for seccomp, so we'd need to write more code in liblxc, get a new lxc release out, then have that be used in lxd. distro patching the unit seems easier :)
<stgraber> xnox: we could take the approach that people don't need audit in LXD containers and drop the 3 audit caps which would fix it too, but again, once audit namespacing lands, we'd have to revert and then things will work or break depending on your kernel version, so not ideal
<xnox> stgraber, i think there is more to that, as i think when audit namespacing lands, systemd/journald will too need to learn stuff about audit namespaces potentially
<xnox> but the host, can never know if something inside is new or old.
<xnox> meh.
<stgraber> the patchsets I've seen so far wouldn't require any special knowledge from systemd in the container
<stgraber> journald on the host could be extended to know what namespace an audit entry came from too (but not required)
<xnox> ack.
<xnox> so hypothetically 16.04 with hwe kernel from 18.04 things would just work(tm)
<xnox> so ideally I need a check for "i am namespaced, i am not privileged, i have _no_ audit namespace"
<stgraber> assuming it's in the 18.04 kernel, yes. audit namespacing has been going very slowly :)
<xnox> is the audit namespace already known?
<xnox> i guess it will be "audit" subsys_name in cgroups?! right.
<xnox> /proc/cgroups
<stgraber> nope, it's going to be a namespace, not a cgroup
<stgraber> it "may" end up having its own entry in /proc/self/ns/ but right now it looks like it'd just be tied to the user namespace, so the only way to detect support would be to see if you get EPERM
<xnox> le sigh
<stgraber> I don't suppose there's a way to tell systemd to just try to do its thing and if it gets EPERM to give up without considering it a full blown failure? (anything but EPERM should be considered a failure obviously)
<stgraber> that's the logic we have in a bunch of places now (oom adj score, sysctl, ...)
<xnox> for a socket unit, failing to bind, given the whole point of socket activation, sounds like a non-ignorable thing to do.
<xnox> i guess i could exetend the socket.unit with FailBind=ignore
<xnox> or something
<xnox> or I could add a Condition binary that tries to open & bind quickly. and that way condition would fail and the unit will not be started.
<xnox> yeah [Socket] supports ExecStartPre
<xnox> huh, but that would still fail the unit.
<xnox> stgraber, in the kernel it does: if (!capable(CAP_AUDIT_READ)) return -EPERM
 * xnox head desk
<xnox> what's the point of capabilities, if they are declared as being there, yet there is no way to know if they are actually available or not.
<stgraber> xnox: right, capable(CAP_AUDIT_READ) is the same as ns_capable(CAP_AUDIT_READ, 0), so checks against the initial namespace. If the check was done against the container's user namespace, then it would have the capability.
 * xnox ponders if i can move it from audit_bind() to audit_net_init() instead. har har. in the kernel.
<xnox> stgraber, is there a way to test, from userspace, against the initial namespace somehow? systemd reads /proc/self/status and read the CapBnd: off there
<stgraber> hallyn: ^
<xnox> as in test if i do have un-user-namespaced capability or not.
<hallyn> xnox: not exactly.  but you can parse /proc/self/uid_map - if you're not in the initial ns then you have no caps against the initial ns
<hallyn> so if it looks like '0     100000      65536' then you have no global caps
<xnox> and if it lookslike '0 0 4294967295' i do?
<xnox> what does uid_map mean?
<stgraber> xnox: oh and that wouldn't actually help you with the audit namespace as once it's there, you still won't have the cap against the initial ns, it's just that the in-kernel check will now check against your userns cap set rather than init ns cap set
 * xnox will look for documentation on its format.
<hallyn> xnox: right.  uid_map means "container_uid host_uid range",
<hallyn> see 'man subuid'
<xnox> ack thanks.
<hallyn> \o
<xnox> stgraber, i am expecting that kernel will change from capable -> ns_capable when audit namespace is implemented.
<stgraber> xnox: right, which will be entirely invisible from userspace
<stgraber> xnox: except that you will now be able to bind()
<xnox> stgraber, i'm trying to add code in systemd, such that ConditionCapability=CAP_AUDIT_READ at the moment also requires initial ns.
<xnox> stgraber, i'm trying to add code in systemd, such that ConditionCapability=CAP_AUDIT_READ at the moment also requires initial user ns.
<xnox> alternatively, send patch to kernel to _move_ the capable check from bind() to init(), and I believe from reading linux source code should make the EPERM return on socket(), rather than on bind() or connect()
<xnox> hm, yeah doesn't help
<xnox> if i mimic kernel check in systemd, i will not magically get everything working when the kernel changes, sigh.
<xnox> basically systemd should bind, and be done with it.
<jdstrand> xnox: in order to talk to the audit subsystem, you probably need 'network netlink ...'. that log message is a unix socket. I'm not sure what it is connecting to
<jdstrand> probably 'network netlink raw,'
<jdstrand> (that is what useradd needed (it uses libaudit))
<xnox> jdstrand, is there a quick check if there is anything like that, in apparmor denies for unprivileged lxd vs privileged one? at the moment I am assuming that I'm not getting an apparmor deny, and it's simply just the kernel giving me an EPERM upon bind().
<xnox> i will look for useradd profiles, and check lxd profiles.
<xnox> so never mind.
<xnox> (low priority)
<jdstrand> xnox: you should see a denial in the kernel log if it is apparmor. you probably want to sudo sysctl -w kernel.printk_ratelimit=0
<jdstrand> xnox: and the log would be very clear if it is a netlink denial. that said, DAC is evaluated first so if you aren't root (or have sufficient caps) and trying to access NETLINK_AUDIT, then the kernel will give you EPERM. iirc, apparmor normally gives EACCES, but not sure for networking
<jdstrand> so, everything in backscroll suggests DAC, not apparmor
<jdstrand> (well, except the unix denial, which would need to be investigated)
<tyhicks> jdstrand: thanks for taking a look
<xnox> i am on the verge of my comfort zone. but i understand everything that was said so far =)
<xnox> and things match source code of linux/systemd so far. will check apparmor configs etc next.
#ubuntu-devel 2017-08-03
<Unit193> Does Launchpad take into account Built-For-Profiles in the changes field?
<MillenniumB> Is there any way to view only all unassigned blueprints?
<Unit193> Huh, it does.
<Unit193> Oh hrm, log looked like it would, but it doesn't.  OK.
<tsimonq2> Could someone on the SRU team please look at bug 1703307? The verification has been done for 9 days now.
<ubottu> bug 1703307 in lxterminal (Ubuntu Zesty) "[SRU] Unable to rename tabs" [Undecided,Fix committed] https://launchpad.net/bugs/1703307
<CodeMouse92__> I just hit THIS bug: https://bugs.launchpad.net/snapcraft/+bug/1587193
<ubottu> Launchpad bug 1587193 in Snapcraft "build of python3 snap fails with 'error: option --single-version-externally-managed not recognized'" [Undecided,Expired]
<CodeMouse92__> Updated it with more information, can it be taken off of expired?
<sil2100> hm, what powers do I need to have to be able to remove ubuntu-sponsors from the subscribers?
<sil2100> I seem to be an indirect owner of the team but I can't remove it from bugs
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
<tsimonq2> sil2100: Could you please force sync link-grammar for me? :) 5.3.16-2 applies the Ubuntu delta (just adding a dependency).
<tsimonq2> (patch pilot <3)
<sil2100> tsimonq2: looking!
<sil2100> tsimonq2: all good, done
<tsimonq2> sil2100: Thanks :)
<cjwatson> Unit193: Not at present.  (dak doesn't either.)  What would it do with that?
<tsimonq2> sil2100: Could you please take a look at bug 1708392 as well? :)
<ubottu> bug 1708392 in sidplay-libs (Ubuntu) "Merge 2.1.1-15 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1708392
<sil2100> tsimonq2: let me take a look after I'm done with some budgie bits ;) (if I don't forget!)
<tsimonq2> sil2100: Sure, this is why I love patch pilot so much ;)
<Laibsch> Can a kind soul please help me understand what is going on in bug 991471?  I don't know udisks2 enough and it seems at least I have another disk monitoring daemon running somehow (udev-based?)
<ubottu> bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471
<Unit193> cjwatson: So I noticed, though in this regard I was referring to PPAs more than Ubuntu repos, though that certainly could be useful too.  In this case, I was wondering if it'd read the field in *.changes.
<cjwatson> Unit193: I think probably the only thing we could usefully do would be to reject uploads that contain it, but that'd be much more relevant if we allowed binary uploads
<cjwatson> I guess we could parse it out, but I'd be surprised if we ever actually saw it at the moment ...
<sil2100> cjwatson: hey! Do you know by any chance what powers I need to be able to unsubscribe ubuntu-sponsors from bugs?
<infinity> I'd argue that if we see it in an upload, that upload is buggy currently, and it should be rejected.
<infinity> sil2100: You need to be a member of the team.
<sil2100> infinity: I am, it seems
<sil2100> infinity: LP says I 'indirectly own the team'
<infinity> Owner != Member.
<infinity> Confusingly.
<infinity> Though owners can make themselves members. :P
<tsimonq2> This is how we keep the Kubuntu Council and the Kubuntu Ninjas separate with the KC as admins, so it's there for a reason. :P
<tsimonq2> (meaning, I see the use in it)
<tsimonq2> Although I can agree that it's a bit confusing.
<cjwatson> Right, you have to actually be a member.
<infinity> Oh, no, it makes sense to have owners not automatically be members indeed.  Just that it's not "intuitive" to some people that that's the case.
<infinity> But the TB and CC and such certainly shouldn't be members of every team they own, for instance.
<Unit193> infinity: Why would you say that?
<cjwatson> Unit193: Well, profiles are meant to be off by default, and our buildds don't enable them.
<cjwatson> Though I can imagine in future that it might be useful to build a PPA with a particular set of profiles enabled.
<Unit193> cjwatson: Yeah I was thinking that, figured while it might be nice to enable indicators with it, doubt that'd ever get past.
<infinity> Unit193: "enable indicators with it"?
<infinity> Unit193: Build-profiles aren't meant to be Gentoo use flags.
<cjwatson> Profiles are generally more for disabling things than for enabling them.
<Unit193> Indeed.
<Unit193> infinity: Hence the "kind of nice, but of course wouldn't fly" part.  It'd grow out of control pretty quickly.
<infinity> juliank: You around?
<infinity> juliank: Nevermind.  PEBKAC.
<ahasenack> Err:23 http://br.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata
<ahasenack>   Hash Sum mismatch
<ahasenack> should xenial still be getting that type of error? ^
<cjwatson> ahasenack: not in general, but I think br.archive's mirror update procedure must be buggy; it has an InRelease file that lists things that aren't in its by-hash directories, which should be impossible with a proper two-stage sync
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<gaughen> wgrant, have you seen "Thunderpants"?
<wgrant> gaughen: Nope.
<gaughen> damn.
<benpicco> There is no sys/random.h (getrandom()) on Ubuntu 16.04?
<ogra> surely in linux-libc-dev
<rbasak> linux-libc-dev:amd64: /usr/include/linux/random.h
<rbasak> If that's relevant?
<rbasak> See getrandom(2)
<rbasak> That says #include <linux/random.h>
<rbasak> libc6-dev depends on linux-libc-dev
<rbasak> So you should just need libc6-dev (or just build-essential)
<benpicco> linux/random.h doesn't include getrandom() though
<benpicco> only Flags for getrandom(2)
<nacc> mdeslaur: does the apache2 change mean it's likely security won't get to the MIR for nghttp2 this cycle?
<mdeslaur> nacc: I don't know, you need to ask tyhicks
<nacc> mdeslaur: ack
<nacc> tyhicks: --^ :)
<tyhicks> nacc: no, it just allowed mdeslaur to land his security fixes
<nacc> tyhicks: ok, thanks :)
<nacc> tyhicks: just trying to make sure i'm putting the right status out there in the various bugs/trello
<tyhicks> nacc: btw, the mod_http2 page has been updated to indicate that it is now an "extension" and not "experimental"
<tyhicks> nacc: you might want to update the MIR description to reflect that
<nacc> tyhicks: yep, i updated all the relevant bugs, i thought
<nacc> tyhicks: i'll doublecheck
<tyhicks> nacc: the MIR (bug 1687454) isn't clear on that
<ubottu> bug 1687454 in nghttp2 (Ubuntu) "[MIR] nghttp2" [Undecided,Incomplete] https://launchpad.net/bugs/1687454
<nacc> tyhicks: ack, just updated it to be a bit more explicit
<tyhicks> thanks! :)
<xnox> infinity, what i meant, yes ADT simply boots artful cloud image; but the scaling stack compute nodes are running xenial right? with xenial GA kernel and GA openstack / non-cloud-archive openstack?
<xnox> infinity, as in me booting cloudimg adt builder on xenial host, booting artful cloudimage is close enough to scaling stack infra.
<infinity> xnox: Well, sure, but other than potential qemu bugs, that shouldn't really make a difference.
<bdmurray> rbasak: You'd suggested waiting more than 7 days in bug 1700373 but the bug got tagged v-done, should we untag it to avoid a mistake?
<ubottu> bug 1700373 in intel-microcode (Ubuntu Zesty) "intel-microcode is out of date, version 20170707 fixes errata on 6th and 7th generation platforms" [Undecided,Fix committed] https://launchpad.net/bugs/1700373
<rbasak> bdmurray: I wondered that, but I didn't want to get into a battle with people over tags. What do you think in terms of appropriate verification?
<rbasak> bdmurray: IOW, if some other SRU team member took an informed decision to release it, I wouldn't object (but I would expect that person to deal with any fallout).
<smoser> bdmurray, if you're around and sru-teaming, i'd really appreciate a cloud-init review (xenial and zesty)
<fossfreedom> hi jbicha - can you/do you know of someone who could help clarify some issues with my patch request please with gnome-desktop3 and gnome-screensaver?  TIA https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/+bug/1703690
<ubottu> Launchpad bug 1703690 in gnome-screensaver (Ubuntu) "Add support for Budgie Desktop using GNOME Screensaver" [Undecided,In progress]
#ubuntu-devel 2017-08-04
<bdmurray> smoser: I was out for a while but can look now
<bdmurray> smoser: bug 1691489 is missing the SRU template
<ubottu> bug 1691489 in cloud-init (Ubuntu Zesty) "fstab entries written by cloud-config may not be mounted" [Medium,Confirmed] https://launchpad.net/bugs/1691489
<bdmurray> smoser: bug 1701097 is also missing some SRU information
<ubottu> bug 1701097 in cloud-init (Ubuntu Zesty) "eni rendering of ipv6 gateways fails" [Medium,Confirmed] https://launchpad.net/bugs/1701097
<smoser> bdmurray, sorry..  i added the first. i'll get the second tomorrow.
<smoser> :-(
<Bluefoxicy> I've posted an updated version of init-zram-swapping on https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1654777
<ubottu> Launchpad bug 1654777 in zram-config (Ubuntu) "zram-config control by maximum amount of RAM usage" [Undecided,New]
<Bluefoxicy> This should be suitable for use in the installer
<Bluefoxicy> It limits the actual memory usage of zram, rather than just setting a swap size and hoping for the best.
<Bluefoxicy> (also the installer complains if you don't set a swap partition; that should probably not be a thing anymore)
<mwhudson> cjwatson: do we publish buildinfo files for artful anywhere?
<infinity> mwhudson: They're stashed away in the DB, but not exposed anywhere yet.
<cjwatson> Yeah, that.  On the to-do to at least make them downloadable from the web UI
<seb128> cyphermox, hey, do you plan any ubiquity upload? I would like to land https://code.launchpad.net/~seb128/ubiquity/new-gsd-binaries/+merge/327611 . I can handle the upload if nothing else is scheduled though (I'm not familiar with ubiquity uploads though, is there any special process?)
<infinity> seb128: I can merge it for you.  The release process is a bit involved if you work from bzr, but if you're just committing a code change you can cheat by applying it on top of the last source package upload.
<seb128> infinity, that would be great, thanks!
<seb128> bonus if somebody do an ubiquity source upload
<infinity> seb128: I'll just merge and upload, so you don't have to worry about that distinction. :P
<seb128> but I guess that's going to happen at some point anyway ;-)
<seb128> infinity, great, thanks
<infinity> seb128: And done.
<seb128> infinity, and of course it fails to build :-/ I'm going to do a fixup update, line > 79 makes tools sad it seems
<infinity> seb128: Hah, pep8 strikes again.  Yeah, maybe I should have run that before I merged. :P
<infinity> seb128: I assume your intended fix is: http://paste.ubuntu.com/25239648/
<infinity> seb128: If so, feel free to just upload directly, I'll grab the diff and apply it to bzr in your name.
 * infinity goes to get pancakes.
<seb128> infinity, right, thanks
<slashd> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: slashd
<slashd> sil2100 ^
<tsimonq2> Yass, more patch pilots :D
<cyphermox> infinity: I'll fix ubiquity
<infinity> cyphermox: I got the impression seb was going to.
<infinity> cyphermox: Otherwise, I'd have just done it myself. :P
<cyphermox> uploaded an hour ago or so, and fails to build?
<cyphermox> seems like seb is already on it
<infinity> cyphermox: Well, like I said, he claimed he'd upload a fix, and I said I'd commit said fix.  But I see no upload, so maybe I'll JFDI.
<infinity> seb128: ^
<cyphermox> you see no upload?
<seb128> infinity, cyphermox , I was at lunch and I'm in a meeting now, I can have a look after that call but if somebody wants to beat me to it please do
<infinity> seb128: Yeah, I'll just do it.
<seb128> infinity, thanks
<cyphermox> alrighty then
<sil2100> slashd: \o/
<smoser> bdmurray, those bugs have sru templates in them now. sorry for the noise, thank you for the help.
<seb128> infinity, so you do the ubiquity fix or should I have a look?
<infinity> seb128: Oh, I "did" it locally already and ran into an entirely different (and not your fault) problem that cyphermox is looking into.
<seb128> oh ok
<infinity> seb128: Looks like some bitrot exposed by the perl transition.
<seb128> I let it to you then, I'm not going to complain about one less thing to do :-)
<infinity> seb128: So, you'll get a ubiquity when cyphermox fixes console-setup.
<seb128> k
<smoser> tjaalton, if you're around and sru-teaming, i have two requests for review
<smoser> pollinate and cloud-init
<smoser> pollinate should be easy
<smoser> cloud-init  more involved.
<smoser> bdmurray, started cloud-init for me yesterday
<smoser> and slangasek if you were sitting bored, since your backup, i'll ping you too
<slangasek> smoser: roaksoax has already jumped the queue this morning with maas, then when I'm done with that I'll look at how far bdmurray has gotten and see what I can do
<bdmurray> slangasek: I didn't get that far, noticed some incomplete SRU bugs
<smoser> bdmurray, do you clicky clicky  ? or is there somethign that told you that the bugs in changelog did not have an sru template ?
<smoser> ie, i'd like to run something like that so as to not bother people early.
<slangasek> smoser: sru-review opens all the linked bugs in browser; we have talked about having a bot insta-reject uploads that are missing templates, but that's not implemented yet
<bdmurray> smoser: I manually read through the bugs, but sru-review from ubuntu-archive-tools opened all the tabs for me. It might work for you too.
<slangasek> yeah you shouldn't need SRU privs to run sru-review
<slangasek> (only to accept)
<bdmurray> smoser: looking at the cloud-init upload it seems to me like it falls into the new upstream microrelease category. Are there any plans to get request a special case for cloud-init?
<smoser> bdmurray, yes there are.
<smoser> you have a link to that ?
<bdmurray> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
<ricotz> slangasek, hi, could you retry https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4/+build/13149357 ? it build on debian https://buildd.debian.org/status/package.php?p=rustc&suite=unstable so it seems worth another try
<bdmurray> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html
<smoser> yeah... so we do want to get that in there the way we did for curtin
<smoser> but we have not done it due to currently limited automated tests.
<smoser> we're working on automated test improvement
<bdmurray> without a lot of automated tests I think we'd need bugs for things like "sysconfig: fix ipv6 gateway routes [Ryan Harper]"
<bdmurray> The test changes are okay IMO without bugs
<slangasek> ricotz: at least one of the failures is a SIGBUS which is a known difference between the launchpad and Debian builders.  Also in general I'm not going to throw a 24-hour build back at the wall to see if it sticks without a specific reason to believe the result might be different
<ricotz> slangasek, ok, I see, the buildtime was not normal and should take around 5 hours
<slangasek> ricotz: in this case, I have a specific expectation that the build failure will be reproducible because of SIGBUS
<ricotz> slangasek, alright
<slashd> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
#ubuntu-devel 2017-08-05
<tsimonq2> >__> ... <__<   *waits around for patch pilot*
<tsimonq2> Oh, that's right, Saturdays are a thing... *exits left*
<mwhudson> tsimonq2: hey, same nag to you as to LocutusOfBorg about using merge-buildpackage or similar to get the debian changelogs into the changes file (and so into artful-changes mail) when you do merges from debian
<tsimonq2> mwhudson: Could you elaborate?
<tsimonq2> I mean, are you just saying, use merge-buildpackage?
<tsimonq2> Or DON'T use it?
<mwhudson> i'm saying use it
<mwhudson> tsimonq2: https://lists.ubuntu.com/archives/artful-changes/2017-August/007186.html <- this should really include the changelogs you merged debian
<mwhudson> *from
<tsimonq2> Ohh I see.
<tsimonq2> O
<tsimonq2> s/O//
<tsimonq2> I'll keep it in mind for next time, and I'll play around with it. Thanks for the ping, mwhudson!
<mwhudson> tsimonq2: no worries
<mwhudson> tsimonq2: thanks for the work you're doing :)
<tsimonq2> mwhudson: npp :)
<tsimonq2> s/npp/np/ grr, irssi over ssh when there's something uploading :P
<LocutusOfBorg> mwhudson, I started doing it a few days ago
<LocutusOfBorg> maybe the first upload of the day I fail, but I recover :)
<LocutusOfBorg> sorry for that
<mwhudson> LocutusOfBorg: i got told off by doko ages ago, just passing on the nags :)
<LocutusOfBorg> the problem is that I don't use merge-buildpackage, because I sponsor debdiffs
<LocutusOfBorg> so I have to search the latest ubuntu entry, and manually pass it
<tsimonq2> I've *just* started to trust the script
<tsimonq2> It's messed with my merges before :P
<tsimonq2> If it's a complex merge, I'll still use pull-{lp,debian}-source...
<mwhudson> LocutusOfBorg: yeah a lot of this feels like busywork
<mwhudson> tsimonq2: you can always run grab-merge and throw everything away apart from the merge-* scripts :)
<mwhudson> (i have actually done more or less this i think)
<LocutusOfBorg> sometimes it is really easier ^^
<tsimonq2> mwhudson: mhhhh, I don't 100% trust it ever since it made me take an hour on a merge that should have maybe taken 20 mins...
<LocutusOfBorg> but then, why aren't merge-* part of ubuntu-dev-tools?
<tsimonq2> +1,000,000OCOCOCOCOCOCOCOCOCOC
<tsimonq2> What
<tsimonq2> What was that
<tsimonq2> idk
<tsimonq2> :P
<LocutusOfBorg> tsimonq2, should we get musescore fixed before landing, right?
<tsimonq2> LocutusOfBorg: My fix in ppa:tsimonq2/universe-upload-testing *should* fix it, but whatever you'd like to do :)
<tsimonq2> LocutusOfBorg: It's uploading now, 44 MB orig on my "awesome" connection
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-tsimonq2-universe-upload-testing/artful/amd64/p/python-tornado/20170714_125436_b6acb@/log.gz
<LocutusOfBorg> uploading
<LocutusOfBorg> new musescore in debian experimental
<tsimonq2> LocutusOfBorg: That IS the new musescore from Debian Experimental :)
<tsimonq2> LocutusOfBorg: uhm... why python-tornado?
<LocutusOfBorg> because I fail to copy-paste https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-tsimonq2-universe-upload-testing/artful/amd64/r/ruby-httpclient/20170805_071948_1176f@/log.gz
<tsimonq2> LocutusOfBorg: oh ok :P
<tsimonq2> LocutusOfBorg: Awesome, thanks!
<LocutusOfBorg> I'm just swapping the patch order
<LocutusOfBorg> disable-test-proxy-ssl.patch
<LocutusOfBorg> omit-sslv3.diff
<LocutusOfBorg> because I prefer ubuntu patches at the end
<tsimonq2> Sure, wfm.
<tsimonq2> Makes sense.
<LocutusOfBorg> done
<tsimonq2> \o/
<LocutusOfBorg> I think you can delete gvfs/indicator-sound-gtk2/ruby-httpclient from your ppa :)
<tsimonq2> LocutusOfBorg: Good point.
<LocutusOfBorg> also musescore
<tsimonq2> LocutusOfBorg: Oh, copied?
<tsimonq2> Cool :D
<tsimonq2> LocutusOfBorg: uhoh, qtbase is ftbfs >_<
<tsimonq2> LocutusOfBorg: Optional templinst symbols are MISSING... simple fix from what I can tell. I can get you an ubuntu2 upload once everything is built if you'd like?
<LocutusOfBorg> yes
<LocutusOfBorg> tsimonq2, you might want to do it now, it is trivial change, no need to wait
<LocutusOfBorg> specially because it takes a lot of time
<LocutusOfBorg> to build
<tsimonq2> LocutusOfBorg: sure
<tsimonq2> LocutusOfBorg: I mean I'd just like to wait because the last thing I want is for symbosl not specific to s390x or ppc64el to pop up...
<tsimonq2> s/pop up/be MISSING/
<tsimonq2> LocutusOfBorg: The build should be done soon anyways, I'll wait.
<LocutusOfBorg> is this a gcc-7 change as usual?
<tsimonq2> Yep.
<LocutusOfBorg> just one symbol, you lucky
<tsimonq2> Like I said, optional templinst symbols :P
<tsimonq2> LocutusOfBorg: No, more than that?
<LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/13201305
<LocutusOfBorg> amd64 seems an happy arch
<tsimonq2> LocutusOfBorg: I don't think it's at that stage of the build yet :P
<LocutusOfBorg> usually new gcc changes qt stuff in lots of places, just one symbol is a good thing
<LocutusOfBorg> it should be mostly there, couple of min?
<tsimonq2> yep
<LocutusOfBorg> oh... more symbols, just look above
<LocutusOfBorg> :( now I got your answer
<LocutusOfBorg> - (optional|arch=amd64 i386)_ZTV17QOpenGLTimerQuery@Qt_5 5.2.0
<LocutusOfBorg> + (optional)_ZTV17QOpenGLTimerQuery@Qt_5 5.2.0
<tsimonq2> LocutusOfBorg: Should I give you an upload with ubuntu2 or would you like to suggest a different revision?
<LocutusOfBorg> ubuntu2 is fine
<tsimonq2> Ok.
<LocutusOfBorg> does the above mean "previously the symbol was available only on amd64 and i386, now also on ppc64el?
<tsimonq2> It means that the optional symbol was only (optionally, if that word makes sense in this part of the sentence :P) available on amd64 and i386, and now it's on that arch specifically as well
<LocutusOfBorg> ok so I got it correctly
<tsimonq2> Bascially what I'm going to do is download all the completed build logs and use https://pkg-kde.alioth.debian.org/symbolfiles.html to do a full symbols update with the build logs.
<tsimonq2> LocutusOfBorg: yep
<tsimonq2> LocutusOfBorg: Are you quizzing me or are symbols not your strong suit? :)
<tsimonq2> (maybe not "not your strong suit" but rather a lack of understanding in this case)
<LocutusOfBorg> I hate symbols and c++ when mixed together
<tsimonq2> Fair. :)
<LocutusOfBorg> I see qt folks uploads, reuploads, reuploads again the same, each time collecting symbols from build logs
<LocutusOfBorg> I don't honestly see the point of having all this stuff done, but probably it is needed
<tsimonq2> LocutusOfBorg: lisandro and mitya57 have taught me a lot about symbols and dealing with them. :)
<tsimonq2> Yep, I see the need for it.
<LocutusOfBorg> but optional symbols are optional
<LocutusOfBorg> many times they are private
<LocutusOfBorg> anyway, I trust you
<tsimonq2> :)
<LocutusOfBorg> yeah, amd64 has been uploaded
<LocutusOfBorg> so, the symbols in amd64-i386 didn't change, but got extended to at least ppc64el and 3s90x
<tsimonq2> mmmh, armhf and arm64 have been sloooooow.
<tsimonq2> LocutusOfBorg: I think so.
<LocutusOfBorg> gl stuff in arm* is different, better wait indeed
<tsimonq2> LocutusOfBorg: looks like musescore builds fine now :D
<LocutusOfBorg> yep this is why I copied it
<tsimonq2> ok
<LocutusOfBorg> and haskell finally migrated
<LocutusOfBorg> hurray
<tsimonq2> \o/
<tsimonq2> :D
<tsimonq2> LocutusOfBorg: now time for Perl :P
<LocutusOfBorg> some perl is migrating now
<LocutusOfBorg> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+build/13201307
<tsimonq2> Yep, keeping my eye on it :)
<LocutusOfBorg> so, arm is fine
<LocutusOfBorg> only ppc64el and s390x needs fixes
<tsimonq2> Well I think it's calling it a bit early.
<tsimonq2> LocutusOfBorg: mhhh, it should be good.
<LocutusOfBorg> push?
<tsimonq2> LocutusOfBorg: Working on it now
<tsimonq2> LocutusOfBorg: I think it would be much easier if you could clone the Git repo, and I can just push it there ;)
<tsimonq2> LocutusOfBorg: https://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu%2b1
<LocutusOfBorg> I can take the commit and download the patch
<tsimonq2> sure
<tsimonq2> working on it
<tsimonq2> LocutusOfBorg: pushed
<LocutusOfBorg> .
<tsimonq2> LocutusOfBorg: in an hour I'll be leaving to work and I'll be back in 4.5 hours, so if that builds with no problems, I'm +1 on landing it. :)
<tsimonq2> LocutusOfBorg: Thanks!
<LocutusOfBorg> thanks to you
<LocutusOfBorg> if it builds I push the button
<tsimonq2> bueno :)
<LocutusOfBorg> merge done, lets see if it builds
<tsimonq2> LocutusOfBorg: gtk+2.0?
<LocutusOfBorg> yep
<tsimonq2> ack
<tsimonq2> LocutusOfBorg: what magical wizardry did you conjure up to get that freaking thing to work? :P
<LocutusOfBorg> tsimonq2, just rebase some bites of the patch
<tsimonq2> LocutusOfBorg: Ah ok
<LocutusOfBorg> *bits
<LocutusOfBorg> anybody debhelper-perl-savvy here?
<LocutusOfBorg> jbicha, gthumb merge?
<jbicha> LocutusOfBorg: you can do it if you want :)
<LocutusOfBorg> please don't ask me :D I don't want to touch it if possible
 * LocutusOfBorg leaves
<jbicha> ok, someone will get around to it eventually
<tsimonq2> jbicha: dibs
<doko> TheMuso: please could you have a look at the brltty ftbfs, and maybe merge from experimental?
#ubuntu-devel 2017-08-06
<doko> stgraber: please have a look at https://launchpad.net/ubuntu/+source/lxc/2.0.8-0ubuntu4
<stgraber> doko: that's a compiler bug
<stgraber> doko: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
<ubottu> gcc.gnu.org bug 78969 in tree-optimization "bogus snprintf truncation warning due to missing range info" [Normal,New]
<doko> stgraber: ta. please can you work around it for now?
<tsimonq2> Does the SRU team do stuff on weekends? There's two things I'd really really like reviewed but I don't know if the SRU does stuff today :)
<Unit193> LocutusOfBorg: Can you sync ruby-specinfra and retry it with proposed ruby-net-ssh when LP picks it up?
<Unit193> In theory, 'serverspec-runner' will pass tests with newer -specinfra.
<LocutusOfBorg> mostly uploaded
<LocutusOfBorg> will be autosyncd
<LocutusOfBorg> Unit193, lets see
<LocutusOfBorg> Unit193, serverspec fixed
<LocutusOfBorg> thanks
<Unit193> Thanks.
<Unit193> I know you're no longer here, but just chef holding ruby-net-ssh back in proposed, either just a bump to allow newer, or the bump and https://github.com/chef/chef/pull/5726/commits/24d230b09a68c8b6857d060b398e779a23ba80bc would fix it.
#ubuntu-devel 2018-07-30
<Unit193> doko: Ah, cool.
<Unit193> (I'd contacted the Debian maintainer a little bit ago with git based updates for 1.1.7)
<infinity> wxl: No idea.  The process is a bit of a black hole after it's sent off to mark. :P
<wxl> infinity: oh, yeah, right. let me check in with him. meanwhile, what's the d-day given current expirations dates?
<infinity> wxl: We expire in 5 days,
<wxl> infinity: you've got another week
<doko> well designed version numnbers ... 1.7.0~alpha2ubuntu2+really1.6.2ubuntu1
<juliank> doko: yes
<realitix> Hello, a patch has been submitted upstream for this bug, I would like to know when it will be available in ubuntu 14.04, is there a place to see that ?
<realitix> https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1778930
<ubottu> Launchpad bug 1778930 in openjdk-7 (Ubuntu) "JVM crash with SIGSEGV as tomcat start with 7u181" [Undecided,Incomplete]
<LocutusOfBorg> realitix, https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<LocutusOfBorg> please fill the data
<ahasenack> realitix: the bug is the right place. I'm a little confused with the proliferation of java machines nowadays, though. Is the bug in openjdk or icedtea? Both? The patch is for icedtea, right?
<realitix> ahasenack: yes the bug is in icedtea, but if I understand properly, the openjdk package is icedtea
<realitix> LocutusOfBorg: Do I need to create a debdiff ?
<LocutusOfBorg> realitix, I don't even find the file to patch in sources
<LocutusOfBorg> find . -name jvm.cpp
<LocutusOfBorg> returns nothing
<LocutusOfBorg> oh... tarballs :/
<ahasenack> java is always so pleasant, isn't it
 * LocutusOfBorg wants to cry
<LocutusOfBorg> we might have a patch here https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/9299391/+listing-archive-extra
<realitix> I put the link to the patch at the end (icedtea source)
<realitix> LocutusOfBorg: Your link seems good!
<realitix> LocutusOfBorg: You are very fast, amazing ;-)
<LocutusOfBorg> realitix, it didn't build :/
<LocutusOfBorg> realitix, can you please do the SRU_Bug_Template paperwork?
<realitix> ok I will try
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<tsimonq2> Unit193: Were you around for a DMB meeting?
<tsimonq2> Unit193: I know you had specific time requirements; I'm not sure if you're around now or not.
<Unit193> tsimonq2: Nope.
<tsimonq2> Unit193: Ah.
<Unit193> Eh?  What list has a pseudonym concern?
<tsimonq2> Unit193: The private DMB one.
<doko> tjaalton: emacs wants to pull xaw3d and xutils into main. could you have a look at that? are these ok for main?
#ubuntu-devel 2018-07-31
<juliank> bdmurray: missing the latest apport upload in bzr, what's the status there?
<juliank> doko: have you seen https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1784107 and duplicates? python3 tries to p3compile hplip files that do not exist
<ubottu> Launchpad bug 1784107 in update-manager (Ubuntu) "package python3-update-manager 1:18.04.11.4 failed to install/upgrade: vereistenproblemen - blijft ongeconfigureerd" [Undecided,Confirmed]
<cpaelzer> hmm, when does hwdata package update its database? Upload Sat, 02 Jul 2016 16:53:06 +0200 database version is 2017-03-16 03:15:01 in /usr/share/hwdata/pci.ids
<cpaelzer> is that a build time regenerated things?
<cpaelzer> yeah the current version is copied since Artful and the build time there somewhat matches the DB 2017-04-20
<cpaelzer> I wonder if that would need regular no-change rebuilds to stay current ...
<cpaelzer> ok, assumption confirmed the makefile curl's the data from the web
<cpaelzer> and Debian bein gon the same package version but an earlier build has an older DB
<cpaelzer> so probably a rebuild would really be useful
<cpaelzer> harr, I see symlink to actually pciutils - now all makes sense as the make wasn't called on build
 * cpaelzer stops mumbling to the chan :-)
<infinity> cpaelzer: wget at build time wouldn't work anyway. :P
<cpaelzer> yep that made me look for links as net+build = nono
<infinity> cpaelzer: Tim used to occasionally do pciutils updates for upstream DB changes as SRUs.  Not sure if someone's taken that over from him.
<infinity> apw, sforshee: ^^
<tjaalton> doko: xutils is just a metapackage, dunno about xaw3d
<apw> infinity, oh, hmmm... yes that likely is through the cracks --- my memory of that is he used
<apw> infinity, to pull us up 'newer' than debian, but that is was essentially resync able
<LocutusOfBorg> doko, gcc8 makes pcl sad "c++: fatal error: Killed signal terminated program cc1plus"
<doko> LocutusOfBorg: which archs?
<LocutusOfBorg> everywhere I would say
<LocutusOfBorg> at least ppc64el
<LocutusOfBorg> other archs are boost failing
<seb128> does anyone know of a more efficient way to get the list of packages a team is subscribed to from launchpad than that?
<seb128> subscribed = desktop_team.getBugSubscriberPackages()
<seb128> for source in subscribed:
<seb128> 	sources.append(source.name)
<seb128> it works but takes 30 seconds
<seb128> cyphermox, doko, mir team, could you review https://bugs.launchpad.net/ubuntu/+source/yaru-theme/+bug/1783600 ? it's our new theme and we would like to switch the default in yaru sooner rather than later to have time to get feedback and fix issues
<ubottu> Launchpad bug 1783600 in yaru-theme (Ubuntu) "[MIR] yaru-theme" [Undecided,Confirmed]
<doko> didrocks: ^^^
<doko> seb128: I don't want to commit on that one for now, busy with other stuff, and afk next week
<seb128> doko, ok, no worry
<seb128> doko, didrocks is the one who is driving the project and doing the packaging so would be nice to have another reviewer, also he's away for summer holidays in a few days
<doko> argh
<seb128> but it's "only a theme" and we started it with the community
<seb128> so maybe it's fine to have a pre-ack to start including it, knowing we commit to fixing reviews issues later?
<doko> seb128: emacs is now built unversioned (and desktop was subscribed to emacs25). could you subscribe to the emacs source?
<seb128> doko, done for emacs, what do you think about pre-approving the theme MIR?
<cjwatson> good lord: drwx------ 2 ddebs ddebs 597336064 Jul 31 10:20 /srv/ddebs.ubuntu.com/.launchpadlib/api.launchpad.net/cache
<cjwatson> rm -r has been running for, err, some time
<seb128> lol
<seb128> impressive
<seb128> cjwatson, since you are around, do you know about the launchpadlib question I asked an hour ago?
<seb128> sorry to use the opportunity and nag you :)
<cjwatson> seb128: I don't know of a more efficient way, no.  You can check with the profiling technique in https://help.launchpad.net/API/launchpadlib#Three_things_to_make_your_client_faster, but looking at the basic response I don't think you'll have any superfluous requests in there and you probably just have one request per 75 packages (usual batching)
<cjwatson> In general we try not to return collections of unbounded size, which keeps the duration of each individual request down but means that some tasks can end up taking longer as a result because they need many round-trips
<seb128> k, makes sense, thx
<seb128> well I guess 30s is ok for that script, my other option is to just load and parse the corresponding webpage
<cjwatson> Which is also batched, right?
<seb128> https://bugs.launchpad.net/~desktop-packages/+packagebugs
<seb128> doesn't seem so?
<cjwatson> that's a bug :P
<seb128> don't fix it :p
<cjwatson> it must just be fast enough that we haven't needed to batch it
<cjwatson> but absolutely no promises about any large collection like that remaining unbatched
<seb128> yeah, that team has quite a list
<seb128> if it doesn't timeout it's probably good enough for most cases
<cjwatson> it would be the first thing we did if it ever started timing out
<seb128> right
<seb128> I'm just going to use the api, cleaner and at least no futur surprise (hopefully)
<seb128> thx
<cjwatson> ok, sorry not to have a better answer
<seb128> no worry, that's for a script that is a cron job geneating team reports, the extra 30s isn't going to be an issue
<LocutusOfBorg> doko, "Fix applying xserver patch, by not building mir." I think tigervnc is now syncable, but I don't know the rationale for your delta...
<LocutusOfBorg> there is no mention of mir anymore in the source code
<LocutusOfBorg> I sync'd, not sure what might break
<TJ-> bcmwl-kernel-source from 'restricted' is failing to build on 18.04 ( bug #1779974 and others) leaving users without WiFi - who's responsible for dealing with that?
<ubottu> bug 1779974 in bcmwl (Ubuntu) "install bcmwl-kernel-source , Module wl not found in directory /lib/modules/4.15.0-24-generic" [Undecided,Confirmed] https://launchpad.net/bugs/1779974
<TJ-> This also affects 16.04 with the HWE kernels
<rbasak> TJ-: try #ubuntu-kernel
<TJ-> rbasak: already done, and sorted :)
<StevenK> Is there a rough timeline for Bionic being added to meta-release-lts now that 18.04.1 is out?
<infinity> StevenK: Soon(tm).
 * ogra shakes head about the always ahead in TZ and always impatient aussies ... 
<ginggs> tseliot: hi!  are you planning nvidia-graphics-drivers-396 any time soon?  (needed for CUDA 9.2)
<tseliot> ginggs: hi. No, sorry, we only support long lived branches
<ginggs> tseliot: ok, thanks
<GunnarHj> infinity: You mentioned you'd SRU your fix of bug #1762952. Still on your list? Anything I can do to help?
<ubottu> bug 1762952 in console-setup (Ubuntu Bionic) "Alternative shortcut for layout switching Alt+Shift unexpectedly set by default" [Undecided,Confirmed] https://launchpad.net/bugs/1762952
<tjaalton> only 3.3.1 is referenced in /win 27
<tjaalton> uh
<ahasenack> hi, my ocfs2-tools upload to cosmic is failing to pass migration because of an s390x failure that is unlikely to go away: https://github.com/markfasheh/ocfs2-tools/issues/22
<ahasenack> there are hints already in place, but for the previous version of the package in ubuntu:
<ahasenack> # Was skipped in lxc, never passed in a vm, not supported on big-endian
<ahasenack> # https://github.com/markfasheh/ocfs2-tools/issues/22
<ahasenack> force-badtest ocfs2-tools/1.8.5-3ubuntu1/s390x
<ahasenack> what's the appropriate thing to do here, bump that to 1.8.5-5ubuntu1 (my upload)?
<ahasenack> or make that more generic, if supported, like 1.8.5? Maybe a newer version will get s390x support
<ahasenack> or update the test and skip s390x entirely, returning a fake "pass"?
<ginggs> ahasenack: I think the usual action is a bump in the hints file, best place to ask is #ubuntu-release
<ahasenack> I always ask in the wrong channel :/
<infinity> GunnarHj: It's sitting in the queue.
<infinity> GunnarHj: And by "it's in the queue", apparently I meant "I built it, signed it, and forgot to upload it".
<infinity> GunnarHj: Uploaded now.
<mdeslaur> in all fairness, you didn't specify which queue
<infinity> mdeslaur: Sure, let's go with that.
<slangasek> infinity: TB meeting?
<infinity> slangasek: Sleep.
<slangasek> tsk
<infinity> slangasek: But you can relay that I've asked wxl to apply another round of Democracy(tm) to our expiries.
<wxl> done already, actually
<infinity> wxl: Ahh, excellent.
<wxl> and i got in touch with mark.. or at least emailed him XD
<wxl> (he hasn't yet replied)
<GunnarHj> infinity: Thanks! :)
<ahasenack> wow:
<ahasenack> Get:1 http://ftpmaster.internal/ubuntu cosmic-proposed/main amd64 libsqlite3-0 amd64 3.24.0-1 [506 kB]
<ahasenack> Fetched 506 kB in 213503982334601d 7h 0min 15s (0 B/s)
<ahasenack> :)
<infinity> Math is hard.
<ahasenack> tjaalton: hi there,
<ahasenack> tjaalton: checking a freeipa dep8 failure with my recent bind9 upload (not related to that pkcs11 crash bug): https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/f/freeipa/20180731_191434_0e520@/log.gz
<ahasenack> tjaalton: any idea what failed there?
<ahasenack> only thing I could find was:
<ahasenack> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from cosmic-proposed
<ahasenack> hm, maybe bind9-dyndb-ldap?
<tjaalton> hard to tell
<ahasenack> ah, likely, actually
<ahasenack> I somehow missed that in the rdepends output of apt-cache rdepends libdns1100
<tjaalton> I have a patch for that crash btw
<tjaalton> asked folks to test it
<ahasenack> I saw the movement in the bug, nice find by that guy
<tjaalton> oh this is cosmic
<ahasenack> yes
<ahasenack> I'm taking care of it
<ahasenack> nothing like asking to find out what is wrong seconds later :)
<tjaalton> yeah needs a rebuild
<ahasenack> does ubuntu use the ...buildN suffix to indicate no-change rebuilds? Or just bump the ubuntu release number?
<ahasenack> I'm not finding examples of ...ubuntuNbuildX in my installed packages
<tsimonq2> If it has an Ubuntu delta, bump the ubuntu number.
<ahasenack> ok
<tsimonq2> Because you want to keep the delta.
<tsimonq2> Fun fact; dch --rebuild does this logic for you. ;)
<tsimonq2> Otherwise, yeah.
<ahasenack> oh, true
<ahasenack> would someone sponsor this rebuild for me? I can't upload bind-dyndb-ldap: https://pastebin.ubuntu.com/p/XVcFrKmqxH/
<ahasenack> or just run dch --rebuild on that package :)
<tsimonq2> I have a script. :P
<tsimonq2> Oh yay, it's in Universe.
<tsimonq2> ahasenack: Doing.
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4/+packages ppa showing it builds fine with the new bind9
<ahasenack> tsimonq2: ^ thanks
<tsimonq2> ahasenack: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-3ubuntu2
<tsimonq2> Have fun.
<ahasenack> tsimonq2: splendid, thank you
<tsimonq2> No problem.
<GunnarHj> tsimonq2: Do you have time to revisit and sponsor bug #1778041? I have taken a couple of actions since the last failed attempt (comment #4 and #5).
<ubottu> bug 1778041 in freshplayerplugin (Ubuntu Bionic) "browser-plugin-freshplayer-pepperflash broken" [High,In progress] https://launchpad.net/bugs/1778041
<ahasenack> tjaalton: when you have a moment, could you please retrigger the failed freeipa tests under my bind9 upload? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bind9
<ahasenack> you can see in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bind9-dyndb-ldap that they are now passing
<tsimonq2> GunnarHj: Done, but you'll need to poke an Archive Administrator.
<tsimonq2> (Missing binaries.)
<GunnarHj> tsimonq2: Thanks, will do! But I don't see the SRUs..?
<tsimonq2> GunnarHj: Oh, let me get those.
<tsimonq2> Where were those?
<tsimonq2> (Did you just want me to wholesale backport that?)
<GunnarHj> tsimonq2: https://launchpad.net/~gunnarhj/+archive/ubuntu/freshplayerplugin
<tsimonq2> GunnarHj: Done.
<GunnarHj> tsimonq2: Thanks a lot! Crossing my fingers for this being it.
#ubuntu-devel 2018-08-01
<tjaalton> ahasenack: done
<dupondje> https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1764819
<ubottu> Launchpad bug 1764819 in freerdp2 (Ubuntu) "CredSSP v6 on Bionic not supported freerdp2" [Undecided,New]
<dupondje> Might be something important to fix? The more people upgrade their windows server, the more people will have issues with freerdp connecting to it ...
<dupondje> don't know who would be the best to guy to get this fixed :)
<dupondje> Guess we don't want to take the cosmic version for bionic? (which is the best option I guess)
<seb128> doko, hey, you didn't reply yesterday about the new theme ... do you think it's possible to have a pre-ack so we can start shipping it? knowing we are the maintainer and commit to fixing issues raised by the review if there is any?
<rbasak> bdmurray: SRU reviewing xfce4-terminal in the Bionic queue, I'm not sure what to do about the translation and build system noise. Is that OK?
<infinity> rbasak: It's expected for a new upstream.
<smb> mvo, you might be interested in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784843
<ubottu> Launchpad bug 1784843 in snapd (Ubuntu) "snap list: unexpected fault address 0xfffff1f0" [Undecided,New]
<coreycb> doko: is python3.7-dbg up to speed with debug symbols? i'm getting a coredump but can't make much sense of it.
<coreycb> doko: nm user error i think
<mvo> smb: thank you, looking!
<coreycb> doko: i may need a hand with this: https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1784854
<ubottu> Launchpad bug 1784854 in python3.7 (Ubuntu) "segfault in _abc__abc_instancecheck_impl at ../Modules/_abc.c:521" [Undecided,New]
<smoser> cjwatson_ or bdmurray i'd appreciate review of https://code.launchpad.net/~smoser/software-properties/trunk.lp1667725-https-signing-key/+merge/351824 . It seems to me to be a general improvement.
<smb> mvo, It appears this was just an unfortunate flipping of bits at some point. I did mark my bug as invalid
<mvo> smb: thanks for the update! interesstinng
<mvo> smb: if you still have the sd card a hash of the snapd binary and snap binary might be interessting to see if the binary on disk got corrupted
<smb> mvo, though I have the SD card the first step I tried was a re-install of the dpkg, so that is gone
<mvo> smb: ok, no worries. your conclusion sounds right
<smb> mvo, After finding that I remembered dpkg --verify and found that a few more things were affected. But all of those much less obvious or likely to notice. I need to make a note to remember doing that next time
<xnox> Laney, what is the backing store for lxd for the armhf-on-arm64 runners? i'm trying to reproduce
<xnox> compat_uts_machine=armv7l
<xnox> bah
<xnox> Unable to read extent map for '/usr/lib/systemd/tests/test-sleep': Inappropriate ioctl for device
<xnox> Assertion 'test_fiemap(argv[0]) == 0' failed at ../src/test/test-sleep.c:94, function main(). Aborting.
<xnox> but failing to do so, on an arm64 bare-metal instance, with lxd container.
<xnox> so wondering what is the "backing" store for the containers on the production machines.... dir? btrfs?
<xnox> Laney, managed to reproduce =)
<xnox> win
<xnox> with btrfs backend
<slangasek> stgraber: hi, so for LP: #1302192, you several years ago marked ping setuid because "there's currently no good ways to have capabilities be kept in all our images".  Is this still a concern?  This comes up because a customer has noticed /usr/bin/mtr-packet also has fscaps configured.  Should we still not be able to rely on xattr support on all our rootfs types?
<ubottu> Launchpad bug 1302192 in iputils (Ubuntu Trusty) "capabilities not preserved on installation" [Undecided,Confirmed] https://launchpad.net/bugs/1302192
<stgraber> slangasek: so it mostly depends on how much we care about tarballs and backward compat of squashfs
<slangasek> stgraber: GNU tar has a --xattrs option now
<stgraber> slangasek: recent squashfs implementations do support xattrs I believe, so as long as our build systems aren't running ancient versions of squashfs-tools that should be fine
<slangasek> stgraber: I do see that in the existing pipeline, a newly-launched lxd container ends up without the fscaps but I haven't looked into it
<slangasek> stgraber: I guess my question is, if I fix that, do you know of any reasons we shouldn't just require fscaps support as a baseline, and revert the iputils diff?
<stgraber> slangasek: right but from what I remember about tarballs, it's an extension which redhat made a while back which isn't strictly compatible with the tar format, so some unpackers may crash
<slangasek> stgraber: fair; otoh I don't think we distribute our rootfs as tarball anywhere except to a particular cloud partner?
<stgraber> slangasek: LP build chroots are tarballs and we publish a -root.tar.xz for all cloud images on cloud-images.u.c
<stgraber> slangasek: the ubuntu-base image on cdimage/releases is also a tarball
<stgraber> ah, base and possibly LP chroots may be fine as they likely don't contain iputils
<stgraber> looking into tar xattr, looks like the issue is incompatible format for xattrs between GNU tar and libarchive
<slangasek> stgraber: and certainly, "fails to restore xattrs on unpack with certain unpackers" is a lesser bug than "fails to unpack with certain unpackers"
<stgraber> slangasek: indeed, loosing the xattr is probably acceptable
<stgraber> slangasek: I wish xattrs were better tracked in .deb packages though, if we had a .xattr file under /var/lib/dpkg/info/, we could trivially write a tool (cloud-init hook?) that could re-apply them all on startup, or if that fails, make all affected files setuid.
<slangasek> stgraber: the root.tar.xz on c-i.u.c, we thought we were dropping, then we had a downstream requirement to bring it back (so it's present again in cosmic).  And it contains mtr-tiny, so is currently affected by this bug, which we either fix by adding xattrs to the tarball or by hacking mtr to not use xattrs (which would be less secure)
<stgraber> slangasek: ok, anyway, I'm not opposed to having that delta be dropped, but this needs to be done carefuly, needs to be documented in the 18.10 announcement and we should expect a good pile of bugs as a result of it because people tend to like using tarballs/rsync with their systems and are unlikely to be passing --xattr to both of those right now.
<slangasek> stgraber: ok, I think I'm going to post to ubuntu-devel and propose that we standardize on xattrs: yes
<stgraber> AFAICT unsquashfs extracts xattrs by default, so that one should be fine
<slangasek> rcj: ^^ fyi
<rcj> slangasek: thank you
<stgraber> slangasek: https://github.com/lxc/lxd/pull/4861 <- LXD side of this
<slangasek> stgraber: is that sufficient to fix the fscaps on /usr/bin/mtr-packet?  i.e. the squashfs we're producing is already correct?
<stgraber> slangasek: that only changes handling of tarballs and rsync, squashfs is supposedly unpacking xattrs by default which would suggest that your squashfs is bad?
<slangasek> ok
<stgraber> then again, mksquashfs says that it stores xattrs by default
<slangasek> yeah, I will investigate
<stgraber> how's the squashfs generated? is it directly coming off the build directory or is that getting repacked somewhere that might go through one of tar, rsync or a fs that's not capable of storing xattrs (or uses fakeroot/fakechroot which I suspect also may not know what an xattr is)
<slangasek> it's generated by livecd-rootfs, it ought to be straight from the build dir without any intermediate tar streaming. But I'll dig
<stgraber> and that's running as real root?
<slangasek> # mount /var/lib/lxd/images/90203fd4cf8732375207ecbde3a1672466dbbfd72a12e39469db9ee6f51b0bbf.rootfs /mnt
<slangasek> # getcap /mnt/usr/bin/mtr-packet
<slangasek> /mnt/usr/bin/mtr-packet = cap_net_raw+ep
<stgraber> oh, good, so the cap is there
<slangasek> so the squashfs was good, but it's not visible within the container?
<stgraber> what storage backend are you using?
<stgraber> zfs has some restrictions on xattrs by default for example
<slangasek> it's zfs
<stgraber> slangasek: what does "zfs get xattr lxd/images" get you?
<slangasek> NAME        PROPERTY  VALUE  SOURCE
<slangasek> lxd/images  xattr     on     default
<stgraber> ok, I usually set that to "sa" to support a larger set of attributes but I don't know that it'd cause the attr to just be stripped
<stgraber> I wonder if it's unsquashfs' manpage lying to us
 * stgraber tests
<stgraber> oh, or maybe not...
<stgraber> it may just be unpriv fscaps causing it
<stgraber> lets see
<slangasek> stgraber: I ran getcap on the mountpoint on the host also; it's not there
<slangasek> $ getcap /var/lib/lxd/storage-pools/lxd/containers/caring-calf/rootfs/usr/bin/mtr-packet
<slangasek> $
<stgraber> ok, so unsquashfs is the likely suspect then, unless LXD changing permissions caused the kernel to strip the attr which is plausible too
<stgraber> yup, that's it, it's the uid/gid remapping that's stripping it...
<stgraber> stgraber@castiana:~$ lxc launch ubuntu-daily:cosmic c2 -c security.privileged=true
<stgraber> Creating c2
<stgraber> Starting c2
<stgraber> stgraber@castiana:~$ lxc exec c2 -- getcap /usr/bin/mtr-packet
<stgraber> /usr/bin/mtr-packet = cap_net_raw+ep
<stgraber> so that's gonna be fun to fix...
<slangasek> heh
<slangasek> stgraber: feasible fun or infeasible fun? :)
<slangasek> if you can't fix it, that puts a damper on a proposal to allow fscaps in packages
<stgraber> should be feasible but I'd need to look into hallyn's work on unpriv fscaps
<stgraber> I don'
<slangasek> ok
<stgraber> I can't remember if we can just set it the normal way in the xattrs or if we need to store the namespaced key
<stgraber> I suspect we want the namespaced key so that the container user can update the binary later on but that's a bit of a blur in my head now :)
<slangasek>        --xattrs-include=PATTERN
<slangasek>               Specify the include pattern for xattr keys.  PATTERN is a  POSIX
<slangasek>               regular expression.
<slangasek> LIES
<mwhudson> is it an emacs regular expression?
<hallyn> whzzup
<hallyn> slangasek: I'm probably misunderstanding, but it sounds like you're expanding a tarball with xattrs in a userns, then expecting to see those from the host;  you'll only see them as xattrs from within a userns which has the same host uid mapped to root
<slangasek> hallyn: this is lxd doing the expanding, and it winds up with fscaps disappearing from the rootfs of an unprivileged container (when viewed from either inside or outside)
<sladen> ~
<rbasak> infinity: did you conclude if you want to accept the nodejs openssl ABI/soname link change?
<rbasak> bug 1779863
<ubottu> bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress] https://launchpad.net/bugs/1779863
<ogra> hmm, anyone familiar with journald ? ... according to the journald.conf manpage the commented values in journald.conf are the defaults ...
<ogra> there are no size limites set in that file which makes me assume there is no upper limit for the logs ...
<ogra> the logs are stored in /run ... which in turn is a tmpfs we mount with a fixed size (10% of the RAM it seems)
<ogra> so that seems to be my upper limit for the logs ...
#ubuntu-devel 2018-08-02
<ogra> now the million dollar question is ... what happens if /run runs out of space due to massive logging ?
<ogra> (since it is mounted with size= i assume it wouldnt grow dynamically or anything=
<ogra> am i missing any piece of the puzzle here or could excessive logging actually kill a system
<ogra> (due to the fact that other processes couldnt write to /run anymore)
<jbicha> ogra: my understanding is that Ubuntu does not set a max size for the systemd journal by default
<ogra> jbicha, right ... so the possible max size is the size of /run ... and that isnt dynamic according to the mount options
<ogra> which means you could potentially make /run out of space if the logs grow to its full size ...
<jbicha> I have heard some user complaints about the journal getting way too big because some process is logging way too much
<ogra> *make /run run out of space
<ogra> right, the point is that if the above is actually true processes wouldnt be able to create sockets and tempfiles in /run which they normally do ...
<ogra> this sounds so massively broken that i think i'm missing something important here ... which is why i asked ;)
<infinity> ogra: It's no different from being able to starve /var with over-logging.  I mean, except that /run is usually smaller, and journald is crap and certain people abuse journald quite heavily. :P
<doko> ginggs: I think we have a problem with dolfin everywhere ...
<ginggs> doko: looks similar to petsc, hangs during build with openmpi
<ginggs> ...and arpack
<doko> ginggs: yes, already in the configury
<ginggs> doko: i couldn't reproduce locally with gcc, openmpi and others from -proposed.  and builds fine in debian
<doko> rbalint: could you have a look at the nfs-utils autopkg test regression triggered by sqlite3?
<rbalint> doko, ok, looking
<rbalint> doko, seems like it was cloud-init, it runs fine now with latest cloud-init, just re-run it to be sure
<seb128> doko, thanks for the yaru review ... what was blocking? I expect having standards-version to 4.1.1 rather than 4.1.5 or use build-depends and not build-depends-indep are not big issues nor blockers, are they? (we are fixing, just curious if those were side comments or part of the reason you put it as incomplete)
<doko> seb128: the question about gtk2
<didrocks> ok, I think I addressed it :)
<seb128> doko, k, we replied to that as well then :)
<seb128> if you can have another look?
<doko> yes, after debconf dinner
<seb128> oh, right, enjoy and I hope debconf is nice :)
<infinity> seb128: It's hot and sticky.
<infinity> seb128: So, I guess that's "nice"? :P
<xnox> ogra, wrong =)
<xnox> jbicha, wrong =)
<ogra> ah, you dragged it here
<ogra> xnox, so wat am i missing ?
<xnox> jbicha, ubuntu uses journald default limits that are capped dynamically based on ramsize and disksize, the actual limits are calculated and printed in the journal, when journald is started. The limits are conservative, but may seem large if one has a big hard drive. All of the bugs filed claiming that it was unlimited, were not true so far. But instead the system had large disks and journal was under the self imposed limit. The current absolute cap
<xnox> for persistent logs is 4GB. But that's when persistent logging is enabled - may or may not be true, depends on the ubuntu release.
<xnox> ogra, jbicha - full glory default details are at https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse=
<xnox> ogra, for you, it matters whether or not you have persistent journal enabled or not.
<ogra> well, assume i'm using the default setup :)
<ogra> (because thats what we do in ubuntu core)
<xnox> ogra, and then check the right limits.... during boot journald logs to /run, but then flushes them to /var/log/journal if it's available. but it would not OOM your system.
<ogra> so no persistence, journald.conf as is from the deb
<xnox> ogra, there is no default, you have to pick one.... tell me if you have /var/log/journal directory present on disk?
<xnox> ogra, it's not about journald.conf =)
<ogra> we dont have a /var/log/journal in core, i can clearly see /run/log/journal being populated
<xnox> ogra, that's bad, you should have /var/log/journal directory created, otherwise you have no logs from previous boot available. unless that's intentional.
<xnox> ogra, all cloud images and later ubuntu releases have it pre-created by default. but it was not universally done in xenial. but we do on cloud images.
<ogra> this is intentional ... we have rsyslog (this is xenial) ...
<ogra> and rsyslog has a core option to allow to disable it to save disk IO on low end systems
<xnox> ogra, ok, then go and read https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse= noting that all limits apply just /run
<xnox> and realise that it would not use up more than 15% of /run tmpfs ever....
<ogra> the system i looked at has rsyslog off and only uses journald with defaults ... logging to /run
<ogra> aha !!!!
<ogra> *that* was the info i was looking for
<ogra> (the 15% bit)
 * ogra hugs xnox 
<ogra> thanks a lot !
<xnox> ogra, everything is in the manpages....
<xnox> ogra, possibly want to find the one on manpages.ubuntu.com
<xnox> ogra, some of defaults are patched in the distro... but when i do that, i patch manpages to match reality too
<ogra> well, i read the top which says "unmodified journald.conf reflects all defaults" . and SystemMaxUse= being empty made me assume there is no upper limit
<ogra> i should have read on ;)
<xnox> a conffile is not documentation
<ogra> no, but the manpage note made me not read on but just look at the values in the conf
<xnox> O_o?
 * xnox notes ogra does not read man pages =))))))))))))))))
<ogra> xnox, https://paste.ubuntu.com/p/CpftcGTb9W/
<ogra> i didnt bother to read on because of this note ...
<xnox> ogra, depend on the key, "empty" has different meanings for a default what it is initialized to
<ogra> right, perhaps the note should say that ... since i was assuming an empty key means no default (so no limit)
<xnox> ogra, if something is numeric.... boolean... frequency.... etc.....
<xnox> ogra, also i'm glad you think a logging system is stupid enough to be unlimited.... given that it is obvious that logs must be contained.....
<ogra> not sure if its just me being dumb though :) or if others could fall into the same trap
<xnox> ogra, anyway $ journalctl -b -u systemd-journald
<xnox> should have like things like this
<xnox> Aug 01 23:36:12 s1lp14 systemd-journald[701]: Runtime journal (/run/log/journal/9627530553e94a23bca5e0080fa400e4) is 8.0M, max 199.2M, 191.2M free.
<xnox> Aug 01 23:36:12 s1lp14 systemd-journald[701]: System journal (/var/log/journal/9627530553e94a23bca5e0080fa400e4) is 504.0M, max 1.9G, 1.4G free.
<xnox> the latter might not be here, if you don't have /var/log/journal
<ogra> yep
<ogra> $ sudo journalctl -b -u systemd-journald
<ogra> -- Logs begin at Fri 2018-07-27 00:23:42 CEST, end at Thu 2018-08-02 14:05:32 CEST. --
<ogra> Jul 27 00:23:42 stream systemd-journald[464]: Runtime journal (/run/log/journal/) is 1.1M, max 9.1M, 8.0M free.
<ogra> perfect
<ogra> thanks a lot
<xnox> tsimonq2, i think i fixed this.... https://launchpad.net/ubuntu/+source/gsettings-qt/0.1+17.10.20170824-5fakesync2
<xnox> tsimonq2, but now getting bus error on armhf..... can we like destroy armhf? or like kill gsettings-qt?
<seb128> shrug
<seb128> slashd, dgadomski, upload things before updating the bug and not updating the vcs = #fail :/ (speaking about gdm)
<seb128> slashd, I just merged that change and another one in the vcs and tagged/pushed, to get a conflict on uploading, now we have a vcs with mismatch the archive :/
<seb128> slashd, dgadomski, please get the git situation sorted out, the recent commits need to be reverted and yours added, then the change reverted needs to be added back
<slashd> o/ seb128 not sure to fully undertand what you mean here
<seb128> slashd, we have a packaging vcs, https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3?h=ubuntu%2Fmaster
<seb128> slashd, you are the one who uploaded https://launchpad.net/ubuntu/+source/gdm3/3.28.2-3ubuntu2 according to launchpad?
<slashd> I did yes
<seb128> slashd, your upload is not in the vcs and conflicts with work pending upload done there
<seb128> slashd, oh well, I'm learning new git tricks and trying to fix it, but please next time when there is a vcs use it
<slashd> seb128, sure, first time I was told something like this, will take note for sure
<slashd> seb128, so does dgadomski and I have to do something at this point ? or you are good ?
<seb128> slashd, I'm good, you just created a bunch of extra work for me but I'm dealing with it
<seb128> slashd, do you plan to deal with the SRUs as well?
<slashd> seb128, sorry for the inconvenient. For the SRU I was planning to do it too yes
<seb128> slashd, can you include the diff from https://code.launchpad.net/~albertomilone/ubuntu/+source/gdm3/+git/gdm3/+merge/351810 in the same upload? (I'm currently uploading that to cosmic)
<seb128> so we have both in the same SRU
<seb128> avoid another roundtrip
<slashd> seb128, sure
<seb128> slashd, thx!
<xnox> Setting up python3-twisted (17.9.0-2) ...
<xnox>   File "/usr/lib/python3/dist-packages/twisted/conch/manhole.py", line 154
<xnox>     def write(self, data, async=False):
<xnox>                               ^
<xnox> SyntaxError: invalid syntax
<xnox> argh
<xnox> packages should FTBFS on syntaxerrors....
<xnox> oh, wouldn't help probably
<tsimonq2> xnox: Thanks.
<xnox> tsimonq2, no idea if this is right or wrong, but works for me
<cjwatson> xnox: fixed upstream FWIW
<cjwatson> commit ee535041258e7ef0b3223d2e12cd9aaa0bc2289f
<tsimonq2> xnox: Please push your patch upstream to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905059
<ubottu> Debian bug 905059 in gsettings-qt "gsettings-qt: FTBFS with Qt 5.11.1" [Serious,Open]
<xnox> cjwatson, ah thanks!
<xnox> cjwatson, oooh they did it in the neat way... cause i was like "surely that will break the function signature"
<cjwatson> xnox: Yeah, clever hack
#ubuntu-devel 2018-08-03
<doko> jamespage, coreycb: https://tracker.debian.org/news/977343/accepted-glance-21601-7-source-all-into-unstable/ please could you address this upstream as well?
<cpaelzer> LocutusOfBorg: hi, I found you hit retry for mrbayes a few times recently
<cpaelzer> I found openssh migration breaking on it as well and wanted to ask if you know anything about the background of this
<cpaelzer> is the mrbayes package just flaky or is there more to it?
<LocutusOfBorg> cpaelzer, no idea sorry
<ginggs> cpaelzer: you need to trigger with openmpi/3.1.1.real-4 as well
<ginggs> openmpi/3.1.1.real-1 in release is broken
<cpaelzer> thanks ginggs, maybe that is the problem
<cpaelzer> will try that
<cpaelzer> LocutusOfBorg: ginggs: the trigger with the new openmpi did it
<cpaelzer> thanks
<ginggs> cpaelzer: yw!
<cjwatson> smoser: Looking, but I hadn't QAed the LP branch myself before it was deployed owing to being on holiday, and the response from the new endpoint isn't quite what I want it to be (JSON rather than just an octet-stream), so I'd like to work on that a bit more before you deploy anything that uses it.
<cjwatson> (it's possible I can't do anything about that aspect of the response due to how lazr.restful works, but I want to at least look into it)
<cjwatson> smoser: ... OK, decided I can't do much about the above except to clarify things a bit.  Reviewed your branch now
<slashd> seb128: dgadomski and I will work on both SRUs (our and yours). For the SRU is there anything we need to do at the vcs level ? Just make to make sure we don't add extra work again for you.
<slashd> re: gdm3 ^
<smoser> cjwatson: around ?
<seb128> slashd, there is a vcs on https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3/log/?h=ubuntu/bionic if you want to mp against that
<smoser> http://paste.ubuntu.com/p/xjQcHrgBr9/
<slashd> dgadomski, ^
<seb128> slashd, but if you want to avoid the work let me just know when you update and I can gbp import-dsc the upload
<dgadomski> hey seb128, is xenial also handled via vcs?
<smoser> expected ^ ? they payload is surrounded by double quotes
<seb128> dgadomski, no, you can see the branches on https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3/?h=ubuntu/bionic
<seb128> we started using git recently and bionic is the only serie where we do enough work to justify it
<cjwatson> smoser: ?
<smoser> cjwatson: in that paste. the first and last character are a "
<dgadomski> seb128: thanks, I've seen the branches, but was wondering if there's e.g. a legacy bzr branch for xenial, I think now I get it
<smoser> seems not expected to me. if it is expected, then i have to adjust the branch for softwareproperties to remove to return data[1:-1]
<seb128> dgadomski, check debian/control from the current SRU, if there is no such info there is probably no vcs
<seb128> dgadomski, but yeah, for gdm no vcs to care about outside of bionic
<cjwatson> smoser: Yes, that's what I was talking about when I mentioned JSON above.  You must not do data[1:-1]; instead, just parse the response as JSON (notice that it has Content-Type: application/json)
<cjwatson> (see also https://code.launchpad.net/~cjwatson/launchpad/archive-get-signing-key-data-text/+merge/352298 which clarifies the docs)
<smoser> oh. right. ok.
<smoser> i thought you were saying you *wanted* a json blob to be returned (as in {"key_data": "blob here"})
<cjwatson> Due to the way the API infrastructure works it isn't practical to have a method that returns a non-JSON response
<cjwatson> I'd have preferred to have it just be Content-Type: application/octet-stream, but that would be a whole ton of hacking
<cjwatson> smoser: You should probably just do accept_json=True
<smoser> yeah. i'll push that. it does work.
<cjwatson> Sorry, I did actually notice that in your branch but apparently completely forgot to write it in my review
<smoser> well, at least we caught it before i uploaded . :)
<smoser> i'll give it a full spin and install and use before uploading.
<smoser> but could you give it one more lok ?
<cjwatson> smoser: LGTM
<smoser> bugger.
<smoser> cjwatson: so... my change to use the devel api encdpiont seems to have broken python2
<smoser> does that make any sense to you?
<smoser>  python -m softwareproperties.ppa ppa:~smoser/ppa
<smoser> that does not work.
<smoser> but python3 same thing does
<cjwatson> smoser: what's the error?
<smoser> and if i change the 'devel/' to '1.0/' we're good. i'll get
<smoser> The user named '~smoser' has no PPA named 'ppa'
<smoser> http://paste.ubuntu.com/p/qXT7KVQfb8/
<cjwatson> It may just need you to not use the obsolete PPA path syntax.  Let me see
<cjwatson> (The canonical URL path for a PPA has been /~OWNER/+archive/DISTRIBUTION/ARCHIVENAME for a while, but I think s-p still uses the deprecated /~OWNER/+archive/ARCHIVENAME form)
<cjwatson> Weird that it would be version-dependent though
<smoser> cjwatson: its getting a 301
<smoser> and the python curl path isn't handling that.
<smoser> python2 curl path. but the python3 libvrary does the right hting.
<cjwatson> Oh, right, there's that weird urllib.request / pycurl thing
<smoser> cjwatson: shall i
<smoser>  crl.setopt(pycurl.FOLLOWLOCATION, 1)
<cjwatson> hang on a sec, I'm looking into this
<smoser> or shall i modify it to do the other url ?
<smoser> ok.
<smoser> cjwatson: i'm sure you're on it. but the differnce seems to me to be that in 1.0, a request for ~smoser/+archive/ppa will return the data directly.
<cjwatson> smoser: So there's already code to handle this, sort of, although it's a bit strange and not used consistently.  How about https://paste.ubuntu.com/p/JnKhm7QMrh/ (only lightly tested) to tighten things up a bit?
<cjwatson> smoser: Note that I fixed a bug in passing in how _recv_key is being called
<smoser> but in devel, it will return a redirect to ~smoser/+archive/ubuntu/ppa
<cjwatson> Yep, I know
<smoser> looking
<cjwatson> http://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/lp/registry/browser/person.py#L489 is the code responsible for this special case
<cjwatson> You want to do this kind of thing rather than adding an 'ubuntu' segment to the LAUNCHPAD_PPA_API URL, because otherwise you're going to run into trouble with existing handling of ppa:~smoser/ppa vs. ppa:~smoser/ubuntu/ppa, I think
<cjwatson> Maybe not in precisely this code path but in other ones
<smoser> yeah.
<cjwatson> All very twisty
<smoser> do you tihnk we should add follow_redirct just for good measure ?
<cjwatson> No opinion
<cjwatson> I guess it shouldn't hurt
<cjwatson> And it would probably be better if it dealt with redirects consistently
<cjwatson> So I guess I do have an opinion, please do :)
<smoser> yeah. ok. i will add.
<cjwatson> Ta
<rbasak> Why is src:squid not autosyncing from Debian? Not that I'm sure I want it right now, but I'd like to understand what's going on first.
<rbasak> Is it because src:squid in Ubuntu last had a delta, even though it has since been deleted?
<ginggs> rbasak: squid is in the sync blacklist https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<rbasak> Ah, thanks.
<rbasak> slangasek: could you look at https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 please? As I understand that statement, the risk of regressing existing users by changing the ABI doesn't exist, and so your primary justification might be moot.
<ubottu> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress]
<rbasak> ddstreet: ^
<cjwatson> rbasak: Even if it weren't in the blacklist, it'd require manual attention due to having previously been removed from Ubuntu
<cjwatson> rbasak: https://people.canonical.com/~ubuntu-archive/auto-sync/current.log is a not-super-friendly log of auto-sync's decisions there (though doesn't include blacklisted packages)
<jbicha> speaking of the blacklist, there's bug 1770792 if an AA has some extra time
<ubottu> bug 1770792 in ubuntu-meta (Ubuntu) "Clean up sync blacklist" [Wishlist,New] https://launchpad.net/bugs/1770792
<slangasek> rbasak, ddstreet: ah interesting, if true then that satisfies me and I would accept the nodejs SRU.  But can we be sure that all modules someone might build would be affected by this node-gyp bug?  Are there no other ways people build node modules?
<slangasek> kees: you had to be difficult; now I'm lost inside the rsync protocol :P
<kees> slangasek: lol
<raidensnake> sorry to bother you but I need to know if it's possible for someone to make a bionic version of the intel hda fix
<raidensnake> it's the package on this link.
<raidensnake> https://code.launchpad.net/~ubuntu-audio-dev/+archive/ubuntu/alsa-daily/+packages
#ubuntu-devel 2018-08-05
<dc-> Oh, what to code, that is the question
<Faux> rust
#ubuntu-devel 2019-07-29
<sahid> jamespage, coreycb: I'm currently rebasing horizon stein, but i can't remember how to refresh xstatic
<enyc> LocutusOfBorg: I can confirm bionic-proposed  virtualbox 5.2.32  works at least as well as 5.2.18 was, for me!
<enyc> LocutusOfBorg: i'm having weird lockups and radeon errors in dmesg  ... going to rty to get it all going on  intel-gpu  or difeent machine!
<LocutusOfBorg> enyc, can you please update the bug report too?
<LocutusOfBorg> thanks!
<ahasenack> sil2100: hi, good morning/afternoon, could you give me some hint about what happened with this billeto run? https://bileto.ubuntu.com/excuses/3763/eoan.html
<ahasenack> sil2100: I've been seeing these kind of results (still running, always failed) in all my eoan runs
<ahasenack> I see it running for a while in that /running url, with logs and all, and then it just disappears, but the state in the eoan.html page isn't updated
<coreycb> sahid: check out debian/README.source
<sahid> coreycb: the problem is not about to build th tarbal it's about to include it
<coreycb> sahid: you'll need to use debuild if you're not using it
<sahid> i tried but that does not look to work, can you confirm the args i should pass to debuild?
<sahid> coreycb: ^
<coreycb> sahid: i use debuild -S -sa
<coreycb> sahid: are both tarballs in the parent directory?
<sahid> coreycb: yep both tarballs, orig.tar.gz and orig-xstatic.tar.gz
<sahid> but pehrpas the problem is somewhere else
<sahid> looks like there are diff related to local_seetings.py.example
<sil2100> ahasenack: let me get back to you in a minute
<ahasenack> sil2100: thanks
<sil2100> ahasenack: ok, so all the logs for those runs were gone, so I couldn't really figure out what happened
<sil2100> ahasenack: I re-set the QA field to trigger another britney run and now the updated results have been uploaded
<sil2100> ahasenack: it's hard for me to figure out what happened - I can only assume that for some strange reason britney reported all test results as 'always failed', so bileto decided that it makes no sense to run britney on it ever again
<sil2100> ahasenack: if you notice such situation ever again, please poke me - but if you want to get some test results in such a moment, you can try the 'workaround' of toggling the QA field to possibly tigger britney to run again
<ahasenack> just a sec, otp
<sil2100> Of couse best if you could just poke me, then maybe we can still get some logs from the britney run that considered the tests as always failing and, therefore, as passing validation
<sil2100> But here this happened somewhere around the 26th
<sil2100> We only keep logs like around 12h back or something?
<ahasenack> back
<ahasenack> sil2100: ok, I see passes now
<ahasenack> weird, and it was super quick
<ahasenack> sil2100: I'll to the qa flip trick if this happens again, and ping you as well
<ahasenack> sil2100: thanks for the help!
<rbasak> juliank: https://paste.ubuntu.com/p/jryp4CfNHs/ - "apt update" returns success even with no connectivity. Is this a bug?
<sil2100> ahasenack: yeah, so what was happening that all the tests have started and finished in timely fashion, but since bileto saw britney at the first run reporting as all the tests as 'always failed', it switched the ticket's status to 'ADT passed' and not ran britney ever again for it
<juliank> rbasak: it's a feature
<sil2100> ahasenack: so the tests passed but a britney run was needed to actually update the results
<ahasenack> sil2100: I see
<rbasak> juliank: it means that if I do things in a fresh container too early (eg. adding -proposed), then apt update fails, the subsequent apt install loses the race and succeeds, and I get non-proposed packages installed.
<rbasak> And upgrading up changes behaviour in my case because the upgrade path is different from the fresh install path :-/
<juliank> rbasak: true, it's always been like this, because the idea was to not break scripts because of temporary failures
<rbasak> :-(
<rbasak> Those scripts should use ; and not && IMHO
<rbasak> The script authors get to pick, but returning success means that I can't pick the latter :(
<juliank> rbasak: I want to add two more error handling modes
<juliank> So you can configure what causes a failure
<rbasak> And then we can set Ubuntu to default to sensible behaviour? :-P
<sil2100> Laney: hey! Would you be able to find some cycles this week to check out the SRU ADT messages MP? No hurry on that one, just a bit sad about not annoying people with ADT regression comments ;)
<rbasak> Anyway, thank you for the explanation. I've registered my use case with you, and I'll leave the decisions to you :-)
<juliank> rbasak: apt-gets behaviour won't change, but I gotta figure out stable CLI for the apt command
<rbasak> juliank: that doesn't help with script users, who are not supposed to use apt directly!
<rbasak> For apt, outside scripting, the exit value hardly matters anyway?
<juliank> That's why I said I want to figure out stable CLI for them
<juliank> So we can fully deprecate apt-*
<rbasak> I see, OK
<juliank> Probably not the best time to think about it now, as I just landed like 2 hours ago coming from Rio to Frankfurt ;)
<rbasak> Put your laptop away then :-P
<rbasak> BTW, would you like a bug for this?
<juliank> rbasak: probably got a few bugs already (definitely in Debian)
<juliank> rbasak: also typing on my phone in a train on flaky connection, not my laptop. Can't relax during train ride anyway
<juliank> :D
<rbasak> :)
<ahasenack> tjaalton: hi, thoughts about sssd 2.2? They jumped from 1.16 to 2.0, 2.1 and now 2.2? is that experimental?
<tjaalton> ahasenack: hi, shouldn't be too experimental now with the most obvious (packaging) bugs fixed
<ahasenack> tjaalton: any idea why upstream was jumping versions like this?
<tjaalton> 2.0 deprecated some features
<ahasenack> and 2.1 -> 2.2? No 2.1 point releases that I can see
<ahasenack> do you know if they have a concept of lts releases, and if 1.16 is one of those?
<tjaalton> it was
<tjaalton> i thinl
<tjaalton> think
<ahasenack> LTM
<ahasenack> that's 1.13.x actually (long term maintenance)
<ahasenack> for major version 2, they call it 2.x series, not even 2.1.x or 2.2.x, just 2.x
<ahasenack> ok, I'll put it on my merge list
<tjaalton> cool
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<milloni> hi, is anyone here involved in work on security features?
<milloni> https://wiki.ubuntu.com/Security/Features
<nacc> milloni: not sure but you may want to try #ubuntu-hardened?
<rbasak> milloni: try #ubuntu-hardened, but you should actually ask your question - people don't generally volunteer themselves for a mystery convesration
<milloni> isn't ubuntu-hardened a separate project
<milloni> rbasak: i know :) i didn't get an answer directly last time so i thought i would reach try to find people directly involved in that
<rbasak> #ubuntu-hardened is the security channel of the Ubuntu project.
<milloni> but if anyone here knows - my question is - is there a reason you're not using mcheck for heap hardening
<rbasak> cpaelzer, rafaeldtinoco: #debian-mysql on OFTC for MySQL discussion
<milloni> i'm eyeballing https://wiki.ubuntu.com/Security/Features#heap-protector
<rbasak> Ask in #ubuntu-hardened please.
<milloni> okay
<milloni> thanks
<mwhudson> good morning
#ubuntu-devel 2019-07-30
<mwhudson> cjwatson: is there a reason the parted build does not run the testsuite? seems it's been that way since 3.1-1 in 2014 but no mention of it in changelog
<mwhudson> oh no, it's from before that
<mwhudson> uh maybe the testsuite has never been run on build
<mwhudson> i guess lots of them need root, maybe more appropriate as an autopkgtest
<sarnold> yikes
<mwhudson> yeah, pretty much
<mwhudson> # FAIL:  9
<cjwatson> mwhudson: 3.1-1 didn't change that, which is why it's not mentioned - that was just the dh conversion
<cjwatson> mwhudson: Quite a few tests do work as non-root, so it's probably worth improving
<mwhudson> cjwatson: of course when i add an autopkgtest to run the tests, a bunch of them fail
<mwhudson> some for trivial reasons, some not
<cjwatson> There's a bug in an fdasd patch which I just fixed on master
<mwhudson> cjwatson: is that the one where vorser.c isn't added?
<cjwatson> yes
<mwhudson> great
<mwhudson> the parted upstream git history is very confusing arond that
<mwhudson> cjwatson: when you say 'master' you mean on salsa?
<cjwatson> Two upstream patches with near-identical commit messages because upstream screwed up applying it the first time round
<cjwatson> Yes
<mwhudson> yeah
<mwhudson> cool
<mwhudson> cjwatson: fwiw my d/tests/control looks like this
<mwhudson> https://paste.ubuntu.com/p/Mjm3hfnnNs/
<mwhudson> cjwatson: all this interest came up because of https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1828558 fwiw
<ubottu> Launchpad bug 1828558 in ubiquity (Ubuntu) "installing ubuntu on a former md raid volume makes system unusable" [Undecided,New]
<cjwatson> bet you need at least dmidecode [amd64 i386] and udev [linux-any] at the moment too, although I'm adding those to Build-Depends in my current WIP
<mwhudson> cjwatson: the tldr of which is that parted mklabel doesn't wipe mdraid 0.90 metadata
<cjwatson> or we need to work out how to disable dmidecode for this because it isn't going to go well ...
<mwhudson> cjwatson: flipflopping about doing something clever with libblkid or just hacking ped_disk_clobber to wipe bigger chunks of the disk
<mwhudson> er can you have an ubuntu system without udev?
<cjwatson> it's not build-essential
<mwhudson> i suppose containers
<cjwatson> mwhudson: partman-md already does mdadm --zero-superblock, so why doesn't ubiquity?
<infinity> ^
<infinity> I thought we decided that was the right answer.
<mwhudson> cjwatson: is mdadm even there?
<mwhudson> in the environment ubiquity runs in
<cjwatson> maybe not
<infinity> Asking any other tool to know where mdadm puts its superblocks is daft.
<mwhudson> if so, that would probably be better
<cjwatson> it could depend on it, if it doesn't already
<infinity> Given that it has many different options.
<mwhudson> i also couldn't really figure out where to jam the zero-superblock call
<infinity> Front, middle, end, sort-of-front-but-not-quite, etc.
<cjwatson> mwhudson: I don't think it would be wrong for ped_disk_clobber to put more effort into zeroing superblocks, maybe, but it should go via upstream
<mwhudson> cjwatson: yeah that too
<cjwatson> I mean it's certainly trying to, as you say
<mwhudson> http://paste.ubuntu.com/p/JT4drXBX8r/ <- output from running that d/tests/control
<mwhudson> some of the failures appear to be device nodes for partitions not showing up
 * cjwatson gives up on trying to run it as non-root, too annoying
<cjwatson> the tiny gpt test segfault looks worth tracking down
<mwhudson> i found another segfault like that
<mwhudson> https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1817267
<ubottu> Launchpad bug 1817267 in parted (Ubuntu) "trying to name a partition on a device with no partition table crashes" [Undecided,New]
<mwhudson> today has been quite the sausage factory experience
<mwhudson> i tried to file a bug
<cjwatson> upstream is theoretically in the process of releasing 3.3, which might be a more rewarding baseline
<cjwatson> 3.2 is really crusty :(
<mwhudson> yeah i noticed the pattern of many commits being cherrypicked into the package
<mwhudson> ah apparently i successfully filed a bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853
<marcoagpinto> mwhudson: could you explain to me what is "cherrypick"?
<marcoagpinto> I notice it when I commit things to Gerrit using the browser
<enyc> LocutusOfBorg: hrrm spotting this https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1803132
<ubottu> Launchpad bug 1803132 in virtualbox (Ubuntu) "virtualbox 0day exploit" [Undecided,New]
<cjwatson> marcoagpinto: https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Patching
<marcoagpinto> ohhhhh
<LocutusOfBorg> enyc, fixed with later releases
<marcoagpinto> Buaaa
<marcoagpinto> :(
<marcoagpinto> it doesn't explain anything
<cjwatson> I don't know how to explain it better than that.  You probably need to have at least a certain amount of git mental model first ...
<rafaeldtinoco> morning o/
<rafaeldtinoco> rbasak: i was able to make mysql8 <-> dbconfig <-> cacti to work
<rafaeldtinoco> im finishing up an idea I had (setting $dbc_authplugin) as a debconf param
<rafaeldtinoco> this way pkg using dbconfig-mysql is able to set auth plugin, and "default" does not set it
<rafaeldtinoco> will finish up patches and push it
<rbasak> rafaeldtinoco: nice, thanks!
<enyc> LocutusOfBorg: i know, but oint bein that is asother support of updating
<rbasak> TIL: the Debian buildds invoke an entirely separate build for Arch: all, rather than doing it at the same time as one of the "any" architectures. That confused me for a while.
<cjwatson> I never got a satisfactory explanation for that approach
<cjwatson> (Despite talking to the person who set it up, more or less at the time)
<rbasak> It might expose a different set of subtle packaging bugs, but I can't see that there's any reason to choose that set from our set.
<rbasak> Today it just mean that I had to discover sbuild's --no-arch-any option to verify that there wasn't a subtle packaging bug causing the FTBFS for Ubuntu but not Debian (there wan't).
 * rbasak needs to type harder
<ahasenack> ok, dh_installman doesn't support [arch] flags in d/foo.manpages
<ahasenack> should I work harder to fix this:
<ahasenack> debian/pmdk-tools.install:[amd64] usr/bin/rpmemd
<ahasenack> debian/pmdk-tools.manpages:doc/generated/rpmemd.1
<ahasenack> i.e., one of the binaries isn't built in non-amd64. Should I work hard to not install the manpage in that case?
<ahasenack> it came like this from debian
<cjwatson> ahasenack: you could do that with dh-exec
<ahasenack> remove this manpage from pmdk-tools.manpages, install it conditionally in pmdk-tools.install?
<ahasenack> I don't think I get the free gzipped version then, do I?
<cjwatson> #! /usr/bin/dh-exec at the top of debian/pmdk-tools.manpages, chmod +x debian/pmdk-tools.manpages, [amd64] at the start of that line in debian/pmdk-tools.manpages, Build-Depends: dh-exec
<rbasak> I would spend the effort filing a bug against dh_installman and then forgetting about it :)
<cjwatson> should work
<rbasak> Or what Colin said
<cjwatson> in fact I don't think dh_install supports architecture filtering directly either?
<ahasenack> a foo.manpages can use dh-exec? I thought that was only for *.install files
<cjwatson> so the package must already be using dh-exec
<ahasenack> cjwatson: correct, the install file is using dh-exec already
<cjwatson> I wouldn't file a bug on dh_installman for this because the settled answer is to use dh-exec for this kind of thing
<rbasak> I didn't realise dh-exec had an arch filter feature
<cjwatson> Unless it doesn't work for dh_installman for some reason, but try it
<ahasenack> will try
<ahasenack> :q
<ahasenack> ops
<ahasenack> hm, got a globbing error now, in another manpage of that same file
 * ahasenack investigates
<ahasenack> does anybody know where I can see the dep8 results for squid 4.8-1 in debian? The tracker says it was accepted into unstable: https://tracker.debian.org/pkg/squid
<rbasak> ahasenack: https://ci.debian.net/packages/s/squid/unstable/amd64/ - linked to from the tracker under "debci"
<nacc> i believe 4.8 was maybe manually uploaded
<nacc> so it doesn't go through CI
<nacc> 'not built on buildd'
<rbasak> Oh, I see. Sorry.
<nacc> https://tracker.debian.org/news/1046100/accepted-squid-48-1-source-amd64-all-into-unstable/
<nacc> it's not clear to me, tbh; just seems a bit weird
<ahasenack> <nacc> so it doesn't go through CI
<ahasenack> wat?
<ahasenack> what's a "manual upload", and why does it skip testing? Feature or loophole?
<tumbleweed> a manual upload is a binary upload, built on the developer's machine
<ahasenack> wow
<ahasenack> ok
<ahasenack> I had no idea this was possible
<tumbleweed> debian is trying to get away from those, thus blocking testing migration
<nacc> I'm not sure it bypasses testing, but if you mean the build-time tests, they obviously aren't run in a binary upload :)
<ahasenack> I'm after the dep8 results, because this upload has a change in that area that I don't understand
<ahasenack> and I wanted to check what happened in debian ci with that change
<tumbleweed> yeah, it simply hasn't run, yet. presumably because fo the binary upload
<Laney> I don't know if it is actually implemented, but you can see on tracker.d.o that this upload is not going to migrate
<Laney> so you could argue that ci.d.n not running it is correct
<tumbleweed> I assume britney is triggering the builds, and britney knows it won't migrate
<tumbleweed> (there are also cron-triggered builds, that may eventually happen here)
<Laney> it could happen like that
<Laney> I'm not sure if it does, but it could
<tumbleweed> I'd ask ivodd, but he's off wondering the island somewhere
<Laney> britney has 'policies' and they can check the outcomes of the ones that ran before
<Laney> so if it's like "were there manual uploads?" "run any autopkgtests", the second part could check if the first part had already vetoed the upload
<Laney> that is called REJECTED_PERMENANTLY in britney terminology
<ahasenack> Laney: how can you tell squid 4.8-1 won't migrate, and why?
<Laney> ahasenack: https://tracker.debian.org/pkg/squid in the middle there
<ahasenack> ah
<ahasenack> not build on buildd, not considered
<ahasenack> the former being the reason why it's not considered? it was a binary upload?
<Laney> yeah I'm not actually sure, but maybe
<Laney> if you're interested in finding out if that's true, suggest stopping by #debci and asking in there
<Laney> or reading the britney code :p
 * Laney is uploading some self built binaries to Debian right now, as it happens (still have to do that for the NEW queue)
<mwhudson> cjwatson: parted upstream said no to more wiping, btw: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853
<cjwatson> OK
#ubuntu-devel 2019-07-31
<rbasak> I've been trying to run britney2 locally. It's been going for ~5 hours, mostly fetching test results from swift, one at ta time, at a rate of around 2 per second.
<rbasak> Apparently all results ever or something.
<rbasak> What am I doing wrong?
<Laney> you're probably the first person to do that
<Laney> in production it benefits from having run before, so there's already state established
<Laney> one thing that the autopkgtest policy needs to do is determine if a test has ever passed before, and that happens by going through the results available on swift
<rbasak> I'm doing it because I want to run an MP against it
<rbasak> s/run/write/
<Laney> even the incremental runs spend a decent amount of time in swift :(
<Laney> running it somewhere closer to the DC might be helpful but I think it's still likely to be fairly slow
<rbasak> It does seem like a very inefficientn workaround for not having a database :-/
<rbasak> Maybe I can hack the code to skip the already-passed check.
<Laney> depending on what you're trying to do, you could chop the problem up in various ways
<Laney> e.g. hack it somewhere to only consider a subset of the archive
<Laney> I feel like autopkgtest-cloud could help solve this problem by exposing some kind of database(-like thing), but there's no designed solution yet
<Laney> I'd be willing to help mentor someone if they wanted to work on it (which is a nice way of saying 'patches welcome', I understand, so maybe not particularly helpful - sorry)
<rbasak> Thanks :)
<rbasak> I thought I'd just add an additional "retry" link for a newer version of a failing dep8 test if present.
<rbasak> Since I have a ton of those to submit and thought it's about time I didn't construct those URLs manually
<rbasak> I think I can see how to write the code, but wanted to be able to test the result.
<rbasak> (and about time I understood more about how britney works too)
<Laney> The testsuite has access to the excuses HTML, FWIW
<Laney> although writing those can be pretty baroque at first
 * Laney glances at pi_tti
<rbasak> Oh, there's a testsuite.
 * rbasak should have looked rather than assume
<Laney> :)
<Laney> You might want to run your idea past vorlon before spending too much time on it
<Laney> He's often got stronger opinions than others ...
<Laney> like you might reasonably say that requesting different variations of tests should be a feature of retry-autopkgtest-regressions rather than britney
<rbasak> My user story is: I examined a failing dep8 test from excuses; I found that an update to the dep8 is the correct fix; I uploaded that fix; now the retry button on the excuses page is no good
<rbasak> And I have to construct a manual retry URL for every architecture
<rbasak> AFAICT
<rbasak> My plan was to add a second link next to the existing retry URL.
<rbasak> An up arrow or something. If a higher version is seen in unstable.
<Laney> OK, so the argument against that is that it's an easy way to test situations that aren't what users will be receving, since the package you're testing will be in -proposed rather than the release proper - and if you've fixed the test then the package should migrate and then a retry at this point will do the expected thing.
<Laney> Maybe we've already conceded this argument by allowing arbitrary triggers at all though, not sure.
<rbasak> The package doesn't migrate in this case - it's held up by the same transition
<rbasak> mysql-8.0 vs libdbd-mariadb-perl
<Laney> nod
<rbasak> Laney: thinking about this, it strikes me that the integration point for autopkgtest in britney2 could be better to be in a different place. Really we want to be testing what britney wants to migrate.
<rbasak> Perhaps that's too hard to implement though.
<Laney> rbasak: I think ideally it'd be after the update_output.txt phase, when you know the transactions that proposed-migration is attempting to migrate - those would be the units that it makes sense to test together
<Laney> but britney's not really designed to facilitate that unfortunately
<rbasak> Yes
<Laney> I'm probably on video at Debconf 15 saying this to pitt_i :P
<ahasenack> tjaalton: hi, do you know if we can build sssd with pcre2 now? That issue you opened is closed, I'm checking if 2.2.0 has that code
<ahasenack> I think it's just in master
<ahasenack> https://github.com/SSSD/sssd/pull/677
<ahasenack> yep
<tjaalton> ahasenack: yeah, needs to be patched still
<rbasak> Laney: do you think gnome-shell in Disco can be released now or should it wait for mutter aging?
<Laney> rbasak: I'll defer to Trevinho if he's (hopefully) around
<Trevinho> rbasak: yes, should be not an issue, let me check a second, but iirc the change wasn't depending on mutter
<Trevinho> rbasak: mutter should be green to go in disco too, though, isn't it?
<Laney> it needs more days
<Trevinho> ah, ok
<Trevinho> anyways yes.. g-s can go
<rbasak> Trevinho: so to be clear, the mutter issue won't be triggered for any user not already affected by just releasing g-s now?
<Trevinho> rbasak: nope, shell fixes are touching something completely different
<rbasak> OK, thanks.
<rbasak> Hmm. sru-release is done, but Launchpad doesn't seem to have updated with the release. I've not seen that before. Perhaps there's a queue?
<cjwatson> The first attempt hit a lock trying to update the bug, and backed off for a while
<cjwatson> It's copied now
<cjwatson> I suspect the copy was unlucky enough to happen at exactly the same time as sru-release itself was posting the bug update
<rbasak> Thanks
<rbasak> That didn't need any intervention presumably? If it happens again, I can be confident that it'll retry eventually?
<ahasenack> juliank: java apps don't seem to be respecting the font scaling we set in my laptop the other day
<ahasenack> I guess that's expected?
<rbasak> FWIW, the reason I was watching this one is that one of the bug tasks was Won't Fix and I wanted to check it correctly flipped to Fix Released. Looks like it did.
<juliank> ahasenack: hmm
<ahasenack> well, "a" java app (only one I have)
<juliank> ahasenack: my eclipse-based one does
<juliank> probably depends on the toolkit in use
<ahasenack> yeah
<ahasenack> "swing"?
<cjwatson> rbasak: No intervention needed.
<rbasak> Thanks
<vorlon> rbasak, Laney: yeah, I think I've -1ed before the idea of adding different retry links on update_excuses, because that page doesn't scale well when there's a logjam and making the page bigger / more memory-consuming to render is not a good tradeoff IMHO
<juliank> $ juju ssh autopkgtest-cloud-worker/0
<juliank> ERROR opening environment: Get https://10.33.102.1:8443/1.0: Unable to connect to: 10.33.102.1:8443
<juliank> ^ I think I broke my laptop's local juju autopkgtest-cloud
<juliank> I rebooted the machine earlier today
<juliank> and it seems it did not recover
<juliank> Also, how do I prevent my lxd containers juju creates from being started at boot?
<juliank> ideas welcome!
<sarnold> juliank: that second bit I can help with :) search for 'autostart' on https://ubuntu.com/blog/lxd-5-easy-pieces
<juliank> sarnold: oh, that's lxd? It does not autostart my other stopped containers at boot
<sarnold> juliank: hmm. I *assumed* it was lxd autostarting things. now that you say it I don't know.
<juliank> Hence my thought that it's juju trying to bring up the units
<juliank> I probably should move the entire juju thing into a multipass VM so I can shut it down more cleanly
<rbasak> Is it just me or has Firefox's performance and stability nosedived in recent months?
<gQuigs> xnox: new push for DNSSEC to be working..  do we still need the DVE-2018-0001 workaround?  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501
<ubottu> Launchpad bug 1796501 in systemd (Ubuntu Disco) "systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes" [Medium,In progress]
<gQuigs> it seems to clearly cause some DNS failures that otherwise would work
<rbasak> Oh, I think it was GNOME leaking something. Sorry Firefox
#ubuntu-devel 2019-08-01
<RikMills> sil2100 seb128: hi, can I draw your attention to this:
<RikMills> [09:51] <sitter>  btw maybe someone can find someone to poke about https://bugs.launchpad.net/ubuntu/+source/libpwquality/+bug/1834480 it's gonna be impacting plasma 5.17 when I land https://phabricator.kde.org/D22122
<ubottu> Launchpad bug 1834480 in langpack-o-matic "translations in not so ideal language-pack" [Undecided,New]
<ahasenack> tjaalton: hi, around? Could you please take a quick look at this paste: https://pastebin.ubuntu.com/p/ZzW8BG2fpm/ line 16
<ahasenack> it seems to imply there is an invisible default /etc/sssd/sssd.conf file
<ahasenack> I'm checking in the debian build now to compare
<ahasenack> same in debian
<tjaalton> ahasenack: and this is with the latest 2.2.0?
<ahasenack> yes
<ahasenack> the install doesn't fail
<ahasenack> tests pass
<ahasenack> but the socket services try to start, and fail like that
<ahasenack> I'm wondering if they could use a ConditionFileNotEmpty
<ahasenack> I guess fedora/rh don't see this because they don't start services by default?
<ahasenack> I'm ready to send an email to sssd-users@
<tjaalton> well no-one has complained about it on debian
<tjaalton> I don't know why it thinks sssd.conf is there
<ahasenack> it also happens there, this is the postinst output:
<ahasenack> tjaalton: https://pastebin.ubuntu.com/p/5cSFT4hmnJ/
<tjaalton> so it needs sssd.conf?
<tjaalton> I haven't used it in a while..
<ahasenack> a few other services start
<ahasenack> these 3
<ahasenack>  1871 ?        Ss     0:00 /usr/sbin/sssd -i --logger=files
<ahasenack>  1872 ?        S      0:00  \_ /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
<ahasenack>  1873 ?        S      0:00  \_ /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
<ahasenack> probably noops
<tjaalton> there's your nss
<ahasenack> but sssd-nss.service stays it's disabled, is this the same?
<ahasenack> execstart for sssd-nss.service has "ExecStart=/usr/libexec/sssd/sssd_nss ${DEBUG_LOGGER} --socket-activated"
<tjaalton> did you have sssd running before the upgrade?
<ahasenack> nope, fresh install in debian-sid
<ahasenack> (same case in ubuntu)
<ahasenack> sssd spawned sssd_nss, but there is also a systemd service file for sssd-nss
<ahasenack> is this a case where one would choose one or the other? Either start it from the get-go, or use socket activations?
<ahasenack> I'm thinking the default implicit config (without sssd.conf) assumes it should start, and we are at the same time trying to use socket activation, but the socket activation is a bit incompatible with this implicit ssd.conf
<tjaalton> I need to test on a vm
<tjaalton> sounds like it should use different defaults when starting without a conffile
<tjaalton> or not start at all
<ahasenack> we could add a ConditionFileNotEmpty, or whatever it's called
<ahasenack> to the socket systemd services
<ahasenack> but it sounds like two categories of services: the normal ones, where you just start it even if it's not used,and the socket activated ones
<ahasenack> starting both seems wrong
<tjaalton> socket activated ones shouldn't be "started"
<tjaalton> so the postinst output looks weird to me
<ahasenack> if we do nothing against it, dh_installsystemd will enable it on first install
<tjaalton> meh, when is samba-common-bin postinst going to be fixed to not fail when smb.conf isn't around
<ahasenack> hm, "The services' list is optional on platforms where systemd is supported, as they will either be socket or D-Bus activated when needed."
<tjaalton> I was wrong, the socket listener is actually started and is shown by systemctl
<tjaalton> anyway, with the conffile from examples it'll work properly, so the daemon defaults are just wrong
<ahasenack> you mean defaults without a conffile
<tjaalton> yep
<tjaalton> upstream says it shouldn't start with sssd_nss
<ahasenack> it's the same about all others
<ahasenack> Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3014]: The sudo responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf.
<ahasenack> sudo, for example
<tjaalton> yes, but for the same reason
<tjaalton> with a dummy conffile it's fine
<ahasenack> so "services" suddenly grew a long list of defaults if there is no sssd.conf
<tjaalton> something like that
<ahasenack> I emailed sssd-users@
<tjaalton> I'm talking with lslebodn
<ahasenack> who is that?
<ahasenack> and which channel, assuming it's irc?
<tjaalton> #sssd
<tjaalton> lukas slebodnik
<tjaalton> from redhat
<tomreyn> is 18.04.3 likely to happen today, i.e. are there known reasons making it unlikely right now (i'm aware such can come up later)?
<tjaalton> tomreyn: no, delayed for one week
<tomreyn> thanks tjaalton , did i miss an e-mail on this? or will there likely be one?
<tjaalton> uh, there isn't one?
<tomreyn> not on -announce or -release
<tjaalton> ok then
<tjaalton> well that's what I heard somewhere
<tjaalton> maybe I'm wrong
<tomreyn> i'm looking at https://lists.ubuntu.com/archives/ubuntu-announce/
<tomreyn> is this the right place?
<analogical> tjaalton, how do you know that 18.04.3 is delayed for a week??
<tjaalton> I don't
<tjaalton> it was a rumor it seems
<tomreyn> sorry to hear this ;)
<tjaalton> ahasenack: so, the verdict is that socket activation just doesn't work without a conffile right now. but it doesn't actually break anything, once sssd has been configured and restarted it's all fine
<tjaalton> trying to find where the defaults are set
<tjaalton> should be a simple patch
<ahasenack> should we add a ConditionFileNotEmpty?
<ahasenack> for sssd.conf
<tjaalton> service you mean?
<tjaalton> sssd.service
<ahasenack> I mean to the systemd socket files
<ahasenack> so they won't start without a config file
<ahasenack> sssd starts fine, albeit useless
<tjaalton> I won't do that in debian ;)
<ahasenack> no prior art?
<tjaalton> looks like src/confdb/confdb_setup.c needs fixing
<tjaalton> it's a non-issue mostly
<tjaalton> install is noisy, that's all
<ahasenack> and if someone checks the status output, as suggested in that output
<ahasenack> but nothing broke, as evidenced by the tests even
<tjaalton> I'll patch the fallback setup instead
<ahasenack>     char fallback_cfg[] = ... <-- that bit
<gaughen> Apologies all, the point release is delayed.
<ahasenack> although it's not listing sudo and the others
<gaughen> it will not happen today, there were issues found in kernel testing.
<tjaalton> to match the patched examples/sssd.conf
<tjaalton> ahasenack: I think socket activation breaks if services lists any of them
<ahasenack> yes, it's one or the other
<ahasenack> but this implicit config, when there is no config file, isn't listing sudo or the others, and they are still complaining that they were listed
<tjaalton> the output just assumes there's a conffile with services=
<tjaalton> tomreyn: ^ the release is in fact delayed
<tomreyn> tjaalton, gaughen: thanks for the notice - can you say until when it'll be postponed, yet, should users check ubuntu-announce for a notice on this?
<gaughen> tomreyn, tjaalton last I knew the plan was for next Thursday, but infinity would have the latest info has he's running the release
<gaughen> tomreyn, I do not think that's an unreasonable expectation, apologies for dropping this on y'all at the last minute
<tomreyn> personally i'm always happy with delays if it helps stabilizing a release.
<tjaalton> ahasenack: patching it didn't help for some reason
<ahasenack> tjaalton: you just dropped the services line?
<ahasenack> in that fallback config
<tjaalton> yes
<tjaalton> then I created a conffile which matches the fallback, and then it works.. so looks like the checker is broken
<tomreyn> so, since it's EOB in UK, should we expect an e-mail or other announcement about the 18.04.3 delay?
<vorlon> there will be an email announcement; the release manager is not on UK time
<tomreyn> great :)
<tjaalton> ahasenack: check_socket_activated_responder() checks for the conffile, and if it doesn't exist, bails out
<tjaalton> ahasenack: I'm currently bisecting a kernel for a regression found in 5.0, so if you have time to poke sssd further then feel free to ;)
<LocutusOfBorg> hello, broadcast question: (I'm talking about flang): how can a package that *never* installs libomp5 in the build process runtime depend on it?
<LocutusOfBorg>  Depends: libc6 (>= 2.29), libgcc1 (>= 1:3.0), libomp5 (>= 0.20130412)
<ahasenack> tjaalton: thanks for the troubleshooting done so far
#ubuntu-devel 2019-08-02
<RAOF> LocutusOfBorg: Something that it *does* install in the build process can list a `libomp5` dependency in their shlibs file?
<LocutusOfBorg> RAOF, already fixed thanks
<LocutusOfBorg> this is the patch
<LocutusOfBorg> http://launchpadlibrarian.net/435533493/llvm-toolchain-7_1%3A7.0.1-8ubuntu1_1%3A7.0.1-8ubuntu2.diff.gz
<LocutusOfBorg> basically libomp5-7 shlibs file started with:
<LocutusOfBorg> libomp.so.5 libomp5
<LocutusOfBorg> instead of
<LocutusOfBorg> libomp.so.5 libomp5-7
<LocutusOfBorg> so dpkg-shgenlibdeps or whatever is called was taking the wrong value when calculating runtime dependencies
<LocutusOfBorg> and this bug never got spotted because the libomp5 points to llvm-default implementation
<LocutusOfBorg> in Ubuntu we have that bug because llvm-8 is the default, while Debian still has llvm-7
<LocutusOfBorg> (so forcing an old libomp-dev
<LocutusOfBorg> (so forcing an old libomp-7-dev was not working, because at runtime it was replaced with libomp5 that points now to libomp5-8, because of the new default (and libomp5-8 conflicts with libomp5-7)
<LocutusOfBorg> a nightmare it took two weeks to figure out
<RAOF> Oh, man. That sounds intensely frustrating.
<RAOF> Good work on figuring it out!
<LocutusOfBorg> it was a good learning experience
<LocutusOfBorg> (this is what I usually say when I loose time doing something)
<LocutusOfBorg> :D
<rafaeldtinoco> rbasak: https://github.com/Cacti/cacti/pull/2873/commits/b14b3da3d10a4ddf70b2514a998fa65ebf4ab3bb
<rafaeldtinoco> and
<rafaeldtinoco> https://salsa.debian.org/cacti-team/cacti/merge_requests/1
<rafaeldtinoco> All synced now, waiting on upstream for good
<rafaeldtinoco> and waiting on debian as well
<rbasak> Thanks!
<rafaeldtinoco> mp!
<rbasak> rafaeldtinoco:
<rbasak> You need to watch for MariaDB
<rbasak> It's version 10
<rbasak> Or higher
<rbasak> So >8
<rafaeldtinoco> oo
<rafaeldtinoco> sh*
<rafaeldtinoco> lol
<rafaeldtinoco> alright, ill fix that
<rafaeldtinoco> tks! totally missed it
<CarlFK> should I make ryan figure out why the import doesn't work now that he changed the slug?
<CarlFK> whoops.. ignore that :p
#ubuntu-devel 2019-08-03
<LocutusOfBorg> Wimpress, hello, thanks for caja extensions
<LocutusOfBorg> however the delta is still needed partially...
<LocutusOfBorg> checking for UPNP... no
<LocutusOfBorg> configure: WARNING: you need gupnp installed to build the upnp plugin (disabling sendto plugin)
<LocutusOfBorg> however I'm not autoconf savvy to craft a retro-compatible patch
<LocutusOfBorg> upstream has a patch https://github.com/mate-desktop/caja-extensions/pull/53/files
<LocutusOfBorg> this one can be applied to Debian as-is https://launchpad.net/ubuntu/+source/caja-extensions/1.22.0-2ubuntu2
<Wimpress> LocutusOfBorg: Thanks for your fixes ð
<Wimpress> I'll incorporate your fixes in Debian.
<LocutusOfBorg> Wimpress, not that easy... looks like the autoconf check is not exporting a required variable
<Wimpress> We'll sort it. On vacation, but it on my list of tasks ð
<LocutusOfBorg> I'm trying to fix it now
<LocutusOfBorg> I might have a "fix"
<LocutusOfBorg> Wimpress, upstream pr updated with my findings https://github.com/mate-desktop/caja-extensions/pull/53
<LocutusOfBorg> it might be not looking that good, but works in both old and new gupnp https://launchpad.net/ubuntu/+source/caja-extensions/1.22.0-2ubuntu3
<LocutusOfBorg> and is upstreamable in debain
<Wimpress> Nice one, thanks!
<malina> after months and months of a passthrough win kvm/qemu, an update? (didn't reboot for a week), now stops gpu(nv) to bepicked up by vfio, unlike before. I added softdep nv/nouv* to ...-load.d/vfio.conf or ratrrher in modprobe.d , and it is agaain caught. However, now when I start the vm, which 'starts' the screen is blank and possibly the passed through controller with trhe hids (kb/m), doesn't seem necessarily to switch over (not sure due to
<malina> scree nbeing all blank). recent qemu updates? apparmour? libvirt? something something? where could I find maintainers of these packages? Feel the 'support channel' might be too simplistic.
#ubuntu-devel 2019-08-04
<bigon> hey, anybody knows what is "QRT-Packages" that appears in some dep8 tests?
#ubuntu-devel 2020-07-27
<mwhudson> so why is popularity-contest not on component mismatches yet?
<mwhudson> oh becuase debian-goodies recommends it
<mwhudson> and debian-goodies is in supported-sysadmin-common
<sil2100> tseliot: hey! Could you verify the ubuntu-drivers-common SRU for focal today?
<sil2100> tseliot: since we want to get rid of all those dpkg-dev deps that are being pulled into focal
<sil2100> For the point release
<tseliot> sil2100: sure
<sil2100> Thanks :)
<rbalint> doko, could you please take a look at LP: #1889069 ?
<ubottu> Launchpad bug 1889069 in gcc-10 (Ubuntu) "glibc FTBFS with gcc-10 10.2.0-3ubuntu1" [Undecided,New] https://launchpad.net/bugs/1889069
<doko> rbalint: you're missing the b-d on g++-10-multilib
<doko> xnox: did you recheck icu with -O3 on ppc64el?
<xnox> doko:  no. Do you want me to?
<xnox> oh i guess gcc-10 might make the difference there.
<xnox> doko:  started build in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4163/+packages if that passes, we can reject icu upload, and do a sync.
<xnox> or like just remember to sync next time icu is uploaded in debian.
<xnox> doko:  ok, it built fine with -O3 now.
<xnox> doko:  what do you want to do? reject current icu, and sync it instead?
<rbalint> doko, thanks, fixing
<xnox> doko:  otherwise icu build finished on all arches, and can go through binary NEW across the board.
<dgadomski> hey bdmurray, whenever you have a moment I'd appreciate your opinion about the apport patch for bug 1881976, thanks!
<ubottu> bug 1881976 in apport (Ubuntu Focal) "apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)" [Medium,In progress] https://launchpad.net/bugs/1881976
<sil2100> tseliot: hey! How's the verification of u-d-c going?
<tseliot> sil2100: I am double checking something, as I ran into a problem
<tseliot> sil2100: I have to upload a one-line change
<sil2100> tseliot: please give me a poke once you do - I can review/accept it (remember to build the source package with -v so that we get the previous changelog entries et.c)
<tseliot> sil2100: I will, thanks
<tseliot> sil2100: ok, I've just uploaded ../ubuntu-drivers-common_0.8.4~0.20.04.2
<sil2100> On it
<tseliot> thanks
<tseliot> sil2100: ok, I verified the SRUs. It's all good with the new upload :)
<sil2100> tseliot: phew, thanks a lot! :)
<tseliot> sil2100: thank you ;)
#ubuntu-devel 2020-07-28
<IPv2> vorlon: I hope you're the right person to ask - if not, I'd be very grateful for a pointer. :-) Ubuntu long-term user but brand new maintainer here. (Big thanks for all your work on Ubuntu, which I've been running as my primary OS for 12+ years.) My package sup-mail needs to be marked as badtest on i386 (like its dependencies are) to allow it to migrate into the Groovy release pocket. I've raised a
<IPv2> merge proposal: https://code.launchpad.net/%7Eubuntu-release/britney/hints-ubuntu/+activereviews - are you the right person to cast your eyes over it please? (I picked your name because you are the most active person, by far.)
<LocutusOfBorg> hello RAOF mir merge please? its FTBFS because of protobuf
<RAOF> LocutusOfBorg: Thanks for the ping. I *think* it's syncable, but I'll just check.
<RAOF> Urgh. Just missing the wlcs autopkgtest. â¹ï¸
<RAOF> LocutusOfBorg: I'm EOD now; I'll get to that tomorrow. If you want to handle it sooner, the only really interesting diff dropped in Debian is the wlcs DEP8 test, which you could just drop in.
<LocutusOfBorg> sorry RAOF I really miss the context... BTW I'm trying to fix the s390x build failure that seems a real bug
<LocutusOfBorg> not fixed in new release https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1889167
<ubottu> Launchpad bug 1889167 in mir (Ubuntu) "mir: build failure on s390x" [Undecided,New]
<RAOF> Oh, huh. Debian probably didn't see that because they disable warnings-are-errors.
<RAOF> I wonder why that doesn't get hit on any other arch? It doesn't seem like it should be arch-specific
<LocutusOfBorg> RAOF, ehm they don't build on s390x
<LocutusOfBorg> RAOF, seems to happen with default -O3 or somethign like that
<tseliot> sil2100: hey I have found (and fixed) LP: #1889181 . I have uploaded that to groovy and to focal-proposed
<ubottu> Launchpad bug 1889181 in ubuntu-drivers-common (Ubuntu Focal) "ubuntu-drivers: fails with the deprecated autoinstall argument" [High,In progress] https://launchpad.net/bugs/1889181
<sil2100> tseliot: ouch, too bad we missed it previously!
<sil2100> Accepted
<LocutusOfBorg> mitya57, hello, I uploaded a compiz with some gcc-10 related fixes, but looks like there is a test failure now, can you please have a look?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/compiz/1:0.9.14.1+20.10.20200526-0ubuntu3
<LocutusOfBorg> also the fixes, looks trivial but I'm not over confident on the code
<mitya57> LocutusOfBorg: not right now, but added to my TODO list
<mitya57> LocutusOfBorg: can you make a merge proposal for git branch with your changes?
<LocutusOfBorg> mitya57, I see an ubuntu auto import on code...
<mitya57> LocutusOfBorg: I mean upstream, https://code.launchpad.net/compiz
<mitya57> Because it's managed by Bileto.
<LocutusOfBorg> mitya57, sure
<LocutusOfBorg> mitya57, not sure if I did it correctly https://git.launchpad.net/compiz
<mitya57> LocutusOfBorg: ah, you committed it directly. That's fine too, thanks!
<LocutusOfBorg> I di follow what was copy-pastable on that page, I was looking to the link to open a merge request, and I found none, and after... magic! it was already there
<LocutusOfBorg> btw the test seems to fail only on s390x
<LocutusOfBorg> https://launchpadlibrarian.net/490456150/buildlog_ubuntu-groovy-s390x.compiz_1%3A0.9.14.1+20.10.20200526-0ubuntu3_BUILDING.txt.gz
<LocutusOfBorg> mitya57, looks like this is the last blocker for protobuf migration
<tseliot> sil2100: thanks, I'll proceed to verify it
<ricotz> xnox, hi, please push a rebuild of source-highlight for the new boost-icu combination
<tseliot> sil2100: verified. All good now
<LocutusOfBorg> mitya57, is it ok to disable testsuite for now (wrt compiz)?
<mitya57> LocutusOfBorg: it's ok. I will investigate it in a few hours, but if it's blocking protobuf then go ahead.
<mitya57> Please disable on s390x only.
<vorlon> IPv2: branch landed, thanks!
<IPv2> vorlon: Greatly appreciated, thank you very much! Favour to ask please: are you the right person to press the retry button on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sup-mail please? (I get a permission denied error)
<vorlon> IPv2: the i386 tests don't need retried; the next proposed-migration run will simply move it from 'Regression' to 'Ignored failure'
<vorlon> IPv2: (but, any Ubuntu developer can hit the retry button)
<IPv2> vorlon: Perfect - I'll wait for the next run. Appreciate the pointers. Thanks again!
<xnox> ricotz:  ack, will do in a minute.
<ricotz> xnox, thanks
<LocutusOfBorg> compiz reuploaded
<mitya57> LocutusOfBorg: unreproducible on zelenka.debian.org :(
<mitya57> 100% tests passed, 0 tests failed out of 1465
<ricotz> xnox, did you forget about source-highlight?
<ricotz> ah never mind, there it is https://launchpad.net/ubuntu/+source/source-highlight/3.1.9-1.2build2
<mwhudson> good morning
#ubuntu-devel 2020-07-29
<xnox> vorlon:  I am failing to test my latest edition of resolved integration with ifupdown & isc-dhcp by upgrading xenial to groovy. Because of invalid shell syntax in ifenslave. I don't think diff conflict markers are valid in dash sh.
<xnox> https://git.launchpad.net/ubuntu/+source/ifenslave/tree/debian/ifenslave.if-pre-up?h=applied/ubuntu/devel#n129
<xnox> vorlon:  do you want to fix it up? or should i? can we just sync ifenslave at this point?
<xnox> (forcesync)
<xnox> vorlon:  it is orphaned in debian, so we can just upload our delta there.
<vorlon> "diff conflict markers" well then
<vorlon> xnox: I don't know than any of these changes are correct in Debian where ifupdown still exists
<vorlon> xnox: I'd rather we just get back in sync with Debian as-is given that this is a universe package that depends on ifupdown
<cpaelzer_> sergiodj: there must have been two libpcap uploads even we couldn't find the first one yesterday
<cpaelzer_> bdmurray: was so kind to SRU-accept one and cancel the other
<niub> o/ is there a place where I can see all the bug related to a specific kernel version?
<niub> I think there is a bug in 4.15.0-109.110 related to btrfs
<rbasak> jamespage: o/ I'm looking at openvswitch in the SRU queue. Looks like your Xenial upload got trumped by a security update, sorry.
<rbasak> Looking at Bionic now
<jamespage> rbasak: no worries - I'll rebase
<jamespage> thanks
<jamespage> rbasak: bdmurray pinged me about the duplicate uploads as well
<jamespage> there more recent one is not based on a git snapshot so the delta is smaller
<rbasak> I spotted your comment in the bug and rejected the older one as requested
<rbasak> Thanks!
<jamespage> brill thankyou
<rbasak> jamespage: where did you get the new orig tarball from? It seems to mismatch https://www.openvswitch.org/releases/openvswitch-2.9.6.tar.gz - different compression, but also the raw tar
<jamespage> rbasak: d/copyright triggers a repack
<jamespage> gz->xz and exclusion of some files
<rbasak> Ah - thanks!
<rbasak> I can figure it out from there then. Seems odd and maybe wrong though - no dfsg label, and only debian/ excluded? Isn't that automatic with 3.0 (quilt) anyway?
<rbasak> To be clear, I'm not bothered about that for the SRU - just thought I'd mention it
<xnox> vorlon:  looking at the code, what we have in 2.9ubuntu1 de-races bringing multiple bonds up. I do not see anything remotely close to fixing that in debian. I've uploaded a revert back to 2.9ubuntu1 as 2.10ubuntu2
<xnox> vorlon:  cause i'd rather keep bonds working the same way they did in focal and down.
<xnox> vorlon:  hm, but i should drop the ifenslave binary i guess.
<rbasak> doko: on bug 1888386, shouldn't these go via the security pocket?
<ubottu> bug 1888386 in openjdk-14 (Ubuntu) "SRU: backport the openjdk-13 and -14 security releases to focal" [Undecided,New] https://launchpad.net/bugs/1888386
<doko> rbasak: when I talked with vorlon and sil2100, they preferred the updates pocket. but I don't mind
<sergiodj> cpaelzer_: that's great, thanks bdmurray :)
<xnox> mwhudson:  it would be nice if you use -x option to git cherry-pick when cherrypicking things. I.e. it's hard to see in livecd-rootfs bionic, which commits have been cherrypicked and which ones are still missing.
<GunnarHj> Hey sil2100! The bionic langpack testing deadline is reached:
<GunnarHj> https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
<sil2100> GunnarHj: oh well, it's better than what I expected anyway
<sil2100> Thanks!
<sil2100> I'll publish those a bit later
<GunnarHj> sil2100: Yeah, at least some of the most important languages were tested.
<ahasenack> sil2100: hi, if you are around, looks like bileto doesn't like it when a binary package is no longer built: https://bileto.ubuntu.com/excuses/4170/groovy.html
<ahasenack> in this case, it's a transitional package I can finally drop
<ahasenack> "missing build on all: libpmemobj-doc (from 1.8-1ubuntu1) "
<ahasenack> can that check be ignored?
<mwhudson> xnox: til
<Laney> ahasenack: I think https://git.launchpad.net/bileto/tree/britney/britney.conf.in needs to get https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney.conf#n32 options ALL_BUILDARCH and HAS_ARCH_ALL_BUILDDS
<Laney> if you wanted to submit a merge proposal that would probably be welcomed :>
<ahasenack> I have no idea how britney works
<ahasenack> but let's see
<Laney> without those options britney thinks there's an arch called 'all' which can fail on its own
<Laney> so I think it's going "omg where are the binaries for 'all' which I knew about before, I don't have any"
<ahasenack> Laney: this? https://pastebin.ubuntu.com/p/DPB45jnRf6/
<Laney> ahasenack: looks right to me
<ahasenack> hmpf, I miss a "fork" buttin in lp
<ahasenack> butotn*
<ahasenack> now to figure out the push url
<ahasenack> ok, got it
<ahasenack> done
<Laney> I'd merge if I could!
<ahasenack> :)
<ahasenack> thanks! :)
<ahasenack> I also don't know if there is a separate deployment step
<Laney> me neither
<cjwatson> fork button> it's coming!
<mwhudson> is the huge build queue fallout from the outage or did the archive rebuild get started?
<mwhudson> actually to be that huge it must be the rebuild
<cjwatson> mwhudson: Test rebuild, yes
<mwhudson> cjwatson: ta
<cjwatson> The outage should be cleared, and so far fixed in a couple of different ways ...
<cjwatson> (Cowboyed code fix for my stupid max/min mistake; code fix under review to move the slow bit of database interaction to a better place; configuration change to have fewer concurrent download connections; code fix under review to make the librarian client use epoll rather than select so that it doesn't matter if the download process pool has lots of FDs open; and some OpenStack thwacking for ...
<cjwatson> ... ppc64el builder resets)
<cjwatson> Test rebuilds are good at shaking out this sort of problem
<cjwatson> Some of this has probably been latent for a while and causing low-level problems, just not quite enough to track down and fix
<mwhudson> cjwatson: nothing like fixing bugs several times over
#ubuntu-devel 2020-07-30
<LocutusOfBorg> smb, hello, xen merge please? the Debian release fixes CVEs...
<smb> LocutusOfBorg, I gladly will allow anyone who wants to have that erm... joy. More seriously, maybe in the next weeks but I more and more lack time to do those other things.
<ahasenack> sil2100: hi, did you see my message from yesterday about bileto and it complaining about the "all" architecture?
<ahasenack> sil2100: Laney suggested this: https://code.launchpad.net/~ahasenack/bileto/+git/bileto/+merge/388324
<sil2100> ahasenack: oh, looking! But from the first glance it looks good
<sil2100> ah this new britney
<Laney> might be worth doing a diff of the whole config ...
<doko> LocutusOfBorg: are you going to extract the ICE information for the llvm-11 build?
<LocutusOfBorg> why should we do it right now?
<LocutusOfBorg> I don't want to use llvm-11 as default in groovy
<LocutusOfBorg> its completely unstable, just an rc
<LocutusOfBorg> interestingly it didn't happen in Debian, meh
<LocutusOfBorg> doko, https://launchpadlibrarian.net/490817056/buildlog_ubuntu-groovy-armhf.ns3_3.31+dfsg-2_BUILDING.txt.gz
<LocutusOfBorg> mmmm lots of ices... looks suspicius?
<xnox> "I don't want to use llvm-11 as default in groovy" -> right now, or at all? cause i hoped that groovy final will have llvm-11 because of all the CET goodness on amd64
<tjaalton> yeah I'd expect mesa to migrate to it
<mwhudson> releasing subiquity to stable
#ubuntu-devel 2020-07-31
<LocutusOfBorg> rbalint_, forked-daapd update to new release please? there is a gcc-10 error that is tricking me
<LocutusOfBorg> and json-c is waiting for it
<LocutusOfBorg> well, I fixed it, will post the patch to the debian bug
<ahasenack> sil2100: hi, did you get a chance to look at that bileto mp?
<sil2100> ahasenack: hi! Yes! It looks good, let me merge it in a moment
<ahasenack> sil2100: thanks! Does it also need a new deployment?
<ahasenack> or merging is enough?
<sil2100> Merging is enough, it will be auto-deployed in 30 minutes
<ahasenack> nice
<melodie> hello!
<melodie> I am back since a few days ago with a question related to the languages at the boot of the live Ubuntu
<melodie> does someone know how that works, under the hood?
<melodie> who should I ask?
#ubuntu-devel 2020-08-01
 * xnox ponders how quick xnox[m] will see this
<Unit193> Usually a 20 minutes to an hour. :>
<Unit193> ...Well that's super useful, mkinitramfs sets PATH to /usr/bin:/sbin:/bin while /usr/share/initramfs-tools/hooks/zz-busybox-initramfs helpfully calls update-ca-certificates which of course is in /usr/sbin..
