#ubuntu-devel 2005-01-31
<Kamion> jdub: oh god
<elmo> ok, processed
<Kamion> we are going to need to publish a script to tell people how badly broken their systems are :P
<thully> is the live CD looking better? specifically, is ipw2200 working properly now?
<jdub> Kamion: i'm considering writing a mail about it, both to them and to ubuntu-users
<mdz> thully: that's the fix I speak of
<Kamion> thully: on its way ...
<ajmitch> how hard will it be for those people to upgrade to hoary?
<Kamion> ajmitch: many of the versions in those repositories are greater than those in hoary, so apt will not upgrade them automatically
<ajmitch> Kamion: that's what I was worried about..
<ajmitch> causing much pain & anguish
<Kamion> I'm not sure it's possible to tell, but they might have pretty much arbitrary breakage
<thully> when will the live CD be ready?  
<mdz> ready for what?
<thully> the one w/the hotplug fix
<mdz> it'll be ready for a round of testing in ~15 minutes or so
<mdz> I'm just waiting for casper 0.22 to appear on mirnyy
<azeem> maybe you can instruct them to adjust apt preferences, and pin Ubuntu's warty above all else and apt-get dist-downgrade'
<Kamion> I think more like ~45 minutes
<mdz> uploaded at 2236 UTC
<Kamion> elmo's processing probably didn't beat cron.daily
<mdz> (build log dated 2236, anyway)
<Kamion> yes, irrelevant 'cos it's byhand
<mdz> I meant the casper build log
<Kamion> oh
<mdz> I would have expected it to appear at :03 just now
<Kamion> sorry
<elmo> I can push cron.daily
<elmo> well once this one finishes
<Kamion> that would be good, thanks
<Kamion> :-)
<elmo> cron.continuously!
<thully> OK - guess I'll go fetch the daily iso now for install
<crimsun> azeem: if they can pin properly, they'd not need the warning ;)
<mjg59> Oh man
<mjg59> How did I never notice xgl before?
<Kamion> Hooray, my heinously awful archive-copier hack works
<daniels> lifeless: pong
<daniels> mdz: pong
<daniels> lifeless: run xrestop to see what's leaking your memory -- probably a client app
<mjg59> daniels: Have you played with xglx/
<buga> hi, are the popularity-contest results publicly available somewhere? popcon.ubuntulinux.org seems to be a bit outdated
<mjg59> ?
<elmo> mdz/jkamion: should be on mirrors now
<daniels> mjg59: nope
<daniels> mjg59: not much good without mesa-solo, anyway
<daniels> since you need to have an x server to run it on top of
<mjg59> Yeah, but presumably faster for composite development than trying to do it on i855?
<daniels> probably, yeah
<mjg59> How's mesa-solo coming along?
<daniels> really well, actually
<mjg59> Cool
<daniels> and soon we'll be able to build mesa and x separately, by the looks
<bob2> mesa-solo = X-less mesa?
<mjg59> So then we start concentrating on 3D support?
<mjg59> daniels: Oh, yeah, the crack all works now
<daniels> mjg59: sweet
<daniels> bob2: basically, yeah
<daniels> mjg59: well, then our build system gets less crap, and we're all using a modular X \o/
<sladen> so,   DRI -> mesa-solo -> xglx -> xlib  ?
<mjg59> That way we only end up with one hardware layer to support
<lifeless> battstat-applet-2
<mjg59> lifeless: Oh, yeah, that leaks badly in 2.9.4
<mjg59> davyd put out a 2.9.4.1 gnome-applets tarball that fixes it
<Kamion> elmo: thanks, building
<mjg59> Shame about legacy hardware without 3D engines...
* mjg59 looks at his old Thinkpad with a non-3D SMI Lynx
<daniels> sladen: er
<sladen> lifeless: prey tell me battstat doesn't flash annoyingly by default?
<lifeless> sladen: dunno what you mean
<lifeless> daniels: still using 8879 root       6 -10  869m 701m 5092 S  0.7 69.3  21:43.65 Xorg                                                                 
<lifeless> after killing battstatapplet
<daniels> lifeless: yes, the allocations don't die
<daniels> it's a leak in the truest sense
<lifeless> oh fragr
<mdz> elmo: thanks
<mjg59> Christ
<mjg59> Why does xserver's autogen.sh not work?
<mjg59> I hate autotools
<mjg59> Maybe it's GTK's fault
<daniels> mjg59: hm, how does it fail?
<Kamion> mdz: done
<mjg59> aclocal: configure.ac: 40: macro `AM_PROG_LIBTOOL' not found in library
<Kamion> cjwatson@little:~/cdimage/www/full/daily-live/current$ isoinfo -R -i hoary-live-i386.iso -x /install/initrd.list | grep ^hotplug-udeb
<Kamion> hotplug-udeb 0.0.20040329-16ubuntu10
<daniels> mjg59: errr
<Kamion> argh, why is base-config not starting gdm automatically?
<Kamion> somebody sucks and I don't know who
<mjg59> Ah. S/AM/AC/ on AM_PROG_LIBTOOL seems to help.
<daniels> Kamion: gtk
<mjg59> No, then autoconf complains
<daniels> re-run libtoolize --force --copy?
<mjg59> Nope
<robtaylor_> mjg59: it probbly needs certain versions of automake and fails to check for them
<robtaylor_> mjg59: try AUTOMAKE=automake-1.9 and see if that works
<robtaylor_> (this seems to be a common theme atm, god knows who started it, i'm sure it used to be normal for autogens.sh's to check versions :/) 
<robtaylor_> (revert that last s// 1st though ;) )
<robtaylor_> oh, and ACLOCAL=aclocal-1.9 =)
<robtaylor_> obviously ..
<robtaylor_> mjg59: any luck?
<mjg59> robtaylor_: configure.ac:41: error: possibly undefined macro: AC_PROG_LIBTOOL
<mjg59> (aclocal-1.9 && autoconf)
<crimsun> mjg59: did you `libtoolize -fc' ?
<daniels> mjg59: aclocal-1.9 && automake-1.9 && autoconf
<mjg59> crimsun: Yes
<mjg59> daniels: Same error
<robtaylor_> mjg59: what source tree? i'll take a look locally
<mjg59> robtaylor_: xserver from cvs.freedesktop.org
<crimsun> mjg59: where is your libtool.m4?
<crimsun> mjg59: in . ?
<mjg59> crimsun: Yes
<mjg59> mjg59@tyrosine:/tmp/xserver$ grep AC_PROG_LIBTOOL *.m4
<mjg59> libtool.m4:AU_DEFUN([AC_PROG_LIBTOOL] ,      [LT_INIT] )
<crimsun> mjg59: aclocal-1.9 -I . && automake-1.9 && autoconf
<mjg59> crimsun: Ok, that works
<robtaylor_> woo!
<crimsun> [I run across that all the time] 
<jdub> daniels: http://www.minion.de/files/1.0-6629/
<jdub> daniels: no idea what this is for, but some dude asked about it
<robtaylor_> mjg59: hmm, maybe a patch for autogen.sh is in order..
<crimsun> jdub: christian worked for Nvidia; he provides those patches.
<robtaylor_> check automake/aclocal version, and add -I . to the autoreconf line, i guess
<crimsun> jdub: he goes by 'zander' here on freenode.
<mjg59> Haha
<mjg59> Patches that we aren't actually legally allowed to apply at the moment
<jdub> oh
<mjg59> (but that's being sorted)
<jdub> i've heard about thoe
<mjg59> Nvidia fuckup on their licensing text
<robtaylor_> mjg59: ah
* robtaylor_ spanks nvidia one more time
<daniels> crimsun: oh, that's zander?
<daniels> mjg59: well, actually, we can now
<sladen> mjg59: before I try, do you reckon your fixed IRQ stuff avoids the need for pci=routeirq ?
<crimsun> daniels: yep, zander.
<mjg59> sladen: It should
* mjg59 goes to get a bath
<thully> Hi - sorry, I haven't tested the install CD yet (I was testing the timezone behavior) - Imay not be able to do so for a while
<thully> Does anyone know if live cd 0119.4 fixes the hotplug issue?
<daniels> which 'hotplug issue'?
<jdub> daniels: so what are these patches?
<daniels> jdub: various patches to the kernel code for the nvidia driver
<thully> issue w/wi-fi not loading properly
<thully> I was discussing it w/mdz
<daniels> jdub: looks like most of them are bugfixes for certain situations
* lamont takes his chalk and goes to the chalk board
<lamont> I WILL NOT TRY TO DIVERT CONFFILES
<lamont> *50
* Mithrandir pats lamont on the back
<mdz> thully: there is a new live CD build up which should fix that
<mdz> thully: I'm downloading it now to test
* robtaylor_ twangs an elastic band at lamont
* robtaylor_ looks innocent
<thully> OK - I'm downloading it now too, 0119.4, correct?
<lamont> heh
<mdz>  /current/
<mdz> should be the same
<thully> OK
<lamont> mdz: and that's what was wrong with the livecd, duh
<thully> I have to go now - have some things to do
<thully> bye
<ogra> is the frambuffer thingie with nvidia fixed ?
<elmo> uh, how do I convert a random iso-8895-nn file to xx from the command line?
<Mithrandir> elmo: iconv or recode
<mdz> lamont: diverting conffiles, eh?
<elmo> iconv says "conversion from iso-8895-1 not supported"
<lamont> mdz: any other locales?  Pre-generate some locales (en_{US,GB,ZA}.UTF-8)
<mdz> ogra: according to daniels, yes
<lamont> mdz: /etc/init.d/dbus-1 would be a conffile...
<Mithrandir> elmo: it's spelled 8859
<mdz> I'll be testing it shortly
<daniels> ogra: which framebuffer thingy?  the livecd stuff?  (if so, should be)
<mdz> lamont: let's start with those
<daniels> it should definitely work on i386
<mdz> lamont: how big are they?
<Mithrandir> not 95. :P
<ogra> daniels: amd64 :)
<daniels> ogra: (and amd64)
<lamont> mdz: the livecd needs some games, you know... :--)
<ogra> daniels: and i have a nice bug for you, i'll file on the weekend if i have time to switch to nv to track it
<mdz> lamont: are you ready to implement the live seed?
<daniels> ogra: awesome
<elmo> Mithrandir: fair point, well made
<daniels> mdz: comment on #5495?
<Mithrandir> ISO8895 -- Shaped insulating refractory products -- Determination of cold crushing strength.  I kinda understand iconv won't convert that. ;)
<Kamion> it would be cool if it did
<lamont> mdz: we could do that.
<lamont> just need an archive to check it out of, and we're golden
<ogra> elmo: btw, if its text you can open it in gedit, it offers to select the locale on save
<daniels> Kamion: no higher than 'enhancement', ok?
<Kamion> daniels: mm?
<daniels> you get to hit scott really hard for that one
<daniels> er, ww
<daniels> Kamion: the bug on iconv :)
<Kamion> oh :)
<lamont> mdz: the nice part is that the live seed just feeds straight into apt-get... no dependency deals or anything..
<lamont> for that matter -it should just go into ubuntu-meta as ubuntu-livecd, which depends: ubuntu-desktop
<mdz> lamont: let's have a round of ubuntu-devel about the live seed and what should go in it
<mdz> the last time, I remember there was some dissent
<mdz> (live should be the same as a desktop install, etc.)
<Kamion> I think I need to tweak germinate a bit to make the live seed really work properly, too
<Kamion> hm, or indeed work at all
<lamont> Kamion: it wouldn't need to be germinated
<Kamion>     for seedname in ("base", "desktop", "ship", "installer", "supported"):
<Kamion> it should be, IMO
<jdub> mdz: only silly pant stealers dissented with liveseed
<lamont> Kamion: ok.
<Kamion> I don't think there should be such a thing as a seed that doesn't get fed to germinate
<Kamion> because if nothing else you want to make sure the stuff stays in main
<lamont> hrm... yeah - liveseed might be broader than supported, eh?
<lamont> Kamion: games in main??? the heresy
<Kamion> live < supported, definitely
<Kamion> but there might be stuff in the text of the live seed not mentioned in the text of the supported seed
<lamont> right
<Kamion> I think we want base < desktop < ship < supported; base < desktop < live < supported; casper < (?) installer < supported
<mdz> it ought to be germinated, so we get a consistent set of stuff on the CD
<lamont> mdz: should be done staring at the changes and pushing a round of updates to all the buildds within the hour.  If you want a dbus-1 happy livecd before that, holler now and I'll go fix it in place and run it.
<Kamion> maybe just casper < supported and installer < supportd
<Kamion> ed
<daniels> mdz: bz email address changed (finally)
<jdub> lamont: livecd was dbus-1 unhappy?
<lamont> jdub: when you divert /etc/init.d/dbus-1 and then do a non-interactive install, you get /etc/init.d/dbus-1.dpkg-new, which is just not what you want later.
<mdz> daniels: thanks
<mdz> lamont: I'm about 1/4 of the way through downloading a full set
<jdub> lamont: oh. why does it need to be diverted?
<mdz> jdub: it had a bug
<mdz> (past tense)
<mdz> Kamion: is there an easy way to point cron.daily-live at an old version of the cloop images
<jdub> oh
<mdz> assuming lamont keeps them around?
<lamont> jdub: and the bug was fixed
<lamont> mdz: never been deleted :-)
<lamont> although the location did change
<mdz> that way, lamont can go ahead and build new images to test the new stuff
<mdz> but if there is a casper problem, I can build new live CDs without downloading another 1.5 gigs
<lamont> mdz: the other option is that if you need to build a new one, you can holler and I'll move the 'current' links back
<mdz> of course, that may become obsolete soon with the rsyncable stuff
<mdz> which would ROCK
<Kamion> mdz: yes, poke /srv/cdimage.no-name-yet.com/debian-cd/tools/add_live_filesystem
<Kamion> I'll let you do that though, I'm off to bed
<mdz> night
<Kamion> amd64 live CD on a bandwidth-limited download overnight
<haggai> has anyone seen this?
<haggai> W: GPG error: http://localhost hoary Release: Unknown error executing gpgv
<mdz> haggai: do you have gnupg installed?
<lamont> haggai: you building in a chroot and running apt in the chroot?
<lamont> or outside the chroot without gnupg installed.
<mdz> haggai: that means that waitpid() returned something unexpected after trying to fork-and-exec gpgv
<haggai> I have gnupg installed, and am running in the chroot
<lamont> -rw-r--r--  1 buildd root    549947608 Jan 19 23:27 livecd-20050119.5-ia64.cloop-1024:65536
<lamont> woot!
<haggai> lamont: I've seen the same thing in 2 seperate chroots
<haggai> lamont: and, I'm trying to get sbuild working.  Have you had the situation where it fails to install any build deps?
<azeem> haggai: what's the error message?
<haggai> azeem: I don't get any error message, just that W: line, and another one suggesting an apt-get update
<azeem> I think you need to run apt-get update in the chroot once to actually have the lists around, did you do that?
<haggai> yes I did
<haggai> same error
<azeem> are you running sbuild from ~/build? do you have links to your chroot in there?
<mdz> daniels: for some reason, when I reboot from GNOME on the live CD, I don't see the shutdown messages until the very end
<mdz> daniels: it seems unlikely to be livecd-specific
<mdz> I haven't tested on a standard install
<mdz> I get vc1 for a moment, and then a blank screen
<daniels> mdz: ack, I've seen that also; depends how I shut down
<daniels> mdz: if I just click through, it's fine
<daniels> mdz: it's likely to be due to our start-gdm-earlier stuff
<daniels> mdz: which has already had weird interactions with XKeepsCrashing if it fires at the wrong time
<mdz> daniels: yeah, I've seen that too
<mdz> daniels: I end up at the XKeepsCrashing dialog with my keyboard in raw mode
* daniels shrugs ...
<mdz> I just pound keys until I get out by sheer luck
<thully> The hotplug issue is fixed
<lifeless> daniels: so how can an X client force the server to leak. Surely thats bad ?
<daniels> lifeless: no, not at all
<thully> This actually should fix another issue I had - in the normal installer, my wi-fi wasn't available as a network interface to configure
<daniels> lifeless: you ask X to allocate a pixmap for you, then you never free it
<daniels> lifeless: the whole server/client thing means that pixmaps, et al, need to be stored server-side as well
<mdz> hda: dma_intr: error=0x01 { AddrMarkNotFound }, LBAsect=135032251, sector=135032072
<mdz> that does not look good at all
<lifeless> daniels: but when the client dies, surely you can walk back to the clients resources and free them.
<daniels> lifeless: not as such, because you can share them aiui
<daniels> lifeless: as they're just identified by an integer
<haggai> azeem: I'm running from ~build and there is a link to the chroot in there, and it finds it too
<lifeless> mmm, you could still know that the client that allocated it has gone, and I presume there are protocol to enable sharing (else it would be a security hole), so you can count as they get shared.
<daniels> lifeless: how would it be a security hole?
<daniels> lifeless: if you have access to the display, you own it
<daniels> lifeless: (just hide all the other windows and pop up one of your own that looks like Firefox doing internet banking)
<daniels> (or, more subtly, just grab all input)
<lifeless> client A has pixmap with the map for foo on it, client B is rogue and copies that pixmap.
<daniels> if client B is rogue, you have already lost in so many ways it's irrelevant
<lifeless> daniels: eek
<daniels> client B just pops up a window that's a direct screen-scrape of client A's
<daniels> or looks like a password dialog or something
<daniels> again: if an untrusted client has access, you have already lost
<haggai> azeem: hmm, not sure what it was that I changed but it's giving me a proper error now
<mdz> thully: thanks for testing
<daniels> there was a pretty half-arsed XSECURITY extension to try and control inter-client exchanges, but it was badly thought out, badly implemented, and even sun has long considered it a very poor idea
<daniels> the selinux guys are doing interesting things on that front, though
<mdz> thully: that was fast; I thought you were on a modem :-)
<robtaylor_> daniels: so if you have  client that allocates pixmaps (i.e. everything nowadays, no?) and it crashes regularly, that causes an irrecoverable memleak in the server?
<azeem> haggai: heh, can you make something out of it?
<daniels> robtaylor_: quite possibly
<thully> mdz - I downloaded it at another PC (not at home) where there's high speed net
<daniels> robtaylor_: iirc gtk's segfault handler will clean up quite well, for one
<thully> I got the hoary install iso too
<thully> will test that next
<lifeless> so, evolution borks regularly for me... ah gtk ok.
<robtaylor_> daniels: ah thats good to know ;0
<haggai> azeem: yeah, it's a build-dep not in main
<thully> mdz: This should take care of an issue with the installer not finding my wi-fi (in install mode) as well...
<robtaylor_> daniels: surely theres a way to refcoun them, as long as they're not MIT-SHM?
<robtaylor_> hell you can even refcount then, but that gets icky
<mdz> thully: the install iso will not have the wireless firmware fix yet
<haggai> azeem: I wonder if apt-proxy and authenticated apt have problems; I switched sources.list
<daniels> robtaylor_: probably, but you could also just pass the reference over to someone else out-of-band and they could use it later :)
<mdz> the next daily build will
<mdz> we did a new live CD build manually
<haggai> mdz: is there a config file option to disable the authentication stuff, or is it only a command line switch?
<mdz> haggai: both
<haggai> mdz: apt, I mean
<robtaylor_> daniels: gosh, didnt think that was possible... urrgle
<haggai> mdz: ah, an undocumented one then :)
<mdz> haggai: man apt-get
<azeem> haggai: bob2 had problems with authenticated apt and sbuild as well
<thully> I have to go now... I'll check out install iso later
<mdz> haggai: by design, all apt command-line flags have a corresponding configuration item
<azeem> haggai: which version of sbuild are you using?
<bob2> very weird ones
<haggai> mdz: ah, I see, the config option is with the command switch
<haggai> azeem: from unstable
<daniels> robtaylor_: aiui, this is the case, but client-side x library stuff isn't my forte
<haggai> azeem: I patched in hoary as a distro
<haggai> mdz: thx
<robtaylor_> daniels: is it anyones? ;)
<robtaylor_> (rhetorical..)
<daniels> robtaylor_: heh ... maybe owen taylor's
<azeem> haggai: if you tell me how to disable authenticated apt, I'll add that to the options sbuild passes to apt
<robtaylor_> daniels: theres some scary s**t in there, i remeber that much =)
<haggai> azeem: --allow-unauthenticated
<haggai> azeem: I don't know if it's necessary, though, assuming it all works
<azeem> I guess that will break on apt from unstable
<haggai> azeem: I think it might just be a problem with my local setup and apt-proxy.  Still, you do have to manually install gnupg in the sbuild chroot before it works
<haggai> azeem: true
<bob2> azeem: yah, is there a need for it to limit the valid distros?
<daniels> robtaylor_: heh, yah
<daniels> robtaylor_: 'swhy I steer clear
<azeem> bob2: no, and I proposed to just check whether there is ~/build/chroot-$dist
<lamont> hrmpf.  somebody upload something, k?
<robtaylor_> daniels: heh, sounds a sane plan to me ;)
<bob2> azeem: oh, that would be awesome
<robtaylor_> daniels: keithp probably once understood it ;)
<azeem> bob2: I'm gonna send of a 'ok to commit mail?' to nudge frankie
<azeem> off, even
<bob2> woo
<azeem> of course, now I have to patch that check out locally here again, or finally figure out how to use sbuild with a chroot on GNU/Hurd
<mdz> amd64 live CD looks good
<mdz> daniels: fb fix confirmed
<lamont> mdz: ok to build a new livecd fs?
<mdz> lamont: yes, thanks
<daniels> mdz: phat
<mdz> daniels: whatever that shutdown bug is, it's definitely worse now
<mdz> I never saw it before today
<lamont> our sbuild doesn't limit the valid distros
<lamont> azeem: bob2: ^^^
<sivang> mdz: shutting downd the hd and repowering it before complete shutdown?
<bob2> lamont: the one you're running on buildds or the one in hoary?
<sivang> I also got a segfault there once in a while..
<mdz> sivang: blank screen instead of shutdown messages
<lamont> actually, that reminds me... I need to send neruo my patches for separating the distros in to their own directories
<lamont> buidlds
<lamont> the one in hoary is the same nobody-uses-it version as debians
<sivang> mdz: eh, havn't tested reboot with latest update then.
<daniels> mdz: it's always been present for me
<daniels> mdz: except it's OK when I shut down from within GNOME
<azeem> lamont: what exactly do you mean, seperating the distros in to their own directories?
<lamont> build-$dist/chroot-$dist is the build directory
<lamont> lets me build different $dists in the same buildd, with different chroots
<lamont> or (what we'll first use it for): rebuild everything from scratch, stealing idle time from the buildd, to look for ftbfs's
<azeem> ah, ok
<haggai> lamont: very nice
<lamont> the non-trivial part is that some things need to stay in build/, while other stuff moves to build-$dist.
<azeem> yeah
<lamont> and I still have a few loose ends
<lamont> buildd-watcher and I are not particularly on good terms right now.
<lamont> $conf::separate_distributions
<lamont> happy happy joy joy
<mdz> daniels: I'm talking about within GNOME
<mdz> daniels: that used to work fine
<mdz> daniels: and now it doesn't
<sivang> lamont: ran and stimpy?
<daniels> mdz: unreproducible. i've gotta run for an hour (new phone!), so i can take a look after that
<lamont> sivang: that could be where I got that from
<lamont> it's been a while
<lamont> mdz: the build logs already have all of the entry points linked from DeveloperResources
<mdz> lamont: ok, thanks
<jdub> daniels: do you know about this crazy capslock per-top-level window foo?
<haggai> lamont: how did you do the ccaching on the buildds?
<lamont> /home/buildd/ccache is bind mounted as /home/buildd/.ccache in each of the chroots on the machine
<lamont> then we shim gcc into 'ccache gcc' everywhere
<haggai> how do you do that?  changing the default path to include the trampolines?
<haggai> lamont: in /usr/lib/ccache?
<lamont> gcc-3.3 is dpkg-diverted
* lamont customizes with a crowbar, you see..
<haggai> heh
<haggai> did you not know about /usr/lib/ccache, or did you find it did not always work?
<bob2> haha
<lamont> ccache actually came second.. tweaking gcc options came first
<haggai> ah :)
<lamont> which reminds me - I need to hijack g{cc,++}-3.4 as well.
<haggai> try putting /usr/lib/ccache at the front of $PATH
<haggai> that should be future proof
<mdz> that's what I use
<haggai> uh, except ccache doesn't have the gcc-3.4 trampolines yet :-/
<bob2> someone should start hacking on ldcache
<mdz> haggai: can't you upload to main now? ;-)
<haggai> mdz: yeah point taken :)
<lamont> mdz: I'm thinking I could just add the timing to the Developer Resources page.. Or I could move the BuildLogs to a new page that talks about 'what happens after I upload my source'
* lamont gets warned of an impending dragging out the door to dinner
<lamont> ls build.live/chroot-hoary/build/chroot-livecd/etc/init.d/dbus-1 
<lamont> build.live/chroot-hoary/build/chroot-livecd/etc/init.d/dbus-1
* lamont smiles
<mdz> lamont: sure, whatever works
* lamont takes his laptop and goes to dinner.
<sivang> mdz: read your thread about clicking an apt source and it get's added to the list, do I need to install some plugin for this to work?
<sivang> mdz: (doesn't work for me out of the box)
<mdz> sivang: what exactly did you click on?
<mjg59> daniels: Jesus. xglx is /usable/.
<sivang> mdz:  let's put it that way, what should I click on? something looking like this deb http://... ?
<mdz> sivang: the functionality that you're talking about does not exist yet
<mdz> but if it were implemented, it would be as a MIME type
<mdz> and so you would need a file with the information in it
<sivang> mdz: yes, but how can we identify deb [space]  http://... does MIME types allow for spaces in a "uri" ?
<mdz> sivang: I don't have time to explain this
<mdz> my hard drive seems to be failing
<sivang> mdz: maxtor?
<mdz> IBM
<sivang> hmm..the same, got on server down with 2 IBM disk failing about roughly one month one from the other..ergg.
<daniels> away
<daniels> jdub: this WHAT?
<jdub> daniels: whichwhichwhat?
* sivang reading about MIME
<daniels> jdub: caps-lock-per-top-elvel
<jdub> daniels: so put on caps lock
<jdub> daniels: mouse around your windows
<jdub> daniels: caps lock now seems to be a per-top-level-window setting ;)
<daniels> jdub: no way
<daniels> i use ctrl:nocaps, anyway ;)
<mjg59> daniels: I just had a see through terminal on top of a video window with drop shadows AND IT WAS ALMOST WATCHABLE
<daniels> jdub: oh my god, that's absolutely frightening
<daniels> mjg59: isn't it great how gl makes us all more productive?
<mjg59> I love gl
<mjg59> Pls to be providing more gl-based crack k thx bye
<mjg59> daniels: You'll be amused by this. I had to increase my colour depth to get xglx to work.
<mjg59> When I restarted X, it wouldn't start
<mjg59> It gave a VBE error
<daniels> mjg59: hah
<mjg59> I did a vbetool vbestate restore AND IT WORKED
<daniels> ... wack
<jdub> daniels: i have no idea where it is in the stack :)
<thully> hi everyone
<thully> mjg59: any luck w/ that BIOS?
<daniels> jdub: i blame svu
<mjg59> thully: Not as yet
<mjg59> It's being worked on
<mdz> fuck IBM
<mdz> there is a hard drive firmware update available which is rumoured to fix this problem
<mdz> but it is only installable from DOS
<mdz> and is too large to fit on a floppy
<mjg59> Always keep a DOS partitoin
<mdz> keep? no.  convert a swap partition into? maybe
<mjg59> Haha
<mdz> I don't even know if freedos will see my SCSI disk
* mjg59 has a 500MB dos partition at the start of the disk for this sort of thing
<mdz> mjg59: which you would use in order to update the firmware on said disk?
<mdz> :-)
<thully> where can I get it?  I could see if I can get freedos on this machine (man I wish I had a floppy drive now...)
* mjg59 decides he's done enough playing with translucent windows for one day and goes to bed
<thully> mjg59: did you see my e-mails about reworking suspend?
<mjg59> thully: Yeah, but I haven't had much of a chance to take a look at that stuff today
<mjg59> Ought to get to it before the weekend
<thully> OK - sounds good
<thully> So far, so good with the live cd - a few glitches, but is to be expected with a daily snapshot
<jdub> mjg59: can you think of any weird livecd/power-management interactions?
<daniels> mjg59: heh
<mjg59> None spring to mind - why?
<thully> one thing i've noticed, though, is that getting through the network step when there is no wi-fi near and you're not plugged into a LAn network is a pain
<thully> that would be the network step of debian-installer, both on the live cd and install cd
<thully> yes - I can
<jdub> mjg59: would be good to pimp the livecd for power management, particularly at preview
<thully> I put my laptop to sleep from the live CD, and when it woke up I couldn't execute any programs
<thully> I did do a simple echo 3 > /proc/acpi/sleep, though - however this has worked for me from HD installs
<thully> I just got an I/O error for each thing I tried to run
<mdz> did the hard drive spin back up?
<thully> I was booted from live CD
<thully> I never accessed the HD
<thully> BTW - I have no system tray applets on the current live cd build (no volume, battery, etc) - is this a known issue?
<mdz> it might be related to a known bug, I'm not sure
<thully> BTW - why was the default for autohinter switched from on to off?  I liked autohinter...
<jdub> mdz: actually, that's an interesting problem
<jdub> mdz: panel chooses default configuration at install time based on laptop-detect
<jdub> (because it's not possible to do it at run time atm)
<jdub> mdz: and fontconfig chooses subpixel based on laptop-detect
<thully> yes - I know subpixel is chosen based on laptop-detect - however, I wonder why autohinter isn't used also (on both laptop/desktop)  This seemed to make the fonts look much better (and was the default on hoary until recently)
<bob2> mjg59: are dell's generally useless for sleep/resume without a new dsdt?
<mjg59> thully: Autohinter works very badly with sub-pixel
<mjg59> bob2: Depends on the Dell. 
* netjoined: irc.freenode.net -> benford.freenode.net
<thully> In my experience, it has worked beautifully - that's funny.
<mdz> jdub: so I guess I should dpkg-reconfigure them from casper
<mjg59> thully: Try small font sizes with sub-pixel anti-aliasing and the autohinter
<mjg59> Without the autohinter, 6-point fonts are readable. With it, they're a blurry mess of colour.
<mjg59> If the autohinter could be enabled above a certain size, that would be a good compromise
<thully> I've had problems like that - but only on KDE, GNOME has always been fine (however, I don't use many 6-pt fonts)
<mjg59> Heh. All my terminals are 6-point
<thully> well - I'll try this - but I thought autohinter was working well before
<thully> the fonts looked like some of the best I've ever seen, especially on xorg w/latest freetype
<daniels> mjg59: you could probably wrap the autohinter definition in a if size > 6 glob
<thully> What did you think of autohinter >6pt, ou of curiosity
<mjg59> A slight improvement, I think
<mjg59> Oh, except on foreign fonts
<thully> For me, it seems great - may depend on the TFT.
<mjg59> The problem seems to be with fonts with fine details, which can be latin characters at small sizes or more intricate characters at larger sizes
<thully> Well, put something in the installer or the definition to not use autohinter on these fonts
<mjg59> thully: http://www.codon.org.uk/~mjg59/tmp/fonts.jpg - small font with autohinter
<thully> I wonder why KDE is always worse than GNOME with these fonts... seems weird
<mjg59> (sub-pixel is actually switched off in that one)
<thully> I see - you like small fonts in your terminals :)
<thully> I just use the default in GNOME's terminal, whatever that is
<thully> The thing that has caused the most trouble with the new live CD is how long it takes to boot.
<bob2> ogra_: congrats!
<thully> Part of this is that the installer makes it take a long time to get through network configuration without configuring a network (and you can't pick wi-fi if wi-fi isn't currently in range, on both the live and install cds)
<mdz> my system is always connected to a network, so I haven't noticed
<daniels> mdz: so ntpdate doesn't bite you in the arse :P
* daniels goes back to php4-imap.
<thully> well - I'm on a laptop, and I'm on and off dial-up and wi-fi
<thully> ntpdate always errors for me on boot
<thully> any way that the application-switching buttons on the taskbar could be enlarged?
<mdz> daniels: oh, you're fixing that?
<mdz> thully: right-click, preferences, Size tab
<daniels> mdz: well, you asked me to ...
<thully> I think they should be bigger by default - as they only take up this tiny area of the bottom taskbar and only show 1 character of the app name by default.
<mdz> ah, didn't see your followup comment
<thully> mdz: I can't find preferences - only properties and size there changes the size of the whole panel, not just the task buttons
<daniels> mdz: i assume we want it for hoary, no?
<mdz> daniels: yes
<daniels> phat
<mdz> thully: you need to right-click on the nub between the 'show desktop' button and the leftmost windowlist item
<thully> OK - sorry about that
<thully> Also, could somebody look into the network configuration part of the installer and make it more friendly to people who don't want to configure any network card, or who want to configure a network card but who aren't connected at the moment
<thully> Or they could just be auto-configured outside the install and something like ifplugd could be used
<jdub> ugh, fuse is merged in -mm
<daniels> thully: as I understand it, there's a 'I'm not on a network right now' option
<thully> I didn't see it - I just saw ethernet and wireless
<thully> Also, is it really needed during the install, if somebody isn't doing a net install?
<daniels> think: updates
<daniels> also configuring the network for the first time as to essid/ip/whatever
<daniels> not everyone has dhcp
<thully> It seems like it would be better to leave this for post-install
<thully> is anything being done with respect to ifplugd and the like (I know they were going to use NetworkManager, but decided against it)
<jdub> no, we've punted that to the next release
<jdub> will most likely be NM
<mdz> thully: the common case is that the system is connected to a network, and it makes sense to bring it up immediately
<thully> daniels: also, if you want to configure wi-fi it refuses to configure unless you are actually at a WAP
<mdz> on the live CD, it should fall back to not configuring the network, but that's polish for later
<thully> will the live CD use DHCP by default?
<mdz> that is what it does, yes
<mdz> so when I boot it in my laptop, I end up with the network available automatically, which is what I want
<thully> It seems like this network configuration should be modified to 1)allow somebody to configure wi-fi without being in range of a WAP 2)allow multiple network devices to be configured 3)have a clear option for "no network"
<mdz> there are far higher priorities at the moment
<mdz> for those currently working on the release, anyway
<mdz> if you or someone else are interested in making those improvements, that would be great
<thully> OK - I know that there are more pressing issues - this network configuration step just seemed a bit confusing at this point
<mdz> it is, in some corner cases
<mdz> but most users don't encounter the problems you've described
<thully> well, many people still have dial-up - and they would encounter this
<mdz> only if they also have ethernet and wireless interfaces that they aren't using
<thully> OK - well, maybe it isn't that common - still, many systems have built-in ethernet and/or wireless
<mdz> yes, my laptop does for example
<mdz> but I use them, and they can be configured automatically
<thully> OK - I've used these also, when I'm in range of wireless
<mdz> in fact I think we have the same laptop
<mdz> we just have different network environments
<thully> T42?
<mdz> yes
<thully> well, maybe different T42 - but same basic laptop
<thully> I'm going to close some bugs soon - there are some which are too trivial to consider at this point, and some others that have been made obsolete that I've reported (especially the ones involving warty's live cd)
<mdz> the new live CD should address many of the bugs in warty's live cd, yes
<thully> Also, I'll take a look at the timezone issues and the network config process - I don't think I can do anything about the network config because I don't know a whole lot about programming at this point (that will change soon, though)
<thully> One more thing I noticed on the Hoary live CD - root has a password set, and it is "ubuntu" - is this intentional?
<lamont> moo
<thully_> hi - just have an erratic net connection right now
<daniels> thom: next time you upload php4, want to get rid of debian/php4-imap?
<thully_> I'm going in a minute to try this install CD out, but first, what is the status of sound servers in Hoary - will it be polypaudio, or esd?  Also, will this be configured to relinquish /dev/dsp after a few seconds, as it was configured in Warty?
<mdz> daniels: one of the GL screensavers is causing my laptop to hang
<thully> where do I get the HD firmware that may fix the problem?  is it from IBM or another source (I don't want to risk voiding the warranty)
<daniels> mdz: AWESOME
<mdz> daniels: cubenetic
<mdz> at least
<mdz> I just ran through them and that one hung it
<daniels> mdz: do you have option DynamicClocks?
<Nafallo> daniels: is it my fault or your fault that my laptop have a black screen with using fglrx amd64?
<mdz> dunno
<daniels> mdz: look at xorg.conf
<mdz> need to reboot
<daniels> Nafallo: ati's fault
<daniels> mdz: blegh
<mdz> damn, not even sysrq+b works
<daniels> nice!
<mdz> HCF
<Nafallo> daniels: ahh, so you got more reports of this then?
<daniels> that's impressive
<daniels> hcf?
<lamont> daniels: how likely are you to upload another xorg before I finish mirroring the last one?
<daniels> Nafallo: not really, but it's a driver bug ...
<mdz>   HCF /H-C-F/ n. Mnemonic for `Halt and Catch Fire', any of several
<mdz>      undocumented and semi-mythical machine instructions with destructive
<mdz>      side-effects, supposedly included for test purposes on several
<mdz>      well-known architectures going as far back as the IBM 360.
<daniels> lamont: not; i'm being gentle and waiting a day or two for the next upload
<daniels> mdz: heh
<lamont> daniels: a day or 2 is about when I'll finish mirroring...
<lamont> the mirror happens at ~3KBytes/sec
* lamont almost worked on a machine with an HCF instruction in microcode.. but they cancelled that project just before I hired in...
<daniels> lamont: 'yes'
<lamont> daniels: heh
* lamont doesn't mind the big packages, he just doesn't like it when they churn.
* lamont crosses digits hoping for DSL availability
<daniels> lamont: seeding the mirror on dsl still hurts
<daniels> lamont: i386+powerpc+source+all basically took me a fortnight
<lamont> daniels: yeah, but even 30KB is better than 3KB...
<lamont> for the large jobs, I go snarf it down in town at 1.5Mbit
<lamont> because 150-160KBytes/sec is much better than 3. :-)
<daniels> heh :)
<thully> Oh - I do all my downloading on a school connection - why download an ISO at 2.5 kbps when you can get it at 500kbps?
<lamont> if I can't get dsl, I may colo a box at my buddy's place, and keep the mirror fresh there, then go rsync it over 802.11 from his driveway to my laptop....
<lamont> thully: yeah - i need to go make some friends in CS at the local uni
<thully> It's reassuring to know that there is someone else without high-speed net on this planet
<lamont> thully: I live at the end of a 29km (18 mile) 802.11 link
<lamont> so it's actually reasonabl bandwidth, but it's metered...
<mdz> daniels: no DynamicClocks
<lamont> at 30kbits, I can suck on the pipe all month and my normal activity doesn't push me too close to quota limits
<mdz> daniels: you want copies of any logs or config files?
<lamont> thully: but it still sucks...
<thully> I didn't know you could do that far of a wi-fi link except proof-of-concept
<thully> I can download a whole ISO at school in the time it takes me to get half a kernel update deb on my modem
<lamont> thully: it's not cheap, it doesn't like weather, but it is w/in FCC limits
<lamont> interestingly, rain isn't so bad.  snow on the far end kills it.
<lamont> and $100 antennas become very familiar. :-)
<lamont> daniels: .au is 120V or 240?
<mdz> mjg59: heh, doing STR during a live CD session booted from a USB drive -> NOT happy
<mdz> the CD doesn't come back
<thully> is it really that much better than dial-up if you have to limit it to 30kbps?
<lamont> thully: for my normal activity (ssh, web  surfing, etc), I don't throttle it.
<lamont> the mirroring is throttled so that I can spread the cost of fetching things over enough time to not matter.
<thully> I just end up using wi-fi at various places a lot
<lamont> you see, any 5 minute period where the total usage is < 56kbps gets discarded from the bill... Anything over 56kbps counts towards quota
<lamont> yeah - I'm pretty well known at a couple coffee houses in town
<thully> that's why I hated it when I tried several linux distros and they didn't support my wi-fi - but Ubuntu works fine with it
<lamont> that's the goal: "it just works"
<lamont> mdz: is baz 1.1 going into the archive?
<lamont> s/the archive/hoary/
<thully> yes - but my suspend only works properly on hoary, not warty (I have to use suspend-to-disk since suspend-to-RAM is royally messed up on my T42 with its battery usage)
<thully> btw, mdz: you have a link for that HD firmware update that may fix the problem?
<mdz> thully: that's for DeskStar hard drives
<mdz> not the thinkpad ones, if that's what you're thinking of
<mdz> but here it is: http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-42215
<mdz> lamont: I expect we will be badgered into it, yes
<daniels> mdz: sure, but doubt uit will be much good
<daniels> lamont: 240
<thully> oh - I thought you were saying that was a fix for T42 suspend
<mdz> daniels: this didn't happen previously
<daniels> mdz: how recently did it start happening?
<lamont> mdz: he was of the opinion that it had been pre-approved in mataro...
<lamont> just oh by the way...
<mdz> daniels: first time I saw it was ~yesterday
<daniels> mdz: could you please roll back xlibmesa-gl and xlibmesa-dri to ubuntu10 and see if it's alright?
<mdz> daniels: hmm, I just tried reproducing under a normal boot, rather than live CD
<mdz> daniels: and the window freezes, I no longer get mouse events anywhere
<mdz> but the pointer is alive
<mdz> and my ssh session is alive
<mdz> nothing in dmesg
<thully> OK - leaving now, bye
<mdz> but the X server is definitely fucked
<daniels> mdz: wack
<daniels> mdz: if I can find out which one of xlibmea-gl or xlibmesa-dri broke it in ubuntu11, that would be awesome
<daniels> i suspect it was -dri
<mdz> daniels: where can I find an old version?
<mdz> looking in the morgue, but don't see it so far
<daniels> the morgue on rookery?
<daniels> hm
<mdz> ah, 2005-01-20
<mdz> hm, no, only amd64 there
<mdz> I need i386
<daniels> mdz: p.u.c/~daniels/xlibmesa-dri_6.8.1-1ubuntu10_i386.deb 
<daniels> (still uploading)
<mdz> I found it elsewhere
<daniels> cool
<mdz> whoa, it's huge
<daniels> yes
<daniels> xlibmesa-dri-dbg is bigger than xserver-xorg-dbg
<mdz> daniels: which one should I try first?
<daniels> -dri
<daniels> you don't need to restart your X server for this one
<mdz> well, I need to reboot the machine :-)
<daniels> heh :)
<daniels> you might want to do full power off
<daniels> i.e. power completely out for about 10sec
<daniels> since the graphics hardware might be quite badly wedged
<mdz> still fucked after downgrading xlibmesa-dri
<daniels> try -gl as well
<mdz> have to run immediately after
<daniels> k
<mdz> still broken after downgrading xlibmesa-gl
<mdz> have to run, mail me with other stuff to try
<daniels> k
<wasabi> tihs metacity "lets not pop on top of you" thing is a bit hard to get used to
<wasabi> i know it's cool... it's just disconcerting.
<wasabi> Man. xcompmgr is so nice.
* wasabi giggle like a school girl.
<chrisa> I've never seen anyone mutter 'xcompmgr' and 'nice' in the same sentence
<chrisa> Usually the adjective is 'broken', 'laggy' or 'slow'
<wasabi> oh it's not slow for me.
<wasabi> nvidia. it's only slightly broken (panel is below everything)
<wasabi> and it hasn't crashed in the 15 minutes I've been running it!
<fabbione> morning
<crimsun> moin :)
<fabbione> mdz: ping
<fabbione> hey doko
<aj> mdz around?
<daniels> aj: he's out
<fabbione> aj: i think he falled asleep not too long ago
<Nafallo> ao! thoggen has still a long way to go ;-).
<Nafallo> 1,7 frames/sec ;-)
<Nafallo> Could I package stuff not in sid for hoary universe and get them pulled in? :-)
<toresbe> I got my discs!! ^_^
<toresbe> I thought one got a cool little display box if you ordered more than 10?
<fabbione> openoffice.org-bin_1.1.3-2.3ubuntu7_sparc.deb
<fabbione> uhuh
<doko> fabbione: morning!
<fabbione> i wonder if the ftpd timeout on jackass has been fixed...
<Nafallo> I really do love rosetta :-)
* Nafallo just translated two more packages
<mdz> fabbione: pong
<mdz> aj: back
<fabbione> mdz: hey.. did you ask elmo to sync alsa 1.0.8-1 from sid? should we so it manually?
<fabbione> (#1293)
<mdz> I did, and he did it already
<aj> mdz: filed a wishlist bug on apt #291338
<mdz> alsa-driver |    1.0.8-1 | http://archive.ubuntu.com hoary/main Sources
<fabbione> ok.. can i close the bug?
<mdz> you merged the kernel patch already?
<fabbione> mdz: yes.. since 2.6.10-9
<fabbione> it's in the bug comments :)
<mdz> fabbione: then yes, it can be closed
* fabbione does
<mdz> jdub: is polypaudio going to happen for hoary, or no?
<jdub> mdz: yes, it should
<Nafallo> *hmpf* I need theora-mmx, but it won't compile cleanly on amd64 :-(.
<d3vic3> doko, ping 
<Nafallo> WTF! snow again.
<jdub> can you find out from proc if the kernel is tainted?
<mdz> doesn't lsmod tell you?
* mdz doesn't have a tainted kernel handy
<ajmitch> no, it doesn't appear to
<crimsun> cat /proc/sys/kernel/tainted
<ajmitch> ah, good
<fabbione> thanks :-)
<crimsun> np
<pitti> Morning folks!
<crimsun> moin pitti
<ajmitch> hey pitti 
<pitti> elmo: Morning! Ready for the big flood?
<fabbione> elmo: sparc.u.c doesn't get any update....
<fabbione> is the crontab for the sync running?
* ajmitch tries building an ssp-patched gcc again
<pitti> elmo: please sync mysql-dfsg and mysql-dfsg-4.1
<Hwolf> Hey. Has OOo2 hit the repro's yet? 
<siimo> hi.. is there a bug in the new nautilus 2.9.x ? 
<robsta> hi
<siimo> the icon labels zoom out smaller than the gnome font size specified
<Hwolf> siimo, It'd highly suprize everyone if it was bugfree. :-)
<siimo> no i am wondering if this is a bug or feature
<Hwolf> That's a different question. :-)
<robsta> i'm wondering where Xauth.h could be in hoary
<robsta> dpkg -S doesn't tell me
<fabbione> guys these are #ubuntu topics
<robsta> neither does it seem to be in xorg-6.8.1 src deb
<martink> robsta, dpkg -S doesn't work if you don't have the relevant package. It's in libxau-dev
<fabbione> robsta: it is in libxauth-dev
<fabbione> yeah xau-dev :-)
<siimo> its very annoying
<Hwolf> Hm. Is OOo2 supposed to be in the repros now? I can see one package, but not the entire load.
<siimo> i like the icons 75% zoom 
<fabbione> Hwolf: -> #ubuntu
<siimo> but icon text zooms out as weel and becomes unreadable
<fabbione> siimo: -> #ubuntu
<fabbione> these are not topics for this chan please
<Hwolf> fabbione. If I open bugbuddy, I should see a list of all programs, right, and another tab with all packages?
<fabbione> Hwolf: this is still #ubuntu related topic
<fabbione> here we discuss only the development for ubuntu
<fabbione> if you need general help please use #ubuntu
<Hwolf> Listen me out will you?
<robsta> fabbione: thx
<fabbione> robsta: np
<Hwolf> I just reported a bug, and I just noted the only program that is listed as such in bugbuddy is the cpu-feq-applet. Now I'm not sure if that's a bug, or a borked system.
<fabbione> Hwolf: there are people working on OOO2. when it will be in the archive is striclty related to when the packages will be ready
<Hwolf> fabbione, what about bugbuddy? 
<fabbione> Hwolf: bug number?
<Hwolf> I just updated my bug 5641 using bugbuddy for the debug output. But I just noticed that if I try to open the program from the menu it does nothing but piont my browser to buzilla.ubuntu.com, when I had it open the only program listed was the cpu-freq-applet
<fabbione> Hwolf: it could be a bugbuddy bug..
<seb128> NO :p
<fabbione> GTK bug?
<seb128> enough GNOME bug, stop here NOW :p
<Nafallo> lol
<seb128> no, kernel bug
<fabbione> seb128: hmm ok
<seb128> :)
<jdub> that's actually not a bug ;)
<seb128> hey jdub 
<fabbione> reassign it to me :P
<jdub> morning seb128 
<fabbione> it's not like 40 or 41 will make any difference
<Hwolf> The launcher for the bug-report-tool lists 'gnome-open https://bugzilla.ubuntu.com/'
<jdub> Hwolf: yes
<jdub> Hwolf: that's intended
<seb128> jdub: what happened to this tab with the main menu for gnome-panel ? UI freeze is monday and Vincent would really appreciate your advice :p
<jdub> seb128: there's acomment on the bug
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=163501
<seb128> no comment from here 
<jdub> erm
* seb128 slaps jdub, stop lying  :p
<Hwolf> Seb128, I've updated my weather-applet and notification-applet bugs.
<seb128> Hwolf: ok, thanks
<jdub> argh
* jdub slaps bugzilla
<seb128> ah ah
<Hwolf> fabbione, is bugbuddy only showing one progam something I should file a bug about, or do I need to let it rest?
<seb128> let it
<Hwolf> ok
<Hwolf> Will at some piont in the future Python 2.3 be uninstalled by an upgrade? 
<seb128> jdub: have you tried gnome-launch-box ?
<ajmitch> Hwolf: going by how debian does it, no, I doubt it will
<ajmitch> unless something were to conflict with & replace python2.3
<Hwolf> ajmitch, would you say it is safe to do so? 
<jdub> seb128: not yet
<jdub> seb128: interested to though :)
<seb128> jdub: worth packaging it ? I'm pondering doing it now :p
<ajmitch> Hwolf: no, I wouldn't do it :)
<jdub> seb128: yeah, might be a cool hoary bling feature ;)
<seb128> ok, let's go for it
<ajmitch> I've still got python 2.1 through to 2.4 on my sid box
<Kamion> Hwolf: these days, I think it's reasonably safe to assume that anything that wants python2.3 will depend on it
<Kamion> so if you can remove it without removing a bunch of other stuff, it's safe
<Hwolf> kamion, is there any chance of kernel-panicky-like errors wrecking the system if I try?
<ajmitch> it should be safe & clean
<Astharot> good morning
<Kamion> Hwolf: kernel panic? hell no
<Kamion> Hwolf: 'apt-get remove python2.3' and look carefully at what it wants to remove
<Hwolf> kamion, I'd not expect a kernel panic, but I'd be pretty pissed off if due to some missing dependency it wrecked dpkg for instance. :-)
<Hwolf> Kamion, did that, nothing not labled python2.3-*
<Kamion> Hwolf: dpkg doesn't have any pythonish stuff in it (yet, anyway)
<Hwolf> Kamion, I'll try it then.
<seb128> jamesh: around ?
<jamesh> seb128: yeah.
<seb128> jamesh: you know how the weather applet works ?
<jamesh> seb128: parts of it.  Why?
<seb128> jamesh: just wondering where it takes the sunrise/sunset times
<jamesh> seb128: it stores the geographic location of weather stations in the Locations.xml file
<jamesh> seb128: when you select your location, it copies those coordinates to a gconf key
<seb128> jamesh: the issue is: https://bugzilla.ubuntu.com/attachment.cgi?id=1081
<jamesh> and then works out the times from that.
<seb128> jamesh: look on the sunrise/suntime
<seb128> jamesh: http://weather.noaa.gov/weather/current/EHRD.html is the METAR page for this
<seb128> ok
<seb128> was wondering if that's a server or applet's bug
<seb128> probably a gweather one so ?
<Hwolf> seb128, how can I check my location?
<jamesh> seb128: the sunrise/sunset calculations are entirely local.
<seb128> jamesh: ok, so an applet bug, thanks
<seb128> Hwolf: I don't understand the question ? You what to know where you live ? :p
<Treenaks> seb128: I have a small GPS-detecting python script for HAL....
<Hwolf> seb128, I want to check if I've set my location correctly during install
<seb128> Hwolf: cat /etc/timezone
<jamesh> seb128: it would either be a bug in the Locations.xml file, or a bug in the calculations.
<seb128> jamesh: but the location has only the coordinate and the METAR code, what could be broken in that ?
<seb128> jamesh: I mean whatever is the location, 19min between sunset and sunrise ...
<jamesh> seb128: in theory, places close to the arctic circle could have very short days
<jamesh> seb128: I don
<jamesh> 't know whether the calculations take into account twilight.
<jamesh> of course, it could just be a bug ...
<seb128> jamesh: I'll have a look on the code, I just wanted to know if the informations come from some net place or are calculated, thanks for the comments :)
<thom> morning
<pitti> Hi thom!
<seb128> hey thom & pitti
<thom> mozilla-firefox-gnome-support: Depends: mozilla-firefox (=
<thom> 1.0+dfsg.1-2ubuntu1) but 1.0-2ubuntu4-warty99 is to be installed
<thom> i assume that's ubuntu-backports madness
<thom> from #5612
<amu> Kamion: what are the differences between 20050120 and .1 ? 
<carlos> pitti: do you have around any example *_translations.tar.gz ?
<Hwolf> Hm. Why doesn't ubuntu recompile the official iso's of warty to incorporate the updates? It's causing a lot of server load to have every new user grab 100+mb of updates?
* thom gets to say "ez gtk bug" in a real bug report
<fabbione> mjg59, daniels: updating the drm stuff now.. but that will mostlikely require another kernel ABI change
<seb128> thom: I hate you :p
<thom> hey now, i'm fixing epiphany for you and you say you hate me? that's not very nice :P
<seb128> bah, ok, if you fix epiphany I'll forgive you for the gtk bug :p
<Kamion> amu: mdz built the first one manually, the second was the automatic daily build: in other words I have absolutely no idea
<d3vic3> I need help uploading to universe 
<d3vic3> how do I upload to universe ? 
<amu> Kamion: ok, thx
<Kamion> same way as you upload to Ubuntu in general. :)
<d3vic3> I have never uploaded to ubuntu 
<Mithrandir> d3vic3: it's on the wiki
<d3vic3> which page ?
<Kamion> Uploads
* Kamion unfucks base-config
<Mithrandir> d3vic3: "search" is a nice thingy. :P  (But Kamion's right as well)
<Kamion> now it might actually be able to run the 'finish' menu entry
<d3vic3> ok found it 
<amu> Kamion: any idea why i can't run su - or sudo, with a "root-terminal" from the menu it's possible to get root
<Kamion> I don't know, sorry
<Kamion> root terminal just uses gksudo I thought
<amu> strange, it works just 1 time, not possible to run 2 root-terminals 
<Mithrandir> amu: strace the panel from the root terminal?
<pitti> carlos: I can generate one
<carlos> pitti: could you send me it, please?
<carlos> pitti: if it's easy for you to create it, if it's not I can do it
<pitti> carlos: is a small one okay? Or do you need one with several files?
<pitti> carlos: pmount only has one pot and one po
<carlos> pitti: that's ok
<carlos> pitti: btw, did you saw last change we did for the tar.gz tree?
<pitti> carlos: with the packages files?
<pitti> carlos: instead of the hierarchy?
<carlos> pitti: the _translations.tar.gz
<carlos> pitti: the mail I sent yesterday
<pitti> carlos: the flat hierarchy with the text file that contains all package info?
<carlos> pitti: yes
<carlos> that on
<carlos> that one
<carlos> pitti: not sure if it affects you or not
<pitti> carlos: http://people.ubuntu.com/~pitti/pmount_0.5.1-1_translations.tar.gz
<carlos> pitti: thanks
<pitti> carlos: yes, I saw it. I liked the idea
<pitti> carlos: however, that does not really affect my part
<carlos> pitti: ok, that's what I want to know
<matt3o> Hi all...
<carlos> don't want to change you the way you are doing your work without talking with you
<matt3o> I have a strange problem with network-admin.... maybe it can interest to you all...
<pitti> carlos: lamont really did a great job. He reduced my part of the work to putting the tarball into <source build dir>/..
<carlos> :-)
<pitti> carlos: so essentially you can change the publishing structure without touching pkgstriptranslations
<no0tic> hi
<ajmitch> morning jeff :)
<jbailey> g'd evening Andrew!
<ajmitch> about 1am here
<ajmitch> debs are working ok, I think I might sleep :)
<ajmitch> although I do have to get manpages for some..
<fabbione> let see if i can kill my box :-)
<trukulo> fabbione: use a shotgun
<no0tic> /etc/init.d/networking start fails, where can I find logs?
<fabbione> UHA UHA IT IS BINARY COMPATIBLE!
<fabbione> YES YES YES !
* ajmitch wanders off to sleep, night all
<fabbione> ajmitch: btw.. what is the bug number?
<fabbione> i didn't get any assigned
<ajmitch> 5659
<fabbione> hmm why isn't assigned to me?
<fabbione> and linux ?
<ajmitch> don't know, it got assigned to debzilla@
<fabbione> ok brb...
<fabbione> i will check it in a few secs...
<ajmitch> ok
* ajmitch might have to update the bug with another option that _could_ be required
<ajmitch> since there was discussion in #selinux that capabilities may need to be built in, rather than as a module
<ajmitch> this hasn't been checked out yet
<ajmitch> anyway, time for bed
<fabbione> ajmitch_ i had that discussion with Manoj this morning
<Keybuk> Bug report submitted to: "Ubuntu Bug Tracking System" <ubuntu-users@lists.ubuntu.com>
<fabbione> it's something selinux people have to address upstream
<Keybuk> meh ... I expected that to go to the Debian maintainer
<ajmitch> alright
<fabbione> trulux: ping
<trukulo> hi ogra
<ogra> hi :)
<ogra> i just tested tonights livecd
<ogra> the first one that gave me X (even if its only 640x480) on my amd64 laptop :-D
<ogra> trukulo: are your graveman packages ready ?
<trukulo> ogra: yup
<trukulo> at least, 0.3.0-1
<trukulo> because there's a new package (that man never rest)
<ogra> trukulo: great, then i'll upload the today after work :)
<trukulo> superb
<ogra> them even
<trukulo> there's a 0.3.1
<trukulo> but i'll wait at least until 0.3.2 for new package (perhaps tomorrow P )
<ogra> yeah, we cant cope with the speed of this guy anyway
<trukulo> it's impossible
<ogra> looking at the diff.....
<ogra> woot !
<trukulo> what?
<ogra> he uses dev=/dev/hdX now......
<trukulo> what?
<trukulo> i have to see this
<trukulo> Added Polish translation, thanks Marcin Undak <masamune _at_ op.pl>
<trukulo> Updated Brazilian Portuguese translation, thanks Andre Luis Lopes <andrelop _at_ debian.org>
<trukulo> Fixed mp3 header decoding by using libmad, now required libmad !!
<trukulo> where did you see that?
<trukulo> Updated files, graveman is now hosted by savannah !
<trukulo> in 0.3.0 ?
<ogra> trukulo: i'm reading the graveman_0.3.0-1.diff.gz
<trukulo> * Fixed ATA and ATAPI devices detection, 2 !
<ogra> yup, thats what i mean
<trukulo> umm, could be, i didn't try autodetection in ubuntu with 0.3.0
<trukulo> can you try it?
<ogra> lol: # Attempt to guess a canonical system name.
<trukulo> i can't here
<ogra> i will....i will just have to compile them for amd64
<trukulo> ok, tell me if yo do
<thom> fabbione: if you're set up to do it, a merge of linux--dilinger--0--patch-43 would be great (brings in Dothan support for cpufreq)
<thom> fabbione: http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/043-dothan_p4_get_frequency.patch
<fabbione> thom: i got it already and no i cannot use arch for the kernel
<fabbione> thom: because it's in debian as well and i sync with them :-)
<fabbione> or better.. i synced this morning
<thom> ah, cool
<fabbione> do you think i am a sloppy kernel maintainer? :P
<robtaylor> fabbione: hey. i was looking at jackd stuff last night. apparently the realtime-lsm module needs secuity to be built as a module in the kernel
<robtaylor> any chance of this happening at all, or is that a no-go?
<fabbione> robtaylor: dude.. you are talking to me like if i can remember everything...
<fabbione> yes i do remember..
<robtaylor> fabbione: heh ;)
<ogra> does anybody know if we plan to have the new ndiswrapper for amd64 in hoary ?
<fabbione> but do we need patches?
<robtaylor> fabbione: nope, just ap amtter fo setting CONFIG_SECURITY=m
<robtaylor> s/ap amtter fo/a matter of/
<robtaylor> (!)
<fabbione> robtaylor: and did you check if it is already there?
<fabbione> because if it is i am going to cross burn you :-
<robtaylor> fabbione: in hoary its set as compiled in
<thom> fabbione: do you want me to answer that question? :P
<fabbione> config SECURITY
<fabbione>         bool "Enable different security models"
<fabbione>         help
* fabbione crossburns robtaylor
<thom> Mithrandir: thanks for the CC
<fabbione> robtaylor: you cannot select SECURITY as module
<fabbione> that makes it kinda difficult for me to compile it as such
<Mithrandir> thom: np.  I suggest we go with whatever Debian does.. it's the least amount of work.
<robtaylor> fabbione: hmmmmm
<thom> definitely
<robtaylor> i wonder what realtime-lsm meant then =)
<Mithrandir> thom: I hope they'll just agree that we can have transitional packages and it'll all work out nicely.
<thom> it'd be pretty frickin' anal of them not to
<mjg59> This is the Mozilla thing?
<Mithrandir> yup
<Mithrandir> mjg59: what conclusion did the thread on -legal end up with? 
<mjg59> Mithrandir: Oh, christ knows
<Mithrandir> I skimmed the mail archives but couldn't find any "We'll do $foo, $bar, $baz" and a reply from somebody saying "yes, good."
<Mithrandir> but then, I guess that's not how -legal works. :P
<mjg59> People keep bikeshedding madly
<Kamion> 2005-01-20 12:39:43 GMT Colin Watson <colin.watson@canonical.com>       patch-108
<Kamion>     Summary:
<Kamion>       Enable ia64 live CDs.
<mjg59> Kamion: Rock
<ogra> woot
<mjg59> For the, uh, 3 people who'll want them? :)
<Kamion> might actually work with any luck
<Kamion> mjg59: lamont, lamont, and, uh ...
<thom> me
<Kamion> ... lamont!
<mjg59> Wow! 4!
<Kamion> lamont said he'll be pimping them to HP people
<mjg59> Mithrandir: I think the Mozilla people are fundamentally acting in good faith, but are possibly starting from the wrong place
<Mithrandir> mjg59: yeah, sure.  I'm not too worried, but we just want to get it straightened out.
* Mithrandir wonders where libapt-pkg-libc6.3-5-3.7 is hiding.
<Kamion> Mithrandir: Provides from apt
<Mithrandir> ok, so python-apt is out of date
<Mithrandir> which leaves ubuntu-desktop uninstallable
<Kamion> oh you're kidding
<mvo_> Mithrandir: it should be updated already
<Kamion>    Binaries from python-apt 0.5.32ubuntu4 cannot be installed:
<Kamion>        python-apt(i386)
<Kamion>    Binaries from ubuntu-meta 0.20 cannot be installed:
<Kamion>        ubuntu-desktop(i386)
<mvo_> Kamion: I uploaded a new apt this morning
<Kamion> maybe it hasn't built
<Mithrandir> mvo_: it == python-apt, I guess?
<Kamion> if this kills my CD build I'm going to hurt people :P
<thom> aaaaargh, why don't the firefox maintainers use dpatch
* thom cries
<mvo_> Mithrandir: yes :)
<thom> s/dpatch/${PATCHSYSTEM}/
<mvo_> Kamion: not this time I hope ...
<Kamion> python-apt | 0.5.32ubuntu4 |         hoary | i386
<Kamion> python-apt | 0.5.32ubuntu5 |         hoary | amd64, ia64, powerpc, source
<Kamion> ARGH
<Mithrandir> Kamion: it's successful on i386 as well
<Kamion> it's not in the archive yet though
<Mithrandir> I wonder where it went, then
<Mithrandir> was finished building two minutes ahead of ppc.
<pitti> elmo: ping
<Mithrandir> what's the timezone on p.u.c?
<Kamion> should be UTC
<thom> pitti: elmo's net.dead, mostly
<pitti> ugh
<Kamion> thom: can you have a look at whether python-apt's in accepted?
<Kamion> 0.5.32ubuntu5
<thom> sure
<thom> no, not yet
<Kamion> any clue where it's gone? the build was on terranova
<Mithrandir> fun, nautilus eats about 500kbit/sec by just having an ssh window open to somewhere.
<thom> Kamion: rejected
<thom> Kamion: md5sum mismatches
<thom> guess the upload went wrong. hrm, wonder if i can retry it from terranova
<Kamion> arr
<Kamion> it'd be really good if you could
<thom> right, they're back in queue/unchecked
<thom> lets see how that goes
<thom> Kamion: and into accepted
<Mithrandir> yay
<thom> python-apt | 0.5.32ubuntu5 |         hoary | source, amd64, i386, ia64, powerpc
* Mithrandir smiles
<thom> just sparc slacking ;p
<Mithrandir> huh, I managed to get this:
<Mithrandir> W: GPG error: http://ftp.ubuntu.com hoary Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<fabbione> thom: i don't think elmo added there...
<fabbione> thom: plus sparc.u.c is not updated
<Kamion> thom: hooray, thanks
* Kamion restarts cron.daily
<fabbione> thom: can i push concordia a bit over load 300 ??
<thom> i'm sure you can try
<fabbione> ok
<fabbione> than i will raise the CONCURRENCY_LEVEL to 400
<fabbione> and see what happens
<fabbione> FLY CONCORDIA
<fabbione> this machine is NO fun
<Treenaks> it just keeps going and going?
<fabbione> Treenaks: yes
<fabbione> it doesn't feel it at all
<Treenaks> nice
<fabbione> and it was up to 326 or something
<thom> fabbione: 103 currently
<fabbione> thom: i know.. it's going down because each process is waiting for the other to finish and link
<thom> opteron > *
<fabbione> that can't be parallelized as much as compiling
<thom> yeah
<fabbione> thom: +1
<Treenaks> fabbione: now try massively parallel email delivery
<fabbione> it's doing all I/O now
<fabbione> Treenaks: something like: cd /usr/src/linux-source && for i in $(find . -type f); do mail -s $i treenack@treenack.com < $i &; done ??
<fabbione> FLY AGAIN CONCORDIA!
<fabbione> YEAHHHH
<fabbione> ride the top!
<Treenaks> fabbione: 8)
<Treenaks> treenack@treenack.com.. I wonder who that is ;)
<fabbione> top - 13:49:11 up 6 days, 23:37,  3 users,  load average: 357.26, 186.30, 92.96
<fabbione> top - 13:49:36 up 6 days, 23:37,  3 users,  load average: 370.75, 203.17, 101.0
<fabbione> going higher :-)
<thom> it's a little unresponsive now, but not much
<fabbione> 378 :-)
<fabbione> can we do better?
<fabbione> no..
<fabbione> it's already up to 400
<fabbione> otherwise it should have gone up to 410 or so
<fabbione> thom: please ship me concordia :-)
<fabbione> 394!
<fabbione> 400!!!1
* fabbione ponders to push the red button
<fabbione> 419.something
<thom> fabbione: you're being silly now :-)
<fabbione> i know sorry
<fabbione> thom: never the less... you are there with top too :)
<thom> i think you may have broken something, too :P
<fabbione> thom: uh?
<fabbione> people's nerves?
<fabbione> ;)
<thom> jeesh, interactivity is fucked now :-)
<fabbione> 425 :-)
<fabbione> i tend to believe that
<fabbione> it should be dropping now
<fabbione> i have 2 kernels left.. and i am done
<fabbione> but at these speed...
<jdub> fabbione: is there some way to disable rw ntfs mounts entirely?
<fabbione> thom: why did you turn off swap?
<jdub> fabbione: preferably in the kernel code :)
<fabbione> jdub: yes. it's a kernel option
<fabbione> 686:# CONFIG_NTFS_RW is not set
<fabbione> jdub: it's not enable in our kernels
<fabbione> ah no
<fabbione> thom: nevermind.. space in swap is finished
<thom> fabbione: turn off swap?
<thom> ah
* fabbione hits the red emergency button
<fabbione> ok now it's back to normal
<jdub> fabbione: hmm
<fabbione> jdub: what arch?
<jdub> i386
<fabbione> it's unset
<jdub> it *said* rw, but i choose not to believe it actually is rw until i've double-checked
<fabbione> jdub: the writing code is disabled
<fabbione> if you try to write it will fail
<fabbione> jusst do a touch foo
<fabbione> + mount shows ro only when you mount as such
<fabbione> check the cdrom's message : warning mounting ro bla bla
<jdub> mount said rw
<jdub> but i choose not to believe it until i've double checked
<fabbione> yeah i get that...
<fabbione> try with touch foo
<Keybuk> Mithrandir: that dpkg bug you just replied to, read the report carefully, look at the code, then look at what he did
<Keybuk> it's actually quite funny
<Keybuk> the report was, basically, "u-a doesn't bitch if the alternative doesn't exist"
<Mithrandir> Keybuk: I had to restrain myself to not be actively rude to him.
<Mithrandir> heh, ok
<Keybuk> the code he changed was "if ($! != &ENOENT)"
<Keybuk> ie. "only report if the error message is /anything but/ ENOENT"
<Keybuk> all he did by changing $! to $| is break the test
<Keybuk> deleting the test entirely would have had the same result
<Keybuk> Kamion: did you know groff renders $| as $| ?
<Kamion> that seems, er, correct?
<Mithrandir> isn't the question whether it renders $! as $|?
<Kamion> perlvar(1) looks fine here
<Mithrandir> try with g-t?
<Keybuk> gah, sorry, I changed my compose map
<Kamion> still looks ok, although sid rather than hoary
<Kamion> and UTF-8
<Kamion> compose map?
<Keybuk> maybe I'm being odd
<Keybuk> but if I search perlvar for \$\| it doesn't find it
<Keybuk> $ is what I get in the output text, not $|
<Keybuk> (ie. U+2502 BOX DRAWINGS LIGHT VERTICAL, not U+007C VERTICAL LINE = VERTICAL BAR)
<smurfix> ouch
<Kamion> yeah, same here
<Keybuk> I guess this is another - vs \- thing?
<Kamion> hm, seems more like rendering of '
<Kamion> seems odd, I'd be inclined to disable that "feature"
<Kamion> it might be for table drawing, I don't know exactly how tbl works
<trulux> pitti: ping
<Keybuk> could be
<pitti> trulux: pong
<Kamion> hm, this is odd
<Kamion> ba      24      0       0x007C
<Kamion> or      "
<Kamion> |       "
<Kamion> so it should work
<Keybuk> .tr \(*W-|\(bv\*(Tr
<Kamion> | must get remapped internally or something, might be a bug
<Keybuk> what's that do?
<fabbione> daniels, mjg59: ping
<Kamion> gar
* Keybuk suspects perldoc is mapping it
<Kamion> Keybuk: that remaps | to vertical bar, deliberately :P
<Kamion> yes, pod2man is being silly
<Keybuk> pod2man sucks, Film at 11.
<Kamion> IZ POD2MAN BUG
<Kamion> pod2man's actually not too bad nowadays; it used to suck much more
<Treenaks> isn't it doing Evil & Wrong things with "-" vs "" as well?
<trulux> pitti: your email is martin.pitt@canonical.com right?
<pitti> trulux: yes
<trulux> ajmitch: what's your email?
<trulux> pitti: ok thanks
<Kamion> Treenaks: yeah, but in pod2man terms that's a relatively recent issue, and tricky to solve correctly
<Kamion> actually it seems to get it right in most cases, there are just a few mistakes
<Treenaks> like the CGI manpage... -charset stuff
<Kamion> pod2man(1) itself seems to be OK though
<pitti> Hi lamont!
<daniels> fabbione: sup
<daniels> fabbione: just about to go to bed
<fabbione>   * Backport drm from 2.6.11rc1:
<fabbione>     - Add patch stolen-from-head_drm.dpatch.
<fabbione>     - Enable matrox drm on x86_64:
<fabbione>       . DRM_MGA=m
<fabbione> good night :-)
<daniels> cool :)
<daniels> night dude, thanks a lot
<trulux> fabbione: hey
<daniels> are we copping an abi bump?
<fabbione> and no ABI breakout...
<fabbione> trulux: hi
<fabbione> daniels: i am not 200% sure for drm modules.. all the others work ok
<ogra> fabbione: thanks :) ....  load average: 0.13, 0.15, 0.10
<fabbione> daniels: meaning that probably people will have to do a modprobe -r i915 instead of rmmod i915
<fabbione> ogra: no problem dude
<fabbione> daniels: i am pretty sure that the drm module needs to be reloaded as well but that's kinda new
<fabbione> so i don't think we will hit the problem at all
<ogra> fabbione: now please ndiswrapper for amd64 ;) ... so i can use my linksys wlan card ....
<fabbione> ogra: that is not really trivial...
<trulux> fabbione: replied to the bug report about kernel auditing
<ogra> fabbione: i just compiled rc3 here .... but there are no 64bit win drivers :-P
<fabbione> trulux: yes i saw that...
<fabbione> trulux: i need to give it a spin
<trulux> fabbione: ok
<trulux> NP
<fabbione> ogra: and it also involves new userlands
<daniels> fabbione: ok, cool
<daniels> fabbione: that's fine, thanks
<trulux> pitti: who is the man maintaining pam related packages?
<pitti> trulux: we don't have particular maintainers in Ubuntu
<fabbione> ogra: you need to ask mdz if we can get a new upstream version basically...
<fabbione> ogra: since we are in UVF
<pitti> trulux: if there is a problem/question, it is usually best to write to ubuntu-devel
<fabbione> ogra: i don't have big problems to do it kernel side
<ogra> fabbione: ndiswrapper 1.0rc3 has amd64 support built in (including the utils) but its quie useless if you only can load 64bit drivers that dont exist
<fabbione> ogra: ok. let's deffer that for a few weeks
<fabbione> ogra: perhaps drivers will show up one close to the other
<fabbione> at the end we still release every 6 months :-)
<ogra> fabbione: or drop it...(i can live with my old orinoco....)
<fabbione> ogra: start asking mdz..
<fabbione> and i am off for today
<ogra> fabbione: relax ;)
<fabbione> i need to put fiber glass on the living room's walls
<fabbione> relax?
<fabbione> are you on somekind of crack?
<fabbione> ;)
* fabbione &
<ogra> fabbione: _you_ chose fiber .... other ppl take wallpaper....
<fabbione> you still need to put it up
<fabbione> and after i have spent 4 days taking away the last 35 years of danish fashion wall paper, i choose fiber
<ogra> fabbione: but it differs a lot   whichmaterial you take (i already did fiber walls)
<fabbione> ogra: clearly.. but i don't like wallpaper anyway
<ogra> fabbione: and decided to prfer paper in the future ;)
<fabbione> eheh
<fabbione> ok i really need to get started
<ogra> fabbione: go....have fun at least :)
<fabbione> it's a 50sqm room and i plan to go to sleep this night :)
<fabbione> with lots of nice corners and edges
* fabbione sighs
<ogra> heh
<fabbione> cya
<ogra> ciao
<mxpxpod> has anyone here tried gnome-launchbox?
<tseng> mxpxpod: id imagine so, seb just added the patch for it to gnome-menus
<mxpxpod> tseng: I was trying to figure out what -dev packaged I needed because it said it couldn't find libdb.a
<mxpxpod> I needed libdb4.1-dev
<sivang> mxpxpod: you
<sivang> mxpxpod: you're compilin gfrom jhbuild?
<mxpxpod> sivang: no, from source
<mxpxpod> and it keeps segfaulting when I type h in it
<thom> seb128: i've applied all the patches from live.g.o 
<seb128> thom: you rock
<sivang> pitti: ping
<sivang> pitti: just talked with g-s-t upstrea, he says that he heared about the tendency to move non system-exclusive things out from /etc to other places, what do you think?
* decko vai testar novo kernel
<pitti> sivang: what do you mean in particular?
<sivang> pitti: garnacho says that the reason for not putting the profile stuff under /etc/g-s-t is per an intention to not put no system specific (i.e. distro nutral related programs files) in /etc/
<sivang> pitti: g-s-t is multi platform tool, thus it's conffiles are put elsewhere.
<Kamion> that's ... odd
<sivang> pitti: (according to upstream maintainer)
<Kamion>  /etc is everyone's configuration space, not just the distribution's
<Kamion> well
<T-Bone> Kamion: did you get my last 'report' on ia64?
<Kamion> g-s-t might want to default to /usr/local/etc
<Kamion> our g-s-t package should still put its configuration in /etc
<pitti> sivang: right, that's why I suggested to put it into /usr/share/gst/profiles or so
<robertj> yeah, /usr/local is _my_ area
<Kamion> T-Bone: yes, haven't really processed it yet
<pitti> sivang: the initial default profile should not be something configurable
<Kamion> T-Bone: 20041227ubuntu6 is a version number more than a date, hence why it looks odd - that *is* current
<T-Bone> Kamion: k, then i'll wait before doign further testing ;)
<robertj> if I want to store vital system state information by encoding it into the mtime of /usr/local, that's my perogative and nobody better mess with it ;)
<pitti> sivang: the _added_ and edited profiles should be somewhere in /etc/
<sivang> pitti: yes, I was talking about a proper localtion for this, however I think we already agreed on "why should any profile be hardcoded in it?" ? :)
<sivang> pitti: doing it that way, it would allow other distros to put in a profile to their likings, without bothering upstream for it.
<sivang> robertj: :)
<pitti> sivang: "hardcoded" in the sense of writing it directly into the perl backend
<sivang> pitti: yes
<pitti> sivang: putting the default profile into a separate file is good, then it can be changed separately from the perl code
<sivang> pitti: exactly
<sivang> pitti: I am trying to talk him into doing this, althogu he seems to favor to relieve distro maintainers from configging it
<pitti> sivang: is it very hard just to change the hardcoded default in the meantime? It would be nice to have a working package soon to play around with
<sivang> pitti: not at all, I already agreed to this :) Just tried to interest him in it, regardless I am working on patching out version :)
* thom wallops pitti
<sladen> ARGH ARGH ARRRGH, new gnome open/save dialogue.  ARRGH
<robtaylor> sladen: that bad?!
<pitti> Aua, aua
<sladen> who can I bribe to back with crack out again
<pitti> thom: what's up?
<robertj> sladen: why do you hate it so?
<thom> pitti: looks like you dropped a patch from cupsys :P
<sladen> robertj: "what would you like to open this pdf with"   [x]  [enter]   ...file opens with PDF
<pitti> thom: ? I used merge-o-matic...
<pitti> thom: or was that YOU who added this silly "don't modify maint scripts' option to dh_installinit?
<robertj> sladen: does it ask you with only one choice?
<pitti> thom: ^ do you mean this patch?
<thom> pitti: no
<thom> pitti: no, there's a patch missing from the init script that scott uploaded in december
<sladen> robertj: "what would you like me to do with this"?  window opens with no focus.  Click focus.  tab once, tab again, press space, tab again press space for 'advanced' options, click drop down, select 'other', type 'xpdf', find it wants the full pathname, type '/usr/bin/xpdf', click [OK] , return to original dialogue box, click to focus, press [OK] 
<pitti> thom: I only removed the "dh_installinit -n" patch, because it broke everything
<robertj> ahh
<pitti> thom: what's missing?
<thom> pitti: in cupsys.init.d; the s-s-d invocation in start
<sladen> robtaylor: worse.
<robertj> sladen: my current gnome pet peeve is that you can't drag from/to the history
<thom> we used to have --background and -F as the options to cupsd
<thom> anyway, fixed now
<pitti> thom: I have "start-stop-daemon --start --quiet --exec $DAEMON"
<thom> yes, which is wrong
<pitti> thom: hmm, odd. I did not do this deliberately, sorry
<thom> we uploaded with start-stop-daemon --start --quiet --background --exec $DAEMON -- -F
<thom> oh well, fixed as i say
<thom> just don't do it again :P
<Keybuk> cupsys_1.1.22-2/debian/patches/ubuntu-init.d.patch
<Keybuk> was in there
<pitti> thom: it's not in http://people.ubuntu.com/~scott/ongoing-merge/cupsys/cupsys_merged.debdiff
<pitti> darn
<Keybuk> pitti: no, but it is in 1.1.23-1ubuntu1
<pitti> so I removed all the "we patch debian/" patches to rely on m-o-m
<pitti> and now I am walloped again
<Keybuk> sorry, I mean you dropped it in that version :p
<pitti> hrm
<pitti> I think I better go back messing up^W^Wfixing squid...
<HostingGeek> i'll just like to point out a comment from wiki/PackageManager
<HostingGeek> Apart from installating from web browser, anoter VERY useful feature would be for the user to click in a .deb file, and synaptic opens and installs it. If there are missing dependencies, tries to find them in the repositories that the user had configured. If the file cannot be installed because of dependencies, then warn the user, else install the .deb without needing to open the console.
<HostingGeek> if this is possible for hoary it should be done
<robertj> I think that would be good if it was signed by a trusted key
<Kamion> that's what I told HostingGeek the last time he asked about this ...
<HostingGeek> Kamion: i know 
<HostingGeek> the reason why i pointed it out here for you guys to repond to it
<sladen> HostingGeek: I think somebody was talking about a   kilk://package-name  URI which could then be feed to apt-get/kilk/synaptic to install 'properly
<sladen> HostingGeek: could you research and find out what Linspire do in this area?
<HostingGeek> Kamion: i forgot the reason why packages are not sign instead of reps
<robertj> just a pie in the sky idea: what if every time you went to a web site it added it to a list of software in gnome-app-install under a seperate section
<robertj> that's really probably something more for beagle though
<jdub> robertj: not entirely pie-in-the-sky :)
<mvo_> HostingGeek: for the "install a deb directly", it's not trivial and needs quite a bit of internal changes in apt to get the dependency stuff right
<robertj> it would also be able to apt-get install mydeb.deb
<HostingGeek> hmmm idea:
<robertj> also, theoretically we could use fam to log installs of software that weren't done through app
<mvo_> robertj: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=47379 for details
<HostingGeek> make it more known that anyone can add apps to universe
<sladen> well, you could download a tarball that expanded to a reposetary, which could then be (temporyily) added to sources (pinning hack?) and the packages within that installed
<sladen> this would pull in all the depndancies---or complain
<HostingGeek> as i am banned from #ubuntu can someone tell me what apps in this screeny http://geeklog.eyesopened.nl/ubdates/notif.png
<sladen> HostingGeek: why are you banned there?
<HostingGeek> sladen: no idea
<azeem> HostingGeek: "as i am banned from #ubuntu..." should indicate to you that your question is off-topic here
<sladen> presumbly the person who banned you told you?
<HostingGeek> no
<HostingGeek> i went offline and reconnected now and found out i am banned
<sladen> riiihgt.
* HostingGeek look at daniels to see if it was him
<HostingGeek> so can anyone answer me i know its offtopic but what can i do?
<azeem> HostingGeek: you can ask on the forum
* T-Bone notes that HostingGeek is also banned from #ubuntu-devel, as the banlist says
<HostingGeek> i am?
<T-Bone> --- #ubuntu-devel Banlist: Tue Jan 11 16:07:08 %*!*HostingGe@*.exetel.com.au Keybuk!scott@descent.netsplit.com
<T-Bone> unfortunately the mask wasn't broad enough
<T-Bone> you've been repeatedly told to stop asking off-topic questions and to RTFM
<HostingGeek> ohh Keybuk you remove the ban? you said it only going to be for a day or two?
<Treenaks> HostingGeek: apparently you haven't learned.
<Keybuk> no, if you don't stop asking questions on the wrong channel, I'll extend it
<sladen> HostingGeek: your development-related quetsions here were good, I suspect if you write them up that may gain you favour with them-what-did-it
<HostingGeek> ok if someone mind tell me whats allowed in #ubuntu and whats allowed in #ubuntu-devel i'll follow it (it must be almost idiot-proof)
<T-Bone> HostingGeek: care to look at the topic?
<mdz> morning
<T-Bone> mdz: hi!
<ogra> morning :)
<mvo_> hi mdz 
<crimsun> moin
<ogra> mdz: the yesterday live cd is the first one that worked on my new laptop ..... thanks :)
<mdz> ogra: great!
<sivang> ogra: then I should also download, mine also didn't work...
<HostingGeek> T-Bone: ummm DeveloperResources?
<HostingGeek> the ubuntu about page: would it be better just to hack gnome-about?
<ogra> sivang: i'm on amd64 with nvidia and 16:10 display.....a lot of possible failure factors :)
<robertj> so if you create a crappy package, it works, linda doesn't barf, what's the usual next step?
<mdz> ogra: were you asked any X questions?
<mdz> robertj: lintian :-)
<ogra> robertj: build a binary, install and test it
<robertj> ogra: well it works :)
<robertj> ok lintian is complaining, i'll polish up these annoyances real quick though, what's next?
<ogra> mdz: yup....but x detection neer worked here.... i already talked to daniels and will file a bug on the weekend if i switched back to nv 
<ogra> never even
<ogra> mdz: but it was the first one that was able to start x at all....(the desktop will still need some bugfixing, is that amus work ?)
<amu> ogra: no, gnome default, parse error; desktop needs some bugfixing?   
<ogra> broken icons....the panel was not responsive at all and gnome-settings-daemon hung....
<robertj> now linda and intain are both quiet ;)
<zul> mdz: i have a question for you are the  motu bugs in the bugzilla actually resolved or just placed on the backburner for later
<HostingGeek> why is About ubuntu point to a html page when it should really be a hacked version of gnome-about? (sry if said two times connection problems....)
<mdz> ogra: which live CD?
<mdz> 20050120 did not have that problem for me
<mdz> HostingGeek: no, it is better to have a page which is written specifically for Ubuntu
<mdz> the documentation team are working on an improved one for Hoary
<HostingGeek> why?
<ogra> mdz: which problem .... (i downloaded it overnight (burned about 8hrs ago))
<mdz> ogra: the panel problems
<sivang> HostingGeek: care to give them some help?
<HostingGeek> personally i'll like a a app than my browser opening so it can start at first login
<sivang> HostingGeek: it will work under yelp
<ogra> ah...hmm, i havent investigated deeper (my job steals my time ;) )
<ogra> i will look into it again tonight
<HostingGeek> sivang: i don't mind hack gnome-about
<sivang> HostingGeek: no, not gnome-about - the ubuntu about page
* ogra thinks there should be a MOTU home in the wiki....
<robertj> mdz: but to my very limited understanding of how things work, the .deb seems to be okay, and all the automated checks seem happy
<HostingGeek> sivang: but if it was a hacked up version of gnome-about it can be started up at first boot with a option not to start up again
<HostingGeek> i hear manbrake has something like this
<mdz> ogra: agreed
<sivang> HostingGeek: I think the tendency is not to pop windows unwillingly infron of the user in ubutu, maybe one time window opened after install would be there, this is still worked by the documentation team.
<sivang> HostingGeek: and you don't have to particulary hack the gnome about page so it could open, you can do it with whatever page you like.
<HostingGeek> sivang: by gnome-about i am talking about that nice looking about app not a html page
<sivang> HostingGeek: yelp is the app, docbook xml is the page :)
<HostingGeek> sivang: no i am talking about the one i am about to take a screeny of
<ogra> sivang: run: gnome-about     in a terminal
<kent> HostingGeek, they know what the about-gnome program is.
<robertj> mdz: so what's the next step, hit up debian-mentors for a sponsor?
<mdz> HostingGeek: the one you are looking at will be, as I said, replaced
<ogra> robertj: you want to be a DD ?
<ogra> robertj: or a MOTU ?
<robertj> ogra: MOTU? I don't want to be a full dd, I just want my package included
<HostingGeek> http://img137.exs.cx/my.php?loc=img137&image=screenshot3cj.png this is yelp 0_o
<ogra> robertj: Master of the universe :)
<ogra> robertj: a ubuntu universe maintainer
<robertj> oh
<sivang> ogra: ah k, well, gnome-about is for gnome that we are using, yelp with the about page specifically for Ubuntu? ;-)
<robertj> nothing quite that ambitious
<ogra> robertj: the question is, do you want to be able to upload yourself, or do you just want to give your package to someone for uploading
<robertj> probably just give it to someone
<HostingGeek> so is that app yelp????
<HostingGeek> it look nothing like yelp to me
<HostingGeek> and is it possible to remove the about gnome entry by default it doesn't look right with about ubuntu 2 stop under it
<robertj> ogra: is'nt there an official debian process for that thoug?
<ogra> robertj: we are not debian ;)
<ogra> robertj: its quite easy to become a MOTU yourself.....
<robertj> well yeah, but I was thinking that it would be better if it trickled into universe
<robertj> no offense, no ;)
<ogra> robertj: steps:
<ogra> 1. make some (any kind of) contribution
<robertj> check
<robertj> (barely)
<ogra> 2. make all the buerocracy stuff needed (a wiki pge about you etc)
<ogra> 3. get approved by the CC to be a _member_
<ogra> 4. get approved by at least 2 TB members to be allowed to upload to universe
<ogra> 5. done ;)
<robertj> hrmm, mentors.debian.net has a deceptively easy looking form
<ogra> robertj: i forgot....a valid, signed and trustworthy gpg key :)
<robertj> yeah, I need to get one signed, I'll send a note out to the campus it group here
<robertj> although not today, I'm *sick*
<ogra> robertj: oh, get well then ...
<robertj> *cough*
<HostingGeek> sivang: is that app in the screeny yelp???
<jdub> HostingGeek: of course not, that's gnome-about
<ogra> HostingGeek: type yel in a terminal
<ogra> yelp even
<HostingGeek> jdub: arghhh then why did they it is
<HostingGeek> ogra: i know how yelp look like
<ogra> HostingGeek: then i dont understand your question
<HostingGeek> but from my understanding you guys are saying gnome-about is a page in yelp
<jdub> HostingGeek: will be, will be
<HostingGeek> yuck
<jdub> HostingGeek: the about ubuntu page will be displayed in yelp
<HostingGeek> why
<jdub> the gnome-about thing will still be there, but won't be in the menu
<HostingGeek> its better to hack gnome-about
<jdub> no, it's not
<ogra> HostingGeek: nope
<jdub> we've decided, between the doc and desktop team to display it in yelp
<tseng> gratitious patching of upstream = gross
<ogra> HostingGeek: you can feed yelp with xml.....
<HostingGeek> its looks a lot better, you can start it at first boot with a little option to disable it from starting at first boot again...
<ogra> HostingGeek: for gnome-about you have to modify the app
<jdub> you'd have to change g-a fairly significantly to suit our needs and add features like taht
<sivang> HostingGeek: that can be doen with yelp also, not sure we want to do that.
<HostingGeek> i can edit the app
<sivang> HostingGeek: could be done with a mere shell script IMHO
<HostingGeek> sivang: but the app looks nicer than yelp
<ogra> HostingGeek: you would have to edit the app for every small change
<HostingGeek> ogra: so you make the app read a page then
<ogra> HostingGeek: while you just change the xml for yelp
<sivang> HostingGeek: and xml allows far more easy modifications.
<sivang> ogra:  :)
<HostingGeek> or have a xml read
* sivang new yelp rendering is way cool
<HostingGeek> sivang: so we can edit that app to read the text from a xml page
<sivang> thinks, even
<ogra> HostingGeek: so you would have yelp with a gnome-about frame....
<jdub> HostingGeek: dude, the decision is already made. the document will look great, don't worry about it.
<sivang> HostingGeek: why would you like to have this?
<kent> HostingGeek, a bit overload to make one application read xml/html, etc, when we already have one which do
<pitti> lamont: Hi!
<pitti> lamont: I still could not upload the langpacks; I really miss elmo :-)
<ogra> oh , he is away ?
<zul> ahh isnt that sweet :)
<ogra> hi pitti
<HostingGeek> but for a about program see the toolbar and menus by default is ugly
<kent> but as far as i understand HostingGeek, i also think that Ubuntu could use an application which starts on first boot which could offer a guide of things usually works in Ubuntu (CD-writing, network-administration etc)  (but that can be a something yelp can show)
<pitti> Hi ogra!
<HostingGeek> kent: i hear manbrake has a very good app which does this
<HostingGeek> but i guess its in QT
<zul> hey pitti how goes it?
<HostingGeek> manbrake is a kde distro right?
<jdub> mandrake ships both
<jdub> most of their admin tools are gtk/perl based
<pitti> Hi zul. Lots of security fixes, as usual :-)
<HostingGeek> jdub: good
<HostingGeek> jdub: why not take there app....
<jdub> because we have the docteam's work already, should we decide to show something on first bootup
<zul> pitti: nice did you make any changes to hardened kernel?
<HostingGeek> jdub: yes
<HostingGeek> jdub: something that links to all this stuff like in manbrake
<pitti> zul: I started to adapt grsecurity to our current kernel today
<zul> i c
<pitti> zul: however, some rejections are quite big, this will take me a whilw
<zul> wouldnt surpise me
<tseng> pitti: youll have some problems with the do_brk fix
<tseng> pitti: pax already modifies that code block to add a lock
<pitti> tseng: I already resolved that
<tseng> great :)
<pitti> tseng: I only have mm/mmap.c left
<pitti> tseng: but that is a tough one
<tseng> one second
<pitti> tseng: I had too much else to do today to finish that
<ogra> Kamion: wrong array url !
<jdub> HostingGeek: you'll get a better reception here if you leave out the unnecessary smart-arse misspellings
<Kamion> ogra: d'oh
<HostingGeek> jdub: no it broke my friends computer and thats why i unoffical renamed it
<Kamion> ogra: correction sent
<jdub> HostingGeek: leave it out, thanks
<ogra> :)
<HostingGeek> jdub: but can we port it to ubuntu and ubuntuize it
<jdub> HostingGeek: no, we're using the docteam's work.
<jdub> Kamion: daily == array 3 atm?
<HostingGeek> jdub: you missed what i said, this app only shows up on first boot AND links to docs and the website....
<tseng> pitti: im basing my tree on -ac atm, who has the uselib fix, we're patching it back out and using one from spender: http://dev.gentoo.org/~tseng/kernel/4003_grsecurity-secfix-200501071130.patch
<jdub> HostingGeek: i know what it is
<tseng> pitti: do you have any other conflicts on mmap.c?
<Kamion> jdub: yes
<mdz> Kamion: sarge boots 2.4 by default on CD #1, right?
<jdub> Kamion: ta
<mdz> (i386)
<jdub> Kamion: going to try out usb too :)
<HostingGeek> jdub: but it doesn't mean you don't use yelp and the docteams work
<lamont> pitti: :-(
<lamont> fabbione: linux-source-2.6.10_2.6.10-10_20050120-0734 04:22:57 (1 entry, sigma 00:00:00)
<lamont> now to see if they actually work....
<pitti> tseng: this patch looks like a recent security udpate
<tseng> yep, what else do you have touching  mmap.c?
<Kamion> mdz: on every architecture except powerpc
<Kamion> jdub: cool
<pitti> tseng: http://people.ubuntu.com/~pitti/mmap.c.rej
<Kamion> mdz: and soon hppa; bdale's moving it, 'cos 2.4 really sucks on hppa
<HostingGeek> why are there no bugs filed for firefox by ubuntu (instead of maoning on the mailing list) for firefoc not using gnome's proxy settings
<T-Bone> hell yes
<HostingGeek> hell yes means?
(fabbione/#ubuntu-devel) one powerline failed for no apparent reason
<fabbione> and the adsl went down
<fabbione> thanks
<fabbione> i am back to work in the house
* T-Bone bbiab, dinner time
<sladen> T-Gone: have you heard of  /away
* pitti tests array 3
<seb128> pitti: you should take some rest sometime :p
<HostingGeek> hmmm seems like screem might have to be upgraded 
<HostingGeek> i am having a problem where the default profile load a loop of untittled pages 
<mdz> haggai: ping
<pitti> seb128: right, I will stop working and go to my parent's house anyway :-)
<seb128> pitti: good :)
<pitti> seb128: but before I want to finish array 3 installation on my Desktop :-)
<amu> mdz: looks like he's away, didnt saw him, last 6h 
<mdz> I want my oo.o2
<T-Bone> sladen: I may have, but I'm pretty deaf ;P
<amu> I want openoffice.org-l10n-de ( from the 1.1.3 ) :) 
<mako> dude, i was (just* about to send a message to mdz
<mjg59> mako: He knew
<HostingGeek> mdz: package it for us plz (even thought someone else is but there tacking there time...)
<T-Bone> yeah, that's why he ran away :)
<HostingGeek> arghhhh
<HostingGeek> he ran away
<T-Bone> mako: howdy!
<pitti> Kamion: do you really think the new format/use behaviour of the installer is better?
<pitti> Kamion: I find it horribly confusing
<mako> T-Bone: hey there ace
<trukulo> hi
* HostingGeek bets mdz is having a kernel-panic
* HostingGeek feels for mdz
<T-Bone> lamont: ping?
<HostingGeek> mdz: wb
<HostingGeek> mdz: kernel-panic?
<mdz> HostingGeek: #5234
<pitti> Kamion: kudos, array 3 @i386 works very well :-)
<mdz> mako: what were you going to message me about?
<HostingGeek> mdz: arghhhh thats bad for me it thundering and i only have one kernel installed and that the b0rken one 
<HostingGeek> better quickly apt-get another one
<lamont> T-Bone: ack
<mako> mdz: i'm writing an email
* T-Bone points lamont at the other window ;)
<mako> mdz: but anyway, a super-motivated hacker i know just emailed me about ubuntu on servers. he's since caught up all the dicussions so far and has a handful of suggestions and has suggested a server-team (like a laptop team)
<lamont> doh
<mako> mdz: he always wants to deploy it in an entire college i think :)
<mdz> Kamion: I'd like to publish a companion set of live CDs for array 3
<mdz> Kamion: I'm going to test the current dailies
<HostingGeek> seb128: read my reply to your comment in the mailing list
<mdz> mako: I think we already have a server team; there's just no one on it yet ;-)
<seb128> HostingGeek: ELACKCONTEXT, which list/comment ?
<sivang> mdz: we do, accoring to the website. thom is the lead :)
<seb128> HostingGeek: gstreamer0.6 ?
<seb128> HostingGeek: upgrade of what ?
<HostingGeek> seb128: yes
<HostingGeek> seb128: warty > hoary
<HostingGeek> seb128: woody > hoary
<mako> sivang: it's not on wiki/Teams
<HostingGeek> seb128: sarge > hoary .....
<seb128> HostingGeek: and how this will help upgrades ?
<sivang> mako: oh, well, we should add it there then.
<seb128> HostingGeek: the package is removed
<seb128> HostingGeek: you want to delete the file over the user decision ?
<HostingGeek> seb128: it needs to be a dummy 
<seb128> HostingGeek: user is free to keep using it, why forcing to delete it ?
<seb128> HostingGeek: it doesn't
<HostingGeek> seb128: good point but then why do this with famd?
<seb128> because it conflicts with gamin
<mako> sivang: yes, absolutely
<seb128> gstreamer0.6 doesn't conflict with anything
<seb128> HostingGeek: BTW you replied to me and not to the list :p
<HostingGeek> seb128: i fwd it...
<seb128> ok
<HostingGeek> i noticed itand slapped gmail
<seb128> I read the lists, no need to send a direct reply
<seb128> ok
<trukulo> ogra, did you tried new graveman ?
<ogra> trukulo: i uploaded already :)
<sivang> mako: I am adding the entry, ok?
<trukulo> ogra, cool, but here, in my warty, i't doesn't detect my burner
<ogra> trukulo: awaiting elmos approval.....but he has to fight some real world probs today i heard
<sivang> mako: (for the server team)
<ogra> trukulo: same error as ever....but works for a handfull of atapi and all scsi writers...
<ogra> trukulo: its quite easy to work around though
<HostingGeek> can xchat replaced with xchat-gnome in the next release of xchat-gnome?
<ogra> trukulo: you just need to edit the config file and add ome lines
<trukulo> ogra, yeah, i know
<HostingGeek> xchat-gnome: http://xchat-gnome.navi.cx/
<trukulo> and i added that in README, and send it to sylvain
<thully> has anyone noticed breakage in the gnome networking applet which causes it to be impossible to configure DHCP for a wireless connection there?
<trukulo> ogra, cat /usr/share/doc/graveman/README
<ogra> trukulo: as long as he uses the cdrecord scanbus method for atapi drives it wont get better :(
<trukulo> yeah, unfortunately
<trukulo> but program is getting better day by day
<ogra> /usr/share/doc/graveman/README reminds me.... i wanted to sendf a germn translation
<mako> sivang: aweseome, thanks sivan
<trukulo> ogra, to sylvain? for graveman?
<ogra> trukulo: yup...but i'm currently a bit short of time....
<trukulo> ogra, as everybody man
<ogra> trukulo: and the number of strings seems to grow daily ;)
<trukulo> ogra, and versions...
<trukulo> new version every two days
<thully> is the volume control applet currently broken in hoary, out of curiosity?  It doesn't appear for me currently (it appears to be there, but the actual control is invisible)
<ogra> thully: change the device (file->select device)
<ogra> thully: in the real volume-control, not the applet that is
<thully> does nothing - it still doesn't show up in systray
<haggai> mdz: pong
<ogra> thully: if the master of the alsa mixer is at 0 level it is hidden....
<thully> That seems like a bad idea
<pitti> seb128: do you use gaim?
<thully> I see it - but I think it isn't a good idea to do this by default
<seb128> haggai: hi, how is going the OO.o2/eds/link issue ?
<ogra> thully: yup....i'm still considering if i categorize it as bug or feature :)
<seb128> pitti: yeah, that and gossip
<thully> bug
<thully> that's my vote
<ogra> thully: ...it avoids an error dialog if sound doesnt work
<haggai> seb128: I can't reproduce it, very wierd.  I even set up an sbuild and although it's not finished yet it is already a long way through
<pitti> seb128: since a few days, the gaim panel icon reduced to an 3-pixel wide line
<jbailey> pitti: Mine did that and then stopped doing that.
<pitti> seb128: for you as well?
<seb128> pitti: oh, interesting, you can reproduce it ?
<ogra> thully: so it has advantages.....
<jbailey> pitti: Hasn't done it for me again since.
<pitti> seb128: it's here
<thully> however, if the driver ends up muted by default (which seems to happen with ALSA a lot) then the user is left confused with no sound applet in their tray
<tseng> that happens to me only when starting a new session with gaim in it
<pitti> seb128: I cannot make it work again
<seb128> pitti: no, had a such issue sometime but didn't get it for months
<tseng> before the panel is fully loaded
<ogra> thully: if the mixer is muted by default thats a bug in the alsa setup....
<seb128> pitti: only with gaim ? or with rhythmbox/gossip/other icon for the notify too ?
<mdz> Kamion: ok, make that "would have liked"
<mdz> the daily is fucked
<sivang> mako: https://www.ubuntulinux.org/wiki/ServerTeam
<sivang> mdz: livecd?
<mdz> usb mice don't work
<mdz> alsa unmuting doesn't work
<pitti> seb128: I just installed array 3 freshly
<pitti> seb128: so I can only try to remove my gnome configuration stuff
<haggai> seb128: yeah, it just got to the final project with no problems
<pitti> seb128: no, other icons work fine
<thully> anybody tried to configure wi-fi through network applet in GNOME?  setting DHCP doesn't stick for me
<seb128> haggai: perhaps that was an evolution-data-server bug and I fixed it with my uploads :)
<haggai> seb128: hmm, could be
<haggai> maybe I should just upload and see what happens
<seb128> I've added some -dev depends
<seb128> yep
<seb128> go go go
<haggai> there are some deps I fixed on the oo side too
<seb128> pitti: could you keep the bug until tomorrow ?
<pitti> seb128: sure
<seb128> pitti: the panel devel who made the layout patch is interested in this issue but he's not able to reproduce it
<seb128> he's away atm but will probably be online tomorrow
<seb128> I'll let you know how to get useful stuff :)
<HostingGeek> can vhcs be included into universe there are debs for it which are under testing homepage: vhcs.net (its a free stable open source working feature rich control panel)
* lamont bangs head on table.
<haggai> HostingGeek: are you interested in maintaining them?  There aren't enough people to upload everything
<lamont> fabbione: you around>?
<mdz> Kamion: hotplug seems completely b0rked, no idea why
<HostingGeek> haggai: yea
<HostingGeek> haggai: the debs are all ready there and working but still have a lot of bugs
<crimsun> HostingGeek: there seem to be quite a few major bugs
<HostingGeek> but if i can get it into universe it will be good
<ajmitch> haggai: there are a few volunteers around for uploaders to universe now
<HostingGeek> crimsun: tell me about it, but it worked on my box and seem mostly fixed
<ogra> haggai: btw: are you our MOTU master now ?
<haggai> HostingGeek: did you test that the packages build on ubuntu?  Sometimes some build-deps may need adjusting, and you'll need to add an -ubuntu version no
<ogra> ajmitch: currently two to be precise....
<crimsun> (I would love to be contribute to universe, but I presume I'm supposed to wait until CC meeting next Tuesday.)
<ajmitch> ogra: 2 people who can upload, or 2 waiting to get the nod from the CC & others? :)
<HostingGeek> can it still get into hoary?
<haggai> ogra: well, I said I'll do it but haven't heard anything official back.  I'm not sure elmo has implemented everthing yet
<ajmitch> yes, I'd love to get to the CC meeting, but it happens to be at 5AM NZ time
<ogra> ajmitch: two who can upload .... and hopefully crimsun next week :)
<HostingGeek> haggai: yes it just needs one edit.... and this edit is also need for debian
<ajmitch> ogra: may I join that list of hopefuls? :)
<ogra> haggai: not completely....but nice to hear, since i'm MOTU now :)
<ogra> ajmitch: you have to fulfill some criteria first....
<haggai> HostingGeek: please do that and I'll take a look.  Let me know at chris.halls@credativ.co.uk
<crimsun> ajmitch: I'm unsure whether it _must_ take place at a CC meeting. It sounds like 2 CC members need to approve, and that can occur at any time, but I need to confirm that with mako/mdz
<ogra> ajmitch: start here: http://www.ubuntulinux.org/wiki/MaintainerCandidates
<haggai> ogra: cool :)  what are you planning on maintaining?
<mdz> crimsun: anytime
<ajmitch> ogra: already on there
<crimsun> mdz: thanks muchly.
<mako> crimsun: for MOTU stuff, it doesn't need to be done at a meeting from now until hoary releases
<crimsun> mako: great, thank you :)
<HostingGeek> haggai: well i'll get BeeEmm to maintain it as he makes the debs is it possible for it to be in main once all bugs are fixed as apache2 is in main
<ajmitch> ogra: what about the CoC?
<ogra> haggai: i'm targeting main, so i wont pick a special package in universe but fix all bugs in everything that needs it i think
<HostingGeek> (not sure if its deps are in main)
<HostingGeek> *all
<trukulo> ogra, did you see my graveman package? tell me if anything is wrong
<ogra> ajmitch: ask mako, he wanted to put a download version up for signing
<pitti> argh: arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<ajmitch> ogra: hopefully (depending on the DAM) I'll be a DD soon
<pitti> I thought that should be fixed in baz 1.1 *grumble*
<ogra> trukulo: lintian didnt complain and i burned a data and a audio cd which work fine :)
<haggai> ogra: ok great
<trukulo> :) cool
<trukulo> but i'm afraid problems building in ppc or amd64
<T-Bone> http://www.ubuntulinux.org/wiki/ <- shows an error message at the bottom of the pages, FYI
<ajmitch> mako: what is the CoC requirement for prospective maintainers?
<haggai> HostingGeek: it can only be in main if it's got someone willing to maintain it for Ubuntu long term
<trukulo> i mean, is my first package, and i'm not confident yet with myself
<HostingGeek> haggai: BeeEmm
<haggai> HostingGeek: sorry I mean Ubuntu not just Debian
<HostingGeek> haggai: he is making those debs i'll talk to him
<HostingGeek> haggai: he can do it for ubuntu
<ogra> ajmitch: how long did it take you ?
<HostingGeek> he has not added it to the debian reps *yet*
<ajmitch> ogra: well, it's taken a long, long time to get this far :)
<ajmitch> and I'm near the top of the queue for DAM approval, it seems
<ogra> ajmitch: ...ubuntu is easier :)
<T-Bone> elmo: ping?
<ajmitch> ogra: yeah, I figure that if I can become a DD, getting into ubuntu will seem simple by comparison :)
<ajmitch> at least they try & make the NM process for debian rigourous enough now - what reviews are in place for people who upload to universe?
<haggai> ajmitch: I, and others yet to be chosen, keep an eye on new uploads
<ajmitch> haggai: alright
<ajmitch> that could get to be a big job
<ogra> ajmitch: only 15000 packages...come on
<haggai> ajmitch: yes 'fraid so
<ajmitch> ogra: thankfully most are borrowed straight from debian :)
<haggai> ogra: thankfully not all of them will be touched..
* ajmitch has a bunch of packages that need uploaded already :)
<crimsun> mdz: / haggai: Are you currently willing to approve me for universe? I've been working on 'rox-filer' (I've already done some work on 2.1.4-0.1 with Frankie [ROX-in-Debian Project, http://alioth.debian.org/projects/pkg-rox/] , diff available at http://www.trilug.org/~crimsun/outside/rox-filer/rox_2.1.4-0.1.diff.gz).
<T-Bone> mako: ping?
<thully> Are we intentionally or unintentionally asking the user for what resolutions to use in stage 2 of the hoary installer?
<lamont> thully: that should only come up if it can't query the monitor
<lamont> or rather, if the query fails
<haggai> crimsun: I can't connect to trilug.org.  Could you mail it to me please?
<mdz> fabbione: what have you changed in the kernel recently?
<thully> it didn't come up in warty for me - but it comes up in hoary
<mako> T-Bone: yes
<mdz> fabbione: I am not getting hotplug events for USB devices at all
<crimsun> haggai: certainly.
<mdz> fabbione: the hci driver is not even noticing that they come and go
<haggai> crimsun: chris.halls@credativ.co.uk
<ajmitch> haggai: so pre-reqs are signing the CoC, then getting you & someone else to approve?
* T-Bone points mako at the other window as well ;)
* ogra sees ooo2 come in....crosses fingers....
<haggai> ajmitch: I believe so.. unless they changed the rules.. yet again ;)
<ajmitch> the rules are a little hazy on the wiki still
<ajmitch> I'm sure it's a way to dissuade casual enquirers, like debian's NM process is designed to break applicant's spirits :)
<ogra> ajmitch: it gets just worked out....we are the guinea pigs ;)
<thully> There is a few default settings in Hoary which I question, and wondered as to the reasoning behind them.
<thully> First of all, why is snd-intel8x0m not blacklisted when it is loaded automatically by drivers which need it and breaks some other drivers (all of said drivers are unsupported)
<haggai> ajmitch: if you want to get in, do something about it :p  - send me a package or too
<haggai> two
<mdz> thully: we have already had this discussion, and you have an open bug report about it.  there is no need to raise the point again and again.
<thully> OK - I saw the discussion, but I never remember any decision being made - did I miss anything?
<ajmitch> haggai: sure, I've got 10 or so here, but they can be uploaded to debian & synced from there :)
<haggai> ajmitch: there's no syncing going on any more
<mdz> haggai: only manual syncing
<ajmitch> no automatic syncing
<crimsun> haggai: sent.
<haggai> mdz: via dev uploads or some other mechanism?
<ajmitch> eg I've got a bug for a package that is fixed in a new upstream version
<mdz> haggai: the email-elmo mechanism
<mdz> which needs to be documented in DeveloperResources
<mdz> could someone do that, please?
<haggai> mdz: indeed
<mooch> seb128: ping
<thully> as to the whole timezone issue - why is the clock assumed to be UTC on a clean install?  The vast majority of systems use local time by default on their system clocks
<seb128> mooch: ?
<mdz> thully: same answer
<mooch> seb128: is it with you i have to talk about a problem with gnome-terminal ?
<mooch> seb128: i can see some horizontal lines in the background of my terminal...
<crimsun> thully: current hoary has a solution for the on-board sound chipsets' modems.
<thully> what do you mean?
<mooch> i took an screenshot and amplified it, and they are certanly there...
<seb128> mooch: is that new ? do you have them all the time ?
<mdz> crimsun: it has a solution for them becoming the default sound device, but thully is complaining about something else
<mdz> he wants to use non-free drivers
<mooch> seb128: is not new, and they appear when i have some text on the terminal
<mdz> and not load the alsa driver at all
<thully> yes - but I know of nothing that benefits from loading the alsa driver - and many things that have problems because of it
<mooch> i can put the file on my webserver and you will see what i mean
<crimsun> mdz: ah, thanks for the clarification.
<haggai> crimsun: hmm, your diff is against a different package version than in universe
<seb128> mooch: do you have a screenshot ?
<crimsun> haggai: yes, 2.0.1 is in universe. I can backport the necessary alternative and further cleanups.
<haggai> crimsun: take a look at http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze and decide if the new version meets the criteria
<mooch> seb128: http://www.pumuki.org/~data/Screenshot.png
<mooch> should be
<haggai> ajmitch: same for you, please bear http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze with the uploads you are thinking about
<ajmitch> haggai: yes, it's not hard for me to put the change into the previous revision
<ajmitch> as the fix I need is just in a postinst
<mooch> seb128: got it?
<haggai> ajmitch: ok, that's what I need to review.
<haggai> ajmitch: sorry I haven't time to actually do the work for you :)
<seb128> mooch: yeah, but that's only some text on a background :p
<ajmitch> I'll rebuild them with the fix on the hoary box here :)
<mooch> seb128: look at it closer
* ajmitch also completely changed the packaging for the new upstream version, anyway :)
<mooch> it has some horizintal lines...
<seb128> mooch: are you sure that's the right link ?
<ogra> mooch: there are only some letters on white bg
<mooch> there are some lines in fine gray
<ogra> mooch: not here...
<mooch> ogra: if you make the pic big enough you will see themmm
<mooch> trust me, is there...
<crimsun> haggai: 2.1.4 is the current stable version [http://rox.sourceforge.net/phpwiki/index.php/ROX-Filer]  and contains relevant fixes to operate correctly with metacity. Despite 2.1.5 being released recently, it seems like 2.1.4 is the suitable candidate against which to base efforts.
<ogra> mooch: you mean i should download it and magnify it in the gimp ?
<mooch> yep
<mooch> or just magnify it under gqmpeg or similar image viewer
* lamont decides that he's better at writing stories than documentation
<thully> P.S. I added the results of the tests Kamion suggested yesterday to the timezone bug in Bugzilla
<ogra> lamont: isnt most of dev resources from you ?
<lamont> ogra: nah - I'm ammeding it to actually explain what happens to your uploads
<crimsun> haggai: there are some urgent issues in Debian BTS; I'll attempt to address the most pressing policy violations
<lamont> the build logs are mine, but the page was someone elses creation
<ogra> lamont: ah, ok
<mooch> ogra: can you see the lines?
<mooch> the show in lines where text is actually there
<mooch> if there is no text, there is no line
<mooch> seb128: can you see them?
<haggai> crimsun: ok, so a new upstream version is necessary to fix problems related to metacity, right?  And, your versioning is for Debian, not Ubuntu
<crimsun> haggai: I'll whip up a new diff tonight and mail it to you.
<mooch> crimsun: how difficult would it be to add window groupping to metacity?
<mooch> crimsun or anyone who could know about it...
<ogra> mooch: http://www.grawert.net/s-shot.png
<haggai> crimsun: ok great
<crimsun> haggai: thanks for your time
<mooch> ogra: so you see the lines...
<ogra> mooch: nope...
<haggai> np
<seb128> mooch: no
<mooch> ogra: reduce the contrast of your monitor, or the brightness
<ogra> mooch: probably my display hasnt the contrast settings 
<seb128> mooch: the windows are grouped in the panel if you active the option
<ogra> wait....
<mooch> i will try to modify the colour balance
<ogra> i see dashed lines if i hold my laptop in a weird angle
<mooch> seb128: i would like to move 2 windows grouped together...
<mooch> ogra: yes! that is...
<ogra> hmm
<mooch> ok, with the edge detector on the gimp:
<mooch> http://www.pumuki.org/~data/Screenshot2.png
<haggai> lamont/elmo: does either of you know off the top of your head where I can override the default path in sbuild?
<lamont> ??
<lamont> I expect $HOME/.profile in the chroot...
<lamont> you're saying that you want to have sbuild use other than the default?
<haggai> yes, adding the ccache dir
<haggai> sbuild seems to call chroot dpkg-buildpackage without modifying the environment explicitly, and there isn't a .profile in $HOME for the user
<lamont> you could see about overriding things by searching for: $env_cmnd dpkg-buildpackage
<lamont> that's where dpkg-buildpackage gets invoked.
<ajmitch> haggai: you want source-only changes for universe fixes?
<lamont> I don't believe that there's anything for specifying environment variables
<haggai> ajmitch: yup
<ajmitch> good, less pressure on bandwidth :)
<haggai> lamont: yes, I couldn't see anything straight off
<lamont> haggai: I know I hacked in arbitrary ENV stuff (for LANG, specifically), but I rather expect that $HOME/.profile is what you really want to mess with
<lamont> er...
<lamont> "cd $bdir && PATH=$conf::path ".
<lamont> if you have that string, then I'd look at .sbuildrc for $path=....
<haggai> oh I searched for PATH
<mooch> seb128: you see what i mean?
<haggai> lamont: are you looking at a patched sbuild?  I can't find PATH in the source at all
<lamont> uh, probably
<lamont> where did you get your sbuild?
<haggai> debian/universe
<lamont> ftp.debian.org, or the good one.
<lamont> ah, that one's crap
<haggai> oh that's great :(
<azeem> haggai: don't listen to lamont
<azeem> :)
<lamont> haggai: the one being used on all the buildd's that I know of is found at deb http://db.debian.org/ debian-admin/
<azeem> lamont: really, the one at debian-admin is pretty crap, too, if you are not running a buildd by chance
<lamont> azeem: well, true.
<lamont> but I'm almost certain it has $conf::path, because I don't remember hacking that in,
<azeem> the buildd I run has the one from debian-admin of course
<haggai> I would have found it believe me I searched for path stuff all over the source of that one
<haggai> lamont: where do I go from that URL?  I'm just on the search page
<lamont> add that to /etc/apt/sources.list is the easiest way.
<lamont> http://db.debian.org/debian-admin/Packages.gz
<haggai> ah secret voodoo
<lamont> and then find what you want and give it the path relative to debian-admin/
<lamont> nah, not secret.  apt.
<mooch> ogra: no comments on that?
<ogra> mooch: no idea, sorry....is this hoary or warty ?
<lamont> haggai: the one in debian-admin insists that the only valid releases are 'stable', 'testing', and 'unstable'... you'll need to defeat that before you can use chroot-hoary...
<haggai> lamont: I already did that for the 'broken' one
<haggai> there is no source package in the Sources.gz
<lamont> sbuild is not modified in building.
<lamont> actually, the source package is wanna-build
<mooch> hoary
<mooch> ogra: hoary updated 2 mins ago
<haggai> lamont: ah thanks
<ogra> mooch: already rebooted to get the new kernel to work and be sure that all changes are made ? did you use backports or any other foreign repo on warty ?
<mooch> ogra: no reboot, but the problem is related with gnome-terminal, not with any other app
<mooch> and the only external repo is mplayer, which is, again, non-related
<ogra> mooch: there are certain changes that would need a X restart i guess (new fontconfig, xorg etc) they all could affect it, i would do a reboot to make sure everything is in place
<ogra> mooch: i did understand you correct, you updated from warty 2 mins ago ?
<mooch> huh! no! I have neved had warty except for the day i installed the mahcine, and that lasted 10 minutes, back in mataro
* lamont solicits feedback on www.ubuntu.com/wiki/BuildDaemons
<mdz> thom: ping?
<ogra> mooch: hmm, so i misunderstood....sorry
<ogra> lamont: nice....at least i understand it :)
<lamont> ogra: is that a good thing??? :-)
<ogra> lamont: how should _i_ judge it (if thats a good thing) ? (wait, i'll ask my GF)
* ajmitch finally gets around to building the package
<lamont> heh
<ajmitch> haggai: package will be done soon, just doing a binary build first (and it's a slow box)
<ogra> lamont: she says its always good if i understand something....hmm
<lamont> hm...
<ogra> lamont: in fact it explains the task very good and i think everybod will easy understand it :)
#ubuntu-devel 2005-02-01
<lamont> ogra: thanks
<thully_> hi - I closed a bunch of my bugs (ones that were obsoleted by changes in hoary, suggestions that really can't be considered at this point, etc etc) and opened a few new ones
<thully_> I added some info to the timezone bug - may help in fixing this
<mdz> haggai: amd64 has failed on oo.o2, but the others are apparently still going.  a good sign, I take it :-)
<thom> mdz: yo?
<mdz> lamont: it looks like the locales in the cloop image are selected, but not actually generated yet.  I want them to be pre-generated
<mdz> thom: never mind
<lamont> mdz: grumble.  I thought I _had_ pregened them.
<lamont> will fix.
<mdz> lamont: well, 
* lamont must go fetch his daughter
<mdz> I'm getting the usual complaints from perl, at any rate
<mdz> but when locale-gen runs, it lists all 4 locales
<mdz> (and after that the errors go away)
<lamont> right.
* lamont bets on fat fingers.
<lamont> will investigate tonight\
<mdz> thanks
<lamont> but also mustn't be late.
<lamont> bbiab
<mdz> thom: have you tried the live CDs yet?
<jdub> so the livecd image building bits... do we have a timeframe for cracking those open?
<ajmitch> haggai: ok, finally built :)
<jdub> have some more people interested in doing customised livecds
<ajmitch> the .diff.gz is a mere 1.9MB
<T-Bone> jdub: i'm one of these ;)
<jdub> mdz: ping
<mdz> jdub: pong
<mdz> jdub: those two things are not related
<mdz> sivan green and brian sutherland are in the process of writing a HOWTO at this very moment
<mdz> based on customizing an existing Ubuntu live CD image, rather than building it from scratch, which is far preferable
<mdz> it's very simple
* T-Bone calls it a night
<jdub> ok, urling up the dude on the in-progress document
<thom> mdz: not yet
<mdz> thom: are you short on bandwidth where you are now?
<thom> no, just short on anywhere to put computers until i get a desk on saturday
<seb128> thom: do you have the bogus webdav around ? 
<seb128> thom: not needed now but would be nice to try some fixes tomorrow
<thom> seb128: no. i'll talk to old job tomorrow and see if they'll reopen it
<seb128> ok
<seb128> thanks
<thom> seb128: so my new firefox works and epiphany still works so i'm gonna upload
<thom> you can apply the ephy half of that patch and we get search again
<stockholm> huhu!
<stockholm> does canonical have a logo, too?
<jdub> stockholm: canonical.com
<seb128> thom: rock, thanks !
<stockholm> geee. (c:
<stockholm> on that page i dont see a telephone number...
* stockholm checks whois
<mako> stockholm: what sort of telephone number are you looking for?
<stockholm> mako: optimally for marks. 
<stockholm> i want to harass him becaues of debconf sponsorship in general and debconf5 specifically
<daniels> stockholm: email generally works well
<daniels> we all have internet access
<stockholm> daniels: oh. (c:
<stockholm> i got delegated to jane.
<stockholm> ok, thanks
* daniels slaps forehead.
<jdub> yeesh
<jdub> thom: hrm, not to, um, pour salt on the would immediately after your firefox upload, but...
<jdub> thom: are the fileselector changes remotely useful to us at this point?
<thom> jdub: the ones that fedora ship?
<jdub> fedora and novell; not sure if it's the same code
<thom> i've not looked at the novell sources, probably ought to
<daniels> jdub: ez gtk boooog
<jdub> ;)
<daniels> thom: 'entertaining' doesn't do that version number justice
<thom> heh
<daniels> something like 'ludicrously insane'
<daniels> comic relief while we were all stressing during the warty crunch :)
<lamont> Kamion: you around?
<lamont> fabbione: or you?
<mdz> lamont: oo.o2 still chugging along?
<lamont> mdz: only 21 MB of log file so far.
<lamont> and it's only been  building for 170 minutes..
<lamont> given that oo.o 1 takes 4:47....
<toresbe> is 2.0 out?
<lamont> this is one of those packages where no log file is a good thing... :-)
<lamont> openoffice.org2_1.9.66-0ubuntu6
<toresbe> aha
<lamont> looks like a pre-rel version to me...
<toresbe> heh, yeah
* daniels stares at mdz.
<toresbe> there was a cool report about Linux on Norwegian TV
<toresbe> they got some parts ludicrously wrong ("In 2003, Novell bought Linux, and sought to commercialize the previously free system")
<toresbe> but they did some really cool interviews with Skolelinux (easy-to-setup special-purpose school distro)
<toresbe> and a lot of the students were really positive towards Linux
<mjg59> daniels: http://www.codon.org.uk/~mjg59/tmp/xglx.png
<mdz> daniels: you need to kick this habit of closing bugs just because they're difficult to fix
<mdz> especially when someone else is working on fixing it
<mdz> lamont: well, that's about 20.99MB farther than the last one got
<daniels> mdz: i just saw the REOPENED, not the rest.  it's usually traditional to provide a comment. ;)
<daniels> mjg59: pimp
<mjg59> daniels: So, *so* much faster than using composite on i855 otherwise
<daniels> mjg59: gotta love xaa
<thom> mjg59: holy transparent terminals, batman!
<jdub> composite on nvidia is actually pretty respectable
<jdub> but oh man
<jdub> i855
<mjg59> I have seen the future, and it is xglx
<daniels> mjg59: s/xglx/not XAA?
<daniels> s/.$/\//
<mjg59> (on mesa-solo, not on X)
<jdub> i didn't realise what all the fuss was about composite being not ready until i ran it on i855
<mjg59> daniels: Pff. Like anyone's ever going to get round to doing decent render acceleration for i810
<lamont> mdz: heh
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | today is "make mdz happy by actually downloading and testing a Hoary live CD" day
<tseng> mdz: you said the nightly was bunk, which should I grab?
<mdz> tseng: I have no idea what is wrong with it, which is why I need people other than me to be testing them
<mdz> even better would be if people other than me had tested yesterday's, and could confirm whether this problem is new
<mdz> as it is, USB functionality seems completely fucked and I don't know why
<mdz> thom: still here?
<mdz> thom: it might help me if you could diff the manifests for the past few live CD builds
<mdz> thom: unfortunately they're only available inside the isos, so I can't get to them on little
<thom> mdz: i'm litterally about to fall into bed. can you send me a mail and i can check first thing tomorrow, if that's any good?
<lamont> mdz: on little... http://mcmurdo.buildd/~buildd/livecd/
<mdz> I'm grasping at straws here
<lamont> you want current, and some previous directory
<lamont> that is, for i386
<mdz> lamont: could you grep those for kernel stuffs and see when it changed?
<sivang> mdz: iso links on the wiki page as usual? (for testing)
<lamont> sure - "grep linux"??
<mdz> if you could tar up the past week or so and send it to me, that'd be good
<mdz> sivang: I think the wiki page has a link to the index
<lamont> heh - terranova, anyway
<sivang> mdz: ok, current is the one right?
<lamont> mdz: people.ubuntu.com/~lamont/mdz/manifests.tar.gz
<mdz> sivang: yes
<mdz> lamont: thanks
<mdz> 20050120.1 and 20050120 are identical
<mdz> how likely is that?
<mdz> 20050119.3 and 20050120 are also identical
<lamont> well, the first one is from the manual run, I expect.  the second one is from 0615
<lamont> it's whatever was on jackass when it ran - would have to compare that to changes, I guess
<lamont> mdz: turns out that I populate /etc/locale.gen, and somewhere decided that would cause locales to generate them...
<lamont> anything else you want done in the chroot?
<mdz> lamont: nothing comes to mind
<mdz> lamont: if you could make USB work again, that'd be great ;-)
<mdz> mjg59: for some reason I see the apm module loaded twice, once "overridden by ACPI", once "disabled on user request". do you know why?
* ogra starts the downloads of 3 livecds (testing tomorrow)
<ogra> night
<mjg59> Erm. Nope.
<mjg59> It should only be being loaded from /etc/modules
<jdub> https://www.ubuntulinux.org/wiki/JoeZicarelli
<mjg59> Unless apmd tries to modprobe it, or something
<mdz> it's not in /etc/modules
<mdz> but apmd does try to modprobe it
<mjg59> Hrm. I thought it was meant to be.
<lamont> mdz: right.
* lamont will go into town in a little bit and fetch some images to play wiht
<lamont> mdz: btw, _does_ debian do rsync-able .debs by default?
<mdz> lamont: no
<lamont> I rather expect that there is a good deal of non-determinalism in the file system, which complicates things for us as well.
<lamont> fs layout that is.
* lamont grumbles at his router
<lamont> mdz: number of blocks allocated in a cg affects the placement of a new block, no?
<mdz> lamont: I think the blocks are large enough that we'd be ok with --rsyncable
<mdz> but we could always crank it up to 4k if needed
<sladen> lamont: this is puzzling me.  AFAIK, the cloop/cramfs effectively compresses each 64kB block separately.  ...therefore there should already be a fair amount, ---but only 64kB at a time
<lamont> sladen: hence my assertion that the placement of files on the device is varying
* lamont goes to test his assertion
<mdz> we tested that already
<mdz> by matching the cloop block size with the filesystem block size
<mdz> it didn't help
<lamont> mdz: I'm going to rsycn 20050120.1/livecd-fsimg onto a copy of 20050120/livecd-fsimg and see how much diff there is - shouldn't be much...
<lamont> or the situation is hopelesss
<mdz> huh?
<lamont> if the original fsimg is rsyncable, then it makes sense to try and make the cloop rsyncable
<lamont> if not, then not.
<mdz> oh
<mdz> it will be
<mdz> I have confidence
<mdz> I didn't realize fsimg -> uncompressed
<lamont> yeah
<thully> I've been fiddling with autohinter - I've found that there are some statements to test font size
<daniels> thully: patches gratefully accepted ...
<sladen> lamont/mdz does an ISO contain all the extra 2048->2352 overhead ?
<lamont> livecd-20050120.1-i386.fsimg-1024
<lamont>   2147482624 100%   14.96MB/s    0:02:16  (1, 100.0% of 1)
<lamont> wrote 2147744895 bytes  read 40 bytes  14966863.66 bytes/sec
<lamont> total size is 2147482624  speedup is 1.00
<lamont> that looks like a 'NO' to me.
<sladen> lamont: that's just the cloop filesystem?
<lamont> uncompressed
<mdz> lamont: interesting
<mdz> lamont: how about -B 1024 ?
<thully> I've got some ideas, but I'm not quite sure about the syntax of fontconfig files - and all autohinter fonts look good on my machine, so It's a little hard to tell
<sladen> ...why is so precisel half?
<lamont> that was 1024
<lamont> sladen: half??
<lamont> speed? that's just the sucky disks we ahve
<mdz> lamont: I mean rsync -B 1024
<lamont> oh
* lamont repeat
<lamont> s
<mdz> sladen: 2048->2352 overhead?
<lamont> actually, syncing the first one back over the copy of #2
<sladen> mdz: cd frames are 2352 bytes eg;  with Audio, all but 8(?) bytes are audio data;  data (mode 1) uses 288 bytes for extreme error detection/recovery
<sladen> == 1 x 2kB sector per frame
<mdz> the default block size for rsync is 700 bytes
<mdz> so 1k filesystem blocks should be just fine, really
<lamont> wrote 2147744893 bytes  read 40 bytes  14761133.56 bytes/sec
<lamont> total size is 2147482624  speedup is 1.00
<sladen> lamont: can you build a fileystem compressed with deflate=0 ?
<lamont> sladen: if the input isn't rsyncable, it doesn't matter _what_ we do in compression
<lamont> and it's not seeing any benefit from rsync
* lamont tries -B 8
<sladen> lamont: hence wanting to know what happens if you create something non-compressed
<lamont> I'm working with non-compressed images
<lamont> mdz: I think the choices come down to (1) come up with some way to populate the filesystem in the manner _we_ want, or (2) live with no rsyncability...
* sladen goes away to re-read cloop source
<lamont> which is really to say (1) fix gene2fs or (2) live with it.
<lamont> s/fix/fix or rewrite/
<mdz> I can't think of anything genext2fs could possibly be doing wrong which would cause this
<lamont> we're not using genext2fs
<mdz> ext2 stores file data in blocks, period
<mdz> or the kernel
<lamont> were lomounting a 2GB file, and rsyncing into that
<mdz> the 2GB file starts out zeroed, right?
* lamont wonders if maybe there is unitialized mem on the end of the frags
<sladen> time to try with small / empty files and investigate what is actually happening
<mdz> GMTA
<lamont> 2GB file starts out as a sparse file with 1KB of zeros at the end
<lamont> I suppose I could try it with it zeroed
<mdz> that should cause it to be zeroed when read from
<mdz> but worth a try
<mdz> maybe loop-mount is weird
<lamont> exactly.  it _shouldn't_ matter...
<mdz> lamont: yeah, and USB _shouldn't_ be fucked on the live CD :-/
<mdz> I am at my wit's end with this thing
<mdz> it makes no sense
<lamont> dd if=/dev/zero of=$IMGNAME count=$SZ bs=1024 
<lamont> that should do something, anyway.
<mdz> bs=1M ought to be quicker
<lamont> yeah, but then $SZ would have to be in MB. :-)
* lamont fix0rs
<sladen> lamont: that's fine, you can  append   k/m/g  to bs= and count=
<lamont> sladen: but can I tell it to divide count by 1024?
<lamont> :)
<sladen> eg.  count=2k bs=1M
<lamont> doesn't matter - it's calcluated anyway...
* lamont burns a couple images
<mdz> lamont: it would be worthwhile to do a cmp --verbose over those two images, I think
<sladen> lamont: do you have the command the cloop for the CD is build with?
<sladen> command(s), script, fooage
<mdz> sladen: create_compressed_fs <input> <block size> > output.cloop
<mdz> we use 65536 at the moment for the block size
<jdub> mdz: have you tried dir_index and EAs-in-inode yet?
<mdz> jdub: no, rsyncability is a bigger problem
<mdz> jdub: because Ubuntu developers (cough) say they can't test live CDs due to bandwidth limitations
<lamont> haggai: /build/buildd/openoffice.org2-1.9.66/ooo-build/build/src680-m66/sal/rtl/source/macro.hxx:102:2: #error "unknown ARCH -- insert your ARCH identifier above"
<lamont> early and violent death for ooo2 on amd64
<sladen> mdz: no, the bit before that.  the mkisofs/genext2fs ---that's where the problem is
<jdub> mdz: 8)
<mdz> sladen: the mke2fs?
<jdub> mdz: understood and greatly appreciated :-)
<mdz> sladen: I think that uses all defaults
<mdz> lamont: any mke2fs args?
<lamont>  mke2fs -b $FSBLOCK $INUM -Osparse_super -F $IMGNAME
<lamont> INUM=""
<lamont> FSBLOCK=1024
<sladen> yeah, the $INUM was puzzling me, the man page says  mke2fs ... $device $inode_count  (in *that* order)
<mdz> lamont: that oo.o failure is expected, v2 isn't ported either
<lamont> INUM is either "" or "-N nnnn"
<mdz> i386 built, though!
<lamont> mdz: in 3:40! woot
<lamont> although he better not be special casing builds by the user 'buildd' again......
<mdz> that was rene
<mdz> it quits working pretty much the instant that init is re-execed
<mdz> which makes no sense whatsoever
<jdub> mdz: related to usb b0rk?
<mdz> jdub: yes
<mdz> frustrating as hell, I've spent most of the day on it
<sladen> lamont: so you mke2fs the image.  then loop mount it, then copy the files in, then umount it, then create_compressed_fs it?
<mdz> which is why I'm in such a dreadful mood
<lamont> sladen: yes
<jdub> mdz: let's do the warty dance!
<sladen> lamont: any chance of the script doing the copying?
<mdz> jdub: do you realize how far that footage has spread?
<lamont> sladen: I'm told no.
<jdub> bob2 showed me a debian bug on gstreamer about it
<lamont> or rather, "not at this time"
<jdub> how the hell did it get out, man?
<jdub> this is totally going to ruin my porn career
<lamont> lol
<mdz> lamont: any insight from that cmp --verbose ?
<lamont> I was stalling for the zero'ed images...... guess I'll fire up another window.
<sladen> lamont: does it do anything more than  cp -a ?
<lamont> sladen: it builds a chroot with debootstrap/apt, runs a few things, and then rsync -a's the chroot into the loopback mounted file
<mdz> I don't see how it could possibly matter
<mdz> but if it's using rsync, I think that means the file list is even sorted
<mdz> jdub: more people have seen it than have looked at that photo of the giggling 12-year-old spanish girls
<sivang> mdz: heh, it was actually not that good IMHO ;-)
<mdz> the dance? oh, it sucked
<ajmitch> jdub: some disturbing footage?
<mdz> ok, that does it
<mdz> I launchped a shell from /sbin/unconfigured.sh
<mdz> it doesn't get any earlier than that
<lamont> mdz: 124MB into the cmp --verbose, 1.4GB of output...
<mdz> and USB is fucked there
<sivang> mdz: launchped ? ;-)
<mdz> lauched
<mdz> launched
* lamont killed the cmp at 168MB compared, 2.3GB of output
<mdz> lamont: what does the output look like?
<jdub> ajmitch: three men who should know better swinging their hips.
<mdz> the amount doesn't tell us much, there would of course be a lot
<ajmitch> sigh, I wanted php5, but the debs at sources.dotdeb.org are crap
<sivang> mdz: hehe I read it  like launchpaded.
<mdz> I would have expected there to be swaths of identical bytes
<ajmitch> nearly no build-depends,..
<lamont> mdz: on the order of 10-30 bytes per hundred are different
<mdz> lamont: do you save the output from the daily d-i builds?
<mdz> lamont: somewhere in there I think there is a list of the versions of the udebs in the initrd
<mdz> lamont: I need to know if that changed
<lamont>      82101   0 371
<lamont>      82102   0  41
<lamont>      82105   0 372
<lamont>      82106   0  41
<lamont>      82109   0 373
<lamont> logs for the dailybuilds are under ~lamont/buildLogs
<lamont> in the usual place...they're binNMU's
<mdz> apart from the logs, there is a file
<mdz> like the manifest you generate for the cloop
<lamont> the above is a block that was used in one image, not the other
<mdz> I think it's in the tarball
<ajmitch> would php5 be welcome in universe once the debs were usable?
<lamont> tarballs tend to not get pruned, truthfully
<mdz> lamont: yeah, you know what's fucked up about the un-rsyncability of that ext2 filesystem?
<lamont> ajmitch: I don't see why it wouldn't be....
<mdz> it's like 25% empty
<lamont> or more
<ajmitch> lamont: it'd be a new package, so after hoary?
<sivang> strange, nautilus-cd-burner doesn't offer  me clear the CDRW...thus doesn't let me burn..hmm
<lamont> ajmitch: yeah
<mdz> surely there are a hell of a lot of contiguous blocks of zeroes
* lamont thinks that contiguous isn't quite what you mean..
<mdz> I do mean contiguous
<lamont> they're scattered all over the iamge
<mdz> if 1 in 4 blocks are empty, lots of them are going to be adjacent
<mdz> chunks of 2k, 4k, etc. all over the place
<lamont> and we're doing 65536, since it didn't make any difference to do the 4096
<mdz> which even if something funky is going on with file allocation, would rsync
<mdz> I'm talking about the uncompressed image
* lamont goes to process the images and count how many times there is a contig block of 1024 bytes of zeros at the same place in the two files... sound like a good test?
<mdz> it doesn't need to be in the same place, that's my point
<lamont> or do you want 1024 with the block on either side being zero in the other?
<mdz> if there is a block of Nk zeroes in one image
<mdz> and also a block of Nk zeroes in the other image
<mdz> rsync ought to find that
<lamont> how close to each other though?
<mdz> I didn't think it mattered
<mdz> rsync scans the whole file before it does anything
<lamont> in 2GB image, it's not going to cache it all forever....
<mdz> are you sure rsync isn't being too smart?
<mdz> noticing that you're doing a local copy, and saying fuckit on the delta algorithm?
<lamont> that wouldn't surprise me...
<lamont> ah, could be...
* lamont fetches across the network instead.
<mdz> ARGH
<mdz>        -W, --whole-file
<mdz>               With this option the incremental rsync algorithm is not used and
<mdz>               the whole file is sent  asis  instead.   The  transfer  may  be
<mdz>               faster  if  this  option  is used when the bandwidth between the
<mdz>               source and destination machines is higher than the bandwidth  to
<mdz>               disk  (especially  when  the  disk  is  actually  a  networked
<mdz>               filesystem).  This is the default when both the source and  des
<mdz>               tination are specified as local paths.
<sladen> I was going to suggest that
<mdz> ok, so I get to go back to sticking to my guns and saying that the uncompressed filesystem will rsync OK
<sladen> however, the I suspect the kernel ext2fs is still non-deterministic in its file placement;  ...and maybe the rsync search window isn't as big as I thought
<sladen> lamont: re: mdz.  Why /are/ you using rsync if this is an empty, fresh image each time
<sladen> lamont: and if it's /not/ a fresh image, it'll be full from crap from the last time
<mdz> rsync makes a nice local copy command as well
<lamont> yep
<mdz> rsyncing against the last build would be clever, though
<lamont> and the origin chroot is rm -rf'ed at the start of the script, and the target image szeroed
<mdz> then the unchanged files would be left in place
<sladen> good point.
<lamont> cloop size grows though that way mdz
<lamont> rather quickly, I might add
<mdz> lamont: rsync --delete
<lamont> (it didn't used to do that...)
<lamont> changed files still change blocks
<mdz> rsync --delete --inplace
<mdz> rsync --delete --inplace --no-whole-file !
<sladen> that's fine.  but the *unchanged* blocks within (even changed files) stay exactly where they were the last time
<mdz> sladen: that's what --inplace would do
<lamont> that has potential
<sladen> mmm.  yummy.
<mdz> though even if we completely lost on every changed file
<mdz> we would still win big
<mdz> because most of them don't
<smurfix> The way this is going, you need "rsync --every-option-ever" soon. ;-)
<lamont> smurfix: not quite, just most of them.,
<sladen> smurfix: rsync because useful after about:  rsync -CvzapP --stats
<lamont> mdz: then we just need a tool to rip through an ext2fs and zero any blocks that aren't being used.
<mdz> lamont: doesn't this mean that your 4096/4096 test was invalid as well?
<lamont> certainly
<mdz> lamont: actually, that already exists
<smurfix> lamont: cp /dev/zero FS/zero; sync; rm FS/zero
<mdz> partimage
<lamont> mdz: what package?
<mdz> lamont: partimage
<mdz> universe
<lamont> ah, that'd explain that
<sladen> you should also be able to make the image 25% bigger to avoid fragmentation and let cloop take care of the unused parts
<mdz> hmm
<mdz> unloading and reloading all of the usb modules fixes it
<mdz> sladen: he does that already
<mdz> because it's useful to have free space for runtime
<sladen> mdz: does diffing the before and after of:  /sbin/lsmod | grep -E '(hci|usb)' | awk '{print $1,$4}'   produce the same result?
<mdz> lamont: did --no-whole-file give us some nicer statistics?
<mdz> sladen: dunno
<lamont> mdz: each of these tests takes about an hour...
<mdz> lamont: you're shitting me
<lamont> although I suppose that if I just did it manually, I could get it down to 40 minutes of my time
<lamont> run the script twice, look at the results
<mdz> oh, you rebuilt the image
<lamont> == 30 minutes * 2
<lamont> it was already running...
<mdz> I am just interested in taking the last two images, already built, and rsync --no-whole-file'ing them
<mdz> which should take almost none of your time
<lamont> so the plan is rsync --delete --inplace --no-whole-file, using the previously built fsimg as the base, correct?
<mdz> well, not the last two
<mdz> because they're too close
<lamont> fsimage, or mounted tree?
<mdz> fsimage
<sladen> mounted
<sladen> never mind
<mdz> I'm taking a few steps back
<mdz> I'd like to know what our theoretical savings would be
<mdz> I'd also like to retry the 4096/4096 test
<mdz> both of those should be doable with existing images, the latter recompressing them
<lamont> wrote 324458 bytes  read 651330424 bytes  2290526.83 bytes/sec
<lamont> total size is 2147482624  speedup is 3.30
<lamont> *(^_^*(&+)}_*U rsync
<lamont> that's over the network
<lamont> yes, same to fsimages as before
<mdz> which two were those?
<mdz> 20050120 and .1 ?
<lamont> yes
<lamont> sigh..
<lamont> not entirely
<lamont> those are 20 and 20.1 amd64 images
<mdz> sladen: notably, reloading only ehci_hcd (the one with the device actually connected to it) doesn't change anything
* lamont re-checks really using the same two images
<mdz> sladen: only reloading usbcore fixes it
<mdz> I wonder if it's related to /proc/bus/usb somehow
<mdz> this is insane; I have no idea what changed
<sladen> mu.  load order, usbfs on procfs on ro, subtle timing delays.  
<sladen> Is the broken universal for everyone and/or just ppc, just i386
<sladen> just mdz?
<mdz> that's what I've been trying to determine
<mdz> and why I've been bitching about lack of testing ;-)
<mdz> it breaks for me on amd64, powerpc and i386
<mdz> so I highly suspect it's universal
<sivang> mdz: done burning, testing now.
<lamont> mdz: --no-whole-file on 0120 and 0120.1: wrote 635250483 bytes  read 324462 bytes  1905771.95 bytes/sec
<lamont> total size is 2147482624  speedup is 3.38
<mdz> interesting
<mdz> not bad, but not as good as one would expect
<lamont> of course, that's still about 500MB too much
* sivang now talking from the livecd
<mdz> sivang: does USB work?
<sivang> mdz: lemme test, btw, sound (EMUK10) doesn't :(
<mdz> one problem at a time
<sivang> mdz: btw, Xorg is superb, maximum resolution, hebrew selection in d-i ingored completly
* sivang plugs usb disk in
<sivang> erggh, nothing.
<sivang> not even appearing in hal-device-manager
<sivang> :-/
<sladen> sivang: okay, now  sudo modprobe -r uhci_hcd  && sudo modprobe uhci_hcd
<sivang> sladen: ok, load them modules up :)
<sladen> sivang: remove+reload
<sivang> sladen: eh right , -r
<sivang> sladen: blank password?
<sladen> I have no idea, I'd guess so.  Though I've a feeling sudo can get unhappy about blank passwords
<sivang> hmm, I need to search the wiki for what the root/sudo password is.
<lamont> mdz: btw, any feedback on https://www.ubuntulinux.org/wiki/BuildDaemons ??
<lamont> mdz: I assume that even if we have reason to use partimage, it'll stay in universe?
<lamont> or do we want to support it?
<sivang> mdz: any idea for what the sudo password is? I can't load the USB modules without it it seems.
<sivang> sladen: ah! guessed it, "ubuntu" :)
<sladen> went into the Apple Store in London last week hunting for Mac Mini's to test Ubuntu PPC on.  They didn't have any, but I did figure out all the Apple Express IP->audio units had  apple/apple  as their username/password combo
<sivang> back in the cd,
<sivang> (using it)
<sivang> sladen: modprobing hung up the terminal and the whole system so I had to power reset the machine
<sivang> sladen: however , this was when the usb disk was already in - I will try now when it's unplugged first.
<sladen> godo point, might be prudent to add a good sleep between unloading and reloading
<sivang> yes
<sladen> since I think modprobe returns before it's been finished
* sivang finds it funny that the livecd is *much more* responsive then his hoary upgraded system on disk
<mdz> lamont: when do uploads get noticed by the buildds?
<mdz> sladen, sivang: in my case, reloading the HCI module had no effect whatsoever
<mdz> only after unloading usbcore
<lamont> mdz: it's in there..
<lamont> ah, almost in there..
<sladen> mdz: modprobe -r  should do that
<mdz> sladen: modprobe -r ehci_hcd won't unload usbcore
<lamont> The build daemons are frequently idle, and just waiting for packages (and therefore sleeping for up to 5 minutes), so on a good day, they'll start building your package somewhere between 0 and 5 minutes after the source enters the archive.
<sladen> mdz: it should do if it's a dependancy and it's use-count is zero
<lamont> mdz: updated
<mdz> lamont:  so roughly, <=5 for the source to be accepted, <=5 for the buidds to notice, build time, <=5 for binaries to be uploaded and accepted, then the next :03 or :33 for them to appear
<mdz> ?
<mdz> sladen: usbcore gets loaded when /proc/bus/usb is mounted by mountvirtfs
<lamont> np
<lamont> no
<sivang> mdz: would you have a modprobe line to test with? I had already tested 2 times, same behavior: terminal spitts endless CRs,
<lamont> <5 for the source to be accepted, up to 3-32 minutes for the source to actually hit the archive, < 5 for the build to start, < 5 for the binaries to be built and uploaded, < 5 for them to be accepted, and then the next :03/33, they're in the archive.
<mdz> sivang: perhaps you have a USB keyboard
<sivang> system hung up other then that. (had to reset)
<lamont> or, in other words:
<sivang> mdz: I do, how do you know? ;-)
<lamont> < 5 for source accepted mail, then next :03 or :33 the build starts, and 30 minutes later you have binaries
<mdz> lamont: oh, so the source needs to be in the archive before it's built?
<lamont> yes.
<sivang> mdz: well, it should wotk with it also isn't it?
<lamont> no accepted auto-building
<mdz> why not?
<mdz> doesn't Debian build from accepted?
<lamont> because we run cron.daily every 30 minutes
<lamont> yeag
<lamont> but they only run cron.daily once a day
<mdz> what would it cost us to build from accepted?
<lamont> it's not instantaneous, you know...
<lamont> as it sits, elmo has turned off building the Contents files, because that pushes us (with 4 architectures)( over 30 minutes on heavy-churn runs.
<lamont> that and it's a pain... if you make elmo turn it on, I can certainly add the deb-src/deb-src line to the buildd's.
<mdz> you're saying that cron.daily takes longer if we build from accepted?
<sladen> sudo umount /proc/bus/usb && sudo modprobe -r uhci_hcd    works from here
<lamont> no. cron.hourly takes longer then, since it has to apt-ftparchive
<sivang> sladen: this time I didn't plug the stick at all, but mdz suggested my usb keyboard is cuasing the problems..
<lamont> and it has a 5 minute budget
<lamont> (since it runs every 5)
<lamont> and the thinking was that folks who couldn't wait 30 minutes should get a life, or something like that..... dunno. :-)
<mdz> sladen: here as well
<sivang> sladen: using usb kbd?
<mdz> sivang: your keyboard is USB.  When you unload the USB drivers, your keyboard will *stop working*
* OddAbe19 is away: I've got a lovely bunch of coconuts... diddily dee... and so forth
<sladen> '''hi users, the first thing you'll need to do to use the LiveCD, is plug a network connection in and bring up an SSH session to fix the USB drivers
<sivang> mdz:  woops right, I hate to be so overlookinig for so obvious details..
<mdz> sladen: devices which were activated during stage 1 continue to work fine
<mdz> but no new devices are noticed, and no removals are noticed
<sivang> mdz: ok, is there a way to do mount the stick without removing ehci_hcd ?
<sladen> is /proc/bus/usb remounted?
<mdz> sivang: you have confirmed that the bug exists for you also, thank you
<mdz> remounted?
<mdz> it gets unmounted during casper/d-i shutdown, and then mounted again when init starts up, yes
<sladen> to remove usbcore, I was having to umount /proc/bus/usb
<mdz> I've also tried leaving the d-i mount there
<mdz> correct, /proc/bus/usb holds a reference to usbcore
<sladen> I don't have an image to play with;  how big is the test LiveCD to suck down (smaller is better)
<mdz> about 550M
<mdz> -rw-rw-r--  1 mdz mdz 525M 2005-01-20 00:02 hoary-live-i386.iso
<mdz> 525
<sladen> feh
<sivang> mdz: glad to be of service, lemme know if you need further testing with that as I am learning how to customize the livecd ;-) , I am also on 1.5Mbit conneciton so downloading the cd is not biggy.
<mdz> I just don't understand how usbcore can get into this state
<sladen> mdz: can you drop to a shell during d-i and see what state it is at that point?
<mdz> or what is triggering it
<HostingGeek> does someone want to explain to me why you need windows/dos to flash bios?
<mdz> not here
<mdz> but sure, another time
<HostingGeek> mdz: well if it can be asked in the devel's mail list it can be asked here
<HostingGeek> i prefer if someone reply to it rather than explain it here....
<mdz> don't ask it on the development mailing list either
<sladen> HostingGeek: there are tonnes of flash chips out there.  the /dev/bios drivers and MTD drivers eat some of them.  But not most
<HostingGeek> sladen: i am a idiot i have no idea what that ment
<HostingGeek> are not bios a chip on the m/b with a rom loaded on to it
<HostingGeek> if so why can not mb makers offer just the rom and the end user can use his/her fav. tool to flash
<smurfix> sladen / HostingGeek: I think mdz said "not here" ... and I agree actually
<HostingGeek> sry i didn't see that comment
<HostingGeek> mdz: no its a reply to something about using freedos to flash bios
<sladen> HostingGeek: additionally, the 'images' frequently don't come as images, but compressed files that can be patched and uncompressed for a particular machine before being hurt---the provided floppy disks have all that in one glob.  dosemu isn't really an opinion because of port and timing-critical sections that can't be achived under emulation or userspace.  Hope that answered your question.  If it didn't, pester me privately  (/query sladen).  But pref
<mdz> I can't find any other way to trigger this behaviour, other than actually using the live CD
<mdz> mounting /proc/bus/usb elsewhere, unmounting it, mounting it multiple times, nothing breaks it
<lamont> mdz: what's the default finish action in partimage, I wonder...
<mdz> finish action?
<lamont> nm
<thully> hi
<mdz> unmounting /proc/bus/usb before doing the pivot doesn't make any difference, either
<lamont> mdz: any reason I shouldn't link the BuildDaemons package in?
<lamont> (i.e., publish it.)
<sladen> lamont: I'm sure it would be very useful when a structure for derivities is available;  I can see if leading to temptation and confusion right at this point
* lamont adds a note that this is the current infrastructure, being replaced when we have the derivatives infra in place.
<fabbione> morning
<mdz> fabbione: morning
<mdz> fabbione: I have been fighting with this strange kernel problem all day
<lamont> morning fabbione 
<mdz> #5701
<sladen> fabbione: how much effort was the sparc port?   (...alpha appears to be lacking at the moment :-)
<fabbione> guys ... stop
<fabbione> i just woke up
<fabbione> and reading emails :-)
<lamont> heh
<fabbione> mdz: 5701 worksforme on normal boxes
<fabbione> what kernel are you using right now?
<fabbione> because i remember fixing something USB related recently
<mdz> fabbione: can you try the live CD?
<mdz> fabbione: it worksforme on normal installs too
<mdz> and it _used_ to work on live CDs
<mdz> but something has changed and I have no idea what it is
<mdz> the live CD I'm using has 2.6.10-10
<fabbione> mdz: yes. i will try in a bit ok?
<mdz> fabbione: wonderful, thank you
<fabbione> i need to see if my mirror is synced
<fabbione> mdz: no problem
<fabbione> mdz: when did you build the last one?
<mdz> the most recent one is a daily build
<mdz> 20050120.1
<fabbione> mdz: is it the same you are using for testing?
<mdz> correct
<fabbione> ok it is synced
<lamont> fabbione: all the 20050121* images are me testing stuff
<jdub> jdz_: dude :)
<jdz_> jdub: hey man :)
<fabbione> lamont: i use the "current" symlink to update
<fabbione> i don't mirror everything even if i could :-)
<mdz> jdz sounds like a fusion of jdub and mdz
* lamont mumbles something very similar to "never mind"
<mdz> a frightening concept
<fabbione> ehhehe
<fabbione> mdz: it's burning...
<fabbione> and i need to wake up my gf
<jdz_> *laughs*
<sladen> jdz_: were you thinking some KY-Jelly would solve this problem too?
<zenrox> hahahha
<jdz_> oh man ;P
<fabbione> mdz: booting now...
<fabbione> mdz: everything is working fine here
<mdz> fabbione: you can plug and unplug USB devices?
<fabbione> mdz: sure.. but that won't make it working properly
<fabbione> you know that, don't you?
<mdz> what?
<fabbione> the usb devices, when unplugged and replugged. might get a different /dev/input/<name>
<fabbione> it depends on how fast you do the operation
<mdz> have you read the bug?
<fabbione> and X will not reopen the FD
<mdz> when I plug in a USB device, it does not even log in dmesg
<mdz> nothing happens
<fabbione> ok just a sec...
<mdz> I think I have found the next level of cause
<mdz> khubd dies
<mdz> once khubd is dead, no more USB device events are noticed
<mdz> yes, that is it
<mdz> reloading usbcore restarts khubd
<mdz> OH
<mdz> khubd can be killed by SIGKILL
<mdz> which init sends it, of course
<mdz> but this never happened before
<fabbione> hmm
<fabbione> i unplug my mouse and replug it i get a lot of crap in dmesg
<magnon> mdz: are we on "why doesn't my usb stuff show up in nautilus"?
<fabbione> driver/*/usb-core: input irq status -84 received
<magnon> my card reader just shows up the first time it's mounted
<mdz> magnon: no, this is "why is USB broken on the live CD"
<magnon> ah.
<magnon> I should file a bug on this, if it isn't filed alraedy
<mdz> fabbione: I am fairly sure I have isolated it
<magnon> and I need sleep, to fix my typing
<mdz> fabbione: sudo killall -9 khubd
<fabbione> mdz: worth a try to boot with that irqpoll ?
<mdz> fabbione: and you will see exactly what I am talking about
<fabbione> there is no khubd runnig on that machine
<fabbione> i already checked
<mdz> what
<sivang> magnon: card reader? as in smart card?
<magnon> CF
<mdz> fabbione: this is with the same live CD I am using?
<fabbione> mdz: it's the last one from archive in current/
<fabbione> if you need another version you need to tell me
<mdz> khubd should be started as soon as a hub is detected
<fabbione> but yes i can reproduce the problem on livecd
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/daily-live/current $ md5sum hoary-live-i386.iso
<mdz> 1d1afb2a99db7501486b6b8d7840ca0a  hoary-live-i386.iso
<mdz> oh, you can?
<fabbione> ok
<mdz> you just told me you got messages in dmesg when you connected USB devices
<fabbione> boot -> X everyuthing works
<mdz> which would mean that you cannot reproduce the problem
<fabbione> i remove the mouse and replug it -> the message you wsaw above
<fabbione> 1d1afb2a99db7501486b6b8d7840ca0a  hoary-live-i386.iso
<fabbione> looks about the same
<mdz> no idea about that message; that is not the same as my bug
<mdz> but I am 99% sure I have nailed it
<mdz> on the live CD, when init re-execs, it kills all other processes
<fabbione> mdz: ok.. let me know...
<mdz> first SIGTERM, then SIGKILL
<mdz> it sends a SIGKILL to khubd
<mdz> which kills it
<mdz> which is what causes the problem
<fabbione> but why do you send that message around?
<mdz> what message?
<fabbione> SIGTERM, then SIGKILL
<mdz> it is init, that is what it does
<mdz> kernel threads are not supposed to die from signals
<fabbione> mdz: that's true.. but that didn't change 
<mdz> but khubd does this:
<mdz>         daemonize("khubd");
<mdz>         allow_signal(SIGKILL);
<mdz>         /* Send me a signal to get me die (for debugging) */
<mdz> if it is only for debugging, I say turn it off :-P
<fabbione> i am pretty sure i didn't patch anything there of that kind :-)
<mdz> yes, I don't understand why this didn't happen before
<fabbione> let me check the patchsets
<fabbione> what file is that?
<mdz> drivers/usb/core/hub.c
<mdz> I checked; you don't patch it
<fabbione> yup.. i am checking if there is a fix upstream
<fabbione> the code is clearly broken
<mdz> I think I know why I didn't see this before
<fabbione> the code is BAD!
<mdz> maybe the mouse driver was loaded by d-i
<fabbione> it sends signals to itself to exit and die
<mdz> hmm, no, doesn't look like the mouse drivers were ever there
<mdz> aha
<mdz> it's in input-modules
<mdz> I bet input-modules was on the CD before, and is now gone, and that's the problem
<mdz> well, the trigger
<mdz> hotplugging still would not have worked
<mdz> but my mouse worked before, and this is why
<mdz> confirmed: I am not insane
<mdz> (yet)
<fabbione> well there are no changes in the code for a long while
<fabbione> mdz: so who is at fault and what do you want me to do?
<fabbione> HMMM
<fabbione> this code is still strange tho
<mdz> yes, it makes sense that there have not been changes
<mdz> what changed was which modules were shipped on the CD
<fabbione> ok
<mdz> in my opinion, it is pointless for a kernel thread to die like that
<mdz> I see two ways to fix it:
<mdz> 1) patch the kernel so that the thread doesn't die
<fabbione> it is needed on cleanup
<mdz> 2) try to unload all USB modules before pivoting on the live CD
<fabbione> i am reading more code...
<mdz> SIGKILL is the wrong way to clean up a kernel thread
<mdz> in my uninformed opinion
<mdz> but many other threads do it
<fabbione> mdz: i am checking waht is in bk
<mdz> so I guess this will be a bigger problem than just usb
<fabbione> and they started using it even more
<mdz> md_thread does it
<fabbione> the point is that you load khubd when you need it
<fabbione> and you need to remove when you don't
<mdz> many filesystems do
<fabbione> they accept to die?
<mdz> trying to unload all the modules is not really feasible
<fabbione> mdz: stop sending them signals :-)
<mdz> so I guess I will need to patch init
<fabbione> mdz: another option would be for me to provide you a boot option to diable allow_signal
<mdz> how can I tell a kernel thread from a user process?
<mdz> hmm actually
<mdz> I can't fix this in init
<mdz> I am pretty sure init does kill(-1, SIGKILL)
<mdz> so it is a kernel problem again! ;-)
<fabbione> mdz: nope...
<fabbione> but i can help you with that
<daniels> argh, the ltmodem source package is shit
<mdz> how do you mean?
<fabbione> the point is that either you or me needs to patch something to be used only on livecd
<fabbione> so either i give you a boot option
<mdz> well, let's think about this
<fabbione> or you patch init to recognize that it is a live cd and NOT send SIG_KILL
<mdz> won't this be a problem when rebooting?
<fabbione> mdz: fromt he livecd?
<mdz> fabbione: from anywhere
<mdz> let's say your filesystem uses a thread which can be killed by SIGKILL
<mdz> init SIGKILLs it
<fabbione> no.. because we can enable the boot option only on livecd
<mdz> and then runs the shutdown scripts
<mdz> aaaah
<mdz> ./doc/Changelog:  * killall5 now skips kernel threads
<fabbione> tsk :)
* fabbione hits init and mdz with a refrigerator
<mdz> well, this means that sysvinit has found a way around this problem
<mdz> and we just need to do the same in busybox
<mdz> man
<mdz> this has been one of those "one bug" days
<mdz> one bug the whole damn day
<lamont> mdz: and a trivial fix at the end of it.
<lamont> which fits the rule
<mdz> not as trivial as I'd like
<lamont> (time to fix is inversely proportional to the time to find)
<mdz> not trivial at all, unfortunately
<fabbione> ehheh
<mdz> busybox uses the simplest possible method
<mdz> kill(-1, <sig>)
<mdz> sysvinit walks /proc
<lamont> ouch
* lamont looks at the clock, decides that _tomorrow_ he will go into town, not _tonight_
<daniels> an autoconf'ed source distribution that seemingly can't be made to use srcdir!=builddir
<daniels> whoohoo!!!
<magnon> the beauty of autotools
<jamesh> using automake 1.4 by any chance?
<lamont> daniels: I'm sure keybuk can hit it over the head hard enough...
<daniels> lamont: it uses a bastard mix of automake and kbuild
<daniels> i've given up on srcdir != builddir for this crap
<lamont> hrmpf.
<lamont> it's 0645 at the data center...
<fabbione> lamont: welcome to the concept of TZ's ;)
<fabbione> lamont: is there anything you want me to do so you can go and crash?
<lamont> fabbione: nah-  what I really need to do is add some mutual exclusion to the livecd build script...
<lamont> IOW... oops.
<lamont> | #define HAVE_STDINT_H 1
<lamont> | #define  1
<lamont> | #ifdef __cplusplus
<lamont> hehe
<lamont> no mvo yet, eh?
* lamont debates filing an aptitude bug
<fabbione> daniels: do you have any machine where you can dri and test the new kernel modules?
<daniels> fabbione: two
<daniels> fabbione: (i855, which uses the i915 module, and radeon)
<fabbione> ok.. what flavours do you need?
<daniels> 686, k7
<daniels> i need to start getting ready very soon though
<fabbione> uplaoding them now
<fabbione> no problem
<fabbione> i am not going to release today
<daniels> cool, ta
<daniels> ahr sweet
<daniels> in that case I might check them when I get back
<daniels> lest I die for not being ready on time
<fabbione> daniels: i am uploading them to people
<fabbione> in my home
<fabbione> they should be up in 30 minutes or so
* lamont declares bedtime
<fabbione> g'night lamont
<lamont> night
<fabbione> daniels: i need you to upgrade the kernels without rebooting the machine
<fabbione> daniels: unload the old module and load the new one
<fabbione> to see if the ABI is broken or not
<fabbione> from my tests is not, but i can't really use dri here
<fabbione> so my loads are fake
<daniels> fabbione: sure
<fabbione> cool
<daniels> i915 should be ok
<daniels> it's just adding more functions
<daniels> and it bumped the version number
<fabbione> daniels: just check both of them
<fabbione> i did review the code again
<daniels> yah
<daniels> sweet
<daniels> alright, I'm off now
<fabbione> and there is a new module that collect all the common code
<fabbione> drm.ko
<fabbione> and all the others have been changed to use it
<fabbione> ok.. later dude
<d3vic3> doko, ping 
<doko> d3vic3: morning d3vic3, just sent you an email
<d3vic3> oh ok 
<d3vic3> morning 
<ogra> morning
<ajmitch> morning ogra 
<Treenaks> hey ogra
<Treenaks> why is everyone so ignorant about the package system/apt etc?
<Treenaks> on the ml
<ajmitch> the -devel list?
<Treenaks> no, users
<ajmitch> that's no surprise then
<Treenaks> but you can't vent steam in front of the people you're venting steam about :)
<ajmitch> :)
<ajmitch> I think people would like a nice easy way to install debs they've got themselves
<Treenaks> still, there should be a huge brigt yellow-on-purple screen with "USE PACKAGES", about 10 times during installation
<Treenaks> bright
<ogra> i just started to create a MOTU page skeleton on the wiki....any idea what other subtopcs should be there ? https://www.ubuntulinux.org/wiki/MOTU
* ajmitch looks
<amu> moins 
<ogra> moin
<ajmitch> hi amu 
<ajmitch> hmm, a little empty
* ogra wonders if it makes sense to have a interim solution for bugs until malone is ready
<ajmitch> ogra: want to upload a fix for a universe package for me?
<ogra> ajmitch: skeletons mostly have less flesh ;)
<ajmitch> this is more like a couple of knuckles than a skeleton ;)
<ogra> ajmitch: if it was approved by haggai make him send me a "ok" and i'll do :)
<amu> ajmitch: *waves*
<ajmitch> ogra: ok, I'll talk to him
<ogra> Treenaks: do you have uploader status already ? (or will we have to wait till next TB)
<Kamion> morning
<ogra> morning
<fabbione> yo
<Treenaks> hi Kamion 
<pitti> Hi guys!
* pitti opens a bottle of champagne
<pitti> I just was in my uni, got my diploma certificate :-)
<Treenaks> pitti: congratulations!
<mvo_> pitti: congrats!
* mvo_ cheers
<pitti> thanks
<pitti> amu: ping
<amu> pitti: moins 
<pitti> amu: I have some CAN numbers for konversation
<pitti> amu: I'll mail you, amu@ubuntu.com?
<amu> pitti: congrats first, look to you incoming filedir, i fixed warty ar morning ;) 
<amu> s/ar/at
<pitti> amu: argh, I thought you wanted to wait until the CANs are there?
<amu> pitti: mdz was faster ;) 
<pitti> okay :-)
<amu> pitti: mdz sended the CAN numbers at morning ..  
<pitti> amu: it built fine, I'm releasing it now. Thanks for preparing!
<ogra> pitti: yeah, prost und glueckwunsch !
<amu> pitti: np
<pitti> ogra: Danke :-)
<Treenaks> "Willkommen in #Deutschland" ?
<pitti> Treenaks: mea culpa :-)
<Treenaks> pitti: it's just that there's a lot of Germans in here :)
<amu> ogra: thx for your translations, you're fast like light 
<ogra> heh :)
<ogra> amu: somenative speaker should review it, my grammar is mostly crap ;)
<toresbe> schni schna schnappi, schnappi schnappi schnapp :D
<toresbe> oops
* toresbe quickly runs to the correct window
<ogra> i added some flesh and bood to the MOTU page....feel free to extend or correct it
<ogra> blood even
<Kamion> hm, I think I might have nailed thully's timezone bug at last
<ajmitch> ogra: looks better
* ogra thinks there should be a little He-Man image in the page header....
<Treenaks> ogra:  ...
<ogra> huh ?
<Astharot> good morning
<ogra> Treenaks: do they still sell it ?
<Treenaks> ogra: http://imdb.com/title/tt0403102/?fr=c2l0ZT1kZnxteD0yMHxzZz0xfGxtPTIwMHx0dD1vbnxwbj0wfHE9aGUgbWFufGh0bWw9MXxubT1vbg__;fc=21;ft=22;fm=1
<Treenaks> uh
<Treenaks> ogra: sorry, http://imdb.com/title/tt0427340/
<ogra> Treenaks: hmm, the plot outline from there would make a good introduction :)
<ogra> " He-Man, the most powerful man in the universe, goes against the evil"
<Treenaks> ogra: you're NOT he-man
<ogra> hehe
<ogra> Treenaks: nope, haggai is ;)
<Treenaks> ogra: nah.. wrong accent ;)
<ogra> lol
* ogra wonders what he should write for sladen there.....
<ogra> sladen could you add something there that describes your universe work: https://www.ubuntulinux.org/wiki/MOTU
<Riddell> ogra: has sladen done universe work?
<fabbione> RIFE THE SPLIT
<fabbione> RIDE even
<ogra> Riddell: nope, but he has uploader status
<Treenaks> fabbione: well.. "rife" is OK too, here on freenode ;)
<ogra> heh
<ajmitch> Treenaks: now, I hadn't seen a split for hours :)
<Treenaks> ajmitch: then you've been lucky ;)
<fabbione> ehehe
<pitti> Hi seb128 !
<Treenaks> seb? where? :P
<fabbione> hey Keybuk 
<mvo_> hi seb128, hi Keybuk 
<Treenaks> grr... my client doesn't show joins..
<fabbione> hey seb128 
<Treenaks> this tends to help
<fabbione> hi mvo_ 
<mvo_> hey fabbione 
<seb128> hey pitti & mvo_ & fabbione 
<Treenaks> hey seb256
<pitti> seb128: please ping me if you want to debug this icon issue
<seb128> pitti: right, I've just pinged the panel guy, waiting for a pong :)
<seb128> pitti: there is a patch in http://bugzilla.gnome.org/show_bug.cgi?id=108864, to apply to gnome-panel in gnome-panel/applets/notification-area/
<seb128> pitti: if you could try that
<pitti> seb128: bah, that means that I need to recompile gnome-panel?
<seb128> pitti: yeah
<seb128> pitti: I can make a patched package if you want
<pitti> seb128: I don't mind recompiling it, it just will take a while :-)
<pitti> seb128: this patch looks fairly intrusive...
<seb128> why ?
<seb128> looks ok imho
<pitti> seb128: I downloaded the 18 MB of build-deps now :-)
<seb128> ah ah
<pitti> seb128: I compile it and report back
<seb128> nice, thanks
<pitti> seb128: bah, FTBFS with the patch
<pitti> seb128: hmm, this is nontrivial
<pitti> seb128: the patch uses some variables (tray, xev, icon) which are not declared anywhere
<pitti> Hi carlos!
<carlos> hi
<seb128> pitti: 
<seb128> vuntz: a priori, s/xev/xevent
<seb128> vuntz: s/tray->sockets/manager->socket_table
<seb128> icon -> socket
<seb128> pitti: don't bother too much if that doesn't build
<pitti> seb128: hey, it compiles now :-)
<seb128> cool
<pitti> thanks
<seb128> np
<elmo> haggai: ?
<pitti> seb128: that's so mean! I tried the usuall killall axe to restart nautilus, panel & co, and now it works fine (still with the old version!)
<pitti> elmo: is it okay if I upload the l-p flood?
<elmo> pitti: no, sorry, I lost all of yesterday and didn't get a chance to implement the jennifer change.. give me 10minsw and I'll do it now
<pitti> elmo: no problem
<elmo> pitti: also, please get me a listing of what will be being uploaded so I can pre-add them to bypass NEW
<elmo> preferably a list of binary packages 
<pitti> elmo: no problem, I mail it to you
<seb128> pitti: :(
<pitti> elmo: I currently have a list of solely the binary package names (no version, no ".changes" suffix, etc.)
<pitti> elmo: is that okay? or do you need the filenames of the debs?
<seb128> pitti: perhaps that happens only in the login (depending on the order to load gaim/panel/...)
<rburton> is the usplash source available in cvs/arch anywhere?
<pitti> seb128: I tried to logout and back in as well
<pitti> seb128: anyway, I try some further, and then I try the new pacakge
<pitti> seb128: if the new pkg works as well, it's probably okay to upload :-)
<seb128> ok :)
<seb128> pitti: BTW why have you killer the panel with the old version still here ?
<pitti> seb128: just testing...
<elmo> pitti: that's great
<pitti> seb128: probably the killall triggered a rewrite of some configuration file.
<seb128> :(
<pitti> elmo: sent
<pitti> brb, new gnome-panel test...
<pitti> seb128: I KILL this damn panel some day!!!
<pitti> kill -9 --extra-bloody --try-harder gnome-panel
<seb128> ah ah
<pitti> s/kill/killall/
<smurfix> pitti: doesn't matter, it gets restarted automatically
<smurfix> ;-)
<seb128> pitti: if you want to kill it just "gnome-session-remove gnome-panel"
<pitti> find -name "*panel*" -exec rm -rf '{}' \;
<pitti> that should do
<seb128> :)
<pitti> seb128: thanks for that hint
<seb128> np
<pitti> seb128: 
<ogra> ....the return of the undead panel....
<pitti> $ gnome-session remove gnome-panel
<pitti> gnome-session: you're already running a session manager
<seb128> gnome-session-remove
<seb128> that's a command
<pitti> argh, thanks
<seb128> :)
<smurfix> ... without a manpage, as usual :-/
<seb128> patches are welcome :)
<pitti> seb128: the gaim icon is still there, well and up
<pitti> seb128: that bloody thing was broken for a week now!
<smurfix> seb128: can I patch the upstream authors to please include manpages?
<pitti> anyway, I test the new package now
<seb128> bah, that's always like that, when you want to get a but that works
* thom pokes seb128. i do all that work for you, and you can't be bothered to upload a new epiphany :P
<seb128> smurfix: upstreams don't care to add a manpage for that but if you send one ..
<seb128> thom: dude, fixing a gtk bug atm :p
<seb128> thom: have you get the webdav access btw ?
<smurfix> seb128: I know. I want to patch the upstream people so that the *do* care. ;-)
* pitti votes for teaching people to use bash and text consoles
<seb128> smurfix: that's not an easy patch :p
<seb128> yeah, be good guys
<seb128> STOP USING GTK :)
<ogra> huh ? QtGnome ?
<seb128> no, just the command line
<ogra> heh
<pitti> ogra: gnome-curses :-)
<ogra> *g*
<ogra> pitti: the ones you suffer from ?  ;)
<pitti> seb128: the new panel works just as well
<thom> seb128: have emailed, not heard back
<pitti> seb128: shall I upload it and see what happens? :-)
<thom> elmo: please can you sync apache from unstable
<pitti> elmo: and if you are at it: mysql-dfsg and mysql-dfsg-4.1 syncs as well please :-)
<Kamion> pitti: the partman changes were upstream, not something I did; it'd be a lot of effort to change the UI back and I'm not sure it's worth it
<fabbione> elmo: can you please sync libapache-mod-radius-auth and libpam-auth-radius (it's universe stuff, but since we are it ;))
<pitti> Kamion: I think it is confusing to be forced to specify the fs type if I just want to use a partition
<seb128> pitti: feel free :) Could you update the patch upstream ?
<seb128> thom: ok
<pitti> Kamion: furthermore, if I accidentially pick the wrong fs type, I can not choose to not format it...
<Kamion> pitti: I didn't know you needed to; that sounds like a bug, it should autodetect the currently-used fs type
<ogra> hmm, www.ubuntulinux.org is unreachable again ... ??
<seb128> elmo: please remove "gstreamer gst-plugins gst-player kgst" from hoary
<pitti> Kamion: the fs type is shown in the partition list
<pitti> Kamion: but if I select it, I cannot just select "use this partition" any more
<Kamion> yes, but the one that's currently on the partition should be the default
<smurfix> ogra: works here
<Kamion> that sounds like a plain bug, please report it
<pitti> Kamion: okay, I try that out again and report it
<ogra> smurfix: hmm, i get timeouts tracrouting from several different places.....
<smurfix> ogra: traceroute is typically blocked by firewalls
<ogra> 62.140.218.35 is always my last hop
<elmo> seb128: not built from source?
<elmo> aiee, my airo-cs dies and I get flooded with requests
<smurfix> ogra: doesn't matter. telnet to port 80 instead.
<ogra> probably the routing is broken anywhere at Level3.net ....(all routes i use take that path)
<seb128> elmo: old gstreamer0.6 stuff, should be erased from the archive now :)
<smurfix> ogra: traceroute -I works too (that uses ICMP packets instead of UDP)
<ogra> smurfix: hmm, interesting...GTE / works....
<ogra> GET even
<haggai> elmo: yup
<ogra> haggai: http://www.ubuntulinux.org/wiki/MOTU
<thom> seb128: launch-box FTBFS :(
<haggai> ogra: great stuff, thanks!
<elmo> fabbione: are those the names of source packages?
<thom> it's mod-auth-radius
<ogra> haggai: it needs some more flesh and blood but is a start to point ppl to
<seb128> thom: lemme see
<fabbione> elmo: if i didn't mispell them, yes
<elmo> haggai: what's the deal with the oo.2 crack?
<fabbione> thom: no..
<fabbione> thom: i didn't name them as upstream... i got them like that
<elmo> haggai: a package called 'openoffice.org2-l10n-' ?  and what's with all the new ones?
<thom> fabbione: ahem?
<thom> 20:10 < willy> There is no record of the libapache-mod-radius-auth source package, and no bugs have been filed against it.
<thom> 20:11 < fabbione> libapache-mod-auth-radius
<fabbione> <thom> it's mod-auth-radius
<haggai> elmo: bah, the l10n- should be en-us
<fabbione> thom: ok ok.. you removed the libapache-
<fabbione> and i am off
<fabbione> i really need to start the weekend now
<thom> you really ought to know the names of your own packages :P
<fabbione> thom: <fabbione> elmo: if i didn't mispell them, yes
<pitti> seb128: uploaded
<haggai> thom: I know what *I* think they should be ;)
<fabbione> thom: shushhhhh
<fabbione> :P
<fabbione> ah haggai
<thom> that's not mispelling! that's out and out misremembering :-)
<fabbione> haggai: ooo1?
<thom> haggai: *g*
<seb128> pitti: thanks
<haggai> thom: that's a script going wrong :-/
<elmo> so anyway, once you guys figure out who is who's bitch, pls let me know the names of the source packages to sync.  kthxbye
<haggai> kthxbyelmo
<thom> elmo: apache is the only thing that matters ;-)
<fabbione> libapache-mod-auth-radius_1.5.7-6 and libpam-radius-auth_1.3.16-3
<Treenaks> g
* fabbione is really tempted to figlet elmo
<haggai> fabbione: well ooo2 mysteriously started working again so I guess all I have to do is reupload
<fabbione> haggai: hold on
<fabbione> no need to reupload to get a build
<haggai> fabbione: oh?  what's the magic?
<fabbione> haggai: ping lamont
<haggai> ah,k
<haggai> lamont: ping :)
<elmo> fabbione: done
<fabbione> thanks elmo
<seb128> morning jbailey 
<jbailey> Morning sb!
<pitti> seb128: sent patch to the gnome bts
<seb128> pitti: thanks
<ogra> seb128: is it intended that the volume-control applet is hidden if the master mixer is muted on login ?
<seb128> ogra
<seb128> oups
<seb128> ogra: no
<ogra> so its a bug....
<seb128> correct
<seb128> at least I think so, I'm not the upstream
<ogra> .... i will wait if your current upload still behaves like this and fle one then ;)
<ogra> file even
<ogra> seb128: it could also be a feature since it avoids the "no mixer found" errormessage it seems...
<seb128> I'll ask to upstream
<seb128> ogra: I'm opening a bug upstream
<Treenaks> pitti: you were working on language packs right?
<pitti> Treenaks: right
<pitti> Treenaks: I await elmo's GO for actually uploading them
<pitti> Treenaks: this still needs some preparations
<pitti> Treenaks: already tried the unofficial ones?
<Treenaks> pitti: well, I just got a mail from someone who made a list of packages to make a system more Dutch
<Kamion> hm, just hypothetically, what would it take for me to become gdk/linux-fb maintainer?
<pitti> Treenaks: cool, just send it to me
<pitti> Treenaks: I can add them to language-support-nl
<ogra> seb128: ok, thanks
<ogra> trukulo: http://people.ubuntu.com/~lamont/buildLogs/g/graveman/0.3.0-2ubuntu1/graveman_0.3.0-2ubuntu1_20050121-1237-i386-successful
<ogra> :)
<thom> hrm, firefox and ephy really dn't like o2's build lg
<Treenaks> pitti: how's your Dutch? :)
<pitti> Treenaks: not there :-)
<trukulo> ogra: tell me
<trukulo> COOL !
<ogra> :)
<Treenaks> pitti: hmm.. http://www.lacocina.nl/artikelen/ubuntu-nederlands.html is his page.. he links to a few debs that aren't in ubuntu yet
<decko> ogra, Are you building graveman???
<trukulo> sp graveman is in universe for hoary?
<pitti> Treenaks: oh, I can only depend on packages in main
<trukulo> or warty?
<pitti> Treenaks: I think I should be able to figure out what's written there
<ogra> decko: i just upload it...trukulo made the package ;)
<Treenaks> pitti: things like a Dutch openoffice dictionary file can't be in main?
<elmo> pitti: can you do me a favour and upload two things: 1) a binary upload (of anything) signed by the language pack key, 2) a source upload of anything other than a language pack signed by the lang pack key
<ogra> trukulo: hoary
<trukulo> ogra: ok
<ogra> trukulo: wartys universe wont change anymore
<decko> ogra, Because I know a DD that made the package for the lastest version (0.3.1).
<trukulo> that's what i tought, ok
<pitti> Treenaks: openoffice.org-l10n-nl is in main
<trukulo> decko: brazilian one?
<decko> trukulo, Yes! otavio
<trukulo> yes, sylvain told me
<decko> trukulo, otavio is his name
<pitti> elmo: hmm, real packages (which go into the archive), or just some mockup which you will trash?
<Treenaks> pitti: oh wait.. it described manual installation of "myspell-nl" if the package isn't available
<trukulo> no problem for me, if he knows to make better packages than me, then it's better
<trukulo> i don't mind, i only want graveman avalaible
<elmo> pitti: mockup
<elmo> pitti: they'll be rejected, and if they aren't, I'll purge them by hand
<decko> trukulo, I think that he upload graveman yesterday do sid
<trukulo> decko: how do you know it?
<decko> trukulo, he told me
<trukulo> umm, i made an ITP in debian
<Treenaks> pitti: and he made his own mozilla-firefox-locale-nl package, because it's not in debian or ubuntu
<pitti> elmo: I upload a pmount version lower than hoary's current one, this should be rejected
<trukulo> for graveman, 3 days ago
<decko> trukulo, Wait a moment
<elmo> pitti: nono
<elmo> pitti: please upload something that would otherwise be accepted
<pitti> okay
<elmo> just trust me when I say it's not going to get into the archive proper
<trukulo> decko: ok
<pitti> elmo: ah, now I understand :-)
<pitti> elmo: pmount 0.5.1-1invalid1_source uploaded (signed by langpack key)
<trukulo> decko: could you tell ottavio my jabberid?
<decko> trukulo, What's you jabber ID???
<decko> trukulo, What's is your name??? Miguel???
<trukulo> yes
<trukulo> don't mind, i'm in query with him
<decko> trukulo, Ohhh No problem
<decko> trukulo, ha has send a email to you!!!
<elmo> pitti: okay, that's 2), (1) too pls
<pitti> I'm at it
<pitti> I want to use another package
<pitti> elmo pkgstriptranslations_4invalid1_i386.changes uploaded (signed by langpack key)
<trukulo> decko: he's telling me, don't worry
<decko> trukulo, :)
<elmo> pitti: excellent, thanks
<ogra> trukulo: amd64 and ia64 were successfull too ;)
<trukulo> ogra: superb
<ogra> yup :)
<ogra> we got a gtk2 burning app, yay
<elmo> pitti: I'm just creating the 'translations' section in the archive, will pre-add all the packages, then test-run lang-pack-en, and then FINALLY we'll be ready
<pitti> cool!
<elmo> pitti: okay, please upload the pack and pack-updates for -en, so we can test all 3 types auto-build correctly
<pitti> elmo: done
<elmo> ok, all 3 in accepted.. let's see how they auto-build, assuming they do, and you're happy, you're clear to upload the rest
<pitti> nice, thanks!
<pitti> I will follow the build progresss
<lamont> haggai: which arch do you want ooo2 requeued on?
<elmo> haggai: seriously, what's the point of splitting the oo.o components out by function when they all depend on a 45Mb .deb (140Mb installed) -core package?
<haggai> lamont: just ooo1 thanks
<haggai> elmo: modem users are very happy if they don't have to download eg 6mb of spreadsheet
<lamont> haggai: and on which architecture?
<haggai> elmo: and it follows upstreams' packaging
<lamont> mvo_: you around?
<haggai> lamont: i386 thanks
<haggai> elmo: I did already remove 2 tiny packages which upstream had and merged them into core
<elmo> haggai: dude, modem users are faced with the 45Mb -core, and godsknowshowmuch -common.. I'm pretty sure they've already drunk themselves unconcious rather than think about oo.o anymore
<Treenaks> elmo: "Let's have a beer for every minute of download time" ?
<lamont> given back
<elmo> btw, appeals to upstream authority are particularly unimpressive when upstream are the folks who include glibc into their upstream source.. :-P
<haggai> elmo: I've had enough people have complained about the all-one-one lump situation we've had up until now who are thankful for every saved meg
<mvo_> lamont: yes
<haggai> there's no glibc in the source
<haggai> thankfully that one's a sun-onlyism
<elmo> anymore...
<haggai> no, it never was in the offical source
<elmo> ok, well they still include a bucket load of crack that they ought to just link to
<daniels> elmo: that's stupid, man
<haggai> yeah well rene has been hard at work fixing lots of that
<daniels> elmo: you've gotta include your own copies of zlib, freetype, fontconfig, ...
<haggai> daniels: for us yes, but not for their broken environments
<Mithrandir> daniels: slightly forked, preferably.
<Treenaks> daniels: xlib 8)
<daniels> Treenaks: x including xlib is ok, as much as i wish xlib would die
<elmo> haggai: well, I'm not going to add the "-l10n-" package as is at least, FYI
<haggai> elmo: the oo2 tarball has quite a few of those system lib removed already now btw
<no0tic> hi, when will mozilla-thunderbird-enigmail be available?
<no0tic> 1.0
<ogra> daniels: i got a colleague with a dual opteron and a matrox four chip card ..... xorg can only intialize the first chip for him....
<haggai> elmo: no problem it should have been l10n-en-us and I already uploaded a fix
<elmo> haggai: it's still 155|Mb ?
<Mithrandir> no0tic: it's available already.
<daniels> ogra: four-head, or four-core?
<haggai> elmo: the official upstream source is > 200mb nowadays
<daniels> if it's a g650 (parhelia), you're sol, I'm afraid
<daniels> matrox have refused to give us any docs at all on the parhelia
<ogra> daniels: it has four chips and four heads...
<no0tic> Mithrandir: I updated right now, but I found 0.90.0-1 version
<haggai> m65 was a whopping 229 meg
<Mithrandir> no0tic: yes, and that is the latest version.
<ogra> daniels: he is here...., its a g450 mms
<Mithrandir> no0tic: it works with thunderbird 1.0
<no0tic> Mithrandir: ah, ok I thought it was for thunderbig 0.9 .. :)
<daniels> haggai: ... that's not COMPRESSED, is it?!?
<Mithrandir> no0tic: the depends for packages are usually correct, so you wouldn't be able to have incompatible thunderbird and enigmail installed at the same time.
<daniels> ogra: hm, I don't think we have support for those -- certainly never seen one
<haggai> daniels: uncompressed its over 0.8gb...
<ogra> daniels: i could get you the data :)
<daniels> anyway, I'm tired as hell, so need to crash -- if you want to file a bug, I'll take a look at it in the morning
<daniels> haggai: sick sick sick sick sick sick sick sick sick sick sick sick sick
<trukulo> ogra: tonight graveman-0.3.1 is going to enter in sid
<no0tic> Mithrandir: thanks
* lamont takes kids to school.
* Kamion attempts to understand gdk foreign windows
<rcaskey> graveman is a neat app but it should be two slightly less neat apps
<rcaskey> or two different menu entries ;) graveman --audiocd or graveman --duplicate
<rburton> serpentine!
<rcaskey> ?
* rburton waits patiently for new gnome-python-extras releases
<seb128> thom: gnome-launch-box in the archive :)
<thom> sweet!
<ogra> rcaskey: its just a modern replacement for xcdroast in my eyes
<rcaskey> ogra: yah
<rburton> rcaskey:  http://s1x.homelinux.net/projects/serpentine
<rcaskey> but just with a bit of tweaking it could be much more gnomish
<ogra> rcaskey: the two apps you look for are nautilus-cd-burner and rhythmbox ;)
<rburton> ncb and rhythmbox|serpentine will rule
<rburton> i've got half-done serpentine debs hanging around somewhere
<rcaskey> yeah rhythmbox will take that over
<rcaskey> but there is no point and click way to duplicate an optical disk is there?
<ogra> rcaskey: i just urged to get graveman in universe to have _anythin_ at all for audio in gnome....to prevent tha ppl to be forced to use k3b
<rcaskey> is RB going to get burning in in time for hoary?
<rcaskey> I compiled the other day and it did okay but crasehd out burning a disk
<chrisa> rcaskey: Would likely make more sense to ask in #rhythmbox on gimpnet
<trukulo> ogra: graveman in sid tonight or tomorrow
<rburton> but but but graveman is ugly
<ogra> trukulo: ypu, i saw it
<rcaskey> because if it is, maybe it's better to get experimental rb debs going instead
<ogra> rburton: its at least _something_
<rburton> ogra: serpentine is a better audio cd burner
<trukulo> ogra: ok
<rcaskey> Serpentine does look nice in the screenshots
<ogra> rburton: btter then telling users pleas use k3b or xcdroast if you wanna burn audio
<rburton> ogra: i understand, but i'm not saying use xcdroast or k3b
<ogra> rburton: so when will you become a MOTU and bring it to universe ?
<rcaskey> ogra: do you know anything about point & click copying of optical media?
<rcaskey> (btw, I put out an SOS last night for a debian-trusted signatory for my key)
<ogra> rburton: since you are already writing ubuntu stuff :)
<rburton> ogra: amusingly i'm still running warty on my desktop :)
<rburton> i must find more disk space and get a warty install
<haggai> elmo: please can you sync dmake from Debian?
<ogra> rcaskey: what exactly do you mean if i know anything about point n click copying ?
<rcaskey> is there a nautilus extension for that I am missingh
<elmo> haggai: that's in main and would violate the UVF.. please mail me, cc mdz and jeff
<rcaskey> some little gtk python frontend to dd
<elmo> [Updating]  dmake (4.2+cvs20031009-5 [ubuntu]  < 4.3-1 [debian] )
<haggai> elmo: ok
<rcaskey> ogra: like open up Computer, right click on CD drive and select "Make an Illegal Copy of this Disk" from the menu
<elmo> haggai: (oh, btw, when you send mail, you need to include rationale for violating UVF)
<rburton> rcaskey: iirc that's planned for ncb 2.12... hadess keeps on saying he'll write it
<thom> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/universe/g/gnome-launch-box/gnome-launch-box_0.1-0ubuntu2_i386.deb  404 Not Found
<thom> grump
<ogra> rcaskey: should be trivial to implement (but i wont do it yet)
<rcaskey> ncb?
<rburton> nautilus-cd-burner
<rcaskey> ahh
<rcaskey> does n-c-b work fine for data dvds as well?
<ogra> rcaskey: yup
<ogra> rburton: join in ;) https://www.ubuntulinux.org/wiki/MOTU
<rburton> how the hell did that page change the bg colour of my URL entry field
<ogra> https
<ogra> :)
<ogra> its firefox that does it, not the page
<rcaskey> I've been wondering how many man-hours it would take me to get up to speed enough on c and gtk to hack on nautilus, I'm thinking maybe 100 man hours
<opi> and that's nice feature
<rburton> ogra: aah, new galeon feature.
<rcaskey> some things about it are bugging me to death
<rcaskey> #1 is the fact that items on the history bar are not gtk drop targets
<rburton> rcaskey: nautilus team always want more hackers
<rcaskey> yeah, I need to learn how to suck less though
<ogra> rburton: so will we see serpentine integration in soundjuicer ?
<rcaskey> At work I have a G4 but I'm getting a Dualie G5 next year
<rburton> ogra: how?
<rburton> that's the 3rd time i've been asked about serpentine integration into SJ but i can't see a single good reason
<ogra> rburton: audio CD copy
<rburton> ogra: that should be a right-click action on the CD icon in Computer
<rburton> thus in ncb
<ogra> hmm...true
<rburton> SJ audio CD copying would encode and then decode an entire album
<rburton> waste of time and effort
<ogra> rburton: but currently th only way to do it with a default gnome
<Treenaks> ogra: coaster..
<ogra> Treenaks: audio ?
<chrisa> People actually use coaster?
<Treenaks> chrisa: don't know
<chrisa> I thought it was just something harshy spoke of that no one really paid attention to
<tseng> ogra: do multiverse bugs apply to you?
<ogra> tseng: hmm, good question .....
<ogra> tseng: what is it ?
<Treenaks> MotU vs MotM ?
<elmo> pitti: err, dude
<ogra> Treenaks: nah
<tseng> ogra: hm, fixed possibly anyway
<elmo> pitti: I thought you seeded the language packs?
<pitti> elmo: I did?
<rcaskey> coaster is someting I see all the time on the planet and think "why"
<pitti> $ madison language-pack-en
<pitti> language-pack-en |   20050119 |         hoary | source, all
<ogra> rcaskey: because libburn is the future.... ?
<zul> hey pitti
<pitti> Hi zul
<rcaskey> I thought it wasn't using libburn anymore?
<pitti> elmo: what's wrong?
<elmo> pitti: yeah, but anastacia wants to demote them all to universe
<elmo> pitti: anyway, if you did, don't worry for now, I'll check some more, the problem may be at my end
<pitti> elmo: I added them to "supported"
<pitti> elmo: so shall I wait with uploading the rest?
<elmo> nah, you can do that if you want
<pitti> okay, fine!
<pitti> then let's get ready for the flood :-)
<Mithrandir> fabbione: feel like looking at 2502?  noapic doesn't seem to apply there?
<pitti> elmo: uploaded. I'll grab something to eat now, later
<no0tic> I get an error installing gnome-panel-data
<no0tic> just upgraded
<no0tic> I can paste it in Italian, sorry, it's a problem in /schemas/apps/clock_applet/prefs/hour_format, it doesn't recognize value  for the schema
<no0tic> brb
<smurfix> anybody know mako's schedule?
<tseng> 6am wake up, shave, shower, 7pm breakfast (of champions), 7:15, hit irc
<smurfix> tseng: ... am or pm?  ;-) and which timezone?
* tseng shrugs
<Mithrandir> he lives in NYC, iirc
<lamont_r> smurfix: he's UTC-0500 right now, but dunno what his schedule is
<lamont_r> Mithrandir: yep
<amu> smurfix: mako: Core Hours: roughly 10:00 - 18:00 EST (15-23 UTC)
<sivang> Morning all!
<smurfix> thanks, that's helpful.
<amu> sivang: moins? it's going to be dark :) 
* lamont_r makes a note to go see what his "core hours" says
<sivang> amu: yeah :), I am trying to go back to UTC , but my body keeps EST :)
<smurfix> lamont_r: mine look more like "core dump hours" lately
<sivang> smurfix: hehe
<amu> lamont_r: hehe you should use UTC :) 
<lamont_r> amu: meh
<opi> we should use Swatch Internet time
<opi> ;-)
<__daniel> hai
<ogra> oh, __daniel....hi :)
<amu> opi: I found you *g* pls join #kubuntu-devel 
<__daniel> did anyone notice the   Arithmetic exception   on amd64's gnome-launch-box?
<Treenaks> ogra: beats! yeah!
<__daniel> i would so much liked to use it :-)
<ogra> :)
<__daniel> hi ogra
<Treenaks> uh. opi 
<ogra> heh
<opi> hi Treenaks
<ogra> Treenaks, opi: are you sure they are not patented ?
<opi> hum..
<opi> never heard about it
<opi> but I liked the idea
<Treenaks> there should be locale-modifiers to do this!
<opi> ,,lets meet @500''
<opi> it was clear, without all this UTC, CET and stuff
<Treenaks> opi: there's still the dateline problem... "the NEXT @500, or the @500 after that?"
<opi> Treenaks, true :)
<Treenaks> opi: "stardate" would fix that
<ogra> Treenaks: or ubuntime
<opi> UNIX_TIMESTAMP()
<opi> from UTC time
<Treenaks> opi: that's too geeky for most ;)
<opi> naa, we need a simple program and a database ;)
<opi> SELECT UNIX_TIMESTAMP(NOW())
<sivang> opi: that's in shell/c ?
<opi> SELECT meeting FROM meetings WHERE UNIX_TIMESTAMP(NOW()) == meeting_date
<opi> sivang, SQL
<opi> sorry, I'm in a middle of finishing a financial system
<opi> and I'm sensible when it comes to dates ;)
<sivang> opi: ah ok :)
<lamont_r> wrote 174063 bytes  read 127798477 bytes  2348120.00 bytes/sec
<lamont_r> total size is 618282296  speedup is 4.83
<lamont_r> hrm...  that's not too bad
<Treenaks> opi: finanicial systems in SQL... I did that once :)
<opi> sivang, but SQL query can be called from virtal any language :)
<opi> Treenaks, SQL's just a place to store things
<Treenaks> opi: I know.. I did it in Perl + SQL
<opi> Treenaks, but thanks to SQL language you can do mutch stuff with query
<Treenaks> opi: + apache
<opi> Treenaks, instead processing data by yourself
<lamont_r> wrote 160329 bytes  read 17721011 bytes  701229.02 bytes/sec
<Treenaks> opi: I put most of my "intelligence" in queries.. the programs did not much more than just show the output
<lamont_r> total size is 524116225  speedup is 29.31
<lamont_r> and that's just _FUNNY_
<opi> Treenaks, that's the way it should be done
<opi> Treenaks, database is so mutch faster at processing
<Treenaks> lamont_r: nice transfer speeds
<Treenaks> opi: yeah
* decko escutando Black Sabbath - Symptom of the Universe
<lamont_r> we need a little package churn in ubuntu-desktop... where's seb128 
<lamont_r> ?
<opi> Treenaks, some people just SELECT * FROM table ;-)
<lamont_r> Treenaks: that's the data center lan
<lamont_r> it's more the speedup that I care about
<Treenaks> lamont_r: I don't even know what it means...
<lamont_r> since that's the cloop image for the livecd
<seb128> lamont_r: what ?
<ogra> opi: at least thats an easy entry threshold.....didnt we all start with select * from ... once ?
<lamont_r> seb128: how much more gnome uploadage should I expect today?
<opi> ogra: sure we do.. but it's lame if you won't go further
<seb128> lamont_r: I'm making bug triage, so probably not a lot
<lamont_r> sadly, that 17MB of data rsync transferred were from officially identical cloop filesystems...
<opi> ogra: if you see someone who do sutch stuff as a proffesional developer, then you just cry ;-)
<lamont_r> seb128: oh well. :-)
<seb128> lamont_r: should I hold the upload for a while time to get a CD built or something ?
<ogra> opi: nope, i suggest gettina an SQL class ;)
<lamont_r> seb128: no.  I actually _want_ some churn today
<lamont_r> but no big deal
<seb128> why do you want that ? :)
<no0tic> seb128: Changes submitted for bug 5717, gnome-system-tools
<lamont_r> so I can see what affect a bit of churn has on the livecd cloop fs
<seb128> no0tic: I get mails from bugzilla, no need to ping on IRC
<no0tic> seb128: sorry
<seb128> no0tic: oh no, don't worry, that's was just for information :)
<wasabi> Heh. All that database stuff that was just talkeda bout.
<wasabi> THat's a formula for inscalibility.
<seb128> no0tic: seems to be a dup of #5578 which should be fixed
<seb128> no0tic: somewhat the patch has not been applied to the build, updating the package right now
<no0tic> seb128: I searched in bugzilla before posting, I didn't noticed there already was...
<seb128> no0tic: it's closed ... 
<seb128> no0tic: that's probably why you didn't notice it
<lamont_r> haggai: ??
<lamont_r> haggai: openoffice.org2_1.9.66-0ubuntu6_i386.changes REJECTED
<lamont_r> Broken l10n package name.
<lamont_r> haggai: of course, what that actually means is an elmo question
<shlomil> hi , where can i find source for Rosetta? what is the license for it ?  
<thom> shlomil: try #rosetta
<shlomil> oh ok , thanks 
<haggai> lamont_r: don't worry I asked elmo to reject it
<haggai> lamont_r: there should be a fixed pkg building
<lamont_r> ah, okl
* haggai hopes this one will actually work..
<lamont_r> haggai: so the 3.4 trampolines in ccache mean I can start hijacking it and routing it through ccache?
<haggai> lamont_r: should do, if you prepend /usr/lib/ccache to your path
<lamont_r> I wind up invoking it as 'ccache gcc-3.4.real ...', actually
<lamont_r> so it probably doesn't even care about the trampoline, no?
<haggai> oh, no
<haggai> the trampoline is only for if you don't include ccache explicitly on the command line.
<LetterRip> Hello all, I read the meeting minutes and saw a mention of a site blocking tool to be developed for ubuntu, I have a fairly nice design document for a tool I call safeTNet that I'd be interested in having the coders consider
<haggai> if you do, ccache should ignore all gccs that are actually symlinks to itself like in /usr/lib/ccache
<decko> Hi people!!! What's happen to the ubuntu mirrors??? I can't download anything from them
<lamont_r> haggai: ok.
<lamont_r> decko: what exactly is the failure?
<decko> lamont-away, 404 Object not found!] 
<lamont_r> decko: and you have a current Packages file?
<lamont_r> that is, if you re-update and try again, does it work, or still fail?
<lamont_r> and what exactly are you trying to download?
<lamont_r> hrm.. no -onomtime,noctime available in mount... :0)
<lamont_r> I guess that's a good thing
<decko> lamont-away, I'm not using apt to download this files, I'm trying to download from the ubuntu's packages page 
<lamont_r> ah, ok
<lamont_r> url?
<lamont_r> both the 404 and the page with the link, that is.
<decko> Nope! I know, when you go to the packages page, select a package, and after this, select the archicteture
<decko> lamont_r, And then, you select from where you want to download the file
<lamont_r> decko: of course, this really belongs in #ubuntu...
<lamont_r> decko: I need a url before I can see what's happening..
<lamont_r> ironwolf: shouldn't you be asleep right now?
<decko> lamont_r, http://higgs.djpig.de/ubuntu/www/hoary/gnome/update-manager
<decko> lamont_r, Select the i386 architeture and try to download something
<__daniel> decko: i had problems on archive.ubuntu.com too some minutes ago - i guess you just have to be patient for 20 minutes or something
<Mitario> heyhey
<decko> __daniel, But I can't download anything from any mirror!
<__daniel> decko: i had problems too, some minutes ago
<lamont_r> decko: that mirror looks out of sync
<lamont_r> 0.36 is current, although that was uploaded on Jan 19
<Mitario> hey guys, is there any active testing/development/debugging project of bluetooth stuff in hoary?
<Mitario> or for the future :)
<decko> lamont_r, ahauahuahua Then all the mirrors are out of sync!
<decko> __daniel, Ok guy! Thanks so much!
<Kamion> update-manager |       0.36 |    hoary/main | amd64, i386, ia64, powerpc, source
<Kamion> that's on rookery ...
<mvo_> decko: maybe it's just this http://higgs.djpig.de/ubuntu/www/ site that's not up-to-date?
<Kamion> decko: ftp.mirrorservice.org is fine, for instance; definitely not all the mirrors
<mvo_> seb128: is a new version of libnautilus-extensions available? it looks like g-s-t needs it
<lamont_r> mdz: wrote 160329 bytes  read 17721011 bytes  701229.02 bytes/sec
<lamont_r> total size is 524116225  speedup is 29.31
<lamont_r> mdz: 4k/4k is _worse_ by loads... (127MB)
<lamont_r> although 17MB of diff for effectively no change is kinda sad...
<__daniel> decko: de rien :-)
<lamont_r> mdz: doh.. comparing manifests, 10 packages are different, so I'm less concerned.
* lamont_r prepares do deploy... Kamion wanna burn new livecd's in about 45 minutes?
<seb128> mvo_: no
<seb128> mvo_: which version is required ?
<pitti> lamont_r: the langpacks are flowing into the archive. strip time! :-)
<pitti> lamont_r: this time for real, I hope :-)
<lamont_r> pitti: current plan was to drop new livecd roots into things, then go to the gym, then go home...  Mind if stripping waits a couple more hours?
<mvo_> seb128: it claims that it needs 2.9.3
<seb128> mvo_: CVS or a release ?
<seb128> mvo_: that's the CVS version (bumped after the 2.9.2 release)
<mvo_> seb128: ok
<Kamion> lamont_r: sure
<mvo_> seb128: I'm sending garnacho a patch that makes the use of sudo a gconf option
<Kamion> lamont_r: is this the rsyncable one?
<seb128> mvo_: rock
<lamont_r> Kamion: no, the next one is :-)
<lamont_r> yes
<lamont_r> 3/4 building... (ia64 needs more help.)
<lamont_r> %partimage: !ia64 !alpha                                              # 64-bit is br0ken
<lamont_r> hrm.. that bodes ill for amd64 as well...
<lamont_r> or is the filesystem 32-bit?
<lamont_r> Kamion: so anyway, this'll give us much more rsyncable i386/ppc images, and rsyncable amd64 images that may or may not be totally and thuroughly broken.
<lamont_r> please advise. :-)
<amu> mvo_: any plans for sun? 
<pitti> lamont_r: I don't mind at all. This was just intended as a notification :-)
<mvo_> amu: still uncertain :)
<lamont_r> pitti: cool
<Kamion> lamont_r: awesome
<lamont_r> Kamion: after the gym, I'll ping you and download the image that I'll rsync against after this...
<Kamion> lamont_r: hm, is ia64 broken? I thought it had started working
<lamont_r> and then I'll go home and change things so that partimage is optional
<lamont_r> the new script uses partimage for some of the rsync magic
<Kamion> it's got a livecd-current.cloop
<lamont_r> and partimage is PaS
<Kamion> lamont_r: ia64 CDs should be building anyway as of tonight
<lamont_r> yes - not the rsyncable change though
<lamont_r> once you see ~buildd/livecd/latest populated with a cloop, then current is the same thing and ready for the CD
<lamont_r> build
<Kamion> I'd enabled it but forgotten to sync to little, and then I managed to run into a baz bug ... but the change is there now
<lamont_r> partimage and 64-bit: either ia64 could build and be fine, or amd64 may be toast.
<lamont_r> ah, ok
<lamont_r> so someone should really test the new amd64 livecd once you burn it... :-)
<lamont_r> anyway, off to the gym, and then the bandwidth-rich coffee shop.
<lamont_r> back in about 90-120 minutes, give or take
<amu> lamont_r: 20050121/amd64 ? 
<lamont_r> amu: no, the one Kamion is going to build in about 40 minutes or so
<lamont_r> you'll want to grab that one in any case, since future ones should rsync much nicer....
<amu> lamont_r: no prob, i can test it 
<fabbione> hey gys
<fabbione> guys
<lamont_r> amu: thanks - if it's thuroughly b0rked, then we need to fix partimage...
<amu> Kamion: just ping me if it's ready
<amu> *pong*
* lamont_r grabs partman by the throat and shakes it
<Kamion> what's up with partman?
<lamont_r> it really doesn't like to run without a valid $TERM
<Kamion> how did you manage not to have a valid $TERM?
<lamont_r> Failed to open terminal.Unknown terminal: unknown
<lamont_r> Check the TERM environment variable.
<lamont_r> Also make sure that the terminal is defined in the terminfo database.
<lamont_r> Alternatively, set the TERMCAP environment variable to the desired
<lamont_r> termcap entry.
<lamont_r> easy - it's inside a chroot in an at job.
<Kamion> uh, you sure you mean partman?
<Kamion> that's part of d-i
<lamont_r> partimage
<lamont_r> sorory
<Kamion> aha
<fabbione> jdub, thom, Mithrandir: ping
<thom> fabbione: yo?
<fabbione> thom: you should be able to install hoary from sparc.u.c now :-)
<fabbione> elmo: can you bless the latest d-i please? (when you have time)
<thom> fabbione: heh
<stockholm> Werner_: it is in pere`s homedir on /wc
<stockholm> heh
<thom> stockholm: uh, wrong window one suspects
<stockholm> thom: (c:
<fabbione> pool/main/l/language-pack-bg/language-pack-bg_20050119_all.deb
<fabbione> YEPPA
<stockholm> thom: but this time it was not even embarrassing.
<stockholm> content at least.
<seb128> wasabi, wasabi_: no need to Cc: me I read ubuntu-devel
<wasabi_> did i?
<wasabi_> oh, oops. ;)
<wasabi_> actually this one menu editing thing has incited me. i work in an office of people using ubuntu now, and one of the office guys wanted to try hoary... and was really miffed that he couldnt' edit the menus, and that he was forced to use weird text files. ;)
<wasabi_> and i have to agree with his feelings.
<seb128> why do you need to edit the menu ?
<seb128> it should "just work"
<wasabi_> They want to add their own items to it.
<wasabi_> Stuff that is not properly packaged.
<wasabi_> And probably never will be.
<seb128> ie: you get a menu entry with all the user apps
<wasabi_> third party apps
<Kamion> if you're adding your own applications then you *obviously* need to edit the menu ...
<lamont_r> seb128: and my list of machines menu
<wasabi_> if it was just temporary and attributed to "hoary not being done yet", I wouldn't have a problem... but that the feature is being removed because the replacement "is not done yet"... seems odd.
<seb128> applications:// was crap
<wasabi_> just leave the old peice of crap in until a proper replacement is complete.
<wasabi_> i agree.
<seb128> you can't argue than the old menu with applications:// was better than the new one
<wasabi_> i'm not trying to
<seb128> the old piece of crap edit a vfolder
<seb128> which is not used for gnome-panel
<seb128> that doesn't work
<wasabi_> but a feature was just ripped out from under many people who used it, and they were told to "edit some arcane text files instead".
<wasabi_> that's just not right.
<seb128> you prefer to do nothing so ?
<wasabi_> I prefer to leave the menus as they are until the proper way is complete.
<seb128> I agree than having an editor would be better
<seb128> ok, so you would have kept the old vfolder crap with applications:/// rather than the new menu
<lamont_r> seb128: are there plans for one before 2.10?
<seb128> lamont_r: no
<wasabi_> seb128: that's not the question
<wasabi_> seb128: the question is "would you prefer to be able to edit the menus in hoary or not"
<seb128> lamont_r: "plan" could be, people with the willing and the time ...
<lamont_r> seb128: right
<seb128> wasabi_: no, that's not the question
<wasabi_> it's the question I was just asked by an ubuntu user here in the office
<seb128> wasabi_: you are saying "keep GNOME 2.8 for hoary"
<wasabi_> basically
<seb128> just install menu and menu-xdg
<lamont_r> seb128: I think the real question he's trying to ask is "is the lack of an editor for menus in 2.10 considered a release critical bug or not?  ditto for hoary?"
<seb128> you'll get the Debian menu
<wasabi_> My users don't give a damned how you make it happen.
<seb128> and edit that :p
<seb128> lamont_r: if you ask if I'm going to write a menu editor for hoary, I'm not, too busy for that :)
<lamont_r> because wasabi_ appears to consider it release critical.
<seb128> but patches are welcome
<wasabi_> This is just one of those things which really pisses peple off about linux and open source in general
<lamont_r> seb128: I know that
<seb128> we should bounty that if 
<wasabi_> And I'm just hilighting that.
<seb128> jdub: ping ?
<Kamion> hey, let's not turn this into something more general than it needs to be
<wasabi_> heh.
<lamont_r> wasabi_: as opposed to proprietary source,where they just don't implement the feature and don't give you the source??
<Kamion> I've seen this kind of thing happen with software from all sources
<lamont_r> Kamion: ditto
<wasabi_> listen, all im saying is when I deploy hoary, my users will come to me for support, and I won't have a good answer (unless menu-xdg is a good answer, perhaps it is, trying it now)
<seb128> wasabi_: you should consider that applications:/// was not really obvious in warty too and many people were already complaining about the menu edition, that's not new
<seb128> wasabi_: menu-xdg install a Debian menu in applications ... have you already used debian/the debian menu ? :)
<lamont_r> seb128: IOW, "lack of a good menu editing solution continues to be an issue looking for someone to solve it."?
<wasabi_> seb128: you could right click on items In The Menu and edit them. add remove, delete.
<wasabi_> You did not need to browse to applications:///
<wasabi_> So, it was VERY obvious.
<seb128> hum
<seb128> so why people keep complaining about it for months :p
<wasabi_> I just confirmed this on Warty across the office.
<wasabi_> I dunno.
<seb128> lamont_r: right
<wasabi_> I mean, I don't have a good answer for you, from the developer side.
<jdz_work> This might make a good love-fest afternoon or a good bounty.
<wasabi_> But, from the user side, I can say, it's one of those things which will come back to haunt ya.
<seb128> wasabi_: I've a 2.8 box here and adding a menu in the menu doesn't seems to be obvious
<lamont_r> seb128: and 2.8->2.10 goes from a really crappy menu editor to no menu editor?
<wasabi_> seb128: right click in the sub menu
<seb128> lamont_r: correct
<wasabi_> use the ... "Entire menu" or something, box.
<wasabi_> You can add new items.
<seb128> wasabi_: I've an option to add the menu to the panel
<lamont_r> seb128: so if I install menu and menu-xdg I get a 'debian' menu entry that I can then play with?  that could be a start for me...
<wasabi_> Yeah, it does suck. It is bad UI.
<wasabi_> But, a right click can figure it out.
<seb128> wasabi_: but not to create an entry
<wasabi_> seb128: right click on an item in a submenu, use the Entire Menu sub pop up menu
<seb128> lamont_r: you get a debian menu ... do we have an editor in debian for this crap ? :)
<seb128> wasabi_: bah, that sucks, most of people don't find it and I know why :p
<lamont_r> Kamion: eta 35 minutes or so
<Kamion> wasabi_: if you're doing the deployment, do you have the facility to add .desktop files?
<lamont_r> Kamion: actually, i386 is about 5-10 away from done... :)
<Kamion> [note I don't know enough about GNOME to know whether that's sufficient to add menu items] 
<seb128> Kamion: you just need to add a .desktop to add a menu entry (in /usr/share/applications or ~/.local/share/applications)
<seb128> BTW perhaps KDE has an editor for the menu, since the menu are freedesktop ones now ?
* lamont_r makes plans to learn enough about .desktop files to create his own again
<seb128> haggai: ping ?
<jdz_work> seb128: So what we need is a graphical editor for .desktop menu entries?
<Riddell> seb128: kmenuedit has always been there
<seb128> jdz_work: a way to edit menu since some people want this
<seb128> Riddell: does it use the freedesktop spec ?
<wasabi_> and Add new item to this menu
<wasabi_> It pops up the launcher creator box
<wasabi_> Let me just list some apps my users need in these menus... some of the ones I *know* about anyways.
<wasabi_> vmware we use. it doesn't make .desktop items.
<wasabi_> that stupid ass adobe acrobat reader
<wasabi_> most of our developers put Eclipse in there
<wasabi_> some install Wine applications which we need and put an item in there for each thing.
<wasabi_> etc etc etc
<wasabi_> anyways, i dont have a good answer for you. i realize the old system sucked and the new one is better...
<Riddell> seb128: yes I think so
<wasabi_> woh
<wasabi_> lag
<seb128> wasabi_: could you try this kmenuedit ?
<haggai> seb128: pong
<wasabi_> Kamion: I dont do the deployment of a lot of things. We're a very ad hoc company. We deploy the basic stuff, but really each department fends for themselves... users are given artistic license on their PCs
<seb128> haggai: anything in KDE to edit GNOME menus ? :p
<wasabi_> seb128: checking
<wasabi_> Kamion: and to say that that's not the case for every home user would be foolish.
* wasabi_ downloads all of kde. =/
<amu> seb128: kmenuedit ? 
<lamont_r> Kamion: i386 is compressing, other two are chunking along in apt - I'm finally gonna go disappear for that 2 hours or so
<seb128> I'll try kmenuedit
<seb128> dunno if it works for the new GNOME fd menu
<Kamion> wasabi_: I'm not trying to say that; I'm trying to help you by suggesting workarounds
<haggai> seb128: yeah, kmenuedit.  I don't know if it works for the Gnome menu nowadays
<Kamion> wasabi_: (and yes, every company I've ever worked for as a permanent employee has worked the way you say, and it's great)
<seb128> bah, still, I hate pointing a KDE stuff to GNOME users :p
* haggai fires up laptop
<amu> haggai: should works also for gnome, both use fd.o
<wasabi_> kmenuedit looks like it works
<seb128> wasabi_: ok, you have a workaround so if you don't mind installing the deps ...
<wasabi_> or not.
<Riddell> seb128: can't they use applications:///
<wasabi_> it reads... doesn't look like it saves
<seb128> Riddell: that has been dropped in 2.9
<Riddell> seb128: why is that?
<wasabi_> seb128: kmenuedit does not work
<wasabi_> seb128: it reads the config, but does not save changes.
<haggai> looks like gnome menus don't get updated
* haggai logs out & back in
<seb128> Riddell: you should read ubuntu-devel :/
<seb128> Riddell: gnomevfs has dropped the vfolder support which was the stuff used for the old menus, now it uses the freedesktop specifications
<seb128> Kamion: about #4280 ?
<Kamion> hmm
<Kamion> I think germinate will be OK with that, let me see
<haggai> bah it won't log back into my Gnome session
<mdz> morning
<haggai> afternoon
<seb128> hey mdz 
<fabbione> hey mdz
<fabbione> haggai: did you talk with lamont?
<haggai> fabbione: yes thank
<haggai> s
<fabbione> did he give it back?
<Kamion> mdz: can I add a backdrop title to casper?
<Kamion> something like "Ubuntu Live CD"
<haggai> fabbione: hmm seems he did and it failed again
* haggai grabs log
<mdz> Kamion: yes, certainly
<fabbione> ok
<fabbione> no.. it's not ok
<mdz> Kamion: I had planned to do that, and some other live CD improvements yesterday, but instead I spent all day chasing that init/khubd bug
<pitti> Hi mdz!
<Riddell> why are ubuntu milestones called arrays?
<Kamion> mdz: note I'm going away for the weekend starting in about an hour; if I'm to do the busybox modifications I had better start now
<mdz> not even so much as a log message to say "usb is useless now because khubd died, sorry"
<fabbione> mdz: RUN! when pitti add a "!" at the end it means troubles!
<Kamion> Riddell: collective noun: an array of hedgehogs
<sivang> fabbione: hehe
<sivang> pitti: Hi Martin!
<mdz> Kamion: you already explained what needed to be done for the backtitle; I can do that if you take care of busybox
<mdz> Kamion: are you back monday morning?
<Kamion> mdz: ok. yes, probably Sunday evening although I don't know if I'll be around much then
<pitti> fabbione: no worries, just sayin' hello
<fabbione> pitti: :P
<pitti> fabbione: I don't trash anything any more at Friday evenings :-)
<fabbione> ehehh neither do i
<haggai> fabbione: same problem, I'll start a local build
<fabbione> i am laying in bed with 39 of fever :/
<Riddell> Kamion: but of course :)
<fabbione> haggai: ok, because i trashed my build after you told me you will look at it ;)
<haggai> fabbione: np
<mdz> Kamion: "Ubuntu Live CD" you think?
<mdz> Kamion: hmm, but it will also be used on DVDs and USB sticks
<Kamion> yeah, was wondering about that
<T-Bone> hi
<mdz> that's one of the reasons that casper has a proper name
<mdz> "Ubuntu Live"?
<T-Bone> fabbione, ping?
<fabbione> lamont-away:
<fabbione> cat chroot-hoary/CurrentlyBuilding 
<fabbione> Package: aca
<fabbione> Component: universe
<fabbione> so the fix works :-)
<fabbione> T-Bone: pong :-)
<Kamion> mdz: works; reads a bit oddly at first glance
<fabbione> i read the mail and answered to it
<pitti> fabbione: oh, bad
<Kamion> "Live Ubuntu Environment"?
<fabbione> pitti: the funny thing is that i don't feel it at all
<pitti> fabbione: anyway, I already did my trash of the day, I uploaded 246 packages (language packs) :-)
<T-Bone> fabbione, just read your mail (i'm recovering a few boxes at school after powerfailure),
<Kamion> "Live Ubuntu"?
<mdz> Kamion: if we can think of something better, a number of other Casper templates could use improvement too
<sivang> Kamion: UbuntuLive
<fabbione> pitti: my gf noticed that i had a weird (more than usual) look
<haggai> Ubuntu Live
<mdz> I'm not particularly satisfied with "Preparing for live session" either
<pitti> fabbione: hmm, but not feeling anything with high fever might also be a very bad sign...
* haggai high-fives sivang
<T-Bone> fabbione, what do you mean by 'taking the leadership for the kernel'?
* sivang high fives haggai back :)
<fabbione> pitti: nah.. it has always been like this and i saw the packages :) congratulation man
<amu> fabbione: hehe, rest and heal :) my flu is over  
<fabbione> T-Bone: you can take over the kernel team leadership :-)
<fabbione> amu: i have only 9 days to finish 2 rooms in the house :(
<fabbione> it's no good to have to stay in bed
<T-Bone> fabbione, who's on that team. What would it involve from my side? :)
<fabbione> T-Bone: did you read on the wiki?
<T-Bone> fabbione, i'm installing firefox atm ;)
<T-Bone> there, having a look
<Kamion> mdz: BTW translations of backdrop titles won't work until we get a newer cdebconf (I fixed that upstream), but that's not urgent
<fabbione> T-Bone: as kernel leader you lead the team and it involves basically everything 
<T-Bone> fabbione, ok got it. Now what am I expected to do, as a (potential) team leader?
<fabbione> :)
<fabbione> coordinate, delegate, qa, do releases
<T-Bone> fabbione, lol, that's an answer I can't cope with :)
<fabbione> that's why there is a team
* T-Bone curses warty installer for not offering a proxy setting
<fabbione> T-Bone: that has been disabled
<amu> fabbione: place the "brush" into you GF's hand :) 
<fabbione> if the installer can reach one of our server it doesn't ask for proxy
<sivang> fabbione: from where I know, a team leader also has to cover for team members who do not manage to complete tasks and who do embarrasing stuff :)
<sivang> s/where/what
<fabbione> sivang: as well
<sivang> fabbione: hehe :)
<fabbione> amu: she is working
<amu> fabbione: you got it :) 
<fabbione> i need to reboot 
<fabbione> brb
<jmones> Hello! I'm not sure if this question is appropiate here, but it seems to me that something is wrong. I need to find /usr/include/X11/Xauth.h but it's not in xlibs-static-dev as in Debian. Where is it?
<sivang> jmones: strange, when doing apt-file search for that, I do find it there, did you install the package?
<jmones> mmm... yes
<sivang> jmones: sorry, my mistake
<sivang> jmones: xlibs-static-dev: usr/X11R6/include/X11/Xauth.h
<jmones> i installed xlibs-dev
<jmones> and xlibs-static-dev
<sivang> jmones: so it would be under X11R6 , not under X11
<jmones> opps... my fault then
<ogra> jmones: ogra@honk:~ $ dpkg -S /usr/X11R6/include/X11/Xauth.h
<ogra> libxau-dev: /usr/X11R6/include/X11/Xauth.h
<jmones> isn't it in X11 in debian?
<Treenaks> ogra: ah, Xorg with split packages
<azeem> jmones: there's a compatibility symlink
<ogra> yup :)
<Treenaks> jmones: Debian has XFree86, Hoary has Xorg
<jmones> ah ok
<jmones> i've recently changed from xfree86 to xorg and there's are some glitches 
<jmones> btw, there's a bug that avoids the user from using ctrl+alt+f1 to switch to VT
<sivang> jmones: on a hoary?
<jmones> i set the sources from hoary to a warty
<jmones> and without dist-upgrading (i was in a hurry) installed xorg
<fabbione> jmones: nah.. that's plain wrong...
<jmones> i noticed the problem about crl+alt+f1 (there are a lot of references on the web) is because xlibs version
<fabbione> jmones.
<ogra> jmones: this will certainly break
<fabbione> either you update properly or stuff won't work
* sivang is using hoary happily without anything simiarl.
<sivang> ofcourse, I've done dist-upgrade everytime.
<jmones> i've now dist-upgraded and everything works :)
<fabbione> a bug like that would be noticed even by CNN
<sivang> moquist_: Matt ! :)
<sivang> fabbione: CNN are using Ubuntu? ;o)
<jmones> lol
<jmones> thanks very much
<fabbione> sivang: no idea.. but if something like was broken, both Daniel and I would have tons of people knocking at the door
<sivang> fabbione: true.
<ogra> fabbione: knock knoc
<ogra> k
<fabbione> ogra: come in :)
<ogra> fabbione: on the recent ppc livecd console switching doesnt work for me *g*
<jmones> i thought that perhaps setting a conflicts in xserver-org on old xlibs could be ok
<fabbione> ogra: that has to be a ppc problem
<ogra> fabbione: (baut taht is caused by the special machine i got ;)
<jmones> ogra, that's another bug i thing related to keyboard
<sivang> ogra: doesn't work for me also in i386
<fabbione> jmones: please can you move these topics to #ubuntu?
<fabbione> the are not really related in here
<ogra> jmones: it is common for that machine....x dtdection also doesnt work ;)
<fabbione> and if there are bugs, please report them vua bugzilla
<fabbione> via even
<jmones> fabbione, ok. Sorry. Thank you
<fabbione> because otherwise people will lose track of these stuf
<fabbione> not everybody uses a huge irc scrollback
<fabbione> or read eons of it
<fabbione> and the X maintainer is not here
<fabbione> abelli: you can start testing the sparc d-i from sparc.ubuntu.com
<abelli> fabbione: mmm... sorry for the lack of help, but i had some problems collecting the machines
<Kamion> mdz: patch sent; see you next week
<Kamion> mdz: as I said, no time to test it I'm afraid :-(
<mdz> Kamion: I'll give it a shot, and fix it up if necessary. thanks
<ogra> Kamion: thanks for fixing the MOTU typo ;)
<mdz> Kamion: enjoy the weekend
<ogra> Kamion: have a nice WE
<Kamion> ogra: I like details ... :-)
<ogra> goood :)
<Kamion> mdz: apparently I shall be wearing a snake costume to a fancy dress party
<ogra> lol
<ogra> Kamion: please take pictures :)
<thom> good weekend, folks
<sivang> Kamion: nice, I'd join if I was in a walking distance :)
<Kamion> my other half is in the process of buying an amelanistic corn snake
<sivang> thom: c'ya!
<sivang> Kamion: you should put some photos maybe ;q)
<ogra> wow, how do i rape css: http://zengarden.20megsfree.com/
<abelli> rape?
<ogra> mistreat
<__daniel> abuse :-)
<ogra> yep
<abelli> __daniel: yeah..
<__daniel> ogra+__daniel: Online Thesaurus 1.0 (c) 2005 :-)
<ogra> hehe
<ogra> my cpu is pushed from 800Mhz to 1.6 Ghz by only displaying this page...woah
<sivang> ogra: at least you got cpu scaling working :)
<ogra> sivang: yup, worked from the beginning....
<sivang> ogra: worked for me also in the beggining of hoary, not now though.
<__daniel> sivang: which kernel do you have installed?
<ogra> sivang: you fiddle too much with your system ;)
<abelli> what does it mean if the installer throws a segfault?
<abelli> :)
<sivang> __daniel: 2.6.10-1
<mako> smurfix: 
<ogra> sivang: why not -2 ?
<abelli> why not -hardened?
<sivang> ogra: -2 sefgaulted amd tried to kill init :)
<ogra> sivang: you definately fiddle too much with your system ;)
<__daniel> sivang: that's bad because 2.6.10-2 made cupfreq_userspace working again :-)
<sivang> __daniel: well, I'm upgrading the dellappi now , see where that gets me, unless I would open a bug.
<__daniel> sivang: i'll have my fingers crossed :-)
<sivang> __daniel: ok, MOTU also are you?
<mdz> lamont-away: today's i386 live CD image is bigger; did you change parameters on the daily build?
<__daniel> sivang: er... whats MOTU?
<ogra> https://www.ubuntulinux.org/wiki/MOTU
<ogra> sivang: __daniel will be a MOTU .....
<ogra> sivang: i will care for that ;)
<__daniel> sivang: i'd love to be... really, but i'm busy with my thesis at the moment
<sivang> ogra: ah you two know each other?
<__daniel> sivang: yes... you could say that :-)
<ogra> sivang: we learned to know each other through ubuntu :)
<sivang> ogra: eh nice :) please to meet you __daniel 
<wasabi_> Hmm. I wanna be a MOTU. ;)
<wasabi_> do they get t-shirts?
* __daniel curtseys before sivang ;-)
<jdz_work> t-shirts! :D
<__daniel> sivang: so until april/may i unfortunately wouldnt have the time to do the job properly
* ogra looks at his chest....
<sivang> __daniel: no prob, not all of us can, work, other stuff etc.
<__daniel> sivang: mvo_ lives 10 km away from me, too :-)
<wasabi_> Actually. In all honesty... is anybody working on Java on Ubuntu?
<wasabi_> or is it all just copied out of debian
<ogra> sivang: nah, there are only 15000 packages....
<ogra> ;)
<sivang> wasabi_: Jeff Bailly is, IIRC
<mdz> wasabi: jbailey is working on that for the hoary release
<__daniel> sivang: so this area is properly ubunt-ized :-)
<mdz> wasabi: see JavaIntegration in the wiki
<ogra> mdz: on todays livecd the desktop worked like a charm.....(amd64)
<sivang> mdz: anything sorted out with the usb bug?
<eruin> does the ubuntu 2.6.9-kernels have fixes for the ptrace bug that messes with cedega/wine/ copy protection=
<wasabi_> Oh.
<wasabi_> Hah.
<wasabi_> odd.
<wasabi_> jbailey: It's just come to my attention that you ARE the Java guy for Ubuntu. Want Eclipse? :)
<__daniel> the term MOTU is just too funny :-)
<zul> damn now im thinking he-man and she-ra
<wasabi_> Whose the Master of the Multiverse?
<__daniel> zul: that's what i thought too :-)
<ogra> wasabi_: haggai is the master of the MOTUs (which would make him he-man i guess)
<eruin> why is #5619 marked a duplicate of 5582 ?
<eruin> fabbione? 
<zul> __daniel: all we need is battlecat and we would be set
<__daniel> zul: not quite sure man-at-arms would be :-)
<__daniel> zul: not quite sure, who man-at-arms would be :-)
<orro> heh
<mdz> sivang: yes, I found the bug last night
<mdz> sivang: colin wrote an initial patch this morning
<mdz> and I am fixing it up now
<sivang> mdz: ok, I'll resync/download at your will.
<mdz> lamont-away: I'm going to need d-i builds a bit later
<sivang> yay! new 2.6.10-2 doesn't segfault init anymore and works.
<__daniel> sivang: woohoo! :-)
<elmo> uh
<elmo> mdz: you know how you approved the language packs - did you realise it was going to pull in about 40 random l10n packages with it?
<elmo> mdz: people.ubuntu.com/~james/l10n.txt
<mdz> elmo: yeah, those should all have been seeded anyway
<mdz> they're either new, or ones we missed
<elmo> ok
<mdz> in fact we should probably remove the ones which are seeded, and let the language packs handle it through germinate going forward
* T-Bone is done restoring vital hw setup @school, heading back home. Bbl.
<__daniel> i don't get why i'd need myspeel-de-{de,at,ch}
<__daniel> but good to have those metapackages anyway :-)
<abelli> is openoffice2 avaible now?
<rcaskey> mdz: how many more arrays are left until release?
<rcaskey> is there a torrent?
<mdz> rcaskey: http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule
<rcaskey> (anyone on the southern light rail ;)
<rcaskey> mdz: did the arrays get started later than planned?
<sivang> ogra: ergh, updated to 2.6.10-2 newone, boots the syste, but now no sound and cpufreq applet still b0rked
<ogra> hmm :(
<__daniel> sivang: what does dmesg say when you modprobe cpufreq_userspace or the appropriate module for your soundcard
<sivang> ogra: I should put some more time into investigatin it when I am less busy..
<sivang> __daniel: the machine is busy doing something else at the moment, I will run this when I get a hold of it agian.
<ogra> sivang: did you make any changes to your grub kernel line ?
<sivang> ogra: didn't touch it
<ogra> sivang: never ?
<sivang> ogra: hhm, sudden;y I  not sure , I may have added something for the PCI collision workaround..
<ogra> sivang: thats what i thought when i read dell....
<ogra> sivang: if you added it dirctly to the kernel line it is overwritten on upgrade
<jbailey> wasabi_: *lol*
<ogra>  /is/was 
<sladen> sivang: hunt around in /proc/cpufreq the display should be independent to the control
<jbailey> wasabi_: Let's talk about it. =)
<ogra> sladen: great to see you, could you add some info here: https://www.ubuntulinux.org/wiki/MOTU
<abelli> can i install OOo2?
<wasabi_> jbailey:  =)
<wasabi_> jbailey: my mission right now is to get most of the java stuff on debian that's stuck in contrib for some reason into main.
<wasabi_> Mostly so it makes it into Ubuntu for myself.
<wasabi_> So, I think our goals merge.
<jbailey> wasabi_: Yeah.  Are you one of the authors of the JavaInMain on wiki.debian.org?
<wasabi_> no.
<wasabi_> but, im one of the people working on it. :0
<jbailey> =)
<wasabi_> I dont know how out of date that page is
<wasabi_> We've got ONE package to get into main before Eclipse hits it.
<wasabi_> Lucene.
<mdz> init is the biggest pain in the ass to debug
<jbailey> Reasonably, but the sense of the page is still pretty good.
<ogra> mdz: rewrite it :)
<mdz> ogra: it's not the implementation
<ogra> ouch
<mdz> but thanks for the helpful suggestion :-p
<ogra> hehe
<ogra> mark would kiss you for a python replacement
* ogra has weird ideas today
<__daniel> python replacement of what?
<ogra> init
<ogra> *g*
<wasabi_> jbailey: when Eclipse hits main, that will give us eclipse-javac. It's a 100% complete javac, that's free enough.
<wasabi_> So, we can compile anything at that point.
<mdz> you can't trace it, you can't debug it, you need to replace it and reboot in order to test a change, and if you have a bug, the system halts
<wasabi_> http://jack.feedbackplusinc.com/~jhaltom/eclipse    I need testing of those packages. ;0
<sivang> wasabi_: whatever you do, make sure you include a simple DOM parser that's easier to learn then Xerces ;-p
<sivang> and subclass..
<Mitario> jo all
<Mitario> jdub, here?
<amu> Kamion: your image is finished? 
<ogra> amu: Kamion is away for the weekend
<amu> weekend: command not found ;)
<ogra> heh
<ogra> for me its... weekend, finally i can do the serious work....
<ogra> mdz: probably a vm would be helpful, i think xen has something like that
<ogra> debugging that is
<mdz> not really
<sivang> ogra: I wish QEMU would be a bit faster, then I could be using it more efficiently for cross platform needs :)
<ogra> ah, only kernel debugging it seems....http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/#SECTION03340000000000000000
<T-Bone> mako: ping?
<sladen> keybuk: see #ubuntu if you're around
<wasabi_> ubuntu cd's should come with a friendship bracelet.
<ogra> wasabi_: great idea, start wattling ;-P
<amu> wasabi_: ;)
<__daniel> wasabi_: in germany we make fun of the right one of these: http://www.fernando-express.com/Petri_01.jpg
<__daniel> wasabi_: at least 2-3 years ago :-)
<ogra> __daniel: LOL
<__daniel> ;-)
<amu> __daniel: heheheh
<wasabi_> that guy, with that hair, has more friends than me. =(
<__daniel> wasabi_: but i guess he's not on any gpg-keyrings :-)
<seb128> thom: here ?
<__daniel> i thought that was the modern friendship bracelet :-)
<ogra> __daniel: in this case ^^^, the new hoary cd will obviously ship one :)
<__daniel> i'll wear it too, i promise ;-)
<ogra> *g*
<jbailey> What's the magic command to tell cdebootstrap to build a hoary chroot?
<ogra> https://www.ubuntulinux.org/wiki/DebootstrapChroot
<jbailey> Ah, debootstrap, not cdebootstrap.  That'd be why google didn't have it. =)
<jbailey> ogra: Thanks! =)
<sivang> ogra: if I already have hoary, do I need to create a chroot env? only for testing breakage stuff i,e ?
<ogra> sivang: if you dont want your system polluted with unecessary packages a chroot is very helpful
<sivang> ogra: k, that what I though :)
<sivang> ogra: tnx
<ogra> :)
<sivang> ogra: strange, I get E: No such script: http://archive.ubuntu.com/ubuntu/
<mdz> sivang: you gave the wrong arguments
<sivang> mdz: used riddle's args from the wiki...
<sivang> mdz: # udo debootstrap --variant=buildd hoary chroot/ http://archive.ubuntu.com/ubuntu/
<ogra> sivang: after making the dir ?
<mdz> you don't need to make the dir
<mdz> remove the trailing slash from "chroot/"
<sivang> mdz: k, thanks alot.
<sivang> mdz: same, I think it can't find archive.ubuntu.com or something..
<ogra> sivang: i just tried it again, even with the / it works here
<sivang> ogra: could you msg me the line you executed?
<mdz> you have an extra space somewhere, or something like that
<mdz> you're passing 4 non-option arguments to debootstrap, instead of 3
<ogra> sivang: i copy and pasted:  sudo debootstrap --variant=buildd hoary chroot/ http://archive.ubuntu.com/ubuntu/
<sivang> ogra:  sudo debootstrap --variant=buildd hoary chroot/
<sivang> I: Retrieving debootstrap.invalid_dists_hoary_Release
<sivang> E: Failed getting release file http://ftp.debian.org/debian/dists/hoary/Release
<ogra> sivang: now you are missing the archive ;)
<ogra> my IRC line is wrapped....
<sivang> ogra: working.thanks
<ogra> hmm, it might be because the wiki adds this odd little globe graphics in the line....did you copy and paste from the wikipage before ?
<ogra> i changed the layout to a better copy and pasteable format
<ajmitch> I should setup a hoary chroot/pbuilder setup on my sid box
<ajmitch> there was something on the wiki about that somewhere
<ajmitch> can't find it now :)
<sivang> ogra: I: Base system installed successfully.
<ogra> yup
<ogra> ajmitch: https://www.ubuntulinux.org/wiki/DebootstrapChroot
<ajmitch> ogra: I'm sure there were other instructions along with that
* ajmitch looks over the page
<ogra> https://www.ubuntulinux.org/wiki/DeveloperResources
<ajmitch> and I was wanting something for sid
<ajmitch> which is what the wiki had, iirc
<ajmitch> the debootstrap line requires the hoary debootstrap scripts to be installed
<Nafallo> ajmitch: those are copyable ;-)
<ogra> ajmitch: there is another page, youre right:http://www.dina.dk/~abraham/religion/vi-music
<ajmitch> the use of apt-proxy or similar will have to be mandatory for me :)
<ogra> oops, wrong url
<ajmitch> heh
<ogra> https://www.ubuntulinux.org/wiki/ArchitectureBootstrapping
<sivang> ogra: gcc-3.3 ??
<sivang> ogra: in the chroot 
<ajmitch> now that looks nice & evil;
<ogra> ajmitch: but i think dropping the archive url in the end of the line and changing hoary to sid sould work too
<ogra> from the Debootstrap wiki page ....
<ajmitch> I've already got a pbuilder chroot setup for building sid packages
<ajmitch> so I guess I can get another one setup for warty & then upgrade that to hoary or something :)
<moquist_> sivang: hi!  I see you said hi a long time ago.  :)
<__daniel> brb
<rcaskey> ogra: is warty going to ship with esd as default?
<wasabi_> warty shipped awhile ago. ;)
<rcaskey> err hoary
<rcaskey> it's 4:48 here, you know how it is ;)
<T-Bone> fabbione: ping?
* rcaskey bangs head o wall
<thully> hi - how are the dailys looking today?  are they broken in any severe way?  is it advisable to use these or array 2?
<rcaskey> array3 is out
<thully> that's what I meant - array 3 - my bad
<rcaskey> dunno then
<rcaskey> btw thully, can you just substitute in array3 or array for hoary?
<thully> ? - array 2 and array 3 are milestone snapshots of hoary
<rcaskey> yeah, I was wondering if there was a way to track the milestones
<thully> no - you track hoary - the milestones are just cleaned-up daily builds for installation
<rcaskey> yeah, but they are cleaned up ;)
<T-Bone> lamont_r: ping?
<lamont_r> ack
<rcaskey> usplash debs are due next week right?
<lamont_r> Kamion: you still around?
<lamont_r> amu?
<amu> yep?
<lamont_r> how was the amd64 livecd?
<amu> lamont_r: Kamion left, i didnt got an image :( 
<lamont_r> curses.  I'm competing with another downloader.  only 70Kbytes/sec
<lamont_r> oh
<lamont_r> bummer
<lamont_r> mdz about?
<mdz> yep
<rcaskey> lamont: isn't that linked to in osnews' story
<mdz> beating on #5701
<thully> how good are today's live CDs for i386?
<thully> I'll download today's build if it doesn't sound like it's extremely broken today
<amu> lamont_r: there's still time for a new download :) 
<lamont_r> mdz: wanna kick a livecd build for us?
<lamont_r> latest cloop image rsync'ed 17MB, with 10 packages diff in the manifest...
<mdz> no shit?
<lamont_r> not sure we can get much better than that without dinking around with timestamps in the fsimage
<mdz> how did you manage that?
<mdz> did you do the zlib thing?
<thully> there won't be any new builds in the next hour, right (if there will be, I'll hold off on burning the current one)
<mdz> lamont_r: sure, I can do one right now
<mdz> lamont_r: a bit later, when I'm finished with busybox, I'll need a set of d-i builds, followed by live CD builds (but no new cloops)
<lamont_r> woot
<wasabi_> Is anybody here named Celso Pinto? 
* lamont_r waits for mdz to say the images are done to do the download
<thully> lamont_r - are you talking about live or installer builds?  because if there is a new build coming I'll hold off on burning the current build
<lamont_r> mdz: funny thing was that the 4k:4k version was 127MB of rsync,while te 1024:64k was 17MB...
<lamont_r> livecd
<lamont_r> thully: although mdz is going to burn a new install cd in a while as well.
<thully> will it be ready in next 45min-1hr?
* sivang is also waiting for the new live cd to test the usb bug fix.
<thully> I have to leave for home soon, and I only have dial-up there (here I can nab an ISO faster than a kernel .deb at home)
<mdz> should be ready in <10
<thully> I heard a timezone fix should be in - and want to test it
* sivang promised to make mdz happy by teting the livecd ;-)
<mdz> thully: a time zone fix would probably require a new installer build, which I don't think has happened yet.  did Kamion tell you that?
<thully> the fix is in base-config - check bug 2416 for details
<mdz> lamont_r, thully, sivang: new live CD builds are up
<mdz> 20050121.1
<mdz> ah, ok, if it's in base-config, it only requires a new cloop image from lamont
<mdz> which I think he made recently
<thully> I'm talking about installer cd for the timezone fix
<lamont_r> Setting up base-config (2.61ubuntu13) ...
<lamont_r> is the last one I built, some 4-5 hours ago
<lamont_r> or rather, is what's in the last cloop fs that I built
<T-Bone> lamont_r: has the "libunwind" bug been fixed in that one?
<thully> yep - that's the one that fixes it - is this on the installer build?
<mdz> hoary-install-i386.list:/pool/main/b/base-config/base-config_2.61ubuntu12_all.deb
<lamont_r> T-Bone: should almost certainly be...
<mdz> ^^ that's what the latest install CD has
<T-Bone> lamont_r: gonna test then.
<thully> no, then
<T-Bone> Kamion: ping?
<thully> ubuntu13 has fix
<lamont_r> mdz: btw, there's a risk to amd64 livecd because of partimage...
<lamont_r> partimage is PaS'ed on ia64,alpha right now (debian), with a comment about it being b0rked on 64-bit....
<lamont_r> so either ia64 should try it again, or amd64 is b0rked.
<Mithrandir> is there something _really_ fucked with archive.u.c atm?  I'm getting approximately 5k/sec from it.
<mdz> Mithrandir: maybe the cd images mirroring or something?
<sivang> mdz: what's the rsync url? (i recall it differs form the vhost of the website)
<mdz> the I/O on some of those servers is horrific
<Mithrandir> mdz: I don't know, it
<mdz> sivang: rsync://cdimage.ubuntu.com/cdimage/daily-live/...
<sivang> mdz: thank you
<Mithrandir> 's just _dog_ slow and wondered if anybody else saw it
<sivang> Mithrandir: the archive?
<lamont_r> although it's maxed out on rsync clients right now...
<lamont_r> dammit
<sivang> Mithrandir: I updatted my chroot, was a _pain_
<lamont_r> OTOH, I know that it won't rsync for crap this download...
<Mithrandir> sivang: I'm running dist-upgrade and getting 8k/sec now, yes.
<sivang> Mithrandir: got B/s at the end...
<sivang> :-/
<T-Bone> Mithrandir: you're sorta lucky, i just timeouted on archive.u.c
<Mithrandir> ok, so it's not just me.
<thully> I've got a snails-pace download also 
* lamont_r is getting 6KB/s on a wget of the cdimage
<maswan> Well, good thing there are mirrors, bad thing that the mirrors are not perfectly up to date?
<T-Bone> this is just happening. I downloaded 200M 20mn ago at 540kB/s avg
<Mithrandir> ooh, it's 10k/sec now.
<sivang> lamont_r: you're not rsyncing?
<sivang> @ERROR: max connections (15) reached - try again later
<sivang> ergh
<lamont_r> yeah - that'd be why sivang 
<sivang> ok, then wget it is..
<lamont_r> mdz: I don't suppose the livecd is bt-able, eh?
<amu> lamont_r: i think, it make no sense atm 
<sivang> 8.57K/s erg..
<mdz> lamont_r: ask thom
<sivang> 1.64K/s
<lamont_r> I was getting 60K/s for a several seconds there...  now1.8
<wasabi_> haha i had the same problem.
<wasabi_> i was trying to figure out if our inet was messing up
<lamont_r> hell - I could fetch it at home this quick...
* Mithrandir updates his local mirror instead.
* lamont_r looks at the topic, sees that mdz is to blame for DDoSing cdimage.u.c
<Mithrandir> it should probably go on another machine?
<Mithrandir> or be torrented?
<lamont_r> it should tget torrented
<lamont_r> but, ENOTHOM
<T-Bone> heh
<sivang> 41.09K/s
<sivang> starting to rise up..
<lamont_r> bouncing between 15 and 70
<lamont_r> wow! it actually said 113K/s there for an instant. :-)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion and support on #ubuntu | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<mdz> that was yesterday
<Mithrandir> it's faster again now
<lamont_r> mdz: to late, dude. :-)
<lamont_r> yeah, much faster
<lamont_r> wot
* T-Bone edits xchat2 source to remove that fsckin ctrl-a==ctrl-q shortkey
<lamont_r> what you hitting ctl characters for anyway??? :-)
<T-Bone> lamont_r: get back to the beginning of the line, as it should: ctrl-a / ctrl-e :P
<lamont_r> T-Bone: see - that's why I don't use emacs
<T-Bone> lamont_r: neither do I. I *hate* emacs :^)
<T-Bone> lamont_r: pretty much as I *hate* perl :)
<T-Bone> lamont_r: gives you the picture, heh? :^)
<elmo> gtk-key-theme-name = "Emacs"
<elmo> T-Bone: ^-- add that to ~/.gtkrc-2.0
* T-Bone does
<T-Bone> doesn't work
<elmo> sure it does
<mdz> lamont_r: what was the secret to getting the ext2 image more rsyncable?
<T-Bone> elmo: what it's supposed to do?
<mdz> lamont_r: was zeroing the empty blocks with partimage the ticket?
<lamont_r> mdz: amazing foo, thanks
<lamont_r> mdz: partimage
<mdz> neat
<lamont_r> well, that and rsyncing over the top of the previous image
<mdz> and cloop took care of itself, I guess
<lamont_r> which either (a) necessitates partimage, or (b) makes the cloop grow over time
<lamont_r> yeah
<mdz> are you doing the rsync-inplace-from-previous-image trick too?
<lamont_r> had to
<mdz> ah, yes
<lamont_r> that was the real trick.  partimage just cleans up the trash
<lamont_r> Mithrandir: you gonna grab one of them thar new amd64 livecd images and tell me if it even boots?
<Mithrandir> lamont_r: sure, I can do that
<mdz> lamont_r: locale generation looks good now
<sivang> 185.83K/s ah back up!
<mdz> speeds up the boot by several seconds
<sivang> mdz: it didn't general he_IL.UTF8 when I tested it llast time..
<sivang> generate even
<lamont_r> mdz: that'd be because it actually _runs_ locale-gen
<mdz> sivang: I find that difficult to believe
<mdz> lamont and I are talking about the pre-generated locales
<mdz> but generating them on-demand has always worked
<lamont_r> sivang: it pre-generates en_{US,GB,ZA},UTF-8
<sivang> mdz: just before preparing the live session, well, I only chose "hebrew" as the language in the d-i menu.
<sivang> lamont_r: maybe something else is needed to trigger generating other locales?
<sivang> I mean, on the user side.
<mdz> sivang: did you actually see that the locale wasn't generated, or are you assuming?
<mdz> perhaps something else went wrong
<mdz> was the locale set in /etc/environment properly?
<sivang> mdz: I watched the "generating localeles" message on the debug console or the other consoel that allows me to see what's happening while "preparing for live session".
<sivang> mdz: I will check that with the new iso.
<lamont_r> mdz: the pre-gen populates /etc/locale-gen (or such) before the install, and runs locale-gen after- dunno if that's affecting the postinst..
<mdz> sivang: and it said "Generating locales..." and your locale didn't appear in the list?
<mdz> lamont_r: d-i goes in and manhandles it anyway
<sivang> mdz: nope
<mdz> getting 3MB/sec on amd64 iso download
<lamont_r> back to 100K/s here - must be someone else downloading
#ubuntu-devel 2005-02-02
<sivang> I'm getting 200Kb/s now :)
<mdz> seems to be getting a poor transfer rate on the blocks it downloads, but isn't downloading many
<lamont_r> ah, ok
<mdz>    564506624 100%    2.24MB/s    0:04:00  (2, 33.3% of 9)
<sladen> 20Mb average isn't bad...
<sladen> what link do you have there?
<sivang> mdz: pheee 
<mdz> sladen: 3mbit
<sivang> man
<mdz> yay, the busybox init fix took
<ogra> mdz: i get 68KB/s on amd here (line is capable to do 90 which i noramlly get from c.u.c)
<mdz> i386 download is getting a more non-rsync transfer rate
<ogra> mdz: how did you track it in the end ?
<ogra> init that i
<ogra> s
<mdz> ogra: many slow test cycles
<ogra> hmm with a lot reboots i guess....
<sladen> mdz: do you find an easy way to differeniate kernel threads?
<mdz> lamont_r: is this a delta against 20050121 or 20050120.1?
<mdz> I'm not sure what I had locally when I started the rsync
<lamont_r> mdz: the change in cloop generation is in 20050121.<largest int>
<lamont_r> for i368 that's > 10... for the others, it should be .1 or so
<mdz> sladen: we stole code from sysvinit
<T-Bone> are popcon stats available somewhere, or is it just 'not yet enabled' ?
<lamont_r> down to < 60 minutes
<__daniel> re
<__daniel> thanks ogra :-)
<ogra> __daniel: doe sit work now ?
<__daniel> ogra: finally, yes :-)
<ogra> hreat :)
<ogra>  /h/g/
* __daniel sees the headline of tomorrows newspaper: study proves: kernel-updates waste valuable time of your life
<ogra> mdz: i understood that also non debina packages should have a ubuntu version number, sorry, next time i'll regard it
<ogra> __daniel: ask fabio :)
<ogra> __daniel: he can tell you about kernels and how they eat your time.... :)
<__daniel> now at least i know about /etc/iftab
<__daniel> and found out that dhcp is capable of netbios stuff
<Hwolf> Did any if you guys have any trouble with the repro's today?
<lamont_r> __daniel: what's in /etc/iftab?
<__daniel> lamont_r: a table telling which ethX has which MAC/or_other adress
<ogra> lamont_r: its a table that adds the ethX device to a specific MAC
<lamont_r> ah, cool
<lamont_r> glad that finally got in there.. (yeah, sometime ago, I'm sure..)
<__daniel> lamont_r: after the reboot, my router kept on confusing network devices
<ogra> lamont_r: remember, with 2.4 you had to regard the load order of the modules ....
<__daniel> so thanks to ogra, i'm safe now :-)
<lamont_r> ogra: or write scripts that figured out what the kernel had done to you...
<ogra> yup :)
<lamont_r> Ifrename always use the first matching mapping starting
<lamont_r>        from  the  end  of  iftab, therefore more restrictive mapping should be
<lamont_r>        specified last.
<lamont_r> that could use some change...
<sladen> win 45
<ogra> lamont_r: this whole paragraph sounds strange (even above this sentence)
<lamont_r> my daughter just decided to write a short story with her spelling words...
<lamont_r> yes
<lamont_r> but that sentence really wants to say 'always uses the last matching mapping...'
<ogra> lamont_r: the two sentences seem not related at all....probably worth a bug
<lamont_r> ogra: feel free
<ogra> heh
<ogra> ogra@honk:~ $ dpkg -S /etc/iftab
<ogra> dpkg: /etc/iftab not found.
<ogra> hmm, what may generate it ?
<mdz> ogra: netcfg creates it
<Riddell> what version number should I use in debian if I've already put a package in ubuntu versioned -1ubuntu1
<sivang> mdz: are there any set of documents appropriate for shipping on the cd? docteam ubuntu user guide for example?
<ogra> mdz: hmm, but it has a manpage that is wrong....ha, found it ogra@honk:~ $ dpkg -S /usr/share/man/man5/iftab.5.gz
<ogra> ifrename: /usr/share/man/man5/iftab.5.gz
<mdz> sivang: I should ask you, you are on the documentation team, and not me ;-)
<sivang> mdz: I say we do! However, that should probably be in the limis of the diskspace on the cd.
<crimsun> Riddell: assuming -1 is in Debian? -2 would be the dch -i; then you'd make -2ubuntu1, and so forth.
<Riddell> crimsun: nothing is in debian
<sivang> I'd opt for having all the ubuntu specific docs in, so someone without net access could also learn about the system - again, in the space constraints.
<lamont_r> son of bitch. must kill pitti
<mdz> sivang: if you have enough documentation that we need to worry about space, then that is a good problem to have
<lamont_r> 700 files to mirror???  gag me
<crimsun> Riddell: if the packages are identical aside from branding differences, I say -1.
<sivang> mdz: hehe, ok, I'll tell the gang that you said to fill up the remaining space with docs :)
<Riddell> crimsun: ok
<crimsun> Riddell: normally they're -0ubuntuX until they're in Sid, then -1ubuntuX and so on
<lamont_r> crimsun: the logical successor to -1 is -1ubuntu1, not -2ubuntu1
<lamont_r> debian's -2 should  be newer
<crimsun> lamont_r: that's what I'm saying.
<ogra> sivang: make an mpeg screencapture tutorial for all functions of the desktop if you dont know how to fill the space ;)
<crimsun> lamont_r: otherwise he'd have to make a -2 for sid and then a -2ubuntu1 for hoary, no?
<lamont_r> if he was doing something for sid, then he'd bump the debian version.
<lamont_r> and merge the ubuntu diff into that
<crimsun> lamont_r: according to him, currently there's no sid package of it
<lamont_r> then probably -0ubuntu1 and start counting
<crimsun> lamont_r: yeah, that was my reasoning as well, except there's already a -1ubuntu1 ;)
<lamont_r> of course, if it could go into debian (even experimental), that'd be the preferred method
<lamont_r> because if you wind up with a diff orig.tar.gz in debian, then you wind up with 1ubuntu1-1ubuntu1 later. :-(
<lamont_r> grumble. back down to 50K/s
<lamont_r> 15 minutes remaining... woot
<lamont_r> crimsun: after -1ubuntu1 is -1ubuntu2
<crimsun> lamont_r: so he should make -2 for experimental/sid, then a -2ubuntu1 for hoary, correct?
<ajmitch> it's not too hard to upload -2 as the first release to sid
<lamont_r> ah, if he's sending something to sid and he likes himself, then yes... -2 for sid and -2ubuntu1 for hoary
<crimsun> ajmitch: right.
<lamont_r> and just remember the -sa for sid
<Hwolf> I've been having problems with the repostories all day, has anyone else noticed anything?
<ajmitch> nope
<ajmitch> I've been downloading fine
<lamont_r> Hwolf: if you mean bandwidth being sucky, then yes - others have noticed it although it appears happier now
<Hwolf> W: GPG error: http://security.ubuntu.com hoary-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<Hwolf> That, and package not found, etc.
<crimsun> hoary-security?
<lamont_r> hoary-security doesn't have anything (and won't until at least april, hopefully much later...)
<lamont_r> crimsun: it's created, but empty
<crimsun> lamont_r: right.
<ajmitch> lamont_r: I don't notice lack of bandwidth from the server ,since I have none at my end :)
<lamont_r> ajmitch: I only notice it when I drive 15 miles to town to get bandwidth... :-)
<Hwolf> Hey ajmitch, have you gotten any hint on what could cause the gnome volume applet to mess up my audio?
<ajmitch> Hwolf: changes alsa settings? 
<ajmitch> I don't know
<ajmitch> on my sid laptop, restarting udev causes the volume settings to be restored
<Hwolf> If I open gnome-volume-control it breaks the currently playing audio and all I hear is static, if I reselect the card, or reopen the tool, things go back to normal.
<ajmitch> interesting
<lamont_r> ajmitch: firing up the panel and switching back to alsa fixes it... no clue as to cause
<ajmitch> gnome-volume-control uses gstreamer as backend now, right?
<Hwolf> ajmitch: It should
<ajmitch> sigh, seems that a LUG machine that friends run just got rooted
<ajmitch> great way to spend a weekend :)
<Hwolf> ajmitch, consider spending the weekend at the university cafeteria working on a business plan with a monday-4pm deadline.
<ajmitch> oh that's fairly usual for students
<ajmitch> except it's more spending the weekend in the basement lab coding for me
<Hwolf> *g* I've put in 15 hours on the plan in the last 4 days, and we still need 20% of it. 
<mdz> lamont_r: still here?
<lamont_r> yeah
<Hwolf> 3 people are writing, and i am typing it into a single cohesive project, editing and such. I feel braindead. :-)
<lamont_r> 4 min eta
<lamont_r> kids would like to go home from the coffee shop though...
<lamont_r> mdz: wassup?
<Hwolf> lamont_r, here in holland, you don't let kids into coffee shops. :-)
<ogra> hehe
* lamont_r wonders if/when daniels is going to split xorg source up, so that it's less than 270MB/upload
<lamont_r> Hwolf: yeah - there are a couple of other kids in evidence, but mostly considerably younger than mine...
<daniels> lamont_r: it was going to be hoary, but I got overruled on that one.  ho hum.
<lamont_r> daniels: any planned need for -12?
* Hwolf thinks daniels would rather do that either when xorg goes modular, right?
<daniels> lamont_r: yeah
<daniels> Hwolf: it's already moving modular
* lamont_r sighs.
<lamont_r> this week, or next?
<daniels> lamont_r: this weekend
<amu> daniels: hint dbus-qt :) 
<daniels> amu: yeah :)
* lamont_r makes a note to snarf bandwidth somewhere
<Hwolf> daniels, can you tell me how to get xvid working with the fglrx driver? I've tried, but had no luck.
<daniels> lamont_r: you could just ignore *6.8.1-1ubuntu12* for a while
<daniels> Hwolf: dunno, sorry, don't use binary drivers myself
<mdz> lamont_r: going to upload busybox-cvs shortly
<Hwolf> daniels, cool. 
<daniels> i've used fglrx for about 10min to make sure it worked, and nvidia-glx for about an hour to debug a weird problem
<mdz> lamont_r: need to get those changes into a d-i build
<lamont_r> mdz: OK.
<lamont_r> gonna make :30, or do I have an hour?
<Hwolf> daniels, the problem is, at this moment you can't use the fgrlx drivers out-of-the-box with apps like totem or tvtime.
<daniels> Hwolf: hmm ... there's probably an option about picking the gl or xv overlay
<mdz> lamont_r: it's on its way up now
<mdz> and my clock shows :30
<lamont_r> daniels: if I want good 3D 24-bit double buffered video,what card do you recommend
<Hwolf> daniels, i've searched, but can't find it. And anyhow, it should be standard, right?
<lamont_r> DC shows mostly after :30
<daniels> lamont_r: 3d video?
<daniels> Hwolf: not really, fglrx has its own wacky options
<daniels> including one which is a bitmask about capabilities
<lamont_r> which means source will snap at :03, and binaries will be there at :33.. d-i should be available shortly thereafter
<lamont_r> meaning I have to be at the computer at :33
<lamont_r> daniels: s/video/graphics/
<lamont_r> some sort of accelerated 3D engine, etc, etc.
<lamont_r> oh, and under $200
<lamont_r> US
<lamont_r> :-)
<daniels> lamont_r: i got my radeon 8500 for $us20 off ebay -- very good card
<daniels> i mean, it probably isn't too shit hot on hl2, but yeah, it generally keeps up quite well
* lamont_r makes a note
<daniels> if you can find a radeon 9100, even better
<daniels> the 9200 is flaky and I dislike it, ditto 9250
<lamont_r> ok.
<daniels> and anything above that requires fglrx for 3D
* lamont_r runs so he can buzz the store on the way home.
<Hwolf> daniels, i've had a 9200se for a year, and it's the latest supported card for 'ati' Has always worked fine, specially with ubuntu
<lamont_r> mdz: if you _DID_ make :33, please phone/txt msg me and I'll hussle, otherwise should be back on at about :15 or :20
* lamont_r flees
<mdz> lamont_r:   79 N T Jan 22 Ubuntu Installe (0.3K) busybox-cvs_20040623-1ubuntu10_source.changes ACCEPTED
<lamont_r> is that from :35 or :30?
<mdz> Date: Sat, 22 Jan 2005 00:30:02 +0000 (GMT)
<lamont_r> sigh.  you won
* lamont_r will hussle
<daniels> Hwolf: i dislike the entire concept of the rv280 chipset, and the 9200 has had a lot of weird problems
<Hwolf> btw: Is anything planned to simplify using an rp-pppoe connection with ubuntu? Last time I tried it took me 3 days to get the network going here?
<Hwolf> daniels, I'm starting to dislike ATI in general, they spend more time doing marketing than coding drivers, if you ask me. 
<Hwolf> I got around setting up ppp this time by buying a router, but here they sell a lot of cheap-ass adsl connections which come with the modem integrated in a usb-stick, so putting in a router is not an option.
<daniels> Hwolf: unfortunately, for open drivers, all you have is ati and i8xx for halfway-modern hardware, and i8xx relies on often incredibly buggy VBE implementations to program modes
<daniels> (my laptop has an i8xx, my desktop has a Radeon)
<Hwolf> daniels, unfortunatly, my next mobo is not going to be agp, so i'll have to move closed-source. :-S
<daniels> Hwolf: mmm, yeah.  i've got a PCIE motherboard (other parts on order), so it's going to be closed-source for 3D.
<daniels> (that being said, the 3D stuff I want to play is closed-source, so I've already taken that hit)
<Hwolf> I've got a new-year resolution of not installing windows at all this year. I use it at school and at my parents, that's enough. However, i've got one of the greatest games in history lying on top of my monitor, and there is no way in hell that winex will ever support it. :-S
<sjoerd> easy solution, don't play games 
<Hwolf> I've been using mostly ubuntu since the release of warty, but I haven't played a game exept majhong since december. :-S
<Hwolf> That's the longest i've been without playing games since I was 11, i think.
<sjoerd> the last time i seriously played a (proprietary) game is more then 5 years back
<sjoerd> or more..
<Hwolf> It's a good way to get rid of the addiction.
<Hwolf> All I want right now is to see hoary play a dvd out of the box. :-S
<sjoerd> if you want to buy games, buy a console, much better :)
<Hwolf> gstreamer made some progress, I can now play a dvd in totem-gstreamer. I don't have sound tho.
<sjoerd> and no i don't have one..
<Hwolf> sjoerd, I'm a strategy-gamer. That doesn't go with consoles.
<sjoerd> the problem is the patent stuff and the gray legal area...
<sjoerd> Hwolf: point
<Hwolf> I know the problem. I've considered trying Yole. They ship patented stuff. Based in Russia. :-D
<daniels> mjg59: http://www.ubuntuforums.org/showpost.php?p=52998&postcount=12
<daniels> sjoerd: no halflife 2? :P
<ajmitch> Hwolf: apt-get install freeciv :)
* sjoerd didn't even know that there was a sequal
<sjoerd> fps make me sick anyway
<sjoerd> daniels: how's with the dbus qt bindings? any plans on them 
<sjoerd> more and more people start asking
<Hwolf> ajmitch. I'd rather see something like the total war series. :-)
<jdz_> Hwolf: Check out Battle for Wesnoth, it's in universe.  Hoary's version is much better (newer)
<Hwolf> Whooh. I feel good. I'm running a pyhton2.3-less system. 
<Hwolf> jdz_ I did. It was good for an hour.
<jdz_> Hwolf: *laughs* okay.
<ajmitch> Hwolf: and what do you have against python2.3?
<Hwolf> jdz_ The problem is, once you've seen a squad of armoured war-elephants march through a few units of legionaires, 2d just doesn't cut it anymore
<daniels> sjoerd: either today or tomorrow
<Hwolf> ajmitch, nothing, exept that it's 70mb and 50 packages. :-)
<daniels> sjoerd: heh, I have a PS2.  both that and San Andreas aren't exactly open source/open platform.
<sjoerd> daniels: cool, lemme know then i'll put it in the debian package too
<daniels> sjoerd: will do
<sjoerd> if it works out for ubuntu then it should be fine for unstable too....
<sjoerd> daniels: consoles aren't general purpose machines, so i don't care as much about being open..
<sjoerd> and if you want to do proprietary games your already lost... No need to make it worse by forsing more and more closed stuff on you once open/free system :)
<Riddell> could someone explain what this means (trying to work out why a package hasn't been built "universe/sound/kdemultimedia_4:3.3.2-1ubuntu4 by buildd+crested [optional:out-of-date] "
<daniels> Riddell: needs to be built, although I'm not sure why crested has claimed it
<daniels> Riddell: how long ago did you upload it?
<daniels> sjoerd: heh.  at the same time, I want it to look nice, which sort of precludes r2xx. :P
<Riddell> daniels: amu uploaded it on the 15th
* sjoerd has all nice and free drivers on his rv350
<Riddell> "universe/sound/kdemultimedia_4:3.3.2-1ubuntu4: Building by buildd+crested [optional:out-of-date] "  is that the build-depend on arch-all which depends on arch-specidic problem
<sjoerd> it's not that thare are non-free drives i could use, but still :)
<daniels> sjoerd: sure, but not with 3D acceleration
<daniels> i mean, I could run free drivers on my r423, and I will almost all the time
<daniels> but when I'm playing HL2 ... not really
<sjoerd> as said, no games, easy solution :)
<daniels> sjoerd: heh
<mdz> daniels: any idea why ctrl+alt+f1 doesn't work in X anymore on the live CD?
<mdz> it used to
<daniels> mdz: hm.
<daniels> mdz: no
<daniels> mdz: i'll download the latest live CD tonight
<mdz> daniels: lamont has made it rsyncable
<mdz> I wonder if it is possible to combine rsync and torrent
<mdz> use rolling checksums with bittorrent
<daniels> mdz: in any case, I haven't got a seed
<daniels> so I'll grab the full tonight and add rsyncing it to my mirroring script
<mdz> there are no torrents for the hoary live CDs yet
<daniels> terminology collision
<daniels> seed as in, pull it the first time
<daniels> so rsync is more useful than wget
<Hwolf> daniels, will usplash make Hoary?
<Riddell> Hwolf: ask sladen 
<Hwolf> Riddell, It's 2 am, and I wanted some good news before going to bed. ;-)
<Hwolf> omg. It's saturday already. In 10 hours i'll be rewriting business plans again. :-)
<Hwolf> Good night to you all. 
<mdz> daniels: if you don't have a seed, wget is preferable
<daniels> mdz: right
<lamont-away> mdz: so you're gonna be ready at :33, or did you not upload yet?
<mjg59> daniels: Yeah, it switches off the backlight (as does vbetool dpms off), but it doesn's solve the power consumeption issues
<daniels> mjg59: oh, hum
<daniels> arse
<mjg59> (V. V. Drunk)
<daniels> mjg59: it is, after all, saturday morning
<daniels> no better time
<mjg59> I got dragged to a gay bar
<mjg59> (Let's start a nuclear war)
<mjg59> 1.5 bottles of wine, 3 pints, some spirits. Not too bad on the grand scale of things.
<mdz> lamont: everything I need is uploaded
<mdz> lamont: last thing was at 0054 UTC
<lamont> so it should be in the archive now, yes?
<mdz> in theory
<mdz> but it isn't
<lamont> gotta give it a little time to mirroor
<mdz> build log is there
<lamont> what state does Lists say?
<mdz> where is Lists?
<mdz> ah, buildLogs/Lists
<mdz> utils/busybox-cvs_20040623-1ubuntu10: Installed by buildd+mcmurdo [-:out-of-date] 
<mdz> misc/casper_0.26: Uploaded by buildd+rockhopper [-:out-of-date] 
<lamont> so casper isn't, but busybox-cvs is
<lamont> assuming those are the right versions
<lamont> Jan 22 01:10:01 buildd-mail: casper has been installed; removing from upload dir:
<lamont> \
<lamont> that was 0.26
<mdz> those are the right versions
<lamont> hrm.. the logs aren't necessarily mirrored quite that quick... let me check.
<mdz> casper 0.26 and busybox-cvs 1ubuntu10 are the ones I want
<lamont> casper is arch: all, yes
<lamont> ?
<mdz> yes
<lamont> so you want it to be missing from Lists/hoary.all.i386
<lamont> and it is.
<lamont> just not mirrored yet
<lamont> launching d-i builds everywhere
<mdz> thanks
<T-Bone> lamont: will you be hanging around on IRC tomorrow?
<T-Bone> lamont: i've finished salvaging my CVS stuff and can't do much hacking tonight (2:40AM), but will certainly test and debug ia64 stuff by tomorrow
<lamont> T-Bone: dunno what the plan is for tomorrow...  afternoon (>7UTC) is pretty committed, for at least a few hours, earlier than that is possible
<T-Bone> ok cool
<lamont> wife has a full day, daughter #1 has a full day, daughter #2 is gonna have to find something to entertain herself with.
<T-Bone> lol
<lamont> me, I may just go download the rest of my aching mirror
<lamont> 271 files to go
<T-Bone> lamont: want me to play the baby-sitter? :^)
* T-Bone ducks quickly!
<lamont> don't think you could fly here that quick
<T-Bone> hehe
<lamont> actually, not much babysitting involved
<lamont> mdz: so you just need new d-i b its, not a new tarball?
<lamont> s/tarball/rootfs/
<mdz> lamont: correct
<mdz> hell
<T-Bone> lamont: i'll dl last iso tomorrow and hope that everything has been merged so that I can get the install to complete :)
<mdz> elmo isn't around to byhand them, though
<T-Bone> gnight all
<mdz> so I don't suppose there's any point
<lamont> mdz: I have the tarballs
<lamont> or will have
<mdz> it would be nice if we didn't need N people all to be present in order to make this work :-/
<lamont> mdz: if you had a reasonably close mirror, you could always start building the SoCal edition...
<mdz> no point in doing the d-i build, I guess
<lamont> already running
<lamont> and no point in killing it - the cleanup is annoying
<lamont> so ubuntu-desktop and ubuntu-base install on hppa.  of course that means _ABSOLUTELY_NOTHING_
<lamont> mdz: what would you think of having the binary build of ubuntu-meta notice that base-$arch is missing, and use the Packages files in /var/apt/lists to go with the seeds to build something for the bastard step-child architectures?
<daniels> lamont: if you don't need them, exclude xserver-xorg-dbg and xlibmesa-dri-dbg
<daniels> lamont: there's a win there of 50mb per package per arch
<mdz> lamont: I don't follow
<lamont> yeah - that's most of the half of the 270.. :-)
<mdz> lamont: why not do a source upload?
<lamont> mdz: because the next source upload would trash it.
<mdz> the decision to _not_ do anything funky like that during the binary package build was explicit
<lamont> or would it?
<mdz> the only thing which changes the lists in the source package is the update script
<lamont> so the answer to my question is that you would strenuously object.  got it.
<mdz> the binary build does nothing but gencontrol substitutions
<lamont> what about making it FTBFS if {base,desktop}-$arch are not present?
<mdz> it should work unchanged for all architectures in the main archive
<mdz> hmm, it doesn't already do that?
<lamont> no.  it builds a package with no Depends
<lamont> which is cute but unhelpful
<ogra> no pcmcia networking for me on the live cd today :(
<mdz> failing would be preferable
<lamont> mdz: OK.  will make the change
<lamont> s/will/I will/
<mdz> ogra: did you do any troubleshooting?
<ogra> not yet.... its about 3am here....i'll do it tomorrow, but it detects fine, even dhcp detection is done in less then 2 seconds (normal) it seems to fail in the last stage
<ogra> the rsolv.conf contains my local dns entry, but there is no pcmcia device...../etc/init.d/pcmcia is missing as well, is this intentional ?
<lamont> ogra: which architecture?
<lamont> i386?
<ogra> amd64
<lamont> mdz: guess we want to have pcmcia packages in the rootfs, eh?
<lamont> Riddell: ??
<mdz> ogra: does it work during the first stage?
<mdz> ah, yes, it is
<mdz> so I think lamont is correct
<mdz> in fact I think I noticed that it was missing and forgot to email
<ogra> i havent pinged or switched consoles
<mdz> lamont: you'll want to be careful about the install though
<mdz> lamont: I've seen pcmcia-cs hang non-laptops if it starts up
<mdz> that's also going to be a problem for the live CD
<mdz> but we need to fix that anyway
<daniels> lamont: sorry
<lamont> s/non-laptop/no pcmcia/, yes?
<mdz> dunno, never saw a laptop without pcmcia
<lamont> daniels: 12 uploaded you say?
<ogra> mdz: i've seen that to on a desktop machine (pcmcia hangs)
<daniels> lamont: not yet, but about to.  and a l-r-m.  with a new orig.
<lamont> non-laptops can have pcmcia
<mdz> well, not one capable of running Linux
<lamont> daniels: life goes on
<daniels> (but l-r-m won't happen desperately soon, given the orig takes 45min to upload)
<mdz> I assume it's non-pcmcia
<mdz> I have a bug open in bugzilla about a Dell (go figure) which has this problem
<mdz> our new slogan should be "Ubuntu: don't buy a Dell!  kthxbye"
<daniels> heh
<daniels> mdz: at least it has PCI
<ogra> mdz: i think you dont need to focus on getting pcmcia for non desktops to work
<mdz> barely
<daniels> someone tried installing Ubuntu on an ISA laptop not long ago
<Riddell> lamont: ah, you're here
<lamont> Riddell: replying to your mail now
<mdz> I bet that fails spectacularly
<ogra> err, /desktops/laptops/ indeed
<ajmitch> hmm, /var is 50% full on my hoary box already
<ogra> mdz: i think it would have worked, but the lappie only had 32MB.....so the guy gave up after about 2 weeks of struggling...
<lamont> Riddell: sent
<ogra> mdz: the guy daniels is talking about....
* lamont brb
<lamont> rc  pcmcia-cs      3.2.5-7ubuntu6 PCMCIA Card Services for Linux
<lamont> I had it installed on my desktop at one point...
<daniels> mdz: quite spectacularly, yes
<Riddell> lamont: thanks
* Riddell sleeps
<daniels> mdz: it also lacked a cd-rom drive
<daniels> mdz: and had no netboot capability
<mdz> lamont: it usually works
<mdz> but sometimes doesn't
<mdz> d-i has a check it uses to decide whether to install pcmcia-cs
<mdz> I think init.d/pcmcia-cs should do the same
<mdz> and then we can install it unconditionally
<ogra> mdz: i can do more tests tomorrow morning if you like, any particular info i should collect additionally ?
<mdz> ogra: I think lamont is correct, and the problem is simply that pcmcia-cs is not installed
<mdz> ogra: please file a bug
<ogra> ok
<lamont> mdz: pointer to the logic?  and then I'll add it, upload, and update the package
<lamont> s/package$/livecd script/
<ogra> #5730
<ogra> night all
<thully_> hi - has anyone here been having trouble w/usb on the live cd?
<elmo> mdz: your lack of faith is disturbing - of course I'm around
<mdz> elmo: well, I hope you're at least drunk
<mdz> elmo: does that mean you'll process the d-i uploads?
<elmo> already done, they'll go out in the next cron.daily in 5 mins or so
<daniels> mdz: are d-i uploads that depressing?
<mdz> elmo: thanks
<mdz> elmo: 20041227ubuntu6.0.200501220, right?
<elmo> yeah
* lamont apologizes for the trailing 0
<lamont> "it's a feature"
<sladen> thully_: mdz thinks he's fixed it today.  Have you tried the latest build?
* mdz launches a live CD build
<mdz> the one that's building right now is the first one with the fix
<mdz> there is still a bug which breaks booting from a USB CD-ROM, though
<thully_> no - I'm on a slow connection now
<mdz> some udev/proc/something race
<thully_> No - i'm talking about using usb devices
<mdz> that's the one I fixed
<mdz> the one which remains has to do with booting from a USB device
<lamont> is xfree86 supposed to be in main?
<lamont> oh. nm
<lamont> that'd be warty-security hitting me.
<mdz> new live cd builds are up
<mdz> rsync is full, as usual
<mdz> lamont: I _think_ the pcmcia-cs check is in base-installer
<thully_> I tried an install, and looked at the part where the system asks about network cards
<lamont> ok
<mdz> nope
<elmo> mdz: can you fix the trigger scripts on little?
<thully_> One small change that would make it less confusing, especially for dial-up users, would be to move the "No network" option from the ethernet card configuration to the screen where you are asked to select a network card
<mdz> ah, yes i tis
<elmo> s/fix/alter/
<lamont> case "$ARCH" in
<lamont>         i386*)
<lamont>                 if [ -e /proc/bus/pccard/drivers ] ; then
<lamont>                         waypoint 1      install_pcmcia_modules
<lamont>                 fi
<lamont>         ;;
<lamont> esac
<lamont> that???
<mdz> elmo: yes
<mdz> thully_: my current feeling is that it should try to bring up each interface in turn, and if it fails, simply move on without prompting
<thully_> on the live CD or the install CD also? 
<mdz> at least the live CD, and maybe the install CD
<thully_> I heard from the upstream author of the TrackPoint patch (that at one point was in hoary) that a new version will be out soon which supports trackpoint scrolling.  can this be added to hoary?
<mdz> I need to get Kamion's opinion
<thully_> when it's ready
<mdz> thully_: it was removed because it broke normal PS/2 mice
<daniels> thully_: no, I told you as much in the bug
<mdz> so it cannot be restored unless that entire class of bugs is fixed
<thully_> well - I'll ask him if this was fixed in the latest version
<elmo> hmm, language-* is uninstallable.  neat.
<thully_> what was the exact problem - did it screw up PS/2 mice connected to a laptop with a touchpad, or all PS/2 mice?
<daniels> it would misdetect some normal PS/2 mice as being TrackPoints
<daniels> the moment any PS/2 patch (TrackPoint, ALPS, whatever) intrudes on other mice, it gets cut
<thully_> what caused misdetection, out of curiosity, (so I can pass this on to the author of this patch) 
<elmo> WTF
<daniels> thully_: the TrackPoint patch probes the mouse to see what type it is (as with all of these wacky patches), but gets it wrong in some cases as it's too wide as to what it includes
<daniels> elmo: ?
<thully_> OK
<mdz> elmo: for all values of *?
<elmo> mdz: oh, I dunno about rigourously 'all', but britney output is certainly chocker full of whining about it
<elmo> anastacia doesn't want to sync anything else tho.. am checking with a hoary chroot now
<thully_> I have a little question concerning the sound server - is polypaudio still planned for Hoary?
<mdz> thully_: according to jdub, yes
<mdz> if you're going to ask about releasing the sound device, please be patient
<thully_> OK - i realize that it makes no sense to fix something that will be irrelevant soon (as polypaudio is a different animal)
<thully_> another sound question - has ALSA been fixed in hoary?  it seemed to mute itself often a couple days ago
<elmo> hmm, the hoary chroot thinks the language-packs are installable
<elmo> oh,meh, it's all ia64.  clearly I need to go to sleep
<elmo> anyway, mirnyy is growing a cdimage mirror, it's already got daily-live/, if anyone's still struggling to get an update
<thully_> and caused me to go crazy looking for my volume control - as now it is hidden by default when the sound is completely set to 0
<elmo> mdz: can you change little to also pulse mirnyy, please?  for cdimage, I mean, it already does for releases
<mdz> is it in the rotation for cdimage.u.c?
<elmo> mdz: not yet, no
<mdz> elmo: if I read the script right, it already does
<elmo> [of course, while it's syncing at Gb across the LAN and saturating the RAID 5 with writes, it's performance won't be much better than auckland, but it'll finish in 10 mins or so I guess] 
<mdz> lamont: amd64 seems to be missing pre-generated locales
<mdz> lamont: other than that, it works fine
<mdz> lamont: excellent, in fact
<mdz> thully_: yes, that bug has been fixed
<mdz> you may need to dpkg-reconfigure alsa-base and select 'autosave always' if you installed from a bad CD
<elmo> night all
<mdz> night
<lamont> mdz: sadly...
<lamont> Error: sizeof(DWORD) != 4 (8)
<lamont> This version has been compiled with an uncompatible version of gcc.
<lamont> so, no, you don't have a new-style cloop on amd64
* lamont will have to remove things...
<lamont> elmo: just btw, partimage should be PaSed on amd64
<thully_> does the volume control applet still disappear when sound is completely muted?
* lamont updates debian PaS
<lamont> sent 164226 bytes  received 7638638 bytes  12802.07 bytes/sec
<lamont> total size is 549206016  speedup is 70.39
<lamont> mdz: looks like you missed an update, or one of the others was big
<lamont> mdz: so... decision time for amd64....
<lamont> do you want rsyncable images that grow until they don't fit on the CD?
<lamont> or do you want clean painful-to-rsync images?
<lamont> we could just nuke them every saturday morning, and let them grow all week...
<lamont> or 1st and 16th, or some such...
<lamont> thoughts?
<robertj> woah!
<robertj> I'm getting elements fly across my screen
<robertj> err flying, like things are being almost dragged and dropped in fast motion
<robertj> I see mimetype icons appear, drag, and disappear
<robertj> anyone heard of that happening?
<mpt> robertj, take the book off your mouse
<robertj> the cursor aint moving
<mpt> hmmm
<mpt> Got nothing resting on your Enter key?
<ajmitch> maybe your computer is possessed
<robertj> nope
<robertj> it's not happening now though
<mdz> lamont: let' talk about it tomorrow; need to go to dinner
<ajmitch> ok, time to test patched init for selinux..
<sladen> lamont: with  rsync --delete  the CDs shouldn't be growing.  partimage -e  is zeroing everything and the large image is catching defragmentation?
<lamont> sladen: amd64 has no partimage
<lamont> have a nice day, it says
<lamont> so, rsync --delete --inplace --no-whole-file, and file size changes may or may not result in some new,  non-zero unused blocks on the device.
<lamont> hence growth in the cloop
<sladen> lamont: scp cd.ext2 x86-box: && ssh x86-box partimage -e && scp x86-box:cd.ext2 .
<lamont> but it should be slow.. I'm inclined to just let it grow and see what the trend is first
<lamont> not really feasible in the current build environment
<lamont> nor should we be using other architectures to do our dirty work..
<lamont> I'm more inclined to spend a little love on partimage.
<lamont> if the growth rate becomes evil
<sladen> lamont: it shouldn't need much at all.  Is it a build failure, or has somebody expressly marked it as x86/ppc only?
<sladen> and/or 64-bit unclean
<lamont> <lamont> Error: sizeof(DWORD) != 4 (8)
<lamont> <lamont> This version has been compiled with an uncompatible version of gcc.
<lamont> runtime error
<lamont> and PaS on ia64/alpha (and now amd64 in debian...)
<sladen> hmmm.  Loving time, hopefully it shouldn't be too big---I don't think partimage is /that/ big
<ajmitch> yay, my machine doesn't boot now :)
<ajmitch> I think udev is not working with selinux yet
<lamont> doko around?
<ajmitch> udev+selinux doesn't work without tmpfs
* ajmitch updates bug report
<lamont> sladen: it may be kinda trivial...
<lamont> typedef bool BOOL; // variant size
<lamont> typedef unsigned char BYTE; // 8 bits
<lamont> typedef unsigned short int WORD; // 16 bits
<lamont> typedef unsigned long int DWORD; // 32 bits
<lamont> typedef unsigned long long int QWORD; // 64 bits
* lamont giggles
<sladen> D'oh!
<daniels> oh my god
<lamont> # if  ((~0UL) == 0xffffffff))
<lamont> now there's a cool hack
<sladen> #include <asm/types.h>
<daniels> anyone with more of a clue on #5646 would be appreciated
<sladen> lamont: probably breaks if you're cross compiling
* lamont will do the kewl ~0UL hack
<sladen> daniels: ./q3demo +r_gldriver libGL.so.1   I think.  Do you want me to start the laptop up and find out
<lamont> why does partimage's _clean_ target run configure, I wonder...
<ajmitch> they sometimes do that, to regenerate the makefile for some reason
<sladen> daniels: esdctl off ; ./q3demo +set r_gldriver libGL.so.1 ; esdctl on
<daniels> sladen: ah cool, thanks
<lamont> mdz: what's the magic for livecd?
<lamont> or does one just hit return and ignore the fact that it wqyw install type things?
<sladen> daniels: strange.  xorg under hoary works without that now
<daniels> sladen: word.  go me.
* lamont giggles at the "The system is going down NOW!!this console" line at the top of his screen
<lamont-live> moo
<lamont> mdz: we still don't take over swap?
<lamont> or is my laptop config wacko?
<lamont> my poor laptop has 3.9MB of free RAM once it boots
<lamont> (livecd that is)
<daniels> 'linux custom' is the right foo to get a ubuntu-desktop-less install, no?
<ajmitch> I believe so
<ajmitch> at least it was for the warty installer
<wasabi> so is ubuntu going to have a supported server install, you know, with all the same focus on Just Working as the desktop?
<wasabi> (like windows and os x )
<lamont> well, actually, almost 30MB, counting the buffer cache
<daniels> wasabi: we already have it
<daniels> ajmitch: right, for warty
<wasabi> no, i said "like os x and windows"
<wasabi> =)
<ajmitch> wasabi: I heard yes :)
<pixelmonkey> I have a question: is Hoary's menu supposed to be a bit broken right now, i.e. Applications menu icons not appearing
<ajmitch> pixelmonkey: it appears fine here
<daniels> wasabi: could you be less specific?
<pixelmonkey> ajmitch: is there a way I can get gnome to rebuild its menus?
<wasabi> daniels: i could.
<ajmitch> pixelmonkey: no idea, sorry
<wasabi> daniels: uis for server software, click to install apache, etc
<wasabi> integration between components...
<wasabi> like a default kerberos/openldap setup
<sladen> pixelmonkey: it's a race condition.  do  pkill -u $USER  and log back in
<pixelmonkey> I think my applications-all-users.vfolder-info is a bit broken or something, which is why my menus are insane... basically, under Applications there is a folder called "Applications" which has every app which was on my old menu, then I have all the typical categories without their icons and a "Settingsmenu" with settings under Desktop
<lamont> gui_text.cpp:88: warning: cast from pointer to integer of different size
<lamont> so much for simple
<lamont> 64-bit love for partimage is gonna actually take some work.
<lamont> 293 lines of warnings, most of them fatal
<ajmitch> rebuilding linux-image looks like it may take awhile
<jdub> morning dudes
<ajmitch> hi jdub 
<lamont> morning jdub
<jdub> what's a good hostname for an accesspoint/router?
<daniels> jdub: 'disruptive'
<jdub> haha
<daniels> (seriously, that's what my wrt is called)
<jdub> just got a wrt54gs to replace the one we gave to pipka's parents
<lamont> ajmitch: 2-7 hours depending on the architecture
* lamont deploys yet another livecd.sh, waits to see how it does in 20 minutes
<ajmitch> lamont: I'm expecting >24 if I actually build on my hoary box (a 400MHz k6/2)
<lamont> yeah... the buildd's are a bit faster than that
<ajmitch> either that or I finally setup the chroot on my sid box
<mdz> lamont: current casper searches /dev/[hs] d[a-z] [0-9] * for swap and activates it if it finds any
<mdz> lamont: did it not work for you?
<lamont> could be I have the wrong fstype on the partitioon...
<lamont> I'll check that
<mdz> it looks for the swap space signature
<mdz> so if swapon works on it, casper should find it
<ajmitch> crap, apt-proxy uninstallable
<mdz> jdub: rsyncable live CDs, courtesy of lamont
<ajmitch> looks like there's a few packages in universe that need to be rebuilt for python 2.4
<crimsun> I've been pointing out to ogra the ones I'm running up against, ajmitch.
<lamont> ajmitch: for a sufficiently large value of "a few"?
<jdub> mdz: elite! what was the fix?
<ajmitch> lamont: just the ones I'm trying to install :)
<ajmitch> I can't give numbers yet
<mdz> jdub: layer upon layer of cleverness
<mdz> jdub: if I tell you too much your brain will explode
<ajmitch> grep-dctrl should tell me..
<jdub> haha
<jdub> rock!
<mdz> jdub: now it does an rsync based on the old filesystem, and then copies only the allocated blocks to a new file (to zero out the free space)
<mdz> so unmodified files stay in exactly the same place
<mdz> and in theory, even modified files should tend to stay put
<jdub> can this method also be used with install cd images?
<mdz> lamont: any luck with the swap? if there's a case I've missed, I'd like to fix it
<mdz> not really
<mdz> but install images are iso9660, so they don't have these problems
<jdub> given that post-uvf, half the debs are the same?
<mdz> there is no free space, and every file is contiguous
<mdz> so they already rsync very well
<lamont> SwapTotal:           0 kB
<lamont> SwapFree:            0 kB
<lamont> what do you know - no swap
<lamont> that's non-live
<lamont> type 83, no swap footprint that I could see....
<lamont> rebooting with swap actually present on the disk.
<ajmitch> lamont: 155 packages
<ajmitch> that depend on python (<< 2.4)
* jdub does a nice big install/live rsync :-)
<lamont> jdub: they should go faster after that...
<lamont> mdz: once I did the mkswap, it found it just fine... :-)
<mdz> good
<jdub> mdz: how about the usb issue?
<ajmitch> can swap be on an LVM volume instead of a partition?
<mdz> jdub: fixed in the current build
<mdz> the one I was chasing yesterday, anyway
<ajmitch> or will it not find that?
<jdub> ajmitch: apt-proxy (and v2) are poo - it would be great to have a replacement :-)
<jdub> mdz: known fix or magic?
<ajmitch> jdub: I know, but with 128kbit, I need something
<sladen> ajmitch: yes.  (Is this a #ubuntu question?)
<mdz> ajmitch: it wouldn't find that, no
<ajmitch> sladen: asking mdz 
<mdz> sladen: he was asking about the live CD auto swap activation
<sladen> aaah *nod*
<mdz> sladen: did you see I finally nailed that weird USB bug?
<mdz> it turned out to be a kernel thread getting killed by a signal
<sladen> mdz: from the killall5 ?
<mdz> sladen: killall5 is smart and skips them, but busybox mini-init, on the other hand...
<jdub> heh
<mdz> Colin patched it up this morning, and I fiddled with it until it worked
<jdub> mdz: so in preparation for polypaudio, the recommended configuration is to close the device when it's not in use
<jdub> mdz: but that may result in the device being opened by something not configured to use polypaudio/esd
<mdz> jdub: thully will be thrilledully
<jdub> heh
<lamont> mdz: btw, current script just skips the partimage-scrubbing step if it's not there, so ia64 and amd64 should be rsyncable, but we'll have to keep an eye on the size of the image, and decide how often to rebuild it from scratch
<lamont> (and take the rsync bump)
<mdz> ex
<mdz> ok
<lamont> what package creates /usr/lib/terminfo/u/unknown?
<ajmitch> jdub: you're right, apt-proxy is quite broken when used with hoary, as I think it recompresses Packages.gz
<jdub> ajmitch: it's broken normally anyway ;)
<ajmitch> it is at least functional when used with sid :)
<ajmitch> I did start writing my own proxy in python at one point
<ajmitch> which was crap code
<mdz> lamont: ncurses-term: /usr/share/terminfo/u/unknown
<lamont> ah - symlink pain.
<lamont> ok
<lamont> mdz: next amd64 and ia64 downloads may experience full-size issues, since I think they're actually the first of the rsyncable string on their architectures.
<lamont> i386/ppc should already be fine
* lamont heads to bed.  night all
<mdz> someone else look at the function get_ide_offset in /etc/udev/scripts/scsi-devfs.sh
<mdz> and tell me if it makes any sense whatsoever
<mdz> oh, it does, never mind
<ajmitch_> arse
<ajmitch_> computer just decided to reboot 
<__daniel> hai
<ajmitch> hello
<froud> where can I get rc3 hoary from a site in the US?
<ajmitch> fabbione: sorry about missing the tmpfs option first time round
<Mithrandir> froud: use a torrent?
<froud> no
<froud> have a mirror in co.za but they cap the download to 9KB per sec
<froud> at 500+ that's a long download
<Mithrandir> froud: archive.ubuntu.com is in the UK and has a lot better bandwidth than that.
<froud> Lookfor the the ISO
<Mithrandir> http://www.ubuntulinux.org/wiki/Archive has a list
<Mithrandir> including four in the US
<froud> http://archive.ubuntu.com/cdimage/sounder-test/current/
<froud> that sounds good
<mdz> those CDs are ancient; you don't want them
<mdz> where did you find that link?
<mdz> those pre-date the current stable release
<froud> mdz, didn't just used my common sense
<mdz> if you want the latest pre-release stuff, it's at http://cdimage.ubuntu.com/daily/
<froud> when Mithrandir said archive. I looked
<mdz> the stable release is at http://cdimage.ubuntu.com/releases/4.10/release/
<froud> mdz, have problems with 4.10 on box
<froud> cant get    past base installation
<Mithrandir> froud: http://cdimage.ubuntu.com/releases/hoary/array-3/ is what you want
<froud> OK now I have two http://cdimage.ubuntu.com/daily/current/
<froud> mdz, but other distros install fine on the same machine
<mdz> try hoary, and if hoary doesn't work either, file a bug
<froud> yes, that's the plan
<froud> also need hoary for the docs
<froud> mdz, you think I should use the http://cdimage.ubuntu.com/daily/
<froud> and Mithrandir says array-3
<mdz>  /daily/ is the leading edge of development
<mdz> array-3 is the current milestone
<froud> mdz, so if I install array-3 how can I then get to edge
<mdz> by upgrading
<froud> and keep on edge
<mdz> regularly
<froud> ok but that URL is iso images, where do I do my apt get from
<mdz> this is getting a bit off-topic for this channel; glad to answer further questions in #ubuntu
<froud> fine
<__daniel> are there any plans to step from gcc-3.3 to 3.4 or 4.0 (once it is released)?
<__daniel> even in 3.4 there were some improvements for amd64
<mdz> not for Hoary, but perhaps for the release after Hoary
<__daniel> erm... i mean recompiling the packages too, because yesterday seb128 and i tried to sort out, why gnome-launch-box on amd64 gives a floatingpoint exception - the imendio guys said it worked nice on their amd64, they guessed it could be a gcc issue (they used 3.4)
<__daniel> ah... ok
<__daniel> (that's what expected :-))
<__daniel> i only wished someone could tell me, why gdb only spits out memory adresses and nothing useful in its backtraces, although i installed -dbg packages and did not strip the binaries in-question
<sivang> Moins all
<__daniel> hellas sivang!
<sivang> (that was a rather quick night sleep)
<__daniel> when did you go to bed, sivang?
<sivang> __daniel: Hello! :-)
<sivang> __daniel: around the last time I awayed my irssi , approx.
<daniels> kkkkkeeeyyyyyyyyyyybbbbbbbuuuuuuuuuuuuukkkkkkk
* sivang burning 20050121.1 for testing.
<sivang> mdz: you didn't build a new image overnight right? (my night)
<pitti> Morning folks!
<abelli> pitti: ciao
<abelli> pitti: does your kernel like frame buffer?
<ajmitch> hi pitti 
<sivang> pitti: Moins!
<pitti> abelli: on ppc yes, but not on my i386 desktop
<abelli> argh..
<abelli> it's "all black"
<pitti> abelli: right, but just wait until X starts
<abelli> yeah i know..
<sivang>  /msg nickserv identify speedy123
<abelli> sivang: ops
<sivang> hrm
<sivang> that was not good.
<ajmitch> no, it might be time to change that one
<sivang> ajmitch: yepss ;-/
<abelli> ciao im off..
<pitti> D'oh
<pitti> "mind the gap"
* ajmitch attempts yet another kernel recompile
<pitti> i. e. the space
<sivang> pitti: exactly.
<ajmitch> compiler has segfaulted once, and had one kernel oops.. hopefully it'll build this time :)
<amu> moins 
<pitti> Hi amu!
<pitti> Riddell: ping
<amu> servus pitti 
<Riddell> pitti: hi
<pitti> cool, just got my Python Cookbook
<sivang> pitti: o la la ;-)
<sivang> pitti: sounds tasty
<pitti> Hi Riddell! Just mailed you about koffice
<lifeless> jdub, mdz: oh, baz 1.1.1 is released, that would be good to get into hoary
<Riddell> pitti: uploaded
<daniels> sjoerd: read yo' email
<sjoerd> daniels: you mean the bindings patch ?
<daniels> yah
<sjoerd> nice
<sjoerd> i'll probably push it to experimental today (well to NEW in that case..)
<Riddell> lamont: kdewebdev is missing logs for i386, could you tell it to try again?
<Riddell> lamont: any idea why k3b/0.11.18-2ubuntu1/ has a ia64-successful and a ia64-successfull (sic)?
<amu> elmo: ping 
<Riddell> lamont: kdeedu is missing logs for i386 and ia64
<no0tic> hi, where Can I find changelogs for updated packages?
<Riddell> no0tic: hoary-changes
<__daniel> no0tic: /usr/share/doc/<package>/changelog.{Debian.gz,gz} or install  apt-listchanges 
<amu> http://people.ubuntu.com/~mvo/changelogs/pool/
<no0tic> tnx
<amu> daniels: *remind* dbus-qt 
<daniels> amu: yeah, I haven't forgotten :)
<amu> daniels: no prob, kind of blocker atm :) 
<daniels> heh yeah, i have a patch that i'm just looking over now
<daniels> but it is 2303 on a saturday, heh
<amu> .oo ohh today it's saturday? which year? ;)
<amu> releax, do it if you have time for it 
<ogra> morning
<__daniel> hellas ogra :-)
* ogra yawns
<Riddell> compiler question: what does -fPIC mean?
<__daniel> riddell: "If supported for the target machine, emit positionindependent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, m88k, and the SPARC.   --    Positionindependent code requires special support, and therefore works only on certain machines."   :-)
<daniels> amu: heh, 2005
<daniels> amu: yeah, I'm going to sort it either when I get back (later tonight) or tomorrow, just about to head out
<__daniel> Keybuk: daniels seems to have called you earlier today: ;-) (10:19:41) daniels: kkkkkeeeyyyyyyyyyyybbbbbbbuuuuuuuuuuuuukkkkkkk 
<Nafallo> hehe, that didn't give hilight then *s*.
<Keybuk> Nafallo: well, no; it's quite hard for my IRC client to detect highlight when I'm not logged in <g>
<Keybuk> __daniel: yeah, I saw his blog post.  I think he was trying to use Libtool, it's a common reaction
<ogra> lol
<Nafallo> Keybuk: hehe. I should get more jolt for myself ;-).
<ogra> hmm, why is daniels not on planet ubuntu ?
<haggai> jdub: apt-proxy v2 isn't poo becuase it needs replacing, it just needs some help because the author died...
<haggai> lamont: any idea what's up with oo2-ubuntu8?  No buildd logs
<kent> can one have both oo2 and oo1 installed in Hoary?
<Riddell> kent: no, openoffice 2 isn't in hoary yet
<opi> hi
<opi> is launchpad down, or I just have a ,,bad network'' day?
<__daniel> opi: doesnt work for me either
<opi> __daniel: damn, I've some spare time to play with Rosetta, and it's gone :-)
<jdub> smurfix: 'ubuntu-cc'?
* __daniel comforts opi
<lamont> universe/editors/openoffice.org2_1.9.66-0ubuntu8: Dep-Wait by buildd+terranova [-:uncompiled] 
<lamont>   Dependencies: dmake (>= 4.3-1)
<lamont> haggai: does the dmake build-dep need to be killed?
* lamont points at wiki.ubuntu.com/BuildDaemons
<HostingGeek> __daniel == daniels ?
<ogra> nope
<Keybuk> mdz: dude, are we having TB meetings weekly now ? :p
* lamont watches rsync bounce around between 21kB/s and 450kB/s
* __daniel should fashion himself a new name
<danielh> hm
<fabbione> daniels: ping
<danielh> maybe better  dholbach , so you guys wont have to type daniels completely :-)
<jdub> *screeech* namespace b0000rk! :-)
<fabbione> there is a *daniel* inflation here
<ogra> hehe
<dholbach> maybe that's better
<ogra> dholbach: youre changing colors all the time.....
<dholbach> ok... i'm set now :-)
* ogra examines his tobacco....
<dholbach> :-)
* dholbach will bother you with other useless stuff now ;-)
<HostingGeek> hmm is it just me or are both au mirrors down?
<HostingGeek> thats it i am learning python 
<dholbach> i'm off... bye
<ogra> ciao :)
<dholbach> bye ogra
<jdub> Kamion: ?
<jdub> Kamion: fucken idiotic 2am idea for you.
<jdub> Kamion: http://www.adam-lilienthal.de/directvnc/
<Keybuk> Kamion is at the pub with the rest of the debian-uk folks, I expect
<jdub> haha
<jdub> i'll sms him
<jdub> we need to get colin an incredibles tshirt
<jdub> and claim the i stands for INSTALLERMAN
<fabbione> error: command 'gcc' terminated by signal 11
<fabbione> this is not good.. is it?
<siretart> most probable reason is defective ram for that errormsg
<fabbione> siretart: it's a very remote possibility.. considering that it happens only building one specific program
<jdub> Device seems to be: Generic mmc2 DVD-ROM.
<jdub> cdrecord: Warning: controller returns wrong size for CD capabilities page.
<jdub> cdrecord: Warning: controller returns wrong size for CD capabilities page.
<jdub> cdrecord: Warning: controller returns wrong size for CD capabilities page.
<jdub> Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
<jdub> Driver flags   : MMC-3 SWABAUDIO BURNFREE FORCESPEED
<jdub> Supported modes:
<jdub> 
<jdub> nice one. :|
<ogra> jdub: still struggling with your writer ?
<jdub> yeah, just this one in my desktop
<ogra> does n-c-b work ?
<jdub> cdrecord doesn't work, so... :-)
<ogra> hmm
<ogra> ho do you access it ? dev= ?
<ogra> how even
<jdub> dev=ATAPI:/dev/hdc
<ogra> drop the ATAPI:
<jdub> aha, if i run it as root, i get supported modes
<ogra> cdrecord doesnt like the ATAPI: thingie....try with a simple dev=/dev/hdc, then it should work as user too
<jdub> red light is on
<jdub> cpu at 100%
<jdub> rawk
<ogra> uhh
<sivang> jdub: 2.6.something made the need for the emulation layer redundet ;-)
<jdub> sivang: thus the above, it's not using scsi emu
<jdub> oh, i mistook the orange light for the red light
<jdub> there are two
<jdub> orange again, 66% cpu
<sivang> jdub: orange sounds good
<ogra> yup
<kent> 66% cpu,  isn't that a bit much?
<jdub> at least this seems to be doing something slightly more sane than it did with windows
<HostingGeek> hey why doesn't ubuntu use xfce 4.2 menu editor!?!?!? it gtk+, it follows the freedesktop standard it in the bg in this screeny: http://de.lunar-linux.org/xfce4/screenshots/snap_VII.jpg
<HostingGeek> it has feature people like to see
<azeem> and it looks horrible
<ogra> this doesnt look usable
<kent> HostingGeek, im against using temporaly solutions for problems which we can solve by our self. Next Gnome release might have a better application, and we cant just change applications time to time. As long as programs comes tith a .desktop-file there no hurry with menu-editing.
<HostingGeek> azeem: no it doesn't
<HostingGeek> its in gtk
<HostingGeek> its a nice GUI
<robertj> looks fair but not good enough
<HostingGeek> ogra: its more useble than than what gnome HAD
<HostingGeek> robertj: it has all features NEEDED
<robertj> The Applications menu serves as a place from which to drag launchers to your panel ;)
<robertj> HostingGeek: true has all the features needed
<robertj> there really isn't a problem with the Applications dropdown not being editable
<ogra> HostingGeek: not at all..... and i doubt my mom would be able to use it (in opposition to the applicatins:// location gnome used before)
<robertj> ogr: I've found that on OS X the Appliations folder isn't that intuitive for users
<wasabi> hah
<HostingGeek> ogra: my dad said wtf is this applicatins:///
<HostingGeek> i gave this program and he loved it
<wasabi> you guys know you COULD have right clicked in the menu and hit "Add" directly.
<wasabi> Without applications:///
<ogra> mabe, but its still a horrible UI i wouldnt give to anyone
<HostingGeek> be aware my dad is a idiot at computer and doesn't understand what a os is
<robertj> Application installer is where it's at
<robertj> if you can't installing an app with application installer, you need help
<robertj> my personal gnome gripe of the day (GOTD) is that folder launchers can't be dragged to to place files
<robertj> last night I dragged a python file to a random folder and it launched Rhythmbox
<robertj> actually right now launchers to directories dont seem to do anything
<ogra> HostingGeek: do you think my mom is rocket sience engineer ?
<ogra> HostingGeek: she wouldnt be able to use such a cluttered app 
<HostingGeek> ogra: do you think my dad is
<HostingGeek> ogra: my dad is 80
<jdub> wasabi: dude, that mail was so unproductive.
<wasabi> i suspose
<wasabi> i couldn't hit unsend though heh
<jdub> "Ubuntu CD detected "
<jdub> "You can automatically upgrade from it, start the package manager application or cancel"
<HostingGeek> wtf?
<sjoerd> jdub: more crack for gvm ?
* jdub reboots with the livecd.
<ogra> sjoerd: nope, update-notifier
<jdub> sjoerd: update-notifier.
<sjoerd> ah
<wasabi> this is odd. i think update-initrd is leaving off my scsi driver on 2.6.10
<haggai> lamont: ah, thanks for the link.  Please clear the dep-wait, I uploaded a pkg that uses the internal dmake again
<ogra> jdup is the source for monkey-juice anywhere available (i would like to have a amd64 version)
<jdub> monkey-juice?
<jdub> mdz: livecd is elite.
<sivang> jdub: livecd allows you to upgrade your warty system?
<jdub> sivang: no, it's a bug.
<ogra> jdub: -journal....sorry
<jdub> ogra: oh. www.gnome.org/~clarkbw/ ?
<HrdwrBoB> hello
<jdub> yo HrdwrBoB 
<seb128> wasabi: stop trolling on this list :p
<ogra> jdub: thanks :)
<jdub> seb128: bring up epiphany again!
<seb128> what about epiphany ?
<jdub> "Why do you guys ship Firefox instead of Epiphany?"
<jdub> "Iz GTK+ bug."
<seb128> ah ah
<seb128> that's right
<seb128> jdub: why you guys ship firefox ? :p
<seb128> GIMME EPIPHANY
* seb128 hides
<lamont> haggai: wacking
<seb128> and thom has screwed the firefox update which was supposed to fix the typeahead
<seb128> thhooooooooooooom
* fabbione notes that it is saturday evening....
* chrisa never liked epiphany or galeon
* fabbione and that not everybody is addicted to his pc
<seb128> thom: do you mind if I upload firefox to fix the typeahead ? :p
<ogra> fabbione: no ?
<fabbione> no
<jdub> seb128: last one who touched it gets to be maintainer.
<seb128> doh
<sivang> seb128: epiphany also uses java?
<ogra> fabbione: hmm, weird people....
<seb128> I'll send a patch rather so :p
* jdub is awake because it's HOT and there are MOSQUITOS eating him.
<fabbione> that's what i did with apache :-)
<seb128> sivang: java ? to do what ?
<fabbione> ops
<lamont> haggai: done
<seb128> jdub: how crazy would it be to set the default pdf viewer to evince ? :)
<sivang> seb128: it would be good! do it :)
<jdub> seb128: it's really tempting, isn't it?
<bradb> jdub: come cool down in montreal. it's a relaxing -22C here.
* ogra would love to change jdubs mosquitos against the 5 degree C outside
* sivang would be great not seeing xpdf anymore
<jdub> seb128: i think we should go with gpdf though.
<jdub> seb128: evince for bendy :)
<seb128> jdub: no type3 fonts support in gpdf
<jdub> seb128: martink fixed that, i'm sure
<jdub> martink: ping
<seb128> jdub: I pinged him 2 days ago, he didn't and he has no ETA
<jdub> oh
<jdub> what does evince do?
<seb128> jdub: he said we should keep xpdf rather gpdf he doesn't know when he'll do that
<seb128> yep
<jdub> i thought it used fixed gpdf code
<seb128> no, evince integrates more xpdf code afaik
<jdub> i'm sorely tempted, dude.
<seb128> :)
<jdub> i'll chat to jrb and co about it.
<seb128> ok, thanks
<seb128> c'mon, xpdf is ugly, evince is niiiiiice :)
<jdub> seb128: gnome-launch-box is weird.
<martink> sorry for gpdf non-fixing. I'm a terrible slacker
<seb128> it doesn't work fine here, but I've uploaded since people keep asking for it :p
<jdub> martink: we still love you ;)
* sivang think evince looks more of a gnome app, rather then an X hack like xpdf
<seb128> jdub: be careful, don't get a .desktop without a Icon= line or gnome-lauch-box will shock on it :)
<seb128> sivang: gpdf too .. 
<jdub> martink: so how did evince dodge the font problem? does it cheat and not use pango, or...?
<sivang> seb128: evince ru-lez, right? ;-)
<martink> jdub, cheat and not use gnome-print. Of course, suddenly lots of pdfs appear that look better in gpdf than in xpdf
<martink> jdub, it uses the same renderer as xpdf (and kpdf 3.4)
<jdub> martink: aaahhhh
<lamont> Warning:Outdated PO file: debian/po/ca.po, running
<lamont>   debconf-updatepo --podir=debian/po 
* lamont grumbles at xorg
* tseng shrugs at gnome-launch-box
<lamont> speaking of lunch.. I should eat
<ogra> hmm, what is gnome-launch-box supposed to do ? it dies with a Floating point exception here (amd64)
<sivang> ogra: it just hanged my whole session, had to restart x
<Nafallo> ogra: thanx for the wikipage on MOTUs :-).
<ogra> :)
<sivang> looks to me like a big drawing of a mouse
* Nafallo detach to try to get fglrx going *
<ogra> Nafallo: go ahead, become a MOTU and gain fame and recpect :)
<ogra> hmm, why is gnome-btdownloadgui still not in universe ?
<srbaker> is there a tool available in ubuntu that allows one to easily change wireless networks?
<srbaker> i want a gui way to switch network configs
<sivang> srbaker: did you try network-admin?
<HrdwrBoB> sivang: network-admin does not allow that
<srbaker> sivang, no.  i thought there was a panel app for this.
<sivang> HrdwrBoB: oh, well, I know garnacho was working on something like this, maybe it for after 2.10..
<HrdwrBoB> netapplet does
<srbaker> i can't find netapplet
<HrdwrBoB> it's in hoary, called 'netapplet'
<srbaker> oh.  i'm on warty
<srbaker> this is my lappy, i'd rather not have to do instability
<Nafallo> ati doesn't like me :-P
<ogra> Nafallo: but your money :-P
<srbaker> can someone tell me what the significance of version numbers is?
<srbaker> 4.10, 5.04 ?
<srbaker> that's just *WEIRD*
<tseng> srbaker: month.day
<srbaker> ahh
<lamont> srbaker: year.month
<ogra> year.month
<tseng> yeah, that.
<srbaker> that looks better
<Nafallo> ogra: ;-)
<Nafallo> ogra: if the damn card wasn't inside my lappy I would change to something that supports DRI ;-).
<Riddell> lamont: could you tell the buildd's to try again with kdeaddons, kdeedu and kdewebdev
<lamont> yet again?
<lamont> what kind of broken build-deps are you using??? :-)
<wasabi> very interesting. I found why my initrd was broken...  it seems 2.6.10 tries to use initrd-kver.gz, while 2.6.9 tries to use initrd.img-kver
<wasabi> the .gz one isn't working
<HrdwrBoB> I had to build my own initrd for the 3ware card, that was fun
<wasabi> update-initrd kver does it.
<wasabi> after you add the module to /etc/modules, it seems
<wasabi> so, that's not that hard.
<HrdwrBoB> yeah but 
<Riddell> lamont: well for example I can see a build log for kdewebdev for ia64 not but not for i386
<HrdwrBoB> I didn't know that at the time so I extracted the initrd and hacked in my driver and used that :)
<lamont> Riddell: I could swear I gave it back.. /me looks
<lamont> Riddell: hrmpf... could have sworn I gave that one back...
<lamont> anyway, I just gave back a bunch more
<lamont> they should start building w/in 5 minutes, etc, etc.
<Riddell> thanks
<lamont> Riddell: feel free to poke me again in a little bit if they're not built, etc.
<daniels> fabbione: pong
<azeem> hey gowlin 
<gowlin> Hey.
<haggai> lamont: thanks
<Nafallo> is there a reason not to have memtest86+ availible for amd64?
<eruin> has anything happened recently that might break sound in 2.6.8 while it's ok if I run a more recent kernel?
<eruin> I can't use 2.6.9+ due to a change in ptrace behaviour that winex/cedega/wine isn't following
<srbaker> grrr
<srbaker> anyone here have rubygems or rake packages for ubuntu?
<Nafallo> memtest86 isn't depending on the kernel AFAIK, but is it depending on architecture? (or atleast, isn't it compatible with amd64)?
<HrdwrBoB> yes
<HrdwrBoB> it's it's own thing
<Nafallo> trying to build it then... :-)
<fabbione> daniels: did you test the kernels i prepared for you?
<Riddell> how can I tell debuild -S not to ignore my deleted files?  "dpkg-source: warning: ignoring deletion of file debian/patches/029-ruby1.8-not-just-ruby.diff"
* ogra dances around extatically with an insane giggling and steals jdubs pants
<ogra> jdub: --> 
<ogra> GOT IT !!!
<jdub> haha
<ogra> i'm so happy :-D
<Riddell> ogra: what's happened?
<ogra> i ripped xscreensavers lock screen code apart......
<ogra> glued it together again with xft support and dots instead of the stars :)
<ogra> Riddell: the dots were the hard part (wchar_t vs. char while the app uses memcpy for replacing the typed pw)
<ogra> Riddell: an early stage: http://www.grawert.net/xss_shot_1.png
<HrdwrBoB> wow, it's not hideously ugly
<mdz> jdub: 31337\
<mdz> jdub: I think the d-i network config is the next thing to tackle
<mdz> but I need to talk it over with Kamion when he gets back
<mdz> seb128: here?
<jdub> mdz: would you like a mail with nitpicky stuff about it?
<mdz> jdub: my current idea is that it should try pretty hard to configure _one_ network interface by brute force without asking anything
<mdz> jdub: but if it can't, just continue without asking any questions
<mdz> this seems like reasonable behaviour for both the live CD and install
<jdub> what about the perennial wifi problem?
<mdz> sabdfl has always wanted it to try to find an open network first
<jdub> so if wifi's the primary interface, try open, then ask for details?
<mdz> try open, then give up if it doesn't work
<mdz> and let them configure it with netapplet
<mdz> jdub: the server install, though, should fall back to interactive static config, I'd say
<Nafallo> ogra_: damn, that looks great :-).
<jdub> mdz: yeah
<HrdwrBoB> oh, btw, my system starts 
<HrdwrBoB> pcmcia wayyy after networking
<mdz> there's a bug open about that
<ogra> Nafallo: yeah, thanks, i'm quite proud of it :)
<mdz> but no one has had the combination of pcmcia networking and motivation to fix it
<HrdwrBoB> I just don't reboot, keep suspending
<mdz> jdub: do you have nitpicks which would still be applicable to that approach?
<HrdwrBoB> I'll check it out tomorrow
<jdub> mdz: oh, meant a full review
<mdz> jdub: oh, live CD usability in general, rather than just the networking?
<jdub> yeah
<mdz> jdub: msg'd you my todo list
<jdub> btw, do you know anything about the framebuffer hang in d-i?
<mdz> hang?
<ogra> huh ? which arch ?
<thully> mdz: I don't know about that, as that would mean - test my ethernet, and if it can't find anything network wouldn't work
<thully> correct? or would it try wi-fi first
<jdub> waiting for /proc/fb/0 or whatever... tick tick...
<jdub> much shorter now, but still apparent
<mdz> thully: it would try each interface
<mdz> jdub: that's udev sucking
* wasabi_ ponders a hal script that automatically adds interfaces to /etc/network/interfaces
<mdz> jdub: it's just hot-plugged a few hundred devices and is still catching up
<Nafallo> ethernet should be something like ifplugd IMHO :-).
<jdub> mdz: boh
<mdz> jdub: that's a general d-i thing, of course, not part of my live CD todo
<jdub> yeah
<mdz> but I think a strategically-placed udevstart would clean it right up
<wasabi_> ifplugd, or something like it, can be used to bring stuff up and down, sure.... but to actually add the devices to interfaces...
<jdub> can we make udev do fb earlier?
<jdub> yeah
<mdz> udevstart walks /sys and creates the device nodes synchronously
<thully> the one big issue with current network setup is that if you want an interface to DHCP on boot, it will stall bootup until it finds a network or times out
<wasabi_> seems to me network startup/setup should be stuffed into the hotplug/udev routine
* Nafallo hates when he visit a friend and his wlan will timeout because it has the wrong wep-key :-P.
<Nafallo> or at school when I can't find an AP.
<jdub> NM will do this
<mdz> wasabi_: please file a bug about that initrd problem if there isn't one already
<mdz> wasabi_: there is at least one bug open where mkintird isn't loading the right drivers anymore
<wasabi_> will do
<mdz> wasabi_: that filename explanation sounds odd to me; the initrd has never been named .gz as far as i know
<mdz> the name is determined by kernel-package, which hasn't changed in some time
<wasabi_> wasabi@kyoto:/etc/hal/device.d $ ls /boot/initrd*
<wasabi_> /boot/initrd-2.6.10-2-k7.gz  /boot/initrd.img-2.6.10-2-k7
* wasabi_ shrugs
<mdz> jdub: did you notice the pretty background title? ;-)
<jdub> mdz: ...
<mdz> wasabi_: one of those came from the kernel package installation; the .gz must have come from someplace else
<jdub> mdz: hold on ;)
<wasabi_> mdz, actually, I deleted them both, and rerun update-initrd and they both came back
<mdz> wasabi_: what is update-initrd?
<wasabi_> ... beats me.
<mdz> that is not an Ubuntu tool
<wasabi_> haha
<wasabi_> I thought it was. ;)
<wasabi_> i used it to add the 3ware drivers to my initrd.
<wasabi_> wasabi@kyoto:/etc/hal/device.d $ dpkg -S /usr/sbin/update-initrd
<wasabi_> discover1: /usr/sbin/update-initrd
<wasabi_> ahh I see what's going on
<wasabi_> the kernel packages have the non-.gz one... update-initrd makes a .gz one.
<wasabi_> update-initrd is just confusing because it's present.
<wasabi_> update-initrd actually builds an initrd for the specified kernel, copying all the scsi/ide modules into it. I had *thought* that linux-image ran it in postinst... I just had assusmed, hadn't looked at it.
<mdz> update-initrd needs to go
<mdz> the tool used by the kernel packages is mkinitrd
<wasabi_> ahh.
<ogra> mdz: discover neeeds to go at all....
<mdz> ogra: hopefully for hoary+1
<mdz> xserver-xorg still needs it
<ogra> yup
<HostingGeek> hmm flink is no where near as good as "Mail Notefaction"
<wasabi_> I had always fancied the idea of building an initrd in a postinst script. Leaves open the possibility for third party storage drivers to be included.
<ogra> btw, who is writing the dbus frontend for evoluitions mail notification ?
<mdz> update-mkinitrd gone
<ogra> :)
<HostingGeek> *Mail notification
<HostingGeek> why doesn't Mail notification take over the mail applet
<HostingGeek> well it not a applet even
<srbaker> is jakarta ant in warty multiverse?
<mdz> srbaker:        ant |    1.6.2-2 | http://archive.ubuntu.com hoary/multiverse Sources
<mdz> srbaker: seems to FTBFS
<srbaker> suck
<mdz> http://people.ubuntulinux.org/~lamont/buildLogs/a/ant/1.6.2-2/
<mdz> build-depends on a proprietary jdk, it seems
<ogra> srbaker: become a MOTU and change it ;)
<srbaker> ogra: i have to get an apartment first.
<ogra> srbaker: as a MOTU you dont need an appatment, you own the whole universe ;-P
<srbaker> ogra: i need an apartment to have somewhere to work from
<ogra> srbaker: just kidding... :)
<jdub> mdz: so what's this background thing you mention?
<mdz> jdub: in the upper-left corner of the screen during d-i
<jdub> oh
* jdub reboots again
<jdub> mdz: haha. "oh."
<ogra> hmm, only 6.8K from cdimage.ubuntu.com ..... grr
<mdz> jdub: I already know how to suppress the hostname prompt, but it's so convenient for me when debugging
<mdz> it stops at just the right time
<jdub> hrh
<mdz> just added code to fix up the session based on whether the system is a laptop or not
<mdz> though it didn't work
<mdz> oh, probably /proc wasn't mounted at the time
<eruin> https://bugzilla.ubuntu.com/show_bug.cgi?id=5582 <--- I need sata drivers in my initrd :-)
<ajmitch> morning
<mxpxpod> what do I do if the MD5 sum on the source package list for universe on powerpc is incorrect?
<Riddell> lamont: kdewebdev et al have now compiled for all platforms but if you try to install it you get errors saying the .deb is 404
<lamont> when does the log say that it finished building>?
<Riddell> lamont: 20050122-1719-i386-successful 
<Riddell> Finished at 20050122-1740
<lamont> that's the start time...
<lamont> very last line of the log has the ending time... /me looks
<lamont> ah, ok.
<abelli> lamont: what about OOo2?
<lamont> and that's 3 hours ago, so....
<lamont> abelli: http://people.ubuntu.com/~lamont/buildLogs/Lists/
<ogra> lamont, could you have a look at the md5 sum thing ? i get the same error like mxpxpod here
<lamont> Riddell: Jan 22 17:45:03 buildd-mail: kdewebdev has been installed; removing from upload dir:
<lamont> out of my hands
<lamont> ogra: what md5 thing?
<abelli> lamont: thank you
<ogra> lamont: md5sum doesnt match error for hoary ppc universe PAckages.gz
<ogra> looks like a sever side prob....
<Riddell> lamont: so who's hands is it in?
<lamont> Riddell: the archive..  just a sec
<lamont> Riddell: EW!  they're in the master, but haven't made it to archive.ubuntu.com
<lamont> elmo?
<lamont> ogra: it does appear that you may be on to something...
<ogra> tell me if i can collect any info here...
<lamont> ogra: nothing not more easily done on the archive machines.
<lamont> which I don't have logins on..
<lamont> mdz about?
<ogra> ah..
<ajmitch> yay, I finally have a working hoary chroot on sid to build a kernel in
<mxpxpod> ogra: so, what do I do?
<ogra> mxpxpod: we wait for elmo....
<ogra> or mdz ?
<mxpxpod> :(
<jbailey> Hmm.  Bugzilla tells me I need to enter a component, and there isn't a place to do so...
<Treenaks> jbailey: ubuntu bugzilla?
<jbailey> seb128: I'm trying to file that bug, and pan doesn't show up in the drop box. =)  
<jbailey> Treenaks: Yeah.
<Treenaks> jbailey: hm
<seb128> jbailey: use UNKNOWN as component, assign the bug to me, and ask a pan component to jdub/mdz :)
<jbailey> What email are you using on here?  It doesn't know sebastien.bacher@ubuntu.com
<seb128> jbailey: just put seb in the field :p
<seb128> jbailey: you'll probably get a list, you can also use seb128 which will work directly :)
<netdur> I installed gnome-core-devel, gnome-devel and libgnomeui* packages, but gcc still can't find "gnome.h" header files!
<jbailey> Ooo, fancy.
<seb128> (I'm using seb128@ubuntu.com)
<sivang> mdz: ping
* Treenaks gives seb128 another bit
<crimsun> netdur: libgnomeui-dev
<seb128> netdur: seems to be a old GNOME 1 stuff
<jbailey> seb128: w00t, done. ;)
<netdur> installed "/usr/include/libgnomeui-2.0/gnome.h"
<netdur> gcc can't find it
<seb128> that's the GNOME2 version
<seb128> what are you trying to build ?
<martink> netdur, do you use pkg-config correctly?
<netdur> gcc 'pkg-config --cflags --libs libgnomeui-2.0' test.c
<seb128> and what's the error ?
<sivang> mdz: livecd doc is ready, we would like thought to know where does apt-get source debian-installer can take us ;-) new levels of customization?
<netdur> something like... gnome.h no such as file or directory
<seb128> what include are you using ?
<netdur> #include "gnome.h"
<seb128> <gnome.h>
<seb128> no "gnome.h"
<seb128> <> for the system stuff
<netdur> wow, I feel so stupid
<netdur> I know it, but made the mistake
<eruin> any of you have an idea of what might cause sound to come out corrupt on 2.6.8 while working fine on 2.6.9+ on the same hoary install?
<crimsun> emu10k1?
<eruin> only started happening a few days ago
<crimsun> oh, it worked before?
<eruin> yeah
<eruin> that's what's having my head in a spin
<crimsun> I only know of the <<2.6.9 and emu10k1 issue
<eruin> hehe, I use viarhine ;)
<netdur> thanks
<sivang> netdur: you're trying to build gnome?
<Riddell> lamont: count you put amarok 1:1.2beta3-0ubuntu1 back into the buildds?
<netdur> no, I try to convert my gtk+ app to gnome app
<netdur> anyway, I changed "" to <> but got the same error!
<sivang> netdur: btw, if you want a really good channel for gnome developemnt, there's no place like home ;-) == gimp net's very own, gnome-love
<netdur> at first I though it ubuntu problem, now in my hand I handle "the official gnome 2 developer's guide"... not that good :\
<sivang> netdur: what application do you have there?
<netdur> rss reader
<netdur> I don't like how blam and liferea manage rss fees! email way!!!
<netdur> feed*
<lamont> mni
<lamont> Riddell: so  libkjsembed-dev will magically be there this time?
<sivang> lamont: what's up with the archive again? 21.7kB/s ?
<Riddell> lamont: amarok?  that was waiting for libtunepimp2
<lamont> auckland is having a very bad day.
<lamont> ia64 was waiting for libkjsembed-dev
<sivang> ergh
<lamont> Riddell: have I mentioned how wrong virtual packages in build-deps are?
* lamont updates the wiki
<Riddell> lamont: ok, don't do amarok until I've sorted kdebindings then
<lamont> 3. Virtual packages in Build-Depends. If you use a virtual package in your build depends (and thereby leave it up to the buildd to pick one for you, maybe even the right one...), and said package is not in the archive yet, then you'll get dep-waited on the virtual package name. And it won't ever be cleared until someone uploads a package with that name, or you get lamont to clear it. Please don't build-depend on virtual packages.
<crimsun> 3a. Always bug lamont.
<lamont> crimsun: and he'll give you a pointer to the logs/lists.
<crimsun> lamont: stuffed. :/
<lamont> 3b. tell lamont what you actually want done (clear the dep-wait, give it back, etc)
<lamont> Updating mozilla-firefox chrome registry...E: Registration process existed with status: 1
<lamont> E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
<lamont> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
* lamont grumbles
<lamont> thom: you around?
<mdz> lamont: here now
<mdz> sivang: pong
<mdz> sivang: apt-get source debian-installer is not relevant to live CD customization, or development at this point
<lamont> mdz: auckland was struggling, appears to be happier now
<mdz> I couldn't have done anything about that anyway :-)
<mxpxpod> mdz: do you think you could redo the md5 sums on the powerpc universal packages files?
<lamont> mdz: me neither...  I was looking to fob the problem off on you... :-)
<mdz> mxpxpod: no, I can't.  why do you think they are incorrect?
<mxpxpod> mdz: because I'm getting an error
<ogra> mdz: me too
<mdz> someone needs to be a little bit more specific
<ogra> hoary ppc universe Packages.gz ... md5sum mistmatch
<mxpxpod> sorry, I was waiting to get the error again
<ogra> thats the error
<mxpxpod> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hoary/universe/binary-powerpc/Packages.gz  MD5Sum mismatch
<lamont> mdz: it looked like auckland had paused mid-mirror, or the script died
<mdz> elmo: ?
<lamont> the ppc error was one thing, other packages that were 3 hours old hadn't shown up yet (but are there now)
<mdz> I'm getting awful transfer rates to archive.u.c again
<lamont> mdz: it could be that if we upload something, then it
<lamont> will just regen the ppc file for them..
* lamont casts around for some universe package that could now build to give back
<mdz> yeah, I'm getting the error as well
<mdz> has anyone sent email to elmo?
* lamont didn't
* ogra neither
<sivang> mdz: ok then, off to remove it from the doc ;-)
<dholbach> re
<mdz> sivang: I just edited it
<mdz> sivang: I moved that part to the bottom as "additional information", because it is confusing to have it at the top (it looks like the start of the instructions)
<sivang> mdz: ah ok, you're fast like lightning...it's clear now. thanks.
<sivang> mdz: btw, booted lastnight's live image, works fine, locale working, no sound , usb not tested yet.
<mdz> sivang: why do you say that debconf-utils is required?
<sivang> mdz: hrm, this was jinty's perliminary remarks, either way it's already installed on hoary
<sivang> mdz: should it be remove also?
<mdz> fixed
<sivang> mdz: k, cool.
<mdz> straw poll: for a small package containing miscellaneous Ubuntu-specific utilities, "ubuntu-tools" or "ubuntu-utils"?
<tseng> utils, after debian-utils
<dholbach> utils :-)
* mxpxpod plays devils advocate
<mxpxpod> tools
<mxpxpod> :)
<dholbach> this is the current state on my box:
<dholbach> daniel@bert:~$ dpkg -l | grep utils | wc -l
<dholbach> 32
<dholbach> daniel@bert:~$ dpkg -l | grep tools | wc -l
<dholbach> 30
<dholbach> ;-)
<lamont> utils
<ogra> ogra@honk:~ $ dpkg -l | grep utils | wc -l
<ogra> 24
<ogra> ogra@honk:~ $  dpkg -l | grep tools | wc -l
<ogra> 28
<mdz> mizar:[/tmp]  apt-cache -n search tools |wc -l
<mdz> 188
<mdz> mizar:[/tmp]  apt-cache -n search utils |wc -l
<mdz> 195
<mdz> a dead heat
<sivang> mdz: utils
<jdz_> utils! :D
<dholbach> ogra: what did you do? your statistic is all wrong? ;-p
<mdz> I was leaning toward 'tools'
<sivang> mdz: then tools, you decided for it at the end no? ;-)
<mdz> because it's the same length, and is an actual word, rather than an abbreviation
<mxpxpod> dholbach: he has part of his search messed up because of screwed up md5 sums
<jdz_> mdz: you said yourself, "Ubuntu-specific utilities" :)
<ogra> i rely on my system...its almost always right :) tools > utils
<ogra> mxpxpod: i'm currently not on ppc ;)
<mxpxpod> ogra: oh, nevermind that, dholbach :)
<mdz> jdz_: yes, but ubuntu-utilities is long and awkward to type :-)
<lamont> mdz: too many u's.
<mxpxpod> ogra: hopefully this little md5 issue will be fixed soon
<jdz_> mdz: of course, but utils is shorter while retaining the intended meaning!
<dholbach> what will those "utools" be for?
<mdz> jdz_: "utils" is a technical abbreviation which is common in Unix and almost nowhere else
<ogra> mxpxpod: as soon as elmo fixes it...
<mdz> "tools" has a very similar meaning, but is equally meaningful in a less specialized context
<mxpxpod> ogra: as soon as he wakes up...
<mdz> mxpxpod: it is 2230 in elmo-land
<mxpxpod> mdz: ah, ok
<mxpxpod> my bad
<ogra> mxpxpod: he probably has real world probs to solve
<dholbach> mdz: what will those tools/utils be for?
<ogra> finally the livecds have finished downloading...
<mdz> dholbach: just some simple informational scripts at the moment
<dholbach> mdz: a tool is something, i'd expect to do some clever, but small amount of work for me, utils are things that do stuff in the background... but i won't bitch... just go ahead ;-)
<lifeless> micro-tools, love it
<mdz> dholbach: the first example is that I wanted to provide a simple tool to determine whether the system is running an official Ubuntu kernel, and show the version number
<mdz> it is currently confusing, because there are kernels from different sources, and they have both a kernel release number and a package version number (which are similar in syntax, but distinct)
<mdz> mizar:[.../canonical/ubuntu-tools-0.1]  ./ubuntu-kernel-version
<mdz> This system appears to be running an Ubuntu packaged Linux kernel
<mdz> linux-image-2.6.10-2-k7 version 2.6.10-10
<lifeless> mdz: so how, check the md5sum ?
<mdz> lifeless: it guesses
<mdz> there's no way to tell authoritatively where the kernel in memory came from
<mdz> if there is, I'd like to hear about it
<lifeless> mmm, nice problem.
<ogra> mdz: probably through the build time ?
<mdz> it would be handy if the boot loader would give us an md5 or something
<mdz> ogra: that would be a good additional check, hmm
<mdz> would need to extract the string from the on-disk image
<mdz> mizar:[~]  strings /boot/vmlinuz-2.6.10-2-k7 | grep "^2.6.10-2-k7 (.*) #[0-9] "
<mdz> 2.6.10-2-k7 (buildd@rockhopper) #1 Wed Jan 19 17:18:18 UTC 2005
<ogra> mdz: i think the build machine hostname is in there too
<lifeless> what I was thinking was go module-dir -> dpkg for the package name, if thats missing is not official, then -> the image matching that module dir according to dpkg, and check the image md5sum
<mdz> lifeless: module-dir is the same as version number
<mdz> so what I currently do is take the version number, look for a package, and do some sanity checks
<mdz> I'm adding ogra's suggestion as an additional one
<dholbach> mdz: i guess naming it -tools or -utils is rather inconsiderable, just an expression of the current pent-up emotions, so i won't stop you there, i'll rather give my blessing :-)
<mdz> that should catch cases where the kernel has been upgraded, but the system hasn't been rebooted yet, also
<mdz> dholbach: hence the straw poll :-)
<lifeless> yeah
<dholbach> mdz: ;-)
<ogra> mdz: i found dholbach's suggestion "utools" quite nice :)
<mdz> 'u' is a bit overloaded
<ogra> true....
<ogra> but you save a dash
<lifeless> tools
<lifeless> ;_
<lifeless> :)
<ogra> hehe
<ogra> makes sure utf8 is working.... good idea
<mdz> hmm
<mdz> mizar:[~]  strings /boot/vmlinuz-2.6.10-2-k7 | grep "^2.6.10-2-k7 (.*) #[0-9] "
<mdz> 2.6.10-2-k7 (buildd@rockhopper) #1 Wed Jan 19 17:18:18 UTC 2005
<mdz> mizar:[/tmp]  cat /proc/version
<mdz> Linux version 2.6.10-2-k7 (buildd@rockhopper) (gcc version 3.3.5 (Debian 1:3.3.5-6ubuntu1)) #1 Wed Jan 19 17:18:18 UTC 2005
<mdz> these are not the same
<mdz> how irritating
<ogra> uname -a `
<ogra> ?
<lifeless> its built out
<lifeless> you should be able to synthesis it;)
<lifeless> (strings for gcc in the image too)
<lifeless> hmm, missing :p
<lifeless> garh
<lifeless> certainly you can reduce proc/version to the version string
<mdz> currently, yes
<mdz> but the fact that they come from different code means that they won't necessarily always match
<lifeless> true
<mdz> maybe they'll decide to stick the binutils version number in there too :-P
<lifeless> Linux version $ver $gcc $binutils $bz2 $build-uptime $number-of-butterflies $date
<mdz> kernel.version = #1 Wed Jan 19 17:18:18 UTC 2005
<mdz> that still leaves the user@host bit
<mdz> but version + date is damn good
#ubuntu-devel 2005-02-03
<sivang> ogra: knoppix has an ltsp server inbox?
<sivang> ogra: that is, in box
<ogra> it once had... i hvent seen knoppix since about two years...
<dholbach> sleep tight guys - i'm off to bed :-)
<sivang> dholbach: night!
<dholbach> bye sivang, sleep tight :-)
<sivang> yay, gnome-cups-manager identifed my HP printer now! cooool
<sivang> dholbach: oviderzane!
<sivang> (I probably have MANY mistaked there)
<ogra> night daniel
<sivang> mdz: ping again, would you like to send me a suggestin script for localizing the livecd? or is it a matter of installing language-support-XX into the cloop compressed img?
<sivang> mdz: I want to fill up the localization section also.
<dholbach> sivang: wow... if you pronounce "oviderzane" in english, it's nearly right :-)
<mdz> sivang: slow down; those packages were not even available until a few days ago
<dholbach> sivang: we spell it "auf wiedersehen" in german :-)
<sivang> dholbach: this is how i hear it :)
<ogra> sivang: learning german ? 
<dholbach> sivang: i didnt say it was wrong :-)
<sivang> ogra: trying hehe ;-) wish I knew some more..
<ogra> ssh ogra@sivang apt-get install language-support-de
<ogra> ;)
<sivang> dholbach: ok
<sivang> ogra: does it habve anyting inside it already?
<ogra>  language-support-de ?
<ogra> dunno....
<sivang> ogra: oh , it has some things in it already :) I am now installing
<ogra> sivang: it was a joke ;)
<ogra> sivang: i was installing it on you via ssh....
<kent> should python-xdg be expected to work? if that python module has support for the new freedesktop menu, then a simply menueditor for gnome should not be so hard to write?
<sivang> ogra: take a look at wiki/ServerTeam, would like to hear some thoughts
<sivang> (everybody else are also welcome)
<jdub> GOOOD MORNING FREEDOM LOVERS!
<sivang> jdub: MORNING!
<sivang> jdub: wiki/ServerTeam
<tseng> lo jdub 
<sivang> jdub: what about the pantalones?
<jdub> later in the day :)
<sivang> jdub: heheh
<jdz_> howdy :)
* jdz_ wants to learn how to make a .deb today
<jdub> yo jdz_ 
* sivang is after jdz_ in line ;-)
<lexhider> FTBS, can someone please define?
<chrisa> Perhaps you mean FTBFS?
<lexhider> probably, although the email I'm reading says FTBS, I don't know what either mean.
<chrisa> Failed to build from source for one, not sure about the other
<lexhider> thanks
<lexhider> I'll also add to glossary page on wiki
<jdub> whoa
<sivang> can someone suggest why I am not able to run g-s-t::users-admin from within my hoary chroot?
<sivang> jdub: you have an idea why is needed to do in order to run X/GNOME clients under a chroot?
<jdub> a crap load of everything
<jdub> you're better off using a debootstrapped chroot than a minimal chroot
<jdub> or uml or something
<jdub> first problem is that you won't have access to the display
<daniels> jdub: well, if you bind-mount $HOME, you get ~/.Xauthority
<daniels> (don't forget to bind-mount /tmp/.X11-unix for the transport)
<jdub> yeah, but that's just the start ;)
<daniels> well, running GNOME can be a pain
<daniels> never really did work out how to run multiple GNOME sessions as the same user on the same machine
<daniels> (different $DISPLAYs, obviously)
<jdz_> oh, thats a big proublem
<jdz_> with a 2nd gnome login, most of the applets are dead, genearly looks horable, etc
<sivang> eh well, I was not really looking to run the whole session, only some selected apps.
<sivang> jdub: ot
<sivang> erghh, crappy keyboard.
<sivang> jdub , daniels : it's amazing how much I learn that I do not yet know just from you answering my questions :) what is bind-mount? 
<sivang> (hmm, maybe mounting my original home folder from the chroot env?...)
<jdz_> sivang: mount -o bind /source-location /destination
<daniels> sivang: it basically glues two locations together
<daniels> sivang: i have /home/daniels/chroot/hoary-newx/home bind-mounted to /home, so it's like an exactly mirror
<daniels> sivang: think like a symlink, but works within chroots, etc
<sivang> daniels: cool, tnx
<sivang> daniels: so then for the duration of the bind mount my original home folder "vanishes" and the chroot one is used instead?
<daniels> sivang: yeah
<jdz_> They both exist :)
<daniels> /home in the chroot looks exactly like your usual /home
<daniels> (i assume you mean that the original /home you had in your chroot vanishes)
<sivang> yes
<jdz_> ah, right
<daniels> right
<sivang> daniels: so, any breakage I would create in the chroot's home, basically ruins my own home from the main system...
<sivang> sorry, s/chroot's home/chroot's user home folder/
<daniels> sivang: correct
<sivang> daniels: ok, tnx++
<sivang> phew, if you forget the bind mount gnome is also non usable on the other login...
<wasabi_> There some plan for gcc 4.0 anywhere?
<wasabi_> =)
<sivang> wasabi_: shush, don't let fabbione here you, he may be already awake...;-)
<wasabi_> haha
<wasabi_> I just actually noticed debian has it in experimental.
<sivang> wasabi_: that's like extra breakage sources for sid right? (it's not somthing more unstable then sid IIRC)
<wasabi_> I bet it's in there because of sarge.
<wasabi_> woh. it moved.
<sivang> when I have something like that in the debian/rulez, does that mean it uses cdbs?
<sivang> include /usr/share/gnome-pkg-tools/1/rules/uploaders.mk
<sivang> jdub: this is from the g-s-t source pkg.
<ajmitch> it looks similar to cdbs
<ajmitch> but is gnome-pkg-tools
<wasabi_> That's the peice of the gnome packages that adds the gnome package maintainers to it.
<wasabi_> It's an odd setup... Debian's pkg-gnome group.
<wasabi_> Packages have a control.in, with @GNOME_UPLOADERS@ in it.
<wasabi_> Each member of the pkg-gnome team has their name/email stuck in there.
<sivang> wierd
<sivang> wierd
<wasabi_> well, it works. It's so each member of the team can upload, but each person can remain the maintainer of their own packages.
<sivang> wasabi_: the control.in is supposed to be als oin that package? I'll look there..
<wasabi_> The control.in is in the package that uses gnome-pkg-tools.
<sivang> clean::	
<sivang> 	sed "s/@GNOME_TEAM@/$(uploaders)/" \
<sivang> 	debian/control.in > debian/control
<sivang> yep
<sivang> boy, emacs has such a nice coloring for make files..
<sivang> wasabi_: basically, all those include file and cdbs's are make file classes right? inherent feature of the make lanugage.
<wasabi_> yeah
<sivang> wasabi_: then it's really all sums up to what mdz/jdub said, if you start with reading the make manual, everything will look easier after..;-)
<sivang> (you have to finish reading it ofcourse)
<wasabi_> i never read the thing
<wasabi_> i still barely grasp it
* wasabi_ compiling gcc-4.0 for hoary
<sivang> wasabi_: so how do you manage to munge your daily dose of pkgs?
<sivang> cdbs?
<wasabi_> eh?
<wasabi_> sometimes.
<wasabi_> cdbs if possible.
<sivang> wasabi_: and on the other times? ;)
<wasabi_> For Eclipse, cdbs was impossible.
<wasabi_> So I learned make.
<wasabi_> actually basic make is really easy.
<wasabi_> learning how to set up your rules to actually make a package, and understanding debhelper, is a bit harder.
<sivang> I see.
<sivang> wasabi_: so , a quick question, I have a pacakge, all set and building/installing ok, I just want it to install another file in a specific location, how do I add this to the rules/dh_* commands?
<wasabi_> just copy it into the temp install directory before you run dh_builddeb
<wasabi_> probably using "install"
<sivang> ok, I'll try that, tnx.
<HostingGeek> hey my friend just told me a cool feature redhat has and that is /sbin/services is linked to /etc/init.d/
<HostingGeek> so you do services <app> restart...
<HostingGeek> it makes it a lot easier than typing out /etc/init.d/
<HostingGeek> even thought there is tab completion
<HostingGeek> but i know why redhat did it because they add rc.d
<HostingGeek> MonoDevelop is broken is this known???
<HostingGeek> anyone?
<daniels> HostingGeek: a) these things are still utterly inappropriate for #ubuntu-devel, b) invoke-rc.d, c) if it's broken, file a bug, don't harass people on irc
<daniels> we've asked you before repeatedly not to misuse our development channel and make it useless for us
<HostingGeek> daniels: /msg
<HostingGeek> daniels: did you ignore me?? why arnt you answer me
<crimsun> HostingGeek: your questions tend to be more suitable for #ubuntu (just an observation)
<HostingGeek> --- Cannot join #ubuntu (You are banned).
<HostingGeek> crimsun: and this is why i keep on msg daniels but he seemed to ignore me
<daniels> HostingGeek: i don't sit at the computer every waking hour; i was trying to print something
* fabbione yawns
<fabbione> hey daniels.. still around?
<daniels> hey papa
<daniels> let me test the drm stuff for you
<fabbione> what's up kid :-)
<daniels> nommuch man
<fabbione> no rush..
<daniels> just getting read to head out and see a movie
<fabbione> i just woke up
<fabbione> eheh cool.. what movie?
<daniels> ah cool :)
<daniels> blues brothers, actually
<fabbione> ehhe
<daniels> they have the moonlight cinema in this massive park ... portable screen, starts at sunset.
<daniels> ok, wget'ing now
<fabbione> oh that's nice...
<fabbione> daniels: no rush.. i just need to know within 24hours or so
<fabbione> today is dedicated to the house ;)
<fabbione> we have almost done with the big stuff in the livingroom
<fabbione> it's only left to paint the walls and do the small details
<daniels> oh, nice!
<daniels> that's awesome
<fabbione> i still have the glassfilt hitching my skin :-)))
<daniels> how long will the walls take?
<fabbione> daniels: 3/4 days
<fabbione> + another 2/3 days for details
<fabbione> the real problems are the waiting time for stuff to dry
<ajmitch> hi fabbione 
<fabbione> otherwise it wouldn't take THAT long
<daniels> yeah
<fabbione> hi ajmitch 
<ajmitch> just testing out selinux kernel stuff now
<daniels> ah, that's good then :)
<daniels> nice work dude
<fabbione> thanks :-)
<fabbione> daniels: i will put up pics when it's done
<ajmitch> after a number of build failures :)
<fabbione> you are one of the few that can see the diff ;)
<daniels> heh heh
<fabbione> Total 4570 package(s)
<fabbione> wow.. i already munged 50% of universe
<fabbione> but there were tons of FTBFS due to missing-deps
<ajmitch> alright, seeing plenty of audit messages related to tmpfs.. a good sign, I hope
<daniels> fabbione: hoy crap, that's insane
<fabbione> why?
<daniels> fabbione: i thought about cleaning up my room, but then xorg and l-r-m would lose a week of activity
<fabbione> do you realize that 100% of the big packages are in main?
<daniels> fabbione: the 50% of universe
<daniels> mmm, I suppose
<daniels> but there are still like a few gcc versions
<fabbione> daniels: only 2..
<fabbione> 2.95 and 3.2
<fabbione> that for sure are smaller than 3.3 (6 hours to build)
<daniels> not as bad as I thought then
<daniels> heh :)
<fabbione> probably... kernel-image- for sparc
<fabbione> that is relatively big...
<fabbione> but there is not much left really
<daniels> cool, that rocks
<daniels> you get the fun of qt/kde as well
<daniels> ah no wait, qt's in main
<fabbione> and already built :-)
<fabbione> i know there is a circular build-dep somewhere in kde iirc
<fabbione> but that needs to be solved manually
<fabbione> = at the really end
<daniels> heh
<fabbione> i need to remember to ask elmo/lamont to publish source-deps
<fabbione> there is one for debian, but i don't think we have one for us
<daniels> fabbione: no ABI change for radeon
<fabbione> cool, does it actually work?
<daniels> yeah :)
<fabbione> neat
<zenrox> what about my vid card
<zenrox> lol
<daniels> fabbione: and i915 is fine too
* daniels heads out the door.
<daniels> fabbione: thanks a heap
<fabbione> daniels: cool, have fun
<dholbach> hai
<HostingGeek> daniels: can gambas-gtk move into ubuntu already
<crimsun> HostingGeek: he's away at a movie.
<HostingGeek> why the hell will anyone want to be stuck with Qt?
<HostingGeek> crimsun: ok but can we still move it into universe?
<crimsun> HostingGeek: I don't even see a Debianized GTK portion
<HostingGeek> weirod
<HostingGeek> there site says it in debian
<crimsun> where?
<crimsun> `apt-cache search gambas|grep gtk' returns nothing.
<crimsun> note that gambas is already in hoary/universe
<HostingGeek> look at http://gambas.sourceforge.net/ > Distros & OS
<HostingGeek> ok
<HostingGeek> as linex.org is the maintainer for debian
<HostingGeek> and it is in linex.org 's rep but not in debian
<HostingGeek> for what ever reason can we just build the source packages from linex.org?
<crimsun> um, no. We want packages that are held to some QA standard, yanno.
<HostingGeek> QA?
<crimsun> you're familiar with quality assurance, correct?
<HostingGeek> yes
<HostingGeek> crimsun: linex.org IS the debian maintainer
<HostingGeek> i check it just now
* HostingGeek wonders why linex.org isn't the nvu maintainer
<crimsun> who, Jos L. Redrejo Rodrguez <jredrejo@edu.juntaextremadura.net>?
<HostingGeek> that linex.org
<HostingGeek> crimsun: i know from email linex.org over the nvu package
<crimsun> if he's the maintainer, then ask him why there's no gtk package.
<crimsun> [in sid] 
<HostingGeek> crimsun: well he is away he has no answered my email from a few weeks ago
<crimsun> HostingGeek: you could always (re)package it yourself and submit it for MOTU approval. That would speed along the process.
<HostingGeek> glade package needs rebuilding
<crimsun> It'd be wise to do thorough lintian checks.
<HostingGeek> "Couldn't show help file: glade-faq."
<crimsun> Are you saying Glade needs to be rebuilt in Hoary?
<HostingGeek> yes
<HostingGeek> goto glade > faq and you will see that error
<crimsun> then file a bug on the appropriate packages.
<HostingGeek> how the hell am i ment to file a bug if bugzilla is so slow
<HostingGeek> its been 12min and still haven't be able to file it yet
<HostingGeek> i have pushed new 8 times in bugzilla its done nothing
<HostingGeek> am i doing something wrong?
<HostingGeek> *yes* ok it working
<dholbach> gambas-1.0-1 seems borked - at least on amd 64
<crimsun> dholbach: from hoary/universe?
<dholbach> sizeof(CLASS) = 256 !  -  ERROR: #51: Bad archive: invalid argument 
<dholbach> crimsun: yes
* dholbach thinks . o O { what an informative error message } :-)
<crimsun> dholbach: not surprising.
<dholbach> does "new contact" work for you in evolution?
<crimsun> dholbach: yes.
<dholbach> hmmmmmmmmmmmm :-/
<dholbach> crimsun: i click the button and nothing happens
<dholbach> strange
<crimsun> 2.1.3.2-0ubuntu3
<dholbach> crimsun: yes
<crimsun> I'm sorry, I don't know of amd64 issues.
<Mithrandir> dholbach: hm?  evo broken on amd64 again?
<dholbach> Mithrandir: not sure
<dholbach> Mithrandir: doesnt have to be an amd64 issue
<dholbach> oh... i see: something f.cked up the addressbook: evolution-addressbook-WARNING **: error loading addressbook : e_book_load_uri: no factories available for uri `file:///home/daniel/.evolution/addressbook/local/system'
<dholbach> hmm
<HostingGeek> hmm WTF why does when connecting to a ftp server open in firefox?
<Treenaks> HostingGeek: shy are you asking on a developer channel, instead of a user-support channel?
<HostingGeek> Treenaks: because someone banned me from #ubuntu and i am showing them that it is a stupid idea as it will mean i'll use this one instead
<Treenaks> HostingGeek: you know it'll just get you banned here /as well/
<HostingGeek> Treenaks: well if you don't want me to ask here then you'll have to unban me from #ubuntu and i'll stop asking here
<thom> seb128: what's wrong with firefox? (and no, i don't mind)
<seb128> thom: bah, you have not add typeaheadfind to the list of extensions in debian/rules so basically the changes are not used :p
<seb128> s/add/added/
<seb128> thom: BTW chpe has updated the patch (added 2 little change)
<seb128> thom: all these change are just here to get a typeaheadfind which doesn't conflict with the firefox find stuff ... but you still need to build typefindahead :)
<thom> oh, doh
<thom> i can do that now
<seb128> bah
<thom> or you can
<thom> either way
<seb128> gnome.org is down 
<seb128> I've the changes here, I've built a new package
<thom> go for it then
<seb128> so if you want I can go ahead with it
<seb128> ok
<seb128> BTW how do you handle the changes ? you patch directly the sources ?
<thom> yeah
<seb128> ok
<thom> (it's a total pain, but so's trying to maintain a patch system when debin maints don't want it
<seb128> right
<dholbach> i'll be back later... bye
<jdub> seb128: you read gnome-vfs-list?
<ogra> morning...
<jdub> thom: so with firefox... :o
<seb128> jdub: yep, why ?
<jdub> thom: what are the chances of getting... pango patches for interesting script (indic, arabic) love; either industrial or the other gtk-like theme (which uses icon themes directly?); gnome native filechooser and printing patches?
<jdub> seb128: seen nielsen's patches?
<seb128> jdub: yep, waiting for alex's comments since the patch is not trivial :)
<jdub> cool
<seb128> jdub: make me remember than I've a patch for libsmbclient to upload
<jdub> sweet ;)
<seb128> (patch from the previous work from nielsen for the smb authentification)
<seb128> BTW has somebody tested smb with the current gnomevfs ? the authentification patch is already in and should improve things
<jdub> i'll have a play here, kind of a boring network though ;)
<thom> jdub: pango patches are in, just need turning on; I'll look at marco's patches for gtk-icon-theme love; firefox has the gnome filechooser dunnit? (don't know about printing, got a url?)
<jdub> thom: elite!
<jdub> firefox doesn't have the gnome filechooser without the fedora/novell patches
<jdub> i think you'll find the printing patches in fedora, too
<thom> oh, no, so it doesn't
<thom> right, will review those
<thom> (i think gtk-icon-theme support is more useful than garret's industrial theme, right?)
<jdub> thom: (i was thinking the same thing)
<jdub> thom: (but i haven't seen it in action)
<ogra> gah....warning: implicit declaration of function `strndup'
<ogra> how does one declare a function not implicit ?
<azeem> you #include the correct header file
<azeem> man strndup should tell you which
<thom> ogra: also, strndup isn't portable, it's a gnu extension
<azeem> that's what gnulib is for, I guess
<ogra> thom: its just for my ubuntu lockscreen hack, i doubt it will get used anywhere else....so nongnu wont be a prob
<smurfix> azeem: ? it's in glibc
<thom> ah, fair enough
<azeem> smurfix: or that
<thom> ogra: anyway, string.h and #define _GNU_SOURCE
<jbailey> smurfix: Portability, good. =)
<smurfix> thom: the other way round, actually ;-)
<ogra> great, thanks :-D
<azeem> smurfix: it was my understanding that gnulib includes the gnu extensions so you can have them on non-glibc systems
<mjg59> Argh.
<mjg59> There's no real chance of there being ACPI smart battery support integrated into the kernel before Hoary
<mjg59> Which isn't an issue in itself - we can add it with a patch
<mjg59> But the smart battery code presents different information in a different place to the control method battery code
<thom> jbailey: i'm planning to start scribbling about server team stuff monday or so; today is building furniture day
<mjg59> So the battery status app would have to be updated
<mjg59> Opinions?
<thom> mjg59: "Argh." summed it up quite nicely
<smurfix> azeem: only for non-glibc systems; on Linux it doesn' make sense to duplicate what's already in glibc
<azeem> smurfix: eh, sure
<azeem> thom was talking about portability, though
<jbailey> azeem: That's the general idea.  You put in configure hackery so that it uses glibc when possible.
<jbailey> thom: a'ight.  It was mostly the, "I'd like to be involved in this, I think I had alot to add"...
<mjg59> thom: It should be a simple matter of coding
<thom> mjg59: seriously, though, are the benefits of smart battery support worthwhile enough to do this before hoary? 
<mjg59> If we do it, Acer owners get battery status. If we don't, they don't.
<thom> mjg59: ... the "simple matter of coding" list is getting quite long ;-)
<thom> jbailey: nod
<mjg59> Ha. No, it's just going to be populating some structs in gnome-battery-applet
<jbailey> thom: In which timezone are you?
<mjg59> Ooh, rock
<thom> jbailey: GMT
<mjg59> HAL CVS has ACPI/PMU support
<jdub> oooh
<mjg59> Shame about the lack of APM, but still
<jdub> SHINY!
<thom> mjg59: oh, it landed? sweet!
<sjoerd> mjg59: no it has not
<fabbione> we should rename hoary to hoacpiry
<fabbione> we more acpi support than any distro out there
<jdub> fabbione: hnoapicoary
<fabbione> apic != acpi :)
<jdub> but it's the universal solution :)
<mjg59> There's also been some progress on the Thinkpad excessive power draw stuff
<fabbione> isn't apic = advanced programmable interrupt controller or something like that?
<mjg59> fabbione: Yup
<mjg59> noapic shouldn't be necessary on post-2.6.8 in general - the kernel no longer turns it on unless the BIOS did
<jdub> mjg59: rawk,
<jdub> s/,/./
<sjoerd> mjg59: apm stuff in hal should be easy though
<fabbione> mjg59: oh.. well it's an option we can fry away our configs you know :-)
<no0tic> hi
<mjg59> sjoerd: Yeah
<fabbione> mjg59: anyway.. next kernel new dri no ABI change ;)
<mjg59> fabbione: Fucking rock
<fabbione> mjg59: it was easy..
<fabbione> just a 2 lines change to revert the 4layer memory mm
<no0tic> thunderbird italian localization is stuck at version 0.9.99, and won't install with thunderbird 1.0
<no0tic> is help needed for translating?
<seb128> lamont: here ?
<mjg59> thom: We should probably post that PM stuff to -devel and get some feedback
* Mithrandir notes that postgresql is _not happy_ about being converted from 32 bit to 64 bit without a dump of the database
<thom> mjg59: indeed
<thom> Mithrandir: "gosh"
<pitti> Hi abelli!
<pitti> abelli: is your kernel happy now?
<abelli> actually im on the -2 now..
<abelli> ...CIAOOOO pitti
<abelli> but it still have some problems with the frame buffer
<abelli> the wifi, is ok now
<pitti> abelli: me too, but I have no idea how to fix it
<abelli> and im "spreading your word"
<abelli> ive asked how to do it... to the consolle project... 
<pitti> abelli: however, I hope to finish the porting to the current hoary kernel soon
<abelli> pitti: i hope someday ill be able to help you... :)
<abelli> s/ill/to
<mjg59> Argle.
<mjg59> So, we want Thinkpads to suspend without consuming large amounts of power, right?
<abelli> why not?
<abelli> :)
<mjg59> Option 1: Fix radeonfb and use it by default on Thinkpads with Radeons
<mjg59> (downside: arse to get the backlight back on afterwards)
<mjg59> Option 2: Write small module to do Radeon power management
<mjg59> (downside: makes it hard for people to use radeonfb)
<mjg59> Hrm. I probably need to talk to benh.
<daniels> mjg59: i like #2
<mjg59> daniels: Ok. Easiest way of doing this is to have a module that binds to the radeon PCI ids and has stub PCI suspend/resume routines to set the device to D3
<mjg59> Then we just have to try to reboot it on resume
<mjg59> But I need to speak to benh to find out if that's sufficient
<daniels> it sounds pretty sensible to me
<daniels> but then again, I am not benh, so it may be completely wack :)
<daniels> i'll tell you one thing that isn't, though -- bed
<dholbach> re
<ogra> hi :)
<jdub> mjg59: so you reckon i can suspend-to-ram my desktop? :)
<mjg59> jdub: It's worth a go
<mjg59> Hmm. I should really register for LCA
<jdub> what's the manual way of kicking suspend-to-ram?
<mjg59> If you don't have a sleep button, then try sudo /etc/acpi/sleep.sh
<jdub> ok, will try
<no0tic> fglrx keeps breaking resume?
<jdub> going to be regardless though
<jdub> mjg59: oh, interaction with nvidia driver?
<mjg59> Likely to suck
<jdub> heh
<jdub> here goes
<jdub> night
<mjg59> no0tic: fglrx stands no real chance whatsoever across suspend/resume
<jdub> hrm
<jdub> doesn't seem to do anything
<mjg59> Anything in demsg?
<jdub> nup
<jdub> just an old usb disconnect message
<mjg59> Interesting.
<mjg59> Can you edit /etc/acpi/sleep.sh and add set -x just before it starts running commands?
<jdub> oh
<jdub> hold on
<jdub> heh
<jdub> # Uncomment the next line to enable ACPI suspend to RAM
<jdub> #ACPI_SLEEP=true
<jdub> ^ important point
<jdub> night :-)
<mjg59> Haha
<jdub> didn't work
<dholbach> oh this is funny: evolution-data-server talks a bit in dmesg too: evolution-data-[8358]  trap divide error rip:2a9555e6cd rsp:7fbffff340 error:0
<mjg59> jdub: Failure mode?
<jdub> didn't even get usb key/mouse or network love when it came up
<jdub> let alone video
<mjg59> Oh, it suspended but didn't resume?
<jdub> yeah
<mjg59> Right. Hrm.
<jdub> (both suspend and hibernate work very nicely in windows, if that's an even remotely useful datapoint)
<mjg59> Haha
<mjg59> Hibernation ought to work
<no0tic> mjg59: hibernation works also here with radeon (acer aspire 1350 series)
<no0tic> brb
<no0tic> re
<no0tic> can fglrx & radeon coexist?
<no0tic> can I create 2 different config files? one for fglrx & one for radeon and switch from one to the other restarting X?
<lamont> seb128: back on much later today
<thom> seb128: do you want to leave firefox till monday and let me do it?
<pitti> lamont: Hi! Out of interest, to the buildds already strip?
<pitti> lamont: s/to/do/
<ogra> pitti... got a sec for PM ?
<pitti> ogra: PM?
<Mithrandir> rock!  svn seems to be b0rken on amd64.
<Mithrandir> at least libapache-mod-svn
<seb128> thom: I've it ready to upload here, I just had to go and wanted to run a quick diff with the previous version to be sure 
<Riddell> lamont: any idea what the status of kdebindings is on ia64?  there no log and other platforms succeeded an hour ago
<azeem> man, you Ubuntu guys are spoilt
<ogra> azeem: because we have a lamont and elmo ?
<HostingGeek|ZZZ> sry about nick changes just registering a few
<mdz> jdub: you have received the title of "all-familiar Ubuntu man"
* ogra grins
<robertj_> heya all, question: should I file a bug about the 30 boot fsck
<robertj_> I mean, it's really no fun for laptops
<ogra> robertj_: who reboots his laptop if suspend works ?
<robertj_> ogra: well, it's still bad, and mine still does'nt work
<robertj_> I thought it did
<thom> robertj_: current fsck won't run when you're on battery
<thom> so it's not an issue
<robertj_> thom: maybe something didn't upgrade right?
<ogra> robertj_: mine neither (because i use nvidia drivers)
<robertj_> i dist-upgraded less than a week agp
<robertj_> err ago
<robertj_> ogra: radeon here
<ogra> robertj_: binary drivers ?
<robertj_> ogra: whatever ships by default
<robertj_> but I do have multiverse in so ...
<ogra> robertj_: ah, so the free ones :)
<robertj_> anything I should check to see what's causing the problem?
<ogra> robertj_: with the binary ones its unlikely that susped will work :(
<thom> """
<thom>   * E2fsck will try to avoid doing a forced filesystem chcek if a system
<thom>     is running on batteries according to APM or ACPI.  (Closes: #205177)
<thom> """
<thom> From an e2fsprogs upload in November
<ogra> robertj_: you can adjus it
<ogra> adjust even
<robertj_> ogra: adjust what?
<robertj_> but it did fsck on battery
<ogra> robertj_: the 30 reboot fsck
<robertj_> yeah
<robertj_> G3 ibook
<robertj_> i'd prefer my desktop machine not fsck either
<ogra> robertj_: man tune2fs
<thom> robertj_: it's possible that we need to load modules or do something smarter, but the code is there
<robertj_> ogra: I just mean by default
<ogra> robertj_: even if its annoyin to get a check after 30 mounts, i prefer a consisten fs ;)
<ogra> consistent...
<robertj_> ogra: why is your fs getting corrupted?
<ogra> robertj_: no, but a check more cant be bad :)
<robertj_> yes it can
<robertj_> say you are in a hurry
<robertj_> then waiting would be bad
<thom> robertj_: i don't think it's something we want to turn off by default
<ogra> robertj_: i like the data on my hd, so getting told that everything is in order is just fine
<thom> we'd love to see it be interuptible, patches accepted
<robertj_> thom: I support a 100 mac users and they have never had any problems with file integrity on OS X except for one issue I heard about where after an upgrade ever drive from a particular manufacturer got corrupted
<robertj_> thom: on the disk applet it would be a really nice option
<robertj_> check here to check the disk panel every 30 boots/10 days/whatever
<robertj_> check here to mail this address when SMART indicates a problem
<ogra> SMART should get a dbus message that pops up automatically.....
<ogra> as a full disk should have
<robertj_> ogra: yeah
<thom> robertj_: sounds great, looking forward to the patch ;-)
<robertj_> hehe
<ogra> *g*
<thom> robertj_: seriously though, i've seen just about every filesystem blow up, journalled or not (HFS+ with journal included)
<robertj_> "Your disk is about to die. Turn off your computer and call an expert."
<ogra> robertj_: i would implement these two for hoary, but i'm busy with something else....
<ogra> robertj_: your disk is about 95% full !!
<robertj_> thom: seen stable machines have stuff eaten for lunch?
<ogra> robertj_: like irix does :)
<robertj_> ogra: irix has implemented dbus ;)
<ogra> robertj_: yup :)
<robertj_> home users just don't want to wait though
<ogra> robertj_: and inotify ...and fam....thats where they come from....
<robertj_> if the file system really does go nutz, that's the problem, not the failure to check
<ogra> robertj_: so get aboard and implement it for them: https://www.ubuntulinux.org/wiki/MOTU
<ogra> ;)
<robertj_> ogra: i'm sure I actually could manage to hack out the fsck checks by default, but if everyone doesn't agree it would be rather pointless
<ogra> robertj_:fsck isnt universe :-P
<thom> robertj_: the thing to do, is to ensure that fsck runs in the foreground and make sure it copes with being ctrl+c'd
<robertj_> thom: it does cope well for servers
<robertj_> but not for desktops, but what's right for desktops aint for servers
<thom> robertj_: eh?
<thom> robertj_: can you ctrl+c fsck while it's running in init currently?
<ogra> thom: shouldnt be a prob since it is able to cope with ctrl-c if being run manually
<robertj_> thom: yes, but it wont boot
<robertj_> it drops you to a single user console
<thom> exactly
<robertj_> ro
<thom> robertj_: make it not do that, or make it optional
<robertj_> I mean, so it works, but it's not the "working" my Dad would consider working
<thom> we're on the same page
<robertj_> yeah
<robertj_> thom: oh btw, usb keyboards dont work at that point
<robertj_> unless they are in legacy mode
<ogra> robertj_: hmm, does your dad know about ctrl-c ?
<robertj_> so if you wanted to opt out, you couldn't
<thom> that would seem like the optimal solution...
<thom> meh
<robertj_> thom: why should the fs be randomly corrupted though unless it's a hardware problem? And if it's a hardware problem, wouldn't bringing the machine down for a reboot  be the wrong choice of action
<robertj_> I'm not an expert here by an means
<robertj_> but you got to spin the drive around sometime to get the data off unless you have a _lot_ of money and time
<thom> robertj_: the timed checks just help to ensure correctness; what's the old saw about "an apple a day keeps the doctor away"?
<ogra> heh
<robertj_> it's annoying and probably not that helpful to 99% of people
<thom> i think most people don't actually care, tbh
<thom> it's not like it actually takes that long on modern hardware
<ogra> robertj_: its not more annoying then a virus check once a week (over all files on your 80Gig disk)
<robertj_> just remember that anyone supporting any kind of non-technical user will get called in to look anytime usersplash boot is interrupted
<robertj_> and virus check runs at night or what not
<robertj_> but most people don't have a reboot in cron
* ogra watches GFs notebook doing the weekly check on win....(since 1hr)
<robertj_> ogra: I honesty can stay I never see my machines to virus checks
<robertj_> f-secure is a great product for what it does
<ogra> robertj_: yup, but my GF wants to see directly if viruses are detected, so the check is run on saturday evening every weeeeek
<Riddell> groovy, kdebindings compiled
<Riddell> lamont: could you put back amarok on amd64?  or will it do that itself?
<robertj_> ogra: well it prompts you if it finds it
<robertj_> when is usually when you try to open the attachment
<sivang> pitti: ping
<robertj_> finding this a week later is not the best way to do it
<ogra> robertj_: sh likes to watchit work ;)
<pitti> sivang: pong
* sivang waves to the whole wonderful ubuntu devel crowd
<ogra> she even
<robertj_> but anyway, I think schedule fscks on by default just aren't right for most desktop users
<ogra> sivang: i have looked at the server page....its ok this far....
<sivang> pitti: Just seen the post about the locales depends for the language packs, maybe there is a possibility of of asking the user when installing the pack if he wants his locale modified and created?
<robertj_> anything that can be reasonably done after bootup is good, but by default anything that could disrupt their non-gui experience is a bad thing if it can be at all avoided
<ogra> ARGH
<pitti> sivang: nooooooo
<pitti> sivang: this is not what debconf is for
<ogra> did anybody ever check this ubuntuguide ? 
<pitti> sivang: the locale can be created without asking
<ogra> http://ubuntuguide.org/#extrarepositories
<pitti> sivang: but the default locale should not be modified
<pitti> sivang: you can easily set it in gdm, or if you want, with dpkg-reconfigure locales
<sivang> pitti:I know that, but I was thinking maybe there is an automatic way to do this for the "uninitiated" localized distros..;-)
<pitti> sivang: but you can already set the default locale in the installer
<sivang> pitti: ah ok, then, I would love you to show me this - I'd like to create a proof of concept dervied livecd/installer cd
<sivang> pitti: (localized)
<ogra> OMG, anybody following this guide will totally f**ck his system with marillat stable unstable and testing anebled at the same time and the backports in...
<pitti> sivang: but AFAIK the live cd also uses some degenerated sort of installer, right?
<ogra> gah
<sivang> pitti: yes ;-)
<pitti> sivang: so this installer should ask for the default locale
<pitti> sivang: (which is to be put into /etc/environment)
<sivang> pitti: hmm, ok, when the kbd selector is done, this is all redundent. You are right! 
<sivang> pitti: (new kbd selector smurifx is working on would guess the person's locale)
<pitti> sivang: s/ask/determine and set it/
<sivang> pitti: yep, ok, it's all matter of waiting for this to be ready, cool enough. I shall respond to that person post then, explainig this. He is very keen to have this added to the language pack.
<pitti> sivang: as I already replied, I think it makes perfect sense to generate the relevant locales in the langpacks
<sivang> pitti: so you're saying to move the locale generation from the installer to the langpack based on the info that the intelligent kbd chooser put in /etc/evnironment?
<sivang> pitti: (thus eliminating the need for dpkg-reconfigure locales manually)
<pitti> sivang: hmm, not quite. /etc/environment handles the default, and this should be set in the installer
<pitti> sivang: and this default can be changed with e. g. dpkg-reconfigure locales
<pitti> sivang: and I am still not sure about who does the locale generations; eventually it might get thrown out of the "locales" package
<sivang> pitti: ok, I just understood from your last email that you don't think that the locale generation should happen on installation of the langpacks..
<sivang> pitti: I understood wrongly then ;-)
<abelli> ciao, buona notte, im off
<pitti> abelli: cu
<abelli> ciao pitti
<sivang> eh, quite sunday evening in u-d..;-)
<ajmitch> or monday morning for us unfortunates
<ogra> ogra land is at 22:10
* ajmitch is fighting with udev :)
<sivang> sivang land is 23:18
<HrdwrBoB> bobland is 0818
* ogra would love to be in bobland, even if its monday there :)
<HrdwrBoB> haha yes but I have to go to work, where I have to deal with people, before midday! it's inhumane
<ogra> hehe
<ogra> but pay your rent, doesnt it ?
<ogra> pays even
<HrdwrBoB> yes, that it does :)
* ogra has never had a job he hates as much as this one, but it pays good
<HrdwrBoB> ah, I don't hate mine so much, though I will probably have to leave (I'm a contractor now, when the job goes fulltime the salary will go down >25%)
<ogra> HrdwrBoB: btw, why are you not a MOTU yet ? you do a lot for ubuntu ....
<ogra> HrdwrBoB: yeah, consuling pays :)
<HrdwrBoB> I dunno I just hang around and help people with stuff
<HrdwrBoB> :)
<ogra> go on, join in :)
<HrdwrBoB> I'll see about it later :) in the meantime, my tram is waiting
<HrdwrBoB> catch you later
<ogra> ciao
<srbaker> so i want to take evolution, rip out the mail client, and make it use rubrica for address book.
<srbaker> anyone know the evo code well enough to know whether or not that's feasable?
<srbaker> balsa is a little uh, strange
<Mithrandir> srbaker: just replace the addressbook backend, very much feasible.
<srbaker> hrm.
<Mithrandir> srbaker: bit of work, though.  And you want to do it in evolution-data-server, naturally
<Mithrandir> and you want to add a new type, not remove the current one
<srbaker> well, i hate evolution.  but i think it would make a good mail client ot start from
<srbaker> i quit using evo in favour of balsa.  and balsa is quirky, too
<srbaker> are there any Free groupware servers that evo can talk to?
<thom> hrm, http://www.clearairturbulence.org/new-ikea-stuff/img002.jpeg.html ; it's not a bad collection
<HrdwrBoB> thom: that's very similar to http://hrdwrbob.net/gallery/table/p1010028 this one
<HrdwrBoB> though that's My Fiances desk, so she's only got one machine
<thom> HrdwrBoB: heh
<thom> i'm kinda scared that i only had a laptop 12 months ago
<kent> thom, is that two Billy's? the ones you have the books in.  I have two of them myself (they are called Billy at Ikea in sweden)
<HrdwrBoB> the desk is jerker
<thom> kent: exactly those, yes
<thom> HrdwrBoB: yeah
<mjg59> thom: http://www.codon.org.uk/~mjg59/tmp/junk.jpg
<HrdwrBoB> haha that desk looks more like mine
<HrdwrBoB> large piles of detritus
<mjg59> That's /after/ I cleaned everything
<thom> mjg59: heh
<thom> my a500 is out of shot
<kent> mjg59, that bottle of wine makes it soo romantic ;)
<thom> i've not worked out where to put it
<thom> (pa-risc, not amoeba)
<mjg59> kent: What you can only just make out is the bottle of vintage port behind the keyboard...
<kent> vintage port?  
<mjg59> Yeah
<kent> it is some kind of red wine right? i didn't understod if you corrected me for being wrong about the wine or not :(
<mjg59> Oh, sorry - there's a bottle of wine next to the speaker, and underneath that there's a rather nice bottle of vintage port
<kent> mjg59, i dont realy fancy red wine. Im more a white wine person. I have a bottle of "Franconia Silvaner 2002"  in my room. It tasted very good, :)
<sivang> mjg59: do you recall the module you told me need to be added to the Xorg.conf for nv driver to work with higher reolutions then 640x480? (now that susped works with nv)
<mjg59> sivang: Uh, not off-hand I'm afraid
<HrdwrBoB> ahh, red wine is fine .. white wine makes me stop breating (allergic), but mead is excellent
<mjg59> The problem is probably that you've got missing modelines in your Xorg.conf
<sivang> mjg59: yes, so did daniel commented about this
<mjg59> Best bet is to wait for daniels to show up, he's been working on this
<sivang> mjg59: ok, cool.
#ubuntu-devel 2005-02-04
<Riddell> what is the name of the new user friendly application install tool in hoary?
<HrdwrBoB> gnome-app-install
<Riddell> is it an ubuntu made project?
<HrdwrBoB> I beleive so
<Riddell> "ImportError: No module named glade" looks like it's missing a dependency there, time to dig up my bugzilla account
<jdub> mdz: haha, yeah.
<jdub> mdz: i think that means bignose on the cover.
<Riddell> "gobject.GError: Icon 'gnome-settings-default-applications' not present in theme" can anyone tell me what package that icon is in?
<mjg59> jdub: I found a nice picture of the inside of Cockfosters station
<jdub> mjg59: NOOOOOO!
<jdub> Riddell: gnome-icon-theme and gnome-accessibility-themes
<mjg59> jdub: http://www.charlesholden.com/html/charlesholden_gallery_pages/Cockfosters_1.htm
<mjg59> Dig the funky concrete roof
* jdub refuses to look.
<mjg59> Hahaha
<mjg59> jdub: If I want to do LCA and the Canonical conference and congratulate you on being a married man, what dates do I need to be in Australia?
<HrdwrBoB> LCA is at the most inconvenient time ever
<HrdwrBoB> March 23; contract expires. April 18-23 LCA, April 30th my wedding
<jdub> mjg59: wedding party is on the 17th, linux.conf.au is 18th-23rd, UbuntuDownUnder will be 25th to 30th.
<mjg59> Rock
<jdub> HrdwrBoB: haha :)
<jdub> HrdwrBoB: our honeymoon is lca ;)
<jdub> (not!)
<mjg59> jdub: Party in Sydney?
<HrdwrBoB> haha :)
<jdub> yass (outsiude of canberra)
<kent> what is LCA?
<HrdwrBoB> linux.conf.au
<mjg59> Heh. I guess I'll probably be flying in and out of Sydney
<HrdwrBoB> linux conference in canberra Monday April 18 to Saturday April 23, 2005.
<thom> UDU is sydney, right?
<jdub> yeah
<mjg59> Yeah
<jdub> most likely
<mjg59> It's neat that Ubuntu pretty much just works on the Mac Mini
<jdub> mjg59: oh?
<mjg59> jdub: According to -usres
<mjg59> Someone should write a Wiki page on it and then SELL SELL SELL
<mjg59> Hmm. I can get one for 300 quid with educational discount.
<jdub> that's fantastic news!
<jdub> "48 hours after receiving my Mini I have decided it is not the machine for me. If you would like to purchase my Mini, it is on eBay."
<jdub> weird
<thom> are the hoary livecds rsyncable now?
<thom> jdub: 48 hours seems very short
<HrdwrBoB> I'd get a mini if it had a useful 3d card
<mdz> mjg59: how do you go about getting the discount?
<mdz> thom: yes, they are
<mjg59> mdz: I sign a solemn pledge that I'm a student at a university on the Apple discount program
<HrdwrBoB> mdz: find a friend/family member who is working for/going to an educational institution and get them to buy it
<mjg59> But I can do that online and then order online as well
<jdub> thom: yeah, they are
<mdz> mjg59: oh, ok.  you don't have to promise that you're a swell guy, or anything like that?
<jdub> mdz: dude
<jdub> mdz: so how much policy for the rest of the image is defined in the d-i stage?
<jdub> mdz: much more than the kernel?
<mdz> jdub: meaning what?
<jdub> mdz: i'm wondering about using the POWER OF CASPER for booting other system images, such as red hat.
<mdz> jdub: I wrote it with such use cases in mind
<jdub> obviously the kernel would be an issue, but beyond that, everything else pretty much restarts, right?
<mdz> all the stuff that I've added falls back gracefully if things aren't the way it expects
<mdz> the bits that come directly from d-i probably need tweaks in that area
<mdz> e.g., locale configuration and network configuration
<mjg59> mdz: Haha. Nope.
<mdz> jdub: the only issue with the kernel is that the modules in the image need to be loadable by the kernel on the CD
<mdz> and we could make that a non-issue if we really wanted to
<mdz> just costs some space on the CD
<mdz> jdub: you should be able to build a live CD with isolinux menu options for Ubuntu, Debian, Fedora, Gentoo, etc. with a small amount of work
<jdub> heh -> two kernel monte with a livecd ;)
<mdz> s/CD/DVD/
<thom> mdz: ok, grabbing all the live cds now; will hopefully be in a position to test i386,ia64,amd64 by morning
<mdz> thom: excellent
<thom> it's nice having a desk again ;-)
<thom> now i just have to work out why grub can't see my sata disks, and i'm laughing
<mjg59> 305.50 including delivery
<mjg59> I wonder what kind of PM setup it has. Presumbly something very iBookish.
<thom> mjg59: yeah, all macs should expose PMU to some degree
<mjg59> I need some Mac hardware for PM testing
<sivang> thom: what chipset? I have also SATA , wonder if they'd work - ICH5 I think I have..
<thom> sivang: can't remember; it's onboard the motherboard i have. i suspect the disks have just come disconnected in the process of moving
* mjg59 wonders why the two routes he has to the education store give different prices
<mdz> how very IBM
<sivang> thom: it's a desktop right?
<thom> sivang: yeah
<sivang> thom: well, just opend up the cover and check the cables then
<thom> sivang: oddly, i just checked windows and disk manager can see the drives
<mjg59> Does anyone have the faintest idea what http://groups-beta.google.com/group/uk.comp.os.linux/msg/ab1c6387c8463151?dmode=source is going on about?
<tseng> full threaded smp support?
<tseng> userspace support for smp, heh
<tseng> mjg59: I think its possible that he has a really poor understanding of NPTL/TLS
<HrdwrBoB> just another gentoo crazed person
<jdub> oh man
<jdub> "Ubuntu is worth the install just for the little drum beat that greets you at the login.
<jdub> "
<jdub> ^ murray cumming
<tseng> i smiled at that too, jdub 
<tseng> i was thinking about his point on su being unintuative
<jdub> "I mean, if I do su then it shouldn't just ask me for a password when there's no possible correct answer."
<jdub> ^ good point
<jdub> haha, yeah
<tseng> that perhaps it could give some more useful info and point to an FAQ
<tseng> on failure.
<mjg59> Hmm. That's a claim I hadn't heard before - Miguel wanted to take up a job with MS, but ran into INS-related problems.
<mjg59> Perhaps unsurprisingly, I can't find any independent corroboration.
<thom> i'd heard that before
<mjg59> Oh, no, there's an Andrew Orlowski article on The Register which says that
<jdub> hah, orlowski.
<jdub> 10:46 < mjg59> Hmm. That's a claim I hadn't heard before - Miguel wanted to
<jdub>                take up a job with MS, but ran into INS-related problems.
<jdub> 10:47 < mjg59> Perhaps unsurprisingly, I can't find any independent
<jdub>                corroboration.
<jdub> boh
<mjg59> You suck
<jdub> oh, putty is *SO* ANNOYING
<HrdwrBoB> now I've heard the claim twice
<mjg59> http://www.theregister.co.uk/2002/02/05/explain_yourself_miguel_demands_rms/
<mjg59> I  RMS
<jdub> so /bin/su could do the same thing that sulogin does; checks whether the root password is not set
<mjg59> What should it do in response?
<thom> and then tells you to use sudo?
<thom> but only if it's not being run from sudo, as in sudo su -
<jdub> well, then it's already root
<jdub> surely this is something upstream would take?
<jdub> su is pointless if run as a user with no root password set
<jdub> it should return some error - could that error be external to the binary?
<jdub> or perhaps configured at build time would make sense
<thom> jdub: su - www-data -c foo still has to work, fe
<jdub> then you're not su-ing to root ;)
<thom> no, but you just said: "su is pointless if run as a user with no root password set"
<jdub> well, it could check whether the target account, whatever it may be, has a password set
<thom> :P
<thom> yeah
<mjg59> jdub: Telling someone that there's no root password set is information leakage
<jdub> we are talking about the su-to-root use case here ;)
<mjg59> On the desktop, I don't think it matters. But I don't seem upstream taking it.
<jdub> mmm, and it couldn't just fail, hey?
<jdub> same problem
<thom> it's not something you'd want on a server, for sure
<jdub> hmm.
<mjg59> If it's an administrative decision not to have a root password, random users shouldn't be able to find that out
<mdz> jdub: su: you don't even have a chance! (exit 1)
<robertj> mjg59: i saw that page you pointed to, I think RMS needs to realize that Free software cannot exist in compliance with patent law
<mjg59> robertj: Which one?
<robertj> http://www.theregister.co.uk/2002/02/05/explain_yourself_miguel_demands_rms/
<mjg59> Oh, right.
<robertj> mono & gnome
<mjg59> RMS doesn't seem to have strong opinions on patents yet
<mjg59> Or, rather, the correct way of dealing with patents and free software
<kent> godnight.
<ajmitch> hi jordi 
<pitti> night, guys!
<robertj> Does anyone else find the Desktop Label for the System menu confusing?
<sivang> robertj: hmmm, should be "System" ? ;-)
<robertj> I mean, most of that stuff isn't on my Desktop
<robertj> and what does your desktop have to do with rebooting?
<sivang> hehe
<sivang> Should be syste, but I don't want to start the gnome menus fights again...
<sivang> ;-)
<sivang> Desktop maybe should be "places"?
<robertj> Is that a Gnome thing or an Ubuntu thing
<robertj> I know upstream talks were going on but..
<jdz_> sivang: There's already one called "places"
<robertj> Computer or System is a much better name
<sivang> jdz_: eh right, oops ;-)
<jdub> robertj: current layout is both ubuntu and upstream.
<robertj> it just doesn't seem intuitive
<robertj> why  was System nixed?
<tseng> robertj: if you think about it, to alot of people Computer = Desktop
<tseng> no?
<jdz_> tseng: or laptop, as is my case
<jdub> robertj: there's a discussion bug on gnome's bugzilla about this
<robertj> tseng: yeah, but to a lot of people Desktop = Desktop
<tseng> and what does Computer mean anymore than Desktop does in the context of the stuff in the menu
<tseng> About Gnome?
<jdz_> I propose we call it "Stuff"
<robertj> That's better than Desktop
<tseng> i propose that the name is mildly important
<robertj> at least Stuff makes you think "here is some various stuff"
<robertj> vs. "Here is what is on my desktop"
<tseng> robertj: about gnome = version info about my "desktop"
<ajmitch> jdz_: you might as well call applications 'stuff', and desktop 'more stuff'
<tseng> screenshot is a sshot of my "desktop"
<jdz_> ajmitch: very well :)
<HrdwrBoB> ajmitch: that sounds like my naming scheme
<ajmitch> it's generally how I'd organise things anyway :)
<robertj> should dragging a file to a launcher pointing to a folder move the file?
<HrdwrBoB> move/copy yes
<robertj> "the Gnome Desktop" is different
<robertj> but by that logic Gnome would be a better name
<ajmitch> looks like I need more packages from sid again..
<bob2> which ones?
<ajmitch> selinux stuff that I'm working on
<ajmitch> thankfully rjc said he'd write some debian policy for udev, so I'll be able to boot my system properly :)
<robertj> is it at all possible for usb to be brought online before fsck's run?
<sivang> daniels: ping
<daniels> pong
<jdub> hmm
<sivang> daniels: do you remember the module name you told must be in my xorg.conf file for the opensource nv driver to work with higher resolutions then 640x480 ?
<sivang> (trying to use standby, must use nv driver)
<jdub> hrm
<jdub> so /dev/hdc isn't created before hdparm is run at rcS.d/S07
<ajmitch> jdub hmm?
<ajmitch> udev should be running at S04, right?
<jdub> it does indeed
<jdub> but probably takes its sweet time
<jdub> hrm
<jdub> who can i assign an hdparm issue to...
* jdub chooses thom.
<daniels> sivang: er, you just need HorizSync and VertRefresh lines for nv
<ajmitch> does udev run in the background while creating the device nodes?
<ajmitch> or does everything still block on it?
<jdub> init.d/udev runs udevstart
<jdub> so nothing really blocks on it
<jdub> (it was hotplug that was the big blocker)
<ajmitch> yeah, udevstart being a symlink
<ajmitch> I've been having some problems with it in the last couple of days when an selinux policy has been loaded by init
<ajmitch> trying to get it sorted :)
<ajmitch> so I doubt that it'll make feature freeze
<robertj> jdub: is there a way to determine if a ps/2 keyboard is connected?
<jdub> no idea
<robertj> jdub: because back to the fsck issue, not only is it annoying to laptop/home users, its also really annoying to people running servers on macs
<jdub> which fsck issue?
<robertj> running before usb comes online
<robertj> because if it stops and you don't have a live cd you can't tell it to continue
<jdub> oh right
<robertj> (kinda related to my gripe about the scheduled fscking by default)
<robertj> could that be avoided by building in usb stuff?
<robertj> ?
<mdz> robertj: the usual way to manage that situation is that the BIOS will emulate a PS/2 keyboard if only a USB keyboard is available
<mdz> unfortunately, some of them don't
<mdz> you can always load the USB drivers in the initrd
<daniels> mdz: (or it's configurable, and defaults to not doing so)
<mdz> yeah, "USB legacy blahblah" or whatever
<robertj_> mdz: didn't knnow that
<opi> or, instead of initrd, you can put it into kernel :-)
<robertj_> although it doesn't make much sense for a mac to emulate a legacy keyboard
<robertj_> ;)
<jdub> basic usb key driver in the initrd isn't a terrible idea
<robertj_> what sort of problems might it cause?
<mdz> opi: "sudo vi /etc/mkinitrd/modules" is much more maintainable than building your own kernels
<mdz> jdub: all of hotplug in the initrd isn't a terrible idea
<opi> mdz: I guess, I just used to build kernel without help of Debian tools
<mdz> at least, storage, input, network
<robertj_> mdz: that would make my toaster angry
<jdub> mdz: waiting for initramfs :)
<mdz> jdub: don't hold your breath
<mdz> robertj: how so?
<jdub> heh
<robertj_> ram limits ;)
<opi> ahh, 4:08 Am
<opi> I should start packing to work ;)
<HrdwrBoB> mdz: that would be good, I didn't move a hard drive to a different controller the other day purely because I didn't want to stuff around with initrd
<mdz> the hotplug infrastructure is only a few hundred K uncompressed; shouldn't make the initrd much bigger at all
<ogra> opi: hehe, same here
<opi> ogra: I'll be first in the office (yet again;-)
<ogra> opi: i'm working hadrly on getting fired ;) i'll not be there before 12 :)
<opi> ogra: and they say the labor maket is tigth. ;p
<robertj_> mdz: but what modules do you load in?
<opi> ogra: I'm chasing deadlines, so I have to work 19h per day do get there before end of the month
<ogra> opi: maybe, but i cant stand digital tv ...
<opi> ogra: I don't even have a TV ;p
<robertj_> opi: eek, I hope you get paid well!
<ogra> heh
<HrdwrBoB> tseng: the initrd has them all already
<opi> robertj_: haha, sorry, nope
<HrdwrBoB> er robertj_ 
<opi> robertj_: I'm just workoholic, I could work for a butter ;p
<robertj_> Hrdwr: hrmm, so just sitting around waiting for hotplug to bring the monline eh
<opi> and coffeine
<mdz> robertj_: the -hcd driver for the controller, and usbhid, should get you a working keyboard
<robertj_> opi: eek, I need more challenging work
<HrdwrBoB> opi: excellent, come and work for me I will pay you in food scraps and old hardware
<mdz> as a matter of fact, this desktop has a BIOS which doesn't give me proper USB emulation, so I've been meaning to do that myself
<robertj_> I'm on site like 30 hours a week and work like 10 ;)
<opi> HrdwrBoB: sorry, I could give you some spare hardware, too ;))
* ogra has just finished something.....
<ogra> jdub.....patch sent :-D
<opi> HrdwrBoB: and .au is a bit far ;p
<jdub> ogra: rockin :)
<ogra> jdub: yay
<ajmitch> .au is just a short swim for me..
<ajmitch> hi azeem 
<HrdwrBoB> hha
<opi> grrr. fsck!
<opi> damn, stupid Gnome terminal :(
<opi> https://bugzilla.ubuntu.com/show_bug.cgi?id=5716 -- is there a way to avoid this? Or should I just use XTerm?
<HrdwrBoB> use gvim?
<tritium> Hi.  Is the "Developer Resources" page on the wiki gone?  I can't find it.
<HrdwrBoB> I beleibe it's a screen/gnome-terminal problem
<opi> HrdwrBoB: I prefer to SSH to my box at work
<mdz> that screenshot does not seem to show vim
<HrdwrBoB> opi: ssh -X :)
<mdz> ah, the second one does
<opi> mdz: it's VIm after screwup
<opi> mdz: yeah, I made a mistake ;)
<HrdwrBoB> opi: looks like a website to me
<opi> HrdwrBoB: second one
<opi> GTK file selector fooled me again ;)
<opi> HrdwrBoB: tell that to my ISP ;p
<tritium> mdz, you mentioned on the devel mailing list that resources to be found on "Develop Resources" wiki page would help track status of openoffice.org 2.0
<tritium> mdz, could you please point me to that wiki page?
<mdz> tritium: DeveloperResources
<opi> tritium: see topic
<mdz> is what I wrote in the email, and is also the name of the page
<tritium> sorry, I searched for "Developer" and "Resources" on the wiki, and didn't get a hit
<jdub> search doesn't find stuff in titles haw haw
<tritium> I didn't think to concatenate the two words
<tritium> I see.
<mdz> tritium: there is a bug where searching for the title of a page doesn't find the page
<tritium> mdz, okay, thanks.  And sorry to bother you.
* mdz pummels Plone
<opi> it's not a bug, it's a feature ;0)
<opi> like VIm screwup
<opi> ;-)
<tritium> my whole point of searching for the "resources" you mentioned was to avoid pestering you
<opi> tritium: I think mdz is not mad at you :)
<tritium> opi, yeah, glad I'm not pummeled like Plone :)
<opi> tritium: that would be $50, thank you ;P
<mdz> plone has felt my wrath before
<tritium> opi, check is in the mail
<opi> tritium: I hope it's not made from rubber ;p
<opi> tritium: anyway, it should go to mdz 
<tritium> oh, it'll bounce
<opi> actualy, some newbies fall for that
<opi> when a newbie came to #debian.pl and ask for help
<opi> someone lead him for hand
<opi> and after, when the problem was solved,
<opi> he told him: That would be 50 PLN 
<tritium> poor newbie
<opi> some people was willing to pay, untill we told'em it's a joke around here
<opi> person a) hi guys, what's up? b) nothing, that'll be 50 PLN.
<tritium> Actually, donations to your paypal account are reasonable, especially since you send out free CDs
<opi> we just like helldesks
<opi> free CDs are here thanks to Canonical
<jdz_> Thanks Canonical!
<opi> ;p
<tritium> indeed
<opi> I hope the Horay CD will be even better designed
<opi> or, maybe not, because of that everyone take my Ubuntu CDs away ;)
<robertj_> is free shipping going to continue
<tritium> I going to pass the Hoary PPC Live CD around Purdue's ECE department.  All the faculty have macs, and are impressed with how I've setup my lab with ubuntu.
<opi> from what I read, yes
<tritium> I'm going to convert Debian's own birthplace into an ubuntu stronghold.
<opi> but I guess you should ask Canonical guys
<robertj_> I'd love to get billed $10 per release and get my 10 cds
<tritium> I'd pay for CDs as well.
<opi> you can get'em free and donate, no? :)
<jdz_> Same here.  Actually, what'd be totaly awsome, would be DVDs.  Throw all the supported packages on there.  Good for those of us with limited bandwidth.
<robertj_> opi: well lazyness factors in
<robertj_> id rather just they show up
<opi> jdz_: DVD won't have Universe
<opi> jdz_: a) it won't fit b) it's not supported ;p
<jdz_> opi: I realise that.  But a DVD with supported would be awsome.
<opi> jdz_: DVD will be there, when main will be too big, methinks
<opi> jdz_: Ubuntu should be 1-cd-distro
<opi> so, next step is DVD
<robertj_> I hope next step is cd
<opi> I wonder, is there any pager with ability to use escape codes (color in that case)
<opi> I did a CGI script for something, that outputs in different colors, depends on success
<opi> if I'll log it, less won't show it correctly
<mdz> jdz_: a DVD with all of supported is already produced on a weekly basis
<mdz> http://cdimage.ubuntu.com/weekly-dvd/
<jdz_> mdz: oh!  totaly awsome!  thanks :D
<mdz> it would benefit from more testing
<jdub> mdz: currently only install, right?
<mdz> jdub: yes
<mdz> jdub: why, do you think a live DVD with all of supported installed would be a good idea?
<jdub> mdz: haha
<jdub> mdz: livedvd with supported install and normal live image :)
<jdub> mdz: i thought that was the goal?
<mdz> ah, yes
<mdz> we're not quite there yet
<jdub> although a livedvd with massive chunks of supported would be an enjoyable idiocy ;)
<mdz> opi left, but "less -R" is probably the answer to his question
<jdz_> mdz: I was wondering about that too, so thanks for the answer anyways :)
<sivang> mdz: it would allow us to reach the netless people that are still out there...
<sivang> ;-)
<fabbione> morning
<fabbione> jdub: 5431
<mdz> fabbione: morning
<fabbione> morning mdz
<jdub> fabbione: thanks
<fabbione> jdub: did you try installing hoary on your sparc? or do i need come there and kick your butt around to do that? :P
<jdub> haha
<jdub> it's installable now?
<fabbione> it should be
<fabbione> if you don't try you will never know
<jdub> with netboot.iso, tftpbooting?
<fabbione> sparc.u.c
<jdub> ok
<jdub> ta
<fabbione> yeah that should work
<mdz> no iso yet?
<fabbione> dists/hoary/main/installer-sparc/current/images/sparc64/netboot/boot.img
<fabbione> jdub: ^^
<jdub> fabbione: what do you test on?
<jdub> elite
<fabbione> jdub: netra t1
<fabbione> mdz: no, and no ubuntu-meta either...
<fabbione> mdz: that's why i asked you to add sparc to germinate/seeds & co. :-)
<mdz> fabbione: I don't remember that
<mdz> germinate is Kamion's baby, and it should be trivial to include sparc
<fabbione> mdz: it was on friday i think, but i also said that there was no rush
<mdz> which packages need to be seeded?
<mdz> silo?
<fabbione> mdz: he was mumbling something about using sparc.u.c since germinate has no concept of multiple archives
<mdz> ah, right
<mdz> same problem with ubuntu-meta
<fabbione> silo, silo-installer, sparc-utils should do...
<whiprush> i can help test sparc this week, we have an assortment of them at work.
<fabbione> whiprush: that would be cool, but keep in mind i did test only 2 installation
<fabbione> and it is not a supported arch yet
* whiprush nods
<fabbione> so if it fails you are kinda on your own ;)
<whiprush> heh, it's ok, they're doing nothing but sitting around anyway.
<fabbione> and patches to fix problems are more welcome than bugs :-)))
<jdub> fabbione: burned.
<fabbione> uh?
<fabbione> that's tftp boot dude
<fabbione> or did you burn the mini.iso?
<jdub> hahaha
<jdub> no, i mean, machine is burned.
<jdub> toasted.
<fabbione> */sparc64/NETBOOT/boot/*
<fabbione> ah
<jdub> serious namespace issues with mr. cdrom
* fabbione isn't completely sure what jdub is mumbling about.. it must be some aussies dialect
<mdz> mumble mumble coopers mumble mumble kangaroos
<HrdwrBoB> mumble telstra mumble assgobblers mumble
<fabbione> mdz: would you bless a message to announce for the sparc port?
<fabbione> or should we wait for ubuntu-meta to be in place?
<mdz> fabbione: ubuntu-meta doesn't seem like a prerequisite, no
<fabbione> isn't that required to install ubuntu-desktop?
<fabbione> ubuntu-base & co...
<mdz> only if you try to apt-get install ubuntu-desktop or whatever
<mdz> d-i uses the Task: header instead
<fabbione> ok
<fabbione> mdz: i am going to send a mail to you for itaglish proof reading :)
<mdz> you should have an Itaglish project in Rosetta
<mdz> and then I could translate
<fabbione> eehhe
<daniels> mdz: what's that, it_EN?
<mdz> it_FABIO
<fabbione> ahah
<opi> with my Engrish, I deserve to have my own Rosetta place
<opi> pl_OPI or something ;)
<jdub> fabbione: kernel panic, couldn't find libc :)
<jdub> fabbione: on mini.iso
<jdub> 'attempt to access beyond end of device'
<fabbione> jdub: that's a mini.iso boot parameter that might be wrong
<fabbione> you can try to increase the ram size for the initrd
<jdub> from silo?
<fabbione> it's a kernel parameter
<fabbione> wait a sec...
<fabbione>         append vga=normal initrd=debian-installer/i386/initrd.gz ramdisk_size=12358 root=/dev/rd/0 rw  --
<fabbione> this is what is added to i386 pxeboot
<fabbione> so you need to twick the ramdisk_size
<jdub> tops, that worked
<jdub> now at language screen
<daniels> http://linux.slashdot.org/article.pl?sid=05/01/24/0515248&tid=90&tid=163&tid=106
<fabbione> daniels: hey. install your sparc kid!
<jdub> fabbione: ok, after the language/location/keymap questions, it loops clearing the screen
<jdub> fabbione: debian-installer/framebuffer in the ps output
<daniels> fabbione: give me an archive to mirror off :)
<fabbione> daniels: sparc.u.c :-)
<jdub> fabbione: which is stopping and starting
<fabbione> jdub: hmm that's clearly a d-i bug
<daniels> fabbione: rsyncable?
<fabbione> jdub: you can switch to vty2 and change the script on the fly to avoid restarting
<fabbione> daniels: yeps
<jdub> actually, it's debian-installer itself that keeps restarting
<fabbione> i probably didn't see this problem because i am on console only mode
<fabbione> we will have to ask Kamion about it.
<fabbione> i am not sure how much he changed in the fb section recently
<fabbione> jdub: can you try to use the older installer?
<fabbione> there are 2 versions hanging on sparc.u.v
<fabbione> hem .c
<jdub> 20041227ubuntu5?
<fabbione> yup
<jdub> on its way
<fabbione> i have older ones in the morgue but it will be easier to ask Kamion when he is back
<ajmitch> fabbione: kernel options checked out
<fabbione> ajmitch: good
<fabbione> mdz: you got mail :-)
<fabbione> mdz: if you can proof read it and change what you think should be changes, it would be great
<mdz> fabbione: I always od
<mdz> do
<fabbione> mdz: you don't always get mails from me :-)
<mdz> I got mail from Lisa Clayton about online IT courses
<fabbione> wow.. that'd be cool
<fabbione> i never get mails from Lisa :-)
<sivang> mdz: who's Lisa? ;-)
<mdz> she mails me all the time
<fabbione> bah people must stop filing bugs with url to the forums
<fabbione> mdz: lucky you
<mdz> sometimes about viagra, sometimes about IT education, sometimes about discounted copies of MS Windows
<fabbione> i would take the latter :P
<sivang> mdz: hehehe i get mine from caroline bedford...
<sivang> intersting..
<sivang> ;-)
<sivang> I even get urge requests to allow some .za millonare to put all his money in my account until he can take it back..when he comes back there..It amazing how much variation of this email are out there.
<daniels> i gave my bank details to a .za millionaire
<daniels> my balance even went up a bit after that
<sivang> daniels: heheh
<sivang> daniels: sure, if it was him, I'd give him my bank account before he could say "Eureeka" ;-)
<daniels> mdz: the message hasn't come to me, but we actually have a driver for that specific wireless kill switch in hoary -- fsam7400
<mdz> message?
<daniels> mdz: the mailing list message about wireless kill switches
<bob2> daniels: does hotplug load your bluetooth modules?
<daniels> i think so, yeah
<mdz> daniels: you have bluetooth devices?
* bob2 renames his laptop "unlovedbyubuntu"
<daniels> mdz: my phone has bluetooth love
<mdz> Mark made a request for better bluetooth integration in Hoary
<mdz> what are we missing?
<daniels> i don't know as to things other than phones; all i use is gnome-bluetooth and gnome-phone-manager
<daniels> basically for sending the photos i take with my camera phone to my computer
<daniels> i never did get syncing to work; that would be absolutely killer in general
<mdz> bob2: Ubuntu loves all
<daniels> even those who didn't buy IBM laptops
<jdub> mdz: i've got some build fixes to do
<jdub> mdz: then some input testing
<mdz> daniels: there are laptops which aren't made by IBM?
* mdz makes a cross with his fingers
<crimsun> jdub: how far along is the polypaudio transition, and what can I do to assist?
<bob2> gnome-bluetooth doesn't seem to be installable atm
<daniels> mdz: apparently there's an 'x300' or some shit.  sounds like a cheap ripoff of the x40.
<jdub> crimsun: we should do it straight away
<jdub> i think
<bob2> I hear some fruit company is making laptops now too
<bob2> jdub: fix gnome-bluetooth
<jdub> bob2: see above
<bob2> jdub: oh
<bob2> jdub: well then :)
<chrisa> bob2: I hear those laptops break a lot
<bob2> chrisa: only when used to beat jealous non-believers
<chrisa> bob2: The one in my backpack was never used for such beatings
<fabbione> ajmitch: so is there any other CONFIG option i need to change or TMPFS_XATTR is the last one?
<fabbione> mdz: 5749, any idea?
<fabbione> could it be related to the new alsa changes?
<crimsun> fabbione: I doubt it
<crimsun> fabbione: 5749 needs to attach lsmod output for 2.6.10-1 and 2.6.10-2
<crimsun> fabbione: reads like an irq issue or the secondary codec
<fabbione> crimsun: can you just ask for it?
<fabbione> i am in the middle of a build orgy :-)
<crimsun> fabbione: I'll do that.
<enrico> Hello.  Is there a collective e-mail for the sysadmin team?
<enrico> I mean, sysadmins for the Canonical server farm
<jdub> 'james.troup@canonical.com'
<enrico> Ok.  I thought there was a team with more than one person
<fabbione> crimsun: thanks
<fabbione> jdub: meh! there is also thombot!
<fabbione> ciao enrico
<enrico> fabbione: ciao!
<daniels> admins@admins.warthogs.hbd.com IIRC
<enrico> daniels: thanks!
<pitti> Morning!
* fabbione hides from pitti
<fabbione> hey dude :-)
<pitti> fabbione: no reason to, I don't have new kernel vulns :-)
* pitti yawns
<fabbione> ah that sounds cool
* opi yawns, too
<opi> I need to wake up
<pitti> I should go to bed earlier...
<opi> I shouldn't get up around 2:00 am ;)
<pitti> elmo: please sync awstats
<fabbione> edd: ping
<daniels> keybuk!
<Keybuk> ello
<jdub> morning
* daniels takes a bone and invites Keybuk to join in the picking.
<fabbione> bella Scott1
<daniels> Keybuk: so.  automake.  libtool.
<jdub> seb128: ping
<seb128> jdub: pong
<jdub> yo!
<jdub> morning
<jdub> does your nautilus-sendto work with gaim?
<seb128> hey hey :)
<seb128> afaik yep
<daniels> seb128: how's that keyboard bug going? :)
<jdub> hmm
<jdub> i only get evo in the little menu
<Keybuk> daniels: right?
<seb128> at least here it works if I active the plugin in gaim
<jdub> oh!
<jdub> aha :)
<seb128> apparently you have not :p
<daniels> Keybuk: see my unimpressed face
<seb128> evince 0.1.1 uploaded :)
<jdub> seems a bit bong that you have to turn on a gaim plugin :|
<seb128> agreed
<daniels> Keybuk: the common code has some power management symbols, which are used for back-and-forth references with os-specific code
<jdub> FIE ON GAIM
<seb128> jdub: perhaps there is a way to turn the default for the plugin ?
<jdub> (i almost typed gamin)
<jdub> seb128: probably in gaim pref defaults -> ick
<daniels> Keybuk: once I solved the fact that those got cleaned up automatically (having a libcommon_a_WHOLESOURCES for --whole-archive would be nice), I ran into the awful static interdependency thing
<jdub> ooh
<daniels> Keybuk: so I made a shared archive, but libtool won't make shared archives for noinst
<sivang> seb128,pitti,others : morning
<jdub> sendto is great
<seb128> :)
<pitti> Hi sivang!
<daniels> jdub: a pox on gaim, eh
<HrdwrBoB> a pox on gamin too, while we're at it
<sivang> pitti: How are you ?
<HrdwrBoB> why not be thorough
<Keybuk> daniels: yeah, Libtool does; noinst_LTLIBRARIES gives you a "convenience library"
<pitti> sivang: fine, thanks! I made good progress with postgresql 8 yesterday :-)
<sivang> pitti: ah cool, you may want maybe to add something about it to wiki/ServerTeam ?
<daniels> Keybuk: in the end I disabled power management in order to think about it later, so the OS-specific code didn't call back into common in that regard, but ugh
<daniels> Keybuk: just seems a bit wack that how your library's built depends on the install process
<fabbione> elmo: ping
<pitti> sivang: hmm, what shall I add there?
<jdub> seb128: haha, you can't get files, can you?
<jdub> FIE ON GOSSIP
<jdub> seb128: hrmph.
<jdub> seb128: evince... hrmph.
<seb128> jdub: you sent a file ?
<jdub> seb128: yeah ;)
<seb128> jdub: I thought than file transferts were only working for msn accounts
<jdub> gaim seems to think it can send
<seb128> can you send from gaim ?
<seb128> or only with nautilus-sendto ?
<jdub> both
<seb128> hum
<sivang> pitti: maybe something on support it has under ubunut, actually it may be only some info mainly for "marketing" the fact ubuntu is very suitable at being for example, or a suggestion how a pakcage can be made to make ubuntu with single apt-get a prefect out-of-the-box sql server? ;-) 
<pitti> sivang: hmm, currently I do postgresql in my spare time, and usually maintain it through Debian
<sivang> pitti: ah right..
<pitti> sivang: I did not yet talk with sabdfl/mdz about a particular Ubuntu PostgreSQL support
<sivang> pitti: ok, cool, I was just thinking we should start maybe working towards wiping the "desktop distro" thing, I think one thing that could be done as a starters is making meta packages that pull some sever + a gui controller app for it, so admin would get a working environemtn (if not optimised yet) by one apt-get install. one of the ideas I had wrt that.
<daniels> Kamion: ping
<seb128> Keybuk: just commented on  #5562 for you
<fabbione> daniels:
<fabbione>  dpkg-reconfigure xserver-xorg
<fabbione>  /var/lib/dpkg/info/xserver-xorg.postinst: line 1075: [: : integer expression expected
<daniels> fabbione: PENDINGUPLOAD :)
<fabbione> daniels: ok
<fabbione> let me guess...
<daniels> fabbione: (happens if you don't have a recent-enough xresprobe; I bumped the Suggests to >= 0.4.13, but we don't Depend on it)
<fabbione> it's related to Horiz and Vert sync/rate
<daniels> fabbione: yeah
<daniels> fabbione: when $DISPTYPE is empty (i.e. xresprobe didn't tell us)
<daniels> there's a -n $DISPTYPE on it now
<fabbione> daniels: i have 0.4.13 installed
<Keybuk> seb128: yeah, I just replied
<daniels> fabbione: bong
<daniels> unreproducible
<daniels> let me check it out later
<daniels> i have an xorg upload in the queue here, as well as dbus
<daniels> and I have to eat too :)
<fabbione> i am checking it now
<daniels> thanks
<daniels> but yeah, IIRC that's an empty $DISPTYPE
<Mithrandir> more likely an empty NRES
<Mithrandir> since it's not assigned to at line 1075
<daniels> oh, right
<daniels> yes, I've fixed that locally also :)
<Mithrandir> that's assigned like 20 lines later.
<daniels> maybe that's why I couldn't reproduce it
<Mithrandir> heh
<daniels> yeah, that test is now below the NRES thing
* fabbione sighs
<Mithrandir>     NRES=0
<Mithrandir>     for i in $RESOLUTIONS; do
<Mithrandir>       NRES=$(expr $NRES + 1)
<Mithrandir>     done
<Mithrandir> dude, you know about $#, don't you?
<fabbione> uh? no
<fabbione> i remember i wrote that
<Mithrandir> actually ${#RESOLUTIONS}
<fabbione> ugly but effective
<Mithrandir> at least if $RESOUTIONS is an array
<fabbione> no it's not..
<fabbione> it's a list in a string i get from xresprobe
<Mithrandir> yeah, it can't be an array.  posix sh sucks.
<Mithrandir> and ${#RES} would be the string length.
* Mithrandir stops blubbering and goes to get a switch fixed.
<pitti> elmo: please sync enscript
<daniels> alternately, we could use NRES=$(echo $RESOLUTIONS | wc -w)
<Kamion> daniels: yes?
<Kamion> geez, about a million people were looking for me this weekend
* Kamion assumes anything important got mailed
<jdub> did you get a strange sms? :)
<thom> jdub: you better not have filed a duplicate bug about hdparm :P
<jdub> it was not clearly duplicate :)
<thom> not duplicate on "hdparm: run too early"? ;-)
<Kamion> jdub: phone out of battery at the moment, will no doubt get it eventually ;)
<jdub> heh
<thom> right, lets see how this live cd goes
<fabbione> hey Kamion 
<fabbione> Kamion: can you read the scrollback when you have time? jdub did a test install on sparc, but apparently something in d-i broke fb between ubuntu5 and ubuntu6
<jdub> elmo: ping
<jdub> fabbione: reminds me... ;)
<eruin> any chance of getting updates for linux-restricted-modules for 2.6.8 (k7) ? 2.6.9 incorporates a change in ptrace that breaks cedega/copy protection, while 2.6.10 won't boot due to bug#5582
<fabbione> jdub: wasn't the loop that d-i was restarting?
<eruin> I can't use nvidia-glx since the linux-restricted-modules I have for 2.6.8 is nvidia6111, and for some reason I have to reinstall the official drivers on every boot to fix a memory segment fault...
<eruin> oh so sorry if this comes across as whine ;)
<Kamion> fabbione: I saw that in scrollback, but it doesn't mean I know what's going on
<Kamion> fabbione: and, you know better. ubuntu5 and ubuntu6 of what?
<thom-live> hrm, this live cd thang is pretty sweet
<fabbione> Kamion: d-i
<Kamion> the debian-installer source package just assembles the output of other packages
<fabbione> Kamion: perhaps jdub can give you more info :-)
<thom-live> basically the only problem is the lack of monitor probing on amd64...
* thom-live pokes daniels
<Kamion> fabbione: anyway the only likely candidate for change there is the kernel
<fabbione> Kamion: right... the lists should be on sparc.u.c
<Kamion> it's your port, you get to debug it :)
<Kamion> diff the initrd.list files
<fabbione> Kamion: i know. but it's unlike that i  know all the bits of all the code out there :-)
<Kamion> rootskel didn't change, busybox changed but not in a way that's interesting for that, and nothing else but the kernel is liable to be relevant
<Kamion> ah, no, busybox actually didn't change
<fabbione> jdub: where was the installer hanging or looping?
<jdub> fabbione: seemed to be on initialising or configuring the fb
<jdub> /dev/fb0 existed
<jdub> /proc/fb existed (nothing in it)
<Kamion> /dev/fb/0 surely
<jdub> yeah, sorry
<jdub> seb128: no gnomemeeting 1.2.0?
<seb128> jdub: ups, that's because it's in experimental and nobody as asked a sync ...
<seb128> jdub: and they have not released for ages so I've forgotten about it
<jdub> ;)
<seb128> I'll update it :)
<jdub> hrm, got a few here
<jdub> some are recent, some are not
<eruin> http://209.96.136.140/images/Screenshot.png
<eruin> are you guys tracking fedora patches like that?
<thom> gack. Need to get 464MB/465MB of archives
<thom> eruin: ym the gtk filechooser?
<thom> eruin: yeah, will be
<eruin> yeah
<eruin> ok :)
<fabbione> jdub: is there something relevant in /var/log/ ?
<fabbione> iirc d-i stores all its logging bit somewhere there
<Kamion> /var/log/ before reboot, /var/log/debian-installer/ after reboot
<jdub> i'll have to try it again in a while
<fabbione> Kamion: accoring to the diff on the list there are plenty of udebs that are changed :-P
<fabbione> according even
<fabbione> Kamion: http://www.fabbione.net/udiff <- anything that rings a bell?
<seb128> elmo: pwlib sync from experimental please
<Kamion> fabbione: yes, I already looked at that list myself
<Kamion> fabbione: anna doesn't run until later. casper-check's irrelevant. cdebconf hasn't started yet. di-utils is irrelevant. file-preseed is irrelevant. hotplug-udeb is a possibility I suppose, but you get to check that. initrd-preseed's irrelevant. kbd-chooser runs later. libdebconfclient0-udeb hasn't started yet. libnss-dns-udeb's irrelevant. localechooser and main-menu run later. preseed-common, rescue-check are irrele
<Kamion> fabbione: the only possibility I see is hotplug; porting that is your job. :-)
<Kamion> seriously I can't afford to give debugging time to unofficial ports at the moment; if unofficial means anything, then it must mean that ...
<fabbione> Kamion: yes i understand. i didn't ask for a fix, but for the right direction to look at. and i posted the diff because i didn't get that you already looked at it
<fabbione> thanks for your time anyway
<Kamion> pitti: is language-pack-* guaranteed to depend only on stuff in base, or is it allowed to depend on things in desktop?
<Kamion> pitti: and what should server installations do?
<pitti> Kamion: language-pack-[update]  only depends on a recent libc6
<pitti> Kamion: so, yes, only base
<pitti> Kamion: the bigger problem is language-support
<Kamion> would it make sense to install language-pack-* in the first stage?
<Kamion> or should it be a second-stage thing?
<pitti> Kamion: these packages depend on packages in supported, not only in shipped
<Kamion> that's not a problem
<pitti> Kamion: I would favor second
<Kamion> well, not a soluble one
<Kamion> not all the language packs will fit on the CD so they can't all be shipped anyway
<pitti> Kamion: would it be possible to try to --dry-run the installation of language-support before actually doing it?
<Kamion> no we'll just try to install them and ignore failures
<pitti> Kamion: then the installer would not install the support package if no network is present
<Kamion> not necessary
<pitti> Kamion: okay, same effect
<pitti> Kamion: so the support package is installed if dependencies can be fulfilled on CD (or from network), and not installed otherwise?
<Kamion> yes
<pitti> cool
<pitti> Kamion: server installations should not install support
<pitti> Kamion: however, they should probably install language-pack
<Kamion> if its dependencies can't be fulfilled then germinate will not allow it to be on the CD anyway
<Kamion> ok
<pitti> Kamion: btw, what do you think about moving locale generation from package "locales" to language-pack-XX?
<Kamion> see my mail to the list
<pitti> Kamion: then we don't need the first debconf question any more
<Kamion> I don't think it's appropriate to *move* it
<pitti> do in addition?
<Kamion> yeah
<Kamion> pitti: which first debconf question?
<pitti> Kamion: the locales question of which locales to support
<pitti> (not shown usually, though)
<Kamion> some people were saying some very scary and wrong things in scrollback about having the keyboard selector thing imply a locale
<Kamion> pitti: that's a useful question to have for experts, it shouldn't be removed
<pitti> okay
<pitti> so l-pack would just add its locales (if not already present) to /etc/locale.gen and call locale-gen
<Kamion> (keyboard selection can't imply a locale; they're totally orthogonal things ...)
<Kamion> yeah
<Kamion> and depend on locales, if it doesn't already
<pitti> it doesn't already
<Kamion> ok, will need to
<pitti> sure
<pitti> cool, so array 4 could already have a full language pack support installer?
<Kamion> I'm working on the base-config changes, they're kind of tied in with better kickstart support
<Kamion> yeah
<pitti> neat, then I will see to add the locale generation stuff soon
<Kamion> need to decide which language packs to put on the CD though
<pitti> ^ probably a tb item?
<Kamion> probably
<pitti> I remember sabdfl saying something about 10 to 15 supported languages
<pitti> right now all the langpacks don't use much more space than before
<Kamion> disk space on CD may trump sabdfl ;)
<pitti> since the same files now get stripped from the application debs
<Kamion> sabdfl < laws of physics < baby jesus
<pitti> but in the long run, and with Rosetta, translations will grow :-)
<pitti> lol
<Kamion> hm, have you seen the languagelist file in localechooser?
<Kamion> it has a list of fallback locales for each language
<pitti> no, I did not see it
<Kamion> I'm wondering if we should install all the language packs matching locales listed as fallbacks
* pitti downloads
<Kamion> that would mean most languages would get language-pack-en which is probably a useful thing, and e.g. Norwegian would get Danish and Swedish too as fallbacks
<Kamion> or Galician would get Spanish
<pitti> hmm, sounds as if it would make sense
<pitti> I now have the list on my screen
<pitti> however, why should German folks use en_GB?
<mvo_> seb128: is there already a open bug that nautilus-cd-burner does not allow blanking a RW?
<Kamion> *shrug* that doesn't matter, it'll map to language-pack-en
<Kamion> it's just a fallback, it has to be a full locale but it's not very important which it is
<pitti> Kamion: right, but en is the fallback to most/all languages
<Kamion> yes, that's good :)
<seb128> mvo_: correct
<mvo_> seb128: a word from upstream when it will get fixed :) ?
<seb128> mvo_: http://bugzilla.gnome.org/show_bug.cgi?id=164352
<pitti> Kamion: well, e. g. es as a fallback to Galician makes sense
<seb128> mvo_: no, no reply at all
<Kamion> this means we can ask for some English locale while debugging
<seb128> mvo_: but if you umount it or try again it works
<pitti> Kamion: but installing en everywhere seems a bit too much...
<Mithrandir> Kamion: I'm a bit reluctant with having other nearby languages as fallbacks, actually.  Having a UI with Norwegian and English is a lot less cluttered and confusing than Norwegian Bokml, Norwegian Nynorsk, Swedish, Danish and English.
<Kamion> hmm] 
<Kamion> ok, let's just have the native one for now then
<pitti> Kamion: in any case I would only install the main support package with no fallbacks
<Kamion> it'll actually be Norwegian and C, not Norwegian and English ;)
<Kamion> pitti: sure
<Mithrandir> (this is a gripe of mine currently as well, though)
<pitti> Kamion: since with no langpack you get C (so, usually English) anyway, is there really a need for l-p-en?
<Kamion> pitti: English != C
<Kamion> pitti: it makes a difference for en_GB sometimes
<pitti> right, but approx. :-)
<Kamion> please don't kill l-p-en
<pitti> should be good enough for debugging output
<mvo_> seb128: it looks like n-c-b should just ummount (or ask for it) ?
<pitti> Kamion: no, I won't kill l-p-en
<Kamion> 11:27 < Kamion> ok, let's just have the native one for now then
<pitti> Kamion: for British/American folks, it really makes sense
<seb128> mvo_: it's supposed to do, and that was working with the previous version ...
<pitti> ack
<mvo_> seb128: ah ... thanks!
* jdub eats kangaroo fillet burgers for dinner
<jdub> MMMMMMM!
<jdub> you guys can wait until april :)
<thom> jdub: bastardo!
<thom> jdub: oh, tesco sells timtams here now
<fabbione> thom: since when you speak italian? ;)
<thom> fabbione: since jeff eats kangaroo
<thom> ;-)
<fabbione> haha
<jdub> thom: no way!
<thom> yeah, coffeee just got better ;-)
<jdub> haha
<jdub> tea drinking pansy
<jdub> where is Keybuk anyway?
<thom> pfft, hot drinks rights activist
<jdub> haha
<ajmitch> mm, kangaroo..
<thom> seb128: we should close #980, right?
<seb128> thom: correct
<seb128> thom: BTW are you going to fix #3042, I don't remember what you said about it
<seb128> (and #3044)
<mjg59> fabbione: You have crack
<mjg59> (mail)
<fabbione> ARGH
<fabbione> Uploading via ftp linux-source-2.6.10_2.6.10-11.diff.gz: exiting due to user interrupt.
<seb128> mjg59: have you planned to update dasher in debian ?
<mjg59> Hahaha
<mjg59> seb128: I will do - there's currently a crasher bug in the latest tarball
<seb128> ok
<thom> seb128: oh, right
<thom> yeah
<seb128> so I'll wait :)
<seb128> thom: cool, thanks :)
<fabbione> mjg59: still nothing in my inbox...
<mjg59> fabbione: #5807
<mjg59> Fix for ACPI regression
<fabbione> i see
<fabbione> dude.. can you reduce that patch to what is really needed?
<fabbione> bah i guess i can apply all of it
<mjg59> The other big bit of code is useful anyway - it makes things work with a slightly wider range of broken DSDTs
<fabbione>   * More Matthew Garrett crack:
<fabbione>     - Add patch stolen-from-head_acpi_fix_regression.dpatch.
<fabbione>     (Closes: #5807)
<fabbione> you get also mentioned in the changelog!
<fabbione> isn't that cool?
<fabbione> :P
<fabbione> food time
<mjg59> Haha
<fabbione> ajmitch: are you around?
<ajmitch> yes
<ajmitch> sorry about the late info
<fabbione> CONFIG_AUDITSYSCALL is not portable to all the arches
<ajmitch> ok
<fabbione> i am going to keep it off for now
<ajmitch> I haven't seen it being used yet
<fabbione> ok
<thom> fabbione: is the additional speedstep centrino support patch already in hoary, or is that part of todays upload? (just so i know to ping some bugs or not)
<fabbione> thom: you mean the dothan_p4 fix?
<thom> yeah
<fabbione> today upload
<fabbione> -11
<thom> cool
<fabbione> :)
<thom> fabbione: is it worth setting the default elevator to "cfq"?
<fabbione> thom: i dunno.. mjg59 is the person to ask
<thom> i think it makes a lot of sense for desktop/laptop systems
<mjg59> Do any other distributions use it by default?
<thom> not that i know of
<thom> suse might
<fabbione> does that require me to change something in the kernel?
<fabbione> if so you have less than 10 days to test and let me know :P
<thom> heh
<fabbione> ok a bit more serious now.. do i need to change something in the kernel?
<fabbione> thom: i don't mind "breaking" it now
<fabbione> but later might hurt more
<fabbione> (getting closer to my honeymoon and stuff like that)
<mjg59> It can be done through the bootloader
<mjg59> I've no idea what needs to be done to make it the default
<thom> fabbione: i can't remember the magic, it's a .config change - we already build and ship cfq, i'd just like to change to using it by default
<thom> i'll look in a minute
<fabbione> ok let me check too
<thom> and, as matthew says, you can enable in in your bootloader with "elevator=cfq"
<fabbione> we build and ship all the elevators
<fabbione> but no idea which one is set by default
<ajmitch> anticipatory io scheduler, isn't it?
<Mithrandir> iirc, yes
<thom> yes, anticipatory is default
<thom> coo, the dist-upgrade of destiny is done
<pitti> seb128: ping
<fabbione> thom: there are some documentation bits in Documentation/block/
<fabbione> some of them a bit scary
<seb128> pitti: pong
<fabbione> thom: mind to clean the incoming queue on jackass from the linux-source bits i was uploading before?
<thom> 'spose i can
<fabbione> do you want the centrino speedstep fixes?
<abelli> fabbione: after a dist-upgrade on a k7, apt's asking for linux-386, why?
<thom> fabbione: heh
* fabbione wistles while thom cleans
<fabbione> abelli: no idea.. that's for sure not a kernel problem
<fabbione> abelli: you need to see what is pulling in linux-386
<thom> rm linux-source-2.6.10_2.6.10-11.dsc
<fabbione> there should be also a piece of diff.gz
<thom> fabbione: you should be good to go
<thom> nope
<fabbione> ok cool
<fabbione> Uploading via ftp linux-source-2.6.10_2.6.10-11.diff.gz: 
<fabbione> on the way sir
<fabbione> mjg59: your patch is in
<fabbione> including the new 31337 DRI drivers
<abelli> well aptitude wants them, but if he tries apt-get/synaptic it doesnt seem to be required
<fabbione> abelli: you need to see what depends/reccomends it
<abelli> it seems nothing, since apt-get doesnt say anything about it
<fabbione> apt-cache rdepends linux-386
<abelli> already tried :)
<elmo> amu: ?
<fabbione> hey elmo
<fabbione> elmo: when you have time, mind to add the Release files to sparc.u.c? otherwise d-i can't validate the archive
<elmo> pitti: done
<elmo> uh
<pitti> elmo: thanks. both?
<elmo> pitti: yeah
<fabbione> elmo: dists/hoary/Release
<elmo> seb128: that's one heck of a jump - does that come under your gnome-exemption ?
<mvo_> abelli: a recommends? aptitude installs recommends by default, apt/synaptic does not
<elmo> [Updating]  pwlib (1.6.6.4-5.1 [ubuntu]  < 1.8.3-2 [debian] )
<seb128> elmo: yep, gnomemeeting is a part of the GNOME desktop and 1.2 needs this pwlib
<abelli> mvo_: no is not recommended..
<elmo> seb128: ok, done
<abelli> is "packages (new) that will be installed"
<elmo> fabbione: ok, one sec, I need to clear NEW, and it's far too early in the morning to be breaking my brain with rsync's include/exclude madness
<fabbione> elmo: "when you have time please"
<fabbione> i don't need it right awat
<fabbione> away even
<mjg59> fabbione: Rock
<fabbione> SteveA: patch-2.6.10-mh2.gz <- is this the release you are talking about?
<SteveA> fabbione: not sure.  where do they hide their changelogs?
<fabbione> i am on bluez.org
<SteveA> http://64.233.179.104/search?q=cache:AHgKuJBSS30J:www.zaurususergroup.com/forums/index.php%3Fshowtopic%3D9995%26view%3Dgetlastpost+ambicom+bt2000c+bluez&hl=en&client=firefox
<SteveA> can you get to that google cache page?
<SteveA> this is an annoucement of a binary packaging of bluez for the zaurus
<fabbione> yes i can see it
<SteveA> but, it mentions support for the BT2000C CF card
<fabbione> Ambicom BT2000C Support. Thanks to tetron for spotting this had been included in the latest drivers
<SteveA> so, i'm trying to find out what version of bluez includes that support
<SteveA> and then request that that version is in hoary
<fabbione> 22.01.2005
<fabbione> Bluetooth kernel patch 2.6.10-mh2 available -<
<fabbione> the one before is older than the post...
<daniels> thom: i know, it's on my TODO
<fabbione> so there is not that much difference
<fabbione> i am checking the patch
<SteveA> dude, if you can get this going, i owe you several beers in canberra
* thom boggles at metacity
<seb128> thom: new version broken ?
<fabbione> SteveA: i am checking how intrusive is the patch
<fabbione> SteveA: remember we are going to commit to support it for 18 months :-)
<SteveA> the whole issue stinks, actually.
<thom> seb128: seems pretty unhappy
<SteveA> ambicom had their BT2000 card, with ericson chipset
<SteveA> well supported by the kernel
<SteveA> then, they released another BT2000 card, essentially the same model number
<SteveA> sold interchangably by amazon, retail stores etc.
<SteveA> but with different chipet, not supported.  and stopped selling the old card
<seb128> thom: like ?
<SteveA> so, many people looked into the ambicom BT2000, saw that bluez supported it, and received a *different* kind of BT2000
<thom> seb128: when i change workspace, i see every window i have open for a second
<elmo> fabbione: done
<seb128> thom: we call that a crash :p
<Mithrandir> SteveA: it'll be interesting when they can't pull off such stunts, since they will then be misleading the customer.
<seb128> thom: could you attach it in gdb and give a bt on #5823 ?
<fabbione> elmo: rocking!
<thom> seb128: sure
<fabbione> SteveA: i don't see anything in that patch that is related to that interface
<thom> seb128: it's segfaulting every time i change workspace, yeah
<fabbione> i guess i will have to give a bk check..
<SteveA> fabbione: iirc, the card was already providing some kind of serial interface via bluez.  it needed hooking up in some way or other.  at least, that was one option to get it working. 
<mjg59> fabbione: Good thing you don't work for a company producing an RCS, isn't it?
<fabbione> SteveA: hmm ok.. what if i cook up a kernel for you and test it for me?
<fabbione> mjg59: Good thing i am not part of THAT team :P
<fabbione> SteveA: what kernel do you need? k7 ? 686? ppc?
<SteveA> steve@zeus3 ~ $ uname -a
<SteveA> Linux zeus3 2.6.10-1-686 #1 Tue Jan 11 03:24:24 UTC 2005 i686 GNU/Linux
<fabbione> SteveA: ok.. that's an easy one :-)
<fabbione> stay tuned for the next 20 minutes....
<SteveA> okay
<fabbione> SteveA: in the meanwhile download a copy of linux-image-2.6.10-2-686_2.6.10-10_i386.deb
<fabbione> and  keep it handy for recovery...
<fabbione> nothing should be THAT bad
<fabbione> but it's good to have
<SteveA> i have linux-image-2.6.10-2-686_2.6.10-9_i386.deb in /var/cache/apt/archives/
<SteveA> will that do?
<fabbione> yes.. just copy it  somewhere
<fabbione> it's building now :-)
<SteveA> fabbione: i have a cdrom and ubuntu / knoppix cds for if it goes horribly wrong ;-)
<no0tic> hi, I've upgraded metacity now and it gives me problems
<fabbione> SteveA: ehehe ok
<no0tic> when I try to move windows borders and title bar disappear and window remains where it is
<fabbione> no0tic: please file a bug with all the details
<no0tic> it's rather unusable 
<fabbione> put it as a major problem
<no0tic> it seems like it crashes and restart every time
<thom> no0tic: bug already filed
<thom> no0tic: #5823
<thom> aargh, i've forgotten all my fluxbox foo
<seb128> everybody else than me get this crash ?
<thom> seb128: looks like
<seb128> thom: could you rebuild the package on your box without debian/patches ?
<thom> sure
<pitti> elmo: is it possible to install baz on rookery?
<elmo> pitti: done
<pitti> elmo: thanks
<pitti> sivang: I will now alter l-s-il to depend on culmus
<pitti> sivang: any other dependencies?
<no0tic> I updated metacity bug
<seb128> and I still don't get it :/
<seb128> are you guys using an amd64 ? i386 ?
<thom> i'm on amd64
<no0tic> x86
<no0tic> k7 
<thom> brb with unpatched metacity
<seb128> thom: killall metacity, no need to brb :)
<no0tic> I started metacity from tty1 to display :0
<seb128> do you have a backtrace ?
<thom> seb128: i was running ion ;P
<no0tic> every time I try to do something with windows, it crashes Segmentation Fault
<seb128> get a backtrace !
<no0tic> how?
<seb128> ps ax | grep metacity
<thom> seb128: anyway, still happens without patches (i disabled simple-patchsys in d/rules
<seb128> gdb -p <pid>
<seb128> thom: ok, so I can bother upstreams if needed :p
<thom> it is needed :P
<seb128> thom: remove libglib2.0-0-dbg which is bugged and DEB_BUILD_OPTIONS="nostrip noopt" debuild
<seb128> for metacity
<seb128> get a full bt and I'll kick upstreams :)
<seb128> how many workspaces do you have guys ?
<thom> 8
<jdub> 4
<seb128> jdub: you get the crash too ?
<jdub> haven't upgraded yet ;)
<seb128> so no need to give your workspaces :p
* Mithrandir has 10, but runs openbox. ;P
<seb128> thom, no0tic: theme used ?
<mvo_> Kamion: the /casper dir is only on the live-cd, not on the install cd? (I need a way to not detect the live-cd as a ubuntu-cd)
<no0tic> seb128: it blocked X completly now, I wasn't able to switch to console
<seb128> I got this too while attaching in gdb :/
<fabbione> hem you might want to attach gdb from console and let it run
<no0tic> I was attaching to gdb too
<no0tic> s/to/in
<fabbione> yes but attacching gdb will stop the process from running
<fabbione> you need to write run or something
<fabbione> to resume all the operations
<fabbione> SteveA: uploading the new kernel.. 
<Kamion> mvo_: yes, but it will be on the combination install/live DVD so I recommend against that approach
<Kamion> mvo_: if I figured out how to get rid of /dists/hoary/main/binary-* from the live CD, would that do the job?
<Kamion> is anyone else noticing grub-install segfaulting on amd64?
<Mithrandir> Kamion: hm?
<mvo_> Kamion: probably, yes. I use apt-cdrom ident to check for a valid cd. 
<seb128> no0tic, thom: what keymap are you using ?
<Kamion> /sbin/grub-install: line 516: 21053 Segmentation fault      $grub_shell --batch $no_floppy --device-map=$device_map  >$log_file <<EOF
<Kamion> root $root_drive
<fabbione> SteveA: http://people.ubuntulinux.org/~fabbione/linux-image-2.6.10-2-686_2.6.10-12_i386.deb
<Kamion> setup $force_lba --stage2=$grubdir/stage2 --prefix=$grub_prefix $install_drive
<Kamion> quit
<mvo_> Kamion: live-cd of today worked perfectly on my test-machine btw. contracts :)
<fabbione> SteveA: please test and let me know.. if it works i will add the patch to the final -12 release, but in the meanwhile please roll back to -10/-11
<no0tic> seb128: it
<Kamion> mvo_: congratulations should go to mdz for most of this stuff
<Mithrandir> Kamion: Due to a bug in xfs_freeze, the following command might produce a segmentation
<SteveA> fabbione: so, you want me to install this kernel image, see how the BT card goes, report on it, and then go back to the regular hoary one?
<Mithrandir> fault when /boot/grub is not in an XFS filesystem. This error is harmless and
<Mithrandir> can be ignored.
<Kamion> Mithrandir: yes, it's not that though
<fabbione> SteveA: correct
<Mithrandir> Kamion: ok
<SteveA> okay.  downloading the .deb
<Kamion> Mithrandir: /sbin/grub is segfaulting, not xfs_freeze
<Mithrandir> Kamion: then "worksforme".
<Kamion> I can reproduce it, it's the 'setup' command
<Mithrandir> Kamion: b0rken device.map?
<thom> seb128: theme: mist; keymap: uk
<fabbione> SteveA: cool
<Kamion> Mithrandir: just '(hd0) /dev/sda', it's worked for ages and it's only recently that it's started breaking
<Kamion> strace won't trace /sbin/grub, annoyingly
<Mithrandir> Kamion: grab a 32 bit strace
<fabbione> Kamion: is that on a sata disk?
<Mithrandir> since grub is a 32 bit binary.
<Kamion> fabbione: yes
<no0tic> seb128: unfortunately I must go now...
<Mithrandir> Kamion: I tried on a sata drive as well, fwiw.
<seb128> no0tic: ok, I think thom will track the bug with me so that's fine, thanks
<Kamion> amd64 strace tries, and does report that it's running in 32-bit mode, but falls over with 'ptrace: umoven: Input/output error'
<seb128> thom: hum ... so how is that nostrip build going ? :)
<Mithrandir> Kamion: yes, try with 32 bit strace.  That's normal for 64 bit strace.
<no0tic> seb128: from gdb output: /usr/lib/pango/1.4.0/modules/pango-basic-fc.so  0xffffe410 in ??
<Kamion> Mithrandir: ok
<thom> seb128: wait a second :-)
<thom> ok
<thom> lets see what happens
<Kamion> Mithrandir: 32-bit gdb needed too?
<thom> seb128: new bt up
<seb128> cool, thanks
<Mithrandir> Kamion: I don't know.
<Kamion> argh, no libreadline in ia32-libs
<thom> seb128: i have that gdb session open if you need anything
<seb128> thom: no real idea on it for the moment, no, thanks
<thom> k
<seb128> thom: what keybinding are you using to switch workspaces ?
* fabbione has the feeling that for one reason or another the grub problem will be reassigned to the kernel
<zul> most likely :)
<Mithrandir> fabbione: you can reassign it further to gtk
<thom> seb128: ctrl+alt+{left,right} arrow
<fabbione> i need to find something else than GTK
<seb128> thom: ok, definitively working here :/
<thom> fabbione: firefox
<fabbione> thom: RIGHT!
<thom> i just got my "all bugs but firefox" query sorted, so i don't care ;-)
<fabbione> Kamion: if grub doesn't work.. it's a firefox problem..
<Kamion> it makes no sense to me, grub hasn't changed
<fabbione> Kamion: when you try to run grub, does anything show up in dmesg?
<fabbione> like I/O error related to the hardware...
<Kamion> Jan 24 14:00:24 localhost kernel: grub[21053] : segfault at 00000000555bcb30 rip
<Kamion> 00000000555bcb30 rsp 00000000555bc9fc error 15
<Kamion> nothing else that I can see
<fabbione> Kamion: is it writing the boot record on a plain disk or is it like a raid of somekind?
<Mithrandir> Kamion: that's just a normal segfault, which the amd64 kernel logs per default
<Kamion> ordinary partition, no funkiness at all
<Kamion> like I say it's worked before
<Kamion> a lot
<Mithrandir> weird.
<fabbione> i know lilo crashes if i try to write a mbr and one of the disks in the raid is not spinning...
<Mithrandir> I can test on a couple of boxes more.
<Kamion> it's one of my primary test systems, I've been using it since before warty with complete success
<Mithrandir> M-t
<fabbione> Kamion: what about trying to use an old kernel and see immediatly that i am at fault for some obscure reasons? :P
<Mithrandir> Kamion: what kind of hw do you have in the box?
<Kamion> fabbione: I would if I could actually boot anything else
<fabbione> Kamion: a warty install?
<Kamion> well I don't have a functional grub :P
<fabbione> Kamion: but you can still boot from CD
<fabbione> can't you?
<Kamion> I'll fish out a warty/amd64 CD in a minute
<fabbione> or pxe
<Kamion> Mithrandir: via
<fabbione> i need to go and renew the vaccination from Brazil
<fabbione> later guys
<Mithrandir> Kamion: same as I have -- EpoX 8HDA3+ is the mobo.
<seb128> thom: ok, I get the crash in a flexiserver ... I'm away for a moment and work on that when I get back, thanks for the help
<thom> k, cool
<tritium> this apparent metacity bug makes me again think we need something like apt-listbugs working with ubuntu's bugzilla
<Kamion> apt-listbugs is pretty bogus in Debian though; lack of version tracking makes it difficult for users to see what bugs are in their version, and the upshot is that we end up with a lot of confused users thinking that stuff is fatally buggy when it really isn't
<Kamion> fabbione: chrooting from a warty/amd64 CD works fine
<Kamion> I therefore conclude that it's a kernel bug :P
<Kamion> fabbione: oh, note that I saw the segfault while chrooted into a Debian amd64 system too
<fabbione> Kamion: we have the same patch sets. so i think the problem is upstream, if you and Mithrandir can verify you are using the same hardware and what drivers (blabla) i can check if there is something on bk
<fabbione> i need to leave now.. i will be back either later or tomorrow
<tritium> Kamion, you're right about apt-listbugs, but a similar tool merits some consideration
<trey3> Someone want to add something about the metacity bug to user channel topic please?
<SteveA> fabbione: i've booted into the kernel you made
<SteveA> when I plug a usb BT adapter into the machine, i get a bunch of spew in /var/log/messages and it maps io ports and loads useful hci stuff
<SteveA> when i insert the CF BT card in questions, nothing extra appears in /var/log/messages 
<SteveA> fabbione: anything you want me to try out before i go back to standard hoary kernel?
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*uname@*.exetel.com.au]  by daniels
* mode/#ubuntu-devel [-o daniels]  by daniels
* Mithrandir chuckles a bit at the "s/su/sudo/g" for spanish translations.
<Kamion> fabbione: *chrooted* into a Debian amd64 system> Debian kernel not relevant.
<daniels> Mithrandir: heh :)
<Mithrandir> (not that I speak spanish, but I can imagine the destruction)
<Mithrandir> Kamion: what kernel can you reproduce it with?
<Mithrandir> Linux golem 2.6.10-2-amd64-k8 #1 Wed Jan 19 17:21:54 UTC 2005 x86_64 GNU/Linux
<jdub> haha: "The behavior itself isn't really a bug though, is it? The bug is not having a GUI to control the behavior." -- http://bugzilla.ubuntu.com/show_bug.cgi?id=5763
<Kamion> Mithrandir: kernel-image-2.6.10-2-amd64-generic-di version 2.6.10-10 on this here live CD
<Treenaks> jdub: try unchecking the "per window" stuff in the gnome keyboard layout manager app
<Mithrandir> Kamion: and that segfaults?
<Treenaks> jdub: that "fixes" it for me
<Kamion> Mithrandir: yes
<Treenaks> jdub: ("separate group for each window")
<Mithrandir> Kamion: weird; try with a non-di and k8?
<Kamion> Mithrandir: I'm going to iterate; will take a while
<Kamion> Mithrandir: what package version is yours?
<Mithrandir> linux-image-2.6.10-2-amd64-k8                                         2.6.10-10
<daniels> Treenaks: you're fucking shitting me
<Kamion> Mithrandir: hmm
<daniels> that is the most ludicrously ridiculous thing.  ever.
<Treenaks> daniels: well, it does something to remembering per-window state..
<Mithrandir> Treenaks: not here.
<daniels> that is absolute crack
<Mithrandir> Treenaks: but I'm using openbox.
<Treenaks> daniels: must be some other part of my settings then
<Treenaks> daniels: but if I turn that flag on (per-window groups), all "lock" states are remembered per-window..
<Treenaks> not just the group
<Mithrandir> Treenaks: I can reproduce it regardless of per-window groups.
<daniels> EZ GTK BOOG
<Treenaks> Mithrandir: then it's somthing else
<daniels> Mithrandir: turning per-window groups off fixes it for me also
<jdub> that's insane
<daniels> Mithrandir: maybe gnome-keyboard-applet or whatever fails to set it when not in gnome?
<Mithrandir> daniels: I'm using gnome, but I'm not using metacity.
<daniels> hm
<Mithrandir> and it certainly manages to set such stuff as keyboard repeat rate.
<daniels> bong
<pitti> Kamion: I now created two scripts install-language-locales and remove-language-locales
<pitti> Kamion: I think I rather stuff them into 'locale' instead of duplicating them into all lang packs, right?
<pitti> Kamion: s/locale/locales/
<Kamion> yeah
<Kamion> pitti: base-config should install language packs now
<pitti> cool
<sivang> Kamion: yay!
<thom> Mithrandir: you're a chunderbird user, right?
<Mithrandir> yes
<thom> can you reproduce #4249?
<tritium> thom, I just swiched my preferred mail app to thunderbird, and I do get a new Compose window
<thom> can you comment it works for you then, please?
<Mithrandir> thom: worksforme.
<tritium> curious - if thunderbird is already open, however, it opens the profile chooser
<tritium> rather than a new compose window
<Mithrandir> yeah, that's a tb bug
<thom> ok, cool
<thom> thanks guys
<tritium> sure
<Kamion> upgrading from linux-image-2.6.10-2-amd64-generic 2.6.10-9 to 2.6.10-10 
<Kamion> is enough to trigger that bug
<seb128> daniels: here ?
<Mithrandir> Kamion: but it's not in -k8?
<Kamion> Mithrandir: haven't tried yet
<Kamion> about to
<Mithrandir> ook
<daniels> seb128: wassup
<seb128> daniels: kind of bug flooded a lot, do you have time to figure what wrong with the xkb stuff ? 
<daniels> seb128: did you upload a new gnome-keyboard-manager or whatever lately?
<seb128> daniels: gnome-applets and control-center handle the xkb stuff and both have had a lot of changes recently
<rcaskey_> I've got a list of directories and I'm looking for a way to match up the device icon with the directory, what's the best way to go about doing that with python?
<trey3> Treenaks, possible metacity bug workaround (keyboard > layouts > uncheck "Seperate group for each window") didn't stop occurances here... (told I should say something)
<daniels> seb128: bbbbbbbllllllllleeeeeeeeggggggghhhhhhhh
<daniels> seb128: sort of, but especially wednesday's a holiday, won't get to it until thursday/friday myself
<seb128> daniels: svu upstream is quite responsive and know that code, if you have a good description of the problem that's probably enough
<seb128> daniels: ie: a way to reproduce and an idea of what's wrong ... so I can ping him with it
<jdub> seb128: svu is responsive because he's paid by the russian mafia. that's not the kind of responsive we want to get involved with. :)
<seb128> jdub: ahahah :)
<seb128> (bah daniels probably doesn't fear the mafia :p)
<jdub> that's because he's a rentboy
<daniels> seb128: yeah, I'll have a chat to svu if you like
<daniels> jdub: i am not thom
<rcaskey_> is there a channel that would be a good choice for hal/python questiosn?
<daniels> rcaskey_: #freedesktop
<rcaskey_> thanks
<Kamion> Mithrandir: segfault with -k8 too
<Mithrandir> Kamion: weird, I can't reproduce that.
<seb128> daniels: thanks
<daniels> seb128: no worries
<daniels> seb128: tell me when you aren't drowning in bugs, and I'll reassign you some more ;)
<seb128> ah ah
<thom> daniels: stop distracting him from fixing metacity
<daniels> seb128: #1842 and #4343 are clearly gnome bugs
<seb128> I've 'only' got 130 mails in my "my bugs" box this WE :p
<daniels> thom: worksforme (i haven't dist-upgraded today)
<zul> i would say you guys are swamped :)
<seb128> daniels: everything is gnome bug, I know :p
* thom is currently running pwm2
<thom> it's an experience
<daniels> thom: i hear good things about phluid
<mjg59> daniels: Oh, I spoke to benh - he thinks it might need more doing than just setting the device to D3
<thom> daniels: phluid is k-l33t
<daniels> seb128: it looks like all this stuff can be traced back to new svu crack, which is kind of a relief for me
<daniels> mjg59: oh?
<mjg59> It seems that what the chip does when it's put into D3 depends on the register state beforehand
<daniels> christing shit
<mjg59> He's got some whacked-out shit that ATI told him to do, and no real idea what it's doing
<seb128> daniels: yeah, for me too
* mvo_ has a appointment in town, bbl
<no0tic> seb128: metacity bug?
<seb128> daniels: have you read his blog ?
<mjg59> So I need to get my hands on a T42 again. I might be able to get one for a bit next week.
<daniels> mjg59: unfortunately the only Mobility documentation I have around is M6; all my other spec sheets are for desktop chipsets
<seb128> no0tic: nothing I can real do about it, I've pinged upstreams with a full bt (thanks thom), downgrade if needed of wait for a fix (that's a devel branch that happens...)
<daniels> seb128: anything in particular?
<mjg59> daniels: Worst case, I just rip all the suspend code out of radeonfb
<seb128> daniels: IIRC he described all the xkb changes in his blog
<no0tic> seb128: can you give me some hints on how to downgrade?
<seb128> no0tic: get a old deb (perhaps in /var/cache/apt/archives/) and dpkg -i
<no0tic> seb128: I've only the new deb in there
<no0tic> seb128: :(
<seb128> ok, so find somebody with the previous deb
<no0tic> seb128: I'm feeling lucky ;)
<seb128> no0tic: I'm sorry but I don't have any obvious fix atm, don't use hoary if you don't want to face some issues ...
<no0tic> seb128: I like these issues :)
<tritium> no0tic, if the previous version was 2.9.3-0, I can get you the old .debs
<tritium> it was, I just checked the changelogs
<no0tic> tritium: thanks!
<tritium> hold on, I'll put them on a website for you
<tritium> they're out of the pool already, I guess?
<no0tic> tritium: you're fantastic!
<tritium> no0tic, actually - looks like they're still in the pool
<tritium> http://ftp.cs.umn.edu/pub/ubuntu/pool/main/m/metacity/
<tritium> at least on some mirrors
<no0tic> tritium: pool dir doesn't exist
<tritium> no0tic, I'm browsing it right now
<Kamion> old debs> morgue.ubuntu.com
<Kamion> you need to know when the package was removed
<tritium> thanks, Kamion 
<no0tic> thanks Kamion 
<trey3> Kamion, 2.9.3 is still in repo...
<trey3> (working fine with rest of 2.9.5)
<tritium> no0tic, did you find it?
* trey3 notes #ubuntu-devel isn't tech support  :/
<no0tic> tritium: no
<pitti> amu: no worries, if all the konversation CVEs were handled, then it's okay. I just wanted to know whether they were handled at all :-)
<trey3> ps, just to confirm (cuz I did it) ... metacity is issue... libmetacity 2.9.5 is still installed, but issue is gone...
* trey3 wonders if that should be on bugzilla  :-?
<no0tic> solved
<Kamion> trey3: I didn't check, merely noting a useful resource
<srbaker> is it possible to completely disable OSS in warty?
<OddAbe19> not to be rude or interupt or anything... but there are plenty of complaints in the Hoary forum about the Numlock key turning on and off (application based), is this going to be fixed for the hoary release?
<OddAbe19> or taken away would probably be a proper term
<daniels> OddAbe19: yes, but this is probably more appropriate for #ubuntu
<daniels> in the meantime, desktop->preferences->keyboard preferences->layouts->separate group for each window being unchecked seems to fix it
<OddAbe19> i understand, i was just interested in hearing it from developers though, to besure
<OddAbe19> thanks daniels
<daniels> developers lurk in #ubuntu too :)
<OddAbe19> thanks again
<Kamion> there are many bugs in hoary which will be fixed for release. :-)
<OddAbe19> i know that... it just seemed to be more of a feature
<daniels> a very, very, very misguided feature
<OddAbe19> that got a few people confused
<OddAbe19> lol
* thom waits for firefox to crash
<thom> and there it goes
<trey3> thom, that soo better be amd64 or something... I'll cry if firefox on i386 is broken  :(
<daniels> thom: boom
<thom> trey3: nah, it's just libpr0n blowing up on a corrupt png
<trey3> thom, thats bad too damnit  :(   can't sleep out pr0n  :o
<thom> trey3: libpr0n is mozilla's image rendering  library, so yes it's bad
<trey3> ahh... thats a real library name?
<trey3> haha  *goes back to #ubuntu quietly*
<lamont_r> pitti: buildds are stripping translations
<ericf> Problem: `gksudo ls & gksudo ls & gksudo` makes my system hang... At least X. I kill it in tty1, problem solved. Weird command of course, but... double/triple clicking the update-notifier applet causes a similar situation. Maybe gksudo should prevent this interfering with itself?
<lamont_r> now I just need to get the aggregator written..
<jdub> thom: mind if i upload a gecko-cil package that depends on firefox instead of mozilla?
<thom> jdub: gfi
<jdub> get f*cked idiot? thanks a lot!
<thom> heh
<jdub> done
<thom> if you wanna read it that way go for it :P
<jdub> that'll make beagle happier when it turns up
<thom> now fix metacity 
<jdub> i'm totally not going anywhere near metacity ;)
<thom> before i decide i like pwm enough not to switch back
<lamont_r> thom: what did metacity do now, besides exist?
<thom> lamont_r: don't upgrade today if you want to ahve a working system
<lamont_r> thom: right
<thom> lamont_r: crashes when you switch window or workspace
<lamont_r> lol
* mjg59 screams at Radeons
<mjg59> daniels: Thanks for your help - I think I have a pretty good idea how to approach this now
<daniels> mjg59: no worries, dude :)
<trey3> jdub, chicken  >: |
<Kamion> trey3: well volunteered to fix it
<trey3> jdub, @ 'i'm totally not going anywhere near metacity ;)'
* trey3 runs away again
<lamont_r> does that mean that grabbing a livecd today is also a bad idea?
<jdub> https://bugzilla.redhat.com/beta/
<daniels> nice interface
<Kamion> seems to be just a bit of a redesign; what's so much better?
<daniels> Kamion: very clean to look at
<jdub> small, incremental improvements to bugzilla tend to make a big difference ;)
<haggai> elmo: please can you allow python2.4-bsddb3 into universe
<thom> thom     13440  0.7  0.0      0     0 pts/2    Zl   16:31   0:01 [firefox-bin]  <defunct>
<thom> thanks, firefox
<sivang> jdub: feh, that looks neat.
<sivang> :)
<sivang> it eases on the eyes..
<pitti> lamont_r: nice! But http://people.ubuntu.com/~lamont/translations is still 404 ??
<lamont_r> pitti: like I said - the build's are stripping.  today is 'write the aggregator' day
<lamont_r> (the thing that aggregates 12 buildd's into that url.
<pitti> aha
* lamont_r thinks someone should fix cyrus-sasl (no, not '2') to use something newer than libtool1.4
<elmo> haggai: huh?
<lamont_r> elmo: you saw that partimage should be PaS on amd64 (and removed from the archive)?
* lamont_r can't remember if he emailed that or not...
<lamont_r> 1
<elmo> lamont: err, no?
<lamont_r> elmo: yeah - it's PaS on all 64-bit arch in debian - I added amd64 last week or so
<lamont_r> it's belief that sizeof(long)==4 is rather ubiquitous.
<lamont_r> so when you run partimage on amd64, it dies with a complaint that sizeof(DWORD) !=4, built with incompatible gcc or some such
<lamont_r> then again, given the archive/release model, it doesn't _really_ need to be removed from the archive... it can live on broken. :-)
<srbaker> muwahaha.  it wouldn't be a work day if someone wasn't bitching about my choice of music
<mdz> morning
<daniels> yo mdz
* srbaker jives in his chair to Merle Haggard.
<tseng> odd, latest blam binary is 1.4.1, but source is 1.6.0
<elmo> lamont: is it rdepend clean?
<haggai> elmo: I uploaded python-bsddb3 fixed to build on python-2.4 but heard nothing and assumed it was because of the new package name.  Is there no evidence of it arriving?
<lamont_r> elmo: dunno, didn't look at that
<lamont_r> it's in universe in anycase
<elmo> Rejected: no source found for python-bsddb3 3.3.0-6ubuntu1 (python-bsddb3-doc_3.3.0-6ubuntu1_i386.deb).
<elmo> Rejected: binary uploads are not allowed - please only upload source.
<elmo> Rejected: python-bsddb3_3.3.0-6ubuntu1_i386.changes: upload is signed by 0xBE88B4B38D1F6639580FCCEE7B199D131997E7CF but is not i
<elmo> n the Binary Uploads keyring.
<haggai> elmo: gah sorry.
<Kamion> hm, it looks to me as if grub is segfaulting when it tries to call disk_read_savesect_func(), which is part of install_func()
<Kamion> the only reason I can think of for that to happen on a kernel upgrade is that the kernel is scribbling over user memory
<seb128> thom: ?
<Kamion> grub does this weird thing with functions defined inside other functions that I don't understand
<daniels> with the unichrome and i810 drivers coming entirely from HEAD of their respective development, we're still managing to keep our patchset against 6.8.2 under 100,000 lines
<daniels> (of about 90,000 lines, about 50,000 is patches from X.Org HEAD, unichrome.sf.net HEAD, and linuxwacom.sf.net)
<thom> seb128: sup?
<seb128> thom: http://bugzilla.gnome.org/attachment.cgi?id=36473&action=view
<seb128> thom: should fix the metacity crasher ... feedback welcome
* lamont_r heads home -back non in a bit
<thom> seb128: righto, will look in a second
<seb128> thom: don't bother, I'll update it in the archive, that works here
<thom> fair enough
<tritium> thanks seb128
<seb128> tritium: np
<mdz> thom: did you get my mail about fixing the text on bugzilla.ubuntu.com?
<thom> mdz: i saw your mail, and asked the MOTU folk for some suggested text, not seen a response yet
<elmo> mdz: shall I file the rest of the uninstallablle bugs?  I stopped after doing two
<mdz> elmo: how many are there?
<mdz> thom: hmm.  options I see are: create a new Bugzilla product (ugly, but easy), use a mailing list, or start using Malone
<elmo> mdz: at least 10, related to the lang pack stuff
<mdz> haggai, ogra, etc.: would it be useful to have a mailing list specifically for MOTU stuff?
<mdz> elmo: yeah, sure
<Kamion> do we want to start putting language packs onto the CD?
<mdz> at this point, it would probably be nice to start mailing diffs of britney output to ubuntu-devel
<mdz> since stuff needs to be installable
<haggai> mdz: yeah, might be a good iodea
<elmo> you'll pick  up temporary buildd stuff, if you do that, tho
<elmo> less if you only do it once a day or so, I guess
<mdz> ideally we would get notified if something stays uninstallable for a day or something, but that sounds like work
<jdub> mdz: can we keep motu on -devel until there's enough to push it off?
<mdz> I suppose
<mdz> there is a significant amount of stuff at this point where we need an "answer" from the MOTU team on something, though
<mdz> and a dedicated mailing list is better for that kind of thing
<haggai> yes I agree
<jdub> mdz: as in, "can we get blah updated", or...?
<mdz> jdub: as in, "how do you want to manage bug tracking for universe?"
<mdz> what resources do you need, etc.
<mdz> have to run, back later
<jdub> now there's a question we're supposed to have an answer for :)
<haggai> jdub: how are the kubuntu lists? brewing nicely?
<jdub> haggai: will do tomorrow
<haggai> thankx
<thom> seb128: where's metacity?!
<thom> ;-)
<seb128> thom: upstream rolling a release, I don't want to patch to repackage the new version 10 mins after that :p
<thom> slacker ;-)
<seb128> thom: BTW I've i386 packages on alioth if you want :p
<elmo> mdz: is there any chance of getting the bugzilla component list updated to match hoary or is that beyond our bugzilla-fu?
<elmo> some of these mozilla lang packs depend on like 1.2 or 1.6 of mozilla
* elmo considers filing  a secondary bug on "-uk" locale packages: package name is entirely broken, kthxbye
<elmo> seb128: you going to fix openh323?
<seb128> elmo: I didn't know that it was broken, under a pile of GNOME releases atm, but I'll check that
<elmo> seb128: the pwlib sync broke it
<elmo> I can just file a bug, in case someone who isn't playing one-man-gnome-army wants to fix it?
<Treenaks> seb128: "one-man gnome army".. you need new business cards ;)
<daniels> elmo: -uk vs -gb?
<elmo> daniels: yeah
<elmo> -ca vs godknowswhat too
<zul> seb128: i attached a patch to the gnome-panel buglet for #5822
* Kamion gives up on the amd64 kernel vs. grub problem; it's not worth the four hours I've spent on it
<Kamion> maybe it'll magically disappear with the next kernel revision the same way it magically appeared with this one
<elmo> daniels: do I need to whine at you about lrm?
<seb128> daniels: don't bother I'll fix it
<Kamion> elmo: I thought 2.6.9 was being multiversed
<seb128> zul: I've get the mail thanks, I've pinged an upstream about it, will be fixed in the CVS today
<daniels> elmo: you're going to say something involving the words nvidia_minor, ati_minor, etc, aren't you?
<daniels> seb128: fix which?
<zul> seb128: sounds good
<elmo> daniels: good guess
<daniels> elmo: head -> desk
<Kamion> oh, that l-r-m
<seb128> daniels: s/daniels/elmo/
<elmo> seb128: k
<daniels> seb128: i'd need to get a haircut
<daniels> well, grow my hair
<daniels> and lose about 90% of my wardrobe
<seb128> :)
<elmo> Kamion: is there any reason to not just drop it?
<Kamion> elmo: don't care; if we drop it we should probably drop linux-source-2.6.9 too
<elmo> mdz: ?
<daniels> elmo: there you go
<elmo> daniels: seriously, I think that needs fixed permanently
<daniels> elmo: for bonus points, hack katie to remember the last *_minor and write a new girl to cause a fist to leap out of my monitor and beat the crap out of me when I forget
<elmo> at least to break at source-build time
<daniels> elmo: yes.  ideas?
<elmo> I've no idea - I don't want to look at the source package to see why it's doing that :)
<elmo> but like you said, couldn't you record the last *_minor in a file and just abort if it hasn't been manually updated?
<daniels> well, fglrx and nvidia have their own versions
<daniels> and in the case of nvidia-glx, at least, we have namespace collision
<daniels> but knowing the major versions is *exceedingly* useful, not to mention more or less necessary for sane dependencies
<daniels> mmm, I suppose that's true
<daniels> or at least having to touch YES-I-HAVE-BUMPED-THE-REVISIONS to source-build, and always cleaning that file
<Kamion> can't it work out the ubuntuN from the source version?
<daniels> Kamion: no
<Kamion> i.e. generate N based on the -M at the end
<Kamion> why not?
<daniels> because we revved nvidia to 1.0.6629 at l-r-m 2.6.8.1
<Kamion> every time we increment -M, we also bump ubuntuN by the same amount
<Kamion> so?
<Kamion> I'm not saying that the first part should be autogenerated
<daniels> oh, hm
<daniels> but then you fall down with new upstream versions, no?
<Kamion> new upstreams would require something to be manually tweaked
<daniels> e.g. if we get a new version of nvidia-glx, the first release of that upstream version is 1.0.6743-0ubuntu237
<daniels> mmm, ok.  interesting idea.
<daniels> bonus points if you can come up with a patch while I'm asleep :)
<Kamion> either no problem, or you have REVISION-236 as ubuntuN
<Kamion> IIRC gcc-defaults has something like that
<Kamion> # gcc-defaults 1.19 is the first version with 3.3.5 support.
<Kamion> REL_NO_335      := $(shell expr $(REL_NO) - 18)
<elmo> Kamion: what do you do on little WRT bittorrent-ing?  and how much would care if it moved to a new host?
<elmo> Kamion: oh,and you might like to trash 'ftp.bak' at some point
<Kamion> elmo: I don't do anything WRT bittorrenting, I sort of assume somebody else will take care of it at some point :-/
<Kamion> elmo: yeah, waiting 'til I get round to reviewing/committing the anonftpsync changes
<elmo> Kamion: err, nothing at all??
<Kamion> elmo: I don't generate .torrents for dailies any more, since they weren't all that useful; for releases I pester thom
<thom> and then i cry
<elmo> sweet
<elmo> well, we can't do torrents for dailies anymore anyway, since torrent's moving to a machine without space for them
<elmo> so thom only gets to cry at/near release time ;-)
<thom> excellent
<thom> any more than that and the floods of tears would reach leeds
<Mithrandir> thom: we could hook you up to a hydropower plant
<thom> heh
<pitti> Hi sivang
<pitti> sivang: I had to reboot my server (new kernel), sorry for the lack of notice
<sivang> pitti: no prob, when did this happen?
<pitti> sivang: about two hours ago
<sivang> pitti: oj
<sivang> pitti: ok
<seb128> elmo: around ?
<elmo> seb128: yah
<seb128> elmo: do you know what's going on with metacity 2.9.8 ?
<seb128> it's built for 2 hours according to the logs and not in the archive
<elmo>   metacity | 1:2.9.8-0ubuntu1 |         hoary | source, amd64, i386, ia64, powerpc
<elmo> ?
<seb128> http://archive.ubuntu.com/ubuntu/pool/main/m/metacity/ doesn't list it here
<elmo> it's on mirnyy
<elmo> sigh, auckland is so hosed
<seb128> in fact the current 2.9.5 "just crashes" for many people, so would be nice to get the update
<seb128> oh ok, I was looking in archive ... I thought it was the first place to get the debs
<seb128> thanks
<elmo> both mirnyy and auckland get synced at the same time
<elmo> the problem is auckland is at load 40 24/7 atm, I'm in the process of dumping services off there as fast as I can to try and help
<seb128> ok
<seb128> elmo: and glib2.0 2.6.1-3 sync (dunno if that's already on the mirrors) please
<Simira> seb128: after this yesterdays update, the Gnome-problem has reappeared. Just now it seems like the menus shows up, only it takes incredibly long time
<seb128> Simira: which one ?
<seb128> Simira: there is like 400 GNOME problems in bugzilla
<Treenaks> seb128: itsm the panel-doesn't-fill one
<seb128> Treenaks: itsm ?
<Treenaks> I think she means
<seb128> Treenaks: the nautilus/vfs/panel lock ?
<Treenaks> seb128: might be?
<ogra> seb128: pick the right one and win a prize ;-P
<elmo>  20:51:24 up 10 days,  9:03,  1 user,  load average: 225.56, 227.69, 226.11
<elmo> ok, so maybe not 40
<ogra> woah
<seb128> Treenaks: I really hope it's not, gnomevfs is patched for this for a few days and nobody complained about it since
<Treenaks> seb128: hm ok
<seb128> Treenaks: if this patch doesn't work :/
<Treenaks> seb128: now everyone's complaining about metacity? :)P
<seb128> elmo: urg
<seb128> Treenaks: yep :p
<Simira> seb128: the Gnome panel won't start problem ;p
<seb128> Simira: nautilus too ?
<seb128> you are uptodate ?
<trey3> seb128, panel not dieing bug is fixed too today?
<Simira> seb128: yes
<seb128> Simira: nautilus too ?
<seb128> oh damn, if this is the lock in gnomevfs not fixed :(((((((
<tritium> what's this about metacity 2.9.8?
<tritium> I thought the fix was in 2.9.5-0ubuntu2
<trey3> tritium, knew upstream version for RC1
<trey3> tritium, read link in bug report
<tritium> all right
<pitti> Hi dilinger!
<pitti> how are you?
<dilinger> hi :)
<dilinger> good, you?
<pitti> same :-)
* pitti still whacks PostgreSQL
<elmo> seb128: auckland's back and up2date, FWIW
<seb128> elmo: cool, thanks
<seb128> elmo: BTW have you synced glib2.0 ?
<jdz_> seb128: some of the gnome applets don't become transparent.  are these bugs?
<seb128> yep
<jdz_> seb128: upstream?
<seb128> sure
<seb128> the distro only package
<seb128> hum, not only, but most of the code is from upstreams I mean
<elmo> seb128: it hasn't hit ftp.uk yet, I'll sync it when it does
<seb128> ok, thanks
<elmo> uh, nm, it has.. done
<seb128> cool :)
<seb128> elmo: could you sync easytag too ?
<elmo> done
<seb128> thanks
<mdz> elmo: ?
<mdz> elmo: re: bugzilla, I'm planning to update the component list today
<sladen> tritium: ping
<dilinger> ubuntu strips out kernel firmware, same as debian, right?
<sladen> dilinger: and sticks it in a separate 'restricted modules' package
<thom> mdz: amd64 live cd worked like a charm barring the obvious Xorg not being able to probe screen res, which daniel is working on AIUI
<dilinger> sladen: is the firmware in userspace, or is it compiled into the kernel modules?
<mdz> thom: I had the same problem, but my KVM seems to prevent DDC from working, so it always does that
<mdz> dilinger: no, we ship firmware with our kernel
<mdz> dilinger: not built in, but in the same package, loaded by hotplug
<thom> mdz: ddcprobe uses real mode iirc; i ended up having to stub it ages ago so we could build ddcprobe on amd64 at all
<dilinger> mdz: alright
<sladen> dilinger: yup.  I defer to fabbione/mdz.  They actually know what they're talking about
<dilinger> heh
<tseng> jdub: ping. didnt mean to put you off about tomboy, but ive realized it has very poor QA and needs some fixing.. i was also looking at blam, new version uses gecko-sharp
<tseng> jdub: you just uploaded gecko-sharp to build againt firefox, blam needs a bump to build-dep mozilla-firefox-dev as well
<tseng> jdub: i can send you the source for that if youd like.
<ajmitch> dilinger: do you know if anyone else is working on getting php5 debs?
<thom> infinity is planning to look at doing it at some point in the not too distant, so he was saying earlier
<ajmitch> alright
<dilinger> yea, i thought infinity already did some work on them
<ajmitch> I'm just looking at the debs on dotdeb.org, they need a lot of work if they were to be used
<thom> are they the yada afflicted ones?
<ajmitch> not sure, but debian/rules still has dh_make comments 
<dilinger> i no longer use php, so it's not any sort of priority for me
<ajmitch> I'm going to need php5 for a server soon, so I thought I'd take a look
<thom> dilinger: are you jobless now or doing your notice period?
<dilinger> i've got 4 more days left (after today)
<ajmitch> bbl, lunch
<mjg59> sladen: I've got a lead on the Thinkpad power consumption issues
<dilinger> mjg59: is this the sleep issue?
<elmo> mdz: cool, thanks.  the other thing was 2.6.9; are we planning to support it in hoary?
<elmo> or rather, it's already in universe, but could we just drop it entirely?
<mjg59> dilinger: Yeah, using too much power while asleep
<mjg59> There's some registers that need setting to make it actually shut itself down
<mdz> elmo: definitely not going to support it, if fabbione is OK with dropping it entirely, then let's do it
<elmo> ok, will ask
<dilinger> yep.  is there a spec sheet available for the card?
<mjg59> dilinger: Nope.
<dilinger> ah.  fun.
<mjg59> Not publically, at least
<mjg59> There's actually code in radeonfb to do this, but (a) that only works on PPC at the moment, and (b) we don't want to require people to use radeonfb
<mjg59> So I need to write a small driver...
#ubuntu-devel 2005-02-05
<tseng> jeez
<ogra> lol
<lifeless> erm, whos ops here that can HURT 
<lifeless> SOMEONE
<lifeless> BADLY
<tseng> i asked lilo
<tseng> dunno if he is awake
<T-Bone> wouldn't it be just fine to ban *!*@pound.ifndef.com ?
<T-Bone> (locally ban, here on #ubuntu-devel, for a starter)
<tseng> yes, but no one is seeming to jump on that
<tseng> i guess he slowed down
<ogra> i think the guy is known here, i've seen it happen before
<tseng> hooray
<Geert> :)
<Kamion> I've never seen KeyserSoze actually talking here
<ogra> me neither, but he is always here....(probably a logbot...)
<srbaker> so upgrading to hoary from warty is as simple as s/warty/hoary/ in sources.list and doing dist-upgrade, right?
<srbaker> anything i should know besides that?
* mode/#ubuntu-devel [+o thom]  by ChanServ
<srbaker> oh well.  what the hell
<thom> ber, too slow
<ogra> mdz ?
<seb128> elmo: around ?
<elmo> seb128: unfortunately
* mode/#ubuntu-devel [-o thom]  by thom
<seb128> elmo: what's broken with openh323 exactly ?
<mdz> ogra: ?
<mdz> Kamion: do you have some time to go over some casper stuff?
<elmo> seb128: the soname (and thus pkgname) of pwlib changed?
<wasabi_> jbailey: had any time to check out the eclipse packages yet?
<wasabi_> oops
<elmo> The following packages have unmet dependencies:
<elmo>   libopenh323-1.13.2: Depends: libpt-1.6.3 but it is not installable
<elmo> the two libs are quite tightly synced; I dunno if it requires a newer version or just a rebuild
<seb128> elmo: correct, please sync openh323 it's also needed for gnomemeeting
<seb128> from experimental
<seb128> and nothing out of gnomemeeting uses it in main
<Kamion> mdz: I have maybe fifteen minutes now
<mdz> Kamion: ok, first thing is making netcfg more suitable for the live CD environment
<mdz> Kamion: i.e., being entirely non-interactive
<elmo> seb128: ok, done
<seb128> thanks
<mdz> Kamion: I'm happy for it to try to bring up an interface automagically if it can, but if not, it should just fall back to doing nothing
<Kamion> mdz: if DHCP sends back a hostname, do you want to use it?
<Kamion> if so, that will probably require a minor netcfg change to make that preseedable
<sivang> mdz: Do we want to change the entry over there to bendy? ==> http://www.ubuntulinux.org/wiki/HoaryReleaseSchedule , notice the 26th March.
<ogra> sivang
<Kamion> let's not set "bendy" in too much stone :P
* ogra thinks the grumpy occurences could also get changed to hoary+1 everywhere....
<mdz> Kamion: yes
<mdz> Kamion: but if that's not easy, I'm fine with using a static hostname instead
<mdz> Kamion: the important thing is to suppress the interactivity
<Kamion> ok, do you have the logs from when I gave you questions to preseed to achieve that?
<sivang> Kamion: woops, noted.
<mdz> Kamion: you gave me preseed magic to suppress the hostname prompt
<mdz> but that's not the bit I'm worried about
<mdz> mostly the actual interface config
<mdz> the hostname prompt is actually very convenient, because it pauses the process at just the right time for me to netcat over a new casper and test it out :-)
<Kamion> oh, you mean the "pick an interface" bit? ok
<mdz> yeah
<mdz> ideal would be to try each interface in turn to see if one can be configured automatically
<mdz> but I guess I'd be happy with tryng the first one and giving up, if that's significantly easier
<Kamion> netcfg selects the first one that has a link beat as the default
<Kamion> the trick will be to get it to just pick the default, without asking the question
<lamont> daniels: you around?
<Kamion> mdz: try 'db_fset netcfg/choose_interface seen true'
<mdz> ok
<sladen> mjg59: I'm in Cambridge tomorrow.  You around?
<mdz> Kamion: then there's the isolinux text, which should either be made generic, or different text used for the live CD
<Kamion> mdz: I think that will die if a default doesn't get set for whatever reason, though
<Kamion> mdz: I thought I'd already done that
<mdz> The default installation is suitable for most desktop or laptop systems.
<mdz> To install only the base system, type 'server'.
<Kamion>   * Add syslinux.txt.live with slightly different text for the live CD.
<mdz> that's what it currently says
<Kamion> (debian-installer_20041227ubuntu5 changelog)
<mdz> hm, didn't see that change go in
<mdz> was that after the most recent live CD build?
<Kamion> maybe I forgot to make the corresponding debian-cd change
<Kamion> no, well before
<mdz> I just pasted that from hoary-live-i386.iso
<mjg59> sladen: Leaving at about 9AM
<mdz> Kamion: and the final thing is the templates which say "installer"
<mdz> (language used "for the installation process", etc.)
<Kamion> those will have to be made generic, I think
<Kamion> it's likely to be too much work to allow them to be variable
<mdz> once those three things are taken care of, I think we'd be ready to do a wider live CD milestone release
<mdz> I agree
<Kamion> sigh, syslinux.txt.live didn't make it into debian-cd_info.tar.gz; fixing
<mdz> Kamion: if dhcp fails on an interface with linkbeat, doesn't netcfg fall back to static configuration prompts?
<mdz> if so, the live CD wants to suppress that as well
<Kamion> I'm sure I gave you directions for that
<Kamion> as well as the hostname thing
<mdz> Jan 06 09:40:12 <Kamion>        perhaps: db_fset netcfg/dhcp_options seen true;
<mdz> db_set netcfg/get_hostname some-default-hostname; db_fset netcfg/get_hostname seen true
<mdz> that's what you gave me before
<Kamion> there was another occasion
<mdz> and then we decided that get_hostname wasn't necessary
<mdz> oh?
<Kamion> let me try to figure it out from scratch again
<mdz> that's the only other db_fset I found in my log from you
<Kamion> hm, yes in fact the above should be it
<Kamion> db_fset netcfg/dhcp_options seen true
<Kamion> oh, no
<Kamion> you will also need db_set netcfg/dhcp_options 'Do not configure the network at this time'
<sladen> mjg59: gah, damnit
<Kamion> (and hope that that works in non-English locales ... not sure about that)
<mdz> ah, I didn't realize that template was dhcp_options
<Kamion> dhcp_options only gets asked if DHCP fails
<mdz> my understanding is that choices aren't translated in the db
<Kamion> they are
<mdz> so I assume that works
<Kamion> sometimes
<mdz> oh
<Kamion> in particular that one is
<mdz> the Value: is translated? how weird
<Kamion> oh, well it is in the templates db anyway; whether it is in the questions db I'm not entirely sure, but there's code in other parts of d-i to cope with that
<Kamion> it's all very dodgy
<mdz> I mean, the choices are translated for display, but I thought the english version was actually stored as the value
* T-Bone calls it a night, bye all
<Kamion> this is one of the bits of debconf I don't fully understand
<mdz> so I'll take a stab at the netcfg stuff tonight
<mdz> regarding the d-i templates, are you OK with me going through and mangling them?
<Kamion> yeah, that's fine, make sure to run debconf-updatepo after doing so
<mdz> ok, I'll try to do that tonight too, if I get around to it
<gt500> hey peepz , is there a gui for the ati fglrx-control , or do i have to type fglrxconfig ?
<gt500> woopz
<mdz> and the syslinux thing should happen with the  next live CD build?
<gt500> wrong channel
<gt500> :p
<Kamion> mdz: I'm just this moment uploading debian-installer to fix that, so whenever elmo does the byhand + next live CD build
<mdz> ok, great, thanks
<Kamion> with regard to the hostname prompt, have you considered just using expert mode?
<mdz> yeah, I suppose I should do that instead
<mdz> it's just terribly convenient as-is :-)
<Kamion> while I appreciate the value of having pauses at convenient times and all :)
<mdz> expert mode involves lots of keypresses, right?
<mdz> I thought about adding a casper/debug template which it would check, and pause if it were set
<Kamion> expert mode isn't all that bad
<mdz> though typing in casper/debug=true is lots of keypresses too
<mdz> and qwerty ones
<Kamion> it's maybe half a dozen more presses of Enter
<elmo> christ, the upload server gets warez tested _every_ day
<Kamion> warez tested?
<Kamion> mdz: you could also go back to the main menu and change debconf priority
<mdz> Kamion: should I preseed in casper-check, then?
<Kamion> mdz: yeah, I think that's easiest
<mdz> MKDIR .dpwh
<Kamion> the alternative's for casper-check to ship an actual preseed file
<elmo> Kamion: a file from an automated scanner thing uploads this same (empty) 1mb test file
<Kamion> I'm not sure there's a big win either way
<mdz> which would be a problem for casper/enable=false, I assume
<Kamion> mdz: no, it would be set by the same bootloader options that set casper/enable=true
<mdz> hm
<Kamion> if you have lots of things to set then a preseed file might be a bit more convenient, but until then I wouldn't worry about it
<mdz> I suppose I need to do the db_register trick in order to get the values into the db?
<Kamion> and you have slightly more flexibility outside preseed; for example you can mark a template seen without having to set a default value, if you know that the code in question tolerates that
<Kamion> mdz: yeah
<mdz> ok, I think that should give me enough to go on for the next day or so
<mdz> thanks
<Kamion> mdz: anything still pending from the stuff in scrollback over the weekend? I basically had to discard a lot of that, there was too much
<Kamion> night all
<ogra> night Kamion
<sivang> night Kamion 
<jdub> GOOD MORNING FREEDOM LOVERS!
<ajmitch> hello jdub 
<tseng> hey jdub, see my message?
<mjg59> GOOD MORNING MR JDUB
<jdub> tseng: tomboy/blam/libgecko-cil
<tseng> jdub: yessir :)
<jdub> tseng: send source packages this way when you're happy with them
<sivang> jdub: waiting for your pantelonas greeting :)
<tseng> jdub: email or what
<jdub> tseng: somewhere i can snarf them via http would be easiest
<tseng> sure thing
<tseng> i can do blam right quick
<pitti> night everybody!
<tseng> jdub: hows http://getsweaaa.com/~tseng/blam/
<elmo> mdz: d-i daily build is in the archive
<mdz> thanks
<elmo> [actually it was there, like 20 mins ago, but auckland took a while to catch up :/] 
<daniels> lamont: sup
<jdub> tseng: /blam/blam.exe
<jdub> tseng: wtf? ;)
<tseng> grr how do i keep doing that?
<jdub> tseng: should build depend on intltool without libxml-parser-perl
<tseng> -libxml-parser-perl, +intltool
<jdub> yeah
<tseng> there a min version for that?
<jdub> hmm, shouldn't matter
<tseng> the MonoConventions page is broken on alioth atm
<tseng> there is a bit on locations for foo.exe
<tseng> jdub: refresh the dir for build-dep update
<jdub> tseng: add planet ubuntu, too :)
* jdub builds
<tseng> heh
* tseng looks into that
<tseng> ah easy++
<tseng> testing that patch quick.
<robertj> have any decisions been made about Mono for Grumpy?
<jdub> $ sudo -i
<jdub> sudo: cannot get working directory
<jdub> ^ uh oh
<jdub> robertj: fairly likely we
<jdub> robertj: fairly likely we'll include it if beagle is ready
<tseng> jdub: -4 uploaded, same bat channel
<tseng> with sweet Planet Ubuntu love
<ajmitch> jdub: included in main?
<jdub> ajmitch: fairly likely, yes
<ajmitch> aha
<robertj> those beagle flash videos were impressive
<robertj> did you see em?
<ajmitch> they looked rather neat
<jdub> yeah
<tseng> yeah, Nat is a fun character
<tseng> they should make him in plush
<jdub> tseng: so this is based on another package elsewhere?
<robertj> are the req'd kernel extensions aok'd by upstream?
<tseng> jdub: 1.6.0 source in hoary
<tseng> jdub: it never built it seems
<jdub> tseng: ah, ok
<jdub> tseng: so you need to change the version to "1.6.0-1ubuntu1"
<jdub> tseng: that'd be your first modified revision
<tseng> ah right
<jdub> then you'd ++ to 1.6.0-1ubuntu2
<tseng> how can i specify the suffix?
<tseng> or prefix as it were
<jdub> same way, in debian/changelog
<jdub> because your packages haven't been uploaded, you can coalesce your changes into a 1ubuntu1 releaser
<tseng> yep
<sivang> jdub: dch does that usually fine most of the time..
<sivang> jdub: (from my few experiments)
<jdub> yes, it does
<elmo> uh, anyone got a default warty install handy?  or at least, an unmodified sources.list?
<elmo> if so, what hostname does it point at?
<daniels> elmo: hold on a sec
<jdub> archive.ubuntu.com
<elmo> boggle
<elmo> does anyone here not see archive.ubuntu.com resolve to a round-robin?
<daniels> yeah, a.u.c/s.u.c
<jdub> jdub@lazarus:~$ host archive.ubuntu.com | wc -l
<jdub> 2
<tseng> jdub: refresh if you would please
<daniels> elmo: resolves to auckland+mirnyy here
<elmo> so why has auckland done like 8x the traffic of mirnyy in the last couple of hours
<bob2> same here
<jdub> tseng: it is golden.
<tseng> great
<tseng> glad I could help.
<jdub> tseng: if you pitch for MOTU, i will second you :)
<tseng> hmm alright ill reread that page
<mdz> elmo: is 90% of it from one host or something?
<ajmitch> am I only allowed to complain to the MOTU's about universe bugs (providing fixes, of course)? :)
<elmo> mdz: I'm talking, 90 GB, vs. about 10Gb
<mdz> ajmitch: if you provide fixes, you can complain to anyone you like ;-)
<mdz> elmo: shrug, it's round-robin everywhere I look
<elmo> and it's http too
<robertj> is there a troubleshooting guide for hibernation and the like?
<elmo> I might just disable the auckland.warthogs.hbd.com name in case everyone in the world is using it or something
<ajmitch> mdz: great, there's still 155 packages in universe that won't install with python 2.4 :)
<ajmitch> elmo: who chose auckland, it makes me think it's a local (nz) mirror :)
<mdz> elmo: speaking of warthogs.hbd.com, is there a non-warthogs equivalent for admins?
<jdub> yikes, rsync is working nicely for the livecd
<elmo> ajmitch: sabdfl
<elmo> mdz: er, kind of, it's not fully functional yet - why?
<elmo> hmm, ftp.*.$TLD weren't RR.. done them too
<elmo> btw, hoary/main/i386(+all) is 2 and a bit Gb
<elmo> </random>
<mdz> elmo: phasing w.h.c out of my mutt config
<jdub> mdz:    550086656 100%    1.87MB/s    0:04:40  (1, 100.0% of 1)
<mdz> yep
<jdub> tasty ;)
<mdz> jdub: I wonder if better rsync efficiency translates to more or less I/O thrashing on the server side
<jdub> tseng: and, um, distro name is hoary not unstable (sorry, should've noticed that)
<tseng> gr
<jdub> just respinning now
<tseng> ah ok, i was going to fix
<tseng> nps then.
<jdub> tseng: upload accepted ;)
<tseng> jdub: good show, i need to hit all the docs again before applying
<tseng> i still dont feel like im up to snuff
<sladen> robertj: it's called ''/query mjg59''
<bob2> robertj: or wiki.ubuntu.com/PMTesting
<ajmitch> hm, there doesn't seem to be anything on the wiki about the need to rebuild packages for python2.4
<elmo> does anyone know how to do wildcard domains in postfix's config file?
<jdub> tseng: always happy to answer questions, etc.
<jdub> elmo: as in, accept mail for wildcard domains?
<tseng> jdub: appreciate it
<elmo> jdub: I want to relay for *.$tld (sic)
<jdub> should just be .$tld
<elmo> yeah, doesn't work
<jdub> serious hooray for sftp://
<jdub> elmo: erm, been a while since i've been knee deep; perhaps a regexp hash or something? (should be simpler than that)
<elmo> jdub: I'll have  a look at that.. but this is for lamont anyway, I guess it can wait till he comes back
<jdub> ok
<jdub> hrm, skills atrophy :|
<sladen> elmo: have you tried something along the lines of  virtual_maps = regexp:file  
<elmo> sladen: unfortunately this is the relay host for ubuntu.com, canonical.com etc. so I don't want to mess around, and I'm too tired/lazy to setup the same thing on another box
<ajmitch> ah, this python rebuild is going to take a long time
<elmo> apache's server status page is like a lava lamp... would make a cool xscreensaver hack
<sladen> elmo: this is for  xyz@foo.ub.com,  xyz@bar.ub.com  all going -> xyz@canonical_domain.com  (pardon the pun)
<elmo> sladen: no, I want to relay *@*.sometld to another host
<elmo> if I use foo.sometld in relay_domains, it works
<elmo> if I use .sometld, and try to mail bar@foo.sometld, it doesn't
<mdz> W: GPG error: http://archive.ubuntu.com hoary Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<mdz> elmo: ^^ ?
<ajmitch> crap, pdebuild doesn't want to work, it won't auth packages
* ajmitch fiddles with it
<wasabi> There a pbuilder-xen yet?
<wasabi> =)
<mdz> elmo: hmm, a second update just now got a valid one. did you do anything?
<mdz> elmo: or is there a temporary desynchronization when it mirrors?
<elmo> no
<elmo> no there isn't.. until we start RR-ing with one crap server and one good one
<sladen> elmo: I've not used it with relay_domains;  Touching-Wood, I'd guess just   /^(.+)@\([^.] +)\.example.com/ foobar    and a regexp: path to that file But break/test it on another machine first
<mdz> elmo: I mean desynchronization between Release and Release.gpg
<elmo> I guess there's no guarantee apt will get the Packages, Releases and Releases.gpg from same IP, is there?
<mdz> no, there isn't
<elmo> mdz: there's a _very_ small race there, but I doubt it's an issue .. I suspect it's more the RR
<elmo> well bugger
<elmo> sladen: yeah, thanks
<elmo> mdz: could we not fix apt?  this is going to completely kill Debian
<elmo> it's halfway solvable for us, on our LAN, but it'll kill us too if we ever want to RR a non-local mirror (e.g. archive.us.ubuntu.com)
<mdz> I don't think we can, if you consider proxies and stuff
<elmo> gag
<mdz> unless we do something crazy like keep old Packages, Release and Release.gpg around under different names
<mdz> I guess we could have it retry if the sig check fails
<mdz> treat it like a transient failure
<mdz> but that sucks when you get down to Packages files
<elmo> yeah, but that's still a random chance whether or not you get a good IP
<sladen> do something like --clearsign in as a comment/line: so that it's backward compatible?
<elmo> this totally hoses round-robins; the only way I can see to do them is to have them signal back when they're ready or something insane like that
<mdz> hey, I know, we could just sign packages!
* elmo beats mdz to death with a lava lamp
<elmo> tho, we could sign _Packages_
<mdz> yeah, you'd have to sync over all the index stuff separately, and rename it all at once, or something
<elmo> but, err, no that still has the same problem, meh
<mdz> signing Packages would work if we signed it inline, rather than detached
<elmo> mdz: all sane Debian mirrors sync the indices seperately anyway
<elmo> yeah, that's true
<sladen> instead of .gpg being a detached sig;  you could have .gpg just have an inline signature
<mdz> elmo: all at once across all mirrors ;-)
<elmo> mdz: not all mirrors, just all mirrors in the RR
<elmo> no one sane has more than 6 or so in a RR at once anyway
<mdz> sladen: there would still be multiple files that need to be in sync
<mdz> sladen: Release is signed, contains md5sums for Packages.gz, etc.
<mdz> elmo: if all of them in the RR sync the indexes in a second run, that should make the race pretty small
<elmo> actually, even with the "signal, and then move" thing, you'd get screwed by write-starved machines like auckland, but I suppose you just lose if you hae auckland
<elmo> mdz: dude, there's like a 10 min gap between mirnyy finishing and auckland finishing
<elmo> or, between newsamosa (Gb LAN) and saens (half way across the US)
<elmo> it's much more than 10 min
<mdz> i guess 10 min/day for Debian is not so bad, but 10 min per 30-minute day or whatever we have is pretty crap
<elmo> argh, this is so bad
<mdz> it really shouldn't happen all that often, considering that apt uses http keepalives
<mdz> I don't even know how it happened this time
<elmo> mdz: does anything ignore keepalive requests?
<mdz> stuff that doesn't speak HTTP/1.1
<sladen> if they constantly keep a connection open to rsynd, the updates should get pushed in the order they are performed.  Packages/etc files are then just a checkpoint
<mdz> I've got it going through squid here
<mdz> which I'm fairly certain does keepalives
<elmo> well, let's leave ours in a RR for a day or two and see how many complaints we get
<bob2> lifeless: ^^
<mdz> I remember this came up in debian before
<aj> dadadadum
<elmo> aj has a cunning plan
* aj comes from a punning clan, too
<jdub> aj: congrats :-)
<aj> the idea is make cron.daily to   jenna; rsync; apt-ftparchive   and expect it to run 2-4 times per day
<elmo> that's mostly on a Debian timescale, but the 30 mins cron.daily thing isn't sustainable with triggered mirrors anyways
<elmo> so it could scale to Ubuntu timescales too
<mdz> what does jenna do?
<elmo> mdz: updates suites, so that 1.10-2 replaces 1.10-1
<aj> err, >=2-4 times per day, whatever
<elmo> basically, you'd sync the files in pool first, and then later (like an hour or so or whatever) actually change the Packages files
<mdz> so 1) move debs around in the archive, 2) push debs out, 3) update the indexes, 4) push the indexes
<aj> jenna's standing in for "install debs into the pool, etcetc"
<aj> no
<mdz> no?
<aj> move debs in the archive; push debs packages out (referring to old debs); push pool out (doesn't matter how long this takes, since no one will reference any of the changes anyway yet); when that's done, run apt-ftparchive to update indexes for next run later
<elmo> it's kind of like taking the "rsync everything except indices, then rsync indices" on the client and turning it into "install stuff into the pool, rsync, wait.. generate indices files... repeat cycle" on master
<mdz> ok, so that's what I said, only omitting 4)
<mdz> and leaving it for the next rsync instead
<aj> it's like what you said, but it goes (1) (4) (2) (3)
<mdz> how does that address the indexes being out of sync with each other?
<aj> we currently do (1) (3) (2) (4)
<elmo> mdz: if they only have to sync the indices, the mirror is hugely shorter
<mdz> but they already sync the indexes separately
<elmo> err, window for the race, I mean
<aj> step (4) is very quick, so there's no time to get out of sync on the indices
<mdz> I'm not clear on how changing the order helps with this particular problem
<mdz> it helps with master<->mirror syncage, but not mirror<->mirror
<elmo> mirror <-> mirror gets out of sync because the time-to-mirror is variable
<mdz> or have I misunderstood?
<elmo> if you're only mirroring changed Packages files, the time-to-mirror is much smaller, and -> the variation is much smaller
<mdz> right, but as you said earlier, sane mirrors already do the indexes in a separate pass, no?
* daniels looks at infinity.
<elmo> mdz: directly _after_ they just did the big pool/ update
<elmo> so the variation is still there
<elmo> mirnyy does it's seperate indices pass 10 mins before auckland even starts his
<aj> and they have to do it after the pool/ update, coz unstable Packages will refer to packages that weren't in the pool last time they synced
<mdz> ohh, I see
<mdz> you're turning it around client/server wise
<aj> the bit after "coz" in the above changes if apt-ftparchive is only run after rsync
<infinity> daniels : Stop that.
<mdz> I didn't realize it worked that way
<usual> how new is the ubuntu update manager?
<mdz> so currently, the individual mirrors do 1) pool, 2) indexes, but they do it according to their own schedule
<usual> never noticed it before
<elmo> mdz: no, they do it when we trigger them
<aj> well, they do it when we tell them to
<elmo> mdz: if they're triggers, otherwise yes
<mdz> ...
<mdz> I must be thick
<aj> but it could be anytime they like
<elmo> mdz: ?
<mdz> I think I'm lacking context about how this stuff actually works currently
<mdz> I thought that the pushes went out in two passes, 1) pool to all mirrors, 2) indexes to all mirrors
<mdz> but what I think you're saying is that it's currently pool-to-mirror-1, indexes-to-mirror-1, pool-to-mirror-2, indexes-to-mirror-2
<elmo> no, what happens atm is:
<aj> no, it's {pool, then index} to all mirrors simultaneously
<elmo> right ^- that
<mdz> ok, gotcha
<elmo> we just "signal" them
<mdz> and we give only one signal which lets them do both passes at their own pace
<mdz> can we not signal them separately for pool and indexes?
<mdz> or do we not have a way to tell when they're finished?
<elmo> we don't have a way to tell when they're finished
<aj> right, whoops
<elmo> we could get one..
<aj> it has to be "apt-ftparchive; install into archive; push {dists/, pool/}" not what i said
<aj> my bad
<elmo> we'll have to get one for either scheme
<mdz> yeah
<aj> we will?
<aj> the above should work without that
<mdz> only if you can safely assume that they're done by the time the next cycle rolls around
<mdz> which works for long cycles, but not short
<aj> err
<elmo> well, as I said, I don't think many mirrors will be happy to be triggered every 30 mins
<aj> well, if you have mirrors that don't finish in between cycles you're screwed
<aj> i guess delaying the cycle would be okay
<aj> you could do a snapshot.ubuntu so you create a new dists/ every 10 minutes, so places can keep downloading the old dists for 20 minutes i guess
<mdz> elmo: as long as all of the mirrors in a particularl RR are on the same cycle
<elmo> mdz: yeah
<mdz> archive.u.c and archive-less-up-to-date-but-faster.u.c
<elmo> I'm not sure what to do about the 30mins thing - if we keep it for archive.u.c, but not for mirrors, the hoary/crack-of-they-day folks aren't going to use mirrors
<aj> (bittorrent!)
<mdz> people won't use mirrors anyway until they get shitty throughput
<mdz> I would like to do the bittorrent experiment someday
<elmo> uh.
<elmo> are you guys  serious?
<mdz> not bittorrent, but the model
<elmo> ok
<mdz> at the file level, rather than the block level, really
<jdub> i would run a torrenty mirror here if we had that feature
<mdz> no point in getting pieces of a .deb from a bunch of random places, but there would be value in letting peers exchange debs
<mdz> make everyone's apt cache a mini-mirror
<jdub> if mirrors and downloaders could share packages similarly, that'd be rad
<mdz> the authentication stuff was a prerequisite for anything like that, which is one reason I haven't bothered with it yet
<mdz> I guess you could end up in a shitty situation where you were downloading a huge .deb from a slow peer
<mdz> but generating .torrents for everything is insane I think
<elmo> totally
<elmo> it's beating-worthy to even suggest it
<srbaker> hehe
<jdub> and who better to administer the beating than the sysadmin team (shit-your-self administration)
<daniels> 'employee agrees to be fired out of a cannon'
<aj> yeah, bittorrent itself is unusable for debian; i tried
<stub> Torrents can contain multiple files, and clients may choose to download only some files. Would one torrent, or perhaps a handful, work?
<mdz> it would be nice to be able to download 10 or so smaller debs from 10 peers in parallel, though
<aj> but apt-cache/proxy + bittorrent's logic for finding peers should be doable
<mdz> stub: I think a .torrent for the entire archive would be huge anyway
<aj> stub: no, coz every time the archive gets updated, all the old torrent info becomes useless
<elmo> you'd definitely need to update the algroithm somehow to take into account peer's speeds
<aj> also Packages contain most of the information a torrent needs, so it's half redundant
<mdz> has anyone experimented with sorting the entire Packages file in such a way as to try to maximize compression?
<stub> If Packages was extended to contain *all* of the information a torrent needs, it could be generated on the client
<elmo> it'd be fun actually you could build a figleted "WHATEVER" into the protocol as a message to the peer that you'd didn't want no more of his slow-as-molasses download
<daniels> haha
<mdz> stub: it would be gigantrous
<daniels> i fear the protocol that you build, elmo.
<daniels> it would include 'kthxbye', figlet, and deep personal abuse
<elmo> are you still better about being called a GTK bug? :)
<elmo> bitter too
<mdz> I guess the current sort-by-binary-name probably gets 90% of any benefit that could be had by sorting
<daniels> elmo: no, I'm happy, because verbal abuse means you're not beating me
<mdz> that's only because you're out of reach
<elmo> the last protocol I did was bloody awful.  in a moment of deep insanity, I chose CVS as an inspiration.  unfortunately, I am not joking
<daniels> elmo: and you have root on all our machines, yes?
<elmo> if I don't, we're in trouble
<daniels> well, apparently, if you do, we're in trouble also :P
<aj> mdz: huh? how's sorting going to improve Packages.gz's compression?
<aj> mdz: (and you've seen tiffani right?)
<mdz> aj: by grouping related items together
<mdz> and no
<aj> mdz: why would gzip care about related items being together?
* elmo watches mirnyy handle 25 rsync clients with a < 1 load
<elmo> god damn it I HATE AUCKLAND
<mdz> aj: bz2 does
<aj> mdz: okay, i'll blog about it tonight sometime
<aj> mdz: ??
<mdz> aj: getting related items into the same block should give you smaller blocks overall
<aj> mdz: bz2's just byte&block based like gzip...
<elmo> anyway, past 3am.. night all
<mdz> night
<aj> night elmo
<daniels> elmo: night
<mdz> now that elmo's gone, I can reveal that I think that moving descriptions out of Packages might not be completely insane
<jdub> aj: mdz has been involved in some fairly sick rsync optimisations recently, so... forgive him for thinking too hard on this one.
<aj> mdz: tiffani's the "apt-get update pulss diffs" thing, it's running on merkel atm and is in theory usable, but i need to check
<daniels> mdz: i think we should have one deb per language per package, for language packs
<mdz> daniels: troll
<mdz> aj: oh, the thing that you and mvo and I were talking about
<mdz> ?
<aj> was mvo the one who posted the patch to apt? if so, yeah
<mdz> #128818
<aj> yeah, looks like the right number of digits :)
<mdz> aj: what's the problem with diff -e?
<mdz> florian weimer mentions something about it not being suitable for 'one-pass processing'
<aj> mdz: it puts the changes in reverse order
<aj> mdz: diff -f puts them in order, so you can read from the diff and the original file, and just use pipes to generate the output
<mdz> aj: does your implementation use the one-patch-to-current approach, or a sequence of patches?
<aj> sequence of patches
<mdz> oh
<mdz> that problem doesn't exist if you do each patch relative to current
<aj> trivial to change if needed (the hacked up client wouldn't even need to change), but i couldn't see the point
<mdz> and it should be smaller, too
<mdz> and faster
<mdz> (one HTTP request instead of N)
<aj> yeah, but more complicated on the server, so that can be v2 afaic
<lifeless> bob2: ?
<aj> (it's also harder on mirrors; which might impact how far back diffs can go, though probably not; it's also harder on ftp-master.d.o)
<aj> (doing it as day 14-8 -> day 7; day 7-1 -> today would probably work though)
<aj> (err, 21-15 -> 14 too)
<mako> is there a recommended usb wireless stick for folks stuck on ibooks?
<aj> heh
<aj> i've heard you can plug the old airport cards in instead of the new airport extr3m3, and have it work. no idea if it fries your computer or not though :)
<sivang> anybody knows if dh_make is deprecated or something? it's not recognizable on my dev set up hoary...
<jdub> jdub@lazarus:~$ apt-cache search openoffice.org2 | wc -l
<jdub> 13
<jdub> BLING!
<aj> "openoffice.org2" ? those package names just get worse and worse
<jdub> haha, ooo2-core is 45MB
<jdub> aj: parallel-installable
<sivang> nm, missed one dependency
<mdz> jdub: do you have an opinion on whether we should put it in main now (and possibly remove it later), or wait?
* aj shudders at the thought of having two copies of openoffice.org installed, let alone running
<jdub> mdz: if we're serious about shipping it, we should get it in for testing
<srbaker> i just upgraded to hoary.
<jdub> mdz: oh, i can't make seed changes atm - unrecognised signature
<jdub> i pulled the keyrings
<srbaker> it seems to be OSS only.  i want alsa.
<mdz> haha
<mdz> jdub: have you seen the oo.o2 splash?
<jdub> srbaker: we use alsa by default, via the oss-emu modules.
<jdub> mdz: not yet, downloading
<srbaker> jdub, uh.
<srbaker> ahh
<jdub> lifeless: ping
<srbaker> when i open the volume control, it says it's oss
<mdz> the UI is very different
<mdz> too many gradients
<jdub> srbaker: you'll have volume controls for alsa and oss for each device
<jdub> mdz: got the -gnome package?
<sivang> srbaker: try to select asla from "select multimedia system" 
<srbaker> jdub, no, i only have for OSS
<jdub> haha:
<sivang> srbaker: that's waht I usually do
<jdub> Get:3 http://archive.ubuntu.com hoary/universe openoffice.org2-core 1.9.66-0ubuntu8 [45.1MB] 
<srbaker> gah
<srbaker> it's crackly
<jdub> Get:7 http://archive.ubuntu.com hoary/universe openoffice.org2-impress 1.9.66-0ubuntu8 [153kB] 
<sivang> srbaker: after a couple of crashes for gnome, it works
<jdub> Get:8 http://archive.ubuntu.com hoary/universe openoffice.org2-writer 1.9.66-0ubuntu8 [929kB] 
<jdub> 
<jdub> modular a-go-go!
<whiprush> it's pretty crashy over here.
<jdub> hahaha
<sivang> whee whaa, modulerzied OOo ???
<jdub> mdz: nice!
<jdub> sivang: look at the packages sizes
<sivang> jdub: RAWKING
<jdub> er, no
<jdub> very silly
<sivang> ;-)
* sivang should make him self more clear wrt to sarcasm. How do to this over irc...
<srbaker> url for textmate?
<srbaker> ahh
<srbaker> tgot it
<jdub> mdz: i only see the gradients on the toolbar-too-long menus
<jdub> hrrrm, the menu padding is all out
<mdz> jdub: my menu bar has one gradient, then the toolbar has a different gradient in a different direction
<mdz> then the second toolbar has the same gradient as the first toolbal
<mdz> s/bal$/bar/
<jdub> mdz: got the -gnome package?
<mdz> jdub: not yet
<jdub> that fixes it
<jdub> mostly
<mdz> ah, that's better
<mdz> gah
<mdz> the file open dialog still crashes
<jdub> yeah, just finding that myself :|
<jdub> oh
<jdub> worked that time
<mdz> and the crash dialog is broken
<jdub> yay gnome file dialogue
<jdub> mdz: click the toolbar open button?
<jdub> hrm, no, mine both work now
<mdz> I used the drop-down menu
<lexhider> daniels: I just had a weird thing happen. On boot-up gdm came up in a really low resolution [probably 800x600 or 640x480]  and everything was HUGE. Without changing anythinga 'sudo /etc/init.d/gdm restart' fixed everything. I just want to make sure there isn't already an existing bug before I open one.
<mdz> lexhider: can you reproduce the bug by rebooting again?
<jdub> mdz: what's the patch summary for ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-109 ?
<jdub> mdz: and who committed it?
<mdz> patch-109
<mdz>     Add culmus to supported
<mdz> I did
<jdub> i just get invalid signature
<jdub> key id?
<lexhider> mdz: I'm on dialup so I'll have to try that later. It's not the 1st time, but it doesn't appear to happen everytime.
<mdz> mdz@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--hoary/seeds--hoary--0/patch-109 $ gpg --verify !$
<mdz> gpg --verify checksum
<mdz> gpg: Signature made Fri Jan 21 01:19:22 2005 GMT using DSA key ID 43E25D1E
<mdz> gpg: Good signature from "Matt Zimmerman <mdz@alcor.net>"
<daniels> lexhider: er, weird.  if you open a bug, remember /var/log/Xorg.0.log and /etc/X11/xorg.conf.
<mdz> jdub: why don't I have a signature from you on my key?
<mdz> daniels: maybe a start-gdm-earlier thing?
<jdub> mdz: because i can't believe you're not butter.
<zenrox> lol
<jdub> updated, still have invalid signature
* jdub tries a fresh get
<mdz> you're buggy
<daniels> mdz: do we do anything after S12 that could influence this?
<mdz> daniels: dunno, just a guess
<daniels> i'll check it out when I get back from the supermarket
<mdz> daniels: maybe a udev race, too
<jdub> oh man
<jdub> now i get it on 110!
<daniels> all I've had today so far is an up 'n go
<daniels> and the only things left are red eye and vodka
<jdub> mdz: who's 110?
<mdz> jdub: that's me as well
<mdz> hmm
<mdz> well
<jdub> a fresh get choked on 110, not 109
<mdz> the dir is owned by me
<mdz> but it's Colin's commit
<jdub> 10FA4CD1?
<mdz> gpg: Signature made Fri Jan 21 17:01:37 2005 GMT using DSA key ID 10FA4CD1
<mdz> which is Colin's key
<lexhider> I'll see if I can reproduce with a few reboots, bye.
<jdub> yeah
* jdub does a fresh get again
<jdub> nup
<jdub> hits the wall at 110 again
<jdub> lifeless: ping
<daniels> mdz: i can buy udev being racy
* lamont returns
<mdz> daniels: /dev/fb0?  /dev/agpgart?
<aj> does warty/hoary support the 915g chipset?
<daniels> mdz: i was thinking more /dev/nvidiactl
<mdz> I don't use that noise
<daniels> aj: warty should have basic support for 915g, hoary has full 3d for 915g and 915gm
<daniels> mdz: neither do I, but it's plausible
<aj> l33t
<daniels> aj: (ironically, it's the most advanced open driver in existence.  even that doesn't save it from the crushing weight of shit hardware, though.)
* daniels -> supermarket
<jdub> can binary packages have different versions to source packages?
<jdub> "... have a different version to the source package that produced them ..."
<lamont> jdub: see glibc
<mdz> jdub: absolutely
<jdub> lamont: hrm, not seeing different versions
<jdub> $ apt-cache show $(apt-cache showsrc glibc | grep ^Binary | sed 's#^Binary: ##;s#, # #g') 2> /dev/null | grep ^Version | uniq | wc -l
<jdub> 1
<jdub> 8)
<lamont> hrm..
<mdz> oh man, oo.o2 has problems
<jdub> well, regardless of the example, do you just put a Version: in the binary section?
<lamont> Source: util-linux (2.12p-2ubuntu1)
<lamont> Version: 1:2.12p-2ubuntu1
<lamont> Package: comerr-dev
<lamont> Source: e2fsprogs (1.35-8ubuntu1)
<lamont> Version: 2.1-1.35-8ubuntu1
<jdub> $ apt-cache show $(apt-cache showsrc util-linux | grep ^Binary | sed 's#^Binary: ##;s#, # #g') 2> /dev/null | grep ^Version | uniq | wc -l
<jdub> 2
<jdub> :_)
<lamont> I'd say look at e2fsprogs source.. :-)
* lamont has nfc how it's done
<jdub> lamont: thanks :)
<jdub> this might assist with the gtk-engines/gnome-themes fuckage
* jdub hadn't gone back to it after the stupid discussion on d-d-l about it
<lamont> sorry for being so, um, helpful. :-)
<jdub> heh
<jdub> nah, don't like having all the answer straight up :)
<lamont> jdub: but partial answers jepordize my reputation as a know-it-all. :-0)
<jdub> hahaha
<lamont> s/know-it-all/all-knowing-wizard/ :-
<lamont> _
<jdub> is there some clever lore behind choosing epoch numbers, or is starting with 1: reasonable?
<lamont> 1 is reasonable
<lamont> and has the added avantage of making it look like you only screwed up your version numbers once... :0)
<jdub> ;)
<bob2> what severity a bug is "faaaaaaaaaaaaaaaaaaaaaaaaaaaaabbionne, your 2.6.10 kernels hardlock my machine when I unplug my camera"?
<mdz> it's "leave the severity to fabbione" severity
<mdz> letting bug submitters choose severity is broken anyway
<bradb> Any plans for ndiswrapper to be built for ppc?
<bob2> it only works on i386
<bob2> unless you want a cpu emulator in your kernel ;)
<mdz> whether it works on ppc or not, there aren't any ppc NDIS drivers that I know of :-)
<bradb> bradb@oxygen:~/ndiswrapper-1.0rc4 $ grep -rin powerpc * | wc -l
<bradb> 9
<bradb> bradb@oxygen:~/ndiswrapper-1.0rc4 $
<bradb> all of those matches are in c header files
<bradb> but yeah, i had a feeling it might be a lost cause
<bradb> mandrake distributes it on ppc though. *shrug*
<mdz> it didn't build on powerpc when we (accidentally) tried
<mdz> http://people.ubuntulinux.org/~lamont/buildLogs/l/linux-source-2.6.8.1/2.6.8.1-7/
<bradb> it certainly failed here too
<mdz> but seriously, I don't think there are any ppc Windows drivers out there
<mdz> bradb: I was talking with haggai about the possibility of using Malone to track bugs in universe
<mdz> bradb: what do you think about it?
<bradb> it's a bit early for distro using malone, unforunately, other than on a case-by-case basis (which, iiuc, isn't a possibility even with universe...unless it is.)
<bradb> RSN now though. I'm almost finished support for private bugs. (maybe another full day of work on it will finish it.) Then kiko and mpt will be in Montreal over the next week to really go nuts on the UI, and, who knows, perhaps that might bring us to a really usable point for distro. The main thing we lack right at this moment is a sane way to specify distro and/or sourcepackage and/or binarypackage (as specific as the user can 
<bradb> get.) The UI isn't there yet.
<bradb> s/RSN now/RSN/
<mdz> bradb: there are only a small number of bugs reported about universe packages, but we need someplace to put them
<mdz> if malone isn't ready for it, then we'll need to set up yet another ad hoc bugzilla :-/
<mdz> and then import it later
<mdz> you don't think it's workable even with a light load?
<bradb> mdz: when do you need to do it by?
<mdz> bradb: they currently have no bug tracking facility at all
<mdz> bradb: so the sooner, the better
<bradb> kiko, mpt and I should be able to take some big steps in Montreal towards bringing that part of it to a usable state. I don't have a clear idea from kiko about exactly what we're focussing on, but I'll mention it to him tomorrow and maybe we can focus what we'd need to do to Take on the Universe next week (they're here Jan 26 - Feb 1.)
<bradb> I'll write him the email right now and Cc, just to be sure this isn't lost. :)
<bradb> s/Cc/Cc you/
<bradb> sent
* bradb & # zzz
<mdz> bradb: ok, thanks
<fabbione> morning guys
<mdz> morning
<fabbione> hey bdz
<fabbione> bah
<fabbione> mdz
<fabbione> :-)
<lamont>   ubuntu-desktop: Depends: gnomemeeting but it is not going to be installed
<lamont> bummer
<fabbione> hey lamon
<fabbione> t
<lamont> same old livecd images on all 4 architectures. :(
<lamont> hey fabbione 
* lamont is getting ready to head to bed.
<fabbione> good night :-)
<lamont> night. back in about 6 hours or so.
<lifeless> jdub: phew
<jdub> lifeless: dude, have issues for you
<jdub> mdz: what do you do for mass bogofilter spam/ham classifications?
<mdz> jdub: I have a huge corpus
<mdz> I used to dump it into bogofilter -M, but at some point it grew too large for bogofilter to handle in one go
<jdub> do you use maildir or mbox?
<mdz> so the last time I had to break it up with formail, which was much slower
<mdz> mbox
<jdub> mmm
<jdub> have to do big maildir classifications
<jdub> very slow
<opi> two more minutes and I'll have a Horay box :-)
<fabbione> jdub: did you have any time to check the installer on sparc again?
<jdub> not today ;)
<opi> nooo
<opi> [Invalid UTF-8]  Could not parse file '/usr/share/applications/ooo645calc.desktop': desktop entry contain line 'Comment[ca] =Fulla de c\xc3| lcul d'OpenOffice.org' which is not UTF-8
<Treenaks> [ca] ? /me blames Canada
<opi> dist-upgrade failed at Mozilla-Firefox
<opi> Treenaks, it's not a real country anyway ;-)
<opi> so much for a Horay
<mvo_> blame jordi ... ca == catalan
<opi> should I file a bugzilla raport or e-mail/IRC him?
<opi> it should be a quick fix
<mvo_> opi: before you file, please have a look if it is not already reported (IIRC it is)
<opi> ok then
<opi> I'll put Firefox on hold and see if rest will go up to Horay
<jdub> mdz: https://bugzilla.samba.org/show_bug.cgi?id=2092
<jdub> mdz: approve?
<jdub> mdz: at least in theory? :)
<mdz> jdub: seb128 already rolled that in, dude
<mdz> jdub: /usr/share/doc/samba-common/changelog.Debian.gz
<jdub> hah!
<fabbione> Kamion: ping?
<opi> 16:00 UTC is 17:00 CET?
<Treenaks> yes
<opi> okidok ;)
<Treenaks> opi: TZ=UTC date ;)
<opi> smurfix, that was fast :->
<opi> smurfix, I'll ask at our mailing list
<smurfix> opi: we have these domains for a few days now, I'm waiting for mako to think about my announcement text ;-)
<opi> smurfix, hehe :-)
<opi> smurfix, how about ,,we rules. now pay us.''
<pitti> Morning!
<opi> morning pitti
<fabbione> hey pitti
<fabbione> hi guys
<opi> (I think I'm tabcomp. addicted, I just typed morn<tab> to get morning)
<lifeless> jdub: what are your issues?
<fabbione> SteveA: ping
<opi> uhm..
<opi> why x-window-system-core's on hold..
<opi> ok, fixed
<haggai> what's the canonical way (not Canonical :) to close bugs?  I see closes: Ubuntu#nnn and Hoary #nnn
<haggai> (and nothing in the wiki)
<pitti> haggai: there is no official Standard
<fabbione> haggai: i use the same way as Debian does
<pitti> haggai: some use (Ubuntu: #nnnn), some just #nnnn
<haggai> pitti: do you close them in bugzilla manually?
<pitti> haggai: yes
<pitti> haggai: uploads don't close them
<mdz> haggai: none of those actually do anything
<haggai> pitti: aha, that's what was confusing me
<mdz> they're purely informational at this point
<pitti> Hi mdz
<SteveA> hi fabbione 
<mdz> good morning
<mdz> I'm headed for bed shortly
<pitti> mdz: I want to make a new upstream microrelease of pmount soon to fix some bugs
<pitti> mdz: can I upload this?
<mdz> certainly
<pitti> okay
<pitti> mdz: same for hal, there are new upstream microreleases available
<mdz> the UVF doesn't really apply to packages where one of us is upstream, so long as we follow the release guidelines for the changes we make
<pitti> mdz: however, they also contain some small new features
<SteveA> fabbione: i'm still running the kernel you made
<pitti> mdz: own upstream> makes sense :-)
<mdz> pitti: well, we're not in feature freeze quite yet
<mdz> pitti: and ogra says that he needs some of those new features for the hardware database (/proc support, apparently)
<pitti> mdz: right
<mdz> I told him to talk to you about whether we should bring in a new hal
<pitti> mdz: okay, then I coordinate this with him
<fabbione> SteveA: i read what you wrote.. i am hounestly not sure what to do more than that. I backported the entire new bluez stack. Perhaps you need the firmware installed?
<mdz> but...CC meeting in 7 hours, so I'm off
<pitti> mdz: he already told me about his plans
<mdz> ok, good
<pitti> mdz: good night!
<fabbione> night mdz
<SteveA> fabbione: maybe.  is there something in /sys/ or /proc/ that i can look at to see if the kernel even knows about the CF card?
<fabbione> SteveA: probably.. i don't know which entries the bluez stack creates around. you will need to poke around yourself.. lacking that hardware here, doesn't make it simpler for me
<SteveA> I'll mail you the card if you want.  Just scrap metal and plastic here.
<opi> damn, damn
<opi> after update to x.org prop. NVidia driver gone mad
<fabbione> SteveA: can you try using the firmware?
* SteveA inserts the card again and pokes around
<pitti> ogra: ping
<fabbione> SteveA: or give me a way to check /proc
<pitti> sjoerd: ping
<opi> splash screen covers everything, so even after loggin all I see is NVidia logo
<opi> with Option "NoLogo" there's a blank screen
<opi> it worked with nv driver
<opi> anyone saw something similar?
<sjoerd> pitti: pong
<pitti> sjoerd: Morning!
<sjoerd> morning :)
<pitti> sjoerd: any plans to package hal 0.4.7?
<sjoerd> ofcourse
<ogra> pitti: pog....hal meeting ? :)
<ogra> pong even
<pitti> sjoerd: cool! it seems that it (once again) includes all patches, right? :-)
<pitti> ogra: there recently was a thread about /proc/ support on the hal list
<ogra> yup
<sjoerd> ogra: you have about 10 minutes to ask questions :)
<ogra> thanks for pointing me there, i owe you a beer or something :)
<pitti> ogra: do you know whether you need the new 0.4.7 for your project? or would 0.4.4 be sufficient in principle?
<sjoerd> pitti: well, i've not added patched to the debian for some time now so :)
<ogra> i'm not sure which one is the first to have proc support, but this one i will need
<pitti> I would like to package 0.4.7 anyway, but I don't want to interfere with your work
<pitti> sjoerd: right, this stable branch was really a good idea
<sjoerd> ogra: what proc support are we talking about ?
<sjoerd> pitti: yeah, HEAD code is basically a complete rewrite
<ogra> sjoerd: i want /proc/cpuinfo in hal....
<sjoerd> ogra: 0.6.x :)
<ogra> sjoerd: argh
<ogra> sjoerd: any chance to backport something of that ?
<sjoerd> or if you have some simple patches, maybe david will accept them
<ogra> ok
<sjoerd> ogra: it's not even in yet.. for now it's mostly acpi and pmu stuff
<Treenaks> sjoerd: HEAD doesn't compile on my Suse box 8)
<sjoerd> Treenaks: you don't want had right now
* ogra shudders
<sjoerd> s/had/head/
<sjoerd> (the procfs code is mostly acpi and pmu stuff)
<sjoerd> ogra: do you want the complete /proc/cpuinfo in hal or just some pars ?
<Treenaks> sjoerd: dbus doesn't work anyway.. so hal won't do a thing either ;)
<ogra> sjoerd : heh, im fine with everything i can get :)
<sjoerd> well you must have some reason to want the properties right :)
<sjoerd> Treenaks: you also don't want dbus cvs currently :)
<pitti> ogra: you have to create the patches against 0.4.x for Ubuntu anyway
<pitti> ogra: we will not have 0.6 in Hoary
<Treenaks> sjoerd: tell jhbuild ;)
<ogra> pitti: yeah, looks like...
<sjoerd> ogra: probably nice if you could discuss the properties you want on the hal list.. So they will be the same in 0.6
<pitti> ogra: but keep it as simple as possible and leave the "real" and generic solution for hal upstream
<ogra> pitti: if there is already something in HEAD i can dervie from, i will take that
<sjoerd> ogra: it's not yet in, just discussion, spec and some playing code from some guy..
<ogra> sjoerd: but at least there is a skeleton.....(spec)
<sjoerd> yeah, but you might need to add stuff to the spec
<ogra> thats no prob....
<ogra> you know the problems with the writer and the empty sheet of paper ;)
<sjoerd> heh
<Kamion> fabbione: yo
<fabbione> hey Kamion 
<fabbione> SteveA: re
<fabbione> Kamion: for that kernel problem.. i have half of an idea.. can you try to just rebuild the kernel locally?
<fabbione> i am kinda suspicious about compilation options that are applied on the buildd
<fabbione> and if you can spot if it was introduce in a specific version would also be great
<Kamion> ok, sure
<Kamion> fabbione: definitely 2.6.10-10
<Kamion> fabbione: 2.6.10-9 works great
<fabbione> because it's a little while that i don't update x86_64 specific bits
<Kamion> fabbione: hm, should I try with 2.6.10-11 first?
<Kamion> since that hit my mirror last night
<fabbione> Kamion: if you can that would be nice
<jordi> mvo_: ping
<mvo_> jordi: pong
<jordi> mvo_: when synaptic broken due to the libglade2 bug, did you change anything in the code, or just rebuilt? Do you have any reasoning for why the toolbars were fucked?
<mvo_> jordi: I saved and loaded the glade file with a new glade. the old glade file was incompatible with the new libglade
<mvo_> the toolbar is fucked because libglade2 changed 
<jordi> so might it be a glade-2 bug, not a libglade2 one?
<Kamion> fabbione: 'k, on way
<fabbione> Kamion: no rush :-)
<mvo_> it's a libglade2 bug. the new glade generates GtkToolbarButtons in the glade file, the old one just generates GtkButtons
<smurfix> How can I run an installer-level program (like, for instance, kbd-chooser ;-) without actually booting into the installer?
<Kamion> may as well do it now while I'm thinking about it
<Kamion> smurfix: there are various 'make demo' targets in debian-installer
<Kamion> but in general it's hard, particularly for stuff like kbd-chooser that really cares about the hardware
<mvo_> the "fix" was to regenerate the toolbar with gtktoolbuttons from glade, but libglade should handle a toolbar with GtkButtons equally well 
<fabbione> Kamion: also... when you have time.. we finally have a strace for sparc, so if you can kindly queue up in your debootstrap TODO list to revert that change, it would be just great
<mvo_> the real "problem" is that the GtkToolbar code in gtk changed 
<Kamion> smurfix: most d-i developers create cheap images like netboot for that kind of testing
<mvo_> melt is bitten by this problem too BTW
<fabbione> Kamion: (we did an exception since strace was FTBFS)
<fabbione> Kamion: but i didn
<Kamion> fabbione: righto
<fabbione> Kamion: but i didn't want to upload straigh ahead because i remember you talking about generating the lists from seeds or something
<jordi> mvo_: yes, that's the bug we're trying to chase.
<jordi> mvo_: we fear there might be other apps affected.
<Kamion> fabbione: yes, it's automatic, will rerun
<jordi> but no other have been identified
<fabbione> thanks!
<Kamion> well, semi-automatic
<fabbione> :-)
<mvo_> jordi: there is a patch floating around for libglade that may fix it
<mvo_> jordi: each app that don't use a recent glade and uses glade to build it's toolbar is affected
<mvo_> s/uses glade/uses libglade/
<jordi> mvo_: where is that patch?
<Kamion> smurfix: BTW if you're on powerpc you can boot a netboot image straight off a filesystem without actually having to do a real netboot ...
<elbi> a question, why don't you have a php imap package in warty? (neither multi- or universe)
<Kamion> image=/home/cjwatson/src/debian/debian-installer/trunk/debian-installer/installer/build/dest/powerpc/netboot/vmlinux
<Kamion>         label=random26
<Kamion>         read-only
<Kamion>         initrd=/home/cjwatson/src/debian/debian-installer/trunk/debian-installer/installer/build/dest/powerpc/netboot/initrd.gz
<mvo_> attached to #290811, 288445
<Kamion>         root=/dev/ram
<Kamion> stuff like that
<mvo_> jordi: I can also forward it to you by mail
<smurfix> Kamion: Thanks. For now. ;-)
<mvo_> jordi: (gnome BTS number is #163322 btw)
<Kamion> pitti: has anyone told you that all the language packs are uninstallable on ia64?
<Kamion> pitti: they all have a versioned dep on libc6 ... ia64 has libc6.1
<jordi> oh
<jordi> there is recent activity in this bug
<jordi> ah, no, I had read this already.
<Kamion> fabbione: doesn't seem to be on sparc.ubuntu.com yet?
<thom> sladen: have you read #5361? is the reporter on crack?
<thom> morning, y'all
<pitti> Kamion: urgh, no
<pitti> Kamion: the versioned depends was just to ensure that you use it with a libc6 with /usr/share/locale-langpack support
<jordi> mvo_: if you could mail it I would build a fixed package right now
<fabbione> Kamion: not yet.. do you want me to push it? it's in the buildd queue
<pitti> Kamion: would "libc6 (>= foo) | libc6.1 (>= bar)" do the job?
<fabbione> Kamion: behind the kernel and libc6 :(
<Kamion> pitti: best answer's probably to use ${libc-depends} or whatever and substitute in libc6 (>= 2.3.2.ds1-19ubuntu2) using substvars
<Kamion> pitti: libc6 | libc6.1 works technically but is ugly - substvars are much nicer
<mvo_> jordi: send
<pitti> Kamion: and determine the platform in debian/rules. Okay
<mvo_> jordi: as I wrote, not tested, not reviewed
<jordi> mvo_: you don't mean marga's patch that reverts some of the changes, right?
<jordi> mvo_: ok
<Kamion> pitti: do something like dh_gencontrol -- -V'libc-depends=$(LIBC) (>= 2.3.2.ds1-19ubuntu2)' maybe?
<mvo_> jordi: I'm afraid that's what I send you :(
<Kamion> fabbione: no hurry
<jordi> mvo_: oh dear.
<fabbione> Kamion: ok thanks :-)
<Kamion> pitti: if you're maintaining a list ... alpha/ia64 have libc6.1, hurd-i386 has libc0.3
<mvo_> jordi: so this is not the right fix? bad :/
<pitti> Kamion: hmm, but I guess that nobody modified libc6.1 / libc0.3 to support the alternate gettext tree?
<jordi> mvo_: what happens with the pakcages now using the new api?
<Kamion> pitti: they're all from the same source package
<pitti> Kamion: oh, nice
<Kamion> pitti: glibc just generates different names depending on the architecture
<Kamion> for historical reasons
<pitti> Kamion: then the versions should indeed be the same
<Kamion> e.g. alpha/ia64's soname changed when some different 64-bit syscalls got introduced, I think
<Kamion> yes, definitely
<mvo_> jordi: it just reverts everything? that's clearly wrong.
<elbi> a question, why don't you have a php imap package in warty? (neither multi- or universe)
<fabbione> elbi: becasue it is too buggy to be maintained properly
<fabbione> and it is cause of several headackes
<jordi> mvo_: yeah
<SteveA> fabbione: well... i was trying out the hcitool and rfcomm commands to see what worked, and the whole machine locked up
<SteveA> fabbione: so, i guess it isn't ready for prime time
<fabbione> that's not nice
<fabbione> ok
<SteveA> the card is certainly detected
<SteveA> and it is presenting itself in the right way to the tools
<fabbione> but it wasn't before.. right?
<SteveA> but it didn't actually *work*
<SteveA> yes, I'm in the usual hoary kernel now
<SteveA> and the card isn't detected at all
<fabbione> not even with cardinfo status?
<SteveA> oh wait
<SteveA> that's odd
<SteveA> it appears in hcitool on the second insertion
<fabbione> SteveA: HMMMMM do you actually hear a bip or two bips when you insert the card the first time?
<fabbione> because there is a code behind the beeps to decode the pcmcia status
<jordi> hi SteveA 
<fabbione> first beep(high tone): pcmcia got the card
<fabbione> second beep(high tone): driver is loaded correctly
<elbi> fabbione, several php mail clients depend on that module, so ubuntu shouldn't be used on apache/php deployments?
<fabbione> second beep(high tone): no driver available
<Kamion> fabbione: FWIW 2.6.10-11 still dies
<Treenaks> fabbione: that's second beep(low tone)
<fabbione> Kamion: ok.. :(
<trukulo> hi
<fabbione> Treenaks: right
<elbi> any way to compile the module manually? fabbione 
<Kamion> trying a rebuild now
<fabbione> elbi: yes but this is offtopic here, ask in #ubuntu
<fabbione> Kamion: i doubt it will solve...
<fabbione> Kamion: the only major change is the inotify patch
<SteveA> fabbione: hmm -- same on usual hoary kernel
<Kamion> fabbione: I might try backing out individual changes from 2.6.10-10
<fabbione> SteveA: ok. the driver is way buggy
<SteveA> fabbione: crashed when i reinserted the card a few times and ran rfcomm
<fabbione> Kamion: if you want i can build kernels for you on concordia. I have everything ccached
<fabbione> SteveA: can you add all these info to the bud i mentioned yesterday
<fabbione> ?
<SteveA> fabbione: okay.  i'll keep an eye on the bluez development list to see if support for the card improves
<Kamion> fabbione: mm, that'd certainly be faster if you don't mind and you know what the best candidates to back out are ...
<SteveA> fabbione: okay
<fabbione> Kamion: i don't mind at all....
<fabbione> SteveA: thanks
<fabbione> Kamion: what flavour do you need?
<Kamion> fabbione: generic's fine
<fabbione> Kamion: ok thanks
<Kamion> it's a K8 but I've been doing the testing with generic since that's what's on d-i CDs
<fabbione> ok
<fabbione> Kamion: also because i love to push concordia up to Load: 430 :-)
<fabbione> make -j 400 is teh r0ck
<SteveA> fabbione: comment feels a bit random.  hope it helps.
<SteveA> thanks for looking into this/
<fabbione> SteveA: welcome dude
<fabbione> Kamion: building now
<fabbione> haggai: did you ever get around to check ooo1?
<haggai> fabbione: yes I did, I'm looking at it
<fabbione> ok
<fabbione> great
<fabbione> hey rburton !
<fabbione> jdub: any news about 5431?
<rburton> hi fabbione 
<jdub> fabbione: not yet
<fabbione> ok
<fabbione> my god.. concordia is so slow....
* fabbione hides
<fabbione> Kamion: people.u.c/~fabbione/
<fabbione> there is a kernel image for you to test there
<Kamion> fabbione: downloading; what's changed?
<fabbione> reverted inotify patch
<fabbione> from new to old one
<fabbione> but still there
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<jdub> lifeless: so
<opi> uff. Done. http://opi.pegasos.pl/?siurp=single&id=220 :P
<lifeless> jdub: ah,finally, we pong together
<jdub> lifeless: i'm having problems doing fresh checkouts of the seeds archive
<jdub> lifeless: because there's an invalid signature on patch 110
<jdub> lifeless: however, it works fine for mdz
<lifeless> can you cat the checksum file for me ?
<lifeless> 21:34 <lifeless> ok, that looks fine to me, I'll be its gpg.
<lifeless> 21:34 <lifeless> save that file on your dist, then run sh ~/.arch-params/signing/<relevant .check rule> < path-to-that-file
<lifeless> 21:34 <lifeless> *disc*
<lifeless> 21:35 <lifeless> the relevant check rule is archive-name.check, or, =default.check, searched for in that order.
<lifeless> that should be 'I'll bet its gpg'
<thom> lifeless: your typing seems somewhat off beam today
<lifeless> thom: its on plastic chair is why.
<lifeless> no beam at all.
<fabbione> was it -ctime or -mtime to identify file created more than N days ago?
<Kamion> grr, people who think forums are the ideal place for bug reporting
<fabbione> (using find)
<lifeless> ctime
<lifeless> created ;)
<fabbione>               File's status was last changed n*24 hours ago.
<Kamion> ctime is not created timestamp, it's status last changed timestamp
<Kamion> there is no created timestamp
<fabbione> that's why the manpage says changed?
<fabbione> ;)
<lifeless> oh, crapola.
<jdub> $ sh /home/jdub/.arch-params/signing/\=default.check < checksum; echo $?
<jdub> 1
<jdub> 
<jdub> ok
<jdub> farout
<jdub> my fault
<lifeless> man, thats crack, what is the different from 'mod' and 'change' to a file ?
<fabbione> Kamion: what would you suggest? i simply need to create some kind of morgue script to remove old files from a dir
<Kamion> fabbione: that kernel still segfaults
<jdub> bazaar-gpg-check > baz-gpg-check
<lifeless> jdub: ;)
<Kamion> lifeless: modification => contents changed, change => inode changed
<Kamion> AIUI
<fabbione> Kamion: ok... let's try something else...
<jdub> lifeless: are the gpg-related improvements slated for 1.2?
<lifeless> jdub: not at the moment, we're looking at 'log', 'import', 'export', and 'resolved'.
<jdub> ok
<pitti> seb128: is there any chance that we could get gnome-vim integration into Evolution for Ubuntu?
<lifeless> and if you are a good boy, we might even give you some annotate.
<seb128> pitti: is that an existant stuff ? or should we code it ? :p
* seb128 uses emacs
<jdub> no, it's total crack
<jdub> it replaces the editor component
<jdub> but you have to modify the evo source or binary to do so
<seb128> urg
<pitti> seb128: existing
<pitti> seb128: http://www.opensky.ca/~jdhildeb/software/gnome-vim/
<pitti> seb128: look at http://www.opensky.ca/~jdhildeb/software/gnome-vim/evolution.png
<pitti> seb128: we already have a vim-gnome package in main, not sure whether this is already the one part
<pitti> seb128: however, it seems that our Evolution does not support changing the editor
<pitti> seb128: or does it?
<pitti> seb128: I could not find the option
<jdub> it doesn't
<seb128> it doesn't
<jdub> you ahve to mod the source or binary
<jdub> this is serious crack, dude :)
<seb128> but what's wrong with the textview ?
* mvo_ would like to use emacs with evo
<pitti> jdub: it _is_ crack, but it is good one
<jdub> looks like he's got patches for very old evo
<jdub> to do editor switching
<pitti> I just cannot get used to using another editor than vim any more...
<jdub> which is at least an improvement to the old patches
<pitti> jdub: yeah, that's the problem
<pitti> jdub: however, why is such a thing not adopted upstream?
<jdub> because this is hideously old and hacky
<pitti> jdub: changing the editor should be reasonably generic 
<fabbione> Kamion: building another kernel now
<jdub> if you want to update his patches and submit them upstrea, that'd be great
<jdub>  iw oudl use it too :)
<pitti> whenever I find myself in a non-vim editor, I use to destroy the file by putting "ifoo:w" or "jjjjjkkdw" all over the place...
<stub> I reported a bug in the Roundup package upstream since the Ubuntu Bugzilla didn't want it, but the package maintainer says it is installable for him. Can someone quickly try to install Roundup and let me know if it is an Ubuntu problem (victimized by Python2.4 likely) or upstream ? 
<jdub> haha, same 8)
<pitti> jdub: well, for now I'm a hard core mutt user
<pitti> jdub: but I wanted to at least take a look at the software we are shipping :-)
<lifeless> I have a couple of hardware bugs right now ...
<Kamion>  Package: roundup
<Kamion>  Depends: python (>= 2.3), python (<< 2.4)
<Kamion> just needs trivial fixes for python 2.4 I think
<lifeless> started happening with the 10-2 kernel (&acpi support at the same time). They are 1) fn-F4 (sleep now please) doesn't have any affect, and 2) many times, usb key plugni events don't result in the kernel seeing the usb storage device.
<Kamion> stub: ping one of the masters of the universe and get them to fix it
<stub> Kamion: Who plays He-Man? (I play dumb-user myself)
<Kamion> stub: http://www.ubuntulinux.org/wiki/MOTU
<fabbione> Kamion: new kernel up: removed the 2 patch stolen from upstream and old inotify patch
<stub> Kamion: Ta. Bounced to ogra.
<fabbione> Kamion: i am slowly going back to -9 basically...
<fabbione> there is only one or two changes left that might affect the thingy
<fabbione> after that is -9
* fabbione -> food
<jdub> fabbione: you reverted inotify?
<lifeless> fabbione: any thoughts on my question about usb & fn-sleep ?
<Kamion> jdub: for testing purposes, trying to nail down my amd64/grub problem
<thom> lifeless: check /etc/defaults/acpi-support for the latter
<jdub> Kamion: ahr
<lifeless> thom the new acpi-support package replaced it
<lifeless> thom: what should I look for .. ACPI_SLEEP=true ?
<thom> yeah
<thom> make sure that's uncommented ;-)
<lifeless> ok, thats one.
<lifeless> oh yeah, ipw2200 doesn't come back from sleep
<lifeless> I have to remove and add it, was mjg's magic to do that reverted ?
<thom> add it to the list of modules lower in that file
<lifeless> done
<lifeless> thanks.
<lifeless> now for the usb thing ...
<lifeless> usb 4-1: new full speed USB device using uhci_hcd and address 2
<lifeless> usb 4-1: device descriptor read/64, error -71
<lifeless> usb 4-1: device descriptor read/64, error -71
<lifeless> u
<lifeless> is what I see when it fails..
<fabbione> lifeless: what kernel version are you running?
<lifeless> Linux lifelesslap.robertcollins.net 2.6.10-2-686 #1 Wed Jan 19 18:58:12 UTC 2005 i686 GNU/Linux
<fabbione> i mean the debian version... 2.6.10-???
<nakee_> what's the url to see what package a langauge pack has?
<lifeless> fabbione: -10
<pitti> nakee_: apt-cache search language pack <yourlanguage>
<pitti> nakee_: if you know your language code (de, en, he, etc.), it's language-pack-<langcode>
<pitti> nakee_: for Israel it should be -he
<nakee_> pitti thanks, but is there a way to see it from the web?
<fabbione> lifeless: do you get these messages after a resume?
<nakee_> I want to show it to people who doesn'thave ubuntu yet
<pitti> nakee_: not yet
<fabbione> lifeless: or after a reboot?
<lifeless> fabbione: after a clean boot
<lifeless> fabbione: modprobing usb-storage seems to help
<pitti> nakee_: there will be a web platform which can do this in the near future, but not right now :-(
<nakee_> pitti not even like debian package search?
<fabbione> lifeless: how does it help? is that happening with a usb storage of any kind?
<pitti> nakee_: no
<nakee_> oh.. too bad
<lifeless> fabbione: its my usb flash key.
<pitti> nakee_: at most http://archive.ubuntu.com/ubuntu/pool/main/l/
<fabbione> lifeless: well usb-storage should be loaded automaticcally... 
<lifeless> fabbione: yah, all I know is this never happened before the latest round of updated
<lifeless> *s*
<fabbione> HMMMMM GRRRRR
<nakee_> pitti that has only the po files, I thought it also have other programs?
<nakee_> or is it added as dependencies?
<pitti> nakee_: the dependencies come with language-support-he
<pitti> nakee_: the packs only have translations (mo files)
<nakee_> ok that's what Iwas looking for (the meta package)
<nakee_> if I want to add request packages to be added I need to submit a bug report right?
<pitti> nakee_: you can also ask me straight away
<pitti> nakee_: the next version will depend on the culmus package
<fabbione> lifeless: the only usb change between -9 and -10 is to fix an irq issue on a few ehci driven controllers...
<fabbione> lifeless: are you using ehci?
<lifeless> ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
<lifeless> PCI: Setting latency timer of device 0000:00:1d.7 to 64
<lifeless> ehci_hcd 0000:00:1d.7: irq 5, pci mem 0xe8000000
<lifeless> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
<lifeless> PCI: cache line size of 128 is not supported by device 0000:00:1d.7
<lifeless> ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
<Kinnison> jdub: how about base-files, apt-utils or dpkg to house that script?
<lifeless> hub 5-0:1.0: USB hub found
<lifeless> hub 5-0:1.0: 8 ports detected
<fabbione> lifeless: don't flood the chan dude!
<lifeless> fabbione: oh this is interesting...
<lifeless> sorry, didn't think 8 lines was a flood.
<ups_> i've jut upgraded to hoary, does it install a x11.pc file?
<Kamion> it's *so* not appropriate for base-files
<lifeless> anyway, it looks like ehci and uhci are fighting for the device.
<lifeless> when it fails, I see:
<Kamion> something related to the package manager seems better
<lifeless> usb 5-3: new high speed USB device using ehci_hcd and address 7
<lifeless> usb 2-1: new full speed USB device using uhci_hcd and address 4
<lifeless> usb 2-1: device descriptor read/64, error -71
<lifeless> and when it works, the uhci line does not show up.
<Mithrandir> Kamion: I think ubuntu-utils or distribution-utils would be the right place.
<fabbione> lifeless: can you try to unload the uhci driver?
<lifeless> fabbione: unloaded uhci_hcd, now it just lists 
<lifeless> usb 5-5: new high speed USB device using ehci_hcd and address 10
<fabbione> ok, but does the stick work?
<lifeless> but not the new sda1 etc etc stuff
<Kamion> "distribution-" bugs me as a prefix; it's so obviously a hack, instead of giving the thing a proper name :)
<fabbione> hmmmm
<fabbione> lifeless: try the other way around.. unload ehci and load uhci
<lifeless> done that :)
<lifeless> great minds and all that, and its working fine
<Mithrandir> fabbione: any idea why I'm getting a zillion of:
<Mithrandir> hub 5-0:1.0: over-current change on port 5
<Mithrandir> hub 5-0:1.0: over-current change on port 6
<fabbione> Mithrandir: no....
<Mithrandir> seems to be triggered each and every time a keyboard, disk or network interrupt is received
* fabbione is going to disable USB from the next kernel
<fabbione> Mithrandir:
<fabbione>  * See USB 2.0 spec Table 11-22
<fabbione> #define USB_PORT_STAT_C_OVERCURRENT     0x0008
<fabbione> ok.. who has these specs?
<fabbione> that happens in a loop that verify the usb port status changes....
<lifeless> fabbione: is uhci usb 2 ?
<Mithrandir> fabbione: http://www.usb.org/developers/docs/usb_20.zip
<fabbione> lifeless: nope.. usb1
<lifeless> cause this laptop is meant to be usb2.
<fabbione> lifeless: well please can you try usb1 in the meanwhile?
<lifeless> fabbione: I'm just exploring the problem
<fabbione> hey.. the usb specs are only 10MB compressed!
<lifeless> as I said, uhci worked fine.
<abelli> if gnome-volume-manager, should i check if my user is in the "plugdev" group?
<fabbione> lifeless: ok.. than the driver is buggy as much as all the USB subsystem
<abelli> fabbione: you should see the hardware ones :)
<lifeless> fabbione: so, it sees the new device with ehci, but doesn't invoke the other stuff
<abelli> i think i missed "doesnt automount usb things" :)
<fabbione> abelli: nothing like that..
<abelli> fabbione: because in users ive been suggested to do so..
<abelli> fabbione: what should i do?
<Mithrandir> 11.24.2.7.2.4 C_PORT_OVER-CURRENT
<Mithrandir>    This bit is set when the PORT_OVER_CURRENT bit changes from zero to one or from one to zero. This
<Mithrandir>    bit is also set if the port is placed in the Powered-off state due to an over-current condition on another port.
<Mithrandir>    This bit will be cleared when the port is in the Not Configured state or by a
<Mithrandir>    ClearPortFeature(C_PORT_OVER_CURRENT) request.
<fabbione> abelli: pay us a few liters of beer?
<abelli> fabbione: obviously
<abelli> yes
<abelli> ...italian discount beer.
<fabbione> Mithrandir: yes.. i am reading.. that looks pretty much an hardware problem.. 
<Mithrandir> fabbione: I hate you. ;)
<Mithrandir> fabbione: I might need to whack the board, then
<fabbione> YES YES YES I WIN YES YES!!!!!
<Mithrandir> especially given that I don't see the error on another card of the same kind.
<fabbione> my profecy that all the hardware that the kernel doesn't handle is BROKEN
<Mithrandir> s/card/board/
<fabbione> Mithrandir: mostlikely a shortcut?
<fabbione> or something like that could cause that situation
<Mithrandir> fabbione: not sure; the board is nice and stable.
<fabbione> Mithrandir: a shortcut on one of the usb ports
<fabbione> doesn't need to be everywhere
<fabbione> what happens if you downgrade the kernel?
<fabbione> or is it something completely new?
<Mithrandir> seems like something was fixed in the kernel wrt my IDE controller as well, since I've stopped getting errors about DMA shit.
<Mithrandir> fabbione: it's not new, but I don't see it with the live CD.
<Kamion> getopt(1) is the best thing ever
<fabbione> Mithrandir: the livecd had some issues with USB due to other reasons.. not sure which version you tested
<fabbione> Kamion: i did upload a kernel for you
<Mithrandir> fabbione: the one on archive.u.c about three hours ago.
<Kamion> fabbione: I know, in the middle of the test cycle now
<Kamion> got distracted by shiny new shell constructs
<abelli> fabbione: real ale? is it ok?
<fabbione> lifeless: i am trying to see if there is something mentioned anywhere in bk (other than pulling the entire new USB sybsystem)
<fabbione> Kamion: roger :)
<Kamion> real ale++
<lifeless> fabbione: thanks! If I can provide any diagnostics, let me know
<Kamion> fabbione: (unless you uploaded a new one since 10:59?)
<fabbione> abelli: you can survive with it
<fabbione> Kamion: it's a -10
<fabbione> it's that one..
* Mithrandir notes thom still owes him real UK beer, since he forgot to bring some to Mataro.
<abelli> fabbione: long island?
<fabbione> lifeless: i will....
<fabbione> abelli: nah...
<abelli> fabbione: please... 
<fabbione> abelli: i am lost.. we were talking about beer.. and now you come up with a cocktail...
<abelli> fabbione: martini... george... sambuca... limoncino... peroni... stella artois... :)
<fabbione> nahhh that's for kids
<abelli> im sorry i dont drink beer..
<Mithrandir> abelli: what did you really ask about before you started offering us alcohol? :)
<fabbione> abelli: 70% campari + 30% dry gin on ice
<fabbione> one slice of lemon...
<fabbione> or beer and whisky....
<fabbione> it takes too long to get drunk with long island
<abelli> Mithrandir: gnome-volume-manager doesnt automount usb dings on my laptop, what should i do
<abelli> beer and whisky?!?
<fabbione> abelli: the answer to that doesn't change...
<fabbione> still pay us beer to know the solution
<abelli> i will..
<fabbione> abelli: yes.. beer and whisky
<Mithrandir> fabbione: it does _not take long_ to get drunk on LIIT.
<fabbione> LIIT?
<abelli> fabbione: #define litres ?howmany?
<thom> long island iced tea
<abelli> thom: yeah mate
<thom> fabbione: ^
<Mithrandir> abelli: and your user is member of plugdev?  does pmount /dev/sda1 work?
<fabbione> thom: gotcha.. but i still prefer other stuff
<thom> sure, i was just expanding the acronym :P
<fabbione> Mithrandir: the funny thing is that it looks fb related
<fabbione> and i don't have fb here of anykind
<fabbione> i am on console :-)
<Mithrandir> fabbione: weird; what does the problem look like?
<Mithrandir> kernel stufF?
<Mithrandir> s/F/f/
<fabbione> Mithrandir: accoding to jdub it fails to configure the fb and d-i starts looping
<fabbione> but there are no sparc changes between the 2 kernels in ubuntu5 and ubuntu6
<Mithrandir> huh
<fabbione> Kamion: strace for sparc has been accepted.. it should be on the mirror pretty soon
<smurfix> Kamion: got time for a few not-quite-trivial "need to extend cdebconf" questions, or should I take them to mail?
<Kamion> smurfix: go ahead
<Kamion> fabbione: still segfaults
<pitti> mvo_: ping
<pitti> mvo_: (no security, so don't flee :-) )
<ogra> hehe
* mvo_ was about to duck and run
<mvo_> pitti: pong
<smurfix> Kamion: basically what I need to do is to ask the user to press a key, and get the resulting keycode back.
<pitti> mvo_: you are doing the upgrade hooks, right?
<mvo_> pitti: yep
<smurfix> Kamion: either that, or interpret a whole list of such questions entirely within cdebconf
<pitti> mvo_: can these somehow take care of installing the language packs?
<pitti> mvo_: so, isntall all langpacks for current /etc/locale.gen
<Kamion> fabbione: hm, damnit, not sure I have the right kernel installed actually
<Kamion> smurfix: oh, gar, that non-debconfy thing
<mvo_> pitti: a hook is basicly a information message + a optional script that the use can run (if he want). don't know if that suits your needs
<mvo_> it's kind of per-use-debconf question with script runing in the desktop context 
<mvo_> (and as the user itself)
<Kamion> smurfix: the only sane way I can see to do that is with a custom widget
<pitti> hmm, I think I rather need some system-level hook
<Kamion> smurfix: but we don't have those yet
<pitti> mvo_: any idea how/where we could do that?
<mvo_> what do you need exactly? after a warty-hoary update install all language packs that are in /etc/locale.gen?
<Kamion> smurfix: if I were you I'd implement an extra question type in debconf called "detect-keyboard" or whatever you want to call it, and implement support for asking that question type in the newt frontend
<Kamion> er, s/debconf/cdebconf/
<Kamion> smurfix: it'll have to be done again for gtk anyway
<Kamion> smurfix: the value of that question on return should be just the keyboard type, not keycodes or anything
<Kamion> that way it can be preseeded
<pitti> mvo_: exactly that
<smurfix> Kamion: Makes sense. Interpreting the mini-script I'm generating doesn't take much code
<pitti> mvo_: and probbaly install language-support-$(default locale language)
<Kamion> it'll have to be C, we don't have bindings to allow cdebconf widgets to be implemented in other languages yet
<smurfix> Kamion: Didn't think I could use Python at netinstall time anyway ;-)
<mvo_> pitti: tricky ... it could be done with the upgrade hook. tell the user about the language packs and ask if he wants to run a script that detects and installs it for them. the script can be a nice zenity dialog thing (or even python) that calls gksudo synaptic at the ends and feeds some packages into it
<smurfix> Kamion: What happens if a frontend doesn't implement that kind of question?
<pitti> mvo_: hmm, maybe just "gksudo apt-get install language-pack-* language-support-*"?
<pitti> mvo_: however, if the upgrading involves calling synaptic anyway, then just markign the packages as to-be-installed is better
<mvo_> pitti: sure, fair enough. you know that I'm biased about the front-end to use ;)
<fabbione> Kamion: linux-image-2.6.10-2-amd64-generic_2.6.10-10_amd64.deb
<pitti> mvo_: as long as it happens somehow, I don't care too much, too :-)
<Kamion> smurfix: erm ... reading the code, I think it'll be silently ignored. This is probably a cdebconf bug.
<Kamion> (feel free to send a patch for that one)
<Kamion> fabbione: yeah, I'd just installed -11 by accident; downgrading now
<Kamion> fabbione: (bearing in mind that I'm now not 100% sure that my previous test was valid)
<fabbione> Kamion: argh...
<fabbione> ok
<fabbione> no big deal...
<fabbione> this one incorporates old change + another one
<fabbione> so if this still fails, the previous would have failed too
<mvo_> pitti: is it correct that this script is about the warty-hoary upgrade?
<pitti> mvo_: yes
<pitti> mvo_: "this script" does not yet exist, however
<mvo_> pitti: this is a problem then because a user upgrading from warty to hoary will not have update-notifier in it's session and there is no way (in gnome) to automatically add it to his session. so it will probably not run (only if the user starts it by hand)
<pitti> mvo_: hmm, right
<pitti> mvo_: OTOH we don't need this script any more for Hoary->Bendy
<mvo_> yes ..
<abelli> bon jour
<pitti> mvo_: The brute approach would be to add yet another language-pack-meta package
<pitti> mvo_: this package would install the actually required packs
<pitti> mvo_: and ubuntu-desktop (or -base) would depend on l-p-meta
<Kamion> uh
<pitti> mvo_: the only question is how l-p-meta shall trigger the installation
<Kamion> that breaks fresh installations
<pitti> because callign apt in l-p-meta's postinst is out of question
<pitti> Kamion: why?
<Kamion> oh, um
<pitti> or even better,
<Kamion> I think I see - but I don't think this approach will work
<pitti> Kamion, mvo_: could this be integrated into ubuntu-base/desktop directly?
<Kamion> we need a script to do upgrade tasks anyway
<Kamion> let's not, please
<pitti> okay
<Kamion> it doesn't belong there
<mvo_> Kamion: what kind of stuff will this script do?
<pitti> Kamion: if we already have a system-level upgrade script, then it can just be added there
<Kamion> an upgrade script has been on the wishlist for a while - I don't think it should be crowbarred into ubuntu-meta though
<HrdwrBoB> I think there are old debian 2.4 kernel packages in universe
<HrdwrBoB> can they be removed?
<pitti> Kamion: the only requirement is that this script is not called (transitively) from apt/dpkg
<Kamion> mvo_: not sure :-)
<Kamion> pitti: yes, it has to be post-upgrade, same kind of thing as base-config
<mvo_> so we need upgrade-config :) ?
<Kamion> I actually said once that it should be part of base-config, although I'm not sure about that
<azeem> are universe packages still getting autobuilt when new versions in unstable appear?
<Kamion> well, maybe 'base-config upgrade'
* pitti votes for putting a big red label on the CD saying "Please install l-p-foo"
<Kamion> azeem: no, that stopped at upstream version freeze
<elmo> boggle, WTF is oidentd doing with the gateway ip
<azeem> Kamion: ah, thought that was only for new upstream revisions, not new debian revisions
<fabbione> elmo: iirc the client ip is embedded in the answer...
<fabbione> so it needs to know to be able to answer properly
<Kamion> azeem: new Debian revisions are allowed but you'd have to request them manually
<azeem> Kamion: ok. To MOTU I assume
<elmo> actually, probably to me, Cc'ed to MOTU
<elmo> at least that's how we do main
<azeem> ok. I have to check whether there was a new binary package added first, though (changelog is unconclusive)
<elmo> jdub: ?
<Kamion> does anyone object to passwd's root password question being put back at medium priority? I need it to be there for part of kickstart emulation
<Kamion> it still won't be asked in default installations, only in expert mode
<sladen_> thom: yes, the Eric bloke is on crack.  -centrino is failing to load because of a broken DSDT;  -acpi for probably the same reason;  -smi will work for lots more machines since it's in the BIOS in alot.  It's not the CPU detection in this case, but the machine detection
<fabbione> Kamion: go ahead
<Kamion> and actually even then only if you've preseeded base-config/priority=medium or below
<Kamion> I think
<Mithrandir> Kamion: keyboard selection (at least in the live cd) is on serious crack.  I only get mac-usb-* keyboards if I have an usb keyboard.
<sladen> Kamion: if you're 'emulating kickstart', does that mean that you don't want to setup sudo aswell?
<fabbione> Kamion: go and break the hell! we are still in time to do that :)
<elmo> and OMG pidentd is a 50Mb Virtual process
<Kamion> Mithrandir: can you clarify?
<Kamion> sladen: not sure; I'll probably disable sudo by default if a root password is set
<fabbione> elmo: use oidentd.. afaik is one of the best around (and it supports ipv6)
<Kamion> or not do the "add initial user to /etc/sudoers" thing, anyway
<Mithrandir> Kamion: I'm on an amd64 system with an usb keyboard, booting the live cd.  I get asked about language (norwegian), then keyboard and the choices don't include any norwegian ones.  And they are all called mac-usb-*
<fabbione> pitti: ping
<elmo> fabbione: it's masquerade by default crack scares me
<pitti> fabbione: pong
<fabbione> elmo: nah.. it's ok..
<sladen> Kamion: I suppose it depends whether you are trying to emulate Red Hat, or provide the best /Ubuntu/ system possible
<Kamion> Mithrandir: keyboard types vs. keymap names are very confusing; the actual names of the keymaps are best ignored ...
<Kamion> Mithrandir: I don't know why you aren't seeing the translations though
<Kamion> Mithrandir: what language/country did you select?
<Kamion> (the translations of the keymap names, I mean)
<Kamion>          * It was a mistake to tie "keymaps" to "architectures": all the keymaps
<Kamion>          * in console-keymaps-usb are Mac-specific (at the moment); "PC" USB keyboards
<Kamion>          * all use standard "AT" keymaps. But its too close to sarge release to change design,
<Kamion>          * so we go with the following hack:
<Mithrandir> Kamion: Norwegian
<Kamion> oh, damnit, kbd-chooser tests for i386
<Kamion> it needs to test for amd64 too
<Mithrandir> ok :)
<Mithrandir> care to fix, or do you want a bug?
<Kamion> I'll just fix it
<Mithrandir> thanks
<Kamion> Mithrandir: is __x86_64__ or __amd64__ preferred?
<Mithrandir> C code?  __amd64__, I think.
<Kamion> ok
<elmo> really?
<Mithrandir> I think so, yes.
<Kamion> Mithrandir: 1.09ubuntu4 uploaded; let me know if it works and I'll check it in upstream
<Kamion> my amd64 doesn't have a USB keyboard so it's hard to test
<Mithrandir> Kamion: ack.  Tomorrow's live cd should be ok?
<Kamion> Mithrandir: kbd-chooser's in the initrd, might take 'til Thursday
<thom> sladen: care to say that in the bug ? :-)
<Mithrandir> Kamion: 'k
<sladen> thom: I might miss the bit about crack out
<smurfix> Kamion: DC_NOTIMPL patch to cdebconf: mailed to you.
<sladen> thom: renaming -centrino to -speedstep2 would avoid a couple of these.
<Kamion> smurfix: thanks
<smurfix> Kamion: Don't thank me until you've checked that it works ;-)
<thom> sladen: yeah
<daniels> Kamion: ping
<Kamion> daniels: pong
<seb128>   File "/usr/share/dput/ftp.py", line 59, in upload
<seb128>     if e.args and e.args[0] [:1] =='5':
<seb128> TypeError: unsubscriptable object
* seb128 cries
<seb128> I've to reupload 20M on my 128k upload, nice
<daniels> seb128: mmm :\
<jordi> seb128: heh
<Kamion> this is a much neater patch to shadow than before; I think it must be good, on the elegant==right metric
* daniels kicks i810 really, really, really, really, really, really, really, really, really, really, really, really, really, really, really hard.
<i810> ouch
<daniels> dude, if you want to voluntarily put yourself in as an i810, you'll get a neat torrent of abuse
<daniels> including something involving the words 'Flatley'
<daniels> so, right now, don't :)
<Kamion> heh
<Kamion> I'll have some neat whisky instead, thanks
<daniels> it seems that mode validation is totally shot on i810 because the monitor sync ranges aren't getting propagated from DDC
* daniels frowns.
* Mithrandir kicks glibc
<daniels> (WW) I810(0): Extended BIOS function 0x5f05 failed.
<daniels> (WW) I810(0): Failed to set refresh rate to 52Hz.
<daniels> i think stratus would've been deeply unhappy with 1024x768 anyway
<Mithrandir> Kamion: locales just configures UTF8 locales, it doesn't actually change anything so they are used, right?
<Kamion> Mithrandir: correct
* Mithrandir ponders whether U8MG should do a per-user conversion (which kindof makes most sense, but then it needs to set LANG somewhere in the user's dot files.. or preferably whatever gdm uses when you log in there.)
<Kamion> Mithrandir: that might even be better, kill the /etc/environment brain-damage ...
<Kamion> Mithrandir: you could implement a per-user equivalent of /etc/environment
<Mithrandir> I'm already using ~/.environment for loads of stuff, so that's not a good name, though
<Mithrandir> I need to look at where gdm stores the setting.
<Kamion> I moved that to ~/.bash_environment when I heard ~/.environment being suggested for that purpose
<Mithrandir> if so, it should be ~/.shell_environment as I use it for both bash and zsh
<Mithrandir> but yes, that might be an idea.
<wasabi> I like /etc/environment
<wasabi> I mean, I dislike it... but I like it because some third party programs suck and need env settings. =/
<wasabi> and i can't think of a better way
<Kamion> wasabi: regardless, it's wrong for this purpose because it has to be per-user
<wasabi> Kamion, not specifically. It could be both. It's very nice to be able to deploy, JAVA_HOME, for instance.
<wasabi> For all the PCs in the office.
<Kamion> wasabi: this purpose == UTF-8 migration tool.
<smurfix> Anybody know if elmo'll be back today?
<Kamion> you can't migrate all users at once because migrating to UTF-8 involves recoding filenames etc.
<thom> smurfix: should be
<wasabi> hmm.
<ogra> is anybody else facing a weird font encodig change on amd64 after a while in X ?
* Treenaks suggests /etc/environment.d/ for "global" changes (or is that too evil?)
<Kamion> argh no
<wasabi> gento does env.d
<Kamion> then packages will be tempted to drop things in there
<Kamion> then we have EVIL
<wasabi> Yeah.
<wasabi> Packages shouldn't require env settings. Only admins do. =)
<Kamion> anyway this is http://www.ubuntulinux.org/wiki/UTFEightMigrationTool
<wasabi> Hmmm
<wasabi> I like the idea. Sounds hard to implement. ;)
<wasabi> Also would be a bit concerned about NFS mounted ~.
<Kamion> likewise, but that's why it's not a fully automatic transition; the user gets to say "aargh, no, leave my stuff alone"
<wasabi> The admin needs to be able to say that too.
<wasabi> So he can do it all at once on a network drive.
<wasabi> Or you could just leave ~ alone, and leave the default locale set forever. ;)
<Kamion> the admin could zap the update hook registrations ...
<Kamion> leave ~ alone> that's what'll happen unless you do the migration task
<wasabi> The user will log in. Some dialog will pop up. That dialog needs to be supressable in some fashion. I don't want to confront my users with that.
<Kamion> I think the UI is that an icon appears discreetly on your panel saying "you should probably do this at some point"
<Kamion> not a dialog
<Kamion> anyway this is mvo/Mithrandir's task, not sure why I'm debating it ... :)
<wasabi> Well, whatever. You get my drift? My users would go ape shit with that. I'd be flooded with help desk calls. ;)
<wasabi> Oh. heh.
<Mithrandir> Kamion: I can't get rid of the locale in /etc/environment, actually.  But we could stop installing it if we have /etc/skel/.environment which is created by base-config (or locales?)
<Kamion> yeah, I know, I'd be amazed if there wasn't a way to suppress it though so I'm not that worried :)
<Kamion> Mithrandir: I didn't mean getting rid of the locale there so much as getting rid of the meme that /etc/environment is the place to put all your custom environment variables
<Kamion> it's as bad as autoexec.bat :P
<Mithrandir> Kamion: oh, yeah, I agree.
<wasabi> Hmm. MS fixed autoexec.bat by just leaving it there and making sure nobody NEEDED to use it. ;)
<Kamion> indeed, that's the right answer ...
<wasabi> They provided a UI for setting global env vars haha.
<sivang> pitti: server problems?
<Kamion> erm, yes, well.
<sivang> pitti: (Morning ;-)
<pitti> sivang: I currently experinemt with port forwarding
<sivang> pitti: ah, from where to where?
<wasabi> That sounds like a good GTK project for somebody to do (like me) to get their heads around writting simple gtk utilities.
<sivang> pitti: my session got killed on the server last night, was it experiencing problems?
<pitti> sivang: I replaced my dircproxy on my server with iptables SNAT/DNAT
<sivang> pitti: eh cool
<daniels> bychristfontstakealongtimetobuildevenonadecentmachine
* eruin hugs daniels 
<stratus> daniels, huh?
* Mithrandir kicks gdm in the nuts
<stratus> daniels, wtf with the bios ?
<daniels> stratus: the reason I'm building X right now is to try to track down your problem :P
<pitti> sivang: as I said, I had to reboot due to a kernel upgrade
* stratus hides
<daniels> stratus: unfortunately i8xx desktop chipsets are one of the few things I don't have
<wasabi> Hmm. ~/.environment is going to require modifying pam_env.
<daniels> i'm trying to borrow one for a couple of days, but I think I know where the problem is, and I'm building a debug i810/i830 driver for you now so I can get more information
<sivang> pitti: not a problem, I just wish my irssi would also log the away log, which it didn't to some strange reason.., and logged everything else :)
<Mithrandir> wasabi: correct
<stratus> daniels, i'll lunch now but in a hour i can download your build and test it with you.
<daniels> ok
* daniels goes downstairs to make some espresso.
<stratus> daniels, thanks i'll be back in a hour.
<Kamion> Mithrandir: if you do do ~/.environment, I think it would be worth having a special marker to distinguish it from other random dotfiles people might have by that name
<Mithrandir> Kamion: ~/.pam_environment might be better
<Kamion> yeah
<Mithrandir> I imagine I'm not the first person who has ~/.environment and confusing all those is kinda bad.
<Treenaks> ~/.environment.d !
* Treenaks hides
* Mithrandir twaps Treenaks 
* Mithrandir has possibly fixed the glibc part of multiarch now.
<Mithrandir> I think implementing support for both system-wide conversion by the admin and per-user conversion makes sense.
<Mithrandir> mvo_: how would something like that fit into the hooks?
<mvo_> Mithrandir: the hook script runs as the user. you could asks a question about system-wide stuff and use gksudo in the script
<Mithrandir> mvo_: how would I then mark the user as run for the other users?
<mvo_> Mithrandir: hmmm ... tricky as the hooks are strictly per-user now
<Mithrandir> mvo_: yes, but if a system-wide migration has been performed, it doesn't make sense to do a per-user as well
<Mithrandir> and I think having support for doing it system-wide makes sense.
<mvo_> I agree. a generic solution might be to have a addtion stamp-file/flag that magically marks a hook as completted for all users
<Mithrandir> can you whip something up?  :)
<mvo_> this involes gksudo because it needs to be writen in a update-notifier controlled directoy
<Mithrandir> yeah, but that's ok, since you can't do system-wide stuff without being root
<mvo_> ok, here is a simple one :) what about just moving the hook file into /var/lib/update-notifier/user.d/completed/ once it's no longer usefull (or remove it complettly)? no more magic needed ;)
<Mithrandir> it'll confuse dpkg
<Mithrandir> but I guess that's doable, yes.
<mvo_> anything we can do about dpkg?
<Mithrandir> I can put the file there with the postinst, or let it be a symlink or something
<mvo_> ok. so I need to add a /var/lib/update-notifier/user.d/completed/  directory? or will you just delete the hook afterwards?
<mvo_> do you need additonal support? like calling the script with the name of the hook-file as first argument (so that you always know what hook called the script)
<Mithrandir> nah, it'll ask by itself, I think
<Mithrandir> I don't think I need any extra support
<mvo_> ok, thanks
<daniels> stratus: please grab http://people.ubuntu.com/~daniels/i810_drv.o, put it in /usr/X11R6/lib/modules/drivers/, start xorg with sudo Xorg :1 -ac -logverbose 99999 (and then kill it) and send me /var/log/Xorg.1.log
<Mitario> hi guys
<stratus> daniels, fetching the driver...
<daniels> stratus: cool
<stratus> let's do it.
<stratus> i like all that verbosity, i'll send the output to you now...
<daniels> thanks a heap
<lamont> good morning all
<Mithrandir> lamont: AMD64 daily works mostly.
<fabbione> hey lamont 
<stratus> daniels, mail sent.
<daniels> stratus: rad
<sladen> thom: just looked at the cpuinfo, same as Kinni's desktop box.  No 'est' (enhanced speedstep) flag....
<stratus> daniels, :)
<lamont> Mithrandir: it should - turns out partimage refuses to run there, so it's dropped.
<lamont> Mithrandir: you still get rsync-able images, but they'll continue to grow until we flush them
<Mithrandir> lamont: hm, ok
<Mithrandir> lamont: it sucks in a bunch of places, but not really related to amd64.
<lamont> (partimage is used on i386/ppc to zero out the unused blocks of the livecd rootfs....)
<Mithrandir> ok, so it should work still?
<Mithrandir> that is, it's not a useless test?
<Mithrandir> I burn to DVDs, so size isn't a problem
<lamont> should work still
<stratus> daniels, it's trying to set refresh rate to 52hz and fails, it seems to be using 43hz, but before this set we've
<stratus> daniels, [...]  Not using mode "1024x768" [...] 
<lamont> the amount of growth in the image size is still limited to new blocks, but we don't get to delete all the old blocks.  So your rsync's should be about the same as i386, but we'll need to watch the image and see when we cause you to take a hit and re-download the whole image, just to get it back down to ~525MB of rootfs.
<stratus> daniels, line 1908 (not using mode) and line 2252 (refresh rate to 43hz)
<daniels> the 80mhz pixel clock thing seems weird
<daniels> to debug this further i'll need to give you a new xorg binary
<daniels> but i need to sleep first
<stratus> daniels, np i'll wait for the new xorg let me know.
<daniels> ok, will do, thanks
<stratus> daniels, good sleep it's still 14pm here.
<stratus> s/14/2/
<seb128> grrrrr
<seb128> eds and evo need to be uploaded together, eds need to build first, so there is like 1 hour of unstable situation
<seb128> and some people send bugs during this hour saying that evolution is broken, grrrrr
<seb128> that's a devel branch!!
<opi> hehe
<opi> my Evolution just died
<opi> :)
<opi> crash everytime
<seb128> good one
<seb128> very funny :p
<opi> really
<opi> ;p
<seb128> really ?
<opi> I've cliked a ,,work offline'' and since then all I see is ,,aplication crashed''
<seb128> what version ?
<opi> I was browsing around to look for some kind of lock
<opi> 2.2
<opi> morning update
<opi> I see there's a new one in queue
<opi> I'll apt-get it and raport back
<seb128> 2.2 is not released
<seb128> 2.1.3.2 or 2.1.4 in hoary
<opi> hum
<opi> emil@rude:~ $ ls -l /usr/bin/evolution-2.2
<opi> -rwxr-xr-x  1 root root 168056 2005-01-17 19:16 /usr/bin/evolution-2.2
<lamont> squirrelmail is in main?
* lamont vomits
<opi> haha
<opi> :)
<opi> not on the floor, I've just polished it
<seb128> opi: that's a name, not a version
<opi> seb128, so it should have different name :)
<opi> becuase it's confusing
<opi> wait, I'm dist-upgrading
<seb128> opi: that's stupid to change the name between 2.1 and 2.2
<seb128> opi: the stable release will be 2.2
<lamont> opi: no, it should have the name it will have when it releases
<opi> +'t
<opi> it shouldn't
<seb128> ?
<opi> bah, ignore me for a second :)
<opi> my boss was talking to me
<seb128> :)
<opi> I hope Evolution won't die on me
<lamont> opi: in that case, why are you running hoary? :-)
<opi> who's in charge of Pyton addons
<opi> lamont, I can't snowboard or skydive
<opi> lamont, I need a risky hobby :>
<lamont> opi: so accept that lots of things are in pre-release status, like evo-2.2
<opi> I accept that
<opi> I'm running it, to help you guys develop it
<lamont> so it needs to be called evolution-2.2, so as to not introudce major file-name changes right before release.
<opi> Version: 2.1.4-0ubuntu1 fixed my issue
<crimsun> jdub: I apologize if I'm pinging the wrong person, but why does polypaudio default to module-oss in /etc/polypaudio/default.pa?
<shaya> anyone using the new evolution?
<shaya> it's severely screwed up IMAP
<tseng> it seems to have switched to the new rev1 plugin by default
<shaya> and the old one isn't available
* shaya pokes seb128 
<shaya> build a new evo with the old imap :)
<seb128> don't use hoary if you don't want to use devel branch
<shaya> also doesn't do threading anymore
<seb128> I know
<shaya> also cant find my inbox on a wu imap server
<seb128> that's not cool ...
<opi> ups..
<shaya> works fine for that on a dovcot imap server
* opi runs to check out his IMAP
<shaya> but on the dovecot, seems to only allow one level of directories
<tseng> thats false
<shaya> took out my mail/sent/ directory and mae it sent/
<tseng> i have dovecot
<shaya> I said it works for me on dovecot inbox
<tseng> how do your dirs look in the maildir
<ogra> tseng: why are you not on the CC agenda ? to become a MOTU ?
<shaya> tseng: i'll msg it to you
<tseng> ogra: i didnt apply yet, i said i need to reread the docs a bit
<tseng> shaya: ok
<shaya> it's .mailboxlist for me it seems
<ogra> tseng: heh, since your packages already get uploaded,i think its only some bureocracy thingie
<shaya> actually, it's .subscriptios
<shaya> .subscriptions
<tseng> well, subdirs in maildir need to look like .ubuntu.hoary-changes
<tseng> where hoary-changes is a subdir of ubuntu
<tseng> not like dir1/dir2
<tseng> yes, it shouldnt look like that shaya 
<tseng> .maildir/.folder/{cur,new,tmp}
<tseng> .maildir/.folder.subfolder/{cur,new,tmp}
<tseng> follow?
<shaya> I dont use maildir
<shaya> these are mbox's
<tseng> then what are you using that has folders..
<shaya> just regular file system
<shaya> always used to work before
<tseng> erm.. i had no idea you could have dirs of mboxes
<shaya> always worked before
* tseng shrugs, i cant help you with that then, sorry
<shaya> outlook express, outlook, mozilla mail, thunderbird, evo since 1.0
<tseng> ogra: yeah.. im not as comfortable with the tools and policies as I'd like to be
<tseng> ogra: i definately intend to apply, however.
<ogra> so go on, we need manpower ;)
<pitti> anybody here who could look up something for me on ia64?
<mdz> pitti: look up what?
<pitti> mdz: dpkg -s locales | grep ^Depends:
<elmo> pitti: halley is a porting box
<mdz> pitti: locales is arch: all
<pitti> oh, right
<pitti> Depends: glibc-2.3.2.ds1-20ubuntu3
<pitti>         ^^^
<pitti> this somehow looks very odd
<mdz> it's provided by libcX.Y on each architecture
<mdz> since the package has different names
<pitti> but if that really does depend on a particular glibc version, then it is the very thing I need
<jbailey> pitti: We do this for localesm, etc.
<pitti> mdz: great!
<jbailey> pitti: The better solution would be versioned provides/depends, but ah well. =)
<pitti> mdz: this morning I discussed with Kamion about doing some dynamic dependency generation in debian/rules according to the architecture
<pitti> but with this my job gets much easier :-)
<Kamion> pitti: it's not a good idea to use that!
<Kamion> pitti: that doesn't give you >= dependencies, only exact-version dependencies
<pitti> Kamion: I need to depend on locales >= 2.3.2.ds1-20ubuntu3
<Kamion> pitti: nothing outside the glibc source package should be using those provides AFAIK
<pitti> Kamion: but since locales already depend on a newer glibc, I don't need the libc6 dependency at all any more
<pitti> Kamion: that's what I mean by easy :-)
<Kamion> oh, ok
<Kamion> yeah, that's fine, sorry, just panicked for a second :)
<pitti> thanks, guys, that saved some work :-)
<Kamion> yeah, of course the dynamic dep generation wouldn't have worked for you anyway since language-pack-* are arch: all ...
<Kamion> (d'oh)
<pitti> hmm, right
<pitti> Kamion: in that case I would have needed alternative deps, I guess
<Mithrandir> jbailey: multiarch!
<Mithrandir> root@shonap:/# ls -l /lib/libc-* /lib/ld-linux.so.2
<Mithrandir> ls: /lib/libc-*: No such file or directory
<Mithrandir> lrwxrwxrwx  1 root root 22 Jan 25 18:56 /lib/ld-linux.so.2 -> i386-linux/ld-2.3.2.so
<jbailey> Mithrandir: Is this a declaration of success?
<Mithrandir> jbailey: absolutely.
<jbailey> Sweet. =)
<Mithrandir> root@shonap:/# ls /lib/i386-linux/ | wc -l
<Mithrandir> 41
<jbailey> Now all we need to do is hit LSB  in the head with a board until they accept it. =)
<jbailey> *nice*
<jbailey> How invasive are the patches to the linker?
<Mithrandir> jbailey: makefile changes only ; seven lines added to Makeconfig
<Mithrandir> (including one comment line)
<jbailey> !! Awesome
* T-Bone wonders what it's all about
<Mithrandir> T-Bone: multiarch.
<jbailey> T-Bone: Sane co-existance of multiple architectures on a single drive.
<Mithrandir> T-Bone: http://err.no/debian/amd64-multiarch-3 for a bit more discussion around it
<jbailey> T-Bone: Targetted at crazy people who might want to run i386-linux, ia64-linux, hppa-linux, and i386-freebsd libraries on one box. =)
<T-Bone> jbailey: how would they do that? :)
<Mithrandir> jbailey: a bit bigger changes to the debian build system, but nothing really invasive.
<T-Bone> i mean, i can imagine amd64 & i386, but the 4 of them?
<Mithrandir> T-Bone: ia64 runs hppa and i386 natively.
<T-Bone> doh
<Mithrandir> T-Bone: linux doesn't support hppa yet, but that's just missing kernel support, the cpu supports it
* T-Bone is taught something
<T-Bone> Mithrandir: i thought the mess with ia64 was that i386 code had to be emulated?
* T-Bone has to review his ia64 basis
<jbailey> T-Bone: It's emulated in-processor, but poorly.
<T-Bone> jbailey: ah ok so i'm not mistaken
<jbailey> T-Bone: It can be emulated much better in software, AIUI, but then..  Why would you pay $3k for a chip to have it run ia32 binaries? =)
<T-Bone> jbailey: and it's the same for hppa, right?
<T-Bone> jbailey: to have something to run on it? :^)
* T-Bone ducks
<T-Bone> jbailey: to play Doom3 maybe ? :)
<jbailey> T-Bone: I don't know about hppa speed.  When I asked folks they just shuddered and said "Well, I *spose* it can do that..." =)
<jbailey> T-Bone: I had been asking about having an hppa partition on my ia64 box to test glibc. =)
<Mithrandir> jbailey: according to bdale, it's faster than an hppa, so.. :)
<T-Bone> jbailey: ah ok, so we're both at the same knowledge point. I'm reassured. I thought I missed some /. headline :^)
<jbailey> T-Bone: Nope, nope.  I get all my information from the same channel you do. ;)
<Mithrandir> jbailey: I'm going to get a bunch of other libs up and running tomorrow, also I need to fix up pkg-config, autoconf, maybe some gcc stuff and libtool, then I can work on dpkg, apt and the packaging side of things.
<T-Bone> Mithrandir: heh, I'd like to see that, given the ridiculous perfs of ia64 linux in general
* T-Bone waves back to jbailey from another channel :^)
<T-Bone> now let's pretend lamont has fixed some instability issue on ia64 and download the last daily roll for testing purposes
<Mithrandir> T-Bone: (bdale is CTO Linux at HP); he talked about customers upgrading their PBX-es by ripping out all the HPPA CPU modules and putting ia64 in instead.. the boxes were running HP-UX, though, not linux.
<jbailey> Mithrandir: Nice.  You're not really targetting full mutiarch at Hoary, are you? =)
<T-Bone> s/instability/instalability/
<Mithrandir> jbailey: no, etch and hoary+1.
<jbailey> Mithrandir: Oh good. =)
<T-Bone> Mithrandir: yeah I know bdale.
<Mithrandir> jbailey: it's my master's degree, so.
<jbailey> Mithrandir: So I can deal with the glibc insanity in Debian next year sometime ;)
<T-Bone> Mithrandir: if they're running hpux that's a complete different story
<Mithrandir> jbailey: it's not really insanity, it's a neat and small patch.  (Which I imagine _will_ cause havoc all over the place, but that's a different story ;)
<T-Bone> but i have reasons to believe that the late parisc CPU gens are still doing rather well compared to ia64. And even more when dealing with linux.
<Mithrandir> T-Bone: I don't know ia64 at all, so I'm merely retelling what bdale has told me.
<T-Bone> Mithrandir: hehe. Well, if bdale told you something, it outta be true ;)
<lamont> T-Bone: you're operating under the assumption that I actually have time to _do_ something that's ia64 specific...
<lamont> although I did fetch the install CD last night
<T-Bone> lamont: who said i was *operating* ? :^)
<T-Bone> lamont: i'm mostly executing random instructions :)
<no0tic> from dmesg--> powernow: No PST tables match this cpuid (0x7a0)  I have an Athlon-XP-M 2800+ that was correcly recognized by warty kernel (correct freq & scaling)
<T-Bone> lamont: but if you tell me what i'm supposed to look at to fix the issue I've pointed, i'll gladely use my maintainer-fu to fix it ;)
<lamont> T-Bone: sounded like there were uninstallable packages that ubuntu-desktop depended on... those need to be made installable.. :0)
<T-Bone> ubuntu-base actually, which is even worse
<T-Bone> lamont: sure, how am i supposed to do that? :)
<T-Bone> lamont: i suppose there's some file i outta change in the ISO tree?
<lamont> generally, it's (1) figure out _why_ it's uninstallable, then (2) fix that.
<T-Bone> lamont: in order to fix that kind of issue, is rsyncing the ISO tree enough or do i need something else?
<no0tic> I have to file a bug for this?
<thom> no0tic: yes please
<Kamion> T-Bone: you may find http://people.ubuntu.com/~cjwatson/testing/hoary_probs.html helpful
<Kamion> there's a pile of ia64 issues there for you ...
<Kamion> ubuntu-base seems installable at the moment, though
<lamont> T-Bone: it's frequently because something didn't build, and something else (arch all) depends on it
<T-Bone> Kamion: the problem was:
<T-Bone> "ubuntu-base: Depends: lsb-release but it is not going to be installed"
<mdz> amu: ping?
<mdz> has anyone seen amu today?
<T-Bone> Kamion: as a matter of fact, i'd like to save time: it's counter productive to list a bug, wait for you/lamont to do whatever is need, wait for the ISO to be built, download the new ISO and fail again a few step further. I'd like to skip the "wait [...]  and download" steps, if possible, and perform them locally
<mako> mdz: do you know if sabdfl got any thing done on the newmaintainer stuff?
<amu> mdz: pong
<mdz> mako: he said he had written it, and it was no good, and he rewrote it, something like that
<mdz> amu: reportbug
<mako> mdz: when was that?
<mdz> mako: hmm...last thursday or so?
<mdz> before he left
<amu> mdz: working on it .... 
<mdz> amu: ok, I just saw another Ubuntu bug report go to Debian
<no0tic> for the powernow module issue, the package is powernowd or kernel?
<mdz> no0tic: kernel ('linux' component)
<amu> mdz: *g* 
<no0tic> mdz: thanks
<mdz> amu: this is serious; it is bad for the community
<thom> mdz: um, all the other powernow module problems are against powernowd
<mako> mdz: well, he didn't put anything in the wiki that i can find
<thom> no0tic: tell me the bug # after you file it, please? :-)
<mdz> thom: powernowd decides which module to load, but the driver itself is saying it doesn't support that CPU, no?
<T-Bone> Kamion: anyway I can do that?
<mako> mdz: hopefully there are no process conflicts or too much redundancy of work
<mako> mdz: i'll send him a link
<mdz> mako: ok
<thom> mdz: yeah, but for consistency's sake we've been tracking them all under powernowd for the time being 
<thom> not fussed if they move to the kernel
<mdz> thom: sure, whatever works for you
<haggai> crimsun: do you have the .orig.tar.gz for the rox diff you sent?
<Kamion> T-Bone: you can modify packages and, if necessary, Packages and Packages.gz index files in the ISO image
<crimsun> haggai: in hoary/universe
<crimsun> haggai: oh sorry
<crimsun> haggai: the rox diff needs to be rewored
<T-Bone> Kamion: i'd need to rsync the ISO tree for that, right?
<crimsun> reworked, rather.
<Kamion> T-Bone: when modifying packages, change the md5sum/size/etc. in the Packages files; when modifying Packages files, change their md5sum/size in dists/hoary/Release
<Kamion> T-Bone: loop-mount the ISO
<Kamion> T-Bone: that lsb-release issue is odd, I don't see it here
<haggai> crimsun: ah, thanks
<Kamion> here> in the various reports I mean
<crimsun> haggai: a new diff.gz this evening for rox-filer along with an upstream url for the orig.tar.gz
<T-Bone> Kamion: i'm downloading today's iso, will see what happens.
<no0tic> from lsmod I found powernow_k7 is not used, it's correct this behaviour?
<T-Bone> Kamion: btw, the "built on <oddvernum>" is considered as a feature?
<Kamion> T-Bone: but yeah, I do this sort of thing for testing very regularly, ping me if you need help with the details
<Kamion> T-Bone: it's the version number of the debian-installer source package
<dholbach> hai
<crimsun> haggai: (sorry, my keyboard's eating words: that was supposed to read "I will be sending a new diff.gz ..."
<haggai> crimsun: ok :)
<Kamion> T-Bone: not totally sure whether it's a feature or not; it's certainly handy for tracking problems
<crimsun> haggai: shall I CC: ogra for it?
<Kamion> maybe the wording should simply be changed
<T-Bone> Kamion: yeah, but not that handy to identify several ISOs ;)
<Kamion> T-Bone: sure, it's not the only thing you need
<Kamion> T-Bone: I may be able to figure out a way to embed the ISO build date into the bootloader config
<stratus> Will smartbattery stuff be included in hoary?
<Kamion> T-Bone: I think the wording is a bug but the information that's there now should remain in possibly a slightly different form
<T-Bone> ok
<haggai> crimsun: yes good idea.  Then if I delay it he can remind me :)
<crimsun> haggai: acked.
<ogra> and can look into it for seeing what he has to expect in the future by others ;)
<thom> no0tic: the message you're reporting is from powernow-k7
<no0tic> thom: are you asking?
<thom> no0tic: no, i'm telling you
<thom> that's why it's not in lsmod
<no0tic> thom: #5874
<Kamion> to re-mkisofs an ia64 ISO, it looks to me as if you need to create a boot1 directory alongside the CD tree, put images/cdrom/boot.img from a d-i build tree into boot1/boot/boot.img, and run "mkisofs -r -V 'Ubuntu 5.04 ia64 Bin-1' -o hoary-install-ia64-hacked.iso -no-emul-boot -J -b boot/boot.img -c boot/boot.catalog boot1 new-ia64"
<thom> thanks
<Kamion> I think
<T-Bone> gah
<no0tic> thom: there is in lsmod but it is unused: powernow_k7 8680  0
<Kamion> where the CD tree is new-ia64
<Kamion> constructing ISOs is a pain
<Kamion> at least bootable ones ...
<T-Bone> Kamion: ok,  you've convinced me, I'll do the loopmount way :)
<Kamion> T-Bone: ... this is what you have to do *after* the loopmount thing
<Kamion> there's no way around this
<T-Bone> *UGH*
<thom> no0tic: can you run /usr/share/powernowd/cpufreq-detect.sh and attach the output, also add /proc/cpuinfo 
<Kamion> you have to loop-mount, copy the tree to new-ia64, munge, do the above
<thom> no0tic: thanks
<T-Bone> holly sh*t
<Kamion> unless you want to try to get debian-cd up and running for Ubuntu, which I haven't dared to attempt outside of cdimage.ubuntu.com yet
<T-Bone> heh
<Kamion> you need a local mirror for that
<Kamion> but TBH I'm not sure you'll find it significantly easier, if at all; it's a pile of hacks
<T-Bone> heh
<T-Bone> Kamion: there's no way I can use a netinstall system?
<T-Bone> ie: instead of having to burn an iso, i could just netboot and then use a nfs rep?
<Kamion> oh, sure
<Kamion> well, probably not NFS, but HTTP/FTP will work
<Kamion> (nobody's written an NFS retriever)
<T-Bone> yeah whatever
<Kamion> so, er, do that :) netboot image should be in the archive ...
<T-Bone> because the problem isn't the installer, afaics, so if i could spare the CD-related pain...
<Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-ia64/current/images/netboot/netboot.tar.gz should have everything you need
<Kamion> alternatively, if it's not the installer at all, why not use debootstrap?
<Kamion> on an existing Ubuntu system, 'debootstrap hoary /path/to/new/hoary/chroot'
<T-Bone> Kamion: good point, but i'd rather be able to tell at the end "installation worked fine from A to Z"
<T-Bone> debootstrap doesn't handle system configuration as d-i does
<Kamion> T-Bone: you can do that later - if it's just dependency fixups and things it is much more efficient to use debootstrap during development
<T-Bone> Kamion: besides, it needs an existing ubuntu system, which i don't have yet, given i've ripped my box to test ubuntu ;)
<Kamion> you don't have to do an install from scratch every time, and if you're working effectively you shouldn't
<T-Bone> Kamion: agreed
<Kamion> do you have an existing Debian system?
<T-Bone> Kamion: doh! Dude, don't be so harsh on me :^)
<Kamion> I'm not, just trying to help you avoid the stuff I wasted time on :-)
<Kamion> I used to burn CDs for every test ... *shudder*
<T-Bone> Kamion: i have an existing system on the zx6000 which heats alot and sucks lot of current. I'll try to setup a Debian system on the zx2000 instead :)
<T-Bone> Kamion: lol
<Kamion> ok, you can install Ubuntu's debootstrap.deb on a Debian system harmlessly
<Mithrandir> Kamion: I used to make floppies 
<Kamion> (make sure to pick the hoary version)
<Kamion> Mithrandir: at least they're relatively quick to write ...
<mdz> Kamion: is there a package we could tuck (a fixed version of) update-cd into?
<Kamion> mdz: update-cd?
<mdz> Kamion: that little script I wrote to fix up the checksums and such on the CD after modifying it
<Kamion> oh, there's a script in debian-cd called update-cd too, heh
<mdz> yeah, noticed that the other day
<Kamion> can't think of one offhand ...
<T-Bone> Kamion: for the install archive, i can use stuff on the ISO as the repo served by apache?
<Kamion> T-Bone: not quite, I don't think everything that netboot needs is there
<Kamion> (there's a bug about that - we remove the netboot stuff to save space)
* T-Bone is getting weird throughput from cdimage.u.c, constantly giggling between 150 and 230ko/s
<Kamion> you can try though, I've never tested that on ia64
<T-Bone> s/ko/kB/, for you english speakers ;)
<T-Bone> Kamion: but if i complete with the tarball you pointed me at?
<mdz> Kamion: when I was doing busybox init test cycles, I set up a grub entry on my laptop to boot an initrd from disk, and used that with the CD-ROM
<mdz> so I could quickly modify the initrd and test, without writing a new CD
<Kamion> T-Bone: it'll be extra udebs you need, not stuff from that tarball
<mdz> even better would have been a grub stanza to netboot, but for some reason the grub package doesn't have networking enabled
<Kamion> mdz: yes, that's what I do on powerpc often
<T-Bone> Kamion: k. Any easy way to fetch these?
<mdz> Kamion: do you know if there's any reason why networking isn't enabled in grub?
<Kamion> T-Bone: try first to see if it works
<Kamion> T-Bone: otherwise debmirror
<Kamion> unfortunately our netboot sucks, it always goes to archive.ubuntu.com unless you fiddle about in expert mode
<T-Bone> debmirror? *G*, I hope i don't have to mirror everything, i'll have disk space issues otherwise :P
<Kamion> mdz: no ... I didn't know it had networking support
<Kamion> T-Bone: main/debian-installer is not a large component, you don't need to re-mirror all the debs, just grab a few more udebs
<mdz> Kamion: it's way cool, you can say things like kernel (nd)/vmlinuz; initrd (nd)/initrd.img and it will load them via tftp
<T-Bone> Kamion: ok
<Kamion> oh, tftp, right
<Kamion> I don't know, maybe size issues or something?
* T-Bone tries to remember how to netboot an ia64 box, hasn't done that in quite a while
<mdz> I guess it would make stage2 bigger, but stage2 isn't small anyway
<ogra> is stuart bishop around by chance ?
<Kamion> ogra: he's 'stub', not on channel
<ogra> Kamion: thanks....
<dholbach> has anybody problems with evolution on AMD64? to be precise: "floating point exception"
<ogra> nope
<ogra> i got lots ofg others here, but evo is fine for me
<dholbach> ogra you have the newest available?
<ogra> oh, 35 updates....
<ogra> since it works for me and there are only libs to update for evo, i would suspect one of these
* dholbach too
<dholbach> i had a floating point exception for gnome-launch-box (which depends on e-d-s too) the other day
<ogra> i still have that one
<dholbach> ogra: hm?
<ogra> gnome-launch-box
<ogra> floatingpoint error.....
<dholbach> well, there was only one release yet
<Nafallo> I got no answer in #ubuntu, so this question might be better asked here :-).
<Nafallo> can someone explain why fluxbox is missing menuitems?
<ogra> dholbach: did you have any strange keyboard behavior or broken encoding recently ?
<dholbach> ogra: the imendio guys said it worked nice on their amd64, they reckon it's because of gcc3.3 *shrug*
<dholbach> ogra: strange encodings: not more than in the last months
<dholbach> ogra: strange encodings: not more than in the last months already
<ogra> killall metacity ==  
<ogra> it suddenly appeared out of the blue ....
<dholbach> ogra: metacity in 2.9.5-0ubuntu1 behaved quite strange... 2.9.8-0ubuntu1 fixed it
<ogra> i mean the encoding, not the command :-P
<lamont> pitti: you around?
<ogra> the right part is what i see.... the left what i type...
<pitti> lamont: yep
<dholbach> ogra: metacity seems to save itself from being wiped out :-p
<dholbach> ogra: sorry... don't know what could cause this at all
<ogra> dholbach: i suspect either xkb or the kernel, since i also have some weird key repetition probs 
<dholbach> ogra: we seem to be the only ones having bugged computers :-)
<ogra> maybe the arch.....
* dholbach suspects Murphy :-)
<ogra> YOUR DOG ??
<mdz> ogra: sounds like meta was stuck on?
<dholbach> ogra: :-)
<Nafallo> ogra: I have got no problems except that metacitybug some day ago :-P.
<ogra> mdz: i wouldnt know how to switch it on or of 
<ogra> mdz: i.e. meta has no lock function on my keyboard afaik
<ogra> Nafallo: amd64 ?
<Nafallo> ogra: indeed
* ogra also sees weird dmesg entrys from his synaptics touchpad....
<ogra> and i really start to suspect xorg....
<Nafallo> ogra: I haven't got any :-P
<ogra> lspci also shows a whole lot of unknown devices.... probably this machine is simply to new...
<ogra> (2 weeks old)
<ogra> mdz: btw, is there a chance to get the new nediswrapper into amd64 for hoary ?
<thom> it's in, isn't it?
<ogra> oh, already ?
<ogra> wow, thom is right
* ogra starts to fiddle with his built in wlan card
<mdz> what is the point?  there's no ndiswrapper kernel module for amd64
<ogra> /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
<ogra> :-D
<mdz> from which package?
<thom> mdz: lrm
<thom> daniel added it last week iirc
<mdz> thom: weird, why?
<mdz> on i386, it's built by linux-source
<ogra> ndiswrapper-modules-2.6.10-2-amd64-k8: /lib/modules/2.6.10-2-amd64-k8/misc/ndiswrapper.ko
<ogra> hmm
<mdz> ndiswrapper-modules? that's something you built yourself
<ogra> looking
<ogra> argh, yes
<mdz> my word
<mdz> lrm is bigger than the kernel
<thom> hrm, i thought i saw it go past in the changelogs
<mdz> mizar:[/tmp]  apt-cache showsrc linux-source-2.6.10 linux-restricted-modules-2.6.10 | grep orig
<mdz>  063a64fc0efd9c9901cf07effef1b747 46244465 linux-source-2.6.10_2.6.10.orig.tar.gz
<mdz>  71eda5caf8a927676e3ee573e2b0801e 46930820 linux-restricted-modules-2.6.10_2.6.10.3.orig.tar.gz
<thom> yeesh
<Kamion> nvidia rpms IIRC
<ogra> isdn....avm drivers ?
<Kamion> anaconda is giving me flashbacks to boot-floppies
<azeem> the source?
<Kamion> azeem: yes
<azeem> I thought it was mostly in python?
<Kamion> the early stuff is in C
<Kamion> and is really horrible
<wasabi> Is there a push for getting Mono in main?
<thom> not for hoary
<wasabi> k
<thom> it's been in and been removed again
<mdz> there's nothing which provides motivation for enduring the pain that is mono
<wasabi> Beagle.
<wasabi> Basically what Im fighting now.
<Kamion> not in hoary
<wasabi> Missing dbus-cil
<wasabi> Yeah.
<Kamion> beagle will likely be the motivation for hoary+1
* ogra thinks he heard jdub mumble about universe (if its ready) once....
<whiprush> there's a link to sid .debs for dbus-cil in bugs.d.o
<dholbach> maybe fate is giving a broad hint... evolution, streamtuner and mozilla-thunderbird don't work, maybe i'd better get working again :-)
<Mithrandir> dholbach: how have you broken m-t?
<ogra> Mithrandir: he installed it
<dholbach> Mithrandir: just installed it (and the proposed plugins), then i selected "don't import anything" (since there was no alternative)) and it mysteriously broke off, then i started it again from the console and saw it tried to "Registering Enigmail account manager extension." over and over again
<Mithrandir> dholbach: uhm
<Mithrandir> dholbach: $arch?
<dholbach> amd64
<dholbach>  ***** Registering: Clean Compreg! ****    -      Registering Enigmail account manager extension.    -     Enigmail account manager extension registered.     -       observe:      -     nothing here: null      -      observe called       -      FILE: [xpconnect wrapped nsIFile] *** loading the extensions datasource
<dholbach> over and over again :-)
<Mithrandir> dholbach: weird, worksforme
<ogra> Mithrandir: did you see some weird key repitition probs on amd64 in X or the encoding switching out of the blue ? 
<thom> wasabi: dbus-mono is in universe i believe
<thom> providing libdbus-cil
<wasabi> gmmmm
<wasabi> I thought apt-get install was supposed to find provides
<wasabi> nope, not in universe
<Mithrandir> ogra: I ran it through ssh, so no
<ogra> hmm...
<ogra> k
<mdz> pitti: here?
<pitti> mdz: yes
<dholbach> Mithrandir: here's what it says in the end: DOUBLE-CLICK: 400 --> -1 THRESHOLD: 8 --> -1 Fontconfig error: Cannot load default config file
<dholbach> /usr/lib/mozilla-thunderbird/run-mozilla.sh: line 159: 20852 Segmentation fault  "$prog" ${1+"$@"}
<mdz> pitti: I was just thinking that we may have a problem with the language pack / -update arrangement
<Mithrandir> dholbach: so it's probably related to some fontconfig problems you have
<mdz> pitti: I think we will run into the dpkg bug where it doesn't handle replaces properly if the unpack order is different
<mdz> since we are not removing the files from the replaced package
<dholbach> Mithrandir: there are none i'm aware of... hmmmm
<pitti> mdz: why should we remove them? they are just replaced by newer versions
<mdz> pitti: we shouldn't remove them
<mdz> pitti: I am saying that we will encounter this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=164595
<mdz> pitti: and probably we need to fix that bug before language packs can be considered releasable
<pitti> mdz: hm, thanks for the pointer
<pitti> mdz: I try to reproduce it
<mdz> pitti: perhaps talk to Keybuk about it when he returns
<pitti> yes, will do
<Kamion> fixing that bug would be a Really Good Thing anyway
<dholbach> Mithrandir: /usr/lib/mozilla-thunderburd/run-mozilla.sh says: MOZ_PROGRAM=""  which seems to be the problem
<Kamion> I wonder if anyone's reviewed the patch in #184635
<pitti> mdz: ah, now I understand
<pitti> mdz: that means if I install an update pack the second time, I will get errors because the replaced files are not owned any more by the base package?
* pitti tries that
<mdz> pitti: if you unpack a new language-pack and language-pack-update, and language-pack-update is unpacked first, it will fail
<mdz> (assuming language-pack-update replaces some files)
<pitti> mdz: hmm, the update package should always be unpacked first, because the base package conflicts to older versions
<Mithrandir> dholbach: same here, no problem
<Kamion> night all
<pitti> Night Kamion!
* Mithrandir waves to Kamion 
<ogra> night
<pitti> mdz: okay, I can reproduce the problem
<amu> mdz: bug confirmed, it's very strange, reportbug say all time, bug report will be send to ubuntu, it goes finally to debian  
<dholbach> amu: my reportbug tells me it'd be sent to debian (at least for universe stuff)
<amu> dholbach: warty or hoary? 
<mdz> amu: as I said in the bug, all of the patches are in merge-o-matic
<mdz> amu: you just need to apply the diff which was already there
<tritium> from now on I'll stick to attaching patches rather than pasting in bugzilla.  The newlines only confuse.
<mdz> amu: did you do that already?
<dholbach> amu: hoary
<amu> mdz: patching it, isnt the problem, i try to understand why the problem comes, since i merged the package.  
<amu> dholbach: hmm on my hoary it says: Will send report to Ubuntu (per lsb_release)
<mdz> amu: the old version contained a patch which set the default bts to 'ubuntu'
<mdz> amu: you dropped that patch
<amu> mdz: i set the default to ubuntu, it still sends to debian
<amu> mdz: ok, as i understood it's urgend, so i'll just apply the patches and recheck it
<mdz> amu: I don't know what you tried, but setting 'bts ubuntu' in reportbug.conf (i.e., restoring the dropped patch) does exactly what I expect (reports the bug to Ubuntu)
<mdz> I just tested it to be sure
<mdz> amu: I also tried it without that, using the autodetection, and that works too
<mdz> amu: but ubuntu should be the default as a safeguard
<ogra> while you are at it.... is there any chance that we can collect the OTU bugs anywhere else (additional) then the mailing list....?
<mdz> because clearly there are some cases where it does not work correctly
<ogra> MOTU even
<mdz> ogra: that is up to you and haggai to decide
<ogra> ok...great :)
<amu> mdz: ok, testing it now
<Nafallo> ogra: stealing malone, are you? ;-)
<mdz> ogra: I talked to haggai and bradb about malone
<mdz> ogra: you can review with them, but it seems that the consensus is that malone is not ready
<ogra> is malone ready yet ?
<mdz> ogra: so you must decide whether you can wait, or if you need something immediately
<ogra> thats what i thought
<ogra> it would be essential to have _something_ to stabilize for hoary at least and the mailing list is a pita to search all the bugreports in 19245 mails i got in there currently...
<ogra> is it likely that malone gets stable enough before hoary preview ?
<ogra> bradb ? ^^
<bradb> ogra: We (kiko, mpt and I) intend to have something usable for distro by mid next-week.
<bradb> They're on their way to Montreal as we speak.
<ogra> hmm, sounds enough to me....
<ogra> bradb so lets talk then again....
<bradb> ogra: sure, sounds good
* ogra would love to find some MOTU with python package love....there is still a lot to rebuild it seems...
<sivang> ogra: we should get gazpacho in universe also...
<sivang> IIRC It's was not auto synced from debian
<crimsun> ogra: I'll just email you diff.gzs against what's currently in universe ;)
<ogra> sivang: look in the build logs if it ftbfs.... if not, trigger elmo for a sync....
<sivang> ogra: yes, I should, do you where they are?
<ogra> crimsun: thanks :)
<sivang> lamont something? ;-)
<crimsun> sivang: yes, under his dir on people.u.c
<sivang> crimsun: ok, looking
<ogra> https://www.ubuntulinux.org/wiki/BuildDaemons
<mdz> ogra: they need more than rebuilds
<ogra> sivang: if you plan to go for MOTU, you should also see the other pages listed here https://www.ubuntulinux.org/wiki/MOTURecruitment
<ogra> mdz: as i understand it, mostly a build dep or a dep change against python2.4 is enough...
<sivang> bad, all links in lamont's wiki page for the builddaemons are broken..
<sivang> ogra: where I can see recent build logs?
<ogra> assuming 2.4 is downwards compatible....
<rcaskey_> what kind of hardware does the i386 buildd run on
<ogra> sivang: http://people.ubuntu.com/~lamont/buildLogs/
<mdz> ogra: for native module packages, you need to add a new python2.4-foo package and arrange for it to be built with the new version of python
<ogra> sivang: most recent: http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<mdz> ogra: for python programs, sometimes it is enough to test with the new python and update a dependency
<mdz> at any rate, source changes are required :-)
<ogra> mdz: and thats the majority i guess...since most modules pkgs are in main anyway
<mdz> ogra: will you remove support for 2.2 and 2.1 where it has not been done already?
<mdz> I think doko has done many of them already
<ogra> in universe ?
<mdz> yes
<ogra> i didnt know he also cares for that...
<mdz> ogra: in general, if a change in main breaks many things in universe, we try to help with it
<sivang> ogra: well, the talked package I was thinking about (gazpacho) is not there, where could it be elsewhere found?
<mdz> but with a strong MOTU team, you guys can handle those things
<bradb> ogra: sorry, one quick note: when i said "distro" by the way, i meant "universe" not that main can just drop Bugzilla.
<ogra> mdz: currently the team is 4 ppl :/
<bradb> ogra: but yeah, i get the impression that you're a MOTU, so you should be among the intended early adopters of distro Malone
<ogra> bradb: great, thats exactly what i want as a MOTU
<ogra> mdz: ... which i wouldnt consider ...strong....
<shaya> hmm
<shaya> ubuntu install kills vmware beta
* shaya tries again
<rcaskey_> what is Malone?
<ogra> mdz: and we all have other (big) tasks....
<ogra> rcaskey_: https://launchpad.ubuntu.com/malone
<rcaskey_> ahh
* ogra wonders about creating some advertisements for MOTU :)
<rcaskey_> universe has been very good to me, the only real issue is that I really needed to scrap esd in favory of polypaudio
<rcaskey_> but that directly relates to base
<ogra> rcaskey_: whats your favorite package from universe ?
<rcaskey_> wesnoth ;)
<ajmitch> ogra: heh, I've got some packages for you for universe ;)
<ogra> rcaskey_: like to adopt it andbecome a MOTU ?
<mdz> elmo: is python2.2 able to move into universe now?
<mdz> ogra: that's why we need to grow the team :-)
<ajmitch> ogra: the python programs mdz was talking about
<rcaskey_> maybe, we will see, I'm still trying to find someone to sign my key ;)
<ogra> mdz: thats hat i'm trying ;)
<ogra> what even
<ajmitch> ogra: I've started rebuilding some of the packages
<crimsun> rcaskey_: I've already converted two hoary machines to polypaudio this afternoon.
<rcaskey_> crimsun: was there ever a final decision on what was to be odne about that
<rcaskey_> the BOF notes weren't very complete i'm afraid
<crimsun> rcaskey_: not afaik. I've pinged jdub RE: polypaudio, but I believe he was/is asleep.
<mdz> rcaskey_: www.biglumber.com
<crimsun> rcaskey_: if the plan is to transition to polypaudio as transparently as possible, we can keep gst using esdsource and esdsink and just use the default polypaudio setup
* ajmitch waits for ogra..
<ogra> ajmitch: send me a pointer where i can review them .... hostmaster@grawert.net
<mdz> rcaskey_: polypaudio is likely to happen for Hoary, but it isn't ready yet
<ajmitch> ogra: sure, each package needs modified, so it takes a little while..
<ajmitch> grep-dctrl showed 155 of them at last count
<crimsun> mdz: out of curiosity, what's keeping it in universe?
<ogra> ajmitch: go on... we still have about 2 months.....
<mdz> crimsun: nothing in main depends on it
<rcaskey_> mdz: GA is very short on oSS types it sees
<rcaskey_> the Debian devel map was very sparse  (yes I know Ubuntu is not Debian but...)
<crimsun> mdz: hmm, ok. It is literally a drop-in replacement.
<ajmitch> ogra: usually there'll be a new binary package built, so debian/control, rules, and install files generally need changed for each
<mdz> rcaskey_: biglumber finds 16
<ogra> ajmitch: i know.... jst put the source pkgs online anywhere, point me to them and i'll upload them if i consider them ok...
* lamont goes to update his wiki page
<mdz> crimsun: I accept jdub's assessment that it is not time to switch everything over yet
<crimsun> mdz: ok.
<crimsun> mdz: oh, and regarding the earlier question whether my key is in the strong set, the answer is "yes"
<crimsun> mdz: not many signatures at all, but 'yes'
<mdz> crimsun: a link into the strongly connected set should be sufficient
<ajmitch> mine ought to be in the strong set now
<crimsun> ok, I'll try to make it to our next meeting and have our steering committee sign 
<rcaskey_> I don't suppose the notary public signs ;)
<sivang> mdz: what is the "strong" set?
<crimsun> sivang: http://www.dtype.org/keyanalyze/explanation.php
<ogra> sivang: everything valid/trustworthy you find at the keyservers
<crimsun> my lug is the largest on biglumber.
<seb128> lamont: could you kick nautilus with eel2 2.9.90-0ubuntu3 ?
<lamont> seb128: kicked, I thikn
<seb128> thanks
<lamont> seb128: btw, ximian-connector is ftbfs: non-PIC (libexchange.a) in shared object. :-(
<ajmitch> ogra: placing stuff on webserver now
<ogra> ajmitch: fine :)
<jdub> GOOD MORNING FREEDOM LOVERS!
<jdub> happy australia day! :)
<pitti> Hi jdub!
<ajmitch> uh oh
<ajmitch> hi jdub 
<ogra> morning....jdub
<opi> hi jdub :)
<opi> morning, hehe, I'm going to bed now :}
<lamont> creating libnautilus-private.la
<thom> jdub: happy colony day
<lamont> /bin/sed: can't read /usr/lib/libgnome-menu.la: No such file or directory
<lamont> seb128: ^^^
<crimsun> moin jdub :)
<jdub> opi: waking australians is always a good alarm clock ;)
<jdub> thom: haw haw ;)
<ajmitch> unfortunately our national holiday falls on a weekend this year :)
<seb128> lamont: it has picked 0ubuntu2 again, I said 0ubuntu3 :p
<lamont> seb128: lol
<lamont> I'll wait a little bit then
<seb128> ok
<seb128> or just put a dep-wait ?
* jdub updates to see what the seb128 damage is like this morning ;)
<opi> jdub: <kid voice>you'll beeeeeee sorrry</kid voice> :)
<seb128> jdub: I'm not happy with ximian guys again, they release crappy versions every time, out of this should be fine :p
<crimsun> gotta run out, see you guys.
<ogra> ciao crimsun...and congrats ....
<ogra> :)
<opi> g'night all
<lamont> seb128: depwaited this time :-P
<ogra> OMG..... backports has xorg now ????
<ajmitch> oh dear
<lifeless> hhhaaaa
<ogra> poor users
<ajmitch> guaranteed to break everyones' systems on upgrade to hoary?
<seb128> lamont: thanks :) BTW how the depwait works ? It looks for the deps every ... ?
<lamont> seb128: the packages are 'dep-wait libeel2 (>> ...0ubuntu2)'
<lamont> once a libeel2-dev  (actually) newer than that (>>) is in the archive, the package will automagically transition to needs-build
<lamont> so it'll actually be triggerd by the needed package entering the archive.  If the build still fails, then the chroot is polluted, and I have more work to do.
<seb128> lamont: but how does it notice the new package ? inotify ? :)
<seb128> after each mirror update all the dep-wait are reconsidered ?
<jdub> Setting up openoffice.org2-debian-files (1.9.64-0ubuntu2) ...
<jdub> /var/lib/dpkg/info/openoffice.org2-debian-files.postinst: line 7: /usr/share/openoffice.org-debian-files2/install-hook: No such file or directory
<ogra> ajmitch: pretty likely yes...
<ajmitch> ogra: 3 done, on http://ajmitch.dhis.org/debuild/ubuntu/python/
<tritium> jdub, I posted a patch to fix that
<ajmitch> well, the 3rd one will be there soon :)
<ajmitch> just grab the .dsc & .diff.gz, I think
<ajmitch> hmm, I should make sure I only copy over the ubuntu-versioned ones
<tritium> jdub, please see bug #5853.  I think my patch is correct.
* thom gives up on netapplet for the night
<jdub> thom: nooooooo!
* Mithrandir gives thom a beer
<ajmitch> python-ctypes done as well
<lamont> seb128: as part of the mirror update, after new packages are installed, all the dep-waits are visited
<seb128> ok, nice
<ogra> ajmitch: -XubuntuX versions apply only if you made ubuntu specific changes to the package....
<ajmitch> ogra: since python2.4 isn't default in debian, I made them ubuntu-versioned
<ogra> ajmitch: ok
<jdub> so dtrace has been released
<ogra> ajmitch: just wanted to point it out, since i made this mistake ;)
<jdub> the tarball is dtrace.tar.gz
<jdub> no version
<jdub> and the tarball is insane
<jdub> usr/src/cmd/dtrace/
<jdub> etc.
<ajmitch> how evil
<ogra> jdub: eternal version ;)
<jdub> well, they have been talking about it like it's perfect ;)
<ajmitch> looks like it was made for some 80s UNIX system ;)
<dholbach> wow this is not friendly:  http://bugs.debian.org/292214  :-/
<ajmitch> not unexpected :)
* dholbach surely didnt expect this
<tritium> jdub, did that fix work for you?
<ogra> dholbach: i warned you ;)
<dholbach> ogra: i blame reportbug for it :-)
<ogra> dholbach: it was a bug in reportbug....
<ogra> dholbach: already fixed ;)
<dholbach> ogra: i'll tell ari about
<ajmitch> I should really try & build on a faster computer :)
<ajmitch> either that or make a cup of coffee for each build I do..
<dholbach> ajmitch: i could do with a fresh cup myself :-)
<tritium> seb128, looks like evo-exchange can't authenticate OWA https:// urls
<tritium> but, at least it's no longer contacting localhost instead of my exchange server
<jbarroso_> hi people, I'm now on Ubuntu Hoary .... when I finish to move a window and I pup up mouse button, all my screen is redraw slowly. I'm using nvidia drivers from ubuntu repository
<ogra> doko ?
<kent> the bookmark-section of the Places menu in the panel seems to have issues with folders with spaces in it. For example, i added "/home/kent/Musik film och liknande" to the gtk-filechooser-widget as a bookmark. But when i try to open that with the Places menu, i get this message: http://leviatan.kicks-ass.org/dumps/places-bookmarks.png
<jbarroso_> when I click on title-bar of a window, screen is redraw slowly too ....
<jbarroso_> do you know about it ?
<seb128> kent: what version of gnome-panel ?
<kent> seb128, 2.9.4 (going to bugzilla in a few seconds.)
<seb128> kent: fixed in 2.9.90, update
<kent> seb128, oh. thanks. i wont bugger bugzilla then :)
* lamont goes to fetch kids
<ajmitch> ok, so python2.2 is segfaulting trying to build this package, which is a little worrying 
<sivang> seb128: I have modified bits of the g-s-t pkg to allow a default profiledb to be installed with the package, it's failing on the "05_no_ubuntu_warning" patch, any idea? (I didn't change stuff wrt to that)
<ogra> argh .....
<seb128> sivang: nop
<seb128> sivang: what have you changed ?
<ogra> whats wrong with http://cdimage.ubuntu.com/ ????? !!!!!
<ogra> elmo ^^^^^^^^^ !
<mdz> whoa, that's a lot of punctuation there
<mdz> it looks perfectly fine to me
<dholbach> ogra: to me too
<ogra> www.grawert.net/cdimage.png
<sivang> seb128: first, I changed stuff in in file.pl.in, to split to storage of configuration files xml from the other cache and debug data.
<kent> hmm,  bugzilla.ubunto wont send me my password (yep, forgot it). I did a search on bugzilla and found no bug on hoary gaim that when i kill gnome-panel it also kills gaim and gaim will not respawn. Seems lika gaims plugin for notific.area is buggy or something.
<dholbach> ogra: well yes, that looks somehow wrong :-)
<sivang> seb128: then I added 2 lines to the rules file, to create /etc/g-s-t and to install the config data there.
<seb128> kent: yep, there is no bug open for that
<ogra> http://cdimage.ubuntu.com/daily-live/current/: The requested URL /daily-live/current/ was not found on this server.
<kent> seb128, will wait for bugzilla to send me my password. not sure where that mail went, and i cant get it to send it again.  its probably just taking a few min.
<seb128> ok
<Kamion> looks like it's broken on mirnyy, which is one of the two hosts that cdimage now round-robins to
<ogra> ah...that explains it
<Kamion> mirnyy's new in that round-robin, I guess elmo's still fixing it up
* ogra was already doubting his sanity
<ogra> could someone change the topic in #ubuntu ? i think the metacity warning is obsolete
<ogra> opi: morning ;)
<opi> ogra: gaaa. I can not sleep.
<opi> ogra: I've been flamed once again by gf, because instead of rest I'm doing some Wiki work at ubuntulinux.org ;)
* ogra is happy that his GF supports everything he does ....
<opi> mine supports me too
<opi> but she don't see me often nowdays, even in we live in same flat ;)
<mdz> ogra: you can't change it?
<ogra> mdz: i cant give me op status....
<Kamion> you don't need operator privileges to change the topic unless the +t channel mode is set
<ogra> opi: mine neither, but she knows everything i do is right ;)
<opi> how do I make intend in moinmoin? :)
<ogra>  #ubuntu :You need to be a channel operator to do that
<ogra> :(
<Kamion> ... evidently somebody set +t then, ok
<thom> #3091 is such crack
<nakeee> I have a glibc bug I'm trying to get people to apply a patch to for almost year and a half now if not more
<nakeee> the guy who wrote the patch tried the glibc bugzilla/mailing list
<nakeee> I tried debian bugzilla and I htink the maintainer didn't understand what the bug is
<thom> nakeee: #debian-glibc might be more interested; or ping jbailey
<azeem> there's no 'debian bugzilla'
<nakeee> azeem: debian bug system:)
* nakeee is too used to projects having bugzilla:)
<doko> ogra: pong
<nakeee> no I move to ubuntu so if the patch would get there it's good enough for me:) jbailey is ubuntu's glibc person?
<nakeee> now
<azeem> nakeee: what's the bug number?
#ubuntu-devel 2005-02-06
<ogra> doko ... see my /msg ?
<nakeee> 288948
<mdz> nakeee: if others have reasons not to apply the patch, it's likely that the same reasons will apply to ubuntu.  What did glibc upstrseam say?
<nakeee> it got merged with 180065 for a reason I can't grasp
<nakeee> mdz: nothign whatsoever:)the debian guy was the only one answering
<nakeee> and I don't think he understood what the patch suppose to do (probebly my bad report)
<jdub> mdz: will ubuntu-meta include an ubuntu-live package for the live seed, or will we handle that differently?
<mdz> jdub: if lamont's script uses the metapackages, we'll probably do that
<mdz> if it uses Task:, I see no reason to make a metapackage
<jdub> ok, thanks
<mdz> speaking of which
<mdz> Kamion: are you at all interested in using the metapackages in base-config, instead of Task: ?
<mdz> I think it might help with that long delay while aptitude gets itself together
<nakeee> azeem: found anything intresting?
<smurfix> nakeee: off-hand I'd say that that problem should be handled in the kernel.
<smurfix> To be more exact: If the data structures returned by the kernel contain garbage, the first step is to determine what exactly the correct contents should be, and then fix everything that doesn't conform. This doesn't seem to be happening here.
<nakeee> smurfix: I'm not sure, it seems to be glibc which is assuming things 
<nakeee> which are not written in the specs
<zul> hey
<smurfix> I don't doubt that your analysis is basically correct, but it looks like you're not fixing the underlying problem. I may be wrong -- don't have time to do a more detailed analysis. :-(
* jdub covers his eyes in thom's direction
<smurfix> nakeee: I do agree that there's a problem, readdir() running into an endless loop *cant be correct. :-/
<jdub> thom: browser war insanity ;)
<ogra> hehe....
<thom> jdub: yeah, i know
* ogra thinks php4-imap could bring us a new MOTU candidate.....
<thom> i really shouldn't have replied at all; but i couldn't resist the chance to slap firefux and galeon in one sentence
<nakeee> smurfix: it's almost as bad as the fact the talk between kernel developers seem to get into endless loop leaving the bug as a 2 years old zombie:)
<smurfix> nakeee: Has there been discussion of this on LKML?
<jdub> thom: it was surprisingly frank ;)
<thom> i am tired and my brain hurts from rmlC
<nakeee> [01:15]  <jbailey> Ah, that's the bug that Linus and Drepper can't agree who's problem it is.
<nakeee> I'm not sure but I guess jbailey knows what he is talking about:)
<pitti> night everybody
<ogra> nacht pitti
<dholbach> i'm off to bed too
<dholbach> sleep tight guys
<thom> guten nacht
<dholbach> :-)
<wasabi> hmm. how does one delete a wiki page?
<thom> (this is me attempting to make it bed before midnight)
<nakeee> btw I was looking at the language packs
<nakeee> which is an amazing idea btw
<nakeee> but I think it should be seperated into enabled and localized
<nakeee> it seems to be a very wanted feature
<nakeee> some people get along better with english interface but want spellers and the like in their mother touge
<nakeee> and some want everything including menus to be in it
<nakeee> it should be fairly easy to do I think
<elmo> cdimage.ubuntu.com is fixed
<elmo> mdz: it wasn't, last I checked (this morning)
<mdz> elmo: I looked through the list of rdepends in the latest germinate output, and the ones I checked seemed to have had their deps fixed already
<elmo> rerunning cron.sync now
<elmo> python2.2-dev                             | python2.2                       | python-pyxattr (Build-Depend)            | Matthias Klose <doko@debian.org>                                          |         1124228 |            3296
<elmo> seems to be the remaining offender
<mdz> ah, ok
<mdz> I guess doko is nearly finished
<sivang> seb128: bad netowrk?
<seb128> no, crashed my box by following a bug in bugzilla
* mdz uploads python-pyxattr
<seb128> doh
<seb128> #5887 
<seb128> this umount just hang the box
<sivang> seb128: hehe, anyway want to continue in gst?
<seb128> not really, I feel like sleeping right now
<seb128> if you have a quick question go for it
<sivang> seb128: hrm, is there anything I need to do for my changes not to break the ubuntu_warning patch? :)
<seb128> not change the file patched by it in the same area ?
<seb128> btw time to sleep
<seb128> night
* daniels frowns.
<daniels> i've only been asleep a few hours, and I have a hojillion messages.
<daniels> obviously email does not respect public holidays
<bob2> T~d26012005;D
<ajmitch> gar I hate udev
<ajmitch> the system is only booting when I add in an strace around udevstart in the init script
<ajmitch> playing with selinux here..
<tseng> ajmitch: do you have the latest kernel image?
<ajmitch> tseng: yep
<tseng> just added tmpfs security labels
<ajmitch> this was doing it with the previous one
<tseng> needed for udev i believe.
<tseng> heh.
<ajmitch> yeah, that's because i asked for it ;)
<ajmitch> this isn't a problem with the labelling, but with other stuff
* ajmitch waits for dhcp to timeout
<jdub> http://bugzilla.ubuntu.com/show_bug.cgi?id=5889
<jdub> heh
<tritium> that's the famous blue model
<zul> heh...she is apart of the blue man group
<tritium> heh
<bob2> anyone else noticed ipw2100 in 2.6.10-10 is incapable of showing useful signal strength levels?
<ajmitch> excellent.. uid=0(root) gid=0(root) groups=0(root) context=ajmitch:sysadm_r:sysadm_t
<stackpopper> First of all I'd like to apologise for asking in here, however, I was unable to find sufficient information regarding my problem either in forums, via google or in #ubuntu.
<stackpopper> Basically I was wondering if you could advise me as to how I could hack the ubuntu release iso so that the install kernel as well as default kernel installed can be replaced with one patched to support the imac G5.  As I am assuming that by applying the new imac patches to a newer kernel would resolve these issues plaguing users attempting to install this.  I'd like to be able to contribute a solution to the commu
<stackpopper> nity if at all possible.  Should I simply "go away and wait for the next release?"
<farruinn> I don't know how much work that entails, but I do know that there will be a ppc_64 version of hoary
<farruinn> which is out in 3 months =)
<bob2> there will be?
<stackpopper> This is a good thing.  Sadly my patience is uncontrallably limited and I feel an extreme need to get my hands dirty. 
<stackpopper> power4 refers to the 64 bit IBM processor used in the G5's right? So I could initially replace all in install/power4 with happy alternatives? 
<toresbe> ...
<toresbe> there's an ubuntu install for the IBM power CPUs?
* toresbe would chuckle if there was one for s390
<bob2> why?
<bob2> debian works on it.
<bob2> stackpopper: probably be best to ask on the developer list
<stackpopper> bob2, right :)
<toresbe> yeah, I know, just that the concept of a user-friendly distro like Ubuntu installed on a s390 is amusing
<stackpopper> hopefully that would give install the thing then I could boot change root and compile a friendly kernel.
<toresbe> "< newb-dood> yeah hi i just instaled mandrake linux on a highend z-series computer here at work (nsa) and where cna i get msn mesenger for linux?"
<ajmitch> hah
<bob2> aiui it's not too hard to swap out kernels, but I certainly don't know how
<toresbe> "is 250 terabytes of disk enough for a mandrake install plz msg me"
<mjg59> PLZ PROVIDE LINUX DISTRIBUTION FOR VMS HOT LOVING K THX BYE
<toresbe> hahahaha
<sivang> mjg59: hehe
<toresbe> how do u install linux on cray computer plz msg me thx
<mjg59> You know that someone will ask you that one day, right?
<bob2> mjg59: a/s/l?
* toresbe longs for the day
<mjg59> UBUNTU SUPPORT RECTAL INSTALLATION MSG ME PRIV K THX
<sivang> I wanna have naked people on my AlphaAXP please please make it work there
<mjg59> AXP
<mjg59> Haha
<sivang> mjg59: hehehehe
<sivang> mjg59:  :)
<toresbe> will traed 0day warez for hlp installing ubuntu on cdc6700 msg me
<toresbe> plz hurry computer using 500kwatts of power
<zul> mjg59: i thought you never asked :)
<toresbe> mjg59: Find the goatse man. He'll know how :P
<mjg59> I'm not hot on plastic shards
<srbaker> uh
<srbaker> anyone here know how to change gvim's font?
<daniels> mdz: what the fuck?
<daniels> mdz: when did that regress?
* daniels STARES at #5889.
<mdz> dunno, haven't tried powerpc lately
<daniels> mdz: the first two liens were about cirrus_laguna, but year
<daniels> or cirrus_alpine or whichever
<daniels> oh, I know how that regressed.
<daniels> such a stupid driver. :\
<mdz> I have no idea if it would have actually worked if it got the right driver loaded
<mdz> but trying to load a nonexistent driver seemed pretty broken
<daniels> it's not non-existent as such
<daniels> convention had drivers as %s_drv.o, with libraries as lib%s.a
<daniels> cirrus has cirrus_laguna.o and cirrus_alpine.o
<daniels> which, predictably, matches neither of those two patterns.
<daniels> i think nv has the same problem with riva128.o
<farruinn> will the ppc hoary install disk allow you to mount hfs partitions?
<farruinn> it would make it much easier to install hoary on oldworld macs
<mdz> farruinn: the warty installer doesn't?
<farruinn> no, which is a real hassle
<mdz> the kernel modules are available to the installer
<farruinn> hm, are you saying it would be as simple as a 'modprobe hfs'?
<mdz> I'm saying that hfs.ko and hfsplus.ko are packaged in udeb form
<farruinn> sorry, what's udeb?
<mdz> udebs are the components which make up the installer
<mdz> but all udebs are not loaded unconditionally; the installer decides which ones it needs
<farruinn> ah, so how would I load the hfs udeb?
<mdz> I would expect it to be loaded automatically, by the time you reach the partitioning stage of the installer
<farruinn> ok, I'll boot into the install cd at some point and check
<farruinn> but if it doesn't is there a way to do it manually?
<mdz> yes, but it's not very convenient
<mdz> it'd be something like, udpkg --install /cdrom/pool/main/l/linux-kernel-di-powerpc-2.6/hfs-modules-2.6.8.1-3-powerpc-di_0.71ubuntu12_powerpc.udeb
<daniels> someone needs to extend hfs to the network or something
<daniels> so you can have hfsnw
<farruinn> that looks more straightforward than using chroot though
<mdz> farruinn: Kamion is the person to talk to about this, but he won't be awake for several more hours
<mdz> farruinn: failing that, you can send an email to ubuntu-devel
<farruinn> ok, thanks for the help! =)
* ajmitch hunts down dpkg patches
<daniels> jdz_: you missed my awesome pun
<daniels> er
<daniels> jdub: ^^
<jdub> what was your awesome pun?
<jdub> aha
<jdub> hahahaha
<fabbione> morning
<daniels> whattup fabbione
<fabbione> just woke up
<ajmitch> hi fabbione 
<Mithrandir> good morning.
<fabbione> lamont: ping
<fabbione> hey Mith
<jdub> is there any way of making pbuilder save changes after a login session?
<fabbione> nope
<Mithrandir> jdub: --save-after-exec or --save-after-login
<Mithrandir> jdub: it's the hit on "save" in the man page. :P
<jdub> ahr!
<jdub> silly
<jdub> silly me
<jdub> i shouldn't have got lazy after --help ;)
<jdub> thanks dude
<ajmitch> hmm, only after reading this thread on dpkg+selinux do I see that the dpkg maintainer is a canonical employee... :)
<fabbione> mdz: can we kindly promote silo -> main please?
<fabbione> otherwise i can't buil d-i anymore
<Mithrandir> fabbione: you saw my comment yesterday about not being able to test sparc last night due to forgetting to bring said sparc home?
<fabbione> Mithrandir: no.. i don't keep irc scrollbacks
<fabbione> Mithrandir: don't worry about it
<mdz> fabbione: sure, go ahead and add it to the seed archive
<fabbione> mdz: thanks
<Mithrandir> thom: have I told you how much I hate that firefox loses her menus when you upgrade without restarting her?
<fabbione> Mithrandir: what is the tipical contents of a signing/$archive.check file? gpg --verify ?
<fabbione> (for tla/baz)
<Mithrandir> gpg --clearsign
<fabbione> that's to sign
<fabbione> but to verify?
<fabbione> WARNING: no rule found for checking signatures from ubuntu-devel@lists.ubuntu.com
<mdz> mizar:[/tmp/netcfg-1.07ubuntu3/debian]  cat ~/.arch-params/signing/ubuntu-devel@lists.ubuntu.com
<mdz> gpg --clearsign
<mdz> mizar:[/tmp/netcfg-1.07ubuntu3/debian]  cat ~/.arch-params/signing/=default.check
<mdz> tla-gpg-check gpg_command="gpg --verify-files -"
<fabbione> thanks
<fabbione> somebody already added silo
<mdz> patch-67
<mdz>     Colin Watson <cjwatson@debian.org>
<mdz>     Add silo to base for sparc.
<mdz> a long time ago
<mdz> but it is not in main for some reason
<mdz> probably germinate
<mdz> yeah, definitely germinate
<mdz> hmm, I forget what time the d-i daily build happens
<mdz> jdub: new casper eliminates the network questions
<mdz> jdub: press enter on the keyboard question, and it's non-interactive all the way to the desktop
<mdz> complete with laptop notification icons
<fabbione> mdz: yeah.. i am adding all the other bits..
<mdz> seems to mess up if the IP->name resolution fails
<mdz> but otherwise working well
<Mithrandir> mdz: even when you have three network interfaces like I have?
<mdz> ah, just fixed that
<mdz> Mithrandir: I've only tested with two
<mdz> but I could put in a pcmcia card to test three
<fabbione> mdz: there.. committed to the seeds
<fabbione> mind to check if i did something dumb?
<Mithrandir> mdz: the daily iso I downloaded yesterday got confused.  Or actually, I think it might just be confused about my wlan card, which is a bit peculiar.
<dholbach> hai
<jdub> mdz: eeeeeeee-lite
<mdz> Mithrandir: how so?
<jdub> mdz: current build?
<mdz> jdub: no
<mdz> needs a new d-i upload followed by a new live CD build
<jdub> i'll rsync tonight then
<mdz> i.e., needs manual processing by elmo
<Mithrandir> mdz: it needs to have it's mode set explicitly, and I think it needs to have the ESSID set within the first five seconds after the driver loads.
<mdz> Mithrandir: it makes a reasonable attempt to bring something up, and if it fails, it expects you to do it with network-admin or whatever
<mdz> on my laptop, if the wired is plugged in, it uses that
<doko> mdz: thank for removing the last python2.2. package tonight
<mdz> otherwise it tries wireless
<Mithrandir> mdz: yeah, so if we ever support my setup, I'd be a bit surprised. :)
<mdz> doko: when elmo said there was only one package remaining, I could not resist :-)
<doko> :)
<mdz> fabbione: why sparc-utils in base?
<mdz> rather than supported?
<fabbione> mdz: because it is needed for the buildd?
<mdz> fabbione: I think it should go in supported, and be added to hoary.buildd in debootstrap
<mdz> unless it needs to be part of every installed system (and not just buildds)
<fabbione> in theory it is required only to build
<mdz> jdub: it doesn't reconfigure fontconfig yet, because that causes the cache to be regenerated which takes forever and eats memory
<fabbione> basically every package
<jdub> mdz: eh, bong
<mdz> I think supported+hoary.buildd then
<fabbione> mdz: ok.
<mdz> jdub: if that's important, we'll need to add an environment variable to its postinst or something
<mdz> assuming the cache doesn't actually need to be rebuilt
<mdz> if it does, we're fucked
<jdub> it doesn't
<jdub> just a config file change
<jdub> kinda silly that it does on reconfigure
<mdz> once that's done, the casper bit is trivial
<jdub> s/it does/it does it/
<mdz> I actually already did it, and then had to undo it because it sucked
<jdub> yeah
<jdub> that's rad, dude!
<jdub> woohoo!
<mdz> next I'm going to fix the templates that say installer
<mdz> and then we can do a proper announcement I think
<jdub> cool
<jdub> how are the custom cd docs going?
<mdz> jdub: http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo/view?searchterm=livecd%20custom
<mdz> er
<sivang> jdub: live ones? ;-) basically we're missing a a preseeing premier  and that's it - as I understood you just intall in the cloop fs your pkgs (this case locale and lang support)
<mdz> remove the obnoxious search bit from the end
<sivang> jdub: and that's it
<sivang> all left is to translate..:)
<fabbione> mdz: 112 should do it....
<sivang> s/preseeing/preseeding
<mdz> fabbione: regarding the installer stuff, you will need to ask Kamion
<mdz> but it looks OK to me
<fabbione> mdz: yup.. i will
<ajmitch> looks like selinux stuff won't quite be ready by feature freeze, at this rate 
<mdz> my d-i-fu is weak
<ajmitch> udev works if I strace it with -ff, not with -f
<ajmitch> looks suspicious to me
<mdz> udev is race city
<sivang> ajmitch: didn't you say that already someother time? ;-)
<ajmitch> sivang: yeah, I was expecting that it'd at least work, if only poorly :)
<ajmitch> I've been swearing at it a little too long now
<mdz> I wonder if we can safely suppress the location chooser on the live CD
<ajmitch> sivang: I might as well go back to rebiulding python packages :)
<sivang> ajmitch: hehe, well, just making sure I'm not starting to get heluscinative..;-)
* sivang probably had 98% spelling erros in that word.
<ajmitch> sivang: I mentioned the strace issue before, but only just found that it only boots if I hold my tongue right (-ff)
<ajmitch> I thought the patch I applied from fedora cvs might have helped in some way
<ajmitch> selinux could be something useful for the server team to look at :)
<sivang> ajmitch: ah yes ofcourse, although I may not be the right person to look at technically speaking, I am interested in howtoing one thing or another, testing stuff when needed etc..I am not techincally skilled to review selinux integrated code, patches etc...
<ajmitch> right
<ajmitch> well I talk with jbailey fairly often, he knows my plans
<sivang> ajmitch: cool
<ajmitch> he's heard me ranting today about udev, in another channel :)
<sivang> ajmitch: the glibc one?
<sivang> ajmitch: I am also good at makng unimplementable, rather naive ideas :-)
<ajmitch> yeah, he does glibc & other things
<sivang> ajmitch: http://www.ubuntulinux.org/wiki/DevHub ;-)
<ajmitch> seen it
<ajmitch> phpgroupware is good :)
<sivang> ajmitch: yes, but WorldPilot works with zope :)
<ajmitch> hmmph
<Mithrandir> ajmitch: can't be, it's PHP :)
<Mithrandir> sivang: is worldpilot still alive?
* ajmitch has been doing zope & plone coding recently
<ajmitch> Mithrandir: now php isn't quite that bad..
<pitti> Morning
<ajmitch> hi pitti 
<Mithrandir> ajmitch: I suggest you ask pitti whether PHP is bad. ;)
<ajmitch> heh
<ajmitch> I'm not that brave :)
<Mithrandir> ajmitch: or you could ask thom, fabbione or me.
<Mithrandir> or willy
<Mithrandir> or infinity
<ajmitch> I remember the rants at linux.conf.au for & against php :)
* daniels coughs pointedly at Mithrandir.
<Mithrandir> or daniels 
<Mithrandir> (us being the apache maintainers)
<ajmitch> yeah
<Mithrandir> daniels: we're becoming a spacious team, it seem.
<ajmitch> I think it might have been discussed at the debian miniconf there..
<daniels> ajmitch: and thom buying rasmus on behalf of the apache maintainers
<Mithrandir> buying?
<daniels> ajmitch: yeah, thom was writing his a2 talk while i was rambling about x or something
<daniels> Mithrandir: in the dunk tank
<Mithrandir> ah
<daniels> ajmitch: (my talk was also written in the session immediately before)
<ajmitch> yea, I remember that
<ajmitch> seeing people furiously writing during sessions
<pitti> ajmitch: well, let's say the PHP developers have an "interesting" understanding of e.g. buzzwords like "safe mode" (which is not really safe) or "open_basedir restriction" (which can be easily circumvented) and things like that :-)
* Mithrandir chuckles
<pitti> ajmitch: however, I agree that as a language it is not that bad
<ajmitch> that's useful to know :)
<pitti> mdz: ping
<ajmitch> too much legacy code around, like VB?
<pitti> ajmitch: hmm, I don't even think that this is the problem
<pitti> ajmitch: as I said, as long as you don't rely on safe mode and similar things, but do all checking manually yourself, it's quite fine
<pitti> jdub: here?
<jdub> pitti: yo!
<pitti> jdub: so what about this evo warty-update problem?
<pitti> jdub: why I shall not just upload -3.1 into warty-updates?
<jdub> so what do most packages use to write out crypt passwords in debconf?
<jdub> pitti: 3.1 in -security, given the mdz/me thread
<ajmitch> mdz: are you dropping python 2.2 & 2.1 support from packages now?
<Mithrandir> jdub: use the "password" type; delete immediately afterwards
<jdub> Mithrandir: oh, that's sensible 8)
<sivang> Mithrandir: I linked WorldPilot for the mere nice futuristic features list it had, I am not sure weather it's alive or not though, although might be nice to clone or derive upon :)
<ajmitch> sivang: plone-based?
<sivang> ajmitch: zope 2.x compatibel, so says the package :)
<ajmitch> are you sure you'd want a zope instance running on a devhub install?
<ajmitch> if it's zope-based, I'd prefer it to work with CMF & Plone as well, if possible
<sivang> ajmitch: it's a zope product you add
<ajmitch> yep
<ajmitch> not all zope products work with the cmf framework, but that won't matter to many people, I'd imagine
<ajmitch> the SF page refers to exchange4linux
<sivang> donwloaded it from here : http://umn.dl.sourceforge.net/sourceforge/worldpilot/worldpilot-release-1.1.0alpha4.tar
<ajmitch> yes, the home page link goes to the exchange4linux site
<ajmitch> on sf.net/projects/worldpilot
<sivang> ajmitch: weird, I went away and downloaded the package..
<ajmitch> e4l requires postgres, and omniorb
<ajmitch> I don't think there's any life in worldpilot now
<pitti> jdub: hmm, so I'm not really opposed to put the -updates fix from -ubuntu3 into warty-security
<pitti> jdub: but in general I agree to mdz, that's wrong
<jdub> mdz and i appear to be saying the same thing
<pitti> jdub: if somebody uses -updates, then security updates to these versions should be in -updates as well
<pitti> jdub: no, you don't
* jdub re-read
<pitti> jdub: mdz: 1 in main, 1.1 in -security, 2 in updates -> 2.1 in updates
<jdub> ok
<jdub> i see
<pitti> jdub: jdub:  1 in main, 1.1 in -security, 2 in updates -> 2.1 in security
<jdub> but that means that you'll have to do two security releases for any package that has an upadate
<pitti> jdub: right
<jdub> ok
<pitti> jdub: it will get worse if we have two or three releases to support :-)
<jdub> if you guys definitely want to do that extra work for it ;)
<ajmitch> sivang: so how do I help out the ServerTeam? :)
<pitti> jdub: I think I will upload it into -updates; it's just cleaner that way
<pitti> jdub: I just wanted to make sure that we all agree that this is not principally wrong
<jdub> so this means that, for every release, we'll be maintaining two security tracks for packages that have received updates
<jdub> and then a number of releases on top of that
<pitti> jdub: sounds like hell, doesn't it? :-(
<pitti> jdub: however, once you have a verified patch, shipping it for another release ususally does not take the same time again
<jdub> yeah
<pitti> jdub: maybe except for the kernel
<jdub> given it's the same upstream version
<pitti> jdub: usually, -updates should not receive new upstream versions, right?
<pitti> just major fixes
<pitti> which can come as patch
<pitti> jdub: Uploading via ftp evolution_2.0.2-0ubuntu3.1_source.changes: done.
<jdub> :-)
<jdub> i guess -updates may get new upstream versions
<daniels> god
* daniels notes not to ever update X in hoary post-release.
<pitti> jdub: yeah, but it's not like putting OO2 into -updates when we have 1.1.3 in main (I hope... :-) )
* infinity notes that asking him about PHP is probably a bad idea.
<jdub> ;-)
<jdub> pitti: "mdz: linux-image-2.6.11 for -updates? fixes critical inotify bug"
<jdub> bwaha.
<jdub> <- asso
<fabbione> jdub: ahha
<pitti> elmo: postgresql 7.4.6-7 sync, please 
<pitti> Hi mvo_ !
<mvo_> hi pitti 
<sivang> ajmitch: hmm,  if you can make let's say a package which when install on a "custome"(server) basic ubuntu system and turns it into a router/firewall, that'd be cool - this is one of the "server classes" I thought of :) just edit the wikipage with your findings. but hack, I am in no position to tell people what to do anyways so it's up to you :)
<dholbach> morning mvo_
<mvo_> hi dholbach 
<ajmitch> sivang: aha
<mvo_> new nick?
<sivang> dholbach: morning
<ajmitch> sivang: by router, you don't mean bgp/ospf with quagga, but basic routing & iptables?
<dholbach> mvo_: had to... having 2 different IRC nicks on gnome.org and freenode.net was a bit stupid and people would have killed me, if i'd been danielh (for having to type daniels completely ;-))
<dholbach> hi sivang :-)
<sivang> ajmitch: I am using a custom made debian firewall/NAT/forwarde, and by now I managed to have it support all my bittorrent, ftp, IM and VoIP needs - would be nice to have one apt-get to do (and then even integrated into the livecd) and have it preconfigured, or ask in advance which "services" you want to box to allow as a starters.
<ajmitch> right
<ajmitch> sounds like it could be useful
<sivang> ajmitch: I suppose that with the proper network magic, we could have a livecd for diskless router/NAT ubuntu machines. as I todl you, I like to dream :)
<jdub> hrm.
<jdub> sivang: check out gibraltar
<jdub> sivang: would be good to port it onto an ubuntu livecd
<jdub> maybe get them keen for building it on top of ubuntu
<jdub> (they're debian-based atm)
* ajmitch takes a look
<jdub> gibraltar is nicely put together
<ajmitch> sivang: it shouldn't be too hard with the good work that's been put into the livecd lately 
* sivang tomboys heavily :)
<ajmitch> throw in a bit of traffic shaping, too
<ajmitch> fun, gibraltar have some interesting licensing now
<sivang> jdub: tnx
<ajmitch> free for private use for up to 5 users
<jdub> ajmitch: oh? :|
<ajmitch> jdub: the source code is probably all still there
<ajmitch> but they 'technically restrict' it to that
<ajmitch> http://gd.tuwien.ac.at/opsys/linux/gibraltar/iso-images/copyright
<sivang> ajmitch: even on the source code?
<ajmitch> sivang: no, see the license
<ajmitch> I'm guessing it's not restricted if you want to dig in & fix it
<ajmitch> but cd layout is copyrighted
<ajmitch> great, ETA of 4 hours to download this sucker
<sivang> ajmitch: would you go and add this to the serverteam wiki page? ;-)
<ajmitch> sure, once I get back from supermarket
<ajmitch> need to grab caffiene :)
<sivang> ajmitch: hehe, k
<jdub> what's a relatively safe way of moving a config file in postinst?
<Treenaks> jdub: daniels is the config-move-master
<Mithrandir> jdub: conffile or config file?
<Kamion> mdz,fabbione: sparc-utils looks to me like something for base; it's very similar to powerpc-utils which is in base (and the latter has to be, because stuff like yaboot-installer uses it)
<Kamion> mdz: the problem with using the metapackages in base-config is that it makes it much harder to customise what gets installed
<fabbione> Kamion: hey.. well i think we can keep it in supported.. nothing uses it other than special builds and buildd
<jdub> Mithrandir: conffile
<fabbione> Kamion: are the changes ok, otherwise?
<fabbione> Kamion: so i can ask elmo to do the magic on the archive
<Kamion> mdz: it's a lot easier for people to do ~tubuntu-desktop!foo!bar!baz!ubuntu-desktop than to figure out that ~tubuntu-desktop exists
<Kamion> fabbione: what changes?
<fabbione> Kamion: i did an update on the seeds as mdz suggested
<fabbione> Kamion: also to the installer/ship seeds to get the udebs in main
<fabbione> and the linux-headers..
<Kamion> oh ok, let me check
<fabbione> thanks :-)
<Mithrandir> jdub: conffile moving is deep magic.  Or it might be documented in Debian's developer's reference.
<Kamion> fabbione: do you really need both linux-sparc64 and linux-sparc64-smp in base? i.e. can you not pick one and use it on all machines by default, the way we do on other architectures?
<pitti> elmo: ping
<fabbione> Kamion: yes. we can use the UP one as default...
<Kamion> fabbione: also having put stuff in base and ship you really don't need to (and shouldn't) put it in supported as well
<fabbione> Kamion: i did a grep for some keywords and some stuff was already duplicated.. so i tought it was "standard" practise
<Kamion> it's not, the current instances are mistakes
<fabbione> ok
<Kamion> people misunderstanding germinate generally
* fabbione isn't very different to others in that aspect
<Kamion> basically anything in lesser seeds (base < desktop < ship < supported) is automatically part of greater seeds as well
<fabbione> yes that was clear from the info files time :)
<fabbione> Kamion: can i fix the seeds or are you already doing it while reviewing?
<Kamion> fabbione: is it ok to move linux-sparc64-smp out of base, then?
<Kamion> if so I'll happily do that
<fabbione> Kamion: yes i think there should be no problem
<fabbione> and if it does we can always revert back
<fabbione> i am not too picky at the moment.. i just need to be able to build d-i :-)
<Kamion> fabbione: done
<fabbione> Kamion: thanks dude :-)
<fabbione> Kamion: but killing the -smp kernel from the seeds.. won't that leave it in universe?
<fabbione> never mind me!
* fabbione hands Kamion a /ignore fabbione all
<Kamion> I didn't kill it, just left it in supported
<fabbione> Kamion: did you have any possibility to test again the kernel/grub problem?
<Kamion> sure
<fabbione> Kamion: last thing yesterday was the kenrel on people and you confused on the one you tested :-)))
<Kamion> yeah, but I tried it again and it failed ...
<fabbione> ok
<Kamion> although I can run through again just to make sure. what's the vmlinuz md5sum?
<Kamion> 29de307fc813a97debea29a075cc13e0  /boot/vmlinuz-2.6.10-2-amd64-generic
<Kamion> grub segfaults with that
<fabbione> yup
<fabbione> there is only 2 things left to check
<fabbione>   * Unset CONFIG_ACORN_PARTITION_CUMANA.
<fabbione>       . Add patch thaw_processes.dpatch.
<fabbione> and after that it will be only BONG
<fabbione> because we are talking readding mISDN and ibm-trackpoint patch (ps2)
<fabbione> than we are back to -9
<fabbione> the other changes are hppa/ia64 related
<fabbione> and there is NO way they can affect amd64
<Kamion> would it be worth trying to rebuild -9 on a current system?
<Kamion> it could be toolchain-related
<Kamion> (at which point I assume I'm fucked, but you never know :P)
<fabbione> Kamion: indeed...
<fabbione> i am already building -10 with less changes
<fabbione> finished this.. i will try a clean -9
<Kamion> ok
<dholbach> Mithrandir: did you have luck with syncing mozilla-thunderbird-locale-* from debian?
<ogra> morning
<dholbach> hai ogra!
<ajmitch> hi ogra 
<sivang> ogra: morning
<ogra> :)
<ajmitch> hmm, almost like the ogra fanclub there
<thom> morning
<ajmitch> hi
<thom> hrm, whats the deal with UVF for universe?
<thom> really, i mean, can i stick some NEW stuff in universe now?
<ogra> i dont think it applys thet....
<ogra> there
<fabbione> Kamion: 70c8851a3ac32dfc4c74c67d1d5756da  linux-image-2.6.10-2-amd64-generic_2.6.10-10_amd64.deb
<fabbione> usual place
<ajmitch> ogra: to new packages, or to universe in general?
<ogra> thom: since i did one upload last week, i think its ok...
<ogra> at least nobody complained
<thom> righto
<thom> heh
<Kamion> fabbione: grabbing
<thom> 'swhat i figured, but wanted to check
<fabbione> hey thom
<fabbione> hey ogra
<ogra> hey fabbione
<Mithrandir> dholbach: I haven't had the time to check yet.
<dholbach> Mithrandir: ok
<fabbione> Kamion: ok.. building a clean -9 in the meanwhile
<ajmitch> thom: you are lead of ServerTeam?
<ajmitch> we were just talking before about a router/firewall package to quickly put together a NAT box & firewall
<fabbione> ajmitch: that's quite hard...
<dholbach> ajmitch: bastille is fine there, although it could need some ncurses->debconf- and some simplification-love
* Mithrandir just got about 2kE to spend on a workstation for university.
<sivang> wheee
<ajmitch> fabbione: hard in knowing the appropriate network settings?
<fabbione> ajmitch: not only... also defining a "standard" setup to start with
<fabbione> a router/firewall has tons of different implications...
<ajmitch> the simplest being a home LAN
<fabbione> ajmitch: that can still be a huge problem
<fabbione> probably more complex than you think...
<ajmitch> which is why we talked of integrating existing stuff out there
<fabbione> Kamion: b7f6ec954d6b893b38d969f8f71b02ea  linux-image-2.6.10-2-amd64-generic_2.6.10-9_amd64.deb
<fabbione> as next one
* Kamion does the warty/amd64 install CD dance
<Kamion> fabbione: that -10 fails
<Kamion> getting -9
<fabbione> ok
<ogra> ajmitch 
<ogra> how did you build your packages ?
<ajmitch> ogra: hmm?
<ogra> i see only i386.changes files there
<ogra> but we will need a source package for upload, so it will build on other arches too....
<ajmitch> I was lazy & used debuild, why is that?
<ogra> so use debuild -S ;)
<ajmitch> it produces source packages anyway :)
<ajmitch> actually no..
<ogra> yup, but only for your arch ;)
<ajmitch> pff, everyone uses i386, right? :)
<Kamion> need to use debuild -S for upload
<ogra> hmm, amd64 here.....
<Kamion> the upload'll be rejected if it contains binary packages
<ajmitch> Kamion: yes, I can't upload them so I didn't see a problem with it
<Kamion> ajmitch: sure, but for the future :)
<ajmitch> Kamion: in future I'd probably be using pbuilder for them :)
<ogra> ajmitch: which still rquires -S ;)
<ajmitch> ogra: yes, pdebuild does source packages by default
<Kamion> there's no real need to use pbuilder for source uploads, except perhaps in incredibly scary cases
<ogra> ajmitch: if i shall upload them for you, i will need a _source.changes (and friends) file 
<Kamion> the source-package-construction step hardly ever depends significantly on the base system
<ajmitch> Kamion: my hoary box has  anumber of patched packages now
<Kamion> ajmitch: yes but it's very unlikely to matter
<Kamion> I build most of my Ubuntu uploads on a Debian box, for instance
<Kamion> since that's my main development system and it's awkward to switch it over
<ajmitch> ok
<Kamion> it matters for binaries, but ...
* jdub now has crazy pbuilder tgz action
<ajmitch> I've had issues with pbuilder on hoary, with the tarball not including gpg by default
<Mithrandir> Kamion: I had fun switching vawad this weekend.  And I switched to another architecture while I was at it. :P
<ajmitch> it causes all the package grabbing to fail :)
<Mithrandir> but then, I'm one of the crazy people who think installing a system with wget, tar, ar and gzip is just fine. :)
<ogra> jdub: please convice tseng for MOTU, he still hesitates ...
<Kamion> it's too convenient to have a single system from which I can upload both to Debian and to Ubuntu
<Kamion> without chroot madness
<jdub> tseng: HESITATION IS FOR THE WEAK AND CONSTIPATED!
<ogra> yeah !
<Kamion> ajmitch: hmm, gnupg is not in hoary.buildd
<Kamion> I wonder if that's a bug
<Kamion> lamont: ^-- ?
<ajmitch> ogra: ok, what else do you need? I've rebuilt those 3 as source packages..
<Kamion> hm, I also wonder if lamont would care if I just uploaded it
<Kamion> but he'll be up in a few hours anyway ...
<ajmitch> brb
<ogra> ajmitch: the files described in the _source.changes file....
<azeem> Kamion: why does one need gnupg inside the chroot?
<azeem> ah, apt-secure?
<Kamion> indeed
<Kamion> ajmitch: BTW, always run debdiff <old>.dsc <new>.dsc after building a source upload - then even if something on your system has affected it adversely, you'll know. :)
* ogra wonders about an upload pool for MOTU candidates where the candidates can practise dput/dupload and the MOTU master just appoves them to et forwarded to the buildd....
<Treenaks> uh.. PGP global directory has signed my key? WTF?
<fabbione> Treenaks: did you reply back to their emails?
<Treenaks> fabbione: not that I remember.. maybe the very first one when I didn't know about the torrent of mails that was to come
<fabbione> that's probably why
<fabbione> i refused to answer back
<Treenaks> Oh well... trust = "n" now
<Treenaks> and I'm not signing it back :)
<fabbione> clearly
<Kamion> fabbione: you're gonna love this: -9 fails
<fabbione> OH YEAH
<fabbione> YES YES GO TOOLCHAIN!
<fabbione> Kamion: and now.. who is the amd64 porting team leader?
<Kamion> I'm going to grab real -9 from the morgue, just to make absolutely sure
<Kamion> that would be Mithrandir
<fabbione> fuckedandowned=$(whois "amd64 porting team leader")
<fabbione> mail -s 'fix the toolchan dude' $fuckedandowned@youaredoomed.com
<jdub> oh, elite
<jdub> inotify 0.18 came out
<fabbione> Kamion: good point
<jdub> and gamin just got patches for it
<Kamion> fabbione: the only amusing thing is, there were no toolchain uploads that I can see between -9 and -10
<fabbione> jdub: i want to know what upstream says about it
<jdub> fabbione: kernel?
<fabbione> jdub: for inotify
<jdub> fabbione: viro whinged again
<fabbione> "whinged"?
<jdub> fabbione: bitched?
<fabbione> jdub: ah ok
<fabbione> Kamion: hmmmm libc6?
<Kamion> yow, could be I suppose
* ajmitch returns
<Kamion> if it's the fault of language packs I will laugh and laugh and laugh. :-)
<ajmitch> ogra: .diff.gz & .dsc ought to be there for each
<fabbione> linux86?
<fabbione> Kamion: so will i...
<ajmitch> ogra: do you have to review the whole .diff.gz for each package i give you? :)
<fabbione> Kamion: and you know why i will laugh forever?
<Kamion> fabbione: actually, though, the only glibc change in there was my fix to locales.config
<thom> whiprush: thanks for the filechooser pointers
<Kamion> fabbione: oh?
<fabbione> Kamion: afaik the "you touched last" is still a valid rule :P
<Kamion> ajmitch: I'd expect him to review the interdiff between the previous .diff.gz and the current one
<ogra> ajmitch: i look over the diff and then i build a test package and try it out....if both seems fine i'll upload and get slapped by the guys that know more then me if there is still something wrong ;)
<fabbione> and the libc upload is your ;)
<Kamion> heh
* fabbione sits on his back and grins
<ajmitch> ogra: great, are you able to review pnet as well? it's not python
<fabbione> no seriously.. let's try with -9 from the morgue
<Mithrandir> fabbione: hm?
<ajmitch> Kamion: that's what I hoped, since it's a 1.9MB .diff.gz
<Mithrandir> fabbione: what's broken today?
<fabbione> Mithrandir: the kernel/grub thingy on amd64.. it seems related to something that is not grub or kernel..
<Kamion> I'll confirm in a second
<ogra> ajmitch: upload it, i'll look over it....if its to huge for me i'll forward the request to haggai....
<Mithrandir> fabbione: fun!
<fabbione> Mithrandir: yes.. the amd64 porter will have some fun
<Mithrandir> Kamion: btw, I saw a weird thing on my home box when I booted it.. it looped in "loading stage1.5"
<fabbione> oh but that's you!
<fabbione> :P
<ajmitch> ogra: the diff between the ubuntu revision & the debian one is small
<Kamion> Mithrandir: yes, exact same thing
<Kamion> Mithrandir: if you track that back I bet you'll find that grub segfaulted on install
* Mithrandir kicks fabbione.
<ogra> ajmitch: if it survives my testing it'll be fine :)
<Mithrandir> Kamion: nope, didn't
<ajmitch> it had better..
<ogra> ajmitch: since i assume the debian version works.....
<ajmitch> well yeah
<Kamion> Mithrandir: are you sure? grub-install doesn't bail out as it should when grub segfaults
<ajmitch> I'm the debian maintainer for it
<Kamion> Mithrandir: you'd only have noticed if you were reading the logs very closely
<ajmitch> I'm putting off sponsorship since the DAM has only to create my account...
<Mithrandir> Kamion: fairly sure; I ran grub-install from the command line and couldn't see any segfault.
<Kamion> Mithrandir: strange; at any rate that same loop is why I noticed that there was a problem in the first place
<Kamion> maybe it's related but not identical
<Mithrandir> possibly.
<haggai> jdub: are we nearly there yet? *hide*
<ajmitch> hey haggai :)
<Kamion> Mithrandir: as far as I can tell, grub segfaults when it tries to enter a nested static function
* ajmitch grabs the CoC to sign
<Kamion> at any rate a printf() just inside that function never gets reached
<ogra> ajmitch: finally....
<Kamion> oh, hmmmm. virgin -9 fails now ...
* Kamion wonders if he fucked up the old test :(
<ajmitch> ogra: hmm?
<ogra> * ajmitch grabs the CoC to sign
<haggai> hi ajmitch
<ajmitch> yes...?
<Kamion> sorry fabio
<ogra> ajmitch: yes :-)
<ajmitch> considering that the wiki page says I need to sign after the CC meeting, the next one not being until the 8th..
<ajmitch> I've got quite awhile to hassle you about uploads
<ogra> ajmitch: do you plan to change your packages daily ?
<ajmitch> probably not
<ogra> heh
<ajmitch> at most only every 2 days :)
<ajmitch> but I plan to help out in the grand python transition
<ajmitch> '10
<ajmitch> sigh
<ogra> ajmitch: so i'll take 2 days to review them.... :-P ... makes 3 uploads until you can go for it yourself :)
<Kamion> elmo: please sync groff 1.18.1.1-6 from incoming; no new upstream version, just fixes man page licensing stuff
<ajmitch> ogra: sure, I'll try & get a few done each day then :)
<ogra> ajmitch: if the TB and CC members are in the same meeting, its probably possible to approve you earlier....and if not....its only 2 weeks, not eternity...
<ajmitch> not like debian NM :)
<ogra> NOT AT ALL !!
<ogra> ;)
<Kamion> we'll probably do a round of approvals in the next TB meeting
<ajmitch> I've added myself to the CC agenda page
<ajmitch> but it's at 5am local time, so I doubt I'll be there
<Kamion> mm, let's clear the agenda from the last meeting first, otherwise you might get lost
* Kamion edits
<ogra> ajmitch: its probably not necessary to be there (if i undrstood it right in yesterdays meeting)
<ajmitch> hmm, I guess jeff is already approved by now then :)
<Kamion> yes
<ajmitch> that's useful
<Kamion> OK, fixed up
<ajmitch> thanks
* ogra wonders if not the MOTU master / helper should be there on behalf of new MOTUs, even if its a nice gesture to appear (citing mako)
<ajmitch> do I need to be on the TB agenda or not?
<Kamion> don't worry about it for now, I'll make sure it's mentioned
<ajmitch> ok
<ogra> hahaha https://www.redhat.com/archives/nahant-beta-list/2005-January/msg00064.html
<fabbione> Kamion: so -9 is fucked too...
<Kamion> yeah, sorry for the waste of time :(
<Kamion> I'm walking back through revisions now, PROPERLY this time
<opi> smurfix, moinmoin-twisted is still not there, moinmoin-data depends on Python2.4 :)
<fabbione> Kamion: try -5 and -7
<Kamion> -8 confirmed broken, trying -7
<fabbione> or -8 in place of -7
<fabbione> -7 is no point
<fabbione> try -5
<Kamion> ok
<fabbione> -6 is known to be broken for other reasons...
<lypanov> hi *
* lypanov has a quick question
<lypanov> does ubuntu package ruby in a sane manner unlike debian's current messup?
<smurfix_> opi: working on it (among a bazillion of other stuff)
<opi> smurfix, I'm not rushing you! :)
<opi> smurfix, it's just a note, because I'm in office
<lypanov> as in, is there a package that installs a *standard* ruby installation, or is it required that for any given application the user knows a list of over 10 packages that are normally just installed?
<smurfix_> you can't, you're not paying me for it ;-)
<thom> lypanov: doubt we've touched ruby at all
<opi> smurfix, ;->
<lypanov> thom: can i advise that you do so? :)
<lypanov> thom: the ruby app developers are getting increasingly annoyed at debian's ignorance on the matter
<thom> lypanov: we're not that interested in ruby. if you wish to become a universe maintainer and fix it, please do :-)
<opi> oh, yes, polish Ruby! :)
<lypanov> thom: and i'd love to be able to send a mail to the list saying that ubuntu *don't* screw up ruby
<Kamion> can you elaborate on exactly what's wrong with the Debian packages?
<lypanov> thom: well its a bug in the packaging, and if you care about your users (me ;)) then could you explain how i could get the bug through and the change made?
<Kamion> we don't have any Ruby experts around that I'm aware of
<Kamion> ideally, send patches to correct the packaging
<lypanov> Kamion: ruby is a 'platform' that consists of many libraries that the debian packaging splits up heavily
<Kamion> and hassle us until it gets considered
<opi> it's like Python 
<lypanov> kamion: this isn't a problem, but i don't think its really appropriate for applilcations to check that libraries that shoulld be installed by default are installed
<Kamion> ok, there's nothing intrinsically wrong with splitting up libraries
<lypanov> no. agreed. i like it
<Kamion> why can't applications just depend on the libraries they need
<Kamion> ?
<lypanov> *however* there should be a meta package which installs the default ruby platform or something
<ajmitch> lypanov: I saw someone talking about ruby packaging on planet.debian.net, perhaps something may come of it :)
<lypanov> ajmitch: ah :) i'll read
<azeem> it was just bitching as well
<lypanov> oh :/
<Kamion> hmm, IIRC some of the versioning being on crack with regard to ruby package names around the time of the 1.6->1.8 transition in sarge
<Kamion> I wonder if that's saner now
<lypanov> no point in bitching, however its really important that this gets fixed
<azeem> lypanov: why don't fix it in Debian?
<azeem> daf is a ruby guy I believe
<ogra> lypanov: and if you want, you could always become a MOTU and help fixing it yourself :) (nad convince the upstream maintainer to adopt your changes)
<lypanov> azeem: i'd prefer to get it fixed in debian yup, however it seems that nothing has been done about it. and i know that many people have made complaints though i'm not sure if formal
<ogra> lypanov: https://www.ubuntulinux.org/wiki/MOTU
<Kamion> I don't see a Debian bug about i t
<Kamion> why not?
<azeem> ogra: do you actively promote forking Debian packages?
* lypanov puzzles
<ogra> azeem: not really...
<lypanov> Kamion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286400
<ogra> azeem: but i'm looking for MOTUs ..... what about you ;)
<azeem> lypanov: that's one month ago
<Kamion> oh, source ruby-defaults, ok
<lypanov> azeem: yup, i'm completely confused as to why there aren't more. this has been a *very* old complaint
<lypanov> but as i was previous to ubuntu in no way using debian. it wouldn't have been my place to make a bug report...
<azeem> lypanov: fair enough then
<azeem> let's hope this gets sorted out eventually
<lypanov> azeem: so best way would be to track the progress of this bug and if it doesn't get sorted out moan? ;)
<Kamion> ok, I don't think it's appropriate for somebody who doesn't understand ruby to make this change, but please send a packaging patch to Debian bug #286400 and let us know
<ajmitch> ogra: reminds me, who wants to do the mass filing for python2.4 support on those packages we change in universe?
<Kamion> it would be best for this change to happen in conjunction with Debian, otherwise if Debian happen to pick a different name for the metapackage then we have to figure out how on earth to transition people
<lypanov> Kamion: i'm clueless when its comes to packaging in debian
<ogra> ajmitch: who ever made the change 
<Kamion> lypanov: find somebody who isn't and who knows ruby, and get them to do it
<ajmitch> ogra: ok
<lypanov> Kamion: i'll give that a shot
<azeem> lypanov: I'll talk to daf about it, he does the gnome-ruby packages and might know about this
<azeem> need to talk to him anyway
<ogra> ajmitch: thats one of your resposibilitys if youre a MOTU
<lypanov> thanks azeem
<lypanov> he probably understands the difficulty
<lypanov> for the moment though
<lypanov> whats the line to install all the dependancies of a given package?
<ajmitch> ogra: that's ok, I don't mind :)
<azeem> lypanov: it's basically for ruby developers who want to have a nice development environment, right=
<lypanov> but *not* the package itself
<azeem> ?
<azeem> lypanov: apt-get install foo; apt-get remove foo :)
<lypanov> azeem: well ruby is assumed as having a certain base set of packages and the ruby pkgs in debian don't
<ajmitch> lypanov: apt-cache depends?
<lypanov> azeem: so its not even about nice development environment, its not even possible to install/run some of the most trivial and commonly used ruby packages on debian currently.
<azeem> lypanov: you mean some ruby packages do not declare the correct Dependencies?
<azeem> that's bad of course
<lypanov> azeem: in my installation details for my own package i had to explicitly say exactly which packages should be installed, i don't have to do any such thing for other distributions
<lypanov> azeem: not debian packages. source ditros
<azeem> hmm
<lypanov> s/distros*
<smurfix_> lypanov: How much space do these not-in-Debian standard packages take?
<Kamion> so basically just a metapackage that installs everything in 'apt-cache showsrc ruby-defaults | grep ^Binary:'
<lypanov> smurfix: highly minimal amount they are tiny
<lypanov> Kamion: not sure what that command does ;)
<Kamion> lypanov: run it and find out, it's not dangerous
<Kamion> (purely display)
<smurfix_> lypanov: so splitting them up was stupid in the first place. I hear elmo rant about that weekly.
<lypanov> smurfix: yup
<lypanov> smurfix: these are packages consisting of max 50kb of src code
<lypanov> smurfix: it is really just plain silly
<Kamion> unfortunately if we rearrange them totally in Ubuntu with respect to Debian then our merging job is huge
<Kamion> which isn't feasible without a team dedicated to dealing with it
<lypanov> but thats not required. i have no real problem with the splitup
<lypanov> just that having a meta pkg that installs the default system would be lovely :)
<smurfix_> lypanov: so become a MOTU and upload one. ;-)
<lypanov> oh. i have a debian system here at disposable :)
<Kamion> smurfix_: as I said above, this REALLY should be coordinated with Debian
<Kamion> otherwise we're setting ourselves up for transition costs later
* lypanov is confused by this ruby-defaults thing
<smurfix_> Kamion: I agree
<Kamion> ruby-defaults is there so that ruby1.6 and ruby1.8 can be installable in parallel and 'ruby' can be whatever's currently sensible
<lypanov> ah
<Kamion> (in theory, at least)
<opi> Kamion, what if ruby would be included in main?
<Kamion>    ruby1.8 | 1.8.1+1.8.2pre2-3 |         warty | source, amd64, i386, powerpc
<Kamion> it is
<opi> oh
<Kamion> not ruby-defaults though
<opi> :-)
<Kamion> (don't know why, presumably something cared about ruby1.8 but not about ruby
<Kamion> )
<Kamion> I think it's pulled in by vim
<opi> in debian, there's a vim-ruby
<opi> (iirc)
<Kamion> yes, and therefore vim build-depends on ruby1.8-dev
<Kamion> we actually removed that build-dependencies, but for some reason ruby1.8-dbg is explicitly in supported
<Kamion> s/cies/cy/
<Kamion> which I think was an oversight, we intended to have it all in universe
<azeem> Kamion: there's a comment from (presumably) ruby upstream in #290705 who has all binary packages except -dev, -dbg,-elisp and -examples should be included
<Kamion> oh, there's redland-bindings and swig1.3 too
<Kamion> fabbione: -5 dies; next suggestion?
<azeem> s/has/says/, d'oh
<lypanov> azeem: sounds right
<lypanov> the tcltk/tk stuff should also be optional i guess
<azeem> lypanov: was there discussion about this on the debian-ruby list?
* lypanov doesn't even know about a debian-ruby list ;)
<ogra> <dholbach> wenn ich dich noch 3-4 mal fr MOTUs werben hr, schreib ich mich ein :-)
<ogra> dholbach: become a MOTU !
<ogra> dholbach: become a MOTU !
<ogra> dholbach: become a MOTU !
<ogra> dholbach: become a MOTU !
<ogra> ;)
<azeem> * Dafydd Harries [Wed, 11 Aug 2004 00:15:28 +0100] :
<azeem> > I think having a ruby-stdlib package is an excellent idea
<dholbach> ogra: HAHA! :-)
<azeem> there you go
<ajmitch> ogra: you seem to be rather aggressively recruiting there
<ogra> ajmitch: if it helps ;)
<lypanov> azeem: how on earth do u get this stuff? ;)
<azeem> however, the ruby-defaults maintainer had this comment:
<opi> ogra, you need mind controling device
<azeem> "apt-get install $(grep-available -n -s package -F source -X ruby1.8 | grep lib)"
<azeem> lypanov: http://lists.debian.org/debian-ruby/2004/08/index.html
<ogra> since haggai and sladen are very busy with some big projects, i'm alone with 15000 pkgs HELP ME GUYS !!
<ajmitch> ogra: I don't think I was asked or encouraged much :)
<ajmitch> you'll survive, I'm sure
<ajmitch> 10 a day, and you'll be fine :)
<azeem> heh, haggai managed to get off the train in time?
<opi> ogra, copy'em from ftp.debian.org and throw into archive.ubuntu.com -- then pray -- maybe noone will notice ;)
<lypanov> azeem: thx very much
<ogra> opi: nah, i want MOTUs ;)
<fabbione> Kamion: -5 too???
* fabbione sighs
<opi> ogra, my package-fu is weak, I'm trying to get a white belt soon :)
<ajmitch> ogra: well I'm trying, honest
<ogra> opi: great :)
<ogra> ajmitch: you are nearly there... i want fresh flesh ;)
<opi> ogra, first, what is Linux and where I can get my mineswepper? :)
<azeem> ogra: training minions to do Debian work who are unfamiliar with it is *hard*
<ogra> opi: thats a user question, ask on #ubuntu ;-P
<azeem> I just tried that with a couple of people who got interested in Debian GNU/Hurd
<opi> ogra, ok, will Minesweeper be in main? :>
<ajmitch> yes, I've had a little time to get used to debian packaging
<ajmitch> azeem: just porting work?
<ogra> azeem: but finding people that already did a package and want adopt only their favorite should work i think :)
<opi> ogra, yes, that's what I'm aiming for
<fabbione> Kamion: did 2.6.10 actually ever worked?
<azeem> ogra: great, so you have 15000 - 1 packages to look after :P
<ogra> azeem: at least one less....
<opi> azeem, nah, people have few fav. packages 
<ajmitch> ogra: saying that you have 15k packages is fine, but people need to know where to start.. like do you have a MOTU task list lying around on the wiki?
<ajmitch> I have my favourite packages
<opi> azeem, and if that one is a metapackage, like KDE
<ogra> azeem: to say it in german.... muehsam ernaehrt sich das eichhoernchen ;)
<opi> azeem, :-)
<martink> is there any way to get xtla (wonderful tla frontend for emacs) into universe?
<ajmitch> such as dotgnu, gnue
<Kamion> fabbione: kind of hard to tell, let me roll back to -1
<ajmitch> martink: beg ogra 
<Kamion> fabbione: note I only noticed this when I started trying to track down CD problems
<fabbione> Kamion: 2.6.10-1  and next will be 2.6.9
<Kamion> I'm sure I had at least one successful 2.6.10/amd64 installation, but ...
<ajmitch> I'm not sure what the policy currently is on new packages into universe
<ajmitch> apart from noone complaining yet about new ones
<ogra> martink: send a request mail to hostmaster@grawert.net , i'll poke the right ppl
<fabbione> Kamion: i only find hard to believe nobody (other than you) noticed the problem
<lypanov> azeem: i've emailed the maintainer and the ruby list
<Kamion> fabbione: Mithrandir's got a similar installation problem ...
<ajmitch> oh my
<lypanov> thanks to all who helped. regained faith in ubuntu :)
<martink> ogra: cool, I'll do that 
<ajmitch> xtla is in ams' home dir..
<lypanov> (not that i ever lost it :P)
<ajmitch> or at least it was
<lypanov> but the reaction here was a lot nicer than anything i would have received on the debian channels :/
<ogra> ok, i'm on my way to the office now...ciao, later....
<lypanov> so thanks, thom, smurfix, Kamion, opi, ajmitch, azeem, ogra, hope i got everyone :)
<Kamion> well, if you mean #debian, that's worthless and not really representative ...
<Kamion> at least not of developers
<opi> Kamion, nor for community
<lypanov> Kamion: right however finding the devel room is also not exactly easy. whereas you guys asked me to join here once :)
<opi> Kamion, because #debian.pl, ie is very helpful and nice
<Kamion> lypanov: it's the same naming scheme :)
<lypanov> Kamion: okay. maybe they would have also been nice but last time i got shouted at when on there :(
<Kamion> well, depends, I only bother with #debian-devel on OFTC
<Kamion> these days
<lypanov> ah.k didn't try that :)
<lypanov> like #perl on perl.org is useful but awful here :)
<Kamion> urr. 2.6.10-1 fails ...
<Kamion> fabbione: ok, the cutoff appears to be between 2.6.9-11 and 2.6.10-1 :-(
<Mithrandir> Kamion: hooray :(
<Kamion> fabbione: see http://lists.debian.org/debian-amd64/2005/01/msg00182.html, same problem
<elmo> pitti: done
<ajmitch> hi elmo
<pitti> Hi elmo, thanks
<elmo> ajmitch: hi
<opi> mdz, I don't have transcript from this upgrade anymore. After update this problem was gone.
<Kamion> fabbione: I've mailed some details to that thread
<fabbione> Kamion: thanks!
<thom> opi: i'm gonna resolve invalid on that bug then; i've not seen it at all and no-one else has reported it
<opi> thom, sorry I didn't provide more details
<opi> thom, I was sure that this package is broken due UTF string, and it keeps firefox from upgrading
<thom> the paste you provided was from openoffice
<thom> so it shouldn't affect firefox at all
<opi> yeah, but it keeped Firefox back :)
<opi> actualy I removed Firefox, and then installed it again
<opi> the error was still there, but apt-get -f install managed to finish
<eruin> all my firefox tabs show the last opened address :P
<fabbione> Kamion: is it an option for you to try 2.6.11-rc2-bk3 from kernel.org?
<fabbione> Kamion: if you want i can build it for you...
<eruin> I'm sure I saw an applet for ubuntu-updater getting installed.. am I wrong?
<Kamion> fabbione: yes, I can try that - that'd be cool
<eruin> ie what exactly is update-notifier?
<fabbione> Kamion: ok... i will try what i can
<Kamion> thanks
<thom> crikey netapplet (the applet edition) mostly works
<jdub> thom: you converted it, or added it's stuff to netstatus?
<thom> converted
<fabbione> Connecting to www.kernel.org[204.152.189.116] :80... failed: Connection refused.
<fabbione> DOH!
<Kamion> hmm, there's some weird code in grub that calls the _llseek() syscall by hand
<Kamion> I wonder if the numbers changed or something
<jdub> thom: what do you think about merging them?
<thom> jdub: waste of effort, they're two very different code bases - esp if we're binning both as soon as we hit bendy
<jdub> thom: true
<jdub> thom: though it would be nice to do just one applet replace
<mvo_> eruin: it sits in the background and tells you when updated packages are available (as a small icon in the notification area)
<thom> jdub: true
<eruin> mvo_: does it do any apt-get updating ?
<Kamion> though it does it in the way that the llseek(2) man page recommends
<mvo_> eruin: no, but it installs a apt config variable that will do it nightly. and it monitors for apt-get updates/installs
<eruin> ah :)
<eruin> mvo_: will it update next time you boot if it can't do it at the originally scheduled update time?
<Kamion> oh, no, never mind, that code's inside an #ifdef which doesn't fire
<lifeless> #ifdef KAMIONISBROKEN
<mvo_> eruin: if you have anacron installed, yes
<eruin> I kind of get the feeling I could have read about this somewhere instead of asking in here ;>
<lifeless> Kamion: whats your awk foo like?
<Kamion> lifeless: why thank you
<eruin> mvo_: cheers ;)
<Kamion> lifeless: mm, not excellent
<lifeless> got this bazaar-gpg-check script, it wants gawk, noone knows why.
<lifeless> it shits thom on a regular basis.
<mvo_> eruin: np. tell me if it fails to update itself after install/update :)
<eruin> willdo
<lifeless> I'm trying to find a suck^Wvoluntee^Whero to figure out why it wants gawk and make it mawk friendly
<Kamion> lifeless: I think that's liable to be beyond me, sorry, I don't know mawk/gawk differences
<fabbione> ATA over Ethernet support (ATA_OVER_ETH) [N/m/y/?]  (NEW) 
<fabbione> ^^^THIS IS SCARY!
<lifeless> EEK
<fabbione> 2.6.11
<elmo> mawk is unmaintained upstream and not even posix complete, in some areas, but for trivial use it shouldn't matter
<lifeless> elmo: apparently something thom builds for the distro (cough apache cough) wants mawk to build.
<thom> lifeless: i actually fixed apache2 to just use mawk unconditionally
<lifeless> elmo: and won't build with gawk
<lifeless> thom: cool.
<thom> lifeless: so it doesn't bother me that much now; it just shouldn't be a depends
<elmo> yeah, the problem there wasn't youre use of gawk, it was the build-conflicts apache had
<lifeless> well one stemmed from the other
<thom> lifeless: recommends would be a reasonable relationship, given that you don't *need* the gpg check script to use tla
<thom> anyway, it no longer shits me :-)
<lifeless> thom: gonna nuke the script in a month or two, don't want to fight silly bug reports from folk betwene now and then
<thom> fair enough
<lifeless> but good
<thom> you can just take the correct approach and figlet all bug reporters to death
<lifeless> :)
<fabbione> elmo: can you kindly run the germinate/ universe2main black woodo magic for sparc?
<fabbione> (seeds have been updated)
<elmo> I already did
<fabbione> Kamion: building now
<fabbione> elmo: you rock
<dholbach> see you later
<seb128> hum
<seb128> that's a powerful bug: #5887    	
<seb128> open /mnt/foo in nautilus and umount it with the command line -> box crash
<infinity> thom : The mawk/gawk issue is actually a long-standing gawk bug when operating in UTF-8 locales, or something.
<infinity> thom : It cropped up when vorlon built alpha apache2 binaries on his system.
<thom> infinity: utf-8 related? urk
<thom> yeah
<seb128> I blame the kernel
<infinity> thom : It would be just as sane to force the apache2 build to occur in 'C' and allow either awk.
<jdub> iz gtk bug
<thom> infinity: i hadn't realised it was locales related so i didn't think of that, but yes
<infinity> thom : I just went for the most obvious "it will work, who cares if it's ugly" approach, because, at the time, I was led to believe a release was imminent.
<thom> jdub: itym "boog"
<seb128> jdub: have you read #5887 ?
<jdub> thom: my french isn't very good
<elmo> infinity: a whole bunch of utf-8 issues got fixed in gawk recently...
<seb128> jdub: the box just freeze, even my ssh connections on it
* Mithrandir gets sucked into binutils
<infinity> elmo : How recently?... I can certainly retest this theory.
<seb128> jdub: perhaps an inotify issue ?
<fabbione> seb128: yes
<elmo> infinity: 3.1.4-2, in November
<fabbione> it's the same as 5431
<seb128> fabbione: ok
<seb128> thanks
<thom> infinity: yeah. i just did ac_cv_prog_AWK=mawk in front of configure
<fabbione> seb128: no problem.. i will reassign it soon to jdub
<infinity> thom : That works. :)
<infinity> elmo : Oh, right.  All those NMUs from Japan. :)  I should have tested apache2 after I saw those roll in, but I was either a) not thinking, b) busy.  Who knows which anymore.
<infinity> elmo : Thanks for the tip.
<jdub> seb128: that bug ROCKS
<jdub> seb128: it could indeed be inotify
<jdub> seb128: are you on gamin list?
<thom> elmo: any objections to adding bugs.ubuntu.com? I _always_ try and type it rather than bugzilla
<Kamion> it'd have yet more SSL cert problems ...
<infinity> Not if it just 302's to bugzilla.
<Kamion> true
<thom> i have no idea *why* our bugzilla is encrypted in the first place, but yeah, we could just 302 it 
<thom> anyway, just a thought
<elmo> thom: no
<Kamion> the https is slightly valuable for auth, but the whole thing doesn't have to be https for that does it?
<thom> given bugzilla should be going away anyway, a more generic name might be a good thing...
<mvo_> thom++
<Kamion> I think it was mostly because we used to be in supa-s3kr1t mode
<jdub> thom: or just flagrant url breaking :)
<fabbione> Kamion: what SSL cert problem? thom will take care of it :-)
<thom> fabbione: FOAD :-)
<Kamion> haha
<fabbione> ahah
<fabbione> i am a true bastard
<jdub> serious foad issues with mr. may
<infinity> That reminds me to file an RFU on ssl-cert.
<infinity> (request for unsucking)
<infinity> If that's even possible.
<thom> heh
<elmo> thom: well that's why I've not done bugs.u.c before, because it'll become malone at some point presumably, which would be a confusing switch without transition, but *shrug*
<fabbione> infinity: well.. thom is upstream you know?
<thom> fabbione: so are you
<fabbione> no
<infinity> fabbione : I think that may be the issue. :)
<fabbione> i only did the debian package
<thom> elmo: *nod*
<jdub> thom: oh, btw, no apache2-utils?
<thom> jdub: thinking about it
<jdub> thom: where does htpasswd live in post-apache1.3 land?
<infinity> jdub : We've had a few wishlist requests to split it out.  I was thinking I might.
<infinity> jdub : Right now, they're in -common.
<jdub> aha
<thom> htpasswd2
<jdub> heh
<infinity> thom : If we split -utils, we could retain the same names as apache and just conflict.
<thom> infinity: indeed
<infinity> thom : No irritating "ab2" and "htpasswd2", etc.
<elmo> the worse one is apache2ctl
<thom> we could just disappear apache-utils entirely, actually
<elmo> like, hello, inconsistent-much?
<infinity> elmo : That can't be helped, if we want 1.3 and 2.0 to be installable side-by-side, though. :/
<jdub> infinity: apachectl2
<thom> elmo: the binary is apache2, thus it's apache2ctl, like apache-sslctl
<infinity> jdub : I think it was named to match apache-sslctl and apache-perlctl
<thom> it's actually consistent with apache-*
<infinity> Yeah, what he said.
<jdub> bong ;)
<elmo> thom: it's inconsistent with sanity
<jdub> that's an unusable consistency! ;)
<fabbione> sanity????
<fabbione> what's that?
<jdub> thom: you are inspired by arch
<thom> elmo: and thus perfect for debian
<elmo> seriously, ab2, htpasswd2, apachectl2.. no wait.. sorry, my bad apache2ctl.. how OBVIOUS
<thom> elmo: i'll call it a2b if you like :-)
<infinity> elmo : Well, if we scrap ab2 and htpasswd2, then it becomes less irritating. :)
<fabbione> Kamion: 336081aaf4fe2d5d5e6e4222aaa952d7  kernel-image-2.6.11-rc2-bk3_10.00.Custom_amd64.deb
<thom> but yes, what he said
<infinity> thom : I like the idea of phasing out apache-utils, and just making apache2-utils provide it.  Shall I do that, like.. now?
<fabbione> Kamion: usual place
<thom> infinity: please do :-)
<infinity> fabbione : objections?
<fabbione> infinity: get ready to fix also the 284773243 RC bugs you will get that for that
<fabbione> infinity: i am VAC from Debian
<fabbione> i can't object
<infinity> fabbione : I didn't ask if you'd do it, just if you objected.
<fabbione> infinity: btw.. do we know eachother?
<sivang> seb128: what do you think about changing g-s-t to use tarball.mk ? ;-) what do you think debian upstream would say about that?
<infinity> fabbione : <laugh>
<fabbione> infinity: go ahead. i have no objections
<jbailey> fabbione: He's the one to blame php on... ;)
<fabbione> i know NOTTING
<sivang> seb128: pitti showed me g-v-m, it' so clean
<infinity> jbailey : die.
* jbailey collapses on the floor.
<fabbione> jbailey: yeah i know.. :P
<infinity> jbailey : I was young, foolish.. And now it's too late to give it away.
<pitti> seb128: the problem with not using it that the NNlibtoolize.patch fails to unapply
<infinity> thom : Consider it done.  It's on my TODO for the next few days.
<seb128> jdub: nop, but I could subscribe to this list too :)
<Kamion> fabbione: downloading
<pitti> seb128: I also had this problem with hal; seems to be a cdbs bug, but I circumvented it by using tarball.mk
<jbailey> pitti: What bug? =)
<fabbione> who did the last bunch of uploads like evolution-data-server and rhythmbox_0.8.8-2ubuntu1 ?
<jdub> seb128: comments from viro that may be related
<elmo> fabbione: dude, guess
<seb128> jdub: ok
<seb128> pitti: ??
<fabbione> Kamion: i really do NOT ensure anything about that kernel
<fabbione> elmo: hmmmmm thom?
<Kamion> fabbione: sure
<fabbione> ;)
<pitti> seb128: once I had a hal patch which changed libtool and autofoo files
<fabbione> Kamion: it compiles.. that's all i know
<elmo> fabbione: he-iz-one-man-gnome-army
<pitti> seb128: it applied, but after building the package it failed to unapply, i. e. debclean failed
<thom> infinity: have a look at the ubuntu packages, i'm not sure there's much difference but there may be some stuff worth stealing
<sivang> seb128: same here
<seb128> pitti: pitti oh, right, bugged debian/rules :)
<infinity> thom : Will do.
<jbailey> pitti: What occasionally happens is that at some point afterwards those files get rebuilt.
<sivang> jbailey: the cdbs .mk(s) ?
<jbailey> pitti: You have to make sure that any patching like that also includes setting maintainer-mode in the configure.ac
<pitti> jbailey: _could_ be the reason
<fabbione> seb128: isn't time to start to check the B-D of your packages?
<seb128> fabbione: what's wrong ?
<pitti> jbailey: in any case I prefer tarball.mk since it is so much cleaner and more robust
<jbailey> pitti: It's probably 75% of the suckage around relibtoolising/autoconfing.
<fabbione> seb128: both e-d-s and rhythmbox_0.8.8-2ubuntu1 fails with older versions of some libraries
<jbailey> pitti: Concur, that's why I wrote it. =)
<pitti> jbailey: you can happily mess up build-tree and experiment wihtout breaking your source
<seb128> pitti: is that a tarball in the tarball ?
<pitti> seb128: it's a tarball (the original one) in the orig.tar.gz, yes
<fabbione> seb128: and they do not enforce the B-D on the new ones
<seb128> fabbione: what versions ? rhythmbox has not changed for months
<pitti> seb128: but that's about the only drawback 
<seb128> fabbione: BTW the new rb upload is broken
<pitti> jbailey: oh, that was you? Thanks a lot for it :-)
<jbailey> pitti: dpkg purists have trouble with it, though.
<fabbione> seb128: e-d-s 1.1.4-0ubuntu1: checking for libsoup-2.2 >= 2.2.2... Requested 'libsoup-2.2 >= 2.2.2' but version of libsoup is 2.2.1
<fabbione> configure: error: Library requirements (libsoup-2.2 >= 2.2.2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
<seb128> pitti: no way to do this
<pitti> jbailey: guess what? I looked at Keybuk's dpkg V2 proposal, and it seems to do exactly that :-)
<fabbione> seb128: rb has a similar error
<seb128> fabbione: arg, I've updated it, I swear
<pitti> seb128: yeah, you need a new upstream version to do that
<fabbione> Perhaps you should add the directory containing `gstreamer-libs-0.8.pc'
<fabbione> to the PKG_CONFIG_PATH environment variable
<fabbione> No package 'gstreamer-libs-0.8' found
<fabbione> configure: error: GStreamer not found, or older than version 0.8.1
<seb128> fabbione: rb has dropped a depends that should not be dropped
<fabbione> seb128: no problem :-)
<seb128> yeah, I know about this one, debian's fault :)
<fabbione> just reporting
<jbailey> pitti: Nice!  So far in the proposal the only thing I can see being a problem is the whole idea of unpack-without-using-anything-outside-of-base.  It pretty much eliminates any helper scripts at all.
<Kamion> pitti: which is good - the thing dpkg purists like me have trouble with is that it's not in dpkg
<jbailey> pitti: Or, well, forces me to install one directly into the package. =(
<seb128> pitti: no, that's insane, I'll never do that :p
<eruin> locales broken atm?
<pitti> seb128: try it once, you'll love it :-)
<seb128> pitti: that breaks the pkg-gnome SVN usage totally, which is to have debian/ in the SVN and the upstream tarball in tarballs/ and use svn-buildpackage
<pitti> seb128: right now you have an RC BUG! *muhaha*
<seb128> pitti: no way
<eruin> I've got mine set to norwegian, but no app (but firefox) is in that language. the rest are in danish, swedish and english :P
<eruin> even more so than a few days ago
<seb128> pitti: repackaging the upstream tarball is a real pain
<seb128> pitti: atm upstream tarball == orig
<pitti> seb128: so then the package should be fixed to clean properly
<pitti> seb128: <jbailey> pitti: You have to make sure that any patching like that also includes setting maintainer-mode in the configure.ac
<pitti> sivang: ^ was that the reason for the failure?
<pitti> sivang: i. e. did it call autoreconf/autoconf/automake/whatever during build?
<seb128> pitti: agreed totally on that
<seb128> pitti: BTW gst is not a CDBS package and use dpatch
<Kamion> hm, ENOINITRD I think
<pitti> seb128: argh, dpatch
<fabbione> Kamion: humpf.. let me see again.. i am not a big fun of make-kpkg
<pitti> seb128: okay, then sorry for the disturbance
<seb128> so don't blame CDBS here :p
<seb128> np :)
<Kamion> fabbione: no, I think that's on my end
<pitti> seb128: well, I had the same error with cdbs
<seb128> I know, that happens sometime :)
<pitti> seb128: but as jbailey says, it's probably not a cdbs/dpatch bug
<fabbione> Kamion: no.. make-kpkg wants an option to build the initrd
<elmo> oh dear lord, we have an mdadm that can't start degraded raid 5 arrays in hoary
<fabbione> Kamion: ok.. deb is updated
<fabbione> elmo: thanks the debian maintainer for it
<Kamion> fabbione: hm ok
<eruin> ugh,another random X/gdm crash
<pitti> sivang: new language-support-he package (with culmus dependency) uploaded
<infinity> elmo : Is that the bug dilinger just filed?
<eruin> anyone running the very latest updates here?
<eruin> file -> open (after one or two tries) in gedit makes X restart :P
<infinity> elmo : Ahh, so it is.
<fabbione> eruin: please move these questions to #ubuntu
<pitti> Kamion: that means we can close #3723 now?
<pitti> Kamion: sorry, #3273
<elmo> infinity: yeah
<Kamion> pitti: mm, can I do one test of today's ISO first?
<Kamion> pitti: (but basically yeah)
<pitti> Kamion: okay, I leave it open for now
<pitti> no reason to hurry
<Kamion> fabbione: 2.6.11-rc2-bk3 segfaults
<fabbione> with grub or in general for other reasons?
<Kamion> with grub
<fabbione> ok
<fabbione> than there is not much that i can do
<Kamion> the desktop starts up fine, although I don't have networking (sk98lin)
<fabbione> Kamion: yes.. the sk98lin is a driver we patch
<fabbione> i didn't port all the patches
<Kamion> right
<fabbione> just used vanilla upstream
<Kamion> sadly I think this is RC for amd64, although I suppose we could work around it by forcing lilo
<fabbione> Kamion: i am digging on LKML mailing list
<Mithrandir> Kamion: lilo doesn't exist on our amd64, I'll see if I can track it down.. I guess it's compile time.
<Mithrandir> fabbione: how many patches between our .9 and .10?
<Kamion> Mithrandir: arse
<Mithrandir> Kamion: it's easy enough to build if we want it
<Kamion> Mithrandir: it's PaSed
<fabbione> Mithrandir: you mean bk changesets?
<Mithrandir> fabbione: yes
<fabbione> Mithrandir: TONS
<fabbione> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.10
<Kamion> fabbione: google hasn't been forthcoming for me
<fabbione> each entry in there is at least one changeset
<Kamion> except for that similar report on debian-amd64
* Kamion wonders how long it would take to binary-chop
<fabbione> Mithrandir: the point is that it can be a simple change somewhere in the SATA code or ide or whatever that it is absolutely unrelated to the real problem
<Kamion> I suppose I could try all the RCs to narrow it down
<fabbione> Kamion: it won't help too much
<fabbione> they usually do a huge amount of commits before rc1
<Kamion> fabbione: are you just doing a plain make-kpkg on the tree? if you tell me the command line, I can build stuff myself
<fabbione> and from there on it's only to stabilize for release
<fabbione> make-kpkg --initrd --rootcmd fakeroot kernel_image
<fabbione> inside an unpacked linux tree from vanilla
<elmo> seb128: why are you sonaming -dbg packages?
<fabbione> Kamion: you will need debian/config/amd64/amd64-generic and copy it in the tree as .config
<seb128> elmo: dh_strip --dbg-package= does that
<seb128> elmo: I'm moving from old method to dh_strip 
<sivang> pitti: I think so , how can I make sure?
<elmo> seb128: err, confused - how does dh_strip affect package name?
<seb128> elmo: you can't specificy the name, it takes the lib name and appends -dbg
<pitti> sivang: grep the g-s-t*.build log for "auto(make|conf|reconf|libtool)"
<elmo> seb128: boggle
<seb128> elmo: so libgnomeui-0 dbg is libgnomeui-0-dbg
<elmo> surely that's a bug?
<seb128> is there a problem with that naming ?
<elmo> seb128: well it's generating useless NEW delays, and is user-confusing for no good reason IMO
<pitti> sivan, others, I'm off for about three hours; a friend of mine defends his diploma, and I want to attend
<pitti> cu later
<elmo> seb128: but *shrug* if you don't care, I don't suppose I do that much either
<sivang> pitti: cool, see ya laterz 
<seb128> elmo: yeah, but that's only happening for a few packages (should be ok now)
<seb128> elmo: that's to be done once to get a sane situation after that ...
<seb128> if you don't mind just get this one in, and that's ok after that :)
<elmo> yeah, I already processed it
<seb128> ok, thanks
<tseng> ogra: ping
<jdub> tseng: would you like an endorsement? :)
<tseng> jdub: heh im doing my wiki page now, i got it wrong
<tseng> its a subtopic of the MaintainerCandidates page apperantly
<jdub> that's just zwiki being stupid
<jdub> it saves the page you created your page from
<jdub> and calls it a parent topic
<jdub> it
<jdub> it's very silly
<tseng> oh.
<jdub> i'm a subtopic of the mataro schedule
<tseng> :P
<Treenaks> jdub: well, it could be considered "smart".. but it should ask, really :)
<tseng> do I need to add another link to myself on that page, then?
<Treenaks> tseng: yes, because you could reparent yourself to some other page
<jdub> tseng: only on the CC page
<ogra> tseng pong
<fabbione> Kamion: i think i found the problem
<tseng> ogra: heya :P, doing user page now bud
<Kamion> fabbione: oh?
<jdub> tseng: well, yes, you need to be on the MC page too
<Kamion> fabbione: btw, 2.6.9 and 2.6.10-rc1 were like four days apart - are they really that different?
<ogra> i just saw you talking about , thumbs up !
<ogra> tseng^^
<fabbione> Kamion: never mind.. it's only for NUMA/acpi combinations that do not apply to -generic
<tseng> Treenaks: ah-ha! thanks.
<tseng> jdub: all finished that, I believe
<fabbione> hmm
<jdub> seb128: YAYayayayayAYAYAY!
<seb128> ?
<jdub> gnomemeeting ;)
<seb128> oh :)
<seb128> jdub: could you run your stuff to know what's outdated ?
<jdub> ok!
<seb128> thanks :)
<dholbach> re
<fabbione> elmo: sparc-utils is still in universe. is that intended or the change is still propagating?
<jdub> -platform:gnome-mime-data:2.4.1:
<jdub> +platform:gnome-mime-data:2.4.2:
<seb128> oh, right
<jdub> -platform:intltool:0.32.1:
<jdub> +platform:intltool:0.33:
<jdub> -platform:libart_lgpl:2.3.16:
<jdub> +platform:libart_lgpl:2.3.17:
<jdub> (though you just did that one, right?)
<seb128> these ones is in Debian incoming, I'm waiting for a sync
<jdub> libgnome/libgnomecanvas/libgnomeui
<jdub> ggv
<seb128> these ones are done
<jdub> gnome-speech
<seb128> ggv/gnome-speech to do so :)
<jdub> gtk-engines/gnome-themes -> pending d-g-g
<jdub> libgail-gnome
<seb128> that's yours :) (thanks again)
<jdub> dasher
<seb128> dasher has a crashed according to mjg59 
<seb128> bah, no a lot to do, cool :)
<jdub> e-d-s 1.1.4.1
<seb128> s/no/not/
<seb128> done too
<elmo> fabbione: my germinate doesn't see it
<jdub> how do we have g-s-t 1.1.90 before ftp-release-list does? :)
<elmo> ah, probably  because it's sparc specific
<elmo> hmm, this is going to be painful
<fabbione> elmo: yes.. supported -> sparc-utils [sparc] 
<elmo> hmm, no, it runs germinate for sparc
<fabbione> if it's not an issue i can just kill the [sparc]  bit
<seb128> jdub: ? g-s-t is not been updated yet, some patches need to be rewritten ...
<elmo> fabbione: no, I don't mean that, I meant i thought I wasn't running germinate for sparc arch, but I am.. checking
<jdub> oh, i am just on crack
<elmo> pitti: ?
<sivang> elmo: he's away for about 3 hours
<seb128> jdub: thanks :)
<elmo> meh
<elmo> fabbione: dude.
<elmo> fabbione: sparc-utils isn't in the archive
<fabbione> the source is..
<elmo> doesn't matter
<elmo> germinate works off Packages files - if it's not built, it can't deal with it
<fabbione> AHhhhhh
<fabbione> ok
* fabbione fixes
<sivang> tseng: my layouts are superiro? ;-)
<dholbach> /wois tseng
<dholbach> *pipe innocently*
<sivang> dholbach: huh?
<ogra> dholbach: stop whistling.... :)
* dholbach should either resort to http://www.spiegel.de/img/0,1020,429650,00.jpg or his mouse :-)
<otavio> Where I can get seeds and germinate source to take a look?
<otavio> elmo: can you provide it to me?
<Kamion> otavio: they're all in public arch archives, one sec
<Kamion> otavio: http://www.ubuntulinux.org/wiki/SeedManagement for the seeds
<Kamion> otavio: baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2004; baz get colin.watson@canonical.com--2004/germinate--mainline--0 # for germinate
<Kamion> (or tla if you don't have baz)
<otavio> Kamion: thanks a lot :-)
<ogra> tseng, you maintain nicotine ?
<Astharot> salve
<elmo> Rejected: Unknown distribution `unstable'.
<elmo> Rejected: no source found for sparc-utils 1.9-2.3 (sparc-utils_1.9-2.3_sparc.deb).
<elmo> fabbione: --^
<Astharot> is there a kind of netselect-apt for ubuntu ?
<Kamion> we don't yet have a Mirrors.masterlist file in the Debian format, which would probably kill that ...
<zul> hey ogra
<ogra> hey zul
<fabbione> elmo: that's impossible.. http://archive.ubuntu.com/ubuntu/pool/universe/s/sparc-utils/
<fabbione> the source is there
<fabbione> i just sbuilded it
<tseng> ogra: i did in gentoo
<elmo> fabbione: uh, right, could be the distribution through katie off
<tseng> ogra: barely touch the thing now, however
<fabbione> elmo: that should still allow binary uploads...
<ogra> tseng, it was my fist upload (the one of two jdub missed ;) )
<fabbione> elmo: from the buildd at least
<ogra> http://lists.ubuntu.com/archives/hoary-changes/2005-January/001727.html
<tseng> ogra: nice one
<fabbione> elmo: do you want me to reupload?
<ogra> lamont around ?
<sivang> tseng: take a look ;-)
<tseng> sivang: heh, nice one. thanks
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [-o daniels]  by daniels
<sivang> tseng: no prob, I got to know moin at least while prewarty :)
<farruinn> Kamion: ping?
<Kamion> farruinn: pong
<opi> game, set & mach
<Kamion> "match"
<farruinn> Kamion: I was told to ask you about hfs support on the install cd
<Kamion> farruinn: should already be there
<opi> Kamion, yeah, I know ;)
<farruinn> does it need to be loaded manually?
<Kamion> hm, hfs-modules is Priority: extra so maybe not
<Kamion> farruinn: one sec, I'm looking
<farruinn> thanks
<farruinn> the reason I ask is that if the install cd would allow you to mount hfs partitions it would make it easier to install on oldworld macs
<Kamion> os-prober depends on it; that ought to be sufficient to have the udeb installed automatically
<Kamion> modprobe hfs
<farruinn> ah, ok, I was wondering if it was something as simple as that
<Kamion> farruinn: nobody's written a partman-hfs component yet
<Kamion> so you won't be able to mount them from the partition manager
<farruinn> so nothing would really be accomplished by 'modprobe hfs'?
<farruinn> I mean, you can load the module but can't mount hfs partitions anyway?
<farruinn> (I don't exactly understand what you mean by partition manager - is that the partition tool or some sort of service?)
<Kamion> you can mount them from the command line
<farruinn> ok, excellent =)
<Kamion> I mean the "Partition Disks" user interface in the installer
<farruinn> ok, that's what I was thinking but wasn't sure
<farruinn> thanks for dealing with my ignorance =)
<Kamion> np
<Kamion> let me know if it fails
<dilinger> infinity: recovering raid5 arrays if 1 drive dies is overrated, anyways
<daniels> mdz: ping
<farruinn> Kamion: I booted into the install cd, tried a modprobe hfs but it said "no module found".  The only things in /lib/modules/2.6.8.1-3-powerpc/kernel/fs were isofs and nls
<Kamion> farruinn: don't try that right at the very start
<Kamion> farruinn: you have to run through the interface at least past retrieving installer components (or whatever the step is called)
<stuNNed> PLEASE offer galeon as alternative to web browser, Ximian does it, and although i like firefox it crashes a good bit, the backported version of 1.0 to warty
<farruinn> Kamion: ok, I'll try again this afternoon
<ogra> stuNNed: the backported version is neither supported nor tested by us
<tseng> stuNNed: how about epiphany-browser
<stuNNed> ogra: why isn't galeon in multiverse or universe? :(
<ogra> stuNNed: in fact it will break the upgradeability of your system badly (all backports that is)
<ogra> stuNNed: it was unmaintained and broken when warty released
<stuNNed> tseng: epiphany is ok but really just doesn't have as many gui options as galeon has and to be honest i've been using galeon for the past 5 years and know it a bit more
<stuNNed> so just use something like checkinstall to install galeon deb?
<stuNNed> which i'd rather not do...
<tseng> galeon 1.3.19 is in hoary, btw
<stuNNed> aahhhh.... :D
<tseng> so this will be solved in next release
<stuNNed> that's all i need to know, in the meantime, i'll make my own debs or just install from source, thanks :D
<tseng> it could use a rebuild against firefox-dev it looks like
<tseng> depends on mozilla-browser still
<Mithrandir> tseng: why aren't you a MOTU yet? :)
<tseng> Mithrandir: im on the list now dude :)
<thom> tseng: *shrug* it's in universe :-)
<ogra> Mithrandir: tuesday ;)
<Mithrandir> tseng: ah, ok.
<seb128> elmo: gnome-gv and gnome-speech syncs please
<seb128> elmo: libgnomesu too
<elmo> seb128: done
<seb128> thanks
<fabbione> elmo: do you want me to reupload sparc-utils?
<elmo> fabbione: sure, with the right distro
<fabbione> elmo: it doesn't have any hoary changes.. it's just builded as i am building universe and other packages
<elmo> fabbione: eh?  sure, but the Distribution: line in the .changes still needs to say 'hoary', not 'unstable'
<elmo> that's why it got confused about the source  not existing, it was looking for the source in the 'unstable' suite, which obviously doesn't exist
<fabbione> ahhhh ok
<fabbione> well i guess i can just edit the changes and resign them, right?
<elmo> yeah
<fabbione> there... done
<fabbione> ah here is another one we forgot...
* fabbione updates the seeds
<fabbione> Kamion: i need to add genromfs that is required to build d-i, what is the best seed for it?
<elmo> if it's a b-d of d-i, you shouldn't need to?
<fabbione> elmo: it's one that is downloaded at build time
<elmo> it's also a build-depends
<elmo> once the sparc binary gets into the archive, it'll get auto-seeded
<fabbione> right...
<fabbione> elmo: sorry if i appear silly.. all this seeds <-> archive interaction still hides some black corner cases in my head :-)
<fabbione> and not knowing all the secret details of archive management makes some stuff more difficult for me to understand..
<fabbione> but stuff is getting clear (slowly ;))
<fabbione> there... this should be enough....
<jbailey> Kamion: If you're using hotplug in d-i instead of discover, how are you handling detection of ISA/EISA devices?
<Kamion> I didn't think d-i used discover for ISA detection anyway
<Kamion>                 discover --format="%m:%V %M\n" --disable-all \
<Kamion>                           --enable=pci,ide,scsi${sbus},pcmcia ide scsi cdrom ethernet bridge |
<lamont> fabbione: ack
<lamont> Kamion: gnupg should _NOT_ be in hoary.buildd
<lamont> ogra: ack
<Mithrandir> Kamion: I don't think discover does ISA discovery anyhow
<jbailey> Mithrandir: The man page says that isa is a recognised bus.
<Mithrandir> that doesn't mean it actually _does_ anything with it.  :)
<Mithrandir> you can't really detect stuff on ISA in any sane way.
<pitti> sivang: I'm back
<mvo_> pitti: how was the presentation?
<pitti> mvo_: well, I did not understand most of it
<pitti> mvo_: "High-speed in-circuit debugging of the ARM9TDMI processor code"
<pitti> mvo_: I have a major in theoretical computer science...
<mvo_> pitti: heh
<seb128> pitti: that's probably good time to update the language packs now :)
<pitti> seb128: okay :-)
<pitti> seb128: btw, it does not matter anyway
<pitti> seb128: I can't extract the new translations, they are already stripped
<pitti> seb128: so maybe I wait a little longer, then I can already get the stuff from lamont
<pitti> lamont: here?
<ogra> lamont: i got a bugreport for libgtksourceview-cil and try to rebuild....but there seems to be no mono-utils available, even the logs say it built...
<tseng> ogra: i have mono-utils here..
<ogra> tseng: i suspected this ;) , but i want to know why its not in universe if it was built successfull as the logs say...
<tseng> i see it in universe
<tseng> Get:1 http://archive.ubuntu.com hoary/universe mono-utils 1.0.4-1 [528kB] 
<tseng> Fetched 528kB in 4s (125kB/s) 
<ogra> huh ?
* tseng nods sagely
<sivang> does anybody know how are we ert plone updates from debina?
<sivang> errr debian
<whiprush> ogra: is there a MOTU channel or list?
<sivang> (I have someone on the country team asking)
<thom> ogra: i386 only for mono-utils, i'd bet
<thom> i don't think it built anywhere else
<ogra> thom: lol dumb me...
<ogra> thom: amd64 here ;)
<thom> yeah
<ogra> thanks
<thom> the lack of tomboy on amd64 is seriously annoying me
<thom> i may do something about it soon
<Kamion> lamont: why the emphasis?
<ogra> whiprush: not yet...if you are interested, haggai or me are the guys to talk to
<lamont> thom: mono's lack of buildability is kinda annoying me...
<lamont> Kamion: dunno...  but it shouldn't be there
<lamont> anything in hoary.buildd is defacto build-essential, and gnupg and it's dependencies shouldn't be.
<Kamion> lamont: doesn't apt throw a wobbly nowadays if it can't verify signatures?
<whiprush> ok, it'd be swell if there was a place to ask stupid questions without clogging up in here.
<ogra> lamont: we got tsen aborard soon ;) this will change i guess..
<Kamion> lamont: that's what somebody said was happening in pbuilder ...
<ogra> whiprush: currently i'd like to keep it in here, because here are more experienced devs to look over my stupid answers ;)
<whiprush> k
<azeem> Kamion: the buildds don't use apt in the chroot though, AFAIK
<ogra> whiprush: but for the uture a channel would be fine :)
<ogra> future even
<whiprush> is pbuilder the preferred tool for chroots?
<lamont> Kamion: apt is run outside the chroot
<lamont> whiprush: it's not what the buildd's use
<whiprush> k
<ogra> whiprush: there are some hints if you follow he links on this page: http://www.ubuntulinux.org/wiki/MOTURecruitment
<ogra> argh...why is the chroot page this cluttered suddenly...? could someone look at it, it seems a bit overloaded....(sudo cp /etc/shadow chroot/etc/ ??)
<Kamion> lamont: ah
<lamont> Kamion: the choices are (1) install gnupg, (2) run apt --allow-unauthenticated, or (3) run apt outside the chroot (which sbuild has done since time immemorial)...  we picked (3)
<Kamion> lamont: makes life interesting for supporting pbuilder though
<stratus> daniels, ping
* lamont goes to look at the chroot page
<ogra> lamont: thanks...
<tseng> ogra: we also need to figure out what needs done to get libdbus-cil built
<tseng> it builds here, i think it may just need a reupload
<tseng> or missing a build-dep
<tseng> its needed for the new tomboy, blam, and beagle
<lamont> lets see.. it's missing dev/pts, which is required for at least some packages to build
<sivang> erm..
<sivang> The following packages have unmet dependencies:
<sivang>   plone: Depends: zope-cmfplone (= 2.0.4-2) but it is not going to be installed
<lamont> ogra: the buildd chroots do this:
<lamont>     f=${root}/etc/passwd; grep -q "^${U}:" $f || getent passwd ${U} >> $f
<lamont>     f=${root}/etc/group; grep -q "^buildd:" $f || getent group buildd >> $f
<lamont>     f=${root}/etc/shadow; grep -q "^${U}:" $f || echo ${U}:\*:$(getent shadow ${U} | cut -d: -f3-9) >> $f
* lamont edits the page
<thom> http://www.clearairturbulence.org/netapplet-tehappletedition.png
<thom> PHEAR
<whiprush> ogra: ok, I'd like to sign up. I've never done packaging before but I've been reading the documentation and practicing with my own repo.
<tseng> thom: i kinda think netapplet is the cause of my network dropping randomly of late
<tseng> thom: ive removed it and have been fine since
<thom> tseng: hrm, interesting
<tseng> ipw2200
<thom> i need to do more playing on my laptop
<tseng> im imagining it may have somethign to do w/ the fact that it cant seem to get a signal reading from it
<ogra> whiprush: thats a great start....add yourself to the MaintainerCandidates page .....get a gpg key....
<tseng> shows as a big 0
<whiprush> on it
<thom> oh, that's a definite possibility then
<thom> tseng: hrm, i'll finish this up and then might well ask you for some debug info
<tseng> gnome-netstatus can read it fine
<tseng> thom: sure
<tseng> it might be related to ipw2200 having no rfmon
<thom> yeah, ipw2*00 changed their format recently air
<tseng> im not sure how it calculated it
<tseng> in netapplet
<tritium> isn't orinoco_cs driver now patches to allow putting it in monitor mode?
<lamont> WTH does he want /tmp bind mounted into the chroot?
<tritium> patched
<ogra> heh
<ogra> lamont: thank you, looks a lot saner now...
<lamont> ogra: of course, now you can't run sudo in the chroot..., but that's a good thing, if you ask me...
<ogra> :)
<lamont> the buildd's bind mount /home/buildd/.ccache, proc, devpts, and nothing else
<azeem> lamont: s/deboostrap/debootstrap/ on DebootstrapChroot
<ogra> so probably drop the other stuff
<lamont> azeem: gash!
<pitti> lamont: any chance that I get the stripped translation tarballs?
<pitti> lamont: I'd like to build a current set of langpacks
<lamont> pitti: growing them all together it todays only project.  If you can wait a few hours, I'll have ~lamont/translations up and happy.. If not, I can duplicate all the work and manually copy everything into place...
<ogra> gah, xkb is really broken on my lappie....couldnt type again...
<pitti> lamont: no, a few hours is okay
<pitti> lamont: building the packs tomorrow is perfect
<ogra> lamont: also mounting /home in the chroot seems a bit silly (at least me runs the chroot below home, dunno how others do it though)
<lamont> ogra: /home is a convenience for the users, gives them a trivial way to access stuff inside the chroot, etc.
* lamont goes heads down for a while...
<ogra> driving home.....later....
<elmo> does anyone know off hand where the regex for generating Closes: is in the dpkg-dev scripts?
<elmo> ah, nm, found it
<Kamion> daniels: has anyone mentioned yet that the latest l-r-m failed to build on i386?
* Kamion is wondering why 'modprobe prism2_usb' fails with linux-image-2.6.10-2-386 2.6.10-10 and linux-restricted-modules-2.6.10-2-386 2.6.10.2-2
<elmo> whats' $& in perl and which of the perl manpages is that kind of thing defined in?
<Mithrandir> perlvar
<stratus> perlop?
* stratus hides
<Mithrandir>        $&      The string matched by the last successful pattern match (not
<Mithrandir>                counting any matches hidden within a BLOCK or eval() enclosed
<Mithrandir>                by the current BLOCK).  (Mnemonic: like & in some editors.)
<Mithrandir>                This variable is read-only and dynamically scoped to the cur-
<elmo> Mithrandir: cheers
<Mithrandir>                rent BLOCK.
<elmo> god my perl2python skillz have so attrophied
<Mithrandir> it makes all regexes a fair bit slower, though, so it should be avoided.
<seb128> elmo: could you get gazpacho in universe from debian (we don't have it atm) ?
<smurfix> elmo: a friend of mine once wrote a translator
<elmo> seb128: err, upstream version freeze means no new packages are being imported.. or is it a gnome thing?
<elmo> smurfix: run away
<smurfix> elmo: yep, especially from http://www.crazy-compilers.com/bridgekeeper/
<smurfix> (that domain name should give one a clue or two ;-)
<seb128> elmo: that's a gnome/python stuff, but not part of the desktop. I'll mail Matt/Jeff to ask with you in the Cc:, ok ?
<elmo> seb128: yep, cool, thanks
<smurfix> gah, the thing was opensource last time I looked. :-(
<kagou> hi
<kagou> is there repository for old packages ?
<tseng> hm?
<zul> kagou, morgue.ubuntulinux.org
<kagou> thanks zul 
<tseng> oh, old versions
<elmo> that so needs an index
<mdz> daniels: pong
<thom> i think he's thoroughly asleep by now
<mdz> pitti: pong
<mdz> ajmitch: yes, we have been dropping python 2.2 and 2.1 support over the past couple of weeks
<mdz> morning
<thom> good morning
* pitti scratches his head, wondering what he wanted to ask mdz
<pitti> Hi mdz!
<pitti> mdz: it was probably about the evo security update, I mailed
* thom happy dances at working netapplet
<mdz> ok, catching up on mail
<pitti> guys, has anybody of you ever tried DVD-RAM?
<pitti> I just bought a DVD-RAM drive and tried writing on it, but it's slooow...
<dholbach> pitti: only under winbloze, and it was DAMN slow too
<Treenaks> pitti: at what speed?
<tseng> i have a dvd+-rw
<pitti> I only get about 1.5MB/s
<Treenaks> pitti: wow.. that'll burn a DVD in a day
<pitti> no, wrong
<pitti> 1.5 MB/min
<jdz_> oh man.. ouch.
<mdz> pitti: I have a DVD-RAM/-RW/+RW drive
<pitti> Treenaks: well, so far I also tried CD-RW, and that is fast
<T-Bone> pitti: i have a DVD-RAM here. And yes it's slow. ;)
<mdz> pitti: I use DVD+RW media in it, and it works very well
<pitti> Treenaks: but packet writing is a pain
<pitti> oh, wait
<pitti> maybe it was because of pmount's sync mounting...
<mdz> pitti: the disc isn't mounted for burning
<mdz> it writes directly to the block device
<mdz> pitti, daniels: I'm getting mangled emails from you via ubuntu-devevl
<mdz> devel
<mdz> oh, eek
<lamont> I assume t here's a nice python module that will take 'key: value' pairs and produce a dictionary from same...  what's it called?
<mdz> they're going from you, to the list, out to some subscriber, who is mangling them and sending back to the list
<pitti> yay!"
<mdz> lamont: the 'dict' object does that itself
<mdz> lamont: dict(sequence of x,y) -> dictionary of x: y
<pitti> now it's much faster, using async and noatime :-)
<mdz> pitti: oh, you are using it for a writable filesystem? I have not tried that yet
<pitti> mdz: what is mangled?
<pitti> mdz: DVD-RAM, yes
<mdz> pitti: never mind, it is a subscriber mangling the mails
<pitti> mdz: now it's very nice
<pitti> mdz: yes, I also saw that list. Looks like a bounce
<lamont> mdz: I have ["a:b","c:d"]  and want {'a':'b','c':'d'} ... off to study dict...
<mdz> I have not seen dvd+ram media around; how much do they cost compared to dvd+rw?
<pitti> mdz: you format it with mkudffs, then all the Utopia hotplugging stuff instantly works
<pitti> mdz: I payed  5.90 for one 4.7 GB disc
<mdz> wow, that is a lot
<pitti> mdz: about $7 maybe
<pitti> mdz: yes, it is
<pitti> mdz: but they are said to be _very_ reliable
<mdz> I bought 10 DVD+RW for $20
<pitti> mdz: they aren't for giving to friends 
<mdz> and I have written some of them perhaps 50 or 100 times
<pitti> mdz: they are for reliable backup
* pitti already found a lot of broken CD-R[W] s
<mdz> it is difficult for me to trust optical media for backups :-)
<mdz> pitti: yes, likewise
<pitti> mdz: these things come in a cartridge, so it's protected a little better
<mdz> pitti: I bought 10 CD-RW, and they all failed within a few weeks
<mdz> they came in jewel cases
<mdz> so now I only buy DVD+RW
<pitti> mdz: +rw is better than -rw?
<mdz> also, I enjoy not using cdrecord anymore
<pitti> I bought a bunch of dvd+r media for playing with, too
<mdz> pitti: I have not tried -rw, but having found something which works very well for me, I am happy
<pitti> cool
<pitti> I don't really look through this format jungle
<pitti> mdz: can you do packet writing with cd+rw?
<mdz> yes, it is silly how many formats there are
<pitti> mdz: dvd+rw, I mean
<mdz> pitti: I don't know; I prefer to ignore CD formats
<mdz> ah
<mdz> I don't know
<pitti> I find it difficult to accumulate 4.7 GB of data and write it in one chunk
<pitti> right now I backup my foto collection and I want to do incremental backup
<jdz_> lamont: something like this? dict([stringX.split(":") for stringX in listY] )
<lamont> mdz: doesn't look like dict() will do what I want...
<lamont> jdz_: that assumes exactly one : in each line (which is not true), but yeah, something like that...
<mdz> lamont: I didn't realize you meant you had strings, rather than pairs (tuples)
<mdz> probably easiest would be:
<mdz> for pair in ['a:b', 'c:d'] : key, value = pair.split(':'); mydict[key]  = value
<smurfix> pitti: if you don't finalize the thing you can append to an existing isofs
<smurfix> ... or just build the file system while burning it
<lamont> mdz: again, assumes exactly one ':' per value...
<jdz_> lamont: I don't believe there's a function to do that already; you may have to add a filter to remove extra ":"'s
<pitti> smurfix: maybe; however, I think packet writing finally found its way into 2.6.10
<lamont> jdz_: sigh
<lamont> ok
<smurfix> pitti: sure, but still -- anyone can read isofs. I wouldn't be so sure about packet-written CDs
<mdz> lamont: you have things like 'a:b:c' and want 'a' and 'b:c'?
<lamont> hrm... that would work with ': ' as the delimiter....
<mdz> lamont: if so, use pair.split(':', 1)
<lamont> mdz: ah, cool
<pitti> smurfix: hmm, packet writing is already soooo old, windows can do it for ages
<pitti> smurfix: and it just uses UDF
<pitti> smurfix: so I guess that should be no problem
<T-Bone> fabbione: ping?
<mdz> Kamion: I'd like to do a new d-i build with the new casper-check
<mdz> Kamion: do you want to give it a quick eyeball and see if it looks reasonable to you?
<mdz> it seems to work
<metalikop> I recently upgraded to 2.1.4 and I'm getting some odd IMAP errors
<metalikop> IMAP4 server mail.somesite.com unexpectedly disconnected: Invalid argument.
<metalikop> upgraded _Evolution_ to 2.1.4
<metalikop> Unexpected token in response from IMAP server mail.somesite.com: .
<tseng> metalikop: sounds like an #ubuntu question
<metalikop> possibly, except i'm running hoary so I thought this'd be the best place.
<tseng> no, this is -devel as in development questions, not support on the development branch
<tseng> thats in #ubuntu, ubuntu-users ml and bugzilla
<metalikop> doh!
<metalikop> my bad :(
<tseng> no biggy, just for reference.
<metalikop> would this be a bad time to ask about libmultisync-plugin-evolution?
<tseng> well i cant help you with it, I use gnome pilot
<metalikop> has some dependency issues with libe*1.2-0 (>=1.1.1)
* tseng looks
<tseng> you're quite right, have you grabbed the source and tried to fix?
<metalikop> not yet, I'll give that a shot
<tseng> it looks like this is another one of those buggers that needs rebuilt against each new e-d-s upload =/
<metalikop> indeed
<tseng> apt-get source l-m-e
<tseng> cd l-m-e/debian
<tseng> edit control to the latest build-deps
<tseng> cd .. ; dpkg-buildpkg -rfakeroot
<tseng> install the resulting deb in the parent dir
<tseng> if that works, report back :)
<tseng> (thats the kind of discussion that is appropriate here btw)
<tseng> good luck.
<metalikop> thx
<tseng> may need to do an apt-get build-deps l-m-e on that as well
<tseng> to install dependencies.
<dholbach> tseng: gnome-launch-box will be / is such a bugger too :-)
<T-Bone> gah, still the same failure on ubuntu-base on ia64 :(
* T-Bone wonders WTH: chroot target apt-get -f install solved the issue :P
<tseng> dholbach: gorss
<tseng> *gross
<dholbach> tseng: what's gross? e-d-s dependency heck?
<dholbach> :-)
<tseng> yeah
<mdz> lamont: what time of day does the daily d-i build run?
<mdz> I think I need an additional one
<dholbach> tseng: i guess their api will settle down at some stage :-)
<tseng> dholbach: hopefully.
<dholbach> btw: seb128: i get a floating point exception with evoluation (on AMD64) now too - maybe the  glb  (gnome-launch-box) exception has the same origin
<dholbach> s/evoluation/evolution
<Treenaks> eovulation?
<Treenaks> (is that like mencal implemented inside of evolution?)
<mako> mdz: woot, one of the guys from the solid arab font groups uses ubuntu and can help us with arabic bugs/support
<mdz> mako: nice
<T-Bone> Kamion, lamont: i'll some advice whenever possible ;P
<mako> i'm doublechecking but i think we can close 5330
<dholbach> Treenaks: :-)
<Treenaks> dholbach: if mencal exported icalendar files it could work
<Treenaks> dholbach: anyway...
<dholbach> dholbach: sorry, i don't really know about mencal
* dholbach grabs his head
<dholbach> Treenaks: sorry, i don't know, what mencal is about - i just mispelled evolution and wanted to state it was broken at my place :-)
<Treenaks> dholbach: apt-cache show mencal
<Treenaks> dholbach: or ask amaya :)
<dholbach> Treenaks: HAHA :-)
<metalikop> tseng: you have a second?
<tseng> metalikop: ok.
<metalikop> mind if I pm you?
<metalikop> it's okay to say no, I'll probably only be an annoyance anyways
<seb128> dholbach: if you know how to fix it let me know, I work on i386 not amd64 ...
<tseng> metalikop: go ahead
<dholbach> well guys, i'm off - got a learning meeting tonight :-(
<dholbach> *wave*
<fabbione> elmo: ping?
<fabbione> T-Bone: pong
<elmo> fabbione: yah?
<fabbione> elmo: remember a while ago i was mentioning quinndiff not catching all the Packages to build? i got the same problem again on the same package
<fabbione> elmo: what did i need to send to you?
<elmo> Packages, Sources and your Packages-Arch-Specific
<fabbione> elmo: ok
<fabbione> ARGH
<fabbione> ok
<fabbione> it's listed in the PAS
<fabbione> i wonder why....
<elmo> what pkg/
<fabbione> the reason is *cough*stupid*cough*
<T-Bone> fabbione: any good reason not to enable altivec support in power4 kernels?
<fabbione> ddetect
<fabbione> T-Bone: what is altivec?
<T-Bone> doh
<elmo> fabbione: like MMX and SSE
<elmo> for powerpc
<fabbione> i don't have a ppc
<elmo> fabbione: ddetect isn't in current Debian p-a-s?
<fabbione> i don't know.. i got the configs from Herbert
<fabbione> elmo: i got the PAS that is around the DC
<fabbione> at least the one that is packaged
<elmo> fabbione: christ knows where's that from, it's not what's on jackass
<T-Bone> fabbione: http://www.apple.com/g5processor/executioncore.html
<elmo> we use debian +custom entries for our ubuntu-specific packages
<fabbione> elmo: from lamont pkgs?
<elmo> you'd be much better with current Debian 
<elmo> fabbione: yeah
<T-Bone> fabbione: altivec is roughly a CPU extension that computes vectorized instructions
<T-Bone> fabbione: in other words, it the stuff that makes the CPU rock
<T-Bone> fabbione: so you really want it enabled by default
<fabbione> T-Bone: ok, please file a bug.. and add zul in CC
<stratus> it seems that altivec is like sse2 on p4 cpus
<elmo> t-bone: assuming all machines power4 kernels work on have it
<elmo> and/or the kernel doesn't crash if you enable it on such a machine
<T-Bone> elmo: that's what i'm not sure of, hence my first question
<fabbione> elmo: ok.. so can you handle me a decent PAS for sparc?
<zul> fabbione: eh?
<fabbione> T-Bone: ok, than please investigate
<fabbione> zul: kernel config allignment? ;)
<zul> fabbione: ah
<elmo> fabbione: as I said Debian's is fine, but people.u.c/~james/ has what's on jackass
<T-Bone> fabbione: well, hand me a R6000 and i'll tell you ;P
<T-Bone> fabbione: i think benh would know. better ask him
<fabbione> elmo: thanks
<fabbione> T-Bone: ok, please investigate and let me know :-)
<T-Bone> ;P
* T-Bone rebuilds his kernels anyway, can't stand initrds
<fabbione> elmo: yeah.. that did it apparently
<fabbione> i am off to cook dinner
<fabbione> later 
* T-Bone is off for dinner too
* lamont surfaces
* Treenaks increases the pressure a bit
<Treenaks> hi lamont :)
<lamont> mdz: around?
<tseng> can anyone reupload multisync?
<mdz> lamont: yep
<mdz> lamont: elmo has set of the d-i builds for me
<tseng> it needs a rebuild against e-d-s
<lamont> mdz: if you want to toss me an ssh public key, I'll send you back a command that will let you trigger DI & liveCD builds anytime you want...
<lamont> pitti: around?
<azeem> tseng: I wanted to bug ogra about it
<tseng> azeem: ya..
<lamont> pitti: http://people.ubuntu.com/~lamont/translations
<mdz> lamont: sent
<ogra> tseng, azeem: only libmultisync-plugin-evolution ?
<tseng> ogra: thats one binary from the multisync source
<tseng> ogra: i imagine you'll need to do the whole thing
<ogra> yeah, Source: multisync
<azeem> yeah
<ogra> tseng: can you test it ? i only have ipaqs with linux on them :-P
<tseng> ogra: metalikop did a test build
<tseng> ipaqs?
<azeem> tseng: of the latest package in unstable?
<tseng> in hoary
<ogra> tseng: way old pieces (first generation.....) bought but nearly never used them....silly but true :)
<tseng> i had him do an apt-get build-dep ; dpkg-buildpkg and test the results
<tseng> i dont have any hardware to sync to
<azeem> well, I was going to suggest syncing with unstable, the maintainer has resurfaced and improved the syncml support considerably
<ogra> tseng: i thought you are using it...
<tseng> nosir, i was helping someone else who wondered why it was uninstallable
<elmo> smurfix: ?
<smurfix> yep
<ogra> azeem, tseng: then its better to poke elmo to sync i think....which will initiate a rebuild anyway
<elmo>  adelie.ubuntu.c 193.79.237.14    2 u  929 1024  377    0.235  1403.18 1403.51
<tseng> sounds like a good plan.
<elmo> smurfix: I've got one machine where ntp is showing that, but adelie itself is fine, and none of the other 40 machines syncing with adelie are having problems.. ever seen that kind of thing?
<elmo> (specifically the 1403 jitter)
<elmo> the machine itself is completely idle
<azeem> ogra: I'll see whether it builds fine and then mail you/elmo
<ogra> azeem: great, thanks .... (btw. ubuntu hoary ??)
<smurfix> elmo: anyhing special about that box -- kenrle verson, etwork adapter, ..?
<smurfix> kernel
<ogra>  /hoary/hurd/
<ogra> gah
<elmo> smurfix: nope, it's almost identical to about 15 of the other 40 machines that sync with adelie and aren't showing the same thing
<elmo> meh, and it's gone now
<elmo> nothing helpful in syslog - will the /var/log/ntp stuff be at all useful?
<smurfix> elmo: I assume that standard ping, tracepath, and whatnot all show absolutely zero variance in ping time et al.?
<elmo> smurfix: it's GB LAN :)
<elmo> anyway, don't worry now that it's gone.. if it comes back I'll check out ping etc.
<smurfix> elmo: So? I've seen a boy where that happened too, turned out that the interrupt router to the second network card was shot
<elmo> it made my nagios cry is all
<smurfix> elmo: i.e. it would work perfectly whenever I logged in through the first card and started tcpdumping ;-)
<smurfix> elmo: did you have time to do something about the stupid orig.tgz problem?
<elmo> smurfix: yeah, I msged you?
<azeem> ogra: dunno
<ogra> azeem: i thought you are a hurd guy ....
<azeem> yeah, but I'm a Ph.D. student as well ;)
<smurfix> elmo: ... which got lost. (I hate IRCing from behind firewalls.)
<smurfix> (esp. ones which habitually disregard keepalives and other niceties.)
<elmo> smurfix: ah, well, I just said "fixed" :)
<smurfix> elmo: Thanks -- did you feed the file into the pool or should I upload a -3 version?
<elmo> upload a -3 pls, I'm interested to see if it works :)
<elmo> if it doesn't, I'll just poolify it manually but I hate doing that
<smurfix> elmo: OK, sent, will tell you what the mails say.
<lamont> mdz: sent
<lamont> mdz: note that I just added the mutual exclusion, so the builds that elmo launched for you won't stop you from trashing yourself if they haven't finished...
<whiprush> ogra: ok, I'm all set up on the wiki, ready to do this MOTU thing.
<elmo> lamont: they finished already
<lamont> woot
<mdz> yeah, I just need to wait for an rsync slot to open up now so I can actually download them
<ogra> whiprush: cool :)
<ogra> whiprush: chi Jorge, i'm Oli
<ogra>  /chi/hi/
<lamont> mdz: while ! rsync ... ; do sleep 1; done :-)
<mdz> yeah
<mdz> sleep 5 ;-)
<whiprush> ogra: rock, now what do I do?
<ogra> pitti: ping...
<jdub> GO WHIPRUSH GO!
<whiprush> Would something like thoggen be a good "starter" package?
<ogra> whiprush: thoggen ?
<whiprush> it's that gstreamer ripper/encoder thing for DVDs.
<mvo_> whiprush: I talked with the author and he does not feel that it's quite ready yet
<mdz> lamont: thanks for the scriptage; I'll try it out the next time I need a full set of stuff
<mdz> yay, rsync let me in
<ogra> whiprush: hmm, i thought about packaging this one, but since i got sucked in by the MOTU thing i'm running out of time.... http://s1x.homelinux.net/projects/serpentine <-- could make you quite famous....
<mvo_> beside that thogen is a nice package, it even has a debian directory :) (also it needs some love)
<lamont> mdz: glad to be able to go to bed while you pull an all-nighter... :-)
<mdz> please test the current daily-live/current/ ; if it's good, it is going to go out as a live CD milestone release
<whiprush> ogra: sure, I can do that. any other recommendations?
<Kamion> mdz: did you get that d-i rebuild? I was out at dinner
* jdub rsyncs livecd
* mvo_ download the livecd
<ogra> whiprush: dont make it to hard for yourself, start with something small :)
<whiprush> okey
<mdz> Kamion: yep
<mdz> Kamion: and lamont also set it up so that they can be triggered remotely
<jdub> mdz: max connections reached :)
<Kamion> mdz: hey, rock
<mdz> Kamion: your key should probably be added to the auth for that
<mdz> jdub: just keep trying
<Kamion> yes please
<mdz> lamont: ^^
* lamont waits for rsync to let him in...
<lamont> Kamion: key please
<jdub> haha
<ogra> oh, new live cd....
<jdub> @ERROR: max connections (15) reached - try again later
<jdub> ...
<jdub> @ERROR: max connections (25) reached - try again later
<lamont> or I could gen a new one for you...
<jdub> ...
* ogra takes the iso....
<mdz> jdub: it's round-robin on two servers now
<mdz> and they're both full
<jdub> awesome ;)
<jdub> and bad
<jdub> but mostly awesome
<ogra> lol
<lamont> need to enhance bittorrent to do hashes so we could seed the file... :-)
<mdz> hmm, actually
<mdz> thom: if this live build goes out as a milestone, I'm going to want torrents
<mdz> thom: is that doable?
<Kamion> I know the magic to do the torrents little-side
<mdz> ok
<mdz> and the other bit is the tracker/seeding?
<mdz> that's it, I can't take it anymore
<mdz> I'm patching the beeping out of growisofs
<mdz> it beeps 5 times every time I write a disc
<ogra> whiprush: i just see, your key isnt signed by anybody.....you will need a signature...
<mdz> unless you specify this undocumented 20-character option
<smurfix> mdz: ouch
<thom> mdz: yeah, i can kick the tracker
<lamont> mdz: on that ssh... you'll need to be buildd on the remote end, of course... :-)
<mdz> lamont: added "User buildd" to .ssh/config
<mdz> thom: awesome, thanks
<Kamion> lamont: you have /msg, in case you didn't see
<whiprush> ogra: yeah, I'm pretty new. :)
<lamont> yeah - just sending you email Kamion 
<Kamion> ok, thanks
<ogra> whiprush: do you know anybody with a vlid signed key who could sign yours ? or a local LUG near you ?
<smurfix> Or you could check with biglumber
<whiprush> yeah this is a new key, I'll have that fixed soon.
<ogra> whiprush: great :) 
* mdz boots the powerpc in order to eject the CD
<lamont> Kamion: sent
<pitti> lamont: grrrrreat!
<ogra> pitti: hi
<pitti> ogra: pong. Sorry, was phoning with gf :-)
<ogra> pitti: is it intentional that vim-gtk isnt available on warty-security ? someone asked in #ubuntu-de before....
<pitti> lamont: what does buildd-status contain exactly?
<Kamion>    vim-gtk | 1:6.3-025+1ubuntu2.2 | warty-security/universe | amd64, i386, powerpc
<pitti> lamont: always the latest directory with stripped stuff?
<lamont> pitti: that's the translations since I turned on stripping - please tell me that version 5 didn't turn it back off.. :-)
<ogra> Kamion: universe ? 
<lamont> pitti: for each of the buildd's, it contains the name of the last directory that I walked
<Kamion> ogra: yes
<lamont> pitti: last successfully walked, that is...  oops.
* lamont should fix that...
<ogra> Kamion: strange....i thought it was in main...
<mdz> pitti: do you intend to allow pmount to unmount by directory, rather than only by device?
<Kamion> ogra: nope, vim-gnome is, vim-gtk isn't
<ogra> heh, ok
<Kamion> ogra: see also bug #3599
<ogra> so the guy was missing  warty-security/universe in his sources list then...
<pitti> lamont: that means the directory will change every day?
<Kamion> ogra: yes, as that bug says we accidentally shipped warty without warty-security/universe in sources.list
<pitti> lamont: or, rather, every day gets its own directory?
<ogra> Kamion: ah, got it... thanks :)
<pitti> mdz: if it's easy and robust to map it to a device, I could do that
<pitti> mdz: I'm in the middle of producing a new upstream version anyway, so now is in fact a good time to do that :-)
<Kamion> lamont: excellent, scripted, thanks
<ogra> whiprush: i just see you are interested in ltsp.....thats probably a good startpoint too....
<lamont> Kamion: yeah, and I even fixed the user name on your copy. :-)
<lamont> pitti: so it now only updates the last date ran (in buildd-status) when it successfully walks said tree. :-)
<ogra> mdz: obnoxious beeping ? http://www.dina.dk/~abraham/religion/vi-music
<ogra> :)
<mdz> gah
<mdz> Kamion: this liev CD doesn't have any of my d-i modifications
<mdz> Kamion: was the DI_TYPE switch flipped the wrong way or something?
<mdz> Kamion: it does have the isolinux fix, though
<mdz> gah, it didn't get mirrored
<mdz> elmo: ?
<mdz> I just re-ran anonftpsync manually, and it still isn't showing up
<smurfix> elmo: ENOWAY. "ignoring ntp_4.2.0a+stable.orig.tar.gz, since it's already in the archive". I'm afraid you'll have to manually move the beast.
<whiprush> ogra: yeah I'm in the same lug as jim mcquillan, we've talked about ubuntu/ltsp stuff in the past.
<ajmitch> morning people
<ajmitch> ogra: I saw you mention ubuntu hurd, going to work on it? ;)
<smurfix> ajmitch: my timezone says you're two hours early with that greeting. ;-)
<ajmitch> smurfix: sorry, it's thursday morning here :)
<ajmitch> we just have to wait for the rest of the world to catch up
<ogra> ajmitch: no time for such games....we'll have to wait until azeem has made his diploma *g*
<thom> you australians have to be ahead at something i guess... ;-)
<ajmitch> thom: pfft, I'm in NZ, not that other place
<thom> heh, you need even more help then ;=)
<ajmitch> we're not an australian state yet!
<ogra> thom: nah, if they would be ahead, they would know how to drive on the correct side of the road....
* ogra ducks
<ajmitch> ogra: recruited any other MOTUs?
<ogra>  ajmitch, whiprush is on his way :)
<ajmitch> great, soon it'll be down to only 3000 packages each :)
<ogra> yay :-D
<lamont> smurfix: what are you trying to do with ntp?
<thom> hey lamont, know much about lwresd?
<jdub> hooray for rsync
<ajmitch> jdub: many savings?
<jdub> yeah, it's pretty rad now
<ajmitch> great, it might almost be usable for me
<jdub> ajmitch: 
<jdub>    550098944 100%    3.32MB/s    0:02:37  (1, 100.0% of 1)
<lamont> thom: I know that bind9 includes it... :-)
<jdub> wrote 164343 bytes  read 15886018 bytes  82099.03 bytes/sec
<jdub> total size is 550098944  speedup is 34.27
<lamont> sent 164353 bytes  received 49416730 bytes  38780.67 bytes/sec
<lamont> total size is 550098944  speedup is 11.09
<lamont> that machine hasn't been syncing every day
<lamont> since rsync doesn't really do --bwlimit...
<ajmitch> jdub: impressive
<thom> lamont: gah :-)
<thom> ok
<ajmitch> although I've only got a measly 128kbit line, so I might put that in the crontab
<ajmitch> jdub: that's for the live cd?
<lamont> ajmitch: I saw 425kB/s, on a line that I know is limited to 256kbits
<lamont> yeah
<lamont> jdub: please note that amd64 (and ia64) will have occasional burps as the livecd rootfs grows too big and we have to rebuild it (and thereby trash rsync-ability for the day)
<ajmitch> grabbing at a steady 10K/sec now :)
<ajmitch> someone suggesting anjuta2 be packaged, released in feb - is that possible to stick at least a beta in universe before feature freeze?
<ajmitch> hmm, beta in early feb, no release date mentioned
<jdub> yeah
<jdub> we're more relaxed about upstream version changes in universe
<jdub> as long as we have someone trying them out and saying that they definitely work :)
<ajmitch> great
<smurfix> lamont: uploading a new version to Debian, basically
<smurfix> lamont: ... which 
<smurfix> lamont: ... which proved to be nontrivial; the first upload had a -dbg which elmo didn't want to accept, so I uploaded an .orig.tgz-less -2, which ended up in the pool ... *without* the orig.tgz.
<Kamion> mdz: it was set to daily-installer; changed back to installer
<smurfix> lamont: Needless to say, that shouldn't have happened.
<mdz> Kamion: shouldn't daily-installer have been correct?
<mdz> Kamion: isn't that where lamont's builds go?
<Kamion> mdz: er ... d'oh
* lamont beats openoffice on the head
<Kamion> mdz: quite right, changed back :-)
<ajmitch> for a minute I thought you said 'openoffice on the hurd'.. but nobody's been brave enough to port that
<mdz> Kamion: I didn't run cron.daily-live until elmo said the build was on mirnyy
<mdz> I don't have access to mirnyy to check
<lamont> (use OO.o to edit a file, run it again to edit a file with the same name in a diff directory, exit the second one, get prompted about what to do with changes, click discard, watch everything exit, scream.)
<mdz> but it certainly didn't make it to little
<Kamion> mdz: you can look at http://mirnyy.ubuntu.com/ubuntu/ from anywhere surely
<mdz> ah, didn't realize it was a public mirror
<mdz> Kamion: oh, hey, it's on little now
<mdz> Kamion: did you do a mirror sync?
<mdz> maybe it works for you and not for me
<Kamion> no
<mdz> hmm
<Kamion> didn't touch that
<mdz> lrwxrwxrwx    1 cjwatson cdimage        26 Jan 26 08:01 current -> 20041227ubuntu7.0.20050125
<mdz> lrwxrwxrwx    1 mdz      cdimage        27 Jan 26 21:13 current -> 20041227ubuntu7.0.200501260
<mdz> anyway, doing new cron.daily-live now
<Kamion> how can you have two symlinks both called current?
<mdz> one is from before, the other from now
<mdz> the first was from after I ran cron.daily-live earlier
<mdz> the second one is wthat it looks like now
<mdz> I think it works when I run anonftpsync by hand
<mdz> but the mirror doesn't update when I run cron.daily-live
<mdz> Kamion: just noticed that pxeboot.tar.gz has a config with devfs=mount,dall in it.  that's obsolete, right?
<mvo_> mdz: live cd works fine on my test-system
<mdz> mvo_: thanks; unfortunately it doesn't have the new pieces I needed :-/
<mdz> I just built a new one
<mdz> if you could try that as well, that would be great
<haggai> dpkg-deb: building package `openoffice.org' in `../openoffice.org_1.1.3-2.3ubuntu8_all.deb'.
<opi> mdz, give me a link :)
<haggai> finally I am getting somewhere...
<opi> mdz, I'm going to burn it tom.
<mvo_> mdz: tomorrow in the morning then :)
<opi> mdz, I'd like to leave office today ;)
<mdz> opi: http://cdimage.ubuntu.com/daily-live/current/
<opi> *click*
<mvo_> still, the last live-cd I tested did not work as well (it hanged sometimes during hotplug)
<elmo> mdz: boggle
<elmo> mdz: did you get it sorted?
<mdz> elmo: yeah, I think the problem is on little's end
<mdz> though I have no idea why
<mdz> the script clearly calls anonftpsync near the start
<mdz> and there is no error in the log
<mdz> and I think it works for Kamion
<elmo> hmm, maybe it got smacked down by rsync limits but that didn't get logged somehow?
<Kamion> it's not in the logfile even
<Kamion> mdz: yes, that's obsolete, will fix
<Kamion> erm. would fix if I could find it.
<mdz> ===== Syncing Ubuntu mirror =====
<mdz> Wed Jan 26 20:26:17 GMT 2005
<mdz> is there supposed to be rsync output below that or something?
<Kamion> no, it's normally blank
<Kamion> oh, it goes to rsync.log
<mdz> anonftpsync is quiet when I run it
<mdz> there are some permission denied errors in rsync.log
<azeem> ogra: OK, so I resynced multisync (heh) with unstable and it builds fine again now, the (signed) source package is at http://people.debian.org/~mbanck/ubuntu-hoary/multisync_0.82-5ubuntu1_source.changes
<mdz> rsync.log.1.gz seems to show the d-i build coming across, though
<Kamion> that's the universe->main symlink stuff, I need to reapply my workaround
<Kamion> rsync.log.2.gz shows an error
<Kamion> likewise 3
<mdz> aha
<mdz> yeah, that's it exactly
<mdz> elmo: can we get a username/password for little for unlimited rsync?
<Kamion> elmo: is there any way I could have some kind of privileged rsync access from little?
<azeem> dunno how to proceed from here, a simple sync from unstable is not possible my patch from last time is still needed
<Kamion> heh
<mdz> :-)
<ogra> elmo: if i upload foreign packages, do they need to be signed by me additionally ?
<azeem> ogra: sure
<azeem> ogra: I'm not in the keyring
<ogra> azeem: become a MOTU !
<ogra> azeem: ;)
<ogra> azeem: ok, pulling the source....
<thom> yay, we get to have a celebrity as a MOTU
<Kamion> mdz: seriously I don't see this pxeboot.tar.gz anywhere; only warty has pxeboot.tar.gz as far as I know (it got renamed to netboot.tar.gz), so are you sure you're looking at the right distribution?
<mdz> Kamion: yeah, I was talking about warty
<Kamion> mdz: you still care about warty? :-)
<azeem> thom: from today:
<azeem> 01:26 < nyu> azeem: dude, did you see this joke in debconf3?
<azeem>           http://people.debian.org/~mjb/talks/debconf3/html/slide_31.html
<mdz> Kamion: I was helping someone do a net install
<mdz> Kamion: was it not obsolete yet in warty?
<Kamion> mdz: oh. well, it's obsolete (and was in warty), but harmless; I killed it post-warty
<azeem> ogra: I couldn't find somebody to test the packages (I'm running warty myself), but I guess it's better than right now at least
<thom> azeem: never, ever, will they let you forget :-)
<mdz> Kamion: is pxeboot.tar.gz not automatically built or something?
<mdz> or did it go away since warty?
<Kamion> mdz: it went away since warty.
<mdz> oh
<azeem> thom: I was going to make a webpage with all my lookalikes
<ogra> azeem: lets see.... hoary is still called unstable ;)
<jdub>    * Disable obnoxious beeping
<thom> there's only one true lookalike
<jdub> mdz: wtf ?
<mdz> Kamion: the friend I was helping was following this at first: http://www.ubuntulinux.org/wiki/InstallFromOtherDistroHowto
<elmo> ogra: yes, they do
<mdz> Kamion: which basically tries to walk the user through doing what d-i does by hand
<elmo> mdz/kamion: yeah, meh
<ogra> azeem: but the pics match very well....
<mdz> Kamion: it seems simpler to set up the existing system to boot a netboot d-i
<Kamion> mdz: yarrrr
<mdz> Kamion: which is what I was walking him through.  is there already a howto for that?
<ogra> elmo: thanks
<Kamion> mdz: these howtos keep popping up and I keep having to fix them
<Kamion> mdz: no idea, TBH, sorry :/
<ajmitch> azeem: it's almost like a mirror
<azeem> ajmitch: http://www.geocities.com/mikes_maman/PETEMICHI.html
<mdz> Kamion: I don't expect there should be much to it beyond downloading kernel+initrd and configuring lilo/grub
<mdz> Kamion: trying to talk him into writing the howto along the way
<ajmitch> heh
<ogra> azeem: thought about working for a double agency ? ;-)
<mdz> jdub: I guess you don't use growisofs, or don't use rewritable media
<azeem> ogra: as I said, I'm going to do a website first
<jdub> mdz: naw, what was the beeping? that's bong
<mdz> dammit, wtf
<mdz> jdub: if growisofs notices that you have a filesystem on the media already, it beeps 5 times for 5 seconds before doing what you told it
<jdub> haha
<mdz> which is completely stupid, because it's _rewritable_, and that's what' you _do_ with rewritable media
<mdz> hence the "RE"
<jdub> you have to press the NO REALLY DO WHAT I SAY button
<mdz> Kamion: my template changes are still missing
<mdz> maybe I fucked up
<jdub> i hate that button
<HrdwrBoB> that button is also disregarded
<jdub> i should get some rw media and try it out
<mdz> nope
<mdz> the casper changes aren't there either
<HrdwrBoB> eg: delete all my files please! (are you sure??) YES! .. oh wait.. crap
<mdz> it's clearly not a new initrd
<mdz> WTF
<mdz> though initrd.list says it should be
<jdub> oh man
<jdub> i am very happy with my 52X cd burner now that it works
<ajmitch> so are there plans for a live dvd for hoary+1? :)
<jdub> ajmitch: possibly even for hoary
<mdz> oh
<mdz> powerpc is wrong
<jdub> ajmitch: dvd with installer + live image
<mdz> i386 is right
<ajmitch> that could be useful
<mdz> amd64 is correct, too
<ajmitch> then I could spread ubuntu cheer around uni
<mdz> elmo: are you sure that powerpc d-i upload happened?
<jdub> all of supported :)
<azeem> jdub: or a DVD which contains all arches?
<jdub> only desktop seed for each though
<jdub> but i don't think that's as useful as dvd of supported
* jdub would love to parachute dvd/live/supported CDs into india and china
<Kamion> ajmitch: will do that fairly soon, not sure it'll make feature freeze as I have a lot of other things to do but I hope I can slip it in after that
<mdz> amd64 live is golden
* jdub boots livecd
<jdub> "This is the Ubuntu Live CD"
<jdub> ACTION!
<lamont> mdz: how was i386?
<mdz> lamont: trying it now
<mdz> lamont: problem is, powerpc somehow has an old d-i on it
<mdz> or else I fucked up somehow
<mdz> hmm, looks like I downloaded powerpc before the mirror was synched up
<mdz> so it's probably OK
<jdub> mdz: so where's usplash at? i'm getting testing jitters
<mdz> jdub: sladen said ~35% ready the last time I spoke to him
<jdub> hrm :|
<jdub> mdz: (livecd still asks for hostname, known?)
<mdz> jdub: the latest one doesn't
<mdz> you must have gotten the broken set
<jdub> oh
<mdz> rsync the latest
<jdub> i just synced like, 10 minutes ago
<mdz> c4393b51dba477f9b5ddaa81f062111f  hoary-live-amd64.iso
<mdz> c512b3e1cc389e1309104bf288fb7d85  hoary-live-i386.iso
<mdz> 974f4d42f96d20d26327aa2950dd0ac2  hoary-live-powerpc.iso
<mdz> those are the good ones
<opi> mdz, should I restart too?
<mdz> opi: yes please
<opi> mdz, okidok
<mdz> apologies for the confusion
<jdub> ah smeg
<opi> mdz, ok, donwloading it now
<ogra> elmo: a simple debsign of the changes with my key is enough ?
* lamont freshens again
<ogra> seb128: thanks for fixing libgtksourceview-cil
<ogra> :)
<seb128> np
<jdub> disk in burner more useful for burning said disk
<thom> it tends to help
<jdub> now it will BURN LIKE TRUFFLE!
<mdz> i386 is good
<thom> oh dear god
<lamont> thom??
<thom> lamont: ?
<lamont> <thom> oh dear god
<thom> jdub is on a truffle kick
<lamont> oh.
<thom> on multiple channels
<lamont> we should burn some for him in sydney, eh?
* ogra never tried to burn truffles
<lexhider> can I attach files to a bug report or do I have to post the file contents into the comment.
<lexhider> ?
<HrdwrBoB> lexhider: attach
<lamont> ogra: they're like CD's, only _LOTS_ easier
<thom> and now debian-uk is talking about unicock; and the insanity is complete
<mdz> powerpc is good
<ogra> lamont: i guess they are softer then CDs afterwards...
<mdz> I'm 3 for 3 with the current daily-live
<mdz> amu: here?
<mdz> amu has a live CD test plan we could run through
<thom> mdz: i really need sleep; can i poke bittorrent in the morning?
<lexhider> HrdwrBoB: I'm at https://bugzilla.ubuntu.com/enter_bug.cgi?product=Ubuntu and I can't see where I can attach the files.
<mdz> thom: I won't be around in your morning
<mdz> but I guess we can do a day-long test cycle on it
<thom> lexhider: file the bug, then attach after
<Kamion> mdz: do you want them published under releases?
<mdz> Kamion: wherever you put the array stuff is fine
<mdz> I'm not sure what to call it
<Kamion> mdz: any particular name?
<thom> mdz: if that's ok with you, great
<lamont> mdz: note that you're not using this mornings livecd rootfs, since that didn't build...
<mdz> I wanted to sync it with array-3, but that didn't happen
<mdz> so it's sort of array 3.5 live
<mdz> lamont: that's ok
<Kamion> could call it array-3.5-live if you like :-)
<mdz> lamont: that should be fixed now, btw (the gnomemeeting/libpw stuff)
<lamont> mdz: was just a note...
<thom> 'night
<ogra> night thom
<mdz> Kamion: if no one has a better idea...
<azeem> ogra: debsign asks you whether you want to keep the old sig, just say no and generate a new one
<azeem> or maybe it only asks you if it's from the same key, dunno
<ogra> azeem: got everything ready already... just wanted to avoid additional work for elmo....trying the upload....
<azeem> hey, I'm not pressed :)
<HrdwrBoB> lexhider: looks like it's changed, and doesn't allow that anymore
<azeem> just wanted to point that out
<ogra> azeem: but i tend to forget things f i leave them lying around ;)
* lamont back in a few
<Kamion> sigh, of course changes I make to the cdimage archive are getting merrily corrupted on their way out to mirrors at the moment
* Kamion will have to clean that up later
<elmo> uh?
<Kamion> archive == baz archive
<T-Bone> Kamion: i got the lsb-base issue once again
<mdz> jdub: any luck with the daily?
<jdub> mdz: um, now my burner is crapping out
<Kamion> T-Bone: will need to see error messages for it to make any sense
<elmo> ah
<jdub> cdrecord: OPC failed.
<mdz> cdrecord is crap, and so are writable CD media
<jdub> cdrecord: Success. send opc: scsi sendcmd: no error
<jdub> CDB:  54 01 00 00 00 00 00 00 00 00
<jdub> status: 0x4 (CONDITION MET/GOOD)
<jdub> cmd finished after 60.040s timeout 60s
<jdub> cdrecord: OPC failed.
<jdub> 
<mdz> haha
<mdz> CONDITION MET/GOOD
<jdub> i have no idea wtf that means
<jdub> success no error
<mdz> it means cdrecord is a steaming heap of dung
<jdub> crapsmackula
* jdub burns on a different machine
<mdz> if it weren't for ubuntu-desktop testing I would purge it
<T-Bone> Kamion: the message doesn't make sense at all. As i reported, it says base-install can't be installed because it depends on lsb-base which is not going to be installed
<Kamion> "base-install"?
<T-Bone> Kamion: chroot & running apt-get -f install fixes the issue
<Kamion> there is no such package
<T-Bone> ubuntu-base
<T-Bone> sorry
* Kamion blames apt ;)
<srbaker> trying to build subversion with ENABLE_JAVAHL
<mdz> T-Bone: that means you have broken packages
<srbaker> and it fails trying to call a command called "none"
<mdz> read the log
<srbaker> what the hell?
<T-Bone> Kamion: then after apt-get -f install, if you start again the install process saying ok to use a dirty target, it fails again on some other package
<mdz> mako: can you help me cook up a live CD milestone announcement?
<Kamion> T-Bone: should I have the logs in e-mail somewhere?
<srbaker> ahhhhhh
<srbaker> it couldn't find javac
<mako> mdz: yes sure
<Kamion> T-Bone: the bit about dirty targets is there because it's known not to work, so I'm not too surprised about the latter bit
<T-Bone> Kamion: i'll try to get them to you
<Kamion> ok, thanks
<T-Bone> Kamion: ok
<ogra> yay, katie likes me :)
<mako> mdz: got notes/etc?
<lexhider> I have successfully created the bug report and am attaching files as we speak. I'd like to make the point that it is counter-intuitive to not be able to attach files until the bug report has already been filed.
<mdz> mako: just in my head
<Kamion> T-Bone: just /var/log/messages should be ok
<T-Bone> Kamion: actually the funny thing is that it doesn't fail for the usual reason (awk symlink)
<mdz> mako: shall I email you?
<Kamion> lexhider: yeah, bugzilla sucks, we're not going to be keeping it forever
<mako> mdz: sounds good
<T-Bone> it fails on ubuntu-base, but while installing some other package
<srbaker> ahh
<srbaker> apparenlty it set JAVAC to "none"
<srbaker> what the FUCK?
<T-Bone> Kamion: old on I'm booting the box. I have saved the logs on the HD
<mako> mdz: i'm working on a couple other announcements at the moment so i'm the zone :)
<T-Bone> fabbione: ping?
#ubuntu-devel 2006-01-30
<poningru> what products need testing right now?
<poningru> like really lack testers
<\sh> edubuntu, kubuntu (install and live)
<ogra> yay, dbus built !!!
<ogra> finally :)
<mjg59> Hurrah
<mjg59> Now test it :)
<Kamion> poningru: DVD images
<ogra> mjg59, will do as sson as it hits the archive ...
* ogra kicks gconftool2
<ogra> updates take forever here since a while :/
<\sh> ogra: don't complain i'm compiling vlc the 5th time now...and I'm going mad with this mozilla vlc plugin...#
<\sh> and building in a amd64 dapper chroot in i386 mode doesn't work
<ogra> \sh, i had to update 240 packages yesterday ...
<ogra> it took 4h
<ogra> (20 min download time) 
<\sh> ogra: you mean "download, unpacking, installing"? 
<ogra> there is certainly something wrong with gconf currently
<\sh> ogra: well..240 packages in one go makes this little portege so hot :)
<seb128> patches are welcome
<ogra> 20min download,  3:40 unpacking, installing
<seb128> that's not likely to be due to gconf
<ogra> seb128, i'll be annoyed enough to look into it soon
<ogra> gconftool is seldom below 80% CPU utilisation
<seb128> for 3 hours in a row?
<ogra> and thats where it hangs ... for minutes 
<seb128> right, there is some slowdown issue atm, I think it's due to the base merge
<ogra> i stopwatched 5min for the worst package 
<seb128> but 3 hours, hum
<ogra> some go through in 1min
<seb128> what kind of box is that?
<ogra> ibook
<ogra> G4 1.33, 1Gig
<seb128> what package did 5min?
<\sh> well...I have to go to bed...tomorrow there will be a commercial being spread all over germany via mtv and viva...and I promised george to take care about his little quad xeon babies
<ogra> phew, you can ask funny stuff ...
<\sh> or better today
<ogra> something with gnome-
<ogra> panel or session iirc
<seb128> applets would be most likely to take some time
<ogra> might also have been panel-data
<ogra> or that,  yes
<seb128> session has almost no gconf keys and panel not that much
<seb128> anyway it's on my list but low priority
<ogra> i'd have guessed that it has to do with the gconf change, but this box is a flight2 install, there cant be any old gconf stuff
<seb128> I think that's due to the schemas registration
<seb128> new install or upgrade that's the same amonth of packages/schemas you get
<ogra> i doubt it will disappear magically
<seb128> me too
<ogra> we have time to solve it after feature freeze :)
<seb128> that's not a feature to fix that
<ogra> it just *feels* like its getting worse
<seb128> I don't think so
<ogra> thus the *'s
* ogra hits Keybuks shiny new recycle icon to test dbus ...
<robertj> has shipping with pam_tally configured by default been discussed?
<seb128> not that I know of
<robertj> does it seem like a good idea?
<seb128> don't ask me
<seb128> I don't use  pam stuff :)
<robertj> err..?
<seb128> you should probably mail the list about that
<seb128> s/use/work on
<robertj> hehe
<seb128> anyway time to sleep here
<ogra_ibook> mpfh
<ogra_ibook> Keybuk broke my wlan :(
<ogra> mjg59, suspend works fine, now the acpi-scripts need to learn not to override g-p-m, the lid switch selection still doesnt do what it should ...
<ogra> hmm, why dont i have any sound anymore ...
<robertj> while I am typing up this email should I bother to mention cracklib for outward facing services?
<mjg59> ogra: The scripts /ought/ to do the right thing if g-p-m is running, I think
<mjg59> But yeah, that needs revamping
<ogra> i can select "do nothing" for the lid, but it still suspends
<ogra> but thats on ppc, most likely pbuttonsd's fault 
<mjg59> Yeah, that'll be pbuttonsd
<mjg59> Does hal send an event on PPC lid close?
<mjg59> If so, we should probably just drop it
<ogra> would be nice to have it configurable ...
<ogra> hmm, dbus-monitor doesnt say anything ...
<mjg59> Rather, drop pbuttonsd
<mjg59> Bleah. I'll look into it
<HiddenWolf> Why does my dapper-live daily start bittorrentd?
<bddebian> Ack, where to the mime xml files go..
* bddebian has forgotten everything already :'-(
<spstarr_home> have we fixed murasaki to work in dapper yet, it seems to be rather raw right now, since hotplug appears broke right now. (perhaps rename it BACK to hotplug since it makes more sense?)
<spstarr_home> its not like the average joe is going to know what murasaki is it certainly doesn't tell me its a hotplug implementation :)
<lamont> The following packages have unmet dependencies:
<lamont>   keymapper: Depends: xlibs but it is not installable
<lamont> E: Broken packages
* lamont kicks console-data
<bddebian> Kick it harder
<StevenK> lamont: Can you tell me why the new version of quodlibet hasn't been tried on the buildds?
<bddebian> StevenK: What version?
<lamont> StevenK: according to people.u.c/~lamont/buildLogs/Lists/dapper.all.i386:
<lamont> universe/sound/quodlibet_0.17-1ubuntu1: Dep-Wait by buildd+rothera [optional:out-of-date] 
<lamont>   Dependencies: debhelper (>= 5.0.17)
<lamont> does this mean you changed the build-dep on debhelper in your upload?
<lamont> (dep-waits stay until either they're really satisfied, or infinity/I clear them.)
<bddebian> Doh, I was looking at breezy build logs.. What a dolt
<lamont>   xmkmf: Depends: imake but it is not going to be installed
<lamont>   imake: Conflicts: xmkmf
<lamont> oh, now _that's_ funny.
<bddebian> xmkmf sucks anyhow :-)
<lamont> yeah, but it really shouldn't conflict with something that depends on it...
<lamont> or vice versa
<bddebian> Aye, good point :-)
<lamont> otoh, tex-guy is the only ftbfs that seems to have resulted ATM.
<bddebian> ??
<lamont> The following packages have unmet dependencies:
<lamont>   xmkmf: Depends: imake but it is not going to be installed
<lamont>   xutils: Depends: imake but it is not going to be installed
<lamont> that's from the hppa log for tex-guy
<bddebian> Ahh
<bddebian> Sheesh, do I really need to do a dpatch just to add { } to an else??
<StevenK> lamont: Sorry, I was working. Yes, my upload changed the depends, so can you clear the Dep-Wait?
<lamont> StevenK: will do
<StevenK> lamont: Thanks
<lamont> done
* lamont -> bed
<HiddenWolf> My media keys stopped working on dapper. Which package can I blame?
<Burgundavia> marilize, long time, no see
<viviersf> hmmm prolly leave 
<marilize> Burgundavia: hey mr burger, how are you?
<Burgundavia> marilize, not bad. Banging my head away at writing
<Burgundavia> marilize, when do you start shipping dapper stuff?
<Burgundavia> marilize, can I get cds for April 30th?
<marilize> burgundavia: dont bang too hard :)  your a bit fast for us, not date yet...
<marilize> not sure
<marilize> it will be towards the end of april, but I'm not sure yet 
<jsgotangco> mmm?
<Burgundavia> hey jsgotangco 
<jsgotangco> hey Corey
<jsgotangco> heya sabdfl 
<sabdfl> hiya
<sabdfl> ran into colin charles yesterday in singapore
<sabdfl> v cool to see him again
<jsgotangco> sabdfl: oh sweet how's singapore?
* netjoined: irc.freenode.net -> brown.freenode.net
<lifeless> its a small small world
<sabdfl> dunno. i'm now in new zealand ;-)
<jsgotangco> i thought he was still in au
<jsgotangco> ahh
<jsgotangco> sabdfl: see you in a week then
<sabdfl> absoloodle!
<Burgundavia> sabdfl, is the next development conference expected in middle may?
<jsgotangco> where will that be?
<Burgundavia> jsgotangco, rumours of germany were swirling at UBZ
<jsgotangco> oh :/
<Burgundavia> jsgotangco, I wouldn't bet my house on germany
<sabdfl> Burgundavia: yes, may, and germany was pretty solid till the world cup turned out to make it trickier than expected
<sabdfl> anybody know how to get networkmanager running?
<sabdfl> how do I may the daemon start by default?
<jsgotangco> i add the nm-applet on startup
<jsgotangco> sabdfl: what i did before after installing is restart dbus then add nm-applet on gnome startup
<Burgundavia> sabdfl, oh ick, I forgot about bloody football. All those english hooligans will make it hard to code
<ajmitch> eveningall
<Burgundavia> salut ajmitch 
<jsgotangco> heya ajmitch 
<Burgundavia> sabdfl, when is the formal announcement expected to be made?
* Burgundavia should be able to make the next conference under his own steam
<jsgotangco> wow
<Burgundavia> jsgotangco, some unexpected money
<ajmitch> great :)
<ajmitch> I doubt I'll make it to the next one without help
<Burgundavia> of course, I should be paying off my student loan with it, but meh
<ajmitch> heh
<Burgundavia> sales jobs have things called commissions for those things
<sabdfl> jsgotangco: i get an error
<sabdfl> The NetworkManager applet could not find some required resources. It cannot continue.
<sabdfl> useful, innit
<Burgundavia> sabdfl, welcome to NM. Shall we ship it with dapper then?
<sabdfl> hey pitti
<sabdfl> Burgundavia: maaayybe :-)
<sabdfl> i think it just killed my network connection
<jsgotangco> sabdfl: strange, i got it working just now
<Burgundavia> sabdfl, it will get your name resolution next, just for fun
<sabdfl> Burgundavia: yes, that's the symptom i saw
<torkel> it might need to be upgraded due to the recent dbus/hal/... changes
<sabdfl> torkel: it has always failed for me
<sabdfl> i suspect that my network config has been upgraded too many times for it
<jsgotangco> i didnt have problems on it with breezy and dapper :/
<Burgundavia> pitti, http://mail.gnome.org/archives/utopia-list/2006-January/msg00022.html <-- is this debate resolved? (specifically the part about hte usb and owning hte box)
<torkel> sabdfl: it worked for me until a week ago or something
<jsgotangco> although haven't tested on the recent milestone
<sabdfl> how does starting nm-applet fire up NetworkManager and NetworkManagerDispatcher as root?
<lifeless> dbus
<torkel> it is dbus that starts NetworkManager iirc
<lifeless> the magic off
<sabdfl> is it possible to know that NetworkManager is working even if nm-applet is throwing up errors and not a panel icon?
<torkel> is it running att all?
<sabdfl> torkel: if I run nm-applet from the command line then I get a NetworkManager and NetworkManagerDispatcher processes
<sabdfl> nothing shows up on the panel
<vuntz> sabdfl: do you have a notification area?
<sabdfl> vuntz: yes, believe so. i see gaim icn and restart icon when necessary
<vuntz> maybe network-manager doesn't control any interface and so nm-applet feels it doesn't have to show an icon
<vuntz> I guess this can happen if your interfaces are already configured
<vuntz> (just a guess, though)
<sabdfl> should i try ifdown'ing them all and then running nm-applet?
<torkel> sabdfl: try restarting dbus - /etc/init.d/dbus restart
<vuntz> I'd try this and I'd comment everything in /etc/network/interfaces too, just to be sure
<vuntz> but I'm not saying it will help :-)
<jsgotangco> hmm it just killed networking in my other box
<torkel> after restarting dbus nm-applet works for me again
<whiprush> jsgotangco: dude check out planet.u.com, an awesome opportunity landed in my lap!
<whiprush> sabdfl: you too!
<jsgotangco> whiprush: please don't abuse your puppy
* whiprush scrolls up.
<whiprush> I've found that rebooting the machine after installing nm worked for me
<jsgotangco> he that's pretty long
<whiprush> after that firing up nm-applet and saving the session did the trick
<whiprush> afterwards the applet just fires up on login and connects.
<robitaille> same here.  nm always worked better after one initial reboot to "settle" the applet in my configuration
<whiprush> robitaille: yeah, the restarting thing never seemed to work for me, always just rebooted to get it working right.
<whiprush> once you get nm-applet in your session it works great (there's an upstream bug on this I don't recall)
<robitaille> I have been using nm daily on my laptop since christmas, and I have been pretty happy with it, switching regularly between my wired and my wireless.
<HrdwrBoB> I use a shell script
<HrdwrBoB> I have several different wired and wireless networks
<HrdwrBoB> as well as vpns that start
<whiprush> n-m has a long way to go outside of the "I'm just some guy with a wifi card" use case.
<HrdwrBoB> yeah
<whiprush> I'm sure keybuk has a list about 2 miles long about that.
<jsgotangco> whiprush: that project sure is exciting
<whiprush> jsgotangco: I'm hoping.
<ajmitch> hey whiprush, jsgotangco 
<whiprush> hi aj
<Ibalon> heya ajmitch 
<ajmitch> hello Ibalon 
<jsgotangco> why does nm insist on changing my dns to loopback?
<Ibalon> nm?
<jsgotangco> Ibalon: network-manager
<whiprush> jsgotangco: if anything, it teaches me that you don't know jack about you don't know jack about your local area, even if you think you do. :D
<Ibalon> ah
<whiprush> and whoa that sentence came out all wrong
<whiprush> but you get the idea.
<ajmitch> jsgotangco: it uses a local dns server
<jsgotangco> Good News Gang heh
<Burgundavia> whiprush, indeed
<Burgundavia> whiprush, damn you make me jealous
<jsgotangco> it does?
<whiprush> Burgundavia: not really. If I fail then I suck. :p
<Burgundavia> I feel like such a pathetic fool. I organized an installfest last Sat. and only 6 people showed up
<jsgotangco> hey
<jsgotangco> don't count out those 6
<jsgotangco> they still came
<whiprush> indeed.
<Burgundavia> my local lug is a bunch of layabouts who would rather eat at boston pizza
<jsgotangco> then why not do it at boston pizza
<Burgundavia> rofl
<Burgundavia> but I have an idea, my brain is already turning
<ejofee> what do you people think about including mc (or mc-light) as a console fail-back, for the rescuing situations or for the cases when the live can't reach the graphical user interface (which sometimes does happen); it is very newbye-friendly and many win98 users will prefer it, as it very much resembles nc (norton commander) or dn (dos navigator). we can use this until we have better rescuing tools. (i mean... just imagine a newbye for which x1
<ejofee> n bash.)
<Burgundavia> ejofee, lucas meant the mailing list
<ejofee> Burgundavia: ... right. there was an "@", not an "#", indeed...
<Burgundavia> whiprush, the ubuntu youth project is really cool glueing together of existing organizations
<dholbach> good morning
<mdz> doko: please copy Colin on exception requests
<doko> mdz: ok
<doko> this one as well?
<mdz> doko: all of them
<hunger> Any chance of getting tar -c support into the rescue environment of the dapper CDs?
<hunger> A rescue env in which you can not tar up important files is somewhat limited.
<Kamion> depends how much extra space it takes in the busybox binary, really
<Kamion> I'm not sure CONFIG_FEATURE_TAR_CREATE has been tested much either
<hunger> frogzo1: Yes, that works everywhere but in busybox (== the rescue env):-(
<hunger> frogzo1: busybox does not support the -c option of thar.:-(
<hunger> frogzo1: I am running as root, so -p is used even if I do not give it explizitly.
<Kamion> I don't know who you're talking to, but they must be on a different channel.
<hunger> Kamion: sorry!
<Kamion> any reason you can't just use the tar in /target?
<Ibalon> lol
<Kamion> /target/bin/tar -cf foo.tar /target/bar
<hunger> This bitchx makes me confuse channels all the time... unfortunately it is the only thing I can run on the server with proper internet connection.
<Simira> wow
<\sh> that libnotify1 has problems while unpacking because of conflicts, is known?
<Kamion> yeah
<Kamion> (#29600)
<Simira> Tollef's plain left almost on time!
<Kinnison> hehe
* Kinnison hugs Simira. How're you?
<\sh> well I should read the bugs folder first before I start drinking a coffee
<Simira> Kinnison : good! I started in my new job today. Norway's largest provider of linux services (sertifications, support, network/software solutions +++)
<tepsipakki> kamion: multiverse isn't handled by apt-setup?
<Kamion> tepsipakki: nope
<hunger> Today bringing up network interfaces is broken even more then yesterday. Is this already known or should I write bugreports?
<Kamion> multiverse scares me too much
<tepsipakki> kamion: would you accept a patch to allow preseeding it?-)
<Simira> Kinnison : how are you today? Going to London soon?
<Kamion> tepsipakki: maybe
<hunger> Isen't there supposed to be /var/run on tmpfs nowadays?
<Kamion> tepsipakki: I think it'd be ok as long as it doesn't end up in the default sources.list (even commented) if you don't preseed it
<tepsipakki> kamion: ok
<\sh> oh when the londong dev sprint starts?
* hunger wonders why he got a /var/lock tmpfs but no /var/run one.
<Simira> \sh: Monday officially, I think. Tollef's off today.
<Kinnison> Simira: I'm in London already at a soyuz sprint
<Simira> Kinnison : oh, nice. Are you staying at the same place as Tollef, Adam and others, then?
<Kinnison> Simira: No, I'm on the soyuz deployment sprint this week, then I head back home
* Kinnison isn't on the distro sprint
<Kinnison> Simira: Oh yeah, and I've sold my house \o/
<Simira> ah, of course
<Simira> Kinnison : yay! And now you're rich?
* hunger grumbles about the new /var/run tmpfs idea.
<Kinnison> Simira: No, 'cos I bought a new house too
<Simira> Kinnison : oh. A nice one then?
<hunger> [ -d /var/run ]  || mkdir /var/run can not work while / is still mounted ro!
<Kinnison> Simira: Similar size to my current house. Different area
<Simira> Kinnison : more expensive, you mean :) I so want to move to England. Trying to convince Tollef to buy a summer house in the southern parts.
<Kinnison> Simira: *grin*
<tepsipakki> kamion: oh, how about those patches I sent to debian-boot, apt-setup/local[0-9]  etc? No-one commented on the newer patches
<Kamion> tepsipakki: my first thought was "hmm, I didn't expect quite so many templates"
<tepsipakki> =)
<Kamion> I know I said that there should be templates, but I think perhaps they could be omitted; if you're preseeding, the preseed infrastructure will register dummy templates on the fly anyway
<sivang> hi all
<Kamion> it just means that you have to be careful with db_* calls because now db_get might return an error, etc.
<tepsipakki> kamion: ok, I'll take another look
<Kamion> but we could just do i=0; while db_get "apt-setup/local$i"; do <do something with $RET>; i="$(($i+1))"; done
<Kamion> er, 'while db_get "apt-setup/local$i" && [ "$RET" ] ' I guess
<tepsipakki> thanks, I'll modify it
<tepsipakki> but first the multiverse..
<hunger> I think the installer will need fixing for this new /var/run thingy to work properly.
<\sh> Kamion: can I ask you for advise? i'm not sure if I'm right in this case
<\sh> https://launchpad.net/distros/ubuntu/+source/python-scientific/+bug/5950
<Ubugtu> Malone bug 5950: "python-netcdf does not depend on python-scientific, but does need it" Fix req. for: python-scientific (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed
<\sh> I would remove the dependency p-netcfd from p-scientific , and add a dep to p-netcfd for p-scientific
<\sh> hey mvo 
<Kamion> hunger: huh?
<\sh> hmm..coffee
<mvo> hey \sh 
<hunger> Kamion: Install a fresh dapper with /var on a separate partition.
<Kamion> \sh: no idea sorry, best ask somebody who actually knows the code ...
<hunger> Kamion: Then update and reboot: No more /var/run.
<Kamion> hunger: strange, /var should be mounted before base-files is unpacked and base-files contains /var/run
<Kamion> I have no intention of special-casing this in the installer; I suspect that one or more packages need to be fixed
<hunger> Kamion: Since /var is on a separate partition and that is mounted before base-files is unpacked the root partition does not contain /var/run.
<hunger> Kamion: S00mountvirtfs tries to create /var/run there and fails since / is ro at the time it is run.
<Kamion> I see; S00mountvirtfs had better do something else then
<hunger> Kamion: ... so no /var/run and no tmpfs mounted on it.
<Kamion> creating it on /dev and moving it later might work, for example
<Kamion> or mounting a tmpfs on /var, although that sounds scary
<hunger> Kamion: The does /var/run check is really redundant... mkdir can not work anyway.
<Kamion> anyway, file a sysvinit bug if there isn't one already pleas
<Kamion> e
<Kamion> Scott'll need to rethink this
<tepsipakki> kamion: what kind of a disclaimer should multiverse have? Can I just take the one for universe and modify it?
<hunger> I just did... malone #29637
<Ubugtu> Malone bug 29637: "/var/run is not created" Fix req. for: sysvinit (Ubuntu), Severity: Major, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29637
<Kamion> tepsipakki: a combination of restricted and universe plus extra scary, I guess
<hunger> That malone needs the source packages is *really* annoying by the way.
<\sh> hunger: it's going to change as I understood the launchpadders
<hunger> I have problems figuring out what malone wants from me there... I can not see how a user is supposed to do it.
<Kamion> bradb's already landed a package guesser that lets you use binaries too; it should be making its way into production soon
<Kamion> \sh: (for python-{netcdf,scientific}, ask doko ...)
<Kamion> (since he's the Debian maintainer)
<\sh> Kamion: will do :)
<\sh> ah when you speak about the devil :)
<\sh> doko: do you want to fix malone #5950 or do you want to give me a little advise what I should do :)
<Ubugtu> Malone bug 5950: "python-netcdf does not depend on python-scientific, but does need it" Fix req. for: python-scientific (Ubuntu), Severity: Normal, Assigned to: MOTU Science, Status: Unconfirmed http://launchpad.net/bugs/5950
<doko> best thing might be to have cyclic dependency
<\sh> doko: so adding python-scientific to p-netcfd and leaving the p-netcfd dep for p-scientific
<mvo> doko: isn't debian trying to get rid of them currently?
<doko> mvo: netcdf?
<mvo> doko: no, cyclig dependencies
<theine> Hi, in current Dapper, if I try to bring up a network interface with ifup, is dhclient3 supposed to be called with the -nw flag?
<\sh> doko: do you want to fix it first for debian, so we can sync the package?
<doko> mvo: upstream does see this package now as an integral part of scientific. Of course you still can use netcdf on your own, the now added Scientifc warapper around the extension module just can be used with the scientific package installed
<hunger> May I close bugs in malone or should this be done by a developer?
<siretart> hunger: I think thats okay. if in doubt, ask first here, but in obvious cases, sure!
<hunger> siretart: I guess reports about bugs in dapper in scripts that are no longer shipped do count as obvious;-)
<siretart> hunger: I agree :)
<hunger> Hmm... what is the policy about the new /var/run-tmpfs thing? Will init-scripts cleaning up stuff in /var/run stay for compatibility reasons or should there be bugs reported for them?
<mdz> doko: it looks like upgrades of python-twisted from breezy to dapper will lose python-twisted-web
<mdz> doko: is there any reason why the functionality cannot be preserved across upgrades?
<Kamion> hunger: we don't need to diverge from Debian when it doesn't matter, so in general I think those scripts should stay there
<Kamion> so long as they aren't a major performance hit or anything
<ogra> doko, what about zope3 installability ? 
<ogra> it breaks edubuntu currently ...
<Kamion> but trying to unlink a load of stuff that doesn't exist from a tmpfs should hardly take much time
<hunger> Kamion: That was what I was thinking as well, but then ifupdown-clean was removed yesterday.
<siretart> hunger: it was agreed that /var/{run,lock} will be tempfs because of udev, and that initscript will have to be fixed for that
<siretart> hunger: I'm currently working on courier
<hunger> siretart: Some things need fixing of course (i.e. have directories created), but what about cleanup scripts like sudo or screen-cleanup? They do no harm and cause hardly any slowdown.
<Kamion> they do no harm, so leave them
<hunger> Kamion: OK.
<\sh> pitti: what a surprise, the security notice about imagemagick is noticed as link on heise.de :)
<dooglus> I didn't see any updates for the last 18 hours.  I thought you guys were slacking.  Then I realised my update-notifier had crashed.  :)  Currently downloading 49 updates...
<doko> mdz: I can add the dependencies again, but that was not the intent of the split. I'm going to look at the twisted rdepends and adjust these
<Kamion> tepsipakki: thanks for the patch, I'll look at it once I'm out from under the critical things I have to get done before the distro sprint starts
<doko> mdz, Kamion: is libnotify1 still in NEW?
<Kamion> doko: no
<Kamion> libnotify1 | 0.3.2-0ubuntu2 |        dapper | amd64, hppa, i386, ia64, powerpc
<sivang> Kamion: how can I Know if a a user on the system, is a system user or a regular "human" , scan out all those which have higher GID/UID then 1000 as a harcoded value, or parse adduser.conf for correct behavior when an admin has changed it?
<tepsipakki> kamion: np
<doko> Vorbereiten zum Ersetzen von libnotify0 0.3.0-0ubuntu2 (durch .../libnotify0_0.3.2-0ubuntu1_amd64.deb) ...
<doko> Entpacke Ersatz fr libnotify0 ...
<doko> dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/libnotify0_0.3.2-0ubuntu1_amd64.deb (--unpack):
<doko>  versuche /usr/lib/libnotify.so.1.0.0 zu berschreiben, welches auch in Paket libnotify1 ist
<doko> Fehler traten auf beim Bearbeiten von:
<doko>  /var/cache/apt/archives/libnotify0_0.3.2-0ubuntu1_amd64.deb
<doko> mvo: ^^^
<dholbach> \sh that libnotify1 has problems while unpacking because of conflicts, is known?
<dholbach> Kamion yeah
<dholbach> Kamion (#29600)
<doko> ok
<Kamion> sivang: for what purpose?
<mdz> doko: if you want to allow for a subset of twisted to be installed without -web, then name it something else (Kinnison suggested python-twisted-core)
<mdz> doko: (fyi, this came up due to launchpad-dependencies)
<theine> I'm sorry for asking this question here, but where can one specify the flags that are passed to dhclient3 when it's invoked through ifup?
<sivang> Kamion: home-user-backup, recall that when it's the "admin" of the system, I want to let him backup all users' homes.
<mvo> doko: please remove libnotify0
<Kamion> sivang: looking at the standard 1000-29999 range would be a reasonable default
<sivang> Kamion: for an individual user, I just , mypid = os.getuid(); pwd_tuple = pwd.getpwuid(mypid)
<sivang> Kamion: ok, this value is usually unchanged?
<Kamion> I guess you can parse /etc/adduser.conf if you like; its format's documented in adduser.conf(5)
<Kamion> I'd also be inclined to exclude users with /bin/false set as their shell
<Kamion> (sanity-check)
<doko> ogra: zope3 needs dependencies from Debian NEW, I don't have these packages. asking jinty for these.
<ogra> ok
<Kamion> in fact, you could just exclude users whose shells aren't set to something in /etc/shells
<sivang> Kamion: I'll add exclusion for those now :)
<ogra> thats why i couldnt find the missing packages :)
<sivang> Kamion: ah, right, so that even let me drop the UID/GID range checking altogether...I think
<Kamion> sivang: no, it doesn't; there exist system users with /bin/sh as their shell
<Kamion> for example, trivially, root; but there are others
<sivang> Kamion: daemon as well
<Kamion> (well, root has /bin/bash, but anyway)
<Kamion> yes, when I said "there are others" that's because I knew there were others ;-)
* Kamion maintains the base /etc/passwd file
<doko> mdz: ok, I'll rename that to python-twisted-core and make python-twisted a transitional package
<sivang> Kamion: ok, sorry for the noise. Thanks for tips.
<Kamion> one of these days I'll change more of those to /bin/false, I'm just scared of breaking stuff
<sivang> Kamion: :-)
<hunger> Kamion: Why do some users have /nonexistent as their homedir?
<hunger> Kamion: Won't that get remapped to / on login?
<Kamion> hunger: see the base-passwd changelog
<Kamion> nobody can't log in so who cares
<keherman> Where is pam_console.so -- it seems you guys left it out!?!!
<keherman> now i can't have my LDAP clients use things like /dev/dsp :-(
<keherman> what is the solution?
<tepsipakki> keherman: pam_group?
<keherman> tepsipakki, it was intentianlly left out by martin pitt it seems
<tepsipakki> keherman: yes, but you can get what you want with pam_group
<keherman> tepsipakki, how so?
<Kamion> pam_foreground is the preferred option in Dapper, I believe
<tepsipakki> keherman: modify /etc/security/group.conf
<tepsipakki> kamion: yes, noticed that but haven't looked at it myself yet
<Kamion> or, since you can never really effectively revoke access to something once you've granted it with pam_console, you could just change the groups of whatever devices you want to grant access to ...
<keherman> tepsipakki, how do i give people physically at the machine access to /dev/dsp (not ssh in users)
<tepsipakki> keherman: add "auth optional pam_group.so" in /etc/pam.d/gdm, then in /etc/security/group.conf add a line like "gdm;*;*;Al0000-2400;audio"
<tepsipakki> keherman: "audio" is the group that the user is added to on login
<tepsipakki> keherman: you can add other groups as well...
<keherman> tepsipakki, and for kdm would just change the gdm to kdm?
<rob> does anyone mind if I mess around with gnome-app-install a bit?
<tepsipakki> the documentation for pam_foreground is pretty much nonexistent atm =)
<tepsipakki> keherman: yes
<tepsipakki> keherman: and of course you'd edit /etc/pam.d/kdm, not gdm
<mdz> mvo: how is the upgrade tool testing going?
<mvo> mdz: pretty good, I got lots of feedback so far
<keherman> tepsipakki, what is libpam-devperm?
<mvo> mdz: there was some problem on kubuntu systems and with missing dapper-backports repo
<mvo> but those are fixed
<tepsipakki> keherman: no idea
<mvo> some harder upgrade problems are left, looking into them currently
<tepsipakki> mvo: I had the same issue on ubuntu
<mvo> mdz: a pretty big problem is when dpkg fails for some reason during the upgrade, I had that in a test-upgrade. that can leave the system half-upgraded and in a really bad shape
<mvo> mdz: I'm currently trying to think about some way to continue in that situation, but it's tricky
<doko> ogra: zope3 might take some time, 3.2 just crept in before UVF without the required dependencies
<mvo> tepsipakki: did you send me a report :) ?
<mvo> tepsipakki: there has been some issues yesterday with uubntu-desktop not being installable
<ogra> ouch
<ogra> doko, thats evil ...
<ogra> i think flight 4 will be without schooltool then :/
<Riddell> mvo: kubuntu issue isn't fixed, but will be toot sweet
<mvo> Riddell: the dpkg override error is not fixed? but apparently, the upgrade can be calculated now just fine
<Riddell> well I never fixed it :)
<mvo> Riddell: the upgrade calculation problem was fixed with my upload of kaffeine yesterday (or was it monday?)
<Riddell> yes, it's the file clash in koffice that I was thinking of
<mvo> Riddell: yeah, no problem. it's not too urgent, I'm still pondering how to make the upgrade "mostly-working" when such clashes happen, so it's actually a good test-case :)
* mvo is away to have some food
<keherman> tepsipakki, pam_group did not work :-(
<keherman> tepsipakki, for some reason it still thinks rpcuser is the group!
<keherman> it is geeting this, i assume, since local ubuntu audio group id is 29, but ldap group id 29 == rpcuser!
<keherman> very weird...
<Simira> hm.. no trace of Mithrandir yet?
<Kamion> it's a bad idea to have LDAP gids in the 0-99 range
<Kamion> that range has fixed group assignments in Ubuntu
<Kamion> if you do, then you have to be very careful to avoid collisions
<keherman> Kamion, no the gid i am referring to is in local /etc/group
<Kamion> audio=29 is a fixed mapping on all Ubuntu systems
<keherman> ldap client --> audio:x:29:localuser
<keherman> yes
<keherman> ldap server --> rpcuser:x:29:
<keherman> but that is by RHEL3 default
<Kamion> if you override it in LDAP, I'm afraid you probably lose
<keherman> ldap server == RHEL
<keherman> i never override it
<Kamion> arrange for 0-99 not to be published on the server?
<keherman> when i do "getent group" none of the ldap groups come up
<Kamion> if the client is doing group lookups through LDAP, and the LDAP server is saying that rpcuser is gid 29, then that's overriding values that the system relies upon
<Kamion> or is the client not doing group lookups through LDAP?
<keherman> Kamion, how can i stop it?
<Kamion> no idea, I'm afraid
<keherman> "files ldap" ?
<keherman> versus "ldap files" ?
<Kamion> I don't do LDAP, I just know our gid assignment policy
<Kamion> that sounds like it might help
<tepsipakki> keherman: we have "files ldap"
<tepsipakki> but the server is on MacOSX ;)
<tepsipakki> and I know nothing about it
<sivang> hrm, duplicate oocurence of 'auto $IFACE' is who's problem? :-)
<sivang> (after a dist-upgrade of 10 minutes ago, and reboot)
<pitti> sivang: sounds Keybukish
<sivang> (prevent network from coming up at boot)
<sivang> pitti: I had the feeling. let's see if he's here or else, I will file a bug repot
<sivang> ok, I guess that's going to be a bug report :)
<pitti> rather do the latter, his net connection sucks
<sivang> ah yes, he said something about it yesterday
<Kamion> Mithrandir: any chance of getting that casper espresso-hooks branch merged and uploaded soon, or should I just upload it myself?
<mdz> Diziet: my firefox woes vanish with DEBUG=1 under gdb
<pitti> heh, just like the recent esddsp bug
<mdz> Mithrandir: are you at home today, or travelling?
<carlos> pitti, http://mawson.ubuntu.com/~carlos/rosetta-breezy.tar.gz latest update with data from last Monday
<pitti> carlos: yay
<Simira> mdz : he should have arrived in London now. His plane wasn't even late.
<mdz> pitti: hmm, indeed it seems to be a similar bug
<mdz> pitti: but on i386
<pitti> mdz: the cause of the bug wasn't really platform specific
<carlos> pitti, it only contains .po files from main and should be an UTF-8 export
<pitti> mdz: it was terribly confused when it worked as another user :)
<mdz> Simira: thanks
<mdz> pitti: oh, I thought it was amd64-specific
<pitti> mdz: it just happened to manifest there, bad moon phase, or unlucky number of bits or so
<pitti> mdz: the usual properties of race conditions
<mdz> pitti,Diziet: what was the workaround put into 1.5.dfsg-4ubuntu3?
<pitti> mdz: does disabling esd help?
<mdz> Diziet: the changelog doesn't say what you actually changed
<mdz> pitti: FIREFOX_DSP=none helps
<pitti> mdz: /etc/firefox/firefoxrc
<pitti> right, that was it
<Diziet> Oh, hello.
* Diziet reads scrool.
<pitti> mdz: even with esound 0.2.36-3ubuntu2?
<Simira> mdz : np. You just go easy on him the next week. I want him back in good shape.
<mdz> pitti: I have 0.2.36-3ubuntu2 installed
<mdz> Simira: I won't break him
<Diziet> The workaround was FIREFOX_DSP=none _but only on amd64_.
<pitti> then you just discovered another race as it seems *sigh*
<mdz> Diziet: I'm quite sure I'm not on an amd64
<Diziet> Which is why you don't have the workaround (unless you do it manually).
<Diziet> Broadly speaking the problem seems to be that something in ff assumes more threadsafety than esound provides.
<mdz> pitti: I'm using gstreamer autosink, why do I get esd?
<Diziet> I don't know exactly what pitti did but it seems like the way to fix it will have to be to wrap _all_ the esound calls in locks.
<pitti> mdz: ffox only talks OSS, and esddsp is a way to route OSS through esound
<Diziet> ff uses esd by default for some reason related to thincl, aiui.
<pitti> mdz: ffox knows nothing about alsa or even gstreamer
<mdz> pitti: right, but I got esd started in my session
<ogra> Diziet, thats done on system level, not in ff 
<Diziet> Right, but the esound library is not threadsafe so you have a race.
<pitti> mdz: probably because ffox wanted it?
<ogra> Diziet, at least it shouldnt ...
<mdz> hmm, I don't start firefox in my session
<mdz> I'll watch it next time I logout
<pitti> mdz: if you kill it and start ffox, does esd run again?
<Diziet> ogra: OK.  Sorry, I bow to your greater knowledge of all this.  But iirc you said that making ff never use esd would break it.
<pitti> mdz: it's not started with the session any more
<Diziet> Err, break it on thincl.
<pitti> mdz: it's spawned automatically as soon as some libesd app wants to talk to it
<pitti> Diziet: wasn't the problem that ffox doesn't understand alsa and only OSS?
<ogra> Diziet, it should use the desktops soundsystem ... we make the desktop automatically use esdsink if an ltsp client is used
<sivang> pitti: I wonder what's been modifying it, I see it's listed under ifupdown.
<Diziet> So ff could talk to the oss device directly but that wouldn't work with thincl ?
<ogra> Diziet, yes, that wouldnt work
<Diziet> Right.
<pitti> Diziet: first that, and second it would totally block the sound device since oss doesn't support sharing
<ogra> but not only on thin clients i think
<Diziet> I'm tempted to say something like `why on earth would you want your web browser to make noises' but I suspect I'll get shouted down :-).
<ogra> what pitti said
<pitti> Diziet: some i386 people want flash :)
<Diziet> pitti: Do we know whether ff opens it only when it wants to use it ?
<Diziet> only on thin clients> Well, indeed - on remote sessions of any kind.
<Diziet> pitti: Fools, I tell you :-).
* pitti wholeheartedly agrees :)
<ogra> Diziet, tell that to the webdesigners :)
<pitti> mdz: so, don't be afraid of killing esd :)
<Diziet> Anyway.  So, the only available answers are: (a) break ff (or other) sound under some circumstances by setting FIREFOX_DSP (b) make esound as threadsafe as ff wants.
<Diziet> pitti: You've looked at esound.  Is it _trying_ to be threadsafe ?
<pitti> Diziet: not at all
<pitti> Diziet: Mithrandir added a mutex to the init function, but that doesn't even remotely catch all cases
<pitti> it's full of global variables and such
<Diziet> How many entrypoints are there ?
<pitti> no idea
<pitti> that one patch seemed to work on amd64 at least
<Diziet> Well, yes, but now we have mdz as proof that the bug happens on i386 sometimes too.
<pitti> but apparently there are different races for any given number of bits
<Diziet> Presumably various other random crashes are due to this too.
<pitti> bah, we almost managed to make esound obsolete *sigh*
<pitti> Diziet: another idea: why not use alsa-oss by default?
<pitti> Diziet: does ffox support that?
<pitti> would be worth a try IMHO
<pitti> (not that I could test flash on ppc or amd64, though)
<Diziet> It seems to have esd and something called arts.
<pitti> arts is the KDE counterpart of esd
<j^> since 2 days flash keeps crashing firefox on i386 each time
<j^> Diziet setting FIREFOX_DSP="aoss"
<j^> is possible
<pitti> j^: that works? yay
<Diziet> j^: Oh, good.  I can't see that in this here runner script but we can hack that.
<j^> pitti i remember that it worked
<j^> have to check with the current state again..
<Diziet> Umm.
<Diziet> -anarres:firefox-1.5.dfsg> find -type f -print0 | xargs -0 grep aoss
<Diziet> -anarres:firefox-1.5.dfsg> 
<pitti> Diziet: it would avoid another level of indirection and -- ssshhhhh ---- break ltsp
* ogra listens up
<pitti> ogra: look behind - a three headed monkey!
<AlinuxOS> pitti, hello :)
<ogra> lol
<pitti> hi AlinuxOS 
<j^> speaking of flash flashplayer-mozilla should be dumped from the archives, flashplugin-nonfree is the same but a newer version
<ogra> pitti, i'm not sure that tweaking ff necessarily means that flash wont output to the same device ...
<Diziet> widget/src/gtk2/nsSound.cpp is only 350 lines or so.  Maybe I could make it threadsafe.
<ogra> pitti, and flash is the only intresting part here for ltsp ...
<j^> what about java?
<pitti> ogra: with 'same device' being?
<ogra> whatever you choose for FIREFOX_DSP
<mdke> Kamion, i updated the wiki licensing spec with what was discussed last night. Haven't touched the draft email yet tho, I'll leave it to you
<ogra> afaik esd is hardcoded in flash
<pitti> ogra: it's probably meant for things like the commercial flash plugin which only understands oss
<pitti> ogra: are you sure? that sounds just weird
<pitti> I watched flash even under fvwm when I didn't even know about esd...
<ogra> pitti, iirc you have to have a certain version of libesd to make flash happy
<ogra> its linked very tight to this lib
<ogra> so i doubt the env variable will have any influence ...
<pitti> ogra: aah, right, I remember that bug
<pitti> sb wanted a symlink libesd.so.0 to so.1 or so
<ogra> yup
<keherman> tepsipakki, my user is not being added to the group on login!
<keherman> tepsipakki, even with pam_group!
<ogra> i think the env variable is only used for mime content like wav's in websites
<Kamion> mdke: thanks
<mdke> t_y_
<j^> hm, flashplugin-nonfree is broken too, installing it in ~/.mozilla/plugins firefox crashes with The error was 'BadMatch (invalid parameter attributes)'.
<j^>   (Details: serial 118 error_code 8 request_code 146 minor_code 3)
<Diziet> This is really weird.  AFAICT what this wrapper script does is run      esddsp /path/to/firefox/binary    but my testbed has no esddsp program.
<Diziet> Do other people have a program `esddsp' on the path ?
<pitti> Diziet: I *think* esddsp is just a shell wrapper that LD_PRELOADs libesddsp.so
<j^> DapperDrake thats in esound-clients
<pitti> yes, indeed
<j^> Diziet 
<Diziet> Ah, which I didn't have installed.
<ogra> Diziet, on ltsp clients :)
<pitti> Diziet: so that lib intercepts open('/dev/dsp') and converts the calls to esound interactions
<ogra> its not there in the default desktop
<Mithrandir> mdz: I just arrived in my hotel room in London
<pitti> Diziet: does ffox' wrapper script call the libesddsp.so directly? or really calls esddsp?
<Diziet> pitti: (b)
<Mithrandir> Kamion: I merged it yesterday, but it didn't merge cleanly, so I'll have to fix that before committing and uploading.
<Diziet> And yes, esddsp is a shell script which LD_PRELOADs.
<Kamion> Mithrandir: ok, thanks
<Diziet> And the thing it redirects you to isn't threadsafe !  How lame.
<Diziet> This is just never going to work properly and we should disable it.
<Mithrandir> Diziet: or fix libesddsp.so
<Mithrandir> which is fairly easy.
<ogra> Mithrandir++
<Diziet> Is it ?  You've already tried to fix it once.
<Mithrandir> I fixed it for the init function.  A similar fix for the other (five or so?) functions should work.
<Diziet> Strangely, there's ./widget/src/gtk2/nsSound.cpp too which dlopens libesd.so.0.
<Mithrandir> the problem is plugins like flash, etc.
<j^> Mithrandir any sound output from firefox is the problem
<ogra> j^, other sound output is pretty seldom there ... flash will be the biggest usecase 
<Diziet> Presumably the reason mdz's crashes is that it's trying to produce a little sqrunk noise to say `have an error message'.
<ogra> thats should just be handed to gnome_sound_play() or something like that
<Mithrandir> however, don't we use dmix now?
<Mithrandir> like, by default
<pitti> Mithrandir: we do
<Mez> BenC, ping
<pitti> Mithrandir: but that doesn't help for programs that use the OSS emulation
<Mithrandir> pitti: oh, that sucks.  Why not, and can't it be fixed?
<pitti> Mithrandir: fabbione tried to fix it, but failed
<Mithrandir> Kamion: any chance you could test casper for me?  It's slightly hard with just my laptop and no cdrom.
<Diziet> So, the upshot is: Mithrandir, you're going to fix esound ?  And in the meantime we tell affected users to set FIREFOX_DSP=none.
<Mez> surely if someone includes somrthing into the ubuntu kernel - they should include the tools needed to make it work in buntu too ?
<Mez> or am i missing something
<Mithrandir> Diziet: uh, I didn't volunteer, no. :-)
<ogra_> grrrr....
<Kamion> Mithrandir: sure
<Kamion> Mithrandir: what do I need to test?
<Diziet> It's very tempting to say `Flash is not Free so not supported' and disable the sound.  But I think that's really too evil.
<BenC> Mez: pong
<Diziet> Mithrandir: So I'll take a look at esound.
<Diziet> But first, I need foood.
<Mithrandir> Kamion: a) does it work, like, in general.  b) does networking work?
<Mithrandir> Kamion: if a) good, if b) hooray!  (and if so, I'll release)
<Mez> BenC: you've added the bcm43xx driver to the kernel - is there any reason not to package up the fwcutter tool for it so it's useable
<Mithrandir> seb128: can I whine at you about some evolution issues?
<BenC> Mez: hopefully we will be able to distribute the firmware, I'm working on that
<seb128> Mithrandir: sure
<Mez> BenC: cool - but for now - do you have a problem with me packaging up the fwcutter for universe/multiverse?
<Kamion> Mithrandir: ok, give me an hour or so, just working on some partitioning stuff on the relevant machine right now and then I'll need to sync down new images
<ogra> Mez, that should rather go to main
<Mithrandir> seb128: why does evo have its own concept of timezone instead of using TZ or moving it into central gnome infrastructure (gconf)?  Why does it have a "week begins on" rather than using locale?  And can I have http://err.no/personal/blog/tech/2006-01-25-12-19_misunderstood_i18n fixed?  It should be trivial, and I haven't filed a bug since I was on an airplane when I discovered it.
<Mithrandir> seb128: also, why does the "day begins" thing in the preferences have a date and not just a time associated?
<Mez> ogra: most likely - but if Ben's working on being able to distribute the firmware ... then maybe not
<Mez> brb
<j^> using FIREFOX_DSP="aoss" im able to play many flash videos with sound at the same time
<doko_> Diziet, seb128: can we remove all references to /usr/lib/mozilla from the libnss*, libnspr* and firefox* packages? I think the largest user of these is gnome. did talk with dholbach yesterday, that the gnome packages already have the infrastructure to use nss-firefox.pc / nspr-firefox.pc pkg-config scripts
<seb128> doko_: no objection with me
<seb128> Mithrandir: most are bugs already known upstream. For the week start that's a feature though, locale are too broken to rely on them as showed by all the bugs we got with the panel calendar (maybe fixed with belocal now)
<Mithrandir> seb128: can't we rather fix the bugs in locales than work around them in random other parts of the system?
<Kamion> feature> yay for deciding things are too broken and reimplementing them thus ensuring that we have to fix them twice upon discovering that they're still broken
<Kamion> Tom Lord would be proud
* Mithrandir chuckles.
<Mithrandir> seb128: do you think they'd want patches for gnome 205137 for instance?
<seb128> Mithrandir: previous time I spoke with jbailey: 1- he didn't want to be responsible for locales datas, and nobody else neither 2- locales are not coherent between them and it's not clear on how week-1stday first_weekday etc should be used
<Ubugtu> Gnome bug 205137: "Configurable date formats in components [Was: Alternative date format for Birthdays] " Product: Evolution, Component: Calendar, Severity: enhancement, Assigned to: evolution-calendar-maintainers@ximian.com, Status: NEW http://bugs.gnome.org/show_bug.cgi?id=205137
<Mithrandir> seb128: there's a first_workday in locales too..
<jbailey> Creepy, ubugtu will look up foreign bugs?
<Mithrandir> jbailey: yeah.
<torkel> Mithrandir: I really hope that the date in "day begins" is a temporary bug. In 2.4 it shows only the time
<Mithrandir> torkel: it's there in my current dapper, at least.
<seb128> Mithrandir: current GTK way is to use (week_1stday + first_weekday - 1) % 7
<torkel> Mithrandir: yeah I noticed it too
<jbailey> seb128: They didn't like my fix to correctly use the number of days in the week as per the locale?
<seb128> Mithrandir: but it doesn't give coherent results because differents locales use week_1stday and first_weekday in different ways or somehting like that
<seb128> jbailey: what fix is that?
<jbailey> Lemme dig it out of my logs.
<Mithrandir> seb128: can't we get the semantics fixed, the bugs nailed and everybody go on, happily, then?
<jbailey> I remember that I had sent you what I thought was the right fix there.
<jbailey> Mithrandir: It's a bit complicated with locales
<seb128> Mithrandir: sure, but don't ask me to fix the semantic or the libc :)
<jbailey> (lagging a sec to get my bagel)
<Mithrandir> seb128: locales is easier now that we have the data outside libc, though.
<seb128> jbailey: and it's what has been picked after your comments and my discussion with upstream IIRC
<seb128> Mithrandir: right
<Mithrandir> seb128: btw, why the NIH TZ handling?
<ogra> seb128, is the g-s-d patch to support more than one login already gone into our package  ? 
<seb128> ogra: I don't think so, it didn't go upstream, nobody wants to review it
<jbailey> Mithrandir: Locales can set on of two calendar dates to start counting their weekdays on.
<seb128> ogra: it's not likely to go for dapper
<jbailey> So first day of the week can *either* be Saturday or Sunday.
<ogra> seb128, damned, thats a showstopper for edubuntu and ltsp
<jbailey> Then there's a locale offset from that to determine the actual first day of the week.
<Mithrandir> jbailey: uhm.  crack?
<jbailey> Mithrandir: It's part of the ISO standard.
<Mithrandir> jbailey: what's the use case for that?
<jbailey> Mithrandir: NFC
<Kamion> First day of the week vs. first day of the working week, I assume?
<jbailey> Mithrandir: Probably something to keep people from storming out of Debian or some such like that. ;P
* jbailey hides.
<Mithrandir> Kamion: there's a first_workday too.
<jbailey> Kamion: Nope, work week is different.
<Mithrandir> there's a friggin "week-ndays" and "cal_direction" in there too..
<jbailey> Right.
<zakame> evening devs :)
<jbailey> Because who says a week has 7 days?
<Mithrandir> somebody smoked too much crack when that standard was written, I'd say.
<Kamion> (are there any locales where it isn't?)
<HrdwrBoB> Kamion: that's no reason not to include it.. what if at some point in the future it changes!
<jbailey> Kamion: Not currently, but I think the idea is probably to reach out to traditional calendars for some groups.
<jbailey> Kamion: As in, it would be nice to not redesign the software when we finally figure out how some group deep in the jungle needs to count days.
<Kamion> HrdwrBoB: I know, I was just curious
<Mithrandir> HrdwrBoB: it's called "second system effect".
<HrdwrBoB> yeah
<Mithrandir> jbailey: apart from the fact that no software will actually support it, because it has never been tested.
<jbailey> Mithrandir: *shrug*
<Mez> BenC, have you enable ipv6 in the kernel aswell?
<jbailey> Mithrandir: I suspect a remarkable amount of it would break in subtle ways, but at least the fix for it is known.
<BenC> Mez: We've always had ipv6 enabled (atleast it was in breezy)
<Mez> o_O
<Mez> weird - then it cant be that causing the problems
<ogra> its enabled since warty
* Mez must just be having problems with this driver then
<seb128> Mithrandir: for the %c comment, there is some such discussion for gnome-panel: http://bugzilla.gnome.org/show_bug.cgi?id=102635. Their concern is the 12/24 hours variants you don't have when doing that
<Ubugtu> Gnome bug 102635: "Make hour format easier to localize" Product: gnome-panel, Component: clock applet, Severity: trivial, Assigned to: gnome-panel-maint@gnome.bugs, Status: REOPENED
<jbailey> seb128: Feh, I don't seem to have it in my IRC logs.  Did we chat about it in some bug report somewhere instead?
<seb128> jbailey: locale stuff? no, by query
<Mithrandir> seb128: that's just the hours, I care a lot more about the date than the hours.
<Mithrandir> seb128: currently, I get US-style dates in evo, which is _very_ wrong in .no. :-)
<jbailey> Hrm.
<jbailey> I wonder if I was on a different machine.
<ogra> Mithrandir, so just move to the US... problem solved :)
<Mithrandir> ogra: hahaha
<zakame> lol
<seb128> Mithrandir: because you use an english locale?
<Mithrandir> seb128: no, I don't
<seb128> jbailey: sep 29 according to my log
<Mithrandir> seb128: I use nb_NO.UTF-8, but evo isn't translated to Norwegian, it seems.
<Mithrandir> seb128: it's wrong to use regular gettext to translate something which should be handled by LC_TIME.
<seb128> right
<seb128> for dates their is no reason to not do it that way
<jbailey> seb128: Hmm, I think I may have been working off my laptop then, so I won't have logs.
<seb128> as pointed they don't do it for hours because of the 12/24 issue
<seb128> jbailey: what where you looking for?
<jbailey> seb128: What I had suggested to use instead of % 7
<jbailey> seb128: It won't change the current problem.
<Mithrandir> seb128: sure, and I can understand that 12/24 is more of a like/dislike thing than dates.  If you don't like the output of date +%c, just use a different locale for LC_TIME. :-)
<Mithrandir> hi Scott
<jbailey> Mithrandir: nb_NO has first_weekday 2
<Mithrandir> jbailey: yes, and with day="sndag;mandag;tirsdag;onsdag;torsdag;fredag;lrdag" that's fine.
<Keybuk> rah
<seb128> hi Keybuk
<Mithrandir> jbailey: the first day of the week is Monday in Norway.
<jbailey> Mithrandir: And it looks like nb_NO is a 19971130 locale.
<Mithrandir> what does that mean?
<jbailey> Mithrandir: That the first one there is correctly sndag
<mvo> hello Keybuk 
<jbailey> Mithrandir: So it looks like the locale is correct then?
* Keybuk hugs everyone
* jbailey hugs Keybuk
<Mithrandir> jbailey: yes, at least it's correct in the calendar after I whipped locale-gen a little some time ago.
<Mithrandir> jbailey: it has first_workday=1 which is obviously wrong, though.
<jbailey> Oh, I see.
<seb128> locales are a mess atm :/
<jbailey> Do you have this filed?
<jbailey> I need to do an update from Belocs again anyway, so I can sort that out with Denis/
<Mithrandir> jbailey: no, no bug filed.  Does belocs have a BTS or do you want it in malone?
<jbailey> Malone, please.
<Mithrandir> seb128: the right fix is to fix it, though.  Not encapsulate it. :-)
<jbailey> I won't remember it otherwise.
<jbailey> Mithrandir: Debian is switching to Belocs as well, so it's good to get these fixed. =)
<ogra> Keybuk !!!
<ogra> you broke my wlan !
<Mithrandir> jbailey: \o/ :-)
<Kinnison> hey keybs
<pitti> Hi Keybuk 
<Mithrandir> jbailey: 29657 is yours
<seb128> Mithrandir: the change mentionned by your blog fixes what dates? the ones displayed in the list of messages?
<Mithrandir> seb128: in the "edit event" window.
<Keybuk> ogra: I did, how did I do that?  I fixed most people's :p
* jbailey needs a smart bookmark for Malone bugs now...
<Keybuk> jbailey: I have "https://launchpad.net/malone/bugs?id=%s" as "ubuntu <bug #>"
<jbailey> Keybuk: Thanks!
<ogra_> $%&%&%
<jbailey> Keybuk: Works lovely, thanks.
<Keybuk> ogra: I did, how did I do that?  I fixed most people's :p
<Keybuk> or do you get bitten by "/etc/resolv.conf not writable" ? :)
<Mithrandir> seb128: http://err.no/tmp/Screenshot.png
<ogra> Keybuk, it seems wireless-rate is ignored in my interfaces file now
<sivang> Keybuk: https://launchpad.net/distros/ubuntu/+source/ifupdown/+bug/29654 , sorry that I didn't give pkg version, I Wasn't sure ifupdown was to blame
<Ubugtu> Malone bug 29654: "On last upgrade in dapper, 'auto eth1' was duplicated such that network was down on reboot." Fix req. for: ifupdown (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<Keybuk> ogra: paste your interface file?
<ogra> Keybuk, my broadcom card only works at 1M 
<seb128> Mithrandir: ok, thank you, I'm bugging upstream about it
<Mithrandir> seb128: excellent, thanks.
<Keybuk> sivang: yeah, they get dup'd; but I didn't think that was a problem
<seb128> np
<Amaranth> ogra: your broadcom works?
<Keybuk> ifupdown doesn't care about such dups
<sivang> Keybuk: who's shipping that file?
<ogra> Keybuk, http://pastebin.com/522274
<ogra> its a trivial one ...
<sivang> Keybuk: I tried to assign it to you but selecting validAssignee times out :-)
<ogra> worked until the lats upgrade
<Keybuk> sivang: hmm, you haven't upgraded
<Keybuk> uh
<Keybuk> ogra: hmm, you haven't upgraded
<Keybuk> sivang: ok thanks, I'll look into it
<ogra> Keybuk, since when ? 
<Keybuk> ogra: yesterday
<ogra> Keybuk, i upgraded yesterday night the last time 
* Keybuk plays hunt-the-assign-to-me
<ogra> to test g-p-m
<Keybuk> ogra: that interfaces file hasn't been converted :-/
<Kinnison> Keybuk: click the task, tick "assign to me", hit the submit button
<Keybuk> Kinnison: if I click the task, I don't see an editable form
<Keybuk> just a table-o-text
<Kinnison> Keybuk: Umm, are you logged in?
<Keybuk> Kinnison: yup
<ogra> Keybuk, all i have in update-managert is todays bzr build, any action i can take to convert the file ? 
<Kinnison> Keybuk: bug nr?
<Keybuk> Kinnison: waahhhh, I just went back, and clicked again, and I got an edit box this time
<Keybuk> ogra: /usr/share/ifupdown/upgrade-from-hotplug.pl < /etc/network/interfaces
<Keybuk> ogra: see if that leaves the mapping thing there
<Keybuk> oh
<Keybuk> ignore me
<Keybuk> sorry
<Keybuk> misread your file
<Kinnison> Keybuk: were you log logged in when you first loaded the page?
<Keybuk> Kinnison: yup
<Keybuk> Kinnison: yet another launchpad "Not logged in"/"Already logged in" bug I think
<Kinnison> Keybuk: probably one of those, yes, sorry you hit it
* Kinnison once again whinges that our sessions are in a zodb rather than the sodding database
<Mithrandir> ogra: do you have any bugs on "c-u should delete the password field" for gss, or do you want me to file one?
<Keybuk> ogra: you know you don't have an "auto eth2" line, right? :)
<ogra> Keybuk, it appears as if the "dont wait for dhcp" also became a "dont wait for iwconfig" thing
<Keybuk> ogra: shouldn't be, that was done with an argument to dhclient <g>
<ogra> Keybuk, yes
<Keybuk> ogra: what does "ifup -n eth2" say (assuming it's down?)
<ogra> it cant start the interface on first attemt ... 
<jbailey> seb128: I've sent Denis an email to work on getting these bugs sent upstream.  Should be all good soonish, I hope.  I see that first_weekday is broken for most locales by the look of it.
<sivang> Keybuk: should I break net again to show you the error msg when having the dup?
<Keybuk> sivang: sure, attach it to tbe bug
<seb128> jbailey: cool, thanks
<sivang> Keybuk: ok, I'll break it again then :)
<jbailey> seb128: You said that the locales are a mess.  Is there other places whre you're having specific troubles?
<ogra> Keybuk, dhclient3 -nw -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
<Keybuk> ogra: did it not run anything else?
<ogra> nope
<Keybuk> cute, ifupdown bug then
<Keybuk> nothing I broke
<ogra> only run parts in front and after ... 
<ogra> but no scripts there 
<Keybuk> uhh
<Keybuk> so you lied
<ogra> ogra@edubuntu:~$ sudo ifup -n eth2
<ogra> run-parts  /etc/network/if-pre-up.d
<ogra> dhclient3 -nw -pf /var/run/dhclient.eth2.pid -lf /var/lib/dhcp3/dhclient.eth2.leases eth2
<ogra> run-parts  /etc/network/if-up.d
<Keybuk> dude, when reporting problems it helps if you *REALLY* give everything it runs you know
<Keybuk> thankyou, that's better :)
<ogra> thats the exact paste
<Keybuk> right
<Keybuk> so what's in /etc/network/if-pre-up.d
<sivang> hmm weird
<ogra> wireless-tools
<sivang> I ifdown'd my iface and i can still use network
<ogra> executable ...
<seb128> jbailey: no, just got a zillion of "my gnome-panel calendar start on the wrong day bugs" in various locales
<Keybuk> ogra: and does that have anything that looks at $IF_WIRELESS_RATE ?
<pitti> seb128: mine too :/
<ogra> Keybuk, yup
<ogra> Keybuk, looks fine even
<seb128> pitti: fix your locale, you are the locales master no? :)
<Keybuk> ogra: *shrug* then I don't see the bug :)
<Keybuk> ogra: stick a "set -x" at the top of that script and try again
<pitti> seb128: if it's a locales bug, sure
<ogra> Keybuk, the rate got set fine when it waited for dhcp
<seb128> pitti: it is a locale bug :)
<Keybuk> ogra: <jedi mind trick> that is not the change you are looking for
<seb128> pitti: you should probaly have first_weekday=2 or something
<ogra> Keybuk, yes, i'm aware :)
<pitti> seb128: I do have this
<ogra> Keybuk, set -x still gives the same output for  ifup -n eth2
<seb128> pitti: what about week-1stday ?
<pitti> seb128: maybe the calendar starts counting from 0 or from Monday?
<Keybuk> ogra: bah, uh ... "exec 2>/tmp/test.log" before the set -x
<Keybuk> then read /tmp/test.log
<pitti> seb128: there's no such thing in the locale definition
<seb128> $ locale -k -c LC_TIME | grep week
<seb128> week-ndays=7
<seb128> week-1stday=19971130
<seb128> week-1stweek=0
<seb128> first_weekday=2
<seb128> for my locale
<pitti> week    7;19971201;4
<pitti> for mine
<seb128> (week_1stday + first_weekday - 1) % 7
<pitti> probably the same in a compressed format
<seb128> is the way it's calculated
<seb128> 19971130 == 0
<Diziet> doko: No, I don't have an objection, but I'd like to know the reason ...
<seb128> 19971201=1
<pitti> seb128: 19971201 was indeed a Monday
<ogra> Keybuk, it doesnt get created :/
* sivang is away for some more time
<doko> Diziet: to install libnss4 and mozilla-browser at the same time?
<seb128> pitti: you have week-1stweek=4 ?!
<pitti> seb128: so that's (Monday + 2 - 1) % 7 = Tuesday
<seb128> right
<pitti> seb128: no idea what this number is for
<seb128> you should have week-1stday=19971130
<pitti> so 1stday must be a Sunday?
<Keybuk> ogra: ok, so that script isn't being run
<jbailey> pitti: No, 1stday is set arbitrarily.
<ogra> Keybuk, yup, exactly
<jbailey> pitti: Beyond that, all items are relative.
<pitti> jbailey: and first_weekday is an offset to that which points to monday?
<Keybuk> ogra: we've seen this ifupdown bug before, no idea what causes it though
<Keybuk> it happens in breezy a lot
<ogra> Keybuk, the card doenst expose any wireless capabilitys .. 
<jbailey> pitti: one indexed, and to whatever day is the start of your week.
<Keybuk> uh, just to confirm, btw ... you are running without the "-n" right? :P
<ogra> err, nope 
<ogra> wait...
<jbailey> pitti: Is this de_DE?
<pitti> jbailey: ok, then this is severely screwed; I'll compare it to the old glibc ones
<pitti> jbailey: yes
<ogra> Keybuk, ah, it gets run 
<ogra> and tries to set the right values
<ogra> but the card still doesnt pick up the 1M+
<Keybuk> then I don't see how this is my bug :)
<Diziet> doko: mozilla-browser comes with a libnns ?
<Keybuk> driver problem, perhaps?
<ogra> it didnt appear before yesterday
<Keybuk> out-of-order iwconfigs?  (wireless-tools bug)
<Keybuk> did you get a new kernel yesterday too?
<Diziet> The reason I left it all in /usr/lib/mozilla was for the benefit of embedders like epiphany.
<ogra> yup
<\sh> Keybuk: did you see the problems of n-m only with atheros wlan chipsets or with any wlan card?
<Keybuk> \sh: just atheros so far ... it's a "bug"/"mis-feature" of the madwifi drivers
<jbailey> pitti: Now that we've reunified the locales definitions, do I still need to install the language pack to get that locale?
<ogra> err, nope, the new kernel was on monday iirc
<Keybuk> ogra: *shrug* well, I don't see how any change I made could cause this
<pitti> jbailey: no, sudo locale-gen <locale> does what you want
<Keybuk> the right command is getting run at the same point it always has
<ogra> Keybuk, i always needed to initialize the iface twice... 
<\sh> Keybuk: because I have the wifi signal drops and rescans as well with a ndiswrapper card and atheros (without n-m, just plain network config)
<ogra> thats why its not set to auto
<jbailey> Keybuk: The atheros interfaces are "ath#" and such, yes?  If yes, I also have one.
<jbailey> (acquired last week)
<Keybuk> jbailey: aye
<doko> Diiziet: no, but with /usr/lib/mozillalibnssckbi.so
<Keybuk> \sh: that would fit the hypothesis that the bug is in the HAL ... as the Windows and Linux drivers share the same HAL
<Keybuk> madwifi-ng is said to fix it, and the primary change there is a new HAL
<\sh> Keybuk: well, I blame my wifi router, this problem is described as hw bug of the linksys wrt54g/gs rev 3 
<Diziet> doko: Why shouldn't it use the one from libnss4 ?
<Keybuk> \sh: no, your drops are definitely madwifi related :)
<bddebian> Morning
<Keybuk> \sh: the madwifi driver cannot scan and hold a network at the same time
<\sh> Keybuk: I have them with ndiswrapper cards as well :)
<Keybuk> if you want to scan, you have to disassociate from the network/essid/channel you were locked on
<Keybuk> \sh: I don't know/care much about ndis :)
<bddebian> doko: ping?
<Diziet> doko, seb128: So is it the case that epiphany et al will cope ?  How do they know where to look ?
<\sh> Keybuk: but to be sure, I have to test the different cards with a different wifi router to share your opinion :)
<doko> Diziet: please! there are differences, eclipse doesn't work with the firefox plugin
<doko> it did until 1.0.x, breaks with 1.5
<doko> bddebian: pong
<bddebian> doko: Do you know why the malone python-numeric merge bug appears to still be open?
<jbailey> pitti: So it looks like the only problem is that someone has incorrectly added first_weekday 2 to the de_DE, right?
<seb128> Diziet: apps should get their paths on build from the .pc
<jbailey> pitti: The rest of it looks right.
<pitti> jbailey: well, whatever that '4' is for
<seb128> Diziet: that should be fine (but I've not tried)
<jbailey> pitti: The year started on a Thursday. =)
<pitti> jbailey: but right, fixing s/2/1/ should be enough
<Diziet> doko: OK, OK, I'm just asking.  I'm not fighting here.  I just want to understand all of the angles.
<jbailey> pitti: (ISO 8601)
* Diziet adds it to the ff todo list.
<doko> Diziet: it's right, that builds hardcoding the include and libdir will break, but that should not be that many
<doko> bddebian: no, I didn't look
<jbailey> pitti: http://anubis.dkuug.dk/jtc1/sc22/wg20/docs/14652fcd.txt if you're looking for the details.
<mvo> Diziet: speaking about ff, any news from the pygtkmozembed crash problem? (
<pitti> jbailey: thank you
<bddebian> doko: Well you appear to be assigned 3123 also.. ;-)  python-numeric-tutorial doesn't still use python2.3 does it?
<mvo> malone #26436
<Ubugtu> Malone bug 26436: "gtkmozembed crashs with python" Fix req. for: firefox (Ubuntu), Severity: Normal, Assigned to: Ian Jackson, Status: Unconfirmed http://launchpad.net/bugs/26436
<jbailey> pitti: Do you want to file the bug or shall I?
<pitti> jbailey: there already is one AFAIK
<jbailey> pitti: 'k
<bddebian> Ahh, it feels good to be back bugging people.. ;-)
<pitti> jbailey: bug 5387 AFAICS
<Ubugtu> Malone bug 5387: "clock-applet: first day of week" Fix req. for: glibc (Ubuntu), Severity: Normal, Assigned to: Martin Pitt, Status: Unconfirmed http://launchpad.net/bugs/5387
<bddebian> This is probably a dumb question but why does apt-get dist-upgrade puke but it's fixed with an apt-get -f install?
<mvo> Keybuk: a quick question about dpkg. when it is given a long list of --unpack and then --configure and one of the items fails (unpack with file override problems, configure with bad maintainer script) will dpkg stop? or continue processing the list? it seems like unpack continued in my quick test, but configure didn't. but that seems a bit odd :)
<bddebian> And I have soo missed talking to myself...
<Keybuk> mvo: I think it continues until two or three things have gone wrong
<azeem> bddebian: well, it's a question for #ubuntu...
<Diziet> mvo: I've still got that on my list, but I haven't done anything about it.  Sorry.
<bddebian> azeem: Which question :-)
<mvo> Keybuk: thanks, I guess I won't be able to avoid peeking into the dpkg source then
<mvo> Diziet: thanks, I'll have a look at it again now
<bddebian> azeem: And why is the dist-upgrade a #ubuntu question anyway?  Is that expected behavior?
<\sh> oh..I just forgot...
<\sh> regarding https://launchpad.net/distros/ubuntu/+source/libcgicc/+bug/6420
<Ubugtu> Malone bug 6420: "not able to link cgicc anymore" Fix req. for: libcgicc (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Fix Committed
<kent> bddebian: this is not a support channel
<bddebian> kent: Really?
<\sh> for breezy it needs just an rebuild...can we do that as breezy-update?
<kent> bddebian: read thetopic.
<bddebian> kent: That was sarcasm
<azeem> bddebian: "puke" doesn't help anybody, if you don't have a concrete error, there's not much the developers can do about it.  And I guess dist-upgrade is expected to fail from time to time for development distros
<Kamion> if you don't get help here, at least please refrain from being sarcastic about it
<caugier> hi there, i'm seeking info on how to customize the kernel on the new livecd infrastructure.
<caugier> does anybody know ?
<bddebian> azeem: libnotify fails trying to overwrite itself on a dist-upgrade but -f install resolves it.  Shouldn't a dist-upgrade handle it properly?
<Kamion> caugier: install your customised kernel and the casper package on your development system, update-initramfs -u, dump the kernel and initrd from /boot/ into /casper/filesystem.{vmlinuz,initrd.gz} on the CD, possibly customise the modules in the live filesystem as well (as you would've done with the old live CD)
<siretart> \sh: you asked earlier about NM and madwifi: yes, madwifi sucks in this regard. madwifi-ng has its issues, too: http://madwifi.org/ticket/70
<caugier> Kamion: oh, as usual then, i thought it was supposed to change
<caugier> Kamion: to be simplified, cause generating the udebs is quite complex
<Keybuk> siretart: hmm, that just looks like someone doesn't understand madwifi-ng
<Keybuk> you have to actually add interfaces to your card after detecting it
<Kamion> you don't have to generate the udebs any more; the business with the casper package and update-initramfs replaces that
<Keybuk> it's a bit strange
<\sh> siretart: nono....what I was saying is, that I can't test the behaviour of n-m and madwifi compatible cards in a sane way, because my router has a known problem with dropping wlan connections every now and then and in a reproduceable timeframe (every 1-2 minutes). this happens with all wifi cards I have tested so far...so I can't ack Keybucks statement, that those signal drops are results of madwifi and n-m...
<caugier> Kamion: nice, i'll try that thanks
<siretart> Keybuk: madwifi-ng is targeted for dapper, no?
<Keybuk> siretart: yes, but it's also potentially not ready for dapper
<siretart> \sh: I have madwifi as well, and I know that madwifi does drop connections on scan, which really sucks
<Keybuk> we'll know next week
<siretart> Keybuk: do you need help with testing?
<\sh> siretart: which router?
<Treenaks> how about bcm43xx? :)
<Keybuk> siretart: first I need to install madwifi-ng :)
<siretart> \sh: it happens with all routers.
<siretart> Keybuk: oh! I see :)
<ogra> Treenaks, worked here until yesterday :P
<Keybuk> though testing n-m on any other card would be most welcome
<Treenaks> ogra: I have a mac mini, it never worked
<Keybuk> siretart: uh, what was that bug# again?
<siretart> Keybuk: bugno for what? this one? http://madwifi.org/ticket/70
<Keybuk> no, malone bug
<mvo> Keybuk: is it possible that dpkg dosn't log errors in it's /var/log/dpkg.log?
<siretart> I don't remember a malone bug for madwifi-ng
<Keybuk> mvo: it doesn't log errors
<Keybuk> siretart: the one you just filed, and couldn't assign to me
<Keybuk> or was that sivang ?
<mvo> Keybuk: is this inentional? or a missing feature? 
<Keybuk> mvo: intentional
<mvo> Keybuk: I guess because the calling user/app has to deal with it and dpkg falls back to a good state anyway?
<mvo> Keybuk: I'm pondering over the problem that a single broken package can ruin a dist-upgrade in pretty specatular ways, leaving half the packages unconfigured. it's certainly a problem of apt, but it might need a bit of dpkg assistance
<Keybuk> dpkg logs the states all of the packages are left in
<Keybuk> but yeah, the theory is that dpkg never leaves things in a "broken" state
<Kamion> I think mvo is probably using a different definition of "broken"
<siretart> Keybuk: err, I filed malone #29634, but I think this is something for either BenC or mjg59 
<Ubugtu> Malone bug 29634: "usb dead after hibernate/resume on Thinkpad R40-2772-B3G" Fix req. for: linux-source-2.6.15 (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29634
<Kamion> (?)
<siretart> I think you confused me with someone
<Keybuk> ok, I'm confused then :)
<Keybuk> Kamion: possibly
<siretart> :)
<Keybuk> there's certainly the difference between "package is in a valid, but unexpected state" and "package works"
<Keybuk> I've always maintained that dpkg only cares about the former, and it's up to dselect, APT and friends to care about the latter
<mvo> I think we are talking about the same things then, yeah
<mvo> the problem is that apt does multiple dpkg invocations and stops if one of them goes wrong
<Diziet> This esddsp preload thing is on crack.  Completely insane.
<mvo> that can be in the middle of a dist-upgrade
<ogra_ibook> oooh, new kernel love :) 
<ogra_ibook> looks like i'll have sound again today :)
<Keybuk> Kamion: could you glance at malone #29224 for me ... am I on crack?
<Ubugtu> Malone bug 29224: "Network Interfaces at Install Time" Fix req. for: Ubuntu, Severity: Normal, Assigned to: Scott James Remnant, Status: Unconfirmed http://launchpad.net/bugs/29224
<alpopel> hi. i've got a question... where can i find an up-to-date-sources.list for dapper??
<tseng> take whatever your sources.list is for dapper
<tseng> er for breezy
<tseng> and s/breezy/dapper
<alpopel> well. or what is the problem with my sources.list??    http://paste.ubuntuusers.de/1547
<Keybuk> silly question ... what do we assign kernel bugs to now?
<tseng> if you cant make sense of what I just said, you are probably in the wrong channel.
<Kamion> Keybuk: it's true that netcfg only ever configures one interface, but that's kind of non-trivial to change
<Kamion> Keybuk: but I'd have expected netcfg to at least offer all available interfaces
<Keybuk> Kamion: that's what I thought
<Kamion> Keybuk: unless link detection showed that the wired interface wasn't connected
<Kamion> in which case surely he'd lose anyway
<zul> Kamion: my email says kernel-bugs
<Kamion> I agree it'd be nice to make e.g. all hotpluggable interfaces ifuppable
<Diziet> I'm sorry, but this is just too horrid.  I'm not going to spend days fixing this hideous and hugely invasive LD_PRELOAD hack.  Sound from Flash can go and hang.
<Kamion> or just all interfaces, whatever
<Keybuk> Kamion: would that be difficult do you think?
<Kamion> Keybuk: not sure
<Kamion> I'd have to swap out all the bits of my brain that are thinking about partitioning and swap in the bits that know about networking
<Keybuk> fair enough, let's chat next week instead
<Diziet> Can I make a bug affect two things ?
* Kamion nods
<Keybuk> Diziet: yes, just repeatedly click "Request fix" things
<Diziet> When I submit by email.
<Keybuk> Diziet: two " affects blah" should do it, yup
<Diziet> OK, well, I'll see what it does.
<mdz> ogra: please look at tuxpaint and see what it uses netpbm for, see if the dep can be avoided
<ogra> hmm, iirc i removed that dep for breezy ... 
<mdz> it's there in dapper
<ogra> hmm, was there in breezy as well, seems i remember wrongly
<ogra> i'll try to get rid of it ...
* bddebian breaks out the pistola
<\sh> http://www.desktoplinux.com/news/NS7418276314.html <- anyone knows about this? UbuntuUSB with license key for $30 ?
<Keybuk> \sh: interesting ... though that kind of thing's supported out of the box in dapper
<stratus> Keybuk, i think the problem is with the name.
<ogra> Keybuk, without changing your bios to boot from usb ? 
<\sh> Keybuk: well...I don't mind, but I'm surprised about this statement
<\sh> "We are in a co-marketing position, to promote the operating system with the licensing staff of Ubuntu," Darbonne told DesktopLinux.com in an email. "We do have the right to bundle Ubuntu with our closed source software and/or hardware as long as we give a way to get the source code of Ubuntu.
<\sh> the question which is not answered, if they are allowed to use the brand Ubuntu :)
<jsgotangco> wow
<Keybuk> ogra: sure, you can use the livecd or any other bootable to bootstrap it
<\sh> or the tmed named 
<Keybuk> \sh: *shrug* that's not an ubuntu-devel issue though, that's an ubuntu-silbs issue :p
<stratus> FYI, they are using the ubuntu affiliate logo
<ogra> Keybuk, without changing my bios to boot from the install device ? 
<stratus> http://www.zinside.com/index.php?main_page=product_info&products_id=76&zenid=67ed0b969a8b5455af2abfa9f34452b9
<Keybuk> ogra: I'd reject that claim if they're making it ... how do you boot from something without changing your BIOS? :p
<ogra> " * No BIOS configuration needed"
<\sh> ogra: you need to boot from a cd to boot from your usb device (that's how I understand that)
<ogra> Keybuk, no idea, but thats what they state 
<Keybuk> aye, I understand that they have a boot floppy or CD if you can't change your BIOS
<ogra> tsk
<\sh> it's totally useless
<ogra> yes, it says that under "Required configuration:"
<ogra> silly
<\sh> how can i boot from a cd, if I only have a usb cdrom, and I can't boot from usb?
<jsgotangco> stratus, that's a no-fee status though
<jsgotangco> (just signed terms and conditions)
<\sh> Keybuk: well, sure it's silbs issue :) or actually canonicals :)
<jsgotangco> but i guess they are capable enough :)
<Keybuk> eeevil -> sysvinit_2.86.ds1-6ubuntu6_source.changes
<ogra> Keybuk, ah, come on ...
<rob^^^> \sh: who is the licencing staff ;)
<\sh> rob^^^: ???
<ogra> Keybuk,  thats like saying 21216498623463 is an evil number 
<rob^^^> \sh: in the quote above it said they were talking with Ubuntu's licencing staff ;)
<rob> ?
<bradb> Malone UI feedback request: http://flickr.com/photos/84096161@N00/91063153/ -- an attempt at a table listing of bugs on packages to which you're subscribed. (The idea would be that this kind of look would also make its way into the existing reports.)
<\sh> rob^^^: no they said something else...but it's not for this channel :)
<ogra> bradb, wow clool, only one sidebar left 
<bradb> ogra: we can dream, right? ;)
<ogra> but thats way more usable :)
<rob> bah
<tseng> yeah there is a lot less confusing clutter
<bradb> I will include Ubuntu devs comments in a mail to launchpad@.
<bradb> Because my opinions on these things do zero to change the status quo. It's all about you guys.
<\sh> bradb: I love you guys when you can implement it very fast :)
<ogra> \sh, first it must get approved :P
<tseng> bradb: one question is, when I search, what am i searching?
<bradb> ogra: I *think* it'll be much easier to get approved with hard evidence of the disapproval of the three-column layout (got plenty of that yesterday) and hard evidence supporting a two-column layout.
<tseng> all bugs, ubuntu bugs, bugs on this package
<ogra> bradb, thats 100% UI improvement and will solve me from 2xscreenwitdht firefox windows :)
<tseng> i am guessing the last
<\sh> bradb: two side menus are evil...right side menus is good for right handed people...and left side menus is good for left handed people :) 
<ogra> s/solve/save
<tseng> which would make the label "search within results"
<\sh> s/is/are/
<nomed> hi all
<nomed> using the kernel 2.6.15.12-686 i had this error:
<nomed> mount: special device none does not exist
<nomed> that's gone with 2.6.15-13-686
<tseng> then there is no problem.
<nomed> i've seen in the mail list that one other person has that problem using
<bradb> tseng: Hm, interesting. I thought the label above the box would have been enough to say what's being searched. I'll ponder that.
<nomed> 2.6.15-13-386
<tseng> bradb: it might be
<nomed> do you know what it can be ?
<nomed> i normally use this cmd:
<nomed> mount -t unionfs -o dirs=/tmp/mytry=ro none /tmp/UNIONFS
<sbalneav> Morning all
<bddebian> Hello sbalneav
<ogra> morning scottie
<sbalneav> Hello ogra, bddebian!
<tseng> bradb: im really just having nightmares about the search on launchpad.net and /malone
<tseng> bradb: and applying them to your mockup (Which is nice)
<bradb> tseng: One thing at a time. :)
<tseng> yeah
* bradb starts writing email
<\sh> going home...laters
<ejofee> i think we should add this along with mc: http://mc.linuxinside.com/cgi-bin/dir.cgi#RELEASES
<jordi> pitti: pong_
<pitti> hey jordi, how are you?
<pitti> jordi: nevermind, I couldn't commit to Debian's pkg-alsa, but jdthood sorted that out
<jordi> I'm fighting libxklavier
<jordi> it semes it broke my desktop :)
<jordi> pitti: cool, welcome to the team :)
<jbailey> Oh, hmm.  We don't include linuxprinting.org-ppds in desktop?
<jbailey> I thought we did.
<pitti> 11 MB? holy shit
<pitti> jbailey: probably because postscript printers aren't that common?
<jbailey> Yeah, maybe.
<jbailey> I just thought that before the gnome printing thing had detected my Lexmark automatically.
<jbailey> pitti: 11,1Mo rceptionns en 18s (590ko/s)
<jbailey> =)
<pitti> 668B/s 4m54s - for an apt-get dist-upgrade; high-speed networking at it's finest *sigh*
<jbailey> Ouch
<pitti> erm, not even a dist-upgrade, just an install bzrtools *grumpf*
<jbailey> No, there must be something else.  Here.  I'm fairly certain that it saw and recognised the printer before, and even with these PPDs installed, the E210 isn't listed.
<jbailey> But this is the printer we all used at UBZ
<pitti> somehow ssh to rookery is incredibly slow right now
<jbailey> And it is in /usr/share/ppd/foomatic-rip/Lexmark
<jbailey> I wonder if it's just broken on PPC again.
<bradb> I've done some slight tweaks to the package bugs UI prototype: http://flickr.com/photos/84096161@N00/91073757/
<tseng> bradb: cool
<ogra> WOW
<bradb> Unless anyone changes their opinion to suckage because of those tweaks, I'm going to send the data I've collected to launchpad@ re: two-column vs. three-column layouts.
<tseng> bradb: im a big fan
<ogra> that looks very usable 
<bradb> cool
<tseng> oh
<tseng> the breadcrumb
<pitti> bradb: yay, no wasted space any more :)
<tseng> the page is showing bugs on just ubuntu firefox
<tseng> the breadcrumb stops at sample person
<tseng> there is presumably a navigation step between my person page and this page
<bradb> tseng: That's a tricky navigation issue, that I think is outside the scope of the reporting issue I'm trying to address. But I do agree that with your concern about that.
<pitti> bradb: so that rather useless personal info box is now confined to the actual people page, not to each and every page around?
<tseng> bradb: ok, i definately see other ways to get to what i want
<tseng> bradb: so its not a major problem
<pitti> bradb: btw, thanks for the comment+status change on one page
<bradb> tseng: The idea is that you'd click on a "Package Bug Reports" menu option from your personal page and land on a page that gives you an overview of your package bugs, then you can drill down to each one. (I haven't prototyped the overview page yet, but it'd be pretty simple.)
<tseng> bradb: i have pretty big problems with useless/confusing content, and navigation.. you pretty much killed off the first one in this set so
<bradb> pitti: re: useful info box, well, I'm trying to convince people that it should be gotten rid of, yeah. :) Hopefully sending the data I've collected to some decision makers will help push things in a positive direction.
<bradb> tseng: cool
<tseng> bradb: cookie from me
<bradb> heh
<pitti> bradb: did you get mdz's collection of 'worst griefs ever'?
<bradb> pitti: I don't recall seeing that, but we're /way/ past knowing what you guys dislike about Malone, tbh. :)
<pitti> heh :)
<bradb> We have huge amounts of documentation on this, e.g. wiki.launchpad.canonical.com/DistroTeamOneOnOne
<pitti> to be fair, I like the email interface a lot
<bradb> pitti: Did you see my update to the email doc?
<pitti> it was greatly missing in bz
<bradb> I announced the update on launchpad-users@. I made it, like, readble.
<pitti> bradb: no, I didn't; last time I wanted to look at it wiki.lp was offline, so I used the google cache
<bradb> er, readable
<pitti> bradb: rock
<bradb> http://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc should be an easier read
* pitti should really sub to lp-users
<tseng> im not sure how much you can say about it, but it seems like a pretty big problem if a certain person impeeds forward progress on making the product not suck
<tseng> when the rest of the world agrees that certain artificial requirements are crap
<pitti> bradb: just read it, that's much better; thank you
<bradb> cool
<Menoz> hi all
<Menoz> hi, I would like to set up an ubuntu repository
<Menoz> can someone tell me where can I find some information?
<LaserJock> Menoz: I would go to www.debian.org and under documentation you will find an APT-HOWTO. I believe it has info
<dholbach> I personally think it's better to get stuff into Ubuntu and work hard on doing so.
<dholbach> Letting users fiddle with apt/sources.list is cumbersome and it gets more attention once it's in Ubuntu.
<pitti> jbailey: ok for you if I steal bug 29657 from you?
<Ubugtu> Malone bug 29657: "first_workday wrong for nb_NO" Fix req. for: langpack-locales (Ubuntu), Severity: Normal, Assigned to: Jeff Bailey, Status: Unconfirmed http://launchpad.net/bugs/29657
<LaserJock> yeah, I agree with dholbach, but sometimes I have needed a local apt-repo for testing etc. google can be helpful there
<pitti> Menoz: man apt-ftparchive
<Menoz> ok, thanks to all! :)
<lamont__>   gpaint: Depends: libcairo1 (>= 0.5.2) but it is not installable
<lamont__> hrm...  I think hppa's edubuntu build may have a package or two out of date...
<lamont__> doko: ^^^ thoughts?
<ogra> lamont__, i'm just preparing a new metapackage, n the notification daemon changed its name back and forth ...
<lamont__> ogra: ah, ok.
<lamont__> the libcairo1 thing is more interesting...
<ogra> dunno about that, doesnt show up here 
<bddebian> The cairo stuff frightens me
<lamont__> ogra: yeah, it's some build-dep slippage that doko gifted hppa
<ogra> ah
<ogra> evil doko :)
<lamont__> there _is_ a reason why it's good to actually specify versioned build-deps when you need them...
<lamont__> then again, it might not have been doko - must be nice.
<doko> lamont__: just look at the first letter of the package, don't bother me with g* packages, ask seb128 ;-)
<lamont__> hehe
<seb128> roh
<lamont__> you're both evil, you know.
<ogra> lol
<seb128> how comes that libcairo1 is so outdated?
<lamont__> my real question is, 'what no-change upload do I need to do to make gpaint installable on hppa'
<doko> seb128: it's hppa ;)
<lamont__> because gpaint was uploaded for a transition before libcairo was built
<lamont__> so it happily used what was there
<seb128> and we have no binary-NMU?
<lamont__> since there wasn't a versioned build-dep
<lamont__> no binNMU in the archive
<seb128> hum
<lamont__> (well, except for that one back in warty, but I've repented)
<lamont__> I suppose I could just try rebuilding gpaint and see if (1) it builds and (2) installs
<seb128> just to a build1 upload
<ogra> yup
<ogra> since it works fine on all other arches
<lamont__> I'll test first, thanks,
<seb128> np
<Diziet> I sent a bug report to Malone by email a little while ago but haven't had an ack.  What does that mean ?
<seb128> that you should ask to #launchpad guys if that's normal :)
<bradb> I sent an email to launchpad@ (password-protected archives, unforunately), SteveA, sabdfl, and kiko containing the feedback you guys provided on the two- and three-column listings.
<pitti> did anyone else's network card does not work any more after dist-upgrading today?
<pitti> pretty frustrating, I get a 'eth0: link is not ready', but it is definitively a software problem (breezy works)
<ogra> pitti, hey i have the same here
<ogra> ADDRCONF(NETDEV_UP): eth2: link is not ready
<pitti> exactly
<pitti> but now I can't even dist-upgrade again in case it has been fixed
<pitti> ogra: but I don't remember a kernel upgrade today
<ogra> it works for me if i run dhclient manually ...
<pitti> I already spent an hour rebooting my home server, checking cables, checking from my friend's laptop and so on:/
<ogra> (after some iwconfig stuff, its my wlan iface)
<pitti> ogra: no, not for me; even if I manually configure an IP and route
<torkel> pitti: do you have /var/run/network ?
* pitti looks
<pitti> torkel: yes, I have
<Riddell> ops wanted in #ubuntu for usuarioribas
* lamont__ counts to 5, hoping someone else will grab it..
<pitti> torkel: if contains ifstate which looks sane; but even then, this shuoldn't affect the card at all
<pitti> torkel: maybe ifupdown pukes, but manual ifconfig/route/ping should still work
<torkel> pitti: true
<Keybuk> hmm
<Keybuk> I get that too
<Keybuk> but then it works
<ogra> pitti, mii-tool ? 
<segfault> why x11-common depends on laptop-detect?
<pitti> Keybuk: hm, maybe it's not relevant then
<Keybuk> what driver is your eth0 and ogra's eth2?
<segfault> that's weird, i don't want laptop-detect installed on my server.
<Keybuk> segfault: yes you do
<ogra> Keybuk, bcm43xx 
<Keybuk> segfault: because you don't want things being started that are for laptops
<segfault> keybug: what would be that things?
<segfault> err, keybuk
<segfault> sorry
<ogra> Keybuk, (i'd normally blame the driver for everything if you hadn't uplaoded the network stuff recently :P )
<pitti> Keybuk: skge
<Keybuk> ogra: the stuff I uploaded didn't change much
<Keybuk> so I don't see how it's a problem
<Fade> is there documentation on changing the module load order for a ubuntu system with two soundboards?
<Keybuk> Fade: yes, don't.
<Keybuk> Fade: there's no such thing as "module load order"
<Fade> I'm trying to understand the alsa setup in ubuntu.
<ogra> Keybuk, i got it working now, but apparently it only works if i give the MAC of the ap 
<ogra> wasnt needed before
<Keybuk> ogra: does removing the "auto" line, and doing ifup manually later work?
<Fade> It works on debian and gentoo..
<pitti> ogra: ok, given that I go through the hassle of downloading mii-tool here and carry the deb over to my desktop, what do I do with it?
<Keybuk> Fade: no it doesn't
<lamont__> Riddell: tossed
* Fade points at the debian machine with three sound boards sitting next to him.
<pitti> Keybuk: nb that even a manual ifconfig/route add default doesn't work
<Keybuk> Fade: is it running latest unstable, with 2.6.15+ and udev?
<ogra> Keybuk, i didnt try yet ... i wrote a script to make it work ... lemme try with the MAC in /etc.../interfaces
<Keybuk> pitti: then it's deeeefinitely not something I've done :p
<Keybuk> all I did was write a new init script, a udev rule and remove a warning from ifup :p
<Fade> 2.6.9/hotplug
<Fade> devfs
<Keybuk> Fade: then it predates the removal of module load orders from the kernel
<Fade> but the modules are being loaded manually.
<lamont__> seb128: gpaint -build1 uploaded, tnx
<seb128> np
<segfault> laptop-detect seems to be no overhead at all
<pitti> Keybuk: ok :) but since we hadn't had a kernel update I blamed the new userspace stuff :)
<Fade> Keybuk: is there any documentation on the issue?
<Keybuk> Fade: plenty, on wiki.ubuntu.com, lwn, lkml, etc.
<pitti> Keybuk: and it doesn't work with the previous kernel either, that's why I still blame userspace
<Keybuk> pitti: I don't know of anything in userspace we've changed at that level
<pitti> Keybuk: maybe it loads the wrong module for the card, or so
<Keybuk> if ifconfig doesn't work, that pretty much states kernel problem, doesn't it?
<Keybuk> could be, but that's a kernel problem too
<pitti> Keybuk: but if the kernel didn't change?
<Keybuk> pitti: I've seen a few kernel updates the last two days
<segfault> keybuk: i have a dapper image running on vmware, which was installed using LVM. However, after the latest kernel upgrade, i'm unable to boot it. For some unknown reason, it cannot find the SCSI drivers, but in the busybox shell, if i unload the modules, and load them again, it find the devices, and thus, the LVM stuff.
<pitti> Keybuk: aaaaaaah *headdesk&
<pitti> Keybuk: the recent upgrade swapped eth0 and eth1
<Fade> keybuk -- thanks for the pointer. I appreciate it.
<Keybuk> segfault: no idea, I've not been able to debug that yet
<pitti> Keybuk: I just compared breezy&dapper kernel logs 
<Keybuk> segfault: any and all help would be appreciated
<Keybuk> pitti: :)  yeah, there's no ifrename stuff at the moment
<Kamion> Keybuk: I'll be bringing a vmware installation to the sprint if you want to look at it there
<Keybuk> should have mentioned that somewhere <g>
<Keybuk> Kamion: excellent
<segfault> keybuk: i played around with "local-top/lvm", inserting some rmmods and modprobes before modprobing dm-mod. seems to work, but it's a ugly hack though.
<LeeJunFan> is it just me or is at least us.archive.ubuntu.com got non matching package list and actual files? ie. pool/universe/s/slib/slib_3a2-3_all.deb  File not found
<Keybuk> pitti: udev has at least some of the functionality of ifrename built into it
<Keybuk> so I plan to use and improve that, rather than using ifrename
<Keybuk> that'd solve the swapping interfaces bugs quite nicely
<torkel> yay :-)
<lamont__> pitti: /etc/iftab is your friend
<lamont__> I thought we auto-created that
<Keybuk> lamont__: nothing reads /etc/iftab right now :)
<lamont__> Keybuk: ah, ok
<lamont__> yeah, we should fix that for dapper. :)
<Keybuk> yes :)
<Nafallo> hehe
<Keybuk> but we only just got networking working again <g>
<lamont__> LOL
<Nafallo> network-manager must be <3 then. I never had any network-b0rkage :-)
<pitti> Keybuk: thanks; for now I'm just happy to have my desktop working again :)
<Nafallo> Keybuk: btw, http://www.magicalforest.se/~nafallo/bzr/ <-- current network-manager and dhcdbd in bzr :-)
<Keybuk> Nafallo: I'll look next week
<pitti> lamont__: thanks for the hint
<Keybuk> can you mail that url to me
<Nafallo> Keybuk: sure thing :-).
<pitti> lamont__: indeed, it has the 'correct' (i. e. my previous) ordering
<lamont__> pitti: yeah, what Keybuk said
<Keybuk> in theeeory, we could do something like:
<ogra> Keybuk, its still needs the second attempt and doesnt respect the bitrate at all, but it works again
<ogra> i noted that getting the address takes a lot longer and since the ifup command is nonblocking, its hard to notice when the interface is actually up
<Keybuk> SUBSYSTEM=="net", IMPORT{program}="iftab_helper --export $sysfs{address}", NAME="$env{NAME}"
<Keybuk> which uses the udev built-in rename interfaces stuff
<Keybuk> though we'd need some magic to allow swapping to work, not sure about that yet
<ogra> pitti, did you wait long enough for the interface to obtain an IP ? for me it comes up after some time ...
<Keybuk> ogra: yeah, I need to find a solution to that :-/
<pitti> ogra: already solved; eth0 and eth1 were swapped since /etc/iftab is not evaluated ATM
<ogra> ah, yes, i had that when my eth1 became eth2 last week :)
<Keybuk> hmm?  it only changed yesterday
<ogra> not for the broadcom driver it seems
<ogra> i had it with the 2.6.15-12 upgrade
<Keybuk> kooky
<bradb> DUDES!
<bradb> "I'm happy with the two-column layout there." -- sabdfl
<bradb> i.e. on the package bug reports listing
<HiddenWolf> bradb: are you broadmessaging -devel?
<Keybuk> wow, what was the cocktail you slipped him? :)
<ogra> YAAAY \O/
<ogra> bradb, oh, that was not general ? 
<bradb> ogra: Just for the specific proposal I made re: the feedback you guys gave earlier.
<pitti> bradb: rock
<bradb> One step at a time. This is encouraging news that, given sufficient effort and evidence, there can be positive UI changes made. :)
<ogra> hmm, i think its important on the single bug view as well ...
<ogra> yeah 
<ogra> but having to walk in such small steps is needing a lot of patience :)
<bradb> yeah
<dholbach> mdke: ping
<pvanhoof> difficult-to-spot bug: an upgrade caused "auto eth0" to be added twice in the interfaces line
<pvanhoof> automagically
<pvanhoof> Had this problem on two dapper computers. The first one I thought it was my mistake
<Keybuk> pvanhoof: bug 29654
<Ubugtu> Malone bug 29654: "auto eth1 duplicated in /etc/network/interfaces by upgrade" Fix req. for: ifupdown (Ubuntu), Severity: Major, Assigned to: Scott James Remnant, Status: In Progress http://launchpad.net/bugs/29654
<pvanhoof> ok
<siretart> hm. too late..
<pitti> Riddell: ping
<jbailey> pitti: You're welcome to.  I've emailed Denis and asked him for the Right Way to sync these changes back to him.
<pitti> jbailey: I'd really like to apply these changes on top of the current belocs data (maybe it's even fixed), but I need that glibc update for that :)
<jbailey> pitti: Yes, makes sense.
<jbailey> I wonder if the patches that Denis has done for Debian glibc can just be taken directly.
<jbailey> He hasn't answered the email yet.
<Riddell> pitti: hi
<pitti> Riddell: zyga and I have LangpacksDesktopfiles implemented for Gnome to ~ 90%
<pitti> Riddell: do you have a minute to talk about what's necessary to do that for KDE, too?
<Riddell> pitti: sure
<zyga> pitti: and xubuntu
<pitti> Riddell: the cdbs changes should apply to KDE as well, but I'm not sure whether it catches the domain correctly
<pitti> Riddell: so let's start with that adding of the translation domain to .desktop files
<Riddell> pitti: what does it do?
<pitti> Riddell: oh, heh, it's not, sorry - that's done in gnome.mk
<pitti> Riddell: it basically does some black magic to find out the gettext domain and appends a field X-Ubuntu-Gettext-Domain to .desktop/.server files
<pitti> Riddell: and adds an attribute ubuntu-getttext-domain to .server files
<pitti> Riddell: I assume KDE has .desktop and .directory, too? (maybe not .server)
<Amaranth> it does
<Amaranth> KDE had it first :P
<Riddell> yes, what's the .server again?
<pitti> true :)
<Riddell> we don't have .server files
<pitti> Riddell: it's used for applets
<Riddell> ok
<pitti> Riddell: do all/the majority of KDE programs use cdbs' kde.mk?
<Riddell> pitti: all of KDE proper does yes
<Riddell> except I think kdeedu
<pitti> Riddell: then it would make sense to modify kde.mk in a similar way
<Riddell> certainly would
<pitti> Riddell: I can care for that if you want
<Riddell> how does it work out the translation domain?
<pitti>             DOMAIN=$$(grep --max-count 1 '^GETTEXT_PACKAGE[[:space:] ] *=' $(DEB_BUILDDIR)/po/Makefile | sed 's/^.*=[[:space:] ] \([^[:space:] ] \)/\1/'); \
<pitti> Riddell: maybe there is an easier way for KDE :)
<Riddell> kde has lots of programs and therefor translation domains in one package so I don't know if that would work
<pitti> ah, I remember
<pitti> Riddell: how are .desktop files translated in a KDE package then?
<pitti> Riddell: in gnome, a pakcage ships a .desktop.in, the po files, and intltool-merge puts the translations from the po files into the .desktop file
<pitti> but that won't work with the separated translations in KDE I assume
<Riddell> a script runs over SVN and puts all the .desktop strings into kdebase_desktop.po  kdemultimedia_desktop.po etc
<jpatrick> scripty
<Riddell> then another scripts comes along later and takes people's translations of them and puts them into the .desktop files
<pitti> Riddell: but that's not done on every package build I assume
<Riddell> no, it's done nightly on a checkout of the SVN archive
<pitti> Riddell: hm, maybe you are better suited to do the cdbs modifications then
<Riddell> yes, I'll have a think about it
<pitti> Riddell: the important part is to get the gettext domain into the desktop file, regardless how
<pitti> so that a KDE library can be modified to use gettext() on the strings
<Riddell> that would be KConfig having to call KLocale
<Riddell> and making sure it doesn't do any recusion while it's doing it
<Riddell> hmm, I'd also need to add the .desktop strings to the .pot files
<pitti> Riddell: do you think that this is a realistic target for dapper?
<pitti> Riddell: if not, then maybe we should split the KDE part of the spec into a separate spec
<Riddell> pitti: I'd like to get it working and it may well be possible, but it may well turn out to be quite difficult too
<AlinuxOS> pitti, ? :)
<pitti> Hi AlinuxOS 
<AlinuxOS> :)
<AlinuxOS> I'm very tired..
<AlinuxOS> I?ve done y best..
<AlinuxOS> I've prepared ka.tar.gz :)
<pitti> AlinuxOS: for breezy or dapper?
<pitti> AlinuxOS: great :)
<AlinuxOS> to put into rosetta-breezy.tar.gz
<pitti> AlinuxOS: nice, I can merge it once I verified that rosetta-breezy.tar.gz is sane
<trappist> pitti: watching out for this mdz fella you told me to ask about the alsaconf issue.  ubotu hasn't 'seen' him and I haven't either.  do I have the nick right?
<tseng> trappist: yes.
<trappist> tseng: thanks
<Kamion> he's pretty busy with soyuz deployment work all this week, fyi
<Nafallo> Kamion: oh. still monday-ish?
<sivang> rehi all
<Nafallo> morning sivang :-(
<Nafallo> s:(:):
<Kamion> Nafallo: no idea about status, sorry
<sivang> hey Nafallo :)
<bddebian> Heya crimsun
<bddebian> wb sivang
<Nafallo> then let's hope for monday :-)
<Nafallo> bddebian: yay! have you been in prison or something? :-)
<bddebian> Nafallo: All the -devel people wish, I'm sure. :-)
<sivang> hey bddebian 
<Nafallo> bddebian: nope, we just missed you ;-)
<sivang> bddebian: hehe
<bddebian> Oh and yeah, RL Work ~= Prison :-)
<sivang> bddebian: indeed :)
<Nafallo> ah, oki.
<theine> Didn't vim used to be an alternative for /etc/alternatives/editor ?
<pitti> theine: bug 6586
<Ubugtu> Malone bug 6586: "please provide alternative for /usr/bin/editor" Fix req. for: vim (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/6586
<theine> pitti, thanks
<matara> i got problem with kickstart on dapper
<xhaker> hi all
<matara> whrandom module depreciated
<xhaker> a long delay between source package upload and binary package availability on the repositories is always synonym of build failure?
<xhaker> matara: sure you didn't meant deprecated?
<matara> sorry yep that's what i meant
<Nafallo> xhaker: not always, but often.
<Nafallo> xhaker: could be binary new and such things aswell...
<xhaker> Nafallo: there was a page we could see the build logs not that lamont page. do you know if that feature is in launchpad now?
<xhaker> i want to test the new kernel so badly
<xhaker> see if it's this time my centrino will be handled by the real module
<Nafallo> xhaker: the kernel is binary new I believe.
<xhaker> yes it is
<xhaker> so.. hows development any problems rising?
<dilinger> jbailey: ping me when you're back
<Kamion> matara: sorry, I haven't been maintaining system-config-kickstart very well lately; please file a bug
<sivang> Kamion: what does it do?
<Kamion> sivang: apt-cache show system-config-kickstart
<Kamion> been there since hoary, so I know you have it :)
<sivang> Kamion: :-)
<Burgwork> sivang, it is part of the redhat/fedora system-conifg stuff, cherrypicked into ubuntu
<Nafallo> Kamion: something is blocking NEWing kernel btw? :-)
<sivang> Burgwork: before hoary was released? I was kind'of low on being synced with ubuntu's release process, was then terribly busy with work that it didn't allow me to follow it, I even passed release day being away from testing /irc / ml...
<Burgwork> sivang, somewhere around there, no idea
<Kamion> Nafallo: no, I just don't spend all day watching the NEW queue
<Kamion> and it's not really my job anyway, I'm just backup
<sivang> Burgwork: I think I recall remotely now , that somewhere before hoary Kamion ported the kickstart stuf to allo wmass installs of ubuntu :)
<Nafallo> Kamion: right. I didn't mean it in a bad way. just wondered if it was something like flight-4 or something :-).
* sivang wonders if kickstart is pythonized
* sivang checks
<jbailey> dilinger: ping
<sivang> oh nice, it's python, and it explodes
<Nafallo> hehe
<dilinger> jbailey: you mentioned synching bzr yesterday..
<dilinger> jbailey: 0.7-2 is in sid
<jbailey> Right.  Elmo's not online so I'll email him.
<Kamion> sivang: told you it was broken
<Burgwork> sivang, all of system-config is python
<Mithrandir> Nafallo: elmo is insanely busy those days, so please do give him and us some slack.
<Nafallo> Mithrandir: re:NEW?
<Mithrandir> Nafallo: yes.
<Kamion> I've NEWed the kernel anyway, but don't expect anything more from me tonight, would rather be with my family
<sivang> Kamion: ah right, it's up there in the backlog..sorry for the noise, again.
<Nafallo> Mithrandir: yea. it's just that it usually goes in faster, so I wanted to know if it was waiting for something fun :-). no worries for me since I already run the latest from p.u.c/~bcollins :-).
<Kamion> linux-source-2.6.15  | 2.6.15-14.19   | all amd64 i386 powerpc       | 5 hours old
<Kamion> a whole five hours, sorry we're all such slackers
<bddebian> Yeah, slackers
* Kamion &
<tseng> bye Kamion, have a nice night
<pitti> Good night everybody
<itsmeeh> v
<itsmeeh> must go today 1 alienware area51-m 5700 laptop price 650 includes shipping, carry case. message me on mcsltd@telusmail.net on msn or on mikcomputing on aim
<pitti> bless you
<jbailey> dilinger: Sent
<LaserJock> hmm, I just realized that the volume sliders in Muine and Volume Control are upside down
<Nafallo> ehrm? they are?
<LeeJunFan> launchpad doesn't have an entry for mysql-server?
<jbailey> LeeJunFan: Clearly it's certified to be bug free. =)
<jbailey> LeeJunFan: https://launchpad.net/distros/ubuntu/+source/mysql-dfsg-5.0
<LeeJunFan> jbailey: :) except that /var/run/mysqld dir is 770, so users can't connect to the socket. ie. amarok.
<jbailey> Err.  Isn't amarok a music player?
<LeeJunFan> thanks, I see it's already in there for php.
<LeeJunFan> yeah, it has the option of storing the playlist in mysql.
<LeeJunFan> looks like it has been reported many times.
#ubuntu-devel 2006-01-31
<menoz> hi all! Can you tell me how can I make a mirror of an Ubuntu repository?
<menoz> Should I use rsync?
<zyga_> menoz: please check the wiki/official website first
<menoz> I've found this: http://www.ubuntu.com/download/mirror
<menoz> thanks!
<tseng> argh Keybuk is gone
<tseng> udevplug hangs for a long time (and fails?) because /dev/.udev/queue already exists
<tseng> on my desktop
<zyga_> what is the easiest way to know about the version of some package in debian?
<zyga_> (with package.debian.org being down)
<Nafallo> I keep a deb-src for debians archive and use apt-cache madison :-)
<zyga_> Nafallo: I don't really even know the proper apt.sources line for debian
<zyga_> sources.list... I'm getting sleepy
<Nafallo> # debian sid
<Nafallo> deb-src http://ftp.se.debian.org/debian unstable main contrib non-free
<zyga_> Nafallo: what is the most experimental/fresh debian version?
<zyga_> sid and always sid?
<Nafallo> sid is always unstable, yes :-)
<HrdwrBoB> no
<zyga_> Nafallo: hmm, I want to look at gazpacho, how do I do it now?
<Nafallo> no?
<zyga_> apt-cache source doesn't show me anything new
<zyga_> (I did update)
<Nafallo> apt-cache madison gazpacho
<zyga_> ah
<zyga_> darn I did an obsolete job again :)
<dholbach> good night
<zyga_> night dholbach
<desrt> ciao, chicky
<Nafallo> gnight dholbach :-)
<zyga_> Nafallo: is there any way to tell apt-get source which repo to use?
<desrt> zyga_; /
<Nafallo> zyga_: dunno. I usally want to grab the latest :-)
<zyga_> Nafallo: nv, I have the right version
<zyga_> eh :-)
<zyga_> diff of the diff only shows different date and signature
<zyga_> good night guys :-)
<Nafallo> night zyga_
<hub> hi
<hub> my system is totally hosed because of udev failure
<hub> I don;t know if it is udev or what
<hub> but udev fails
<hub> dapper current
<Burgwork> hub, welcome to dapper
<hub> Burgwork: laptop works fine
<jsgotangco> lol
<hub> but desktop is fscked
<hub> shall I just pop in Flight 2?
<hub> so has anybody a clue?
* jsgotangco updates his laptop
<robertj> What Flight is UbuntuExpress slated for?
<Burgwork> robertj, likely the next one
<robertj> Burgwork: wowzers
<Burgwork> robertj, when that is in anyones guess, likely after the dev spring
<Burgwork> t
<hub> ok, I install SuSE this time 
<hub> since I'm at reinstalling
<hub> :-/
<jsgotangco> SuSE is nice :/
<bddebian> gack
<hub> at least I have CD
<Burgwork> jsgotangco, what does suse do that Ubuntu doesn't?
<hub> my machine is fscked and udev is just driving me insane
<hub> udev is more opaque than the Microsoft plug and pray
<Burgwork> hub, do you even have a xandros mahcine at home?
<hub> Burgwork: I don't
<hub> I have a box of v3
<hub> but otherwise I don't
<hub> have it installed
<Burgwork> well, I guess I don't have any of Userfuls stuff at home
<hub> Burgwork: I still have a server software from the one I used to work for
<jsgotangco> Burgwork: WPA works out of the box
<hub> but I scrap the box as .deb based server soon
<jsgotangco> Burgwork: i admit though, i haven't really tried in-depth with ubuntu
<hub> Burgwork: sonething I'm sure is that the installer is super slow on SuSE
<hub> jsgotangco: I couldn't get it to work
<hub> jsgotangco: because I use Network Manager
<jsgotangco> NM didn't work for me in suse too
<Burgwork> hub, what do they use?
<hub> Burgwork: don
<hub> t know
<hub> the installer is so slow
<bddebian> Why would dpatch attempt to apply in ./ ?
<Tm_T> somethings changed in network handling during boot, now I have to do ifdown&ifup to get net working, and even that returns some errors
<Tm_T> hmm, or maybe it has something to do with kernel, have to check that too
<crimsun> Tm_T: you don't happen to read dapper-changes, do you?
<Tm_T> nope
<Tm_T> where's that?
<Tm_T> crimsun: and thanks for pointing out, I knew I'm missing something ;)
<crimsun> Tm_T: follow the link from lists.ubuntu.com :)
<Tm_T> aah, ML, thank you sir
<Tm_T> 3h sleep last night and it's still early morning, so I'm not in my sharpest knife
<Tm_T> crimsun: I'
<Tm_T> m also crawling through KDE 3.5.1 trying to find changes and problems ;)
<ejofee> does the default (k)ubuntu install *also* include xterm? i want to create a .desktop script which works on both ubuntu and kubuntu.
<Kamion> ejofee: yes, it does
<ejofee> Kamion: thanks
<ejofee> i suggest we used a general xvt symlink which is scripted to stand for *any* [x]  [v] irtual [t] erminal at all that if finds on the computer. and we could do the same with the text editor. this way we won't say "use gedit <path> or kwrite <path>" to the noobs.
<ejofee> s/if/it/
<ejofee> (in a particular priority)
<pitti> Good morning
<Burgundavia> salut pitti, did that hal issue regarding running has unpriviledged and upstream not being happy get resolved?
<pitti> Burgundavia: mostly, yes
<pitti> Burgundavia: upstream and ubuntu now use the same architecture (privilege separation), just in Ubuntu the callouts have minimized privileges
<Burgundavia> pitti, ok, cause I was going to punch big holes in the "if I am at a machine with a usb stick, I can own it other ways"
<pitti> Burgundavia: that also means that power management and so on now work with our hal
<Burgundavia> that is good
<pitti> Burgundavia: heh, I also wrote counter arguments to this to 'the big' thread
<pitti> Burgundavia: like ltsp, digital photo vending machines, etc.
<Burgundavia> pitti, public access terminals, like 100% of Userful's computers
<Burgundavia> pitti, we allow usb access
<pitti> exactly
<pitti> Burgundavia: davidz agreed that this was a problem, so he happily accepted sjoerd's patch for priv separation
<AlinuxOS> pitti, Guten Morgen :)
<Kamion> ejofee: we call it /usr/bin/x-terminal-emulator
<Burgundavia> pitti, do other distros really run hal as root?
<Kamion> ejofee: and /usr/bin/editor
<ejofee> Kamion: wow, didn't know that! so why doesn't people use "editor" instead of "gedit" in their howtos? many kubuntu users complain to me that some howtos don't work on their kubuntu ("command not found" or so)... just because of this :)
<Kamion> ejofee: because they don't know about it either, I guess
<ejofee> s/doesn/don/
<ejofee> Kamion: right
<Burgundavia> ejofee, the official docs simply say "edit the following doc"
<ejofee> Burgundavia: well, some prefer to be as concise as possible
<ejofee> Burgundavia: (including me)
<Kamion> ejofee: (btw, you use update-alternatives to manage those symlinks I mentioned)
<ejofee> Kamion: didn't know that. does it also work automatically? (something like "update-alternatives --auto")
<Kamion> yes
<ejofee> Burgundavia: (in their howtos, that is)
<Kamion> packages' maintainer scripts do that for you though, you don't need to do it by hand
<ejofee> Kamion: thanks
<Burgundavia> Kamion, I was parsing through the seeds today I noticed we still include dselect in the standard seed. Is this really neccessary anymore?
<Kamion> Burgundavia: it is for me
<pitti> Hi AlinuxOS 
<ejofee> Kamion: boy... how i hate it that distros have so many differences between them... these differences are mostly unimportant with respect to their real benefits and so important with respect to creating confusion... which is a very frustrating irony.
<pitti> Burgundavia: yes, FC does
<pitti> Burgundavia: debian, ubuntu, and gentoo didn't
<Burgundavia> pitti, and userfuls product is based on FC. Our lead dev is not sane
<pitti> Burgundavia: no idea about SuSE, but since Kay works for Novell, and he's heavily on the 'root? so what?' side, I expect that SuSE runs hal as root, too
<Kamion> and it's only a 100KB-odd .deb, so please leave it be for us dinosaurs :)
<Burgundavia> Kamion, far be it from me to take away play toys from the developers. You provide us non-technical people with enough shiny toys, like espresso
<Kamion> ejofee: I believe Red Hat has a rewritten version of update-alternatives nowadays too *shrug*
<Kamion> though it might be called just alternatives, not sure
<pitti> Burgundavia: I was grown up with dselect, and for the occasional 'clean up my packages' rave dselect is still a nice tool :)
<Kamion> speaking of which, why the *hell* does espresso not want to quite finish partitioning ... grumble
<AlinuxOS> pitti, I know only apt-get :)
<Kamion> oh, heh, might have something to do with the sys.exit(0) I put in there for debugging
<pitti> AlinuxOS: you should at least know apt-cache search (IMHO still the fastest tool to find stuff)
<AlinuxOS> pitti, yes
<AlinuxOS> I've learned basic commands...and I like apt-get very much.
<AlinuxOS> I heard something about aptitute
<Burgundavia> Kamion, we also need to make a decision on reportbugs for dapper. I get about an email a day to the spam catcher of -users that comes from that
<Kamion> Burgundavia: see the bug about it, I guess, there's been recent activity
<Kamion> pitti: is there any good way to tell g-v-m not to pop up a window when a *particular* filesystem is mounted?
<Burgundavia> Kamion, was unaware there was one, thanks for hte info
<Kamion> pitti: it's very annoying when the live installer has just mounted /target and a window pops up ...
<pitti> Kamion: not right now
<pitti> Kamion: but it might make sense to teach it to only react to stuff in /media?
<Kamion> hmm, yeah, maybe
* pitti wonders why he missed so many IRC messages and notices that the PC speaker isn't working
<pitti> Keeeeeeybuk?
<Kamion> failing that, if I could have /target and everything under it blacklisted, that would be nice
<pitti> Kamion: hm, I think I'll just do the above
<Kamion> ok
* pitti adds to todo
<Kamion> woo, I would just like to say that I have espresso handling almost all its partitioning through partman now
<pitti> great! I can't wait to test espresso
<Kamion> the first version is gonna suck UI-wise, mind
<Kamion> quite apart from poor UI design in general, there are far too many places where the gtk main loop is blocked so the UI is unresponsive
<Kamion> hopefully I'll clear that up soon
<AlinuxOS> espresso ? :) caff espresso mmmm....
<AlinuxOS> :)
<Kamion> AlinuxOS: exactly
<pitti> AlinuxOS: the new way of installing ubuntu from a live CD, which will rock da house :)
<AlinuxOS> pitti, I've seen something similar on Mepis
<AlinuxOS> is it the same?
<Kamion> no
<AlinuxOS> ah
<AlinuxOS> so there will be no more Install + Live CD
<Kamion> live installers aren't news ... the trick is doing one that's maintainable in conjunction with a traditional installer
<Kamion> AlinuxOS: incorrect, we'll still have the install CD available for download
<AlinuxOS> but there will be Live Ubuntu/Installer + Live Kubuntu/Installer ? 
<Kamion> the live installer won't be as featureful as the traditional installer, at least to start with
<Kamion> hopefully, though no work has been done on a KDE frontend for espresso yet
<AlinuxOS> ah
<AlinuxOS> Kamion, very very interestning :)
<AlinuxOS> I've downloaded dapper....
<ejofee> Kamion: "editor" links to mc's editor. this is surely not nice for the average user
* Burgundavia grumbles about Malone not understanding binary stuff
<Kamion> ejofee: mc isn't in the default install
<Kamion> ejofee: nor, for that matter, in main
<ejofee> Kamion: then is it because i just installed mc?
<Treenaks> Burgundavia: it doesn't?
<Treenaks> Burgundavia: not even in attachments?
<Burgundavia> Treenaks, no, I am talking about trying to report against a binary in a package
<Kamion> ejofee: yes, mc registers a higher priority for its editor than the default (nano) does
<Kamion> ejofee: the idea is that if you install something odd then you probably want to use it
<Burgundavia> Treenaks, ie, it doesn't do the smart thing and give you correct source package
<ejofee> Kamion: right, but most users would prefer gedit or kwrite! they should be higher priority (for under x11)?
<Kamion> Burgundavia: bradb's landed a patch for that, it should be in production soon
<ejofee> s/\?/\./
<Burgundavia> Kamion, sweet
<Kamion> ejofee: most users won't install mc in the first place; those users that do probably want it
<ejofee> Kamion: whatever
<Kamion> hmm, gedit apparently only registers itself as gnome-text-editor, not editor
<ejofee> Kamion: any idea why mc-mp is not also included in the universe?
<Kamion> that's awkward, I wonder if it's deliberate
<ejofee> Kamion: it's not only awkward, but also stupid... we have to write separate howto examples for kde / gnome users
<ejofee> Kamion: it should be x-text-editor
<Kamion> and kate doesn't register anything
<ejofee> Kamion: after the model x-terminal-emulator
<Kamion> there appears to be no standard for this; it should probably be discussed on debian-policy@
<Kamion> with the relevant maintainers
<ejofee> Kamion: i guess this is some sort of equivalent to bureaucracy
<ejofee> Kamion: hard to move things
<Kamion> ejofee: sorry, no idea about mc-mp
<Kamion> ejofee: if you just want to throw insults, please don't
<Kamion> I'm trying to help you
<ejofee> Kamion: http://mc.linuxinside.com/cgi-bin/dir.cgi
<ejofee> Kamion: and i really appreciate it.
<Kamion> ejofee: oh, I guess just nobody's packaged it then
<Kamion> you could ask ubuntu-motu@ if anyone wants to do it
<Kamion> it's not bureaucracy anyway, it's aiming for good design rather than random choices
<Kamion> which yes sometimes does involve actually talking to the maintainers of the affected packages
<Kamion> often considered useful :)
<ejofee> Kamion: given the much smaller size, it could replace nano and add a file browser for the rescuing use cases.
<tepsipakki> is mc-cp maintained anymore.. latest release is from 30-Aug-2004
<Kamion> nano's good as the default because it's also available in the installer
<tepsipakki> mc-mp that is
<Kamion> and mc is about ten times the size of nano. Is mc-mp that much smaller?
<ejofee> Kamion: yeah... i can understand that, too. sort of the other side of the coin. i am dreaming of a system which allows for both sides of the coin to be visible simulatenously. :P
<ejofee> tepsipakki: but it seems it's more stable than the maintained mc
<ejofee> s/simulatenously/simultaneously/
<ejofee> Kamion: that's what i implied: why not including mc-mp (which is actually mc-light, that is, much smaller than mc) for doing both file management and editing?
<ejofee> Kamion: ... in the installer, i meant
<Mithrandir> ejofee: what's the size of a compiled mc-mp, then?
<ejofee> "<Kamion> nano's good as the default because it's also available in the installer"
<ejofee> Mithrandir: i don't know the installed size, but the package size is 1,2 mb
<ejofee> Mithrandir: however, an alternative option is lfm
<ejofee> Mithrandir: which resembles mc, but it's way much smaller (and doesn't include its own editor, so we should keep nano)
<ejofee> Mithrandir: an installed lfm is 410 kb.
<Mithrandir> ejofee: nano-udeb is 26k.
<ejofee> Mithrandir: i am talking about a file manager
<Mithrandir> (45k uncompressed)
<ejofee> Mithrandir: lfm is a file manager
<HrdwrBoB> it's also 10x the size
<ejofee> Mithrandir: btw, does the installer include python?
<Mithrandir> no
<Kamion> ejofee: no, it doesn't
<Mithrandir> I'm not sure we need a file manager in the installer.
<Kamion> ejofee: and what Mithrandir said about the installer. No way are we adding that much to the base initrd.
<ejofee> Kamion: so i guess mc has no chance to be included to the installer, right?
<Kamion> ejofee: nope, sorry
<ejofee> Kamion: it's understandable
<Mithrandir> not unless it goes on a serious diet. :-)
<ejofee> Mithrandir: i could call mc-mp quite some diet
<Kamion> I see no compelling reason to put a file manager in the installer, so I see no reason why we'd go to that effort
<Kamion> if you can't handle the shell for rescue work, you can always use the live CD
<ejofee> Kamion: i was thinking of x11 failing back to console
<ejofee> Kamion: for those instances, a mc would be cool
<ejofee> Kamion: so i think it should be included on the cd
<ejofee> Kamion: ... at least
<Mithrandir> ejofee: X doesn't "fall back" to the console.
<ejofee> Mithrandir: but...?
<Kamion> Mithrandir: he means if X fails to start
<ejofee> Kamion / Mithrandir: right
<Mithrandir> Kamion: then we should fix it to fall back to VESA or something.
<ejofee> most users from my generation are used to failing back to dos / nc (norton commander)
<Mithrandir> if VESA doesn't work, then you lose and get to keep all the pieces.
<Kamion> mc's interface is fine for those who are used to it, but it's very quirky
<Mithrandir> ejofee: do you have any statistics to back that up?
<Kamion> and the lack of maintenance makes it a concerning prospect for main
<ejofee> Mithrandir: no, sorry. used the wrong word.
<ejofee> s/most/many/
<ejofee> Mithrandir: it really wasn't in my intention to say "most".
<Mithrandir> I'd argue "a few" or "some", but I don't have any numbers to back it up.
<ejofee> Kamion: there's no more "newbye friendly" alternative to mc anyway, afaik (or please name one). even bios is designed like that. it's the best friendliness we can provide them in the console.
<Mithrandir> newbies are lost in the console anyway and it's way better to just learn to use a shell and some simple commands like ls, cd and less.
<ejofee> Kamion: i mean... at least it deserves to be on the (dapper) live / install cd...
<ejofee> Kamion: knoppix also includes it (not that it means anything imperative to us)
<Burgundavia> ejofee, I thought I convinced you yesterday that mc in the default install is not actually helping anybody
<ejofee> Burgundavia: i began to write the wiki. so you convinced me.
<ejofee> :)
* mvo grumbles about dapper networking not coming up for him
<ajmitch> mvo: I had eth0 & eth1 swap round on one boot :)
<ajmitch> however it didn't repeat
<mvo> ajmitch: yeah, something like this seems to have happend
<Treenaks> Argh! I rebooted and my (built-in) USB card-readers became sda/sdb/sdc/sdd, and my SATA-disk became sde -- which BROKE booting quite badly
<ajmitch> seems that there might be a little issue with module load order or similar
<tobias___> Treenaks: Why don't you use the labels/disk ids in /etc/fstab?
<Treenaks> tobias___: Because the breezy install doesn't do that
<Treenaks> tobias___: by default
<tobias___> Treenaks: True.
<Treenaks> tobias___: also, grub likes to know where its files live
<tobias___> Treenaks: I had assumed you to be on dapper already.
<Treenaks> (root= kernel command line)
<Treenaks> tobias___: I _am_ on dapper now
<Treenaks> tobias___: but upgrading doesn't magically alter fstab
<tobias___> Treenaks: Yes, you are right of course.
<tobias___> Treenaks: But root= can use a label too IIRC. At least it can on redhat.
<Treenaks> tobias___: haven't tried yet, but moving disks around is still broken :)
<tepsipakki> mvo: do you have a newer version of update-manager somewhere? 0.42.2ubuntu1~bp2 just crashes for me
<mvo> tepsipakki: can you start it in a terminal and put the backtrace of the crash to paste.ubuntulinux.nl please? 
<mvo> tepsipakki: dapper-backports is now available btw (answering to your mail from a couple of days back)
<Treenaks> mvo: should the pointer to the update-manager icon be ON the icon (it points to the middle of the red circle icon)
<Treenaks> ?
<mvo> Treenaks: yeah, I noticed that too. the notificaiton-daemon seems to have changed it's semantics. I think I can/could work around it if it is too annoying
<tepsipakki> mvo: does it have some debug-flags?
<seb128> mvo: what is the topic?
<mvo> seb128: notification-daemon put it's arrow in the middle of the attached widget now
<seb128> ah
<mvo> tepsipakki: I think I should enable showing the backtrace in the gui, yes
* hunger sighs.
<tepsipakki> wtf.. somehow apt thinks that all of my packages are obsolete
<hunger> Networking is broken *again*.
<hunger> This time /var/run/network is missing with /var/run actually having been created.
<mdke> hunger, sounds like a bug
<hunger> No more dhcp either:-(
* hunger wonders why if then else constructs are used when both the if and the else branch are identical.
<hunger> The wonders of shell programming I guess;-)
<tepsipakki> mvo: I see that update-manager comments out the breezy-repos from sources.list? short after that it quits
<tonyyarusso> When Dapper is released, will it be as stable on that day as, say, a week later?  WIll everything actually be taken care of before release, or are there likely to still be a few bugs to work out in the first few days?
<mvo> tepsipakki: do you have a backtrace for me :) 
<tepsipakki> mvo: oh you mean from strace?
<mvo> tepsipakki: just what it outputs in a terminal, when it dies. you will have to run it manually inside a gnome-terminal for that ("sudo update-manager")
<Kamion> tonyyarusso: obviously we hope the former
<tepsipakki> mvo: there's hardly anything useful, but wait a sec
<Kamion> that's why we have freezes etc.
<tonyyarusso> Kamion, Right.  What's the experience been in the first week of the previous releases?
<Kamion> tonyyarusso: generally pretty good, the showstoppers usually turn up about six hours before release in my experience ;-)
<Kamion> causing enormous "fun" for the release team, but hey
<tonyyarusso> Kamion, Well, I suppose "fun" makes life interesting.  Thanks.
<Kamion> we're being moderately conservative about dapper because it's to be a long-term-supported release, and pushing the release out an extra week to give ourselves more time, so hopefully should be ok
<ajmitch> feature freeze is slightly earlier than previous releases, isn't it?
<hunger> Kamion: I had to write a bugreport each day of the week since my system did not come up as expected. The good thing is that all of them are fixed already:-)
<Kamion> ajmitch: don't believe so
<Kamion> https://wiki.ubuntu.com/DapperReleaseProcess lists the release process changes relative to breezy
* ajmitch may still have time to get a decently working selinux system working nicely by then
<tepsipakki> mvo: http://users.tkk.fi/~tjaalton/tmp/u-m.debug
<hunger> Kamion: So if you guys can keep up with that, then I have no doubt that you will manage to make dapper pretty stable.
<tepsipakki> mvo: there's also dist-upgrade*.log
<Kamion> ajmitch: in fact it's week 19 now rather than week 17
<ajmitch> currently it's looking like policy would be in universe, and very little changes to what's already in dapper
<Kamion> not sure that's entirely intentional, just how it shook out
<ajmitch> ok
<tepsipakki> mvo: I'm using a local (unofficial) mirror...
<mvo> tepsipakki: thanks! helped me a lot, I think I think I found the problem and will attack it now
<tepsipakki> mvo: cool
<Kamion> hunger: the tail-end of the big invasive boot process changes are still coming in, so I think that's to be expected; thanks for filing bugs
<mvo> tepsipakki: but it's a mirror with valid gpg-sigs? the next-version of the dist-upgrader won't upgrade if anything can't be authenticated
<tepsipakki> mvo: yes, I maintain it =)
<ajmitch> pitti: selinux policy handling has really improved a lot with binary modules & reference policy - it'll be sane for you to support :)
<tepsipakki> mvo: mirrored with apt-mirror, and at least the installer doesn't complain about it
<mvo> tepsipakki: cool :) that's fine then. I'll let you know when I have something new to test
<mvo> tepsipakki: is this a ubuntu or a kubuntu system you are on?
<tepsipakki> mvo: ubuntu
<Kinnison> k
<Kinnison> sorry, wrong window
<tepsipakki> mvo: I have the full list of packages from dpkg --get-selections if you need
<tepsipakki> mvo: only unofficial packages atm are sun-j2dk and w32codecs ;)
<mvo> tepsipakki: that should be fine, it shouldn't do anything to them (if it can avoid it). your sources.list is more interessting to me
<hunger> Anyone working on malone #23388? That one has dapper set as a milestone?
<Ubugtu> Malone bug 23388: "tput used in /lib/lsb/init-functions after /usr is unmounted" Fix req. for: lsb lsb-base (Ubuntu), Severity: Minor, Assigned to: Michael Vogt, Status: Unconfirmed http://launchpad.net/bugs/23388
<mvo> tepsipakki: feel free to send it via mail if you don't want to expose it here in a pulic channel
<hunger> It is not yet fixed.
<mvo> tepsipakki: I have the suspicion that the sources.list rewriter dosn't work well with unoffical mirrors
<Kamion> hunger: I expect that bugs with dapper set as a milestone will be evaluated by the release team as we come up to release to make sure they either get explicitly deferred or fixed, rather than accidentally left behind
<tepsipakki> mvo: it's here http://users.tkk.fi/~tjaalton/tmp/sources.list, after running the u-m
<hunger> Kamion: I hope so... it was defer in breezy already and I find it really unprofessional to have error messages scroll by on bootup/shutdown.
<mvo> tepsipakki: thanks, that helps me a lot!
<Kamion> hunger: well, it was only noticed just before breezy, so that's understandable
<hunger> Kamion: I am not blaming anyone... I do understand why that decission was made back then.
<Kamion> yep
<mvo> mdz_: do you think a summary report about the current state of breezy->dapper dist-upgrades should be send to the ubuntu-devel list? or do you consider it's too early in the release-cycle for this?
<mvo> Diziet: around?
<mdz_> mvo: I think that would be completely appropriate
<mdz_> mvo: we should pay attention to this sort of thing much earlier for dapper
<pitti> Kamion: hmm, 'sudo mount /dev/hda3 /target' doesn't spawn a nautilus window for me...
<mvo> mdz: thanks, I'll writeup something then
<Kamion> pitti: weird
<pitti> Kamion: I get a window for /cdrom, and no window for /mnt and /target
<Kamion> pitti: unless it's an hda/sda distinction (which would be crack)
<pitti> Kamion: lemme dig out the logic for that, then I'll come back to you (I probably need an lshal output)
<pitti> fabbione! 
<pitti> fabbione: had a good journey?
<ajmitch> hey fabbione 
<mvo> hello fabbione!
<fabbione> hey guys
<fabbione> pitti: no it did suck a lot
<Kamion> how do I stop my gtk application from popping up underneath the terminal I launch it from?
<Kamion> excuse the gtk newbie question
<fabbione> mvo: http://people.ubuntu.com/~fabbione/u-n.strace
<Mithrandir> kamion: use a non-insane wm? :-)
<Kamion> Mithrandir: don't get a *lot* of choice on the live CD ...
<Mithrandir> Kamion: I saw somebody complaining about it in the regular desktop the other day.  Blame metacity.
<Kamion> I understand there's some rubric an application can do at startup to set some kind of timestamp
<pitti> Kamion: there's lots of discussion about this bug ATM, see gnome bug 326159
<Ubugtu> Gnome bug 326159: "Experimental strict-focus-approximation feature" Product: metacity, Component: general, Severity: normal, Assigned to: metacity-maint@gnome.bugs, Status: NEW http://bugs.gnome.org/show_bug.cgi?id=326159
<pitti> Kamion: please add your complaint as well, the more, the better :)
<Kamion> hm, ok
<pitti> Kamion: and, well, we need a 'change gnome behaviour two days before the release' item for dapper, too :)
<seb128> pitti: I can work on that one :p
* pitti will bring seb128 a delicate Schnaps if he fixes it
<seb128> oh
* seb128 goes to fix that NOW
<seb128> :)
<pitti> \o/
<pitti> Kamion: ah, I can reproduce it now. seems to depend on the moon phase
<pitti> Kamion: (nautilus window for mount /target)
<Treenaks> pitti: do you still do ALSA?
<pitti> Treenaks: well, I never really 'did' alsa, I changed some bits and pieces in the gnome integration
<pitti> Treenaks: but I have commit access to Debian now :)
<Treenaks> pitti: 'do you handle alsa-lib bugs?' :)
<pitti> I'm not an expert at all for that, but just assign it to me if you want
<Treenaks> pitti: well, I filed it on alsa-lib; and it has a fix in debian
<pitti> oh, easy then
<Treenaks> pitti: AND it's a one-line diff
<pitti> hey infinity 
<pitti> Treenaks: so it's a mere merge?
<Treenaks> pitti: from experimental, I think
<Treenaks> (if I read the debian report right)
<pitti> Treenaks: oh, experimental already has 1.0.11rc stuff, right?
<pitti> well, then we'll patch it rather
<Treenaks> pitti: it's launchpad #29722
* hunger sighs. The move-dhcp-to-background trick breaks ntpdate again:-( And causes lots of spam to appear on screen during bootup (since lo is set up before /usr is there and ifup tries to run stuff from there).
<pitti> bug 29722
<Ubugtu> Malone bug 29722: "libasound2: breaks PMacToonie.conf" Fix req. for: alsa-lib (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29722
<pitti> Treenaks: ah, that rings a bell - BenC mentioned that
* pitti wants a 'bts' shell script for LP
<Treenaks> pitti: the kernel part was fixed in the last kernel upload
<Kamion> pitti: comment added
<ogra> hmm, nobody in this bug takes into account that there might be users that delete the taskbar :)
<ogra> (for whatever obscure reason)
<pitti> Treenaks: ubuntu task opened and assigned to ubuntu-audio (which I'm a member of)
<pitti> Kamion: maybe a slightly different g-v-m semantics is even more appropriate: it should only display nautilus windows for devices it mounted itself, not for devices which were manually mounted
<ogra> hey infinity 
<mvo> tepsipakki: I implemented gui-error reporting, you should be able to test it already. the sources.list rewriting problem is not attacked yet though :/
<Kamion> pitti: works for me; that would avoid the irritating "I ran pmount and a window popped up" thing
<Diziet> mvo: Ah, hello.  What can I do for you ?
<mvo> Diziet: I wanted to ask about the automatic upgrade test stuff, are you working on that? 
<Diziet> Um, I have some automated testing work, yes, but I haven't glued it to piuparts (yet).  Was that what you meant ?
<mvo> Diziet: yes. I did some manual upgrade testing (sort of a by-product of the dist-upgrader work) 
<mvo> Diziet: so I naturally though it would be good to team up
<mvo> :)
<mvo> Diziet: a clean upgrade (packagewise) is important because apt dosn't handles failures in the middle of a dist-upgrade not very well
<Diziet> Right.  Have you read http://wiki.ubuntu.com/AutomatedTesting ?  That's what I've been implementing.
<pitti> Kamion: fixed and uploaded
<Diziet> mvo: Right.
<tepsipakki> mvo: ok, the error is the same as in dist-upgrade.log though
<mvo> tepsipakki: yes, that is intentional, it should be enough to send the two files to make me happy :)
<Diziet> mvo: What do you want out of an automatic upgrade test gizmo ?
<Diziet> Or were you hoping I'd have answered that question for myself ? :-)
<tepsipakki> mvo: right, they are now in here: http://users.tkk.fi/~tjaalton/tmp/
<mvo> Diziet: well, what I really want is to know if a package upgrades cleanly from breezy to hoary. that involves file-override errors, errors in post,pre-inst etc
<mvo> tepsipakki: thanks a lot for your help!
<tepsipakki> mvo: well, they look the same as before ;)
<mvo> Diziet: that isn't covered by the spec, but piuparts should help here I guess
<mvo> tepsipakki: yes, but now your got a gui-dialog that told you about the problem and the error is logged too :)
<Diziet> Surely the best way to find this out is to actually try it ?  Or do you mean you want to look at a package in isolation and check that at the very least you can dpkg -i it over and over again ?
<tepsipakki> mvo: true, it's better this way
<mvo> Diziet: yeah, I totally agree. I mainly wanted to know if anything like this is covered by the automatic testing spec/implementation yet :)
<Diziet> No, I'm afraid not.  It's clear that much of the same system should be able to embrace piuparts and things like it but exactly how to do that glue hasn't been designed or implemented.
<mvo> thanks
<sabdfl> iw
<sabdfl> oww
<Diziet> mvo: I'll raise embracing piuparts up my todo list.  It's a good way of getting a lot of testing done for less effort than writing per package tests.
<pitti> sabdfl: scray sounds - you need a massage? :)
<Diziet> sabdfl: Good morning.  Have a cup of tea.
<Kamion> Diziet: it's possible that it'd get Lars Wirzenius writing code for you, too ...
<sabdfl> pitti: in these parts, that's always a good idea ;-P
<pitti> sabdfl: I had a Thai massage (my first one) two weeks ago, it was sooooo good
<sabdfl> i booked one in Mumbai, but Jane looked like she needed it more than me so I gave it to her
<sabdfl> i mean
<sabdfl> i let the smooth operator give it to her :-)
<ogra> heh
<pitti> hehe
<mvo> Diziet: thanks, I'll have a closer look myself too. not sure how helpful it is though, because apparently it tests a single deb only?
<fabbione> hey sabdfl !
* mvo waves to sabdfl 
<ajmitch> evening sabdfl 
<Diziet> mvo: Yes.  But there's no reason it couldn't be made to have a loop :-).
<mvo> Diziet: :)
<Diziet> If you want to do a whole dist-upgrade test then just do a dist-upgrade test.
<sabdfl> hey fabbione you genius, how's life?
<fabbione> sabdfl: everything is fine.. we are hammering apache 2.2
<sabdfl> ajmitch: good to meet you again
<Diziet> One big point of it is that we'll be able to run it during upload processing.
<ajmitch> sabdfl: enjoying dunedin?
<sabdfl> ajmitch: rather. beautiful part of the world
<Simira> sabdfl : How are you today? I owe you a hug, Ubuntu just got me a job :)
<Kinnison> Simira: yay
<marilize> hi sabdfl
<sabdfl> Simira: CONGRATULATIONS!
<sabdfl> hey marilize
<ogra> Simira, wow, how that ? 
<marilize> sabdfl   :)
<Kamion> sabdfl: morning
<Kamion> or whatever it is there
<Simira> ogra : I'm in a program for getting back to work after being sick for a long time. And I got to work in (at least one of) Norway's  best providers of linux services
<hunger> Does someone have an idea what might have broken wpasupplicant since yesterday evening?
<ogra> Simira, cool !
<mvo> Simira: great! congratulations 
<hunger> Simira: congratutalitons!
<Simira> ogra : definitely. And they took me because of my involvement with Ubuntu. They normally don't take trainees and stuff, but they liked my background.
<Simira> thanks :)
<ajmitch> Simira: great, can you get me a job also? :)
<ogra> wow, thats really awesome :)
<Simira> ajmitch : probably. They are hiring a lot of people these days. You should learn Norwegian though.
<Simira> I also already got requests for features for Ubuntu. I will put a mail on that tomorrow.
<ajmitch> that could be a challenge
<ajmitch>  http://radio.ctd.id.au:88/lalive.ogg
<ajmitch> oops
<ajmitch> gpg: key 5921B5D8: "Andrew Mitchell <ajmitch@ubuntu.com>" 18 new signatures
<ctd> that's cool! pimp pimp pimp
<ajmitch> ctd: copy/paste was broken from my terminal :)
<ajmitch> looks like people have uploaded signatures directly, instead of mailing me
<Kinnison> ajmitch: can't expect everyone to be as careful as us
* ajmitch ought to check which channel he pastes in also
<hunger_> BenC: Are there any problems with wpa_supplicant and the -14- linux kernel set on madwifi?
<hunger_> BenC: It did and does work with the -13- set of kernel and restricted modules.
<hunger_> nick hunger
<Mithrandir> pitti: if I were to build you a casper ISO, any chance you could test it for me?  (Amd64)
<mvo> Mithrandir: if it's just the amd64 testing that is needed, I could help too
<Mithrandir> mvo: Simira can do it for me.
<Mithrandir> mvo: so I should be fine.
<mvo> ok :)
<Mithrandir> (it also means I don't have to rsync a cdimage up on my silly home DSL)
<Tm_T> hey, who's the man to talk about mirrors?
<Mithrandir> Tm_T: mirrors@ubuntu.com
<Tm_T> ah, because iirc fi. mirror is located somewhere in england -> slow
<Tm_T> and I think I found good place for it
<pitti> Mithrandir: erm, sure? if it's reasonably rsyncable against the current amd64 live
<Mithrandir> pitti: I know it is.  It's getting it up again which will be slow.
<pitti> Mithrandir: ok, just send me a link when it's ready
* mvo goes for lunch
<pitti> doko: ok, this alsa-libs issue seems to be reasonably easy, I'll just upload a fix and see whether it works
<pitti> Kinnison: oh, btw, can you ping me right before you switch to soyuz? directly after that I need to upload a pkgstriptranslations which calls dpkg-distaddfile
<Kinnison> pitti: mdz wants us to stick with the current method for a while
<Kinnison> pitti: So you'll have to talk to him
<pitti> ok, fine for my
<pitti> me, even
<pitti> I just want to make sure to not break the buildds and translation tarballs :)
<mdz> we'll do that transition separately and later
<Kinnison> I need to get one of the buildd admins to talk to me about how the translation tarballs get off the buildds so that I can make sure our launchpad-buildd stuff can do it too
<pitti> alright
<doko> pitti: thanks
<pitti> doko: uploaded, I'll watch the build logs and cross fingers :)
<jbailey> pitti: Heya!  29747 seems to say that translations aren't making it into the langpacks.  Is Rosetta still broken for exporting them?
<pitti> jbailey: so far yes
<pitti> jbailey: carlos gave me a new breezy tarball two days ago, thouhg
<pitti> I'm currently testing it
<pitti> but I didn't get a dapper tarball so far
<ogra> pitti, BenC, one of you broke ppc sound 
<pitti> ogra: I just uploaded a new alsa-lib which might fix it again
<ogra> ah, fine 
<pitti> ogra: can you please check? bug 29722
<Ubugtu> moo
<pitti> he?
<ogra> lol
* pitti slaps Ubugtu 
<pitti> ogra: https://launchpad.net/distros/ubuntu/+source/alsa-lib/+bug/29722
<ogra> silly bot
<Tm_T> hum
<Tm_T> has anyone used pypanel ?
<ogra> pitti, hmm, rather looks like th emodules are missing completely 
<pitti> ogra: kernel modules?
<ogra> yup
<ogra> at least nothing is loaded here
<pitti> can you sudo modprobe snd_powermac?
<ogra> * warning: 'alsactl restore' failed with error message 'alsactl: load_state:1236: No soundcards found...'...
<ogra> but now they are loaded
<ogra> hmm... udev glitch ? 
<pitti> ogra: incidentially, my pcspkr on amd64 doesn't work any more :)
<Ubugtu> moof
<pitti> huh?
<ogra> ogra@edubuntu:~$ sudo /etc/init.d/alsa reload
<ogra> /etc/init.d/alsa: Warning: Directory /var/run/alsa is not present
<pitti> Seveas: can you tame this Ubugtu again? it's going mad
<ogra> hmm
<pitti> aaah, that explains a lot :)
<ogra> :)
<Seveas> pitti, I was working on it, moo is my favourite debug statement :)
<pitti> ogra: I'll add an mkdir -p to /etc/init.d/alsa
<ogra> looks like it might get complicated, i guess you need another dir to store them
<ogra> (for hibernate)
<Keybuk> ogra: I'd be surprised ... udev doesn't tend to "glitch", one of the nice things about it is that it's damned reliable
<Seveas> pitti bug 29722
<pitti> why, does hibernation kill /var/run?
<ogra> or does the tmpfs stay 
<pitti> it would be deadly
<pitti> killing all pids, sockets, etc.
<Seveas> urgh, still broken it seems...
<ogra> hmm, true 
<Keybuk> pitti: I'm very tempted to move everything alsa-related into udev rules, and take away that init script
<pitti> Keybuk: go ahead :)
<ogra> Keybuk, does /var/run persist at hibernation ? 
<Seveas> hmm, connection dropped
<Keybuk> it works here
<Keybuk> ogra: damned well should do!  I've done nothing to unmount it
<pitti> Keybuk: I get the same message, FWIW, but my sound card works nevertheless
<ogra> Keybuk, ok, fine ... better to ask then guess :)
<pitti> Keybuk: but the powerpc sound card is not hotpluggable, that's why that script might be necessary
<pitti> Hello Ubugtu, welcome back
<pitti> bug 29722
<desrt> Ubugtu; sup, homes?
* pitti hugs desrt
<desrt> hey pitti. :)
<desrt> oh man.  i think we got him too excited :)
<Seveas> launchpad keeps breaking him
<Treenaks> Seveas: how?
<Seveas> I still have to parse html
* desrt frowns?
<desrt> surely you can do better than that
<Seveas> and they subtly change^Wbreak everything I need every week
<Seveas> nope, launchpad has only an html interface
<ogra> hmm, "/dev/pmu has wrong permissions" what generates this error message ? 
<desrt> have them fix it
<ogra> pitti, is that hal ? 
<desrt> ogra; or pbbuttonsd
<seb128> gnome-settings-daemon does
<pitti> ogra: no, it's something in the panel
<seb128> (the pmu message)
<pitti> ogra: right
<ogra> ah, k
<Keybuk> ooh, cheerful phone engineer today ...
<desrt> seb/pitti; why is gnome accessing /dev/pmu?
<pitti> ogra: we fixed it back in warty, but the patch was dropped recently
<Keybuk> pitti: hmm, does that init script load the module for the powerpc card?
<Seveas> hah
<Seveas> pitti bug 29722
<Ubugtu> Malone bug 29722 in alsa-lib: "libasound2: breaks PMacToonie.conf" [Normal,Unconfirmed]  http://launchpad.net/bugs/29722
<ogra> desrt, reding lid events from hal for gnome-poer-manager for example
* pitti applayds Seveas 
<ogra> *power
<Seveas> it works again and is much more consise (to please fabbione)
<desrt> ogra; seems like that sort of thing should happen through hal.....
<pitti> Keybuk: hmm, so far we have it in /etc/modules, so I don't know
<seb128> ogra: g-s-d doesn't use hal
<pitti> Keybuk: I can try it out
<ogra> desrt, thats why i asked if hal generates the message :)
<ogra> seb128, i know
<seb128> desrt: changing the fblevel 
<fabbione> who does maintain xine-lib? i keep forgetting...
<desrt> seb128; ah.  now this makes sense :)
<pitti> fabbione: slomo 
<ogra> but i get no lid button events here and was hoping that was a related message :)
<fabbione> (and lazy to check the changelog)
<fabbione> slomo: ping?
<seb128> desrt: that's a part of the acme actions (like volume, etc)
<siretart> fabbione: perhaps I can help you? slomo did the split for main/universe/multiverse, though
<fabbione> siretart: http://buildd.mmjgroup.com/buildLogs/x/xine-lib/1.1.1-0ubuntu4/
<fabbione> siretart: can you look at the sparc FTBFS please?
<fabbione> you have a sparc and you can run dapper :D
<siretart> fabbione: As soon as I reach joerg to get igor back online
<fabbione> siretart: ok, when you do, please be sure to either tell me or stop crontab from init s
* ogra wonders how many computers called igor are there in the world
<fabbione> so that the buildd won't start automatically
<BenC> ogra: should be fixed in -14
<fabbione> otherwise it will mess around
<fabbione> hey Ben
<ogra> BenC, that is -14
<BenC> ogra: if not, can you spend some time on it with me?
<BenC> hey fabbione
<ogra> BenC, but seems its caused through missing /var/run stuff
<siretart> fabbione: in which crontab the buildd is started? I will comment it out then
<fabbione> siretart: in sparcbuildd user
<BenC> ogra: what's the error(s)?
<siretart> ok. will disable it then. no problem
<fabbione> siretart: it runs automatically at 20 and 50 of each hour
<fabbione> siretart: ok
<ogra> BenC, the sund modules dont get loaded ... alsa expects /var/run/alsa/modules-removed to be there 
<ogra> BenC, pitti is fixing it already 
<pitti> me or Keybuk, depending on how we want to fix it
<BenC> ogra: sounds like alsa bug
<BenC> ah, ok
<ogra> BenC, yup
<BenC> ogra: do you remember what type of sound chip you had (toonie, tumbler, snapper...)?
<ogra> i think it was snapper ...
<BenC> I did a lot of rework on snd-powermac, and I need feedback
<zakame> evening devs :)
<BenC> ok, let me know how it goes, snapper is untested
<ogra> will do once alsa is in shape again
<BenC> -13 oopsed for snapper, hoping -14 works
<pitti> Keybuk: I'm rebooting with a mkdir -p in the init script and snd_powermac removed from /etc/modules
<pitti> Keybuk: if that works, automatically loading the module from a script sounds preferable
<ogra> Mithrandir, should the ppc liveCD currently work ? 
<Mithrandir> ogra: I assume so, I don't have any bug reports about it not working.
<pitti> ogra: /etc/init.d/alsa reload unloads nothing and loads nithing
<pitti> ogra: and there is no start option
<pitti> so this seems pretty broken anyway
<ogra> Mithrandir, hmm, hangs here with edubuntu live from last night ...
<ogra> Mithrandir, cant mount the rootfs as it seems
<pitti> Keybuk: aah, I see - look in the header of that script
<Mithrandir> ogra: can you get me an error message?
<Kamion> could be mid-kernel-ABI transition, although that should be less likely now
<pitti> # There is no longer any need to run this script on bootup or shutdown.
<pitti> # It must remain in /etc/init.d/ for now, though, because certain
<pitti> # other scripts expect to find it there.
<Kamion> ogra: (try booting with live-nosplash)
<ogra> Kamion, ah, was about to ask, thanks
<pitti> ogra, Keybuk: so let's kill this script and leave snd_powermac in /etc/modules
<ogra> pitti, sounds sane
* ogra tests liveCD
<tepsipakki> seb128: could you look at gnome bug 328404? (same as malone 29178)
<Ubugtu> Gnome bug 328404 in dialog: "dialog loses focus" [critical,NEEDINFO]  http://bugs.gnome.org/show_bug.cgi?id=328404
<seb128> tepsipakki: what about it?
<tepsipakki> seb128: the gnome-vfs stuff, is it normal?
<seb128> it is linked to gnome-vfs, a sec
<tepsipakki> configure checks for it.. wonder why upstream doesn't know about it ;)
<seb128> I commented on the bug upstream
<tepsipakki> :)
<pitti> carlos: ping
<pitti> hi ogra_ibook, does the live CD work?
<ogra_ibook> Mithrandir, sorry, false alarm, it boots after hanging 5min
<tseng> ogra_ibook: does it hang on "Detecting hardware" ?
<ogra_ibook> bug: softmac detected at CPU#0 or something similar
<Mithrandir> ogra_ibook: wasn't that a udev problem some time ago?
<tseng> i have udevstart hanging
<Mithrandir> ogra: nobody has yet given me a powerpc machine, so it's hard for me to debug.
<ogra> lets do it at the sprint then 
<ogra> i saw that before on my GFs mac
<jbailey> pitti: I have another langpackish question for you - might be something to defer to the next spec writing sprint, though.
<ogra> it rather looks like a kernel thing ... or even something in initramfs ...
<jbailey> pitti: timezone data is also updated several times a year.
<pitti> ogra: btw, that /etc/init.d/alsa script does some rather interesting stuff, maybe we should leave it as it is; but it definitively doesn't load modules
<ogra> pitti, i think its used for suspend/hibernate 
<jbailey> pitti: It's a fairly clean import, glibc just does it.  Do you think it would be a horrible stretch to put that into the master locales package?
<pitti> jbailey: no, sounds pretty easy
<jbailey> 'kay.  The suck part is that it's a massive hardlink farm.
<jbailey> I'll have to look at how to export the building of it from glibc, but it seems like something that we really *ought* to be globally updating.
<jbailey> pitti: I have a feeling that part of what I Should do at this sprint is sit down with you and figure out how you do these updates if I'm poking more pieces into it.
<pitti> yes, that sounds like a good agenda point
<pitti> arrgh
<pitti> caaaaaarrloooooos
<pitti> carlos: here?
<carlos> pitti, hi, just arrived
<pitti> ah, great to see you again
<pitti> carlos: I just review the 33 MB worth of breezy tarball diff
<pitti> carlos: there are some removed translations
<pitti> carlos: but since the latest breezy tarball does not contain pot files, I couldn't merge against them, but had to merge against the original breezy pot files
<pitti> (which should actually be correct, though)
<carlos> pitti, URL?
<carlos> pitti, yeah the .pot files should be the same
<pitti> carlos: can we check some removals together?
<carlos> pitti, sure
<pitti> carlos: p.u.c./~pitti/langpacks/current.diff.gz (8,2 MB)
<pitti> carlos: let's do that in /msg
<carlos> ok
<Keybuk> muahahaha
<Keybuk> BT engineers are so much easier to bribe than BT call-centre staff
<rod> hi
<Kinnison> Keybuk: hmm?
<rod> someone knows how to apply transset on menus?
<Keybuk> Kinnison: bribed the BT engineer with tea and fun stories to replace my entire pair
<Kinnison> Keybuk: cool
<Kinnison> Keybuk: ran a new pair to the DP for you too? Or just rerouted at the DP?
<Keybuk> Kinnison: rerouted at both green boxes
<Keybuk> he claimed to be able to here a squeaking noise on my pair, and that it pretty much went through a great big puddle of water
<tseng> Keybuk: how aware are you of udevplug hanging on flight3 installs?
<tseng> strace tells me it is trying to mkdir /dev/.udev/queue over and over, as its already there
<tseng> removing it sets it straight again
<Diziet> dpkg: error processing /var/cache/apt/archives/python-gnome2_2.12.3-1_all.deb
<Diziet>  trying to overwrite `/usr/lib/gnome-vfs-2.0/modules/libpythonmethod.so', which is also in package python2.4-gnome2
<Diziet> Is this known ?
<siretart> Keybuk: I hope you are not angry with me that I stole the courier bug from you yesterday :)
<Kinnison> Keybuk: the DPs yes
<Keybuk> siretart: yeah, fix my bugs, bitch! :p
<Keybuk> tseng: curious
<siretart> hrhr
<Keybuk> tseng: I'm not aware of any bugs
<siretart> I didn't notice that the bug was already assigned to you
<siretart> only after uploading it..
<tseng> Keybuk: there are a few useless but similar reports on LP
<Keybuk> tseng: that's deliberately behaviour though ... that means that udevd has a queue, so it sits there in a loop waiting for mkdir to not return EEXIST
<Keybuk> tseng: if /dev/.udev/queue is empty but the directory still exists, there's another bug
<tseng> hm well it hangs for several minutes on S10udev
<tseng> before I presume it gives up
<Keybuk> it does it for you?
<tseng> because things are properly plugged
<tseng> ya
<tseng> if i let it time out, or whatever it does, i dont get /dev/input/mice and other niceities
<tseng> if i rm queue and force udevplug again
<tseng> its good to go.
<Keybuk> the most useful thing you could do to debug would be boot with init=/bin/sh, then try yourself running "udevd --daemon", check /dev/.udev/queue *doesn't* exist, then run "udevplug -s -v" and see what the last thing printed is before it hangs
<tseng> ill have to look tonight if there is actually something useful looking in the dir
<kent> Diziet: report bugs in malone for them to be known. 
<tseng> Keybuk: noted, thanks.
<Diziet> kent: Yes, I can file a bug but this is blocking me so I have to make the symptoms disappear.  If anyone wants more info before I force it through then it has to be now.
<Keybuk> that'll make it do each plug one at a time, waiting before/after each, and print the sysfs paths it tries as it goes along
<Keybuk> usually you'll find it's one thing that's just not playing ball
<Keybuk> or there's a bug :p
<Keybuk> if /dev/.udev/queue exists before you run udevplug, then that's a more interesting bug :)
<tseng> i suspected usb hub, but it wasnt the case
<mvo> Keybuk: my network interfaces where swapped  (eth0->eth1, eth1->eth0) this morning, did you got a report about something like that already? 
<Keybuk> mvo: I've not done any ifrename work yet ... so they'll go to their "default" (ie. whatever order the kernel feels like today) settings
<ogra> mvo, mine just swapped back 
<Keybuk> first I need to fix ifupdown, which looks like it was written by a monkey (hi, aj! :p)
<mvo> ogra: cool, what did you do?
<ogra> eth2 became eth1 again :)
<bddebian> Hello
<ogra> nothing 
<ogra> 2.6.15-14 seems to have it fixed
<mvo> Keybuk: aha, ok then, thanks
<Keybuk> ogra: don't bet on it, just means that random fluctuations in the space-kernel-continuum mean they got detected in the opposite order *this* boot :p
<mvo> ogra: might to be random then? let's wait for the next reboot :P
<Keybuk> did you know ... that you can't run two ifup processes at once? :)
<ogra> Keybuk, lol, yup
<Mithrandir> Keybuk: it's called "locking".
<Keybuk> Mithrandir: aye, explains many bugs
<pitti> why should they lock globally?
<Keybuk> pitti: because ifup keeps the state file in memory, reads it when it starts and only writes when it's done
<pitti> ah, I see
<Keybuk> or, at least, it *used* to do that :p
<ogra> you broke it ? 
<Keybuk> no, I'm *FIXING* it
<Keybuk> :D
<ogra> heh
<Keybuk> with a sledgehammer
* bddebian fsck's up again.. :'-(
<pitti> Keybuk: <pitti> ogra: btw, that /etc/init.d/alsa script does some rather interesting stuff, maybe we should leave it as it is; but it definitively doesn't load modules
<Keybuk> pitti: hmm, what loads the modules then?
<pitti> Keybuk: /etc/modules :)
<pitti> Keybuk: snd_powermac was put there since warty
<Keybuk> I didn't think the alsa script did ANYTHING on start
<pitti> since this pmu/ado bus is not hotpluggable
<pitti> Keybuk: right, it doesn't even have a start action
<Keybuk> it's the alsa-utils one that restores mixer settings and stuff
<Keybuk> which is the one I meant :)
<pitti> Keybuk: it's just there to unload drivers and kill processes for hibernate, and stuff
<pitti> Keybuk: oh, but that shouldn't load modules, or does it?
<ogra> Keybuk, the script is used for suspend/resume ....
<Keybuk> it doesn't load modules, no
<Keybuk> just does basically the same things the modprobe/udev/et. al. rules do
<ogra> it unloads on suspend and loads whats in the file in /var/run on resume
<pitti> ok, for that I indeed agree
<Keybuk> ogra: ah, probably that one's the one that needs a mkdir then
<pitti> setting mixer levels when the card becomes available instead of at boot makes sense
<ogra> yup
<pitti> Keybuk: grep var/run /etc/init.d/alsa-utils matches nothing
<pitti> erm, right (just read backscroll)
<pitti> ogra: so, what's the issue on your ibook? doesn't /etc/moudles contain snd_powermac?
<ogra> pitti, err, wrong script ? 
<pitti> yes, I just noticed, sorry
<ogra> snd-powermac
<ogra> hmm
<pitti> that's right
<pitti> so why it isn't loaded?
<ogra> shouldnt that be an underscore? 
<pitti> no, that doesn't matter
<bddebian> Bah, who needs powermac when it's all just Intel now?
* bddebian hides
* pitti hits bddebian with his ibook (which has a genuine PowerPC)
<pitti> :)
<bddebian> pitti: :-)
<ogra> pitti, i didnt load it manually ... but upgraded to 2.6.15-14 recently ... 
<bddebian> Hmm, maybe I'll get sound on my RS/6000 :-)
<pitti> doko: alsa-lib_1.0.10-2ubuntu1_20060126-1443-i386-successful.gz \o/
<crimsun> pitti: thanks much, that should take care of some of the sb live & sb audigy skews we've seen
<pitti> right, so far alsa-libs was still at 1.0.9 on i386
<doko> pitti: nice :)
<ogra_ibook> heh, the interfaces are really randomly changing their names :)
<Keybuk> whooh
<Keybuk> my ifupdown butchery actually seems to work
<ogra> pitti, just adding a mkdir -p doesnt solve it ...
<pitti> ogra: no surprise, that script isn't responsible for loading the modules
<ogra> even if the modules are loaded
<ogra> * warning: 'alsactl restore' failed with error message 'alsactl: load_state:1236: No soundcards found...'... 
<ogra> there must be something missing additionally
<Keybuk> okaaaay, this one can go in the archive
<Keybuk> mmmm, "stoned server"
<Nafallo> Keybuk: almost like you should release a new version with more mature strings in it ;-).
<Keybuk> bah
<Keybuk> that ruins the fun
<Keybuk> it's a testament to my immaturity when I wrote it ;)
<Nafallo> hehe, that's one way of looking at it indeed ;-).
<Keybuk> not that I'm any more mature now, of course
<lamont__> in malone, how do I tell it that it's a dup of a debian bug?
<ogra> add a bugwatch ?
<pitti> lamont__: in the menu at the right, 'Link to Other Bug Tracker'
<pitti> ogra: did you get that kernel oops on ppc/live, too?
<pitti> ogra: (in squashfs)
<ogra> yes
<pitti> ogra: I think that's the one fixed in 14?
<lamont__> OH MY GOODNESS!!!
<ogra> but thats there since ever ?
<pitti> ogra: and menu -> shut down -> reboot doesn't work for me
<lamont__> There's an _UNDERLINED_ link on the bugs page.
<pitti> ogra: oh, now it just worked, it took about 30 seconds to react to the 'reboot' request
<zul> hey
<Keybuk> lamont__: are you sure it's not just some dirt on your monitor?
<ogra> heh
<lamont__> Keybuk: link to _CVE_ :-)
<Keybuk> lamont__: that's one of those silly dotted abbreviation wotsits
<lamont__> heh
<Keybuk> if you hover over it, it'll give you an incorrect definition of the abbr.
* lamont__ ponders where in policy bug#29788 is referring to
<ogra> Keybuk, if i boot thin clients via PXE, they get an IP from the PXE request, etehreal and tcpdum show a second dhcp request during initramfs, is it possible to circumvent that ? 
<lamont__> ok.. there has to be a trivial way to say 'show me all the bugs in source package foo'
<Keybuk> ogra: no, because the kernel interface won't be configured with the IP received from the PXE request, afaiui
<ogra> hmm
<Keybuk> the IP that PXE receives is only used by PXE to get the kernel and initrd
<Keybuk> it doesn't get passed to Linux in any way
<Keybuk> so when the initramfs loads the network card driver, it has to begin configuration again
<ogra> would be really cool if we culd hand that to the kernel and get rid of the second attempt
<Keybuk> sure, ask Intel for the source to PXE and modify it, and then hack on the kernel
<ogra> probably PXE offers something in this regard ...
<Keybuk> good luck :p
<Keybuk> nope
<ogra> damned
<Keybuk> does it matter especially?
<Keybuk> if PXE can get the IP, so can the kernel?
<ogra> i'm not sure if it causes the nfsroot timeouts
<ogra> i get the same IP twice in a row (which is fine and wanted) but i suspect the second attempt causes a race ...
<ogra> that might be the reason why the sleep 3 in intramfs helped for breezy
<Q-FUNK> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348281
<Ubugtu> Debian bug 348281 in gnome-screensaver gnome-screensaver/0.0.23-1.: "please add these Debian and Ubuntu floater variants" [wishlist,Open] 
<Q-FUNK> might be of use here too
<Keybuk> \o/  my amd64 is ready to ship
<Keybuk> but boo, I won't get it until after the sprint
<ogra> Q-FUNK, i'm looking into it
<ogra> Q-FUNK, i got your request already, screensaver is just not on top of my todo currently ... dont worry, i'll include it
<Q-FUNK> ok
<ogra> :)
<ogra> nice work btw :)
<Q-FUNK> ogra: I tried convincing the debian maintainer to just merge it and to enable xscreensaver hacks as well, to avoid a fork, but got no response.
<Q-FUNK> at best, got someone on the debian gnome team saying that there's no way they'd merge the ubuntu circle variant
<ogra> the way we handle (and will handle) screensaver hacks is through splitting the package, i doubt that will be accepted in debian
<Q-FUNK> you mean xscreensaver-data ?  
<ogra> Q-FUNK, i like it, but indeed even if i implement it, i'm not the guy to 100% decide it, it gets my vote though 
<ogra> yup
<Q-FUNK> that's not what I meant.
<ogra> xscreensaver-adat will see a an additionyl split the next days 
<ogra> whoops
<ogra> *data **additionally
<Q-FUNK> gnome-screensaver has a compile option that enables it to directly read the xml configurations that come with each hack in xscreensaver-data, thus avoiding the need to duplicate them into .desktop files.
<ogra> ah, yes, but upstream wants to drop that in favor of the .desktop files iirc
<Q-FUNK> sad.  produces needless duplication then.
<ogra> not if the hacks move to gnome-screensaver one day 
<Q-FUNK> that would require xscreensaver also switching to .desktop files
<ogra> gnome-screensaver has a simple script that can generate the .desktop at build time ...
<Q-FUNK> that's what I meant:  duplication of configs.
<ogra> should be no issue to use it from rules ...
<ogra> nope, if you have the hacks in g-s you dont need to install the xml files in the binary package, they are just used as source for the .desktop files
<ogra> you could also try to convince jwz to switch to .desktop files :)
<Q-FUNK> any hope of achieving it, now that it's the standard?
<ogra> convincing jwz ?
<Q-FUNK> or is jwz so hopelessly stubborn about the way he does things?
<ogra> heh, he's known for that, yes :)
<pitti> carlos: yay, my 3rd attempt of building breezy update packs worked :)
<Q-FUNK> however, he's no djb or theo.
<carlos> pitti: are you having problems?
<carlos> oh
<carlos> it worked
<carlos> I missed that word :-P
<carlos> pitti: cool!
<carlos> so do we have new language packs?
<pitti> carlos: the first two attempts failed because there were new packages
<ogra> Q-FUNK, i think it would be a lot more convincing if there was a fredesktop.org spec
<pitti> carlos: I'm building test debs now and test them on my breezy system
<Q-FUNK> ogra: isn't there one?
<ogra> so you could have a standard that applies to all desktops 
<carlos> seb128: dude, I know you are not the author but gnome-xchat rocks! I love the pop-up notifications!
<ogra> i dont think so ..
<pitti> carlos: if you want to test Spanish packs, I can build debs for you, too
<carlos> pitti: yeah, it's a good way to test them...
<ogra> Q-FUNK, at least it would be news to me if that moved from g-s to f.d.o
<carlos> pitti: give me the URL as soon as you have it, please
<Q-FUNK> ogra: afaik all apps that have to do with free DE are supposed to come with a .desktop file nowadays
<ogra> hacks are not apps :)
<ogra> the dont even reside in $PATH
<Q-FUNK> they probably qualify
<Q-FUNK> well, anyhow
<seb128> carlos: thanks, I like the bubble too :)
* mvo hugs seb
* mvo hugs seb128 
* seb128 hugs mvo
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/
<pitti> carlos: ^ fresh breezy-updates langpacks
<pitti> carlos: I need to go now and will test the German/English ones tonight
<pitti> carlos: and upload the lot if your and my tests go well
<carlos> pitti: cool thanks
<carlos> ok
<carlos> I will mail you with the confirmation that all seems to be ok 
<pitti> carlos: thank you
<Diziet> doko: ping
<doko> Diziet: pong
<Diziet> I think I have made ff not use /usr/lib/mozilla.
<doko> nice!
<Diziet> You seemed to have some difficulty with libcknss ?
<Diziet> I did what seemed like the obvious things and it seems to WFM.
<janimo> are UVF exception syncs requested on ml (I see MOTU do this) or here?
<Diziet> I have no /usr/lib/mozilla at all (no mozilla installed on that testbed) and ff works fine even with https.
<Diziet> Is there some other test I should do ?
<Diziet> I left the libnspr headers in /usr/include/mozilla.  I hope that's ok.
<janimo> if the latter I'd like to ask for exo and thunar to be synced. kamion,mdz ping
<mdz> those are universe packages; sync requests for universe packages should be coordinated with MOTU via dholbach
<janimo> mdz, thanks. I hope they are not going to stay in uni for long :)
<doko> Diziet: keeping the headers there makes libnspr-dev and libnss-dev conflict with mozilla-dev
<doko> the firefox-nspr and firefox-nss pkgconfig files could be adapted to just reference /usr/lib/mozilla-firefox
<Diziet> doko: Um.  What uses mozilla-dev and why doesn't mozilla use system nspr ?
<Diziet> And the pkgconfig files should reference /usr/lib/firefox, not /usr/lib/mozilla-anything, surely ?  Because that's what's in /usr/lib.
<Diziet> (Oh, bugger, this .pc file is wrong anyway.  So no upload today.)
<doko> Diziet: well, if the mozilla- and firefox- nspr/nss were compatible, we would not need to care about it ... AFAIK nobody did want to invest if they were, or if the separate nspr nss source distributions would be an alternative
<teuf> hi
<Diziet> doko: Hmm.  The way we're doing this (the whole thing of shipping nspr from ff) assumes that they're compatible.
<Diziet> Note that they have to be because an application might contain (i) something that embeds mozilla or ff and (ii) a plugin which depends (directly or indirectly) on nspr.
<doko> AFAIK nobody did check this ...
<Diziet> Well, I think my best answer is just to move the includes.  It's clearly wrong of the ff package to leave them there if the moz packages want that path.
<doko> Diziet: forwarded you an email from Eric Dorland, debian maintainer
<Diziet> Yers.
<Diziet> These untested combinations are inevitably going to be assembled in an uncontrolled way at runtime, though, no matter what we do.
<Diziet> It seemed better to have only one library providing a particular set of symbols and not to rely on a vague hope that you always get only one and always the right one ...
<doko> at least for eclipse, I add /usr/lib/mozilla to the LD_LIBRARY_PATH, before running the binary
<Diziet> Hmmm.  I really have to go RIGHT NOW.  Will you be around tomorrow ?  We can talk again then.
<doko> at least next week :-)
* poningru hugs mako
<poningru> thanks
<zyga> will the cpu scailing work on k7 before dapper releases or is there some major kernel problem that prevents this?
<Kamion> distro team meeting in #ubuntu-meeting in 8 minuts
<Kamion> er, minutes :-)
<Keybuk> "10 centons"
<ogra_> bah
<ogra_> galactica starts in germany on feb 2nd
<Keybuk> "starts", or second season starts?
<ogra> starts
<Keybuk> ouch.  we were lucky, we got the first season even before the US because the UK satellite network paid for a large portion ofi t
<ogra> we're a little late over here
<Keybuk> but we got the second season after, started in January
<pitti> Hi again
<mdz> devel meeting in 5 minutes in #ubuntu-meeting
<Burgwork> second season is damn good
<Keybuk> while that's happening
<Keybuk> I have a *great* bug
<Keybuk> bug #4729
<Ubugtu> Malone bug 4729 in alsa-driver: "blacklist em8300 in favour of ??" [Wishlist,Needs Info]  http://launchpad.net/bugs/4729
<Keybuk> basically the guy has a sound card that only OSS can drive
<Keybuk> and another one that ALSA can
<Keybuk> so he gets both the ALSA driver for his ALSA card, and the OSS driver for his OSS card ...
<Keybuk> which means the ALSA OSS emulation doesn't work, because OSS has /dev/dsp
<Keybuk> (whew)
<Lathiat> hah nice
<Keybuk> and I don't see that disabling all OSS sound drivers is a solution here
<Lathiat> indeed
<pitti> carlos: still here?
<carlos> pitti: hi
<carlos> yes
<pitti> carlos: thanks for testing
<carlos> any problem on your side?
<pitti> carlos: hm, I can't say right now that everything was from main
<pitti> carlos: universe is sorted out automatically
<carlos> pitti: ok
<pitti> carlos: but I can quickly cobble together a script that checks that
<pitti> carlos: no, german works just fine as well
<pitti> carlos: OTOH I didn't find any string that was untranslated before and is now translated
<pitti> carlos: so the bulk of the update might just be UTF-8 conversion, and thus no real advantage
<carlos> pitti: it's just a sanity check, if you are busy, don't worry. If there is a problem there we will have a problem with soyuz....
<carlos> pitti: the performance should be better
<pitti> carlos: oh, I can easily add a print statement to it and run a dummy build again if it helps you
<carlos> pitti: as glibc will not recode it on runtime
<pitti> carlos: but if that is fine, I'll upload the lot
<pitti> true
<pitti> mdz: okay for you to upload a splash of breezy-updates langpacks?
<pitti> mdz: ('to' == 'if I', of course)
<mdz> pitti: sure
<pitti> mdz: ok, I'll ping you after everything is uploaded
<pitti> mdz: ok, all sources are in accepted/
<pitti> mdz: (while you process these, maybe we can have a quick talk about the other -updates uploads which are bitrotting in accepted?)
<mako> poningru: hey there
<simira> have everyone in London gone to bed?
<HrdwrBoB> yes
<ogra> to disco ? 
<simira> :(
<simira> I should too, then.
<HrdwrBoB> Current timeThursday, January 26, 2006 at 9:58:26 PM
<mdke> not me
<mdke> i think you mean a different sort of "in London" tho
<ogra> simira, tollef is out with infinity, thom and fabio iirc
<simira> ogra: huh. Are you there? Will you give him some bad conscience from me? He shouldn't be out every night and work so much....
<ogra> simira, nope, not there yet, but he said so when he left -meeting
<siretart> slomo: I think malone 29243 can be closed now, no?
<Ubugtu> Malone bug 29243 in xine-lib: "I can't updated libxine1c2" [Normal,In Progress]  http://launchpad.net/bugs/29243
<slomo> siretart: nope... elmo doesn't answer my mail or does what i suggested there :(
<siretart> slomo: oh :(
<slomo> in theory it's a simple issue... libxine1c2 in universe, libxine-extracodecs in multiverse...
<siretart> hm
* shaya pokes scott
<shaya> infinity: you here?
<cliebow> mdz:  couple of us are interested in the qa job ogra mentioned
#ubuntu-devel 2006-02-01
<AlinuxOS> hello someone Armenian user here?
<AlinuxOS> or font package mantainer ?
<nickrud> does anyone know the proper syntax to use in /etc/apt/preferences for pinning according to release? (hoary, breezy, dapper)
<LaserJock> nickrud: I think the Debian Apt HowTo has that information
<nickrud> LaserJock, the Releases file for debian and ubuntu are not the same, and my mediocre attempts at reconciling them have failed
<LaserJock> nickrud: have you tried https://wiki.ubuntu.com/PinningHowto ?
<nickrud> LaserJock, thanks, component from that link may help me get where I need to be
<LaserJock> np, hope it helps
<nickrud> argh, no, it does not. Why, oh why, did ubuntu go so non-standard?
<Kamion> nickrud: we've changed nothing about the Release file syntax
<Kamion> nickrud: what are you trying?
<Kamion> (not that I use pinning myself, so I may only be of limited help)
<nickrud> Kamion, I'm trying (as an exercise, for fun, and all that) a downgrade on a dapper box. In debian, I'd pin to sarge, to downgrade a sid. I've not found an equivalent syntax
<Kamion> yes, what syntax are you using I mean
<nickrud> I was hoping for a quick, "oh, I know that :)" A second, Kamion, while I pull up some refs
<Kamion> I'd expect "Pin: release a=breezy"
<nickrud> Kamion, I'll try that; comparing the Release files, Suite or Codename is what I'd expect, and no, release a=breezy didn't do it
<nickrud> hm, I'll try lowercase breezy
<Kamion> from the code it appears to be case-insensitive
<Kamion> there's no facility in apt for matching on Codename as far as I'm aware; Suite maps to a=
<Kamion> (the former in the Release file, the latter in pins)
<nickrud> thank you
<Kamion> documentation's confusing, I had to grovel through the source
<nickrud> double thank you :)
<Kamion> it talks about Archive, which I suspect was an old name for Suite
<Kamion> if that doesn't work, might be worth looking at 'apt-cache policy' output for various packages to see what it's finding
<Kamion> that should tell you the pin priorities
<nickrud> Yes, that probably will get me there. It's just that I'm very cautious about things; for example ubuntu has a Version in the Release file, and Debian did not. That scares me :)\
<Kamion> Version maps to v= in pins
<Kamion> nickrud: Debian certainly does have Version in Release files, just only for released versions
<Kamion> because the version number doesn't get assigned until not that long before release in Debian; whereas we have a predefined version numbering scheme so we know it in advance
<Kamion> $ grep Version ftp/dists/sarge/Release
<Kamion> Version: 3.1r1
<Kamion> you can use v=5.10 if you like for breezy, should be equivalent
<Kamion> breezy-updates will be a=breezy-updates or v=5.10
<nickrud> but the version is not recorded in the Release File: aias: ~ $ head /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_Release
<nickrud> Origin: Debian
<nickrud> Label: Debian
<nickrud> Suite: testing
<nickrud> Codename: etch
<nickrud> Date: Wed, 25 Jan 2006 21:47:06 UTC
<nickrud> Architectures: alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
<nickrud> Components: main contrib non-free
<nickrud> Description: Debian Testing distribution - Not Released
<Kamion> so I guess that does mean there's a slight difference in semantics between a=breezy and v=5.10
<nickrud> yes
<Kamion> nickrud: testing isn't released and doesn't have a version number yet.
<nickrud> ah
<nickrud> :)
<Kamion> sarge does have a Version in its Release file.
<Kamion> (as I showed above)
<nickrud> Kamion, thanks, you've given me some paths to explore. thanks
<Kamion> np
<Kamion> the grep above was on ftp-master.debian.org, btw, so is canonical :)
<nickrud> god, I do love that word. It is so ambiguous
<Kamion> yep, good innit
<jsgotangco> good morning
<jordi> how do I find out what font is providing me with a UTF-8 character?
<wasabi_> I like the Restart Required systray icon.
<Riddell> lamont: when uploading kdebase I get Uploading via ftp kdebase_3.5.1.orig.tar.gz: Error '(110, 'Connection timed out')' during ftp transfer of kdebase_3.5.1.orig.tar.gz
<Riddell> is that likely to be my fault or the buildds?
<Kamion> source uploads have nothing to do with the buildds
<Riddell> good point
<Kamion> -rw-r--r--  1 poppy katie 28121368 Jan 27 00:54 kdebase_3.5.1.orig.tar.gz
<Kamion> is that the right size, or too small?
<Riddell> 28121368 it is
<Kamion> you could try uploading just the .changes then; the rest of the files seem to be in unchecked
<Kamion> dunno if poppy will let you do that
<Kamion> I don't know why it put an upload without a .changes in unchecked in the first place; strikes me as a bug
<floam> hm.
<floam> anyone notice that sense ubuntu changed the fileselectors default directory to ~/Documents that epiphany fails to respect your set download directory?
<floam> it always defaults to Documents now even if you've got it set to some other directory in ephys UI. (I'm hoping this isn't intentional)
<dabaR> So, did you guys know that there seems to be a bug in the download manager for firefox in breezy? Fx crashes when you have the download manager open, and when you do not, it does not crash.
<dilinger> ugh.  hate the new xchat in dapper.
<psusi> it has some strange default layout doesn't it?
<Burgundavia> psusi, dilinger bug the xchat-gnome people in #xchat-gnome on freenode
<LaserJock> the only thing I don't like about it is the user list. They obviously thought that nobody cared about how they chat with ;-)
<psusi> it isn't xchat... it's the profile or something... I'm running dapper on my desktop and my xchat still looks sane
<psusi> so it's got to be some default config file setting that got changed in the ubuntu package
<jdub> it's a totall different project
<Burgundavia> psusi, it is xchat-gnome, a fork of xchat
<jdub> vastly forked
<psusi> ohhh
<jdub> and, well, needing more love
<Burgundavia> indeed
<psusi> so.... it's like ubuntu-desktop depends on either xchat or xchat-gnome, but xchat-gnome is now prefered?  so I'm still using xchat since I upgraded?
<psusi> nevermind... looks like ubuntu-desktop just switched to xchat-gnome completely, but I had removed it at some point probably due to broken depends from the ABI breakage
<psusi> why did that change happen?  and can we undo it? ;)
<LaserJock> xchat-gnome is supposed to be more integrated. I really don't know what that means other than it maybe looks more like a gnome app?
<Burgundavia> LaserJock, it does have sexy spelling checking and handles urls better
<psusi> to me it looked like xchat, but with a fubar theme that rearanged everything in eye wrenching positions
<psusi> url handling is one thing I don't like about xchat
<psusi> oh my god... according to /. 40% of brits believe in creationism over evolution... is the whole world slipping into a new dark age?  I thought it was just the US that was filling up with retards?
<jsgotangco> :/
* jsgotangco is catholic :/
<LaserJock> psusi: well, I don't want to get into it but I'm one of the retards your talking about
<psusi> you're kidding?  you don't believe that evolution of the species takes place?
<bddebian> LaserJock: Me too ;-)
<LaserJock> psusi: umm, not in the sense that most people think of it no
<psusi> it's like saying the sky is blue because picaso painted it or something... not because it's filled with water dropplets
<bddebian> psusi: creationism and evolution are not necessarily mutually exclusive
* lakin agrees with bddebian.
<jsgotangco> yeah
<psusi> true... I'm talking about the people who believe they are though
<bddebian> Well there are extremists everywhere :-)
<jsgotangco> irregardless of religious belief
<psusi> i.e. literally believe that humans were plopped down on the earth by some magical man in the sky rather than evolving over millenia from lesser beings
<LaserJock> that would be me to a large extent ;-)
<bddebian> It's like pro-lifers that kill abortion doctors ;-P
<Burgundavia> guys, this is horribly offtopic
<psusi> that's some delicous irony right there
<jsgotangco> yeah
<bddebian> True, sorry
<Burgundavia> please take it to #ubuntu-offtopic
<psusi> hehe
<jsgotangco> i'd rather not talk about it really
<jsgotangco> its something private
<Burgundavia> jsgotangco, why are you not in -doc?
<psusi> Mithrandir, ping
<jsgotangco> ekk
<jsgotangco> im in a new client and i forgot
<psusi> Mithrandir, was wondering if there's any news on the e2fsprogs header that was causing dmraid to ftbfs on amd64
<dilinger> yea, i was talking about plain old xchat, not xchat-gnome
<dilinger> i have some 20 tabs open
<dilinger> it used to be, in order to close a tab/window, there was an 'x' up top that you clicked
<dilinger> they moved it right next to the slider arrows in the xchat that's in dapper
<dilinger> so now i go to slide my tabs around, and accidentally close windows
<dilinger> not just one, because in order to slide the tabs you must click multiple times; so i /part 3 or 4 channels before i realize what i'm doing and stop
<dilinger> *really* annoying
<neuralis> mdz: please review the updated CommunityServerHardwareTesting with the web catalog split out to HardwareTestingCatalog, and approve community-server-hardware-testing if you're satisfied.
<ajmitch> evening
<poningru> sorry to disturb but can someone confirm that networkmagic was aborted for dapper
<ajmitch> no, I know that people have still been working on it
<poningru> ok cool thanks
<ajmitch> whether it's ready & stable enough in time will be decided closer to feature freeze, I suspect
<Aegir> Sweet. Now. If only my wireless drivers would actually load on boot... Then networkmanager would be quite handy
<poningru> also any clue when espresso will land?
* mpt remembers a time when network-manager was planned for Hoary
<Burgundavia> poningru, soon
<Burgundavia> poningru, as for NM, it is probably not
<Burgundavia> poningru, not cancelled, that is
<Burgundavia> neuralis, your catalog spec doesn't cover any of the design of actually querying the db
<pitti> Good morning
<Burgundavia> neuralis, I also filled out the laptop use cases
<Burgundavia> salut pitti 
<pitti> mdz / Kamion: can you please approve all the breezy-update langpacks?
<neuralis> Burgundavia: thanks for filling those out. i have a feeling the catalog will get developed outside the general spec process (at least if it happens for dapper), so i'm reluctant at present to spend much time fleshing out the spec.
<ajmitch> neuralis: how are the other server specs going?
<Burgundavia> neuralis, that seems minor counterproductive. I can flesh out some of them if you want
<Burgundavia> s/minor/minorly
<neuralis> Burgundavia: counterproductive in what sense?
<Burgundavia> neuralis, having a spec will allow people to join you in creating it
<neuralis> ajmitch: c-s-h-t is the only one assigned to me; i haven't had time to pay close attention to the others.
<neuralis> ajmitch: i know there have been some licensing hitches with the cluster spec, and there is massive confusion about server certification, but malcolm and i can't seem to synchronize enough to get a phonecall through and discuss it.
<Burgundavia> neuralis, licensing of what sort?
<neuralis> Burgundavia: one of the primary pieces of software in the cluster spec links against openssl
<Burgundavia> oh ick
<neuralis> Burgundavia: yeah.
<neuralis> Burgundavia: i welcome your work on the catalog spec. i'm moving across continents in a few days, so i'm horribly busy and can't find the time for it now.
<ajmitch> neuralis: ah, licensing is annoying
<ajmitch> neuralis: selinux work is going ahead again, thankfully
<Burgundavia> ajmitch, anything in place for dapper or are you looking at dapper+1?
<ajmitch> Burgundavia: I'm looking at policy packages & some few admin tools in universe for dapper
<ajmitch> promotion to main after some testing for dapper+1, if all goes well
<ajmitch> I could probably get policy ready for main for dapper if I worked hard :)
* ajmitch would suggest a policy that only contrains daemons, trying to target all those in main
<ajmitch> but it'd depend on what would be approved
<Burgundavia> selinux is good, if only a pr front
<ajmitch> I'd hate to have it as only pr
<Burgundavia> I have heard/read a few people bang us around on security (wrongly) because we don;t have selinux
<Burgundavia> ajmitch, yes, I realize that. Remember, I am the salesman, I think in terms of PR
<ajmitch> targeted policy for main is basically what fedora has
<ajmitch> I'm surprised that people are that concerned about it though :)
<ajmitch> though I know it can bring real benefits
<Burgundavia> ajmitch, mostly it is optics, nothing more
<ajmitch> hm?
<Burgundavia> selinux is a fancy name to swing around. Things like the work of pitti derooting things just doesn't have the same ring
<Burgundavia> ajmitch, you looked at apparmour yet?
<ajmitch> so you think selinux is just smoke & mirrors?
<Burgundavia> ajmitch, far from it
<Burgundavia> I am merely pointing out the great marketing opportunities from this
<ajmitch> 'mostly optics' and 'a fancy name' doesn't sound like you think highly of it
<Burgundavia> ajmitch, sorry, I am not talking about the technology. I am talking about the preception of the technology
<Treenaks> ajmitch: fwiw, all I've seen of selinux until now is hype
<Treenaks> ajmitch: or severe restrictions which made the system barely useable
<ajmitch> Treenaks: if you were using an early strict policy on fedora core 2 or similar, then yes, it was hard to use
<Burgundavia> Treenaks, it seems to be working for Fedora now. They just had to make a few mistakes along the way
<ajmitch> nowadays it has improved an awful lot
<Treenaks> I still don't see the need, but I might be weird
<Burgundavia> Treenaks, any and all security is a good thing
<tepsipakki> ajmitch: I'll test the policy when you have it ready. selinux is useful for multi-user systems..
<Treenaks> Burgundavia: maybe; try getting into the building here at work and you'll start to disagree ;)
<Burgundavia> Treenaks, caveat my statement with "where implemented appropriately"
<ajmitch> Treenaks: because running daemons with fewer privileges is a good thing - beyond just derooting :)
<Burgundavia> I trust ajmitch is smart enough not to make the same mistakes as FC2
<ajmitch> tepsipakki: thanks, it'll need a lot of testing :)
<Treenaks> ajmitch: oh sure.. as long as it doesn't make the system as a whole 50% slower because of all the checking
<ajmitch> Burgundavia: because I'll be using the same policy base as FC5
<ajmitch> Treenaks: about the highest performance impact people have seen is up to 5% in some cases
<Burgundavia> ajmitch, cool. Have you been in contact with the FC people to poll knowledge/work?
<Treenaks> ajmitch: if it's default, people with slow computers will cry
<ajmitch> Burgundavia: yes, especially this week at LCA
<ajmitch> Burgundavia: I've known & talked to russell coker for awhile
<Burgundavia> ah
<ajmitch> Treenaks: considering that I'm mainly advocating it for server use..
<Treenaks> ajmitch: that doesn't help... someone might not get that point and enable it for everything
<ajmitch> Burgundavia: he's a DD & quite willing to help out with policy problems, as he works fulltime on policy & related stuff 
<ajmitch> Treenaks: and someone might not get that you don't run KDE on a p166
<Treenaks> you don't?!
<ajmitch> Treenaks: you didn't get that I said 5%, in some cases when the system is loaded :P
<Treenaks> ajmitch: I remember running KDE1 on that ;)
<ajmitch> I've run selinux with no noticeable perfomance drop on my older systems
<ajmitch> yes, so did I.. ;)
<Aegir> KDE2 will run on a p166. Runs quite nicely infact.
<ajmitch> Aegir: 3.5, however...
<ajmitch> and with 32MB RAM
<Aegir> ajmitch: Heheh
<Aegir> ajmitch: Oh, good point. My P166 laptop had 90'ish MB of ram
* ajmitch had 64MB, but that's no real issue
<Burgundavia> anyway, I have to sleep. night all
<ajmitch> Treenaks: your bad experiences with it in the past seem to make you wary of it now :)
<ajmitch> it's not like OOo2, where the developers conspired to make it even slower :)
<Treenaks> ajmitch: I'm just not convinced that the standard security model that we've been using for ages is broken enough :)
<ajmitch> oh it is ;)
<ajmitch> we just manage to stay ahead of the more serious problems at times
<pitti> mjg59: libpam-foreground looks fine now, I approved it; it needs germinating and promotion to main now
<tepsipakki> ..and some docs ;)
<pitti> heh, well, it doesn't do much, but true
<tepsipakki> without docs it won't do even that much ;)
<tepsipakki> anyway, I'm patient..
<ajmitch> hey pitti 
* pitti waves to ajmitch 
<pitti> Kamion: who is currently in charge of the automatic keyboard selector in the installer (which determines layout by pressing keys)
<pitti> ?
<pitti> Kamion: it insists that I have a 'jp106' keyboard when I press pc104/US keys (which I want)
<pitti> Kamion: also, do you want a bug report about the proxy dialog, which is superfluous when installing without network?
<pitti> Kamion: (oh, forget the proxy thing, that's already fixed now)
<pitti> oh no, it's not
<doko> Kamion: today's install CD just hangs "Unpacking libsqlite0 ..."
<Kamion> pitti: feel free to send me details of which keys you're pressing in which order in a bug against kbd-chooser (for now)
<Kamion> pitti: the proxy question is displayed because it's hard for choose-mirror to tell the difference between "no network" and "internal network only, needs proxy to get out to the Internet"
<Kamion> I suppose ideally it would check for an interface being up or something
<Kamion> doko: sure it's not a dodgy CD?
<Kamion> if nobody digs into it I'll sort it out at the sprint I guess
<pitti> Kamion: bugs reported about both issues
<pitti> Kamion: I'm doing a current ppc install ATM, I'll watch out for the libsqlite thingy
<doko> Kamion: maybe, but that happens after the packages are copied to the hard disk
<doko> Kamion: minor bug: the installer says "Downloading packages", while copying them from the CD
<doko> ok, installation did succeed by just restarting it ...
<doko> hrm, no /etc/X11/xorg.conf ...
<ajmitch> libsqlite0 is still on the cd?
<Kamion> doko: packages aren't copied to the disk any more
<Kamion> unless apt does that, but I don't think it does
<Kamion> doko: aptitude bug, not my fault :)
<Kamion> should just say Retrieving or something
<pitti> ajmitch: it's on the kill list on DapperDuplicatedPackages
<ajmitch> pitti: that's what I thought
<ajmitch> hm, that apparmour looks interesting, though it's certainly less comprehensive than selinux
<Kamion> pitti: er, isn't it bad for breezy-updates versions to be > dapper for language packs?
<doko> mvo: ^^^
<mvo> doko: asking about the hang? what does ps ax show? is dpkg still runing?
<doko> mvo: no, aptitude saying "Downloading" while "copying"
<mvo> doko: can you strace `pidof aptitude` please?
<doko> mvo: too late, that was during the installation ...
<pitti> Kamion: hm, eventually I should encode the release version number, true
<Kamion> mvo: AFAICT aptitude just unconditionally says Downloading
<Kamion> it certainly does it reliably on every installation
<mvo> doko: is the problem reproducable?
<Kamion> pitti: is there going to be an update to dapper too?
<mvo> Kamion: ah, thanks
<doko> mvo: ehh, I'm not reinstalling again today ...
<pitti> Kamion: it seems that I have to do that, unless we want to reject all those packages
<pitti> Kamion: thanks for spotting that
<Kamion> not especially, considering that rejects from -updates are kinda hard anyway
<pitti> Kamion: I'll build the dapper ones with version 1:6.04+2006blabla
<pitti> Kamion: and the future breezy/hoary ones likewise
<Kamion> sounds reasonable
<pitti> oh, no need for the epoch, even
<mvo> doko: ok, but it happend with todays image?
<pitti> no, we do need an epoch
<Kamion> yes
<pitti> Kamion: ok, I'll build dapper packs now, maybe we should hold back the breezy ones for now
<doko> mvo: yes
<mvo> doko:  20060127 (i386)? or amd64?
<mvo> amd64 is a bit awkward for me to test (it's my main workstation)
<pitti> mvo: no spare partition? :)
<Kamion> pitti: ok, let me know when you've uploaded them
<mvo> pitti: sure, but it means, I can't work that efficiently anymore :)
<doko> mvo: $ md5sum ubuntu/dapper-install-i386.iso
<doko> b3c61ad9e6cd3c6b4c7ddcd4ffc4136e  ubuntu/dapper-install-i386.iso
<mvo> doko: I give it a try here once it finished downloading
* mvo waves to enrico 
<enrico> Hi mvo!
<mdz> infinity: awake?
<pitti> good morning Matt
<Mithrandir> mdz: he'll be around in a minute or two.
<seb128> hi mdz
<mdz> morning
<mdz> neuralis: done
<mdz> Mithrandir: thanks
<infinity> mdz: Yo.
<mdz> infinity: could you make available to Kinnison and cprov copies of the current buildd chroots from the production environment?
<infinity> Yup, can do.
<mdz> thanks
<mdz> Kamion: what would it take to arrange a CD build test using the soyuz-published archive?  ship a copy over to little?
<janimo> pitti, hi could you schedule xfdesktop review for when you have time? It's the only essential package of the remaining xfce bits. thank you
<pitti> ok
<Kamion> mdz: is it accessible within the DC? then I could just mirror that
<Kamion> after that presumably it should be pretty trivial for me to try
<dholbach> hello
<pitti> doko, Kamion: no problem with libsqlite0 here on ppc/daily
<pitti> hi dholbach 
<dholbach> hey pitti
<pitti> doko: confirmed, I have a 0-byte xorg.conf here, too
<pitti> doko: did you already file a bug about this?
<pitti> hrm, of course I don't have a backup for xorg.conf *grumpf*
<tepsipakki> pitti: it's already filed
<pitti> ok, thanks
<tepsipakki> pitti: https://launchpad.net/distros/ubuntu/+source/xorg/+bug/29564
<Ubugtu> Malone bug 29564 in xorg: "xorg.conf is left empty by installer" [Normal,Unconfirmed] 
<Kamion> (not that it's the installer doing that)
<tepsipakki> yeah, well it wasn't reported by me ;)
<tepsipakki> "during install" is closer
<Kamion> your comment said "I can confirm that the installer leaves ..." :-)
<tepsipakki> oh
<tepsipakki> grr
<tepsipakki> great day, can't even remember stuff I did 5min ago
<mdz> Kamion: it's accessible both within and without
<mdz> Kamion: staging.archive.ubuntu.com
<Kamion> I suspect I'll run into rsync limits on that eventually, but sure
<doko> which are the most recent install cd's for ia64?
<Kamion> doko: http://cdimage.ubuntu.com/ports/daily/current/
<doko> Kamion: thanks
<doko> Kamion: but not available via rsync?
<doko> found them ...
<Kamion> rsync URL constructed as usual
<Kamion> mdz: rsyncing over to little now
<Kamion> will take a while, I'm sure
<mdz> Kamion: did you make a copy of the existing archive on little and rsync --delete over that?
<mdz> might be quicker
<Kamion> only by 50% at most, due to ports
<mdz> ports?
<Kamion> hppa/ia64/sparc
<mdz> those are present in both archives
<Kamion> at the moment they're in a separate tree on little
<Kamion> due to the way mirrors are presented to me
<mdz> ah
<Kamion> Kinnison: I thought there weren't supposed to be main->universe symlinks any more
<Kamion> pool/main/b/bison-1.35/bison-1.35_1.35.orig.tar.gz -> ../../../../pool/universe/b/bison-1.35/bison-1.35_1.35.orig.tar.gz
<Kamion> besides, this way gives better logs :)
<Kamion> I'm also curious to know how long it takes to sync the whole thing from scratch, for future cdimage planning
<Kinnison> Kamion: Erm, odd
<Kinnison> that's not in my archive
<Kinnison> Kamion: you sure you're looking in an lp-generated archive rather than a katie one?
<Kamion> it's definitely rsyncing from staging.archive.ubuntu.com::ubuntu/
<Kamion> according to ps
<Kinnison> which isn't right
<Kinnison> Well, I assume it won't be
<Kinnison> since I never set that up
<Kamion> where is the correct rsync URL?
<mdz> I don't know that rsync is set up for this archive
<Kinnison> I doubt it is
<Kamion> please do that, I need it
<mdz> if you aren't syncinc with an existing archive, I don't see why you need rsync
<Kamion> I'm not rewriting everything to use HTTP
<Kamion> I will be, for everything but this one test
<Kamion> so we need rsync anyway, might as well have it
<mdz> Kamion: elmo is not here right now
<mdz> Kamion: if you open up an nc -l I will netcat it over to you from drescher
* Kinnison will try and get znarl to do it
<Kamion> I'd much rather have the opportunity to make sure anonftpsync works on lp
<Kamion> there are some interesting cases in that script wrt symlinks
<Kamion> since I know that symlink layout is slightly different in lp, I want to test that
<mdz> you'll get exactly the same layout
<Kamion> Kinnison has told me that it differs
<Kamion> in particular, no main -> universe symlinks like we have on katie
<mdz> you'll get the same layout via nc that you would via rsync
<Kamion> er, sorry, how does this work with nc?
<mdz> nc -v -l -p 1234 | tar xvf -
<Kamion> ok, but we'll have to rerun all this again in order to test anonftpsync.
<mdz> ok
<siretart> mdz: I don't know if you read the ipython discussion on ubuntu-motu. the debian maintainer (nobse) told me these days, that upstream would like to see the current version in dapper (0.7.1). I've already sent an diffstat and changelog for 0.7.0. I trust nobse (the DD) in charge. are you okay with the update or do you want more analysis?
<Kamion> mdz: 1234 opened
<Kamion> using tar xvpf
<mdz> siretart: I don't have a problem with it, no.  note that universe UVF exceptions are meant to be queued through dholbach
<siretart> mdz: we are still waiting for answer :)
<dholbach> mdz: I sent a mail to colin and you
<Kinnison> Kamion: don't expect the dists/ for anything other than dapper/ to make sense. And we don't have the installer-* dirs yet
<Kamion> mdz: could you cd to ubuntu-archive/ubuntu/ and do that again?
<Kinnison> Kamion: if you rely on those, we need to wait some more time
<Kamion> Kinnison: I rely on those for anything meaningful
<Kamion> Kinnison: I don't need them for live CD builds, but live CD builds hardly touch the archive at all on little
<Kamion> rely on> installer-*, that is
<Kinnison> Kamion: then they're jumping the gun
<Kinnison> which, tbh, they tend to do
<Kinnison> Kamion: we'll prod you when we're ready, and hopefully we'll have rsync ready too
<Kamion> ok, shut down nc again then
<Kinnison> Sorry colin
<Kamion> I'd offer to come down to London for better communication, but I have to stay here to look after the child
<Kamion> feel free to phone me if need be
<mdz> Kamion: connection refused
<Kamion> 10:57 < Kamion> ok, shut down nc again then
<Kamion> there's no point until I have the installer-* directories
<mdz> Kinnison: ok, I need to take care of some other things
<mdz> Kinnison: please drive nc if needed
<Kamion> I won't be able to build a complete CD without those, and will have trouble comparing with previous images etc.
<ajmitch> mdz: is it too late for dapper bounties? :)
<ajmitch> given that feature freeze is in a few weeks
<mdz> ajmitch: depends on how long the project would take to complete, whether it has a spec...
<mdz> feature freeze is the deadline for delivery
<Kamion> btw, is it a bad idea to upload NEW stuff today?
<ajmitch> selinux spec, I'm just working on policy now
<Kinnison> mdz: I will do, thanks
<Kamion> as in, will it be carried over to soyuz?
<mdz> Kamion: I think there are already packages in queue/new we'd need to deal with
<infinity> Oo, my FS just remounted readonly.  AFK for a while.  fscking.
<\sh> seb128: please don't assign gajim bugs to gajim-maintainers team, instead use motu or motuim team
<seb128> why?
<seb128> why is there a gajim team if they don't do gajim?
<\sh> seb128: because gajim-maintainers are upstream, and not the ubuntu responsible people in the first place :)
<seb128> and upstream don't want to heard about bugs in their software?
<seb128> what a nice upstream, I'll keep using gaim
<\sh> seb128: they don't use launchpad for bugs :)
<seb128> so they should not care
<pitti> ogra__: any reason why schooltool and schoolbell have lots of translations (po files), but don't ship mo files?
<\sh> seb128: we had some discussions about this topic...and I'm thinking about taking over the reponsibilties of gajim-maintainers team...gajim upstream are using launchpad only for translations so far
<seb128> maybe they will reply to some bugs when getting the mails, that's their software, they should care a bit for it
<pitti> ogra__, doko: oh, may it be that zope and zope apps (school{tool,bell} don't use gettext, but use po files directly?
<pitti> because they ship the po files
<ogra__> pitti, i must admint, i never looked at translations in schooltool
<pitti> ogra__: well, as long as they work, it's fine
<\sh> seb128: but first there must be a test if it's happening only with our package or it is really an upstream problem, and then we'll inform upstream directly
<\sh> seb128: or fixing the problem and push the patch towards upstream
<ajmitch> morning \sh 
<seb128> bah
<\sh> moins ajmitch 
<siretart> \sh: if you want gajim bugs to be filed against the gajim lp team, you could indicate that with adjusting the maintainer field
<seb128> gajim upstream are ... no comment
<seb128> hate such upstream
<\sh> siretart: no..the reporter tested gajim on dapper...and this is our area..not upstreams.
<\sh> upstream == real upstream
<\sh> siretart: we had some real hard discussions about this with kiko and nkour on #launchpad :)
<\sh> coffee time
<seb128> so you run a LFS box to reproduce bugs out of Ubuntu before forwarding them? :p
<doko> pitti: schooltool/schoolbell is currently broken, because it doesn't work with zope3.2
<siretart> \sh: err, no, you misunderstand me. I mean the maintainer field of the gajim package in dapper
<pitti> doko: gcj does not ship mo files as well, although it looks like it should
<pitti> doko: gcj-4.0 source package, in particular
<pitti> doko: hmm, maybe not, src/gcc/po, src/libcpp/po, src/libstdc++-v3/po doesn't look very gcj specific; the po files might just be superfluous
<\sh> seb128: please...I'm really not in the mood of discussion the mess with real upstream maintainers and launchpad issues. I'll be happy when I convience real upstream to use launchpad, instead of trac, which is quite difficult, when you are dealing with real upstream and real upstream has a debian package maintainer in their team...and no, i will stop discussion this issue right here. MOTU IM is dealing with it..and will take the necessary ac
<\sh> s/discussion/discussing/
<doko> pitti: gij/gcj/libgcj don't have any po/mo files
<seb128> no problem, I'll just no use gajim if upstream are that kinds of guys and don't care about their software
<pitti> doko: ok, thanks
<pitti> doko: it causes translation import errors, so I'll just blacklist them
<seb128> (and sure, I'm dealing with fake upstream all the time)
<\sh> seb128: to be honest, i think it's more a jabber server problem not using the right DNS records...
<doko> pitti: yes, maybe because these are duplicated. it's the same tarball as gcc-4.0
<mantiena-baltix> Kamion, Hi
<pitti> doko: yes, that sounds plausible
<Kamion> mantiena-baltix: hello
<mantiena-baltix> Kamion, I've read latest Ubuntu Dev status and found there info, that you will upload your ubuntu-express today :)
<Kamion> should be able to, yes
<Kamion> aside from it not being called ubuntu-express, of course
<mantiena-baltix> Kamion, when and where ?
<Kamion> dunno. the archive, of course
<mantiena-baltix> archive.ubuntu.com ?
<Kamion> I don't generally bother with staging repositories or whatever
<Kamion> yes
<Kamion> note, it will *not* be easily backportable to anything breezy-equivalent
<Kamion> I think I mentioned that to you before though
<mantiena-baltix> Kamion, yes, I remmember your worlds about dependancies to latest debconf
<Kamion> http://people.ubuntu.com/~cjwatson/bzr/espresso/ubuntu/, anyway
<mantiena-baltix> Kamion, because of this my strategy for this (and next) week is to try integrate some parts of your expresso installer into guadalinex ubuntu-express
<mantiena-baltix> at least 3 parts of guadalinex ubuntu-express are more or less broken - autopartitioning, copying and installing bootloader
<Kamion> mantiena-baltix: I understood that Guadalinex were coming up to a release
<Kamion> I don't think they'd want this code right before a release; if nothing else it's currently very slow and the UI is unresponsive at many points
<Kamion> it's perhaps worth noting that aside from autopartitioning, copying, and installing the bootloader, there isn't that much else ;-)
<mantiena-baltix> Kamion, yea, but I don't need your UI now, guadalinex ui is good enough for me ;)
<Kamion> mantiena-baltix: you're missing the point, I'm afraid
<mantiena-baltix> Kamion, what point ?
<Kamion> mantiena-baltix: the changes I've made to autopartitioning and installing the bootloader are intrinsically connected to the UI and its responsiveness; you cannot separate them
<mantiena-baltix> :(
<Kamion> I do plan to make the UI more responsive, obviously
<mantiena-baltix> Kamion, so, there are no backend/frontend now ?
<Kamion> but I don't have time to do it before the distro team sprint next week, which is my target for an initial version
<Kamion> mantiena-baltix: there is, but the debconffiltered backends drive the frontend in places
<Kamion> and it isn't separated quite enough yet to allow the frontend to keep processing UI events in the meantime
<pitti> jbailey: somewhere between glibc 2.3.5-1ubuntu11 and 2.3.5-1ubuntu17 no .mo files were shipped any more (libc.mo). Is that deliberate or a bug?
<Kamion> somebody mentioned passing stuff over dbus rather than using the current whatever-works mechanism, or maybe there are other IPC mechanisms available
<Kamion> I hope to investigate that next week
<mantiena-baltix> Kamion, ok, thanks for info. how about file copy ? guadalinex ubuntu-express has very slow copying, because it collects information about every file, which needs to be copied and then copies each file separately instead of copying whole folders (/usr/, /lib/, /etc/, etc..)
<pitti> jbailey: ah, I know: 2.3.5-1ubuntu17 disabled the locales package, which apparently shipped libc.mo. Can you please install them into the libc6 deb?
<Kamion> mantiena-baltix: hmm? it just seems to use cpio
<Kamion> oh, it does have to find them all in advance, I guess, but since it's only in two processes I'm not sure it should make all that much difference ...
<Kamion> anyway, I haven't touched that
<seb128> jbailey: another duplicate of #28640
<jbailey> pitti: Will do.
<pitti> jbailey: great, thanks
<mdke> gnome-panel is not installing properly, is this known? http://pastebin.com/525480
<mdke> seems to install ok the second time around
<pitti> hey sabdfl 
<seb128> mdke: seems to be a scrollkeeper-update crash
<ajmitch> morning sabdfl 
<seb128> mdke: sudo scrollkeeper-update -q ?
<mdke> seb128, can I get any more useful information out of my system, given that the packages have installed ok the second time I tried?
<sabdfl> hi guys
<mdke> hey sabdfl 
<seb128> Hi sabdfl
<Kinnison> hey sabdfl feeling better?
<mdke> seb128, that command shoots out some errors, I'll paste em
<mdke> seb128, it is just lots of this: http://pastebin.com/525483
<mdke> but as I say, gnome-panel is installed ok now
* mvo goes for lunch
<carlos> mvo: hi, around?
<LeeJunFan> Anyone know the mirror maintainer? Looks like us.archive.ubuntu.com is stuck. missing such things as hal updates and some other stuff.
<sabdfl> yes thanks Kinnison, now i just have to write a keynote for LCA :-)
<mvo> carlos: lunch, is it urgent?
<carlos> mvo: no, just ping me when you are back ;-)
<ajmitch> sabdfl: we'll look forward to it :)
<carlos> mvo: enjoy your lunch
<ajmitch> assuming I can wake up in time
<hunger> Any intend to package the new gentium font yet?
<hunger> "belonging to all nations" (== gentium) would fit well with ubuntu:-)
<siretart> Kamion: does lintian also need UVF exception? I just stumbled over a bug (false positive error) and noticed, that djpig recently uploaded a new lintian to debian, fixing many many bugs. I'd like to upload that version, with our (trivial changes) merged
<mjg59> pitti: Rock, thanks
<Kamion> siretart: yeah, mail me/mdz as usual for main
<siretart> Kamion: okay. will do.
<Kinnison> Kamion: right, rsync is available
<Kinnison> Kamion: staging-ubuntu
<Kinnison> Kamion: I've copyied the installer-* from archive.ubuntu.com's dapper/main
<Kinnison> Kamion: I hope that's enough for you for now
<Kamion> Kinnison: rsyncing now, thans
<Kamion> thanks
<Kamion> Kinnison: you'll want to be sure to copy daily-installer-* too
<Kamion> although installer-* will do for now
<Kinnison> Kamion: okay, although the archive won't necessarily be in sync for that
<Kamion> you could tell infinity/lamont/fabbione (all) to shut down the daily builds
<Kamion> at some time that's convenient
<Kamion> or we can just not process them, and transfer queue/byhand/ to launchpad after the migration
<fabbione> Kamion: i am not building daily atm, you have green light my side
<infinity> Kamion: d-i or live, or both?
<infinity> d-i dailies will fail miserably anyway, since Kinnison stole those machines. :)
<hunger> Hmm... is it only me of does apt fail to recognize that it has installed python-twisted and python2.4-twisted?
<hunger> apt-get -u upgrade wants to upgrade those two and does not give any error message.
<Kinnison> infinity: Hehe
<Kinnison> infinity: ask mdz what he wants to do about it :-)
<hunger> running apt-get -u upgrade again results in it doing the installs again.
<Kamion> infinity: just d-i
<dholbach> gar! It took me some time to figure out my network problems were my brothers edubuntu installation which offered dhcp in addition to the dsl router
<ogra> ouch
<dholbach> Yes. I wondered how the network could be *that* flakey.
<lamont-away> Kamion: there is the lingering question of what hppa/sparc will do in the launchpad world...
* tseng is making a network segment today to isolate his own dchp netboot server
<Kamion> lamont-away: SEP from my point of view, though :)
<mdz> infinity: you can either set up the daily d-i build on the remaining machine, or do a daily sourceful upload and let it happen in the usual way
* Kamion doesn't want to touch that ...
<infinity> Kamion / mdz : Kay, well, daily d-i is disabled for now, I'll sort out the move a bit later.
<lamont-away> Kamion: SEP?
<Kamion> lamont-away: Somebody Else's Problem
<lamont-away> Kamion: ah, well.  hrm... yes.
* lamont-away votes for elmo.
<lamont-away> :-)
<Kamion> not to say I don't want it fixed, just that I don't want to end up hacking Soyuz :)
<Kinnison> I thought sparc was soon going to be in the datacentre
<infinity> In theory, but we still need to sort how how to do non-DC ports at some point.
<infinity> Like the s390 port that's been bandied about.
<jbailey> infinity: *blink*
<jbailey> infinity: You're kidding, right?
<infinity> jbailey: Nope.
<pitti> jbailey: he'll announce an m68k port next week, shall we bet?
<Kinnison> infinity: Yeah, I have a plan for non-DC ports
<Kinnison> infinity: mostly done, just needs some tweaking
<infinity> pitti: Already bootstrapped on Coldfire. :P
<jbailey> infinity: In qemu?  /me says hopefully.
<infinity> jbailey: No, on bare metal.
<jbailey> I think we should have a rule anything slower than 250mhz needs to run in qemu.
<jbailey> I wonder if s390s come in a desktop model so I could get one here.
<Kamion> Kinnison: archive still syncing. definitely don't wanna do this from scratch every time, gigabit networking or no.
<Kamion> :)
<Kamion> it's at k
<lamont-away> dear casper.  please launch getty's on ttyS[01] , esp if starting gdm fails.  kthxbye
<lamont-away> jbailey: apt-get install hercules
<lamont-away> :-)
<jbailey> lamont-away: Right, I keep forgetting about that.  do you know if it needs extra ROMs or anything?
<lamont-away> nothing extra needed.
<lamont-away> of course, you'll need to install a kernel. :-)
<jbailey> *gasp*
<jbailey> INSUFFICIENTLY USER FRIENDLY, BAH!
<lamont-away> there's this free one you can use, or you can buy VM from IBM or somesuch.
<jbailey> Err.
<lamont-away> jbailey: mind you, I've never done it.  But I know dannf has one on his ia64 box.
<jbailey> lamont-away: Do you know if it's reasonably performant?
<lamont-away> nfc
<jbailey> Fair 'nuff.
<lamont-away> iz pretty phat ia64 box
<lamont-away> faster than an m68k, almost certainly. :-)
<lamont-away> I think it falls into the "doesn't suck horribly" category.
* tseng tries to picture lamont saying "iz pretty phat" in real life
<lamont-away> tseng: it happens
<jbailey> tseng: I think I've even heard it.
<lamont-away> although, for some reason, it seems to trend towards my mutiliation of a french accent. :0)
<jbailey> lamont-away: Mine's only a dual 900, but the 10gb of ram makes up for a lot. =)
<lamont-away> jbailey: yes, it does.
<jbailey> lamont-away: We tried comparing building gcc on a ramdisk and on disk.  No speed difference because it never leaves cache anyway.
<lamont-away> jbailey: as it should be.
<lamont-away> you need more ram, though, so you can keep the entire build chroot in ram
<jbailey> =)
<mvo> carlos: I'm available now
<carlos> mvo: hi
<carlos> mvo: I have a problem with latest update-notifier on Dapper
<carlos> mvo: it makes X.org eat most of my CPU cycles
<mvo> carlos: can you strace it?
<carlos> mvo: I will try to do it when I restart my session
<carlos> I had to kill it
<carlos> and executing it by hand seems like works without problems
<mvo> carlos: ok, if it happens again, please strace it
<carlos> will do
<bronson> Is there any reason CONFIG_9P_FS is not set in 2.6.15-11?
<bronson> Why not make it as a module?
<bronson> (this is the v9fs network filesystem -- looks to be real nice)
<mdz> bronson: that'd be one for #ubuntu-kernel, kernel-team@lists or BenC
<bronson> hah -- didn't even realise ubuntu-kernel existed.
<bronson> mdz, thanks.
<pitti> lamont-away: any idea why rookery:~lamont/public_html/translations has not a single tarball for diffutils?
<lamont-away> because diffutils is unloved? :-)
* lamont-away checks
<pitti> lamont-away: diffutils has po and mo files and all that
<pitti> pkgstriptranslations creates a nice tarball
<pitti> lamont-away: hmm, boggle - the build log has no trace of pkgstriptranslations
<lamont-away> well, that would explain it.
<lamont-away> last built in sept, for that matter.
<pitti> lamont-away: ... because it doesn't use debhelper *headdesk*
<pitti> lamont-away: ok, nevermind, sorry for the noise
<lamont-away> np
<lamont-away> do I see a -ubuntu2 upload in our future?
<pitti> yes, in a very near future
<mvo> carlos: can you please import gdebi into rosetta?
<bddebian> Morning
<simira> god afternoon
<simira> s/god/good
<carlos> mvo: breezy?
<carlos> mvo: product?
<mvo> carlos: dapper, product "gdebi"
<carlos> mvo: dapper is not ready to be translated with Rosetta
<seb128> take it as an upstream project
<carlos> mvo: we will open it soon so I suppose it should be automatically imported
<carlos> seb128: ?
<seb128> carlos: it needs to be translated, it's mvo software, if we can't get to rosetta as a package it can be registred as a project no?
<mvo> carlos: it's available as a (upstream) prodcut in rosetta I think
<seb128> mvo: you can update a .pot for your own project I bet
<zakame> hi devs :)
<carlos> seb128: if it's Ubuntu specific, it should not be added as a product
<mdke> the first one needs to be imported
<seb128> carlos: that's an app, I bet Debian is going to jump on it :)
<carlos> seb128: ok
<mvo> carlos: it's available in debian as well
<seb128> carlos: it's a "double click on a deb to install it"
<carlos> mvo: then I suppose you as upstream would want to use Rosetta  ;-)
<Kamion> Kinnison: archive synced (taking nearly two hours); just syncing up the katie archive so I can do side-by-side test builds now
<seb128> carlos: every .deb based distro will want to use it :)
<carlos> mvo: import it as a product, please
<mvo> carlos: yeah, I just need to figure out how to make gdebi actually my project :)
<seb128> carlos: https://launchpad.net/products/gdebi
<carlos> mvo: aren't you the owner?
<seb128> Registrant:
<seb128> Tim Fuchs 
<seb128> 
<carlos> ok
<seb128> who is  he?
<carlos> I will change it now
<carlos> seb128: someone that likes the application ;-)
<seb128> ah ok
<seb128> you can register a project even if you are not upstream?
<seb128> I though the policy was to get upstream asking for it
<Kamion> pitti: uh, surely manual calls to pkgstriptranslations aren't necessary any more?
<carlos> mvo: it's yours now
<mvo> carlos: woah, thanks. I bow on your launchpad super-powers :P
<Kamion> pitti: a rebuild would've done fine, the problem was that the last build of diffutils was from before we did the buildd trick to do automatic pkgstriptranslations on everything
<carlos> seb128: yes, but we don't have a way to review those new projects and I don't think it's a bad thing to allow people to register it
<carlos> seb128: if upstream wants to use it we give them ownership (like I just did)
<seb128> fair enough
<seb128> thanks carlos :)
<Kamion> pitti: sorry it didn't occur to me to mention it when you were talking about it up above
<mvo> carlos: when I click on "translations" I get "administration help required"
<pitti> Kamion: oh, I remember, right
<pitti> Kamion: ok, I'll remove it again
<carlos> mvo: yeah, I need to fix the link
<carlos> mvo: create the series, and under overview
<carlos> you have a link to request new uploads
<carlos> upload there the .pot and any .po file that you already have
<carlos> and jordi will handle the import request next time he reviews the queue
<mvo> carlos: woooooohhhhhh THANKS
<pitti> Kamion: fixed (i. e. reverted), thanks for your phenomenal brain
<mvo> carlos: and uploaded!
<Kamion> pitti: heh
<carlos> mvo: I see them
* mvo hugs carlos 
<janimo> mvo, what fromat did you use?
<janimo> my upload of a tar.bz2 failed
<mvo> janimo: I have only 3 po files and a pot so far :)
<mvo> uploaded them idividually, but I think it can deal with tar.gz
<janimo> so no tarball?
<janimo> aha
<janimo> thanks
<carlos> janimo: really?
<janimo> it says it can deal with tar tar,.gz and tar.bz2 but failed on tar.bz2, let's try again
<carlos> I fixed that already
<janimo> carlos I did not get notification form LP I thiught it was not fixed
<carlos> janimo: could you give me an URL to the tarball and the URL where you try to upload it?
<janimo> carlos I made the tarball since upstream in in svn
<carlos> janimo: perhaps I forgot to close that bug as I fixed it as a side effect of another change....
<janimo> the project was thunar, tried 3 days ago and filed a bug in LP
<carlos> janimo: bug number?
<janimo> carlos, so fixes to LP are done daily?
<janimo> let me check
<carlos> janimo: no, seems like your tarball triggered another problem
<carlos> as my fix was applied two weeks ago
<carlos> janimo: are weekly unless critical/security bugs
<janimo> https://launchpad.net/products/launchpad/+bug/29604
<Ubugtu> malone bug 29604 in launchpad "Upload of bzip2-compressed PO file tarballs to Rosetta fails" [Normal,Unconfirmed]  
<carlos> mvo: could you tell me the path where you have the .pot file inside your tree?
<carlos> po/gdebi.pot ?
<mvo> yes
<carlos> mvo: ok
<carlos> janimo: ok, this is a different problem. I need to investigate a bit the error message
<carlos> janimo: in the mean time, could you upload a tar.gz?
<janimo> carlos, trying that just now
<carlos> thanks
<janimo> tar.gz worked
<carlos> cool
<Kamion> Kinnison: how out-of-date is staging meant to be?
<Kamion> Kinnison: it's lacking a kernel with the current ABI (-14)
<Kamion> Kinnison: (which hoses images)
<Kinnison> Kamion: erm, when was -14 uploaded?
<Kamion> Date: Wed, 25 Jan 2006 09:39:28 -0500
<Kamion> ^-- source upload
<Kamion> Date: Wed, 25 Jan 2006 09:39:28 -0500
<Kamion> er
<Kamion> -rw-rw-r--  1 katie katie 14066 Jan 25 17:35 queue/done/linux-source-2.6.15_2.6.15-14.19_i386.changes
<Kamion> think that was the binary upload
<Kamion> it required NEW processing, but I did that for the big three architectures on Wednesday evening
<carlos> mvo: is gdebi part of the APT project?
<mvo> carlos: no
<Kamion> Kinnison: unless you haven't synced the overrides for a while or something?
<carlos> mvo: but it's related to it
<mvo> carlos: well, it's based on python-apt. I think the person registering the project added it as releated
<carlos> just asking in case we should remove that link...
<carlos> mvo: anyway, I suppose you will change the descriptions / information as needed
<mvo> carlos: yeah, need to update/polish it a bit
<Kamion> Kinnison: espresso-grub's also missing, which I uploaded on Monday and was NEWed not long afterwards
<carlos> ok
<Kamion> Kinnison: and according to germinate output a bunch of packages that were removed from katie are still there in soyuz (e.g. mozilla-thunderbird-offline, x-window-system-dev, baseconfig-udeb)
<Kinnison> Yes, we haven't handled removals since xmas because gina can't
<Kamion> oh dear!
<Kinnison> We're compiling a list of things to test elmo's melanie implementation
<Kamion> ok
<Kamion> there's removals.txt on jackass which could just be fed to soyuz ...
<Kamion> admittedly it's a sucky format for machine-readability, but we already do that for debian->ubuntu
<Kamion> Kinnison: you can have the CD build log diff if you like; I Ctrl-Ced it at the end and there's lots of noise in it, but the germinate diff near the top should be useful
<Kamion> +W: GPG error: file: dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EFC2E3F9C1597003
<Kamion> Kinnison: new archive key?
<Kamion> -Version: 6.04
<Kamion> Kinnison: removing Version from the Release file may break people's existing pinning setups
<Kamion> -Architectures: i386 amd64 powerpc ia64 sparc hppa
<Kamion> +Architectures: amd64 sparc powerpc source i386 ia64 hppa
<Kamion> having source in there seems a bit odd
<Kamion> -Origin: Ubuntu
<Kamion> -Label: Ubuntu
<Kamion> +Origin: ubuntu
<Kamion> +Label: ubuntu
<Kamion> not sure if that'll break pinning - I *think* it's case-insensitive
<Kinnison> Kamion: yeah, there are various little tweaks for the Release files, I'll add those to my list
<Kinnison> the key is a test signing key
<Kamion> it would be *really* nice if the md5sum/sha1sum entries were sorted in some rational way
<Kinnison> I'll have to look into that, dunno how easy it'll be
* Kinnison is concentrating on end-to-end currently
<Kinnison> once I have the full chain going, I'll sit down and make sure I can fix as many of the Release tweaks as I can
<Kamion> Kinnison: there are *still* no debian-installer sums in Release
<Kamion> I thought I brought that one up at UBZ :(
<pitti> seb128, Riddell: can you help me with testing a new set of langpacks again? http://people.ubuntu.com/~pitti/langpacks/
<seb128> pitti: sure
<Kinnison> Kamion: there aren't? feck, I think I must have a branch somewhere unmerged, ta
<Kamion> Kinnison: (these things *are* being picked up by mdz's comparator, right?)
<Kinnison> yes
<Kinnison> but having an independant rant from you is handy
<Kinnison> makes sure we're seeing the right stuff :-)
<Kamion> Kinnison: http://people.ubuntu.com/~cjwatson/tmp/katie-soyuz-cd-build.diff
<Kamion> the stuff near the top will be the most useful
<mdz> Kamion: gina has been temporarily disabled while we're working here
<mdz> so we're expecting to be missing the past several days of uploads there
<Kamion> ok, unfortunately that makes CD build tests rather difficult since we'd have to wind back seed changes and retrieve older versions of the installer trees
<Kamion> I mean the basics of CD building seem to work, at least, it's just they're working with the wrong pieces :)
<Kinnison> Cool
<Kinnison> Kamion: thanks for this stuff
<Riddell> pitti_: language packs working good here
<pitti_> Riddell: here, too, thank you
<seb128> pitti: works fine for me too
<pitti> seb128: thanks
<hunger> Anyone else having problems with python-twisted upgrades?
<hunger> The debs install fine... but apt insists on reinstalling them over and over again with each upgrade done.
<psusi> I noticed that last night
<psusi> yea... synaptic installs them just fine, only they remain selected for upgrade
<psusi> really weird
<hunger> psusi: Great! I was already thinking I am going crazy:-)
<psusi> me too ;)
<hunger> psusi: Should we file a bugreport or nag pitti and co. here?;-)
<hunger> psusi: Well not pitti, doko did the last changes.
* hunger wonders whether this is a bug of apt or of python-twisted.
<pitti> Kamion: all dapper langpacks are now in the archive (with 6.04+2006... version), so the breezy ones are good to go
<segfault> humm, gnome-screensaver is not safe.
<ogra> segfault, ??
<segfault> when it locks the screen, one can press ALT+F2, and then type xterm, and then, enter.
<pitti> haha
<segfault> after that, you can run: killall -9 gnome-screensaver, and its gone.
<segfault> :)
<ogra> the same you can do with xscreensaver
<torkel> segfault: of course it is safe, the dialog does not get focus so you can't unlock it :-)
<segfault> xscreensaver doesn't let you press ALT+F2 i think
<ogra> there is no screensaver implementation you cant shut down from console
<segfault> (and call the run dialog)
<ogra> it does
<torkel> sure it does, but I think it kills the xsession if you kill it
<ogra> oh, alt-f2 ? 
<ogra> torkel, nope
<segfault> yes, alt+f2 and calls the run dialog in "background". can anyone try it?
<mdke> yes, apparently that is known and solved upstream
<ogra> and doesnt work here
<torkel> ogra: it doesn't? Then it was another screensaver...
<segfault> mdke: ah, didn't know that
<dholbach> segfault: next gnome-panel upload will fix that.
<ogra> torkel, there are only 3 locking screensaver impelmentations i know of ... 
<segfault> dholbach: great!
<ogra> torkel, either of them allows to switch to console
<ogra> all of them just unlock the screen if you kill the daemon
<segfault> i know one can still log from console and kill it, if he has root or sudo access, but this was weird.
<segfault> anyway, back to work. thanks!
<ogra> no need for root or sudo
<segfault> why not?
<segfault> how can user A kill user B screensaver?
<ogra> because you can log in as the logged in user and kill your own processes ;)
<ogra> nope, but user A on the console can kill user A's processes in X
<torkel> ogra: I'm pretty sure it was xscreensaver, but it was on RH and some years ago
<segfault> ahh, but that makes no sense, since you know the password, you can unlock it from the screensaver
<segfault> :D
<ogra> exactly 
<Riddell> Kamion: please promote libmimelib1c2a to main (rename of libmimelib1c2)
<segfault> but indeed, sometimes that situation saves my work, since i had some weird problems with screensavers
<Riddell> Kamion: also demote kuser to universe
<ogra> and if you are truested enough to be in the admin group and use sudo, you wont do it except for a good reason ;)
<Riddell> Kamion: and promote kviewshell to main again
<segfault> heh, sure
<tseng> ja
<tseng> ergh
<Kamion> pitti: all accepted
<Kamion> er, installed
<pitti> Kamion: thank you
<Kamion> Riddell: all done
<Riddell> Kamion: thanks
<ogra> yay, espresso ...!
* ogra gets some fresh coffee ...
<segfault> how's espresso going?
<ogra> got its first upload some mins ago
<Diziet> I like the bug 29760 where someone confirms the bug before I've uploaded the package version which causes the bug.
<Ubugtu> malone bug 29760 in flashplugin-nonfree "Sound does not work properly in Flash in firefox" [Normal,Confirmed]  http://launchpad.net/bugs/29760
<segfault> heh, nice
<Kamion> segfault: UI still extremely rough, number of features missing, but it does at least manage to install ... for me
<segfault> kamion: great. will it be available in today's livecd build?
<siretart> seb128: what are your plans about ekiga for dapper? do you have any?
<slomo_> siretart: dholbach wanted to do it this or next week
<siretart> slomo_: ah. okay
<Kamion> segfault: no
<seb128> siretart: dholbach is working on it atm
<dholbach> siretart, slomo_: i investigated in debian pkg-voip's packages, investigated in library updates, currently looking at rdepends and their rebuild-ability
<dholbach> siretart, slomo_: when i'm going to propose this to Kamion and mdz, i want to be sure to have the information together :)
<siretart> dholbach: bien sr
<dholbach> :-)
<dholbach> la mafia franaise :-)
<siretart> dholbach: so debian already has ekiga packages in their svn?
<ogra> pitti, ping
<ogra> pitti, unping, sorry
* pitti hugs ogra
<ogra> :)
<Kamion> This "Boot from first hard disk" option is the best thing I ever let somebody persuade me into adding. I never bother to take CDs out any more.
<Diziet> kamion: Excellent.
<Diziet> Does it do it by default ?
<mdke> Riddell, I added the packagingguide as target "package" to the Makefile in kubuntu-docs. Can you make the changes to debian/ to ensure that it gets installed? I don't know how. Thanks!
<Kamion> Diziet: no
<Kamion> it's prominently visible on the boot menu though
<Mithrandir> Kamion: yeah, it's bloody useful.
<LaserJock> Diziet: have you started work on the Ubuntu Developer's Reference?
<pitti> Kamion: nice to hear :)
<Riddell> mdke: in generic?
<LaserJock> Riddell: yeah, it's in generic
<Diziet> LaserJock: No.
<Diziet> (sorry)
<LaserJock> Diziet: np, I'm getting the Ubuntu Packaging Guide going a bit more and I was trying to get a feel for what the UDR would look like so I can minimize overlap
<LaserJock> Diziet: will it be more or less like the DDR?
<Diziet> LaserJock: Yes, I was going to make it as a big patch to the DDR.  But obviously it would have stuff in it about Ubuntu-specific things like MOTU.
<Diziet> I think the best thing would be for you to go ahead and if I like your content then I'll just cut-and-paste it and let you (or other UPG maintainers) know.
<LaserJock> Diziet: yes, that sounds good. I have GPLd (instead of the docteam's usual GFDL/CC-SA license so you can use the material withought licensing issues
<LaserJock> Diziet: sorry, that was a terrible sentence. The Packaging Guide is GPL so it will be compatible with the Debian docs and the UDR
<fabbione> NEWS FROM THE APACHE SPRINT: first external modules are running test suites
<Riddell> mjg59: is pmi used any more by gnome or is it all hal?
<mdz> fabbione: FILM AT 11
<Tm_T> hmm, where's xfonts-base-transcoded ?
<fabbione> mdz: php5 is GO, subversion is going as we speak
<mdz> fabbione: GO GO GADGET APACHE
<fabbione> mdz: ehhee
<fabbione> modperl is go too
<fabbione> (Mith claims so)
<Tm_T> this is interesting, there's no transcoded base fonts at all in dapper repository
<Diziet> Does anyone know anything about *gtk_icon_cache* ?
<Diziet> LaserJock: Thanks, that's great.
<fabbione> DVD9 PORN DOWNLOAD: success
<fabbione> apache2.2 is the future!
<LaserJock> Diziet: btw, the HTML version of the packaging guide is at doc.ubuntu.com and is updated from the docteam svn repo on a daily basis.
<ajmitch> morning
<seb128> Diziet: is that supposed to be a GTK API for you?
<Diziet> I'm debugging sabdfl's ff crash and it seems to be dying in _gtk_icon_cache_new_for_path.  That mmaps some file or other.
<Diziet> I'm wondering if it's possible that the cache file it's mmaping is corrupt and whether that might cause a segfault.
<seb128> oh
<seb128> the caches are to /usr/share/icons/<icon_theme>/icon-theme.cache
<Diziet> mmaps some file or other> looking at the source, gtk+2.0-2.8.10/build-tree/gtk+-2.8.10-static/gtk/gtkiconcache.c
<seb128> one cache by theme
<seb128> we don't use a cache for hicolor or gnome
<seb128> gnome == /usr/share/icons/gnome
<seb128> the cache is stupid
<Diziet> "we don't use a cache for hicolor or gnome"> I don't understand.
<seb128> the specs requires you update the mtime of the folder when installing an icon
<seb128> other way it just "mask" your icon
<seb128> so if you have a /usr/share/icons/gnome/icon-theme.cache
<seb128> and install an icon to /usr/share/icons/gnome/... without updating the mtime
<seb128> GTK reply the icon doesn't exist
<seb128> and some apps go buum
<Diziet> Uhh, but surely that wouldn't lead to a crash in the middle of the GTK function ?
<seb128> should not no
<seb128> it should crash on a function which expect an icon and get 0x0
<Diziet> Also, I'm not sure about this crash in particular, but sabdfl said it happened to him when he tried to `save link target as ...'.
<seb128> some apps doesn't handle the case their icon is not present
<Diziet> That's not what's happening here.  The stack frame for _gtk_icon_cache_new_for_path is still there.
<seb128> anyway we don't use the cache for those folders because it would require updating all the packages installing an icon, and break package not doing it
<Diziet> I should say `that's not what happened here'; I don't know if sabdfl's crashes are all the same.
<seb128> this is fine for themes because nothing else will install an icon to a theme folder
<Diziet> So you're saying this function shouldn't be mmapping anything ?
<seb128> yes, it should
<seb128> we do have caches for /usr/share/icons/*/
<Diziet> So is it possible that if the file was corrupt the program would crash ?
<seb128> * beeing all the themes out of gnome
<seb128> yep
<seb128> ask what theme he uses and make him move /usr/share/icons/<theme>/icon-theme.cache maybe
<Diziet> So I think I should tell sabdfl to tar up the cache and email it to me and to move it aside.
<Diziet> Right.
<Diziet> OK, thanks, that's helpful.  Good next step.
<j^> NetworkManager installes files in hicolor/22x22/apps/...
<seb128> np
<seb128> j^: like some hundred other packages, that's why we don't create a cache for hicolor
<j^> ah ok. just rememberd that i had a cach once,... 
<seb128> maybe some unofficial package bugged or something
<seb128> anyway, time for dinner, bbl
<Tm_T> hum, what's the mailing list to ask about font packages? or should I use launchpad?
<zyga> hello
<fabbione> night everybody
<ogra> ciao fabbione :)
<dholbach> Tm_T: if it's a bug, file a bug report :)
<Tm_T> dholbach: well, I think transcoded fonts should be shipped, like in hoary, but not in breezy nor dapper
<Tm_T> transcoded base fonts I mean
<dholbach> hmm
<Tm_T> yeah, no problem as long as you keep your system as utf-8
<Tm_T> but mine isn't
<Tm_T> dholbach: looks like I have those packages from hoary
<Tm_T> "Reinstallation of xfonts-100dpi-transcoded is not possible, it cannot be downloaded" ;(
* Tm_T is about to add hoary repos to his sources.list ;(
<mdke> Riddell, the doc is in generic, but i added it to the kubuntu/ Makefile
<dholbach> Tm_T: might be interesting to investigate the changelogs
<dholbach> Tm_T: there should be a rationale
<Tm_T> dholbach: chancelogs of what?
<dholbach> Tm_T: the package?
<Tm_T> dholbach: hm, you mean in hoary package? because no packages since hoary ;(
<siretart> dholbach: Tm_T is right. we currently don't ship those -transcoded packages anymore. :(
<Tm_T> yes, and that's flaw
<siretart> Tm_T: the problem gets even worse: the location of the font paths changed. so you have to move them around anyway
<AlinuxOS> pitti?
<siretart> Tm_T: for what do you need the transocded fonts?
<Tm_T> siretart: osd_cat
<siretart> osd_cat?
<Tm_T> yes, xosd app
<siretart> hmhm
<Tm_T> http://packages.ubuntu.com/dapper/x11/xosd-bin
<siretart> I know xosd. I'm using it
<siretart> I wasn't aware that it depends on transcoded fonts
<Tm_T> it does, if your locales are ISO-8859-15 ;(
<Tm_T> because now it doesn't find its default font
* Tm_T thinks we can't expect all using utf-8 locales
<siretart> Tm_T: the xfonts package seem to contain kinda pregenerated fonts
<siretart> Tm_T: I don't see an obvious way to add the -transcoded fonts to them
<siretart> Tm_T: filing a bug is a good idea in any case
<Burgwork> neuralis, http://sourceforge.net/projects/pootypedia/ <-- you looked at this?
<siretart> Tm_T: well, the obvious way would be to just grab the transcoded fonts as they are on my harddrive and stick them into a package
* Kamion glares at that debconf bug
<Kamion> missing signal_connect in the Gnome frontend
<Kamion> apparently Gtk2::Object in the perl gtk bindings has somehow managed not to have Glib::Object as its base class
<ogra> Kamion, there is a bug with recent gtk perl ...
<Kamion> yes, I'd gathered that
<Kamion> any actual diagnosis? :)
<ogra> seb pointed me to a bugurl, but i lost it, most gtkperl stuff is broken currently it seems
<Treenaks> bug-eyed earl?
<Kamion> the workaround suggested in #28719 doesn't work for me
<ogra> seb128, do you have the bugnr from the gtkprel bug ?
<Kamion> cjwatson@cittagazze:~/libgtk2-perl-1.102$ perl -MGlib -MGtk2 -le 'my $win = Gtk2::Window->new; print "yes" if $win->isa(Glib::Object)'
<ogra> *gtkperl
<Kamion> cjwatson@cittagazze:~/libgtk2-perl-1.102$
<Kamion> and putting 'use Glib;' in the debconf gnome frontend doesn't help either, so AFAICT that last comment is a red herring
<Kamion> I can't think of a plausible way that would make a difference to perl anyway
<jordi> mvo: DUDE
<seb128> ogra: I did spoke about a gtkperl bug?
<mvo> jordi: hu?
<seb128> ogra: maybe I read it just before you asked or something
<seb128> dunno about it
<jordi> mvo: nm me. I saw your conversation with carlos
<Kamion> I'll look at it myself, my XS-fu should be sufficient if dusty
<ogra> seb128, i asked about it some days ago, you pointed me to an upstream bug ...
<ogra> sadly i lost it
<seb128> ah
<seb128> Overview of changes in Glib 1.114
<seb128> =================================
<seb128> * Completely redo the way GObject types are mapped to package names.  This
<seb128>   fixes the problem uncovered by the recent GInitiallyUnowned issue.  See the
<seb128>   ChangeLog for a detailed description of the changes.
<seb128> 
<seb128> maybe
<seb128> that's a fix of gtk2-perl 2.13.5
<seb128> 
<seb128> Overview of Changes from GTK+ 2.8.9 to GTK+ 2.8.10
<seb128> ==================================================
<seb128> * Derive GtkObject from GInitiallyUnowned instead of
<seb128>   GObject, if possible. Note that this change is known
<seb128>   to break versions of the GTK+ Perl bindings older
<seb128>   than GTK+ Perl 2.13.4.
<seb128> 
<Kamion> ah, yes, that sounds plausible
<ogra> yes, that was it
<seb128> that's what I know on the topic
<Kamion> ok, so we just need newer bindings then
<seb128> correct
<Kamion> thanks
<siretart> Kamion: if you upload xorg the next time, care to fix malone #29483?
<Ubugtu> malone bug 29483 in xorg "x11-common must depend on laptop-detect" [Normal,Unconfirmed]  http://launchpad.net/bugs/29483
<Kamion> siretart: no great plans to do so, I was fixing an installation failure
<Kamion> and as I said in the bug, that description is wrong
<Kamion> in fact, x11-common *already* depends on laptop-detect
<siretart> I beg your pardon
<Kamion> I don't see the problem though, looks like it degrades gracefully-ish
<Kamion> albeit to thinking it's a desktop
<siretart> well, it produces noise in the buildd logs
<siretart> as well as in my chroot
<siretart> but you're right, it is quite low priority
<mjg59> Riddell: It's currently still called by gdm, though probably shouldn't be
<ogra> mjg59, using hal from gdm ? #
<ogra> that sounds evil
<mjg59> ogra: Why not?
<ogra> gdm runs as root ? 
<mjg59> Yes
<ogra> if you have security holes there you could abuse hal ... ?
* mjg59 goes to sabdfl's keynote
<mdz> mjg59: heckle him once for me
<Kamion> grr, I think Debian hasn't noticed the libgtk2-perl thing 'cos it only happens if you build libgtk2-perl with the newer libgtk2.0-0
<Kamion> evil lurking bugs
<simira> who can I blame for my gweather applet not working? It crashes when I try to put it on the Gnome -panel
<Riddell> mjg59: so what uses hal?
<ogra> simira, its starts with a g ....
<ogra> simira, must be a seb128 package then :P
<simira> :)
<ogra> Riddell, the powermanager calls hal who directly accesses pmi
<ulaas> cdrom   floppy   floppy1  floppy3  floppy5  floppy7  sda2
<ulaas> cdrom0  floppy0  floppy2  floppy4  floppy6  sda1
<ulaas> flight 3
<ulaas> known issue?
<Riddell> ogra: powermanager is a panel applet?
<ogra> a notification area applet
<ogra> using gconf for settings ... 
<ogra> would be some work to reimplement it in QT i guess
<ogra> in fact its a daemon a config tool and the applet
<ogra> tied up with gnome-screensaver for dpms 
<Kamion> ulaas: I've got a bug about it at least, haven't investigated yet
<Kamion> I'm assuming it's probably a udev bug
<ulaas> Kamion, ping me if you need info.
<Kamion> ulaas: feel free to subscribe to malone bug #27926
<Ubugtu> malone bug 27926 in partman "fstab  contains 8 floppy drives but PC does not have any" [Minor,Confirmed]  http://launchpad.net/bugs/27926
<ulaas> slomo_, ping
<Tm_T> siretart: ok, I'll file a bug?
<siretart> Tm_T: yes. or even better, provide a package ;)
<ulaas> Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory
<ulaas> i get this when i try to launch monodevelop
<ulaas> is this monodevelop or firefox?
<ulaas> and should i file it?
<torkel> ulaas: works for me. Do you have the latest versions of monodev and firefox installed?
<ulaas> torkel, lemme check.
<ulaas> torkel, monodevelop 0.9-1ubuntu1 firefox 1.5.dfsg-4ubuntu5
<torkel> ulaas: works for me with those versions.
<torkel> ulaas: on the other hand, I have mozilla installed too...
<ulaas> torkel, hmm. lemme try mozilla as well. i have a feeling that it wil work
<ulaas> slomo_, ping
<torkel> ulaas: you need mozilla for it to work. I.e file a bug against monodevelop that it probaly needs it's depends checked
<ulaas> sure
<torkel> and/or it have to be updated to work with firefox
<Tm_T> siretart: provide a package.. huh, that would be "later" 'cause haven't done those ever
<Tm_T> should learn though
<Tm_T> siretart: so basically, I just take hoary package and do necessary changes and that's about it?
<Tm_T> siretart: or, from debian and change it
<Tm_T> ...and ofcourse packages.debian.org is down
<crimsun> use packages.qa.debian.org
<Tm_T> ah, ty
<rob> hi, does anyone know who is looking after gnome-app-install? I emailed Ross Burton but he said its not him anymore, and that it undergoing a rewrite
<Burgwork> rob, mvo handles it
<rob> ok thanks Burgwork, do you know how I can contact him?
<Burgwork> rob, right here
<rob> heh true that
<rob> ping mvo?
<mvo> hello rob
<rob> hi mvo, I was just wondering what the current status of gai is
<rob> I emailed Ross, but yeah
<rob> is there a repository somewhere where I can take a look at the latest code?
<mvo> rob: sure, I'm happy about your interesst
<rob> he mentioned it was undergoing a rewrite
<mvo> rob: not exactly a rewrite, but a big refactor, the current tree that is in dapper is at http://people.ubuntu.com/~mvo/bzr/gai--main/
<mjg59> ogra: If it's running as root and you gain any control over it, you've lost already
<mvo> it has the current treeview design
<mvo> the new look is at http://people.ubuntu.com/~mvo/bzr/gai--new-look/
<mvo> I hope to get it into dapper, i like it better than the "old" look
<mvo> rob: http://people.ubuntu.com/~mvo/gnome-app-install/new-look/gai--new-look.png
<ogra> mjg59, hmm, true ...
<rob> mvo, yes so do I, actually I was going to suggest an "unsupported packages" feature :)
<rob> and spliting the layout like that makes it much clearer
<rob> will you accept patches on gai--new-look?
<mvo> rob: sure, happy to merge from your bzr branch!
<mvo> rob: it should work reasonable well already, but there are some smaller bugs I think
<rob> ok, I'll have to get it set up, this is the first time I've looked at the new code
<mvo> happy to help you with the code or any other questions
<rob> thanks, sounds good
<mvo> to build a package just run debian/rules arch-build
<rob> ok
<rob> I gotta go put my daughter to sleep, thanks I'll take a look and get back to you soon
#ubuntu-devel 2006-02-02
<dholbach> good night guys
<slomo_> ulaas: pong
<ulaas> slomo_, hi. do you have a finger on monodevelop?
<slomo_> ulaas: partially, yes... why?
<ulaas> Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory
<ulaas> if you dont install mozilla
<ulaas> firefox should be enough i presume.
<slomo_> yes, the current sourcepackage already has the correct change for firefox
<slomo_> but it ftbfs because of mono 1.1.13 :/
<ulaas> slomo_, oki.
<slomo_> if you're interested you can provide a patch to fix the build... shouldn't be too hard but i don't have the time currently... but it's on my todo list ;)
<ulaas> you should see my todo list :)
* mvo goes to bed
<kagou> hi
<localuser> There seems to be a bug, unless it is intentional
<localuser> if you first install the server version of ubuntu
<localuser> then do all updates, etc
<localuser> then try to install ubuntu-desktop
<localuser> you will not get the nice splash bootup screen
<localuser> is this on purpose???!?!?!?
<ogra> yes#
<localuser> yes, that is intentional?
<ogra> the server has no usplash installed 
<localuser> ogra, then how can i install it?
<localuser> i know, but i insdtalled ubuntu-desktop package on top of server
<AlinuxOS> hello :)
<localuser> what is the package, and how to setup if i initially did a server install /
<AlinuxOS> alive ubuntu gurus ?
<AlinuxOS> :)
<localuser> ogra, :-(
<ogra> yes, but you didnt recreated the initramfs after you installed usplash 
<localuser> ogra, ok then is there some auto procedure to do this?
<ogra> sudo dpkg-reconfigure linux-imgae-`uname -r`
<ogra> *image
<localuser> ogra, nice!!!!
<localuser> ogra, you fscking rule...
<AlinuxOS> http://alinuxos.no-ip.org/ubuntu-geo.png :)
<localuser> ogra, ok thanks man -- one other kernel bug though -- i see message like "base(0xf0000000) not aligned on a size(0x80000000)" when loggin in with GDM
<localuser> but logging in with KDM works fine
<ogra> hmm, no idea
<localuser> that is in /var/log/messages -- googled around and supposed to be fixed in 2.6.6 -- yet i see it
<localuser> ill file upstream...
<BenC> anyone here have 1Gig of ram on x86 and want to test a kernel for me?
<Tm_T> I do have
<Tm_T> not sure if I like to test ;)
<BenC> are you running dapper?
<Tm_T> sure
<BenC> it's going to just be linux-image-2.6.15-14 + one patch
<BenC> no danger of data loss
<BenC> are you running 386, 686 or k7 variant?
<Tm_T> k7
<BenC> ok, can you give me 10 minutes to compile it?
<Tm_T> BenC: "no danger of data loss" you mean I'm losing all my porn.. eeh, document movies?!
<Tm_T> BenC: sure
<BenC> hehe
<BenC> great, thanks
* desrt cooks benc's todo list
<Tm_T> BenC: aye, slap me when you're ready (so I know to get off from you)
<BenC> ok
* Tm_T needs caffeine/sleep
* lamont-away dist-upgrades an ia64 box to dapper
<Tm_T> BenC: 10 your minutes... ;)
<ogra> BenC, btw, i think you broke the snd_powermac module in -14, cat /dev/sndstat only shows the timer, even if all mods are loaded
<BenC> Tm_T: it's almost done
<BenC> ogra: Fixed already
<Tm_T> BenC: jolly good indeed :)
<ogra> oh, great :)
<ogra> youre to fast
<BenC> actually, I break things intentionally, and have the fixed real fast so it looks like I'm doing real work
<BenC> by dapper release I'll have reverted all my subtle breakage
<ogra> lol
<Tm_T> hehe
<BenC> Tm_T: http://people.ubuntu.com/~bcollins/kernels/test-nohighmem-1g/
<Tm_T> BenC: downloading ty
<BenC> let me know when you've had a chance to boot it and we can see if it worked (other than not failing to boot)
<Tm_T> hehe
<Tm_T> I'll boot as soon it's installed
<BenC> are you on the machine you are testing?
<Tm_T> yes
<BenC> ok, I'll just wait for your reconnect cycle then :)
<Tm_T> hmm, no, this irssi is not running on my pc ;)
<BenC> ah, ok
<Tm_T> but I'll inform you as soon as possible
<Tm_T> installing
<Tm_T> BenC: ok, now rebooting, see you in the other side (or not) ;)
<Tm_T> BenC: alo
<BenC> booted ok?
<Tm_T> xorg failed to get itself up
<Tm_T> otherwise yes
<BenC> are you still booted with it?
<Tm_T> yes
<Tm_T> what you wan't me to check?
<BenC> if so, can you do "dmesg | mail -s highmem-dmesg bcollins@ubuntu.com" ?
<MrRio> there's a typo in synaptic for dapper, "Oficially supported" should read "Officially Supported"
<Burgwork> MrRio, please report a bug
<MrRio> im just checking to make sure it isnt already there now
<Tm_T> BenC: done
<Tm_T> BenC: anything else?
<BenC> thanks!
<Tm_T> np :)
<BenC>  /var/log/Xorg.0.log would be nice too
<Tm_T> any ideas why eth0 need manual ifdown & ifup after boot?
<BenC> other than that, no
<Burgwork> MrRio, better to file more bugs than less
<BenC> hmm, no idea about that either
<Tm_T> BenC: aye, I'll cat xorg log
<MrRio> Burgwork: yeah, true
<BenC> Tm_T: you've been a bug help, thanks. Saved me from having to bug 2x512Meg dimms to test this myself :)
<BenC> s/bug/big/
<Tm_T> bug help indeed ;)
<Tm_T> BenC: ok, network issue is like this, in boot, about in first ten lines, comes error message saying something about ifup's postfix and readonly filesystem
<BenC> ah, that's an initscript issue
<BenC> not kernel related
<lamont__> Tm_T: and fixed in 2.2.8-8
<Tm_T> manual ifdown eth0 && ifup eth0 brings eth0 alive
<Tm_T> lamont__: hmm, ok I'll check updates (did it ~100 times today, as usual)
<Tm_T> thanks :)
<LaserJock> doko: ping?
<Tm_T> lamont__: 2.2.8-8 of what package?
<MrRio> i think the new update bubble is too 'jaggy'
<Tm_T> aah postfix
<MrRio> can i put that in as a bug
<Tm_T> lamont__: ah I see, 2.2.8-6 here, looks like slow mirrors or something
<MrRio> It looks ok-ish i guess, but much worse because it doesnt blend into its background and has horrible jaggy edges
* Tm_T doesn't use gnome for some reason(s) ;(
<Burgwork> MrRio, already being fixed by the upstream developers
<MrRio> Burgwork: great, where can I find the patch for that?
<Burgwork> MrRio, wait
<Burgwork> umm, wait, it should already be in dapper
<Tm_T> aye, that's what I heard
<Tm_T> BenC: ok, what I do now? uninstall that "new" kernel and install old back or wait fixes?
<BenC> apt-get --reinstall install linux-image-2.6.15-14-k7
<Tm_T> hmm, that does downgrade?
<BenC> well, it's the same package name as the current dapper, so it just replaces
<Tm_T> I rarely downgrade things, I'll try
<lamont__> Tm_T: actually, I need to request the sync from debian...
<Tm_T> lamont__: ok :)
<Tm_T> good to know it's fixed anyway ;)
<Tm_T> BenC: hehe, complains about "cannot be downloaded"
<lamont__> Tm_T: let me guess.. /usr is on a diff partition than /?
<MrRio> being proper dumb here, but if i was going to make a patch to synaptic, which cvs would i use? or would i do it against the latest source package from https://launchpad.net/distros/ubuntu/dapper/+source/synaptic
<Tm_T> lamont__: nope, but that package that benc gave has different (higher version)name than what is in repository
<MrRio> it needs to be fixed here and not upstream because its a ubuntu specific typo
<Tm_T> so I did manual downgrade (dpkg -i /var/cache...)
<Tm_T> BenC: ok, rebooting, I'll let you know how this goes (haven't booted yet to repo -14 kernel)
<Amaranth> MrRio: If you're making the patch for ubuntu's synaptic I'd guess the source package is best.
<BenC> Tm_T: I still have't gotten your emails
<Tm_T> BenC: sounds bad
<MrRio> night
<Tm_T> BenC: let me guess, no way to look if it's sent or not
<BenC> Tm_T: look in /var/spool/exim4/ or whatever it is
<Tm_T> ok
<Tm_T> BenC: not existing anyexim ;(
<Tm_T> humm, sounds bad
<BenC> Tm_T: the mail program had to put it somewhere
<BenC> Tm_T: check for dead.letter or something
<BenC> you should be able to grab /var/log/kern.log and /var/log/Xorg.0.log still (Xorg.1.conf might have moved to Xorg.1.log or something)
<BenC> Tm_T: grep highmem /var/log/kern.log if you could
<Fitzsimmons> hello.
<LaserJock> hi
<Fitzsimmons> I did a dist-upgrade to dapper and I might be interested in squashing bugs, but ignore me for a while, as I figure out whether it is an ubuntu problem or a gnome problem :)
<LaserJock> Fitzsimmons: have you tried looking on Malone?
<Fitzsimmons> LaserJock: I have
<Fitzsimmons> LaserJock: I haven't checked upstream yet, but I did a CVS build of gnome-panel (which is what I'm having issues with) and it seems to be having the same behaivour
<Fitzsimmons> I'm going to drop back to a 2.12 verison and see what it is like
<LaserJock> so did you check at bugzilla.gnome.org?
<Fitzsimmons> that's what I meant when I said I hadn't checked upstream
<LaserJock> ah
<Fitzsimmons> doesn't appear to be anything on first sight though
<Fitzsimmons> haha different problem just as useless
<Fitzsimmons> I'll investigate this tomorrow
<Tm_T> argh
<Tm_T> packages python-twisted python2.4-twisted doesn't install properly
<LaserJock> how so?
<Tm_T> every time I run apt-get update && apt-get upgrade (as root) it tries upgrade those two... with same package
<Tm_T> shortly counted have done it now... 56 times
<LaserJock> did you have a local install of the packages?
<Tm_T> afaik no
<Tm_T> I even tried uninstall and reinstall, no help
<LaserJock> that's weird
<Tm_T> you tell me! :)
<Tm_T> nothing but annoying (have to press "n" many many times per hour)
<LaserJock> I'll install them and see if I get it too
<LaserJock> Tm_T: yeah, I got it too
<Tm_T> thanks
<LaserJock> what in the world
<Tm_T> now if I just know why pypanel doesn't work
<LaserJock> it doesn't?
<Tm_T> LaserJock: you doesn't happen to be python wizard?
<Tm_T> nope
<LaserJock> my pypanel works, and no, I'm not a wizard. I know enough to get by in my work
<Tm_T> http://kubuntu.pastebin.com/526878
<Tm_T> both with ubuntu package and from sources
<Tm_T> if you have _any_ idea how to fix it, please tell
<LaserJock> hmm, I'm running it right now and it's ok
<Tm_T> phuuh :(
<LaserJock> do you have the stock .pypanelrc ?
<Tm_T> yes
<Tm_T> afaik
<Tm_T> I can remove it for test
<LaserJock> you might try that
<Tm_T> doesn't help
<LaserJock> It look like the problem is with python-xlib, what version do you have?
<Tm_T> python-xlib/unknown uptodate 0.12-5
<LaserJock> dude, I just don't know :(
<floam> BenC: hey, remember me? I was the guy complaining about the broken ATAPI stuff
<floam> BenC: just now I built my own 2.6.16-rc1-mm3 and the drive magically works
<floam> I'm very happy you're suspicions of the drive being busted aren't correct :)
<floam> your
<BenC> what driver is it working with?
<BenC> floam: is it sata_promise?
<floam> BenC: sata_via
<floam> oh, you're gone
<floam> darn
<zakame> ls
<simira> hjelp
<simira> all teksten er borte...
<simira> #wrong
<dholbach> hello!
<mpt> hi dholbach 
<dholbach> hellas mpt
<Tm_T> LaserJock_away: ping
<ajmitch> evening mpt_ 
<stockholm> ogra: ping
<siretart> wow. how can the kernel interfere with WOL ability?
<siretart> wol used to work during hoary, not in breezy, but again with current dapper. I thought it was a hardware/local config problem, though..
<dholbach> hey jinty
<jinty> hey dholbach
<jinty> hows it going over there?
<dholbach> jinty: how is it going? are you in spain already?
<dholbach> :-)
<dholbach> nicely, thanks :-)
<jinty> here raining:(
<jinty> but tomorrow /me -> South africa
<dholbach> Mr. Jetsetter :-)
<jinty> visit the floks and all
<dholbach> -6C in Trier, gorgeous blue sky, sun shining :)
<jinty> folks
<jinty> here raining, cold, and we dont have any heating
<dholbach> GAR! :/
<jinty> or windows that actually close
<jinty> cold ~5degC
<dholbach> did you have any time off?
<jinty> not yet, there was a bit of an emergency with the schooltool server and work to finish before I leave
<jinty> so I guess I work today/tomorrow
<jinty> and you? why not outside enjoying the sun?
<dholbach> jinty: need to work today - I'll look into the gnome 2.13.90 tarballs and package some a11y related software, i guess :)
<jinty> good luck with that
<dholbach> Thanks. :-)
<mvo> hi glatzor 
<glatzor> hi mvo
<glatzor> No weekend for you? :)
<mvo> glatzor: we ubuntu guys never sleep
<mvo> :P
<ajmitch> mvo: we don't?
<glatzor> My alert box module is nearly finished
<mvo> ajmitch: shhhh, don't give away your secret
<mvo> glatzor: great to hear!
<glatzor> but there is a problem with file bug report issue:
<Mithrandir> mvo: apt breaks fairly hard if you have too many conffiles in a package.
<glatzor> https://launchpad.net/products/gdebi/+filebug
<Mithrandir> mvo: fails to parse the dpkg status file.
<glatzor> if you are not logged in you the showed web page of malone does not give very much information to the user
<mvo> Mithrandir: we talk about that a while ago, it does for any tag that is too big. can I see your conflicts line somewhere?
<fabbione> mvo: apt-get sucks :)
<mvo> glatzor: right
<mvo> fabbione: I found that out the hard way :P
<fabbione> mvo: i have a nice bug for you to fix at the spring
<fabbione> sprint
<stockholm> is mdz on on weekends?
<mvo> fabbione: is it reported already? or a new one?
<fabbione> mvo: no idea.. basically installing a package with tons of /etc/apache2/.svn files makes apt-get update cry out loud
<fabbione> and the dpkg status file becomes somehow corrupted
<mvo> then don't do that :P
<fabbione> without the .svn is ok
<mvo> but sure, I will have a look
<fabbione> i am not doing it, but it is still a bug :)
<fabbione> i will show it to you
<fabbione> we have a simple test case here
<Mithrandir> mvo: not conflicts.   conffiles.  even apt-cache refuses to work.
<Mithrandir> mvo: I also think we managed to confuse it when a package conflicted with itself through a semi-virtual package, or something, but I'd have to track that down further
<mvo> Mithrandir: is the package that breaks apt available somewhere? so that I can have a look?
<Mithrandir> mvo: uhm, no, not really.  But I could make you one
<mvo> Mithrandir: that would be nice (but can wait for the sprint)
<Mithrandir> yup
<mvo> Mithrandir: I need to start packing for tomorrow I guess
<mvo> just got a report that after a dist-upgrade to dapper, the system dosn't boot anymore with: ALERT: /dev/hda8 does not exist. Dropping to a shell
<fabbione> i blame udev/initramfs
<pitti> hey fabbione 
<fabbione> hey pitti
<fabbione> slomo, siretart: ping?
<siretart> fabbione: pong
<siretart> fabbione: sorry, joerg is quite busy these days re: igor :(
<slomo> fabbione: pong
<fabbione> guys, please fix xine-lib FTBFS on sparc
<fabbione> it didn't build for quite sometime and some stuff now build-dep on it
<siretart> fabbione: can you provide us access to a sparc machine?
<fabbione> siretart: not to mine.. sorry.
<siretart> ok. I'll bug joerg again
<fabbione> clearly the failure has been introduced to one of the changes you did
<fabbione> so if you can try to spot it and give me test pkgs, i can test build them
<fabbione> i just don't have the time to reconstruct the lib history to see what you have done to it
<slomo> most probably caused by the update to 1.1.0 from 1.0.1
<fabbione> slomo: did you check if it did build in debian?
<fabbione> for sparc i mean
<fabbione> to cross check if it is an ubuntu change or just upstream
<fabbione> or perhpaps debian has a patch?
<siretart> fabbione: siggi (the debian maintainer) is going to upload 1.1.1 soon. I'm interested if that's gonna build in debian/sparc
<fabbione> siretart: are you aware of UVF?
<fabbione> xine-lib is in main
<siretart> fabbione: I am aware. but I think the changes from 1.0.1 to 1.1.0 are bigger than 1.1.0 (which we currently have) to 1.1.1
<siretart> fabbione: so this would indicate a regression upstream
<fabbione> 1.0.1-1.6 (sparc) (latest build at Jan 11 22:25: maybe-successful)
<fabbione> no
<siretart> oh
<siretart> then I confused something. sorry
<fabbione> debian doesn't have 1.1.0
<siretart> fabbione: not yet. it is still sitting in cvs :/
<fabbione> ok
<fabbione> siretart: let's get igor back asap
<slomo> fabbione, siretart: we have 1.1.1 in dapper
<siretart> slomo: oh. that was my confusion.
<fabbione> meh
<fabbione> hmmm
<fabbione> slomo, siretart: ok, first strange thing is the mad plugin is still there somehow
<fabbione> at least configure enables the local one
<fabbione> and according to your changelog it should be disabled
<fabbione> IPv6 is disabled
* fabbione sighs
<fabbione> hecking for mad... checking mad.h usability... no
<fabbione> checking mad.h presence... no
<fabbione> checking for mad.h... no
<fabbione> *** no usable version of libmad found, using internal copy ***
<fabbione> ^^^
<fabbione> slomo: 
<slomo> fabbione: xine-lib has no support for mad anymore... and no internal version of mad is in the sources so don't worry
<fabbione> ok
<fabbione> doko: ping?
<fabbione> doko: what was the gcc option to keep the generate .s around?
<slomo> fabbione: i was just too lazy to remove the check from configure.in
<fabbione> slomo: ok
<fabbione> slomo: btw... i think the problem with xine-lib goes a bit more down than just xine code
<fabbione> i need to understand if actually gcc is doing the right think
<mdke> anyone else having trouble with ifup/down lately?
<mdke> I can't ifup any interfaces, and lo is down too
<Mithrandir> yes, it's being silly and thinks the interface is up when the dhcp client fails.
<mdke> /etc/network/interfaces:29: interface eth1 declared allow-auto twice
<mdke> ifup: couldn't read interfaces file "/etc/network/interfaces"
<fabbione> mdke: yeah i saw that too
<mdke> Mithrandir, ok, is there a bug open do you know?
* mdke looks
<fabbione> mdke: if by monday you will not see Keybuk online anymore, there might be the option that somebody did use a slightly too big reminder
<Mithrandir> mdke: not that I know of.
<mdke> fabbione, i guess if everyone is seeing it, it'll get fixed without a bug report :)
<fabbione> mdke: well i did see it once... fixed it and so on..
<mdke> there are quite a few bugs open i think
<siretart> mdke: the fix was to remove the redundand 'auto' line from /etc/network/interfaces. at least for me
<mdke> siretart, was your "lo" down too?
<doko> fabbione: -save-temps
<siretart> mdke: yes
<fabbione> doko: there was also a verbose asm output.. that adds comments to each asm line to the respective C line of code..
<fabbione> doko: do you remember that one too?
<doko> no
<doko> fabbione: maybe -fverbose-asm ?
<mdke> siretart, ah I see the second one, it was way down. Thanks :) It's bug 29654, amongst others i think
<Ubugtu> malone bug 29654 in ifupdown "auto eth1 duplicated in /etc/network/interfaces by upgrade" [Major,In progress]  http://launchpad.net/bugs/29654
* fabbione shurgs
<fabbione> slomo: i think i know what is wrong with xine-lib and i know who to beg for a fix :)
<fabbione> slomo: case wants that the same author of that code is the main sparc kernel developer :)
<siretart> fabbione: wow :)
<ulaas> hi. glx issues with nvidia. (incredibly slow) k7 kernel. any ideas?
<Treenaks> ulaas: yes, ask on #ubuntu
<Treenaks> :)
<Treenaks> That's the support channel
<ulaas> sure but i am on dapper and i want to help
<ulaas> i am not asking for help. i want to report to people interested ;)
<Mithrandir> hmm, which is the set of kerberos libraries we ended up with?  Heimdal or kerberos?
<torkel> MIT I think
<mdke> ulaas, if no one responds, don't forget to file a bug
<ulaas> mdke, you read my mind ;)
<fabbione> doko: somehow gcc-4 is generating bad asm on sparc for xine-lib
<fabbione> doko: {standard input}:218: Error: Illegal operands: There are only 32 f registers; [0-31] 
<fabbione> looking at that line:
<fabbione>         ldd     [%g1] , %f40     ! ref
<fabbione> probably it's only a missing option calling gcc?
<fabbione> ohhh hmm
<fabbione> siretart: ayeeeee.. it seems to be a gcc bug, or  a missing CFLAG in libmpeg2. I am testing a workaround, but we want the proper fix
<ulaas> i used to see my mounts in nautilus (cvs) and places. i had a fresh flight 3 install. i dont have them any more...
<ulaas> cvs/vfs
<seb128> file a bug
<seb128> include what version you use, what computer does list, what fstab has, what mount returns etc
<seb128> computer=computer:///
<ulaas> seb128, should i file it under nautilus or gnome-vfs?
<seb128> gnome-vfs
<seb128> but to be honest I doubt that's a GNOME bug
<seb128> maybe hal
<seb128> or maybe not a bug
<seb128> does "gnomevfs-ls computer:///" list them?
<ulaas> seb128, thats why i wanted to ask first. lemme investigate more first. if no info i will file a bug.
<seb128> ulaas: ?
<smurf> doko_: ping
<ulaas> seb128, sorry i got a call. no results. only cdrom filesystem and floppy.
<doko_> smurf: pong
<smurf> doko twisted2.4-conch depends on twisted, not twisted-core. Intentional?
<seb128> ulaas: what kind of drive is mounted and not listed?
<doko_> fabbione: works with 3.4 or 4.1? isntall gcj-4.1 for the latter
<doko_> smurf: there should be an update for twisted-conch
<ulaas> seb128, i ve mounted an ntfs partition and a vfat. 
<Kinnison> Kamion: ping?
<seb128> ulaas: are they listed by fstab?
<smurf> doko_: meaning I'll have to wait a few hours?
<ulaas> seb128, i ve mounted them manually.
<ulaas> seb128, yes in fstab
<seb128> are they listed by /etc/mtab?
<Kinnison> FYI you guys, the soyuz deployment tests are going very well
<ulaas> seb128, they are 
<ulaas> /dev/sda1 /media/sda1 ntfs rw,nls=utf8,uid=1000 0 0
<ulaas> /dev/sda2 /media/sda2 vfat rw,iocharset=utf8,uid=1000 0 0
<seb128> does that make a different if you mount them to /mnt instead of /media ?
<seb128> Kinnison: nice
<ulaas> seb128, no
<seb128> ulaas: does "killall gnome-vfs-daemon" change something? is hal running?
<ulaas> seb128, i guess hal is ok. (device manager is running). killall just respawns :) nothing good happens.
<seb128> ulaas: does setting /system/storage/display_internal_hard_drives with gconf-editor (and restarting gnome-vfs-daemon again) fixes the issue?
<ulaas> seb128, display_scsi_drives fixed it. (as it is a sata disk). however i have this strange volume name with one the drives "ILO%16%06%3FN%3FC"
<seb128> ulaas: lshal | grep ILO ?
<ulaas>  volume.policy.desired_mount_point = 'ILO?N?C'  (string)
<ulaas>   info.product = 'ILO?N?C'  (string)
<ulaas>   volume.label = 'ILO?N?C'  (string)
<ulaas> should i check the label?
<seb128> yep
<seb128> so you have 2 bugs
<seb128> one beeing the default setting of the gconf keys
<seb128> feel free to bug on gnome-vfs2 package for that
<ulaas> oki.
<seb128> and the second is either an HAL issue or NOTABUG
<seb128> if that's the label of you device, that's NOTABUG
<ulaas> i llet you know. normally i dont set labels for my drives. but lll make sure
<ulaas> seb128, hmm some good info. i dont have a label. but even sudo tune2fs -L FAT32 /dev/sda2 i cannot label my drive. i can do it to /dev/hdc1 (PATA) with no problems.
<ulaas> that looks like we have also may have an issue from sata_nv module to deep kernel stuff.
<ulaas> seb128, arghh i got Ooops while selecting the package. hehe filed a bug for the oops. i have filed a bug for a bug. thats cool
<seb128> :)
<Kamion> Kinnison: yes? (only here briefly)
<simira> Kamion: are you anywhere near Tollef?
<Kinnison> Kamion: I was just gonna say that a d-i end-to-end was working
<Kinnison> Kamion: I.E. I uploaded a source to staging, it was accepted, built, binaries accepted, and the raw-installer unpacked correctly
<Kamion> simira: no, I'm at home
<Kamion> Kinnison: cool
<Kinnison> Kamion: currently having a couple of NEW related hiccoughs on other packages, probably to do with being out of sync
<Kinnison> Kamion: other than that, things are really looking good
<siretart> are we there yet? ;)
* Kinnison inverts siretart (inside out)
* Treenaks hands Kinnison the controls to the Digital Conveyor
<siretart> waaah
<Kinnison> Treenaks: Use of the conveyer has always been more of an art than a science
<Treenaks> It has never been tested .. succesfully
<Kinnison> gorignak
<Kinnison> gorignak
<lamont__> Kinnison: but what does a rock _want_?
* Kinnison giggles
<Kinnison> ...maybe you're the plucky comic relief?
<lamont__> what is its motivation?
* lamont__ doesn't want to be the plucky comic relief...
* lamont__ considers daniels for the job of chief engineer.
* lamont__ looks around for someone with a dapper box willing to compile and test something for him
* lamont__ should really build a dapper box.
<Kinnison> lamont__: you could upload it to drescher as a test :-) (but it would bugger up our tests :-)
<lamont__> lol
<lamont__> Kinnison: nm - still fixing a bug sihg.
<simira>  nh
<ogra> nh ?
<siretart> n!
<lamont__> ah, the subtle pronunciation guides...
<siretart> :)
<ogra> hmm, has anybody worked with openssi here =#
<ogra> ?
<Fitzsimmons> the topic mentions that if your initramfs is broken that "infinity" wants a copy.  I think mine is broken.
<Fitzsimmons> what's the next step?
<hunger> Fitzsimmons: Send it to infinity:-)
<Mithrandir> Fitzsimmons: put it somewhere and tell adconrad@ubuntu.com or file a bug and assign it to adconrad@ubuntu.com
<hunger> Fitzsimmons: I think the best way to do that is to open a bugreport and assigning it to adam conrad.
<Fitzsimmons> I want to confirm that we're talking about the same thing - it is the cause of the bootsplash corruption?
<hunger> Any idea why apt keeps updating python-twisted for ever and ever?
<Fitzsimmons> heh, I did a dist-upgrade and apt is convinced that it needs to continually update tons of stuff
<hunger> Fitzsimmons: Even stuff that is installed fine at the version apt installs?
<hunger> psusi had the same problem before (with python-twisted just like I do). I have no idea what to write a bugreport for:-)
<Fitzsimmons> to be honest I need to keep my mouth shut before I start saying things - the pile of stuff itw ants to update is different than it was before =/
<hunger> Fitzsimmons: Hey, I do not mind that;-)
<Fitzsimmons> good :D
<Fitzsimmons> I think I'll need to go upstream with this gnome-panel problem
<hunger> Fitzsimmons: apt-get update && apt-get upgrade && apt-get upgrade installing python-twisted twice is really wierd IMHO.
<hunger> Fitzsimmons: No errors are given, dpkg says everything is installed just fine.
<fabbione> siretart: ping?
<Fitzsimmons> hunger: fun! :P
* Fitzsimmons hops on gnomenet
<Kamion> hunger: https://launchpad.net/distros/ubuntu/+source/synaptic/+bug/29917
<Ubugtu> malone bug 29917 in synaptic "Synaptic wants to update an already updated package" [Normal,Unconfirmed]  
<Kamion> mvo's subscribed to it already, he should be able to investigate
<siretart> fabbione: pong
<fabbione> siretart: mind if i upload xine-lib to fix sparc FTBFS?
<siretart> fabbione: no, just go ahead.
<hunger> Kamion: Thanks. I did not want to file a bug since I am not sure for which package:-(
<siretart> fabbione: slomo wanted to import xine to our svn tomorrow. I don't see any problems
<Kamion> hunger: better a bug report on the wrong package than no bug report at all
<lamont__> Kamion: speaking of bugs... did I remember to file my pkgsel/include= bug?
<lamont__> s/bug/wishlist/
<Kamion> yes
<fabbione> siretart: ok thanks
<Kamion> haven't had a chance to ponder it yet
<lamont__> Kamion: np
<fabbione> siretart: it's a 3 lines change to debian/rules.. nothing more
<siretart> cool
<fabbione> siretart: upload done...
<Fitzsimmons> hm, strange... I reinstalled ubuntu's version of gnome-panel and everything is working again... even though this exact same version of gnome-panel was experiencing difficulty last night
<ogra> fabbione, whats the status of openssi in ubuntu ? will we have something in dapper+1 ?
<fabbione> ogra: no idea.. you need to ask neuralis 
<ogra> will do
<ogra> they have a intresting way of using local devices over the network, i would like to see if its adoptable for ltsp
<trulux> anyone experienced problems with last ptal upgrade?
<trulux> hmm, pitti's changes are broken
<mdke> o.o ubuntu-desktop is getting removed with the latest dist-upgrade
<Kamion> mdke: libpt/gnomemeeting/etc. changes I think, in progress by dholbach
<cassidy> On dapper, have you Pango API in devhelp ? (package libpango1.0-doc)
<LaserJock> Tm_T: pong
<ulaas> what was the name for the fancy new network monitor applets name?
<ulaas> how can i remove a bug that i filed. i made a mistake.
<mdke> ulaas, mark it rejected
<ulaas> mdke, for the glx problem that i  filed a bug against gnome-screensaver. However the package was unlucky. (Wrong place wrong time). My issue is much moreprobably related with K7 kernel. I will test much more this time.
<mdke> ulaas, you can change the package
<mdke> i assume...
<mdke> ulaas, click "request fix in distribution", then select the correct source package
<ulaas> mdke, i must be sure this time. will do when sure. thanx
<ulaas> switched to a 386 kernel. so far so good.
<dholbach> Yay, seems like opal+ekiga go into main (as successors of openh323+gnomemeeting) and only stuff in universe will still depend on openh323
<Mithrandir> dholbach: are we there yet?  I want to call simira! :-)
<dholbach> opal and ekiga have to go through NEW
<dholbach> and promoted to main
<Mithrandir> woo
<dholbach> and some packages in universe have to be fixed with new pwlib/openh323
<dholbach> hey seb128
<seb128> wb dholbach
<desrt> anyone know where james has been lately?
<seb128> which one?
<desrt> h.
<ogra> in #bzr ? 
<ogra> or in #launchpad ? 
<seb128> dunno for my part
<desrt> neither of those places, either
* desrt hasn't seen him around for the past week or so
<Kamion> desrt: as far as I know, he's been very busy with the archive migration to launchpad
<desrt> ah.  so he's to blame for that :)
<Kinnison> Umm, jamesh is nothing to do with archive->launchpad
<desrt> 'sup daniel
<Kinnison> n'much tall dude
* desrt scratches his head wondering if he should feel tall or like he's talking to a british accent
<Kamion> err, I thought desrt meant James Troup not James Henstridge
<Kamion> oh, totally misread sorry
* desrt falls back to his original assumption
<dholbach> I'll call it the day and go packing - see you.
<thesaltydog> is anyone aware of main libglib-perl bug?
<ogra> yes
<thesaltydog> ciao oliver!
<ogra> it requires a new upstream version which is not available in debian yet ... nobody came around to package it yet it seems
<ogra> hi fabio
<thesaltydog>  have talk with muppet, last week... He said version 1.104 has been released. But it needs to be packaged.
<ogra> yup
<ajmitch_> desrt: jamesh has been in dunedin at LCA all week
<desrt> ahh
<desrt> right
<jordi> does janimo tend to be around this channel?
<ogra> yup
<ogra> and in -motu
<jordi> hmm. unlucky he's not here.
<jordi> does anyone know if he's involved in xfce upstream?
<jordi> he requested the import of some xfce module to rosetta, but I don't know if he did it with upstream's permission
<ogra> i think he does work with upstream, yes
<ogra> crimsun would know i guess
<jordi> crimsun: dude
<jordi> crimsun: I need you
<floam> BenC: sorry I didn't get back to you
<floam> BenC: I'm on sata_via
<ivoks> anyone?
<Burgundavia> ivoks, what do you need?
<ivoks> i'm trying to find out what's forster.ubuntu.com :)
<Burgundavia> hmm, no idea
<ivoks> i have reports that some ubuntu installations make connections to this host
<ivoks> and i can't find any info about it :/
<Burgundavia> what sort of connection?
<ivoks> i don't know
<ivoks> i didn't get enough info
<Burgundavia> all machines connect to ntp.ubuntu.com
<ivoks> ah, that could be it
<tseng> they arent the same ip
<Burgundavia> that well, that scuppers that idea
<ivoks> you stoled my line :)
<ivoks> hm
<ivoks> it has only ports 80 and 21 open
<ivoks> eh, 873 too
<Burgundavia> http://www.ubuntuforums.org/showthread.php?t=122632 <-- you know Malone is bad when they complain about it on the forums
<Lathiat> so, i sanyone else having really really bad udev issues?
<ivoks> no...
<Lathiat> like my d/ev/null ends up o-rwx, b44 isnt loaded, somethigns stoppign X from starting, ssh is saying the PRNG isn't seeded and essentially my laptop is fairly useless :)
<ivoks> i'm having problems with forster :)
<Lathiat> oh and ipw2200 loads but doesnt do anything
<ivoks> strange... my works ok
<ivoks> it's a mirror, AFAICT
<ivoks> maybe update-manager? :)
<ivoks> yup
<ivoks>  hr.archive.ubuntu.com is alias for forster
#ubuntu-devel 2006-02-03
<ogra> hi susus 
<susus> hi
<ogra> :)
<crimsun> jordi: hi, I don't know offhand if Jani asked upstream
<hub> hi
<hub> I just installed kubuntu flight 3, and I have a huge issue
<ryanpg> funny topic, save a copy for infinity :P
<hub> the uname does not match the kernel-image package
<hub> and that mess up as I don't have the right drivers
<hub> any idea how to debug that?
<hub> no biggie, I configured the network by hand loading the right kernel module (hard to guess)
<hub> and I apt-get upgrade
<jordi> crimsun: I mailed him, I'll find out.
<Bicchi> i need to write an application that looks just like the "update manager." A bubble should popup showing that an action needs to take place. can anyone point me in the right direction to do this.
<Burgundavia> Bicchi, update manager uses the notification-daemon for its notifications
<floam> Bicchi: anything can do those, even you (go to a terminal and type notify-send Bicchi "Is a very silly man"
<Bicchi> floam: notify-send doesn't do anything
<floam> is xchat-gnome's spell checking broken everywhere?
<Bicchi> floam: notify-send doesn't do anything. how can i display stuff in the notification area. sorry to bother you. :)
<floam> the notification daemon is what that uses, on dapper
<Bicchi> yeah but you said to type on the console: notify-send message here
<Bicchi> and it doesn't do anything, i am thinking maybe the name is wrong
<floam> Bicchi: if nothing happens something is probably messed up
<Bicchi> its weird because i do get those notifications. it must be done some other way. i even get the bubble to popup and allows me click update and everything.
<Den> Anyone here?
<HiddenWolf> never
<Den> HiddenWolf: Say, can you give me some info regarding what I should do about a bug, about perhaps requesting that the latest kernel be put into Breezy & released as an  update?
<HiddenWolf> newest kernel is not going to happen.
<HiddenWolf> hotplug to udev conversion etc.
<Den> I had a bug with external HD offlining, BenC told me to check out latest kernel
<HiddenWolf> bugs should be filed in malone launchpad.net/distros/ubuntu/bugs
<Den> Mithrandir got me a cd with Dapper, the bug is gone.
<HiddenWolf> Den: kernel can not be put back into breezy without breaking the world.
<HiddenWolf> Den: I guess you'll have to use dapper. Which is pretty stable already.
<Den> So, anyone here who could put the newest kernel into dapper?
<HiddenWolf> Den: if it's on BenC's tree, it'll be in shortly, :)
<Den> Er, dapper has mouse & display brightnes problems
<Den> HiddenWolf: What do you mean?  How do I know if it's in BC's tree?
<Kamion> if BenC told you to check it out, it's in his tree
<Kamion> he's the Ubuntu kernel maintainer
<Den> HiddenWolf: Ok, so why do you say it'll be in shortly, when earlier you said newest kernel isn't gonna happen?
<HiddenWolf> Den: kernel will not be updated for Breezy, but it's still under development for Dapper.
<Kamion> it'll be into *dapper* shortly. 2.6.15 kernels in *breezy* are not going to happen.
<HiddenWolf> Kamion: hah, beat you to the punch. :)
<Den> Well, if it's the _kernel_ that fixed the bug, and the kernel won't be updated in Brez, then Brez is being left with a bad bug, & that seems bad.
<Kamion> Perhaps the fix can be backported (ask Ben about that), but we can't just drop the newest kernel in verbatim.
<Mithrandir> most people don't have firewire devices, so doesn't affect most people.
<Den> Don't the developers want to get bad bugs out of a system that will not be supersceded or at least 3 months?
<Kamion> Please read what I said.
<Den> Mithrandir: Hi!  Hey - your cd worked, and solved the bug about offlined devices.
<Mithrandir> coolie
<Mithrandir> Den: that depends on how risky fixing the bug is.  Better with one bug we know about than a random number we don't.
<Den> Mithrandir: Ok, I didn't realize you were on here.  So, if you read my statements above, you know the situation.  So, I'll report back to the bug & BenC the result.  So, I'm wondering what, if anything, I should ask BenC to do (as a way of summarizing the situation to him).
<Den> Mithrandir: It doesn't seem good to leave the bug there, so should I suggest he see if he can backport the fix, since I'm told here it's too much difficulty to backport the kernel?
<Kamion> let him worry about what to do ...
<Kamion> you don't go to a doctor and tell him what to prescribe. :-)
<Den> Kamion: :)
<Mithrandir> Den: just give him the information and he'll decide.  He's the one who knows the kernel best and is in the best position to decide.
<Mithrandir> Kamion: my girlfriend does that. ;-)
<Kamion> and be prepared for the possibility that he'll say that it's too much work to backport it to breezy given the severity of the bug
<Den> Is BenC often active on this channel?  I've never once seen a post by him.  I'm wondering so as to know if I shoujld email him, or try to catch him here & chat with him about what to do.  When is he usually online?
<Mithrandir> he live in the US
<Den> Mithrandir: So do I.
<Kamion> e-mail, or comment on the bug
<Mithrandir> sure that should work
<Den> When is BenC usually active on this channel?
<Kamion> he's normally here during US working hours
<Den> Kamion: thx
<Kamion> but fairly quiet
<Den> Ok, anyone.  So, Dapper has mouse & display brightness problems that Breezy doesn't.  What am I supposed to do about reporting that.  Are those know issues?
<HiddenWolf> Den: check launchpad, and if there isn't a bug open, please file one.
<Den> Anyone - A week or so I checked the bug track system, after it had moved from ?Bugzilla to ?Launchpad, and it seemed that the bug # for the bug I'd submitted on Bugzilla was now for a different bug, and also when I searched using words for the bug I'd submitted, it didn't come up.  Were bugs supposedly brought across using the sme bug #'s?
<HiddenWolf> ubuntu.com is down.
<Den> Should a bug from ubuntu bugzilla have been transfered into Launchpad?  Bugzilla says "not for changing bugs, logins disabled".  Should I file a bug that my bug wasnt' transfered?  Or, start a new bug entry for the same bug? Or???
<HiddenWolf> Den: it should've been transferred, but ask on #launchpad for the specifics
<Den> HiddenWolf: thx
<zyga> is ubuntu.com down or is it just my network?
<Burgundavia> zyga, nah, is down for me as well
<mdke> morning all
<lsuactiafner> ubuntu needs mkvtoolnix to better support Matroska video files, its open source but yet ubuntu doesnt promote such formats that wouldnt give a patent headache in the long-term?
<Burgundavia> lsuactiafner, is matroska patent-encumbered?
<lsuactiafner> nope, not as far as i can tell
<lsuactiafner> http://www.bunkus.org/videotools/mkvtoolnix/
<lsuactiafner> http://www.matroska.org/
<lsuactiafner> i cant manage to install it from source, i tried to install its dependancies manually but they didnt want to work either, seems a large piece of ubuntu is outdated which also needs attention
<lsuactiafner> look @ this goal:      * Establish Matroska as the opensource alternative to existing containers such as AVI, ASF, MOV, RM, MP4, MPG
<lsuactiafner> and media developers already think Matroska is the best container for media
<lsuactiafner> if its adopted rather than avi thats one less hassle for open-source developers
<Kamion> Den: there's a link from the Bugzilla page for the old bug number to the new Launchpad bug. Try there.
<Kamion> Yes, bug numbers have changed.
<Den> Kamion: yes, I was told about it.  But, it seems launchpad itself has a bug in its search function.
<Kamion> You don't need to use the search function. What's the old bug number?
<Den> Kamion: see my comment in #launchpad - last comment to mdke
<Kamion> OK, it looks like you've already found the bug so there's no longer a problem
<Den> Kamion: Bugzilla Bug 21565
<Ubugtu> malone bug 21565 in wireless-tools "ERROR: invalid MAC Address at line 2, this is dangerous" [Minor,Fix released]  http://launchpad.net/bugs/21565
<Den> Kamion: well, there's no problem now as far as my bug being in the launchpad system, buth there is a problem with launchpad search of text words in the bug topic failing to find the correct search resuldts.
<Kamion> http://bugzilla.ubuntu.com/show_bug.cgi?id=21565 has a link saying "View this bug in Launchpad".
<Ubugtu> ubuntu bug 21565 in linux "external hard disk disconnects (firewire ieee1394 over SCSI) during file copy 'Read-only file system' 'Device offlined'" [Normal,Needinfo]  
<Kamion> right, but that's #launchpad's problem and not ours. :-)
<Den> Kamion: yes, but I'm a seldom user of bugzilla, & didn't know to look for that, 
<Kamion> it's on the bug page for your bug *shrug*
<Den> Kamion: I _did_ look on launchpad, & launchpad failed - so I'm letting you know about this launchpad bug,cause I'm too tired & busy to do anything abou t it
<Den> Kamion: Anyway - thanks for your help.! :)
<netdur> on livecd, how do I do pre-select screen resolution? (livecd customization)
<Mithrandir> in dapper or breezy?
<netdur> hoary
<netdur> I guess... must be the same as breezy
<Mithrandir> yes, it is.
<Mithrandir> you could possibly preseed it, I'd think.
<netdur> hmm? what file to edit?
<netdur> I don't what "preseed" mean!!!
<Mithrandir> no need to use multiple exclamation marks
<Mithrandir> you have read https://wiki.ubuntu.com/LiveCDCustomizationHowTo ?
<Mithrandir> search for "preseed" on that page
<netdur> I use it to pre-select lang and keymap, I did not know I could use it to pre-select screen secolution
<netdur> Mithrandir, sorry
<netdur> Mithrandir, thanks for help "DEBCONF_PRIORITY=critical" help to skip the questions... which is fine for me
<Mithrandir> oh, ok.  Yeah, it should
<simira> Mithrandir: good morning, honey. Working today also?
<simira> oh. Not interested today. 
<simira> mwell
<poningru> question where should I be filing bugs to for dapper?
<lifeless> lp
<poningru> I only see about 32 bugs there
<poningru> so...
<poningru> I mean people have to be filing more right?
<mpt__> poningru, most bugs are being reported just on Ubuntu, afaict
<poningru> oh ok
<mpt__> and then developers are targeting them to Dapper or not
<poningru> so should I do the same? or file it under dapper?
<mpt__> I honestly don't know
<netdur> malone?
<poningru> yeah same thing
<mdke> poningru, if it's dapper specific, it would make sense to file under dapper I think
<poningru> ok also should I file some of the obvious ones?
<poningru> like two instances of screensaver under system->pref
<poningru> I mean I assume the dev knows about it
<mpt__> If it's not in the bug tracker, they can't use the bug tracker to decide what to work on next
<poningru> ok this is def weird and confusing, but I will search under ubuntu also before filing for dapper
<poningru> thanks for the help
<mdke> searching under Ubuntu should turn up dapper bugs too, I would have thought
<Kamion> poningru: there's no particular need to file them under dapper
<Kamion> poningru: we'll take care of targeting bugs to dapper as necessary for release management
<zyga> what is the current standards version?
<poningru> Kamion: oh ok
<mpt__> aha, you can't "file it under dapper" anyway
<mpt__> https://launchpad.net/distros/ubuntu/dapper/+filebug redirects to https://launchpad.net/distros/ubuntu/+filebug
<mpt__> which is good
<Kamion> zyga: sudo apt-get install debian-policy
<zyga> Kamion: merci
<poningru> mpt__: doh
<poningru> mpt__: now I see it
* Mithrandir ruffles simira 
<\sh> gnarf
<\sh> loopback is not setup properly
<\sh> running 2.6.15-14-amd64-generic 
<\sh> can anybody confirm this? 
<\sh> [pid  5732]  stat("/usr/bin/xauth", {st_mode=S_IFREG|0755, st_size=35880, ...}) = 0
<\sh> [pid  5732]  socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
<\sh> [pid  5732]  bind(7, {sa_family=AF_INET, sin_port=htons(6010), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address)
<\sh> [pid  5732]  close(7)                    = 0
<Kamion> \sh_away: 'ifup lo'. Check whether that solves your openssh bug too; bugs from a system without lo tend to be invalid
<mdke> \sh_away, see if you have duplicate entries for an interface in /etc/network/interfaces which is preventing your system from bring up lo
<jdong> is there any chance we can get a newer libxine in Dapper?
<zyga> jdong: maybe, but unlikely
<jdong> zyga: the current version cannot play h.264 mpeg4's at all
<jdong> the xine folks say that 1.1.0 and onward have full h264 support
<zyga> jdong: you need to convice someone (I cannot remember who/which group) that this is critical
<zyga> or just badly needed
<jdong> alright, off to LP then
<siretart> jdong: we have 1.1.1 in dapper, FYI
<jdong> hmm, I'm not pulling it.... when was it put there?
<siretart> jdong: this is the latest upstream release. so I don't think dapper will get anything newer
<jdong> siretart:  1.1.1 is perfect; just somehow I'm not getting it
<siretart> jdong: http://packages.ubuntu.com/dapper/source/xine-lib
<jdong> wow I feel stupid
<jdong> somehow there are a bunch of breezy lines in my sources.list
<jdong> I swear I changed them over!
<jdong> wait... booted into wrong partition
<jdong> hehe
<jdong> alright, everyone, point and laugh at jdong
<siretart> jdong: but honestly, I think you are more interested in http://packages.ubuntu.com/dapper/source/xine-extracodecs
<HiddenWolf> siretart: yeah, that's a pity, it used to be only gstreamer that needed tweaking before it'd play. Now with xine lobotomised too, video sucks. :)
<siretart> HiddenWolf: I'd also like to change the world :(
<HiddenWolf> siretart: let's do it together. :)
<crimsun> I find both gstreamer and xine work well for my test cases
<siretart> HiddenWolf: how? - I currently don't see much interest in discussing patent issues in the community
<siretart> in the one corner, you have developers of video players, which are pissed by distributions, because of 'patent issues'. They say that there are so many patents in distributions already, that it wouldn't matter to include/ship their software
<siretart> in the other corner you have distributions, who fear legal prosecution from a really livid multimedia lobby
<topyli> and the winner is... ta-daa! nobody :)
<siretart> recent example: see the discussion about the status of ffmpeg and rte in debian. ffmpeg IS in debian, and can be used to encode video into mpeg, and rte offers the same functionality, but may not enter debian
<siretart> because of this very reason.
<siretart> topyli: the loosers are our users :(
<topyli> yep
<Gandalfar> infinity: I have a broken initrd here for 2.6.15-14-386, it doesn't recognize the hard disk after breezy -> dapper upgrade, does this help you?
<wasabi> Heh. All initrd's I generate don't work. ;)
<hunger> Gandalfar: I think you should file a bugreport, attach the initrd and assign it to adam conrad.
<zwnj> i try to run Gedit in Persian locale, but """LANG=fa_IR gedit""" doesn't work.  same about other gnome applications.
<Treenaks> wow, my SD card reader has some (non-working) driver in current dapper
<zyga> zwnj: could you try running gedit from the terminal and checking out if it says anything helpful?
<jordi> daniel nylander
<jordi> this dude is like the translation superhero
<Treenaks> why?
<jordi> he submits a new translation to rosetta every hour or less
<Treenaks> wow
<jordi> he hit a bug with his policycoreutils translation though :)
<zyga> jordi: upstream or his own?
<jordi> zyga: his own I'd say
<zwnj> zyga: i tried, and it says nothing.  no error with fa_IR.  but if i set LANG to something like ab_CD, it makes Gtk-WARNING: Locale not supported by C library.
<zyga> zwnj: that's because fa_IR is a valid locale and ab_CD is not
<zyga> zwnj: does it crash? does it exit silently?
<zwnj> and i do have this file: /usr/share/locale-langpack/fa/LC_MESSAGES/gedit.mo
<zwnj> zyga: no, it just works like en_US locale
<zyga> zwnj: ah, okay
<zyga> zwnj: then check out if that file really contains any translations 
<zwnj> i tried both fa_IR and fa_IR.UTF-8
<zyga> zwnj: or better, take the upstream version of corresponding .po file and rebuild the .mo file yourself
<zwnj> lemme test a Persian session from GDM
<zwnj> AFAIR, everything works in that way
<zwnj> it's not a gedit bug
<zwnj> non of gnome applications works
* Robot101 would like to suggest Fursty Ferret as a name for dapper+2 :D
<zwnj> zyga: any idea?
<zyga> zwnj|away: no, sorry
<poningru> mako: may I suggest a human turing test?
<poningru> mako: just create a text box with the message dont put anything in here if you are human
<poningru> ofcourse you might have idiots that will fail it: http://adam.rosi-kessel.org/weblog/this_weblog/humans_fall_turing_test.html
<dredg> then surely they fail the turing test and are pronounced not human, right? :)
<poningru> dredg: hehe yeah and their comments are not posted
<dredg> poningru: the correct response from the server should be to kill them in the face.
<dredg> now if only there was an rfc for that
<poningru> I dont know we could try to create a firefox extension that will do that
<poningru> although we would have to convince the user to install it
<mpt> that's similar to jwz's "audio-cock technology"
<dredg> hmm. i wonder if my employers would take issue with adding this feature to the google toolbar...
<mpt> http://jwz.livejournal.com/123070.html?thread=521918#t521918
<dredg> hah. awesome
<Mez> oh poop, we're in UVF arent we
<Mez> so I might as well click "cancel" on that email I was about to send
<EvanCarroll> Are there any plans to upgrade the mplayer package, aparently #mplayer says they are 9months old
<crimsun> eh?
<crimsun> mplayer | 2:0.99+1.0pre7try2+cvs20060117-0ubuntu1 | http://archive.ubuntu.com dapper/multiverse Sources
<crimsun> (I suppose you could always ask for a backport to breezy)
<EvanCarroll> Thats 9 months old.
<EvanCarroll> I'm on dapper.
<crimsun> huh?
<EvanCarroll> old checkout i suppose.
<crimsun> surely you mean _12 days_
<poningru> from their website: v1.0pre7try2 is the latest stable
<EvanCarroll> I'm confused, I agree with you
<EvanCarroll> I just want my rm to play at this point
<EvanCarroll> and it doesn't with the version in the dapper archive =[
<EvanCarroll> pastebin.com/529462
<crimsun> EvanCarroll: it's really quite simple; slomo did a fresh cvs checkout on Jan 17th, which is 12 days ago
<EvanCarroll> I agree
<EvanCarroll> I'm blaming it on bad cvs
<EvanCarroll> Tell me if these work for you w/ your mplayer
<EvanCarroll> webcast.berkeley.edu/courses/archive.php?seriesid=1906978270
<crimsun> let's take this to #ubuntu, because I have a feeling you're trying to play media unsupported by your installed codecs
<EvanCarroll> I have the w32codecs
<EvanCarroll> works with xine
<poningru> that wont do
<EvanCarroll> Why is that?
<poningru> I think realplayer 10 messes up w32codec
<poningru> dont remember the details
<EvanCarroll> I dont have it installed.
<crimsun> I can't play it at all
<EvanCarroll> crimsun: And thats the problem.
<crimsun> again, this is a support question, let's migrate to #ubuntu
<poningru> yeah
<poningru> EvanCarroll: #ubuntu
<EvanCarroll> 16:18 < theoddbot> its bad packager
<EvanCarroll> 16:18 < theoddbot> apt-get build-dep mplayer
<EvanCarroll> 16:18 < theoddbot> then checkout your own cvs and build it
<EvanCarroll> 16:19 < theoddbot> i'm running ubuntu with cvs and it works just fine
<EvanCarroll> 16:19 < theoddbot> strangley enough that particular package (that i also having installed) is fubar
<EvanCarroll> 16:19 < theoddbot> so yeah
<EvanCarroll> that makes two people experiencing the same problem, I'll have my own build done in about 30min
<poningru> what happens when xine tries to play it?
<EvanCarroll> Works perfectly
<EvanCarroll> for him too, he is also on dapper
<EvanCarroll> guess I wont be building my own, libasound dev files 404ing
<EvanCarroll> I'll build after archives updates, and get back to #ubuntu-devel
<slomo> EvanCarroll: what about filing a bug then ;P i'll take a look at it this week and try to get it fixed
<EvanCarroll> Bah i suppose I should do that too. =/ being a little lethargic today
<slomo> EvanCarroll: just as a reminder for me... add the url that doesn't work there, a short description and assign it to slomo
<EvanCarroll> sure thing got the url of the bugtracker
<slomo> https://launchpad.net/malone
#ubuntu-devel 2006-02-04
<simira> anyone here in London for the distro sprint?
<zwnj> i just tested the German locale.  "de_DE.UTF-8" doesn't work too and i see an en_US interface.  note that i get error on "de_DE" and "de"
<poningru> would it be possible to have mplayer automatically loaded and mozilla-mplayer plugin put in?
<Burgundavia> poningru, you want mplayer to be pushed into main and installed by default?
<poningru> Burgundavia: well thats not necessary
<poningru> totem-plugin should be installed by defautl then
<poningru> the correct package is totem-gstreamer-firefox-plugin
<Burgundavia> poningru, totem plugin should already be installed by default.
<poningru> oh?
<poningru> well its not for me
<poningru> hmm
<Burgundavia> file a bug
<poningru> wait what do you mean totem-plugin?
<poningru> which package do you mean by that?
<Burgundavia> it is all being built out of the totem source package, I believe
<test34> What does Ubuntu uses to auto-mount CDs, USB sticks, etc when you plug them in ?
<floam> test34: gnome-volume-manager
<floam> which is given information from HAL and uses pmount
<test34> thanks floam, does kubuntu uses gnome-volume-manager too ?
<floam> test34: probably not
<crimsun> test34: ivman
<test34> cool, thanks
<ninjaru> there someone being a real asshat in #ubuntu, just thought someone here might like to know about it
<ninjaru> quote "thangog: why don't u fuckin fags go fuck yerselves"
<ninjaru> it wasnt aimed at me, but I didnt really apprecaite that much
<Burgundavia> jsgotangco, you still aren't in -doc by default
<jsgotangco> heh i forgot to add it on this machine
<sivang> morning all
<chmj> hi all 
<chmj> is anyone currently working on myubuntu? 
<Burgundavia> chmj, myubuntu?
<chmj> Burgundavia: aka buntu 
<Burgundavia> chmj, ah, not going to happen int he dapper cycle, at this point. Unless a very serious community member stepped up
<chmj> Burgundavia: I thought so 
<chmj> so nothing has been done since breezy? its was listed as a breezy goal.
<Burgundavia> breezy had some seriously optimistic goals
<Keybuk> Dapper's the first release where the "goals" are really intended to actually be met
<Keybuk> breezy and before they were more like "things that could be done if we had the time"
<Burgundavia> Keybuk, likely JaneW's influence, amongst others
<Burgundavia> Keybuk, how are you feeling?
<Keybuk> I'm good
<Keybuk> waiting for SOMEBODY ELSE to get up
<Burgundavia> isn't it 8am there?
<Keybuk> yes
<Aegir> HAH! Y2k bug in Evolution! Has to be! Except it's going to 1996 and not 1906 and won't let me set my damn dates properly in the callender. Oh this is so amusing.
* Aegir sheds a tear of joy
<hunger> Anyone looked into #29917 yet?
<Keybuk> hunger: dude, you filed it on Saturday
* Keybuk hands you a complementary "ARE WE THERE YET?" lurid green t-shirt
<hunger> Keybuk: Oh... was that saturday?
<zakame> afternoon all
<hunger> Keybuk: Seems longer to me;-)
<pitti> Hi
<ajmitch> hi pitti 
* pitti waves to JaneW 
<JaneW> hi pitti :)
<Burgundavia> hello JaneW, have fun with the whip this week?
<ajmitch> morning JaneW 
<JaneW> Burgundavia: heh thanks :)
<JaneW> hi ajmitch 
<jsgotangco> hey JaneW
<JaneW> hi jsgotangco 
<Mithrandir> *yawn*
* pitti hugs dholbach 
<dholbach> hellas pitti
* dholbach hugs pitti
<janimo> dholbach, UVF exception for exo/thunar, need to sent to motu list?
<dholbach> janimo: yeah
<janimo> ok
<dholbach> do it quickly and i'll prod matt and colin, later
<janimo> prod for what, actual sync?
<janimo> or you're the proxy and all goes trhoiught them?
<janimo> actuall these two are approved for main just not promoted yet
<Kamion> janimo: stuff that's only in the xubuntu seeds isn't getting displayed in our list of things to promote at the moment; elmo needs to fix that I think
<janimo> Kamion, yes and xubuntu-desktop still has some bits not approved so I did not push it yet
<Burgundavia> Kamion, isn't great to have a rich and crazy boss?  https://lists.ubuntu.com/archives/sounder/2006-January/003810.html
<ajmitch> Burgundavia: how is that crazy?
<Burgundavia> ajmitch, that marks sees something shiny and then goes "I want it!" and orders it to be so
<Kamion> Burgundavia: seems perfectly sane to me :)
<ajmitch> Burgundavia: it was a spec at UBZ to boot from usb
<ajmitch> not just a random decision :)
<Burgundavia> I guess so, but still funny
* jsgotangco needs a 1GB stick too
<ajmitch> sadly I don't think my 512MB stick is bootable with my laptop
<Burgundavia> mine is only 128, so it won't do
<jsgotangco> i have a 512 muvo
* ajmitch was going to try having an encrypted root fs & booting from usb
<Burgundavia> incidentally, have those UbuntUSB people ever actually contacted anyone at Canonical?
<jsgotangco> what does boot.img.gz do?
<jsgotangco> i think it only contains the kernel and installer
<Mithrandir> Burgundavia: not that I know of.
<Mithrandir> Burgundavia: we'll most likely drive them somewhat out of business with dapper-live, though. :-)
<Burgundavia> indeed
<ajmitch> and the $30 fee is a bit rude
<AlinuxOS> sir pitti ?
<Burgundavia> they were rather evasive in that interview
<pitti> Hi AlinuxOS 
<StevenK> ajmitch: My wife read that statement and came out with a very disturbing statement.
<AlinuxOS> hi
<ajmitch> StevenK: I knew someone would
<AlinuxOS> I have some questions, have got some time?
<ajmitch> I'm always so misunderstood :)
<StevenK> Heh
<Burgundavia> dammit, why is 2am a great time to be up and chatting?
<AlinuxOS> pitti, I have some questions, have got some time?
<janimo> Kamion, how can I in a broken dapper iso install (cannot install kernel) manually install packages from target/media/cdrom ?
<janimo> I can't find dpkg 
<janimo> it's the daily of yesterday on a 64M laptop
<pitti> AlinuxOS: just ask, I'll answer in between my work
<AlinuxOS> pitti, ok
<Kamion> janimo: chroot /target, then you have dpkg
<janimo> Kamion, ta
<sivang> morning all
<ajmitch> morning sivang 
<sivang> hey ajmitch , 'sup?
<ajmitch> just replying to an email about work, nothing exciting
<ajmitch> and longing to get back to ubuntu hacking after a week of LCA
<Burgundavia> Moz corp has 30+ people working on Thunderbird and Firefox, bloody hell
<sivang> Keybuk: I'm still having truobles with ifupdown_0.6.7ubuntu6 , is this solved with an upgrade? (had to downgrade to ubuntu5 to make ti work)
<sivang> ajmitch: oh , LCA sounds cool. I wish I could visit it for once :)
<ajmitch> sivang: it was very cool
<ajmitch> gah
<ajmitch> libsemanage.semanage_link_sandbox: Link packages failed
<sivang> Keybuk: this time it seems that ntp update is to blame
<ajmitch> nasty stuff stil
<sivang> Keybuk: it extis with 1, which breaks ifup I think
<hunger>  sivang: I think the latest ifupdown ruined my dhclient.conf. If you have a backup of that then you should be fine.
<sivang> hunger: I just re-installed ubuntu5, that did the trick
<sivang> hunger: my dhclient.conf seems un-touched
<hunger> sivang: Well, maybe I had broken the dhclient myself. Not sure.
<hunger> sivang: This is why I have not filed a bug:-)
<sivang> hunger: :) Isloation is the name of the game :)
<ajmitch> hm, awk is exploding in my face trying to build this - not helpful
<Keybuk> sivang: "problem"? "troubles"?  what happens/goes wrong/etc.
<sivang> Keybuk: so: I booted with ifupdown_0.6.7ubuntu6 ,
<Keybuk> right
<sivang> Keybuk: getting "run-parts: ntpate exited with 1" or so
<Keybuk> ok
<hunger> Keybuk: shortly after the last upgrade my server would no longer got his IP from its dhcp server.
<sivang> Keybuk: iface won't come up
<hunger> sivang: did you get an IP?
<sivang> Keybuk: that is won't get IP from dhcp server
<Mez> does the fridge-devel@lists.ubuntu.com address work even though it hasnt got a mailing list
<Keybuk> sivang: "won't come up" ?  ntpdate happens after that
<Keybuk> sivang: so did it come up, and go back down again?
<hunger> Keybuk: The /etc/dhcp3/dhclient.conf (IIRC) contained only one bogus line at that time.
<sivang> Keybuk: not that I knew of, anyway to check that?
<hunger> Keybuk: As I said: I am not sure that I didn't break this.
<sivang> Keybuk: from my perspective, it never came up (didn't get an IP)
<Keybuk> sivang: watch it from another terminal, do ifdown/ifup
<hunger> sivang: Is there only one line in /etc/dhcp3/dhclient.conf?
<sivang> Keybuk: how do I watch if an interface came "up" ? (actually, thinking about it- is there a difintion for when an iface is up besides getting and ip)
<hunger> sivang: The symptom is what I had as well.
<Keybuk> sivang: "watch ifconfig -a"
<Keybuk> sivang: yes, "UP" in the ifconfig outpuut :p
<sivang> hunger: two lines, one that I added about broadcasting the hostname (send host-name "ubuntu";)
<sivang> and one about the "request subnet-mask, broadcast-address, ...."
<sivang> Keybuk: will do that and tell you, I'm upgrading again so I reckon ubuntu6 will get re-installed
<hunger> sivang: that and python-twisted (if you have that installed) ;-)
<sivang> hunger: speaking of python stuff, do you know if previously mounted fs were not reported as volumes in hal and now they are ? I have some code that got broken due to that :)
<sivang> hunger: that is, stuff mounted from  a CDROM and USBDisks were reported as volumes, but stuff from HD were not.
<sivang> hunger: and now they are ;-)
<trulux> morning
* trulux testing dapper upgrade
<trulux> nvidia-settings conflicts over here
<trulux> stops from upgrading x11 pkgs
<ajmitch> morning trulux 
<trulux> (nvidia-glx from dapper wants to write /usr/bin/nvidia-settings)
<trulux> hey ajmitch 
<trulux> ajmitch: howya?
<ajmitch> alright, just working on some selinux policy stuff
<Treenaks> btw, am I the only one without image thumbnailers in nautilus?
<trulux> ajmitch: I'll do so once I get dapper working
<trulux> ajmitch: it seems like we can get this one going :)
<ajmitch> hm?
<trulux> ajmitch: support in pkgs since the dbeian sync
<trulux> ajmitch: http://rafb.net/paste/results/cHpamw30.html
<ajmitch> I know that
<ajmitch> I've actually been using selinux & have stuff working
* ajmitch talked with rjc a bit last week at LCA
<janimo> Keybuk, in a fresh server daily install /dev/null is not user RW, is this your area?
<Keybuk> 640 ?
<janimo> 660
<Keybuk> ok ... did it hang for a few minutes on boot?
<janimo> resultis in permission denied on login
<janimo> because of sourcing /etc/bash_completion
<janimo> scrolling of permission denied messages
<janimo> until Ctrl-C
<ajmitch> Keybuk: a familiar problem, is it? the 'detecting & activating hardware' step failing
<janimo> it did not really hang on boot
<Keybuk> ajmitch: I think I fixed it this morning
<hunger> sivang: Nope... I am not kubuntu. That is not so deaply into hal yet I think.
<janimo> no network at all
<ajmitch> Keybuk: great, it was intermittent for me, but I was a little busy to report it
<Keybuk> janimo: udevd is running?  and nothing (much?) in /dev/.udev/failed
<janimo> on every reboot it is set back to 660
<janimo> lemme see
<trulux> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/27040
<Ubugtu> malone bug 27040 in linux-restricted-modules-2.6.15 nvidia-glx "nvidia-glx in 2.6.15.3-1 contains an undeclared conflict against nvidia-settings (all versions)" [Normal,Unconfirmed]  
<trulux> "unconfirmed"
<janimo> Keybuk, not running and failed has a lot of entries underneath
<janimo> maybe because of the manual install, since kernel install from D-i failed so I dpkg -i instead
<Keybuk> janimo: that would be your problem then :)
<trulux> this won't let me remove nvidia-settings now due to x11 pending upgrades
<janimo> ok then, thanks
<Keybuk> janimo: is udev even installed?
<lifeless> seb128: how can I tell if the 'dbus session' thing is running ?
<sivang> Keybuk: ok, I found it the issue - it swapped eth1 & eth0. on boot, all ifaces are UP BROADCAST, but I then need to manually run dhclient to get a lease for eth0 (while it was always eth1 before)
<pitti> lifeless: echo  $DBUS_SESSION_BUS_ADDRESS ?
<sivang> Keybuk: working now with -14
<sivang> (after the dist-upgrade)
<lifeless> pitti: blank
<pitti> lifeless: also, ps aux|grep dbus-daemon does not show a process for your user?
<pitti> it should be like 
<pitti> martin    6807  0.0  0.3   2692   784 ?        Ss   02:47   0:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session
<Kamion> janimo: /var/log/syslog in the installer might help you find why base-installer can't install the kernel
<Keybuk> sivang: oh,yeah, it'll do that
<lifeless> robertc  30252  0.0  0.0   3676   740 pts/1    R+   22:01   0:00 grep dbus-daemon
<Keybuk> sivang: reboot and they'll swap again, and again, and so on
<lifeless> pitti: i.e. nothing
<sivang> Keybuk: yes, pretty annoying :)
<sivang> Keybuk: where do you usually fix something like that? </curiosity>
<ajmitch> Keybuk: how's network manager looking now? in sad shape still?
<sivang> pitti: has there been any changes to hal/dbus that now mounted hard drive partitions are represetned as volumes in the device tree ?
<sivang> pitti: (while in the past they were not)
<lifeless> pitti: so, how do I get dbus running ?
<pitti> sivang: yes, the probe now runs as root
<pitti> lifeless: do you have /etc/X11/Xsession.d/75dbus_dbus-launch ?
<sivang> pitti: ah ok, thanks very much. I need to fix some code then ;-)
<lifeless> no
<sivang> pitti: this is with sjored's new root priviliged daemon ?
<lifeless> pitti: ^
<pitti> sivang: yes
<Keybuk> ajmitch: not looked at it yet
<Keybuk> sivang: when I get around to it ;)
<pitti> lifeless: hmm, it's in the 'dbus' package, which you should have
<pitti> lifeless: but it's a conffile, did you happen to remove it at some point?
<pitti> lifeless: if so, dpkg -i --force-confmiss /var/cache/apt/archives/dbus_*.deb should work
<lifeless> pitti: I am not aware of ever removing it
<lifeless> what dbus package should I have ? 
<lifeless> rc  dbus                        0.50-1ubuntu3               simple interprocess messaging system
<lifeless> note the status
<pitti> uh
<lifeless> I only went with what synaptic did
<sivang> Keybuk: ah, care to ping me up? I'm keen to know about where will this be fixed :)
<pitti> lifeless: maybe you got the victim of some temporary uninstallability due to a library transition?
<lifeless> pitti: I had huge installability probs for about three weeks
<pitti> lifeless: you should have 0.60-2something
<lifeless> half of gnome wanted a different dbus to the other half
<lifeless> or so it seemed
<pitti> yes, sounds like a transition breakage
<pitti> lifeless: aptitude install ubuntu-desktop should cure many problems
<Keybuk> sivang: "ping you up" ?
<lifeless> then it all came good, until I tried to use epiphany -- i.e. immediately :)
<\sh> damn..how can someone check, if the thread manager of a jvm is working?
<\sh> .oO(without checking the logfile for "unable to create a native thread") I hate java
<Kamion> ubuntu-desktop's uninstallable at the moment, we're working on fixing that
<lifeless> Kamion: k
<lifeless> I've happily installed just dbus though
<lifeless> and -utils
<sivang> Keybuk: never mind, I'll just follow the bug report :)
<Keybuk> sivang: what's pinging somebody up?
<Keybuk> is it kinky?
<sivang> Keybuk: hehe
<sivang> this reminds me my mishap in chat with Kinnison sometime ago :-)
<lifeless> pitti: I've asked this in the bug, but if epiphany needs dbus, why does it not depend on it ?
<pitti> seb128: ^ ?
<sivang> Keybuk: could probaby sound like it, but I was more referring to you ping me on IRC when you've found the problem ..but I better be following the bug report instead of bugging you.
<Keybuk> sivang: oh, I know what the problem is
<Keybuk> I haven't written any code to parse /etc/
<Keybuk> ... /etc/iftab and name the network device appropriately
<lifeless> muhaha
<seb128> lifeless: that's right, I'll fix that today
<lifeless> seb128: sweet
<seb128> but epiphany should not crash without dbus neither
<lifeless> it does not crash
<seb128> I'll bug upstream too
<lifeless> it never starts
<lifeless> ;)
<seb128> right, same
<seb128> it should work without dbus probably ;)
<sivang> Keybuk: ah, I see.
<lifeless> mjg59: so, dell x1s - any love to share 
<janimo> Keybuk, yes udev is installed I'll try to find out if it's not too late why the kernel did not install 
<sivang> seb128: any idea when the libc bug regarding non ascii chars wil be fixes? (the one that crashes evo/gaim ..)
<seb128> let me ask jbailey
<seb128> he says: "probably today"
<Keybuk> janimo: kernel?
<janimo> Keybuk, yes the kernel image did not install automatically
<janimo> so I dpkg-i -d it 
<janimo> the finished grub install step
<janimo> so maybe some other things went wrong because of same
* janimo wonders how much should d-i be confused if cmos clock says it's Jan 1 2000 and there's no NTP 
<tseng> janimo: tar gets pretty pissed off if your files are dated in the future
<tseng> janimo: no idea how much dpkg likes that
<Mithrandir> what's the reason for bzr not being in main?
<janimo> tseng yes lots of tar called from postinst warnings
<janimo> and gpgv checking of Release.gpg returns with 2
<janimo> 'C' is not a supported language locale
<janimo> info Found kernels ''
<Kamion> d-i passes the gpgv option to ignore time conflicts
<janimo> so it may be that the broken clock causes all this
<Kamion> the C thing should be unrelated I think, but you never know
<janimo> locale: cannot set LC_CTYPE, LC_MESSAGES, LC_ALL to default locale, no such file or directory
<janimo> adapted for IRC :)
<janimo> and then comes found kernels '' , not installing any kernel ( which seems logical)
<Kamion> there should be some debugging output about what kernels it found in the apt cache in /target
<herzi> dholbach: ping
<dholbach> herzi: pong
<herzi> dholbach: can you take a quick look at 30047? thanks
<dholbach> herzi: no, sorry - i have no clue, what it is about.
<dholbach> herzi: if it's universe, i'd recommend CCing the 'motureviewers' team
<Kamion> janimo: if there's no other output then I guess the apt cache is buggered, which could happen because of apt-get update failing due to the gpgv thing I guess
<herzi> it's about "my wacom tablet doesn't work anymore with dapper"
<janimo> Kamion, I am now in the bootted system which has aworking shell at least but no udev. So there's no /target right now
<Mithrandir> herzi: there's no modular Xorg wacom driver, is there?
<herzi> Mithrandir: there is not
<Kamion> janimo: is this a standard image at all?
<Kamion> or is it one you built?
<Mithrandir> herzi: well, then you lose.  AIUI.
<herzi> Mithrandir: but you can use the package from breezy and add a symlink
<janimo> yesterdays current install -386.iso
<herzi> Mithrandir: it works here with dapper
<Mithrandir> herzi: there's no source package for it, though.
<janimo> and the kernel installed fine with dpkg after a chrooted as you suggested
<janimo> s/a/I/
<Kamion> janimo: hmm, not noticed anything like that with the image from a few days back, so I guess it must be a recurrence of the old time conflict thing
<Kamion> janimo: file a bug on debian-installer attaching /var/log/installer/syslog please?
<janimo> need the installer syslog?
<janimo> ok :)
<segfault> latest udev upgrade changed my /dev/null to 0660, is that supposed to happen?
<janimo> segfault, happens here too, but probbaly not supposed to happen
<janimo> there's a discussion related to this if you scroll back a page or two
<janimo> it happened here because udev is not running
<janimo> I have some strange smbus errors in the log
<segfault> humm, i see
<janimo> do you also have files under /dev/.udev/failed 
<janimo> ?
<janimo> segfault I did an udev reinstall and then a reboot and it's fine now
<janimo> beats me why
<segfault> yes, a lot of them
<segfault> acctualy, 14.
<janimo> after I manually deleted /dev/null and /dev/console because udev restart complained
<janimo> try /etc/init.d/udev restart
<janimo> fast till I it's fresh in my mind ;)
<pef> hello
<Keybuk> JaneW: oops! :)
<JaneW> heh
<mantiena-baltix> Kamion, hi
<zakame> good evening all :)
<mantiena-baltix> zakame, hello
<zakame> hello mantiena-baltix :) what's up?
<mantiena-baltix> zakame, all up ;)
<zakame> at the distro sprint?
<mantiena-baltix> zakame, what is distro sprint ?
<zakame> hm, whip-cracking time for ubuntu-devs involved in Dapper feature goals :)
<AlinuxOS> pitti, ? can you receve my privat msg?
<mantiena-baltix> Kamion, please answer me, when you will be online ;)
<mjg59> lifeless: In what way?
<Kamion> mantiena-baltix: please mail me if you want me to pay attention, or just comment on bugs or whatever; I'm not terribly reliably on IRC this week
<\sh> Kamion: regarding the "loopback" problem from yesterday...I'm not using n-m on my workstation..so I can rely only on the standard network stuff...on my laptop, with n-m, it works without any problems
<siretart> \sh: with madwifi?
<\sh> siretart: no..loopback device not setup properly
<siretart> \sh: I remember you complaining about loosing connection during scans
<\sh> siretart: and eth0 not setup properly after reboot, too
<\sh> siretart: that's something else
<siretart> ah
<siretart> ok. I'm using whereami on my laptop anyway.
<\sh> siretart: laptop with n-m is working, despite the fact of the connection problems, which I can't figure out properly, because it's a regression of the router
<siretart> \sh: ok. 
<hunger> ls
<hunger> Oops, sorry!
<hunger> Could somebody fix the new dhcp? It is "while [ ... ] ; do" not "while [ ... ] ; then" in sh.
<hunger> line 45 of /etc/dhcp3/dhclient-script
<Keybuk> ah, clearly I should do these kinds of things *after* lunch
<hunger> Keybuk: The script works fine apart from that;-)
<Keybuk> [ job dhcp3_3.0.3-6ubuntu2_source from dhcp3_3.0.3-6ubuntu2_source.changes
<Keybuk> ok, uploaded ;)
<hunger> Keybuk: Thanks!
<mantiena-baltix> Kamion, I think it would be easier to communicate through IRC ;) I need to ask just one question - where is changed (set) value of grub-installer/bootdev debconf setting, which uses grub-installer script
<mantiena-baltix> Kamion, I don't find any line in espresso package, which changes this setting
<Keybuk> "...I'm sorry, but Kamion isn't here right now..."
<mantiena-baltix> no problem ;)
<MisterN> hi. I've installed dapper yesterday and want to tell somebody about the issues i've encountered and how i solved them (if i could). is this the right place?
<Treenaks> MisterN: well, the 'best' way is to just file bugs for the issues you have
<MisterN> Treenaks: must I?
<Treenaks> MisterN: you can do that on https://launchpad.net/distros/ubuntu/+filebug (after searching if it's been reported already of course, on https://launchpad.net/distros/ubuntu/+bugs)
<Treenaks> MisterN: problems that don't have associated probably won't be fixed, unless they're VERY obvious
<MisterN> oh well i found a while [...] ; then
<MisterN> in a startup script
<MisterN> is this obvious enough?:)
<herzi> wacom-tools?
<MisterN> na mom
<Treenaks> MisterN: dhcp3 ?
<MisterN> /etc/dhcp3/dhcpclient-script
<MisterN> Treenaks: yes.
<Treenaks> MisterN: (because I just saw a changelog for dhcp3 about broken while; stuff)
<Treenaks> MisterN: it has been fixed already
<MisterN> Treenaks: the update that broke it was done by me 10 minutes ago:)
<Treenaks> MisterN: https://lists.ubuntu.com/archives/dapper-changes/2006-January/005588.html
<MisterN> Treenaks: yeah this should be the thing
<mdz> Keybuk: https://launchpad.net/distros/ubuntu/+source/alsa-utils/+bug/30040
<Ubugtu> malone bug 30040 in alsa-utils "alsactl load state 1236 finds no devices on boot" [Normal,Unconfirmed]  
<mdz> Keybuk: ^^ related to boot process changes?
<Keybuk> Not sure, ALSA is on the list to look at this week
<Keybuk> I wouldn't immediately suspect so though
<mdz> the fact that his sound still works suggests that the device wasn't there when it ran during the boot process, but it was later
<Keybuk> which would be damned freaky
<trappist> mdz: if you're still around, it was suggested I ask you about why alsaconf was removed from alsa-utils
* lamont-work grumbles at 30046... I didn't think postfix had any interactive questions...
<desrt> 'would you like your email fried, or just lightly toasted?'
<mdz> trappist: by whom?
<pitti> infinity: ok, now all main packages use libssl 0.9.8 (on the main architectures at least, sparc needs to catch up)
<torkel> trappist: iirc it was replaced by asoundconf
<pitti> torkel: no, asoundconf does something entirely different
<pitti> trappist: ^
<torkel> pitti: ok
<pitti> desrt: WTH do you do with your postfix configuration? :)
<desrt> pitti; "fry it up good"
<pitti> desrt: ah, I see, nevermind :)
<lamont-work> pitti: nfc
<trappist> mdz: pitti
<pitti> mdz: 
<pitti> mdz: I couldn't remember the exact reason for removing alsaconf
<pitti> mdz: but I guess it's because udev/hotplug should already care for modules?
<mdz> alsaconf is no longer needed for configuring alsa
<trappist> mdz: I for one like alsaconf because it makes it easier to choose which sound card/driver I want to use, and I see a lot of support questions that would be easily solved by alsaconf without having to ask a user whether he's using kde, gnome or something else
<mdz> trappist: https://launchpad.net/products/alsa-utils/+bug/29597
<Ubugtu> malone bug 29597 in alsa-utils "alsaconf missing from alsa-utils" [Normal,Rejected]  
<trappist> mdz: fair enough
<mdz> trappist: if the original bug has been fixed (I don't know), then the only reason to keep it disabled is that it prevents bug reports which would otherwise help get it working without alsaconf
<mdz> if it's been fixed, or if someone submits a patch for it, we can weigh the relative merits of alsaconf vs. bug reports
<mdz> but for alsaconf vs. a working module loader, the latter wins
<trappist> without alsaconf, what's the preferred method of choosing from among multiple soundcards?
<pitti> trappist: System -> Settings -> Audio
<trappist> and if you don't use gnome, or a desktop environment with a similar tool?
<pitti> trappist: or, if you want a command line, set-default-soundcard
<Keybuk> Nafallo_away: ping?
<lamont-work> mdz: is there any reason that DMA shouldn't be defaulted to on on ide drives in dapper?
<mdz> lamont-work: bugs?
<mdz> lamont-work: or if the kernel doesn't think it's safe
<lamont-work> I suppose...
<lamont-work> I finally had a machine where it made enough of a difference for me to discover that it defaults to off...
<mdz> it makes a huge difference everywhere I've compared
<mdz> but these days it's enabled by default in most cases
<Mithrandir> anybody with a firewire block storage device (disk or cdrom) around?
<tepsipakki> mithrandir: yes
<tepsipakki> mithrandir: but atm not on dapper
<Mithrandir> tepsipakki: can you tell me the output of tepsipakki: can you run /lib/udev/path_id /sys/block/$nameofdevice?
<Mithrandir> uhm, obvious fix to that sentence. :-)
<tepsipakki> Mithrandir: not available on breezy :(
<tepsipakki> Mithrandir: but I'll upgrade it soon, are you in a hurry?
<Mithrandir> tepsipakki: no, no hurry.
<Mithrandir> tepsipakki: if you could tell me when you upgrade (or just boot a live cd), that'd be great.
<tepsipakki> Mithrandir: ok, I'll probably upgrade it sometime this week
<tepsipakki> Mithrandir: how recent live-cd would do?
<Mithrandir> tepsipakki: unsure when it was introduced.  Anyway, this week is just fine
<tepsipakki> ok, I'll try a daily-dvd
<Mithrandir> thanks
<Mithrandir> grr
* Mithrandir kicks the transparent proxy in the nuts
<ivoks> Keybuk: hi
<Keybuk> ivoks: hello
<ivoks> Keybuk: dhclient needs minor fix :)
<Keybuk> oh?
<ivoks> yup, it's borken
<Keybuk> ...
<ivoks> malone #30074
<Ubugtu> malone bug 30074 in knetworkconf "eth0 not started for DHCP - regression" [Normal,Unconfirmed]  http://launchpad.net/bugs/30074
<ivoks> and malone #30071
<Ubugtu> malone bug 30071 in dhcp3 "Bug in /etc/dhcp3/dhclient-script" [Major,Confirmed]  http://launchpad.net/bugs/30071
<Keybuk> already fixed
<Keybuk> and already uploaded
<ivoks> i see there is a new version
<ivoks> sorry :/
<Nafallo> Keybuk: pong
<Keybuk> Nafallo: dhcdbd has been uploaded to main now :)
<Nafallo> yea, I saw :-)
<Keybuk> also I modified it to not be setuid-root, and instead just run as a daemon
<Nafallo> something that should go upstream? :-)
<Nafallo> I just upgraded that package after thom anyway :-)
<Keybuk> it looked like that's how RedHat run it anyway
<Nafallo> :-)
<Nafallo> Keybuk: are you taking on NM next? :-)
<Nafallo> Keybuk: 0.6 will probably be out in ~2weeks :-)
<Treenaks> Nafallo: that might need some wpa-supplicant love then
* Treenaks wishes X would be fixed on ati
<Nafallo> yea, and libnl :-)
<simira> Mithrandir: ping
<Keybuk> Nafallo: yes
<Keybuk> Nafallo: I have madwifi-ng packages installed, and network-manager, and it's working so far
<Nafallo> :-)
<Nafallo> that means we finally will have NM in main? :-)
<LaserJock> doko: ping?
<Nafallo> Keybuk: that means we finally will have NM in main? :-)
<Keybuk> Nafallo: we'll see how it goes
<Nafallo> :-)
<Nafallo> fair enough
<Keybuk> Mithrandir: /lib/udev/vol_id -t /dev/hda1 .... handy
<Mithrandir> Keybuk: thanks, vely shiny
<simira> hmf
<doko> LaserJock: pong
<LaserJock> doko: I don't know if you saw (probably did) but I got tightvnc working again
<doko> yes, did see it. thanks!
<LaserJock> doko: I looked at Bjoern Brauel's source package but I think the difference in xorg versions is causing problems
<MrRio> just a quick thought, when i install themes, and then run as a root user, there is a horrible difference of themes. i usually symlink /root/.themes to my own users themes so they always match
<MrRio> is this something that would have security implications if it was implemented in some form for dapper?
<MrRio> the root user seems to default to some horrible grey gnome-default
<crimsun> that's just very, very bad practice.
<MrRio> crimsun, right, fine for someone like me, where im the only user
<MrRio> ?
<crimsun> you can do whatever you want on your own system, but I /highly/ doubt it will be implemented for Dapper due to the severe security ramifications.
<MrRio> ive set .themes to non-executable of course
<MrRio> ok, is it possible for themes to compromise security then?
<crimsun> possibly, though I'm not familiar with the innards to be able to give a solid answer
<MrRio> they just look like simple text files, and the engines require a root password to install anyway
<MrRio> looks like a glorified css-style markup
<crimsun> themes in and of themselves?
<MrRio> yes, at least the clearlooks ones do
<MrRio> ill have a look at some more
<crimsun> hmm, I've just used System> Preferences> Theme
<kent> http://www.kde-apps.org/content/pre1/34523-1.jpg   *fniss*
<MrRio> http://art.gnome.org/themes/gtk2/571   try installing this simple theme 'Glossy P' by dragging it into the theme manger like it suggests
<MrRio> all this does is takes the tar.gz and unzips into your .themes dir.
<MrRio> so when you use a root app, it now doesnt have this theme
<MrRio> and looks ugly
<MrRio> so maybe the theme manger should ask for a root password to install, and move it into root aswell
<MrRio> ?
<kent> sorry, wrong channel. :(
<crimsun> MrRio: you want to ask in #ubuntu-desktop
<cradek> hi all
<cradek> I have some packages I want to distribute by making an apt repository.
<cradek> that's all working except there is an authentication warning when someone tries to install the packages.
<cradek> can someone explain how I can sign the packages so this doesn't happen?
<MrRio> cradek: yeah, get yourself a key if you havnt already, and just sign your packages with it, i like using seahorse since it integreates right into gnome
<MrRio> you need to get people using your packages to import your key for use with apy
<MrRio> apt
<cradek> ok, I know how to sign
<cradek> it's the other part I don't know about
<cradek> how do I have them get my key?  Can they get it from the keyservers somehow?
<cradek> (I'm rusty, I have only set up gpg for email, and that was long ago)
<cradek> do I use dpkg-sig to sign?
<mgalvin> MrRio: put your themes in /usr/share/themes so that they are globally accessible
<mgalvin> this will make the theme show up the same for your account and root(sudo'd) windows
<MrRio> mgalvin: k, thanks, i still feel gnome's theme manager should do this for me
<MrRio> (if i ask)
<LaserJock> hmm, so is it me or is cups messed up right now?
<MrRio> LaserJock, you?
<cradek> is there a faq that deals with my questions about signing packages?
<MrRio> cradek, use dpkg-sig to sign your packages
<cradek> ok
<cradek> then how do my users tell their system my key is trusted?
<MrRio> cradek, they would use aptkey add
<MrRio> apt-key*
<cradek> aha
<cradek> thank you
<MisterN> n8
<MrRio> cradek: so maybe wget -O - ftp://yourserver/yourkey.gpg | apt-key add -
<MrRio> cradek, :)
<cradek> thank you
<MrRio> (forgot to mention ull need a sudo on your apt-key bit
<cradek> sure
<lamont-work> Setting up linux-image-2.6.15-14-hppa32-smp (2.6.15-14.19) ...
<lamont-work> cp: cannot stat `/etc/udev/rules.d/00-init.rules': No such file or directory
<lamont-work> neatio
<MrRio> woo
<MrRio> lamont-work, looks like a nasty
<lamont-work> dist-upgrading from breezy->dapper
<cradek> MrRio: I must still be missing something
<cradek> MrRio: apt-key list shows my key
<cradek> MrRio: dpkg-sig --verify shows GOODSIG
<cradek> MrRio: but I still get the warning when I install it
<lamont-work> sadly, apt-key list dies (as a mere mortal), while gpg < /etc/apt/trusted.gpg works just fine
<lamont-work> (mode 644 file)
#ubuntu-devel 2006-02-05
<poningru> a usability question
<poningru> do we want to put things like 'you are not the owner, so you cant change the permission of this file'
<poningru> I mean when its a family computer people will go huh?
<poningru> 'I am the owner damn it'
* poningru likes to just thiniking out loud
<poningru> think*
<MrRio> poningru: This file requires special permissions for security reasons.
<MrRio> ?
<MrRio> after all, explaining the exact purpose of permissions is going to be the most sensible
<mantiena-baltix> Kamion, good morning :)
* pitti waves to the world
* Yagisan waves to pitti
* the_world waves to pitti
* pitti hugs Treenaks and Yagisan 
<Keybuk> hmm, ok, I can see the n-m light today
<Keybuk> laptop just worked, and dealt with getting on "ubuntu" itself
<ajmitch> excellent
<pitti> \o/
<Treenaks> Keybuk: how about WPA? :)
<mjg59> Keybuk: madwifi-ng?
* pitti asks himself if we can make it work with linux-wlan-ng
* Treenaks just wants working X (ati on 3 machines: b0rked)
<mjg59> pitti: n-m, or WPA?
<Keybuk> mjg59: yeah
<mjg59> Keybuk: Rock
<Keybuk> Treenaks: I don't care about that right now ... a working n-m for the basic usecase is the first goal
<pitti> mjg59: I gave up on WPA after fiddling with that on debconf5 for an hour
<Keybuk> we'll deal with cute features later
<pitti> mjg59: n-m would be nice
<mjg59> pitti: So how does it currently fail?
<Keybuk> pitti: please test it!  install it from universe
<pitti> mjg59: I didn't touch it since some months, I tried it three times in the past and it always wrecked my networking completely
<ajmitch> latest n-m cotd is uploaded?
<Keybuk> pitti: please install it toda
<pitti> Keybuk: I'll do it today while you are in my physical range :)
<Keybuk> pitti: otherwise it'll be in main/desktop before you can stop it
<ajmitch> pitti: fyi, I've got monolithic selinux policy loaded, modularised policy is still giving me a few issues - but progress is being made :)
<mjg59> Keybuk: Anyway, it's quite nice when it's working, isn't it?
<mjg59> Keybuk: We still need to figure out how to deal with the (a) connect on boot and (b) static IP cases
<mdke> morning all
<sivang> hi all
* ajmitch is thankful that no base system changes are needed at the moment for policy to load
<Keybuk> mjg59: leave both to ifup?
<mjg59> Keybuk: In that case we probably want to add code to nm to avoid it touching interfaces with static configuration
<mjg59> Or, at least, to tell it to just up them (like netapplet did) rather than anything else
<Keybuk> mjg59: my job, today :)
<mjg59> Keybuk: Excellent
<mjg59> People - it would be massively helpful if you could test gnome-power-manager
<Treenaks> mjg59: installing [can't test from here though, will do tonight] 
<mjg59> Install it and libpam-foreground, log out, log in, run gnome-power-manager and play with it
<Treenaks> is  'fixing X bugs' planned?
<slomo> mjg59: suspend/hibernate doesn't work with g-p-m here... known problem?
<mjg59> slomo: In what way?
<fabbione> hey slomo
<slomo> mjg59: nothing happens ;)
<fabbione> slomo: did you get my fix for xine-lib?
<slomo> fabbione: yes, thanks :)
<fabbione> slomo: perfect
<fabbione> slomo: we mighht fix that in the tool chain directly
<fabbione> so you don't need to worry about that
<mjg59> slomo: Do you have libpam-foreground installed?
<slomo> mjg59: installed it now... i'll test in a few minutes... so that was the problem?
<mjg59> slomo: If you don't have that, it won't work
<slomo> mjg59: ok, thanks... well, i'll report all other bugs i notice to you :)
<mjg59> You need to log out and in for it to have any effect (alternatively, sudo touch /var/run/console/username:7
<ajmitch> mjg59: by 'stuff happening', does that include system shutdown?
<ajmitch> once I went to the power settings in preferences
<mjg59> ajmitch: ?
<ajmitch> mjg59: it was a surprise to me as well
<mjg59> ajmitch: Uhm. "Stuff happening"?
<mjg59> ajmitch: No, that certainly shouldn't happen
<ajmitch> mjg59: sorry, I installed both those, touched that file, went to the power settings in preferences
<ajmitch> and it started shutting down - I'm fairly sure I didn't accidentally hit something
<mjg59> Which preferences?
<ajmitch> waiting for fsck to finish now (30 mounts)
<ajmitch> power management
<slomo> mjg59: works fine, thanks
<mjg59> slomo: Cool
<ajmitch> under system->preferences
<mjg59> ajmitch: System/preferences/power management ?
<mjg59> Right
<mjg59> No, there's no code in g-p-m to do that
<mjg59> It never requests a shutdown
<ajmitch> I didn't think it would
<ajmitch> so it must have been something else I did
<mjg59> Why does inkscape look nothing like any other gtk apps?
<ajmitch> maybe even hitting the power button, it's in an annoying place
<mjg59> The icons are all tiny
<mjg59> And the toolbars are draggable even though I've got that switched off
<Keybuk> ...anyone got a usb-2 cable in here?
<Mithrandir> Keybuk: usb2-to-?
<Keybuk> standard mini plug
<ajmitch> mjg59: ok, I went to the preferences again & it's shutting down
<ajmitch> so it wasn't a fluke
<Treenaks> mjg59: file bugs :)
<Treenaks> mjg59: (re: inkscape)
<mjg59> ajmitch: Hrngle rrck.
<ajmitch> one could say that
<hunger> Keybuk: I think my USB HD has one... shall I test something?
<mjg59> ajmitch: Can you do strace -o ~/g-p-m.out gnome-power-preferences from a terminal and then stick the output somewhere?
* sivang hugs jbailey for #28640
<sivang> my evo and game are back :)
<Mithrandir> hunger: I think he needed it for his camera.  I just borrowed him one
<ajmitch> sure, just trying to boot
<Keybuk> hunger: was directed at those physically in the same room as me :)  I'm too lazy to go to my hotel room for one :p
<mjg59> ajmitch: Thanks
<hunger> Mithrandir: I suspected something like that but still wanted to offer the limited service I can:-)
<hunger> Keybuk: Tried asking around in the real world? ;-)
<Keybuk> hunger: in the middle of the talk, it'd be rude :)
<hunger> Keybuk: I remember once having a chat with 3 guys while I was at an trade show... I told them that I had to run since I was on a trade show and wanted to catch a talk. We discovered at that time that all 4 of us were sitting on the same table in the cafe:-)
<ajmitch> mjg59: bad news is that it only shuts down when run from system->preferences
<hunger> Ahhh... the wonders of IRC;-)
<ajmitch> within a second of starting it
<mjg59> ajmitch: Christ. Fuck knows.
<mjg59> ajmitch: Running it without strace still doesn't trigger it?
<Keybuk> hmm, battery on this thing sucks
<ajmitch> I'll try that next
<mjg59> ajmitch: By shuts down, it powers down gracefully or it hard powers off?
<ajmitch> yeah, it triggers it, getting the 'going down for halt' message 
<ajmitch> graceful stop
<mjg59> ajmitch: But not under strace?
<mjg59> Hnngh.
<ajmitch> I saw I had sudo in there with strace, removing that now
<mjg59> Ah
<mjg59> Yeah, it'd behave differently with sudo
<ajmitch> good thing bootup is fast now
<mjg59> non-DSDT sleep keys won't currently work in g-p-m (this means Toshibas, Sonys, Panasonics and IBMs won't work quite as expected) yet. This will be fixed once I've sorted the final approach with hal upstream.
<Mithrandir> seb128: gnome-games-data takes _forever_ to install due to gconftool-2 --makefile-install-rule taking forever.
<seb128> yeah, I know, not a lot we can do :/
<Mithrandir> can't gconftool-2 take more than one argument?  I guess that could speed it up somewhat?
<ogra> Mithrandir, you didnt upgrade gnome-applets-data yet 
<seb128> applets or games are quite the same
<seb128> Mithrandir: yeah, I was looking on that just before the sprint
<Treenaks> ogra: it's still quite fast on my dual 3 GHz Xeon though ;)
<seb128> seems that we can do it twice faster by changing gconf-schemas, I need to try some stuff and bug Josselin (who did it for Debian) about it
<ajmitch> mjg59: http://tiber.tauware.de/~ajmitch/gpm2.out.gz
<mpt_> mdz or seb128 or dholbach or whoever: Would you be okay with using "Critical" severity in Malone to track Blocker bugs, or would you want a separate "Blocker" value?
<mpt_> as in, release blockers
<seb128> severity is enough imho
<seb128> if it's easy enough to list all the bugs with that setting and the dapper milestone
<mpt_> yes, I'm asking about the *values* of severity
<mpt_> Currently severity has ... Normal, Major, Critical
<mpt_> Do you need a Blocker on top of that?
<mpt_> ... Normal, Major, Critical, Blocker
<Mithrandir> can you give an example of a critical bug which is not a blocker?
<Kamion> I don't see a particular need for a separate Blocker
<mpt_> ok, me neither
<mpt_> but I couldn't tell if they were distinguished in Bugzilla, because I can't do reports in Bugzilla any more :-)
<mjg59> ajmitch: Weird. I can't find any reason for that to happen.
<mjg59> ajmitch: For some reason, gnome-power-preferences seems to crash
<mjg59> ajmitch: If you move /usr/share/scripts/hal-system-power-shutdown somewhere else, what does it do?
<ajmitch> it doesn't shutdown or appear to crash 
<ajmitch> though I get a few warnings on the terminal
<ajmitch> ** (gnome-power-preferences:5717): WARNING **: Couldn't connect to PowerManager Process /usr/bin/gnome-power-manager exited with status 0
<Keybuk> so ... what's a good video editor?
<Keybuk> need to be able to open files, convert them, maybe cut them and add captions
<ajmitch> mjg59: I suspect it's related to my laptop showing 0% battery, even when on AC
<mjg59> ajmitch: Ah. Possible.
<Treenaks> ajmitch: broken dsdt?
<ajmitch> Treenaks: acer
<Treenaks> ajmitch: ah.. I know that problem
<mjg59> ajmitch: Yeah, that'd be it. Right, it needs to be more resiliant to that.
<mjg59> ajmitch: Even though we should have your machine fixed...
<Treenaks> BenC: (the acpi-ec in the kernel isn't acpi-ec-i2c, so I still can't read battery status, btw)
<mjg59> Treenaks: ?
<ajmitch> mjg59: I didn't see that patch in the changelog
<mjg59> ajmitch: No, it's not in yet
<Treenaks> mjg59: my Acer laptop has a buggy DSDT
<mjg59> Treenaks: Uhm. What does that have to do with acpi-ec?
<Treenaks> mjg59: or a perfectly OK one, actually.. as long as you have a driver to read battery status over I2C
<mjg59> Treenaks: The acpi-ec driver in the kernel should be the one you need for the smart battery driver to work
<Treenaks> mjg59: I can read battery status over I2C from my ACPI EC device
<mjg59> Treenaks: You can, or in theory you can?
<Treenaks> mjg59: I could, in Debian using a self-compiled-and-patched kernel using lmsensors
<Treenaks> mjg59: I can't, in current dapper
<Treenaks> mjg59: with stock kernel
<mjg59> Treenaks: Right, so it's a smart battery
<Treenaks> mjg59: yes
<mjg59> That /ought/ to be fixed for dapper
<mjg59> But isn't yet
<mjg59> I have no test hardware, so it's a pain
<mjg59> I'll push a patch to Ben
<Treenaks> mjg59: I do, just shout on IRC if you need testing
<ajmitch> Treenaks: and I thought I did, but I don't :)
<mdz> mpt_: the existing severities are sufficient for me
<mpt_> mdz, thanks
<fabbione> siretart: ping?
<mantiena-baltix> Kamion, ping
<Kamion> mantiena-baltix: I asked you to mail me; please stop pinging me on IRC
<mantiena-baltix> Kamion, ok, but if you can, ten please tell me where is changed (set) value of grub-installer/bootdev debconf setting, which is used in grub-installer script (espresso-grub package)  :)
<Kamion> PLEASE MAIL ME
<Kamion> thank you :)
<mantiena-baltix> Kamion, no problem, I know how to copy/paste from Xchat to mutt ;)
<Kamion> when you're requesting help from somebody, please in future respect the communications method they ask for
<mantiena-baltix> Kamion, ok, no problems for me, I just think, that if you are not bussy, then maybe for you and me would be to talk here ;)
<Kamion> I am busy.
<Kamion> I've told you this multiple times and you've just been obnoxious.
<Kamion> please, please stop it.
<mantiena-baltix> Kamion, I don't wanna be obnoxious, sorry if I make you any troubles
<segfault> weird, the packages python-twisted python2.3-twisted python2.4-twisted, are in loop. every time i upgrade them, they appear as upgradable again. can anyone confirm this?
<Treenaks> segfault: had this yesterday
<Treenaks> segfault: apt-get --purge remove + apt-get install fixed
<segfault> treenaks: thanks, will do that
<siretart> fabbione: pong
<fabbione> siretart: people.fabbione.net/~fabbione/xine.diff
<fabbione> it's already uploaded, but you have the diff in the meanwhile
<fabbione> in theory you should run autoreconf
<fabbione> but it was spitting errors to me
<fabbione> so i did propagate the changes to configure.ac to configure manually
<fabbione> siretart: slomo did logout too fast this morning for me to give him the patch :)
<pitti> hey carlos 
<carlos> pitti: hi
<siretart> fabbione: thanks :)
<fabbione> siretart: no pro
<fabbione> the bug was upstream tho.
<fabbione> they didn't merge all the changes from David miller
<siretart> I'll add that to our xine svn, no problem
<hunger> segfault: There are bugs open about this issue.
<Keybuk> hmm, who knows about ogg theora?
<Treenaks> Keybuk: a bit..
<Yagisan> Keybuk: in what way ?
<Keybuk> I have a $RANDOM_MPEG and want to convert it into a smaller ogg for distributing
<Treenaks> Keybuk: ffmpeg2theora
<Keybuk> and don't know how, trying to brutalise ffmpeg doesn't seem to be working
<Yagisan> Keybuk: mencoder + theora support ??
<Keybuk> Treenaks: where would I find that?
<hunger> Treenaks: purging and reinstalling python-twisted does not make the issue go away for me.
<Treenaks> Keybuk: there is/was a package in debian, but that's very outdated
<Keybuk> ffmpeg -formats claims vorbis and theora
<Keybuk> Output #0, ogg, to 'test.ogg':
<Keybuk>   Stream #0.0: Video: 0x0000, yuv420p, 720x576, 25.00 fps, q=2-31, 200 kb/s
<Keybuk>   Stream #0.1: Audio: vorbis, 48000 Hz, stereo, 64 kb/s
<Keybuk> Unsupported codec for output stream #0.0
<Keybuk> zsh: exit 1     ffmpeg -i MOV002.MOD -f ogg -vcodec theora test.ogg
<Keybuk> is my current progress
<Treenaks> Keybuk: http://www.v2v.cc/~j/ffmpeg2theora/
<Keybuk> Treenaks: ok, that seems to be working
<Treenaks> Keybuk: it's used by kino (but not packaged properly :(
<Kinnison> Does anyone else find theora unbearably slow?
<Kinnison> Our amd64 box, with optimised libtheora can't manage more than a few frames per second
<Kinnison> (PAL size video)
<Treenaks> Kinnison: Playing theora files is a bit slow on older computers for me
<Treenaks> Kinnison: it works fine on everything >1GHz (ish) for me
<Kinnison> Treenaks: it was more the encoding than the playback I was complaining about
<Treenaks> Kinnison: oh that.. yeah, encoding a 2-hour video takes 6 hours on my 2GHz machine
<Keybuk> Kinnison: running dapper or breezy?
<Yagisan> Kinnison: guess you haven tried h264/mpeg4 part 10 encoding then ;)
<Yagisan> s/haven/haven't
<Kinnison> Keybuk: breezy, amd64, with self-built theora codecs using all the right optimisation flags
<Kinnison> Yagisan: pardon?
<Treenaks> Kinnison: ooh, on gentoo? :)
* Kinnison looks at Treenaks confusedly
<fabbione> [Tue Jan 31 13:10:31 2006]  [notice]  Apache/2.2.0 (Ubuntu) configured -- resuming normal operations
<StevenK> fabbione: Fear.
<Yagisan> Kinnison: theora is much faster compared to eg x264 and co
<mjr> theora isn't that optimized indeed; one would hope that a fraction of the work going towards tuning free implementations of patent-encumbered codecs would go towards theora instead, but such is life
<Treenaks> Kinnison: www.funroll-loops.org --> hand-optimized is l33t!!!
<Kinnison> Treenaks: Don't accuse me of being a ricer or I'll delete your launchpad account
<Kinnison> </hollow-and-pointless-threat>
<StevenK> Muahaha
<mvo> Kinnison: is their theora-mmx branch useful?
<StevenK> Kinnison: How about we accuse you of being a Gentoo user instead?
<StevenK> Is that better?
<Kinnison> mvo: Umm, I don't think so
* Kinnison blanks StevenK 
<StevenK> Awww.
<Yagisan> StevenK: there's a difference ?? I never knew that
<StevenK> Bwahaha
<StevenK> Yagisan: Gentoo users are slightly more fanaticial ...
<Yagisan> StevenK: yep. Must never tell them that on the p4 systems, they may get better performance with -OS rather then -O3 due to their puny caches. "hey lets unroll the loops so that they can't fit into the cache and can force mass cache evictions"
<StevenK> Let's see if burning a DVD is acceptably fast now that DMA is actually turned on.
* StevenK grins at Yagisan.
<StevenK> Yagisan: I suspect most of them think that mass cache evictions only happen on Big Brother.
<Yagisan> StevenK: my eyes! they are burning !!
<Treenaks> /quit brb, cache eviction
* Yagisan rips his eyes out. Gentoo + Big Brother - the apocalypse is here !!
* StevenK cackles.
* StevenK buggers off to bed.
<Yagisan> Night StevenK
<drag_behind> hey anyone awake?
<drag_behind> well I just had a bad problem with a dapper upgrade but I cant be bothered joining the forums
<drag_behind> so just thought Id say here that when upgrading it activated pcmcia services
<drag_behind> which hung my machine
<drag_behind> and kept breaking the booting
<Yagisan> drag_behind: might be a good idea to report the bug at launchpad
<drag_behind> where is that?
<Yagisan> drag_behind: http://www.launchpad.net
<drag_behind> ok will do
<fabbione> mjg59: Jan 30 10:06:30 localhost su[10251] : PAM unable to dlopen(/lib/security/pam_fore
<fabbione> ground.so)
<fabbione> Jan 30 10:06:30 localhost su[10251] : PAM adding faulty module: /lib/security/pam
<fabbione> _foreground.so
<fabbione> Jan 30 10:06:31 localhost PAM-env[10251] : Unable to open config file: No such fi
<fabbione> le or directory
<mjg59> fabbione: Yup?
<mjg59> If you don't have libpam-foreground installed, that's fairly reasonable
<fabbione> mjg59: MEH
<mjg59> fabbione: What do you expect it to do?
<Menoz> hi all, I have a problem with ubuntu customization, can someone help me?
<fabbione> i don't expect standard pam in main to try to use something that is not there by default
<lucas> hi
<mjg59> fabbione: It will be there by default
<mjg59> You just get some log spew for now. Nothing is broken
<lucas> I remember some ubuntu devs talking about an archive where one could find old versions of packages. like: I'm working on merging 1.0-3ubuntu1 and 1.0-4, but 1.0-3 is no longer in Debian.
<lucas> snapshots.d.n clearly doesn't have all versions
<lucas> what's the name of this archive ? how do I get access to it ?
<seb128> lucas: it was snapshots but their disk had issues some months ago and they started from scrash again or something like that
<lucas> I thought ubuntu had its own archive of this kind
<seb128> no
<seb128> Ubuntu has his packages but not the Debian packages we didn't ship
<seb128> s/his/its
<lucas> mmh, I'm interested in working on this, since it's a requirement for easier collaboration with debian
<lucas> (scott's patches sucks when it diffs between very different debian versions)
<Kamion> I suppose if you had another machine with lots and lots of terabytes of disk you could try to duplicate snapshot.d.n
<segfault> can anyone please build mozilla-thunderbird-enigmail for 1.5? :)
<Kamion> seems a bit pointless, but up to you
<Kamion> (since you could just as easily have disk issues ...)
<ajmitch> Kamion: depends if those old versions still lived somewhere, I guess
<lucas> Kaloz: you don't need to keep all old versions
<lucas> Kamion sorry
<lucas> just the one which are potentially useful for ubuntu developers
<hunger> Cool the python-twisted reinstall bug is gone with the newest version.
* hunger closed the bug.
<Kamion> hunger: yeah, we discussed it here and established the cause
<Kamion> 0: epochs bad
<hunger> Kamion: Great! Thanks for fixing this really annoying issue.
<Kamion> wasn't me :)
<Keybuk> lucas: yes, blame elmo for the morgue of love lacking the intermediate versions
<hunger> Kamion: Well, doko is not around afaict.
<lucas> Keybuk: how can I help fix this ? :-)
<Keybuk> lucas: i'm not sure you can
<Keybuk> I don't really understand why the morgue lacks them
<herzi> seb128: can you take a quick look at 30147, this one is really ugly
<lucas> mmh, can I raise the issue at TB meeting tonight ?
<Kamion> if you don't have shell access to spohr.debian.org, it's probably unlikely that you'd be able to help
<Keybuk> there's no TB decision to made, is there?
<stub>  Launchpad is going down in 20 minutes, which will put the wikis into read only mode as well. Estimated down time is 10 minutes. This is for the regular weekly code and database update.
<Kamion> lucas: it's a Debian ftpmaster issue surely, not Ubuntu TB
<Mez> mdz/Kamion ping
<Kamion> Mez: hm?
<Keybuk> lucas: if you have a multi-terabyte disk array, and gargantuan amounts of bandwidth, and can build your own equivalent to snapshot.debian.net ... then that would be useful ;)
<lucas> Kamion,Keybuk: couldn't Ubuntu have its own archive of "potentially useful" packages ?
<Kamion> lucas: not retrospectively, no
<lucas> we don't need that much space
<Keybuk> *choke*gasp*
<Keybuk> yes, we do
<Mez> Kamion: wondering if I can get an OK to sync the latest rar package from debian - contravenes the UVF - but fixes a couple of vulnerabilities in the code
<lucas> current_size_of_source_archives * 2 is enough in the worst case
<Keybuk> no, it's not
<seb128> herzi: ask to ogra, he maintains that theme
<lucas> * 3 maybe
<Keybuk> you need the entire history of source for at least the past year
<herzi> ogra: can you take a quick look at 30147?
<Keybuk> though you could opportunistically cull that
<lucas> Keybuk: you only need versions on which ubuntu versions are based
* ogra looks
<seb128> herzi: and the package source is gnome-icon-theme-gartoon
<Kamion> Mez: UVF exceptions for universe/multiverse go through dholbach rather than being sent to us directly
<herzi> seb128: it's not
<Mez> o_o
<herzi> there are only two sources called gnome-icon-theme*
<seb128> herzi: gartoon
<herzi> maybe then
<dholbach> Mez: read ubuntu-motu@
<seb128> $ apt-cache showsrc gartoon
<seb128> Package: gartoon
<seb128> Binary: gnome-icon-theme-gartoon
<Mez> Kamion: oh poop - sorry got mixed up - thought it was in restricted :D
<Kamion> very little is in restricted
<Mez> Kamion: apologies - slightly confused
<Kamion> ~np
<lucas> what's the current size of the sources archive ?
<lucas> (for one version)
<ogra> herzi, will fix that during the day, seems trivial
<Kamion> lucas: I think it's 13GB for dapper, although I may have done the sums wrong
<lucas> ok, thanks
<lucas> so it's not _that_ big
<Kamion> that's just from zcat ftp/dists/dapper/*/source/Sources.gz and a couple of nasty greps and awks
<herzi> i have an infinite loop in an init script, what's the appropriate severity for a bug report?
<herzi> critical?
<Diziet> Try   date -d 'next month'
<lucas> I've added this as a TB item, saying I'm willing to work on this if ubuntu can provide some disk space somewhere
<lucas> off to a meeting now
<dooglus> in dapper, almost all of the x.org graphic drivers and input drivers are uninstalled by default.  which ones do I need to install?
<dooglus> sorry, wrong channel.
<Keybuk> mjg59: what do I need to touch to avoid logging out?
<mjg59> Keybuk: /var/run/console/username:vt
<mjg59> So /var/run/console/keybuk:7 or whatever
<Keybuk> that exists already
<Keybuk> weird
<mjg59> Implies that you had it installed already
<Keybuk> nope
<Keybuk> weird
<Keybuk> I must have done something that caused it to be created
<pitti> Keybuk: I could circumvent the kernel oops which killed my keyboard :)
<jsgotangco> hiya mako__ 
<Keybuk> pitti: oh?
<zul> hey jeff
<jbailey> Heya Chuck1
<sivang> jbailey: thanks for fixing #28640 =)
<jbailey> bug 28640
<Ubugtu> malone bug 28640 in glibc "libc6 crash on certain UTF8 encoded filename" [Major,Fix released]  http://launchpad.net/bugs/28640
<jbailey> sivang: Does the fix work for you?
<sivang> jbailey: wonderfully :) I got my gaim and evo back 
<sivang> jbailey: couldn't use them before.
<jbailey> Cool, thanks
<mdke> hey dholbach 
<dholbach> hey mdke
<mdke> dholbach, what time are you around this evening?
<Mithrandir> mdke: I hear rumours of you coming to visit us?
<jsgotangco> ouch a lawyer will be visiting that's bad
<dholbach> mdke: I should be around the whole evening. :)
* jsgotangco hides
<dholbach> haha
<mdke> Mithrandir, i hope so
<Mithrandir> mdke: \o/
<mdke> i just don't wanna turn up while you're all at dinner or something
<Mithrandir> we're eating at around 1930-ish, iirc
<mdke> ah hrm
<mdke> i'll be off work at 6, I'll go home, eat and then aim to turn up after that then I think
<dholbach> Cool.
<Keybuk> Nafallo, mjg59: so far we have n-m success with ipw, madwifi-ng, bcm43xx and prism54
<Keybuk> and failure with linux-wlan-ng, gem, airo, and whatever mvo's dodgy one is
<Lathiat> do we have the scanning patch for orinoco in?
<Keybuk> might have been an orinoco
<Lathiat> thats a very common card (at least around here)
<Keybuk> "scanning patch" ?
<Lathiat> Keybuk: that allows for iwlist scan 
<Lathiat> its not in the kernel
<Lathiat> at least not up to a bit back
<Lathiat> dunno if it was merged recently
* Lathiat tries
<Keybuk> if not, bug BenC
<Keybuk> I think I may add some code to n-m to make it only show interfaces it's known to work with
<zul> no scanning patch if i remmeber clearly
<mdke> are you looking for dodgy wifi cards? i have a dodgy acx111 I could bring along
<mjg59> Keybuk: There's an airo patch on the n-m mailing list
<mjg59> What's gem?
<Lathiat> http://bur.st/~lathiat/wlan.png 
<Kinnison> Keybuk: so long as that can be overridden in a config file
<mjg59> Oh, the wired?
<Kinnison> Keybuk: I.E. if I know my <foo> card is supported even though n-m doesn't think it is, I can tell it without recompilation
<Lathiat> interesting
<Lathiat> the eth2 card sems to show all the essids i've used in the past while
<Lathiat> i assume thats an intended feature
<Lathiat> (since it can't scan, list those you used previously with a manual connect, i guess?)
<Keybuk> mjg59: something fabbione has
<mjg59> Keybuk: Wired ethernet, right?
<Keybuk> Kinnison: if I can be bothered :p
<Kinnison> Keybuk: :-(
<Keybuk> mjg59: possibly, I wasn't paying attention
<Kinnison> Keybuk: maybe I'll actually get to distro in time to hack on it too
<Keybuk> I was figuring lathiat's kind of thing
<Kinnison> although the way that G-d is behaving I don't hold out much hope
<Keybuk> "g-d" ?
<Kinnison> right in the middle of critical testing, he smote the production librarian
<Keybuk> Kinnison: oh, you realise if you join the distro team, you're going to get X :)
<Keybuk> EXTREMELY BAD TIMING :p
<Kinnison> Keybuk: I am going to do my best to wear teflon shoulderpads wrt. X
<Kinnison> I refuse to give sabdfl even more ammunition for justifying his confusion of me and daniels back at the start
<Keybuk> you realise that'd also reduce the launchpad's "gay/bi" quotient to zero
<Lathiat> ok so orinoco is supported in dapper
<Lathiat> in a wave of unthinkingness i tested it on my breezy laptop :)
<Lathiat> works good on dapper
<Keybuk> that was like Kamion who did an "oh, I've been accidentally using my Broadcom all day, it works!"
<ogra> lucky Kamion then ... mine onnly works partially
<Kinnison> Keybuk: Hmm
<ogra> Lathiat, the scanning patch was in, it somehow stopped working with one of the last kernel upgrades ...
* Kinnison attempts to play the launchpad game, in order to confirm that
<Lathiat> ogra: works for me here on latest kernel
<ogra> iwlist scan ?
<Lathiat> i just did a round of dist-upgrades tho (not including kernel)
<Lathiat> i'll reboot and test
<Lathiat> ogra: yep, and nm
<ogra> it worked two weeks ago, but downt now ... i didnt follow it very closely though
<ogra> *doesnt
<Lathiat> what kind of card have you got?
<Kinnison> Keybuk: You know, I think you're right. Or at least it reduces the out gay/bi quotient to zero. Not so sure about the closet :-)
<Lathiat> like a pcmcia orinoco, or an airport or?
<ogra> Lathiat, a lucent orinoco silver ...
<ogra> pcmcia
<Lathiat> ok, same card i've got
<Lathiat> potentially different firmwares tho
<ogra> might be, i never touched it ...
<Lathiat> tho i've never heard of any issues at all with scanning and firmwares
<ogra> (i know yu can patch it with the gold firmware)
<wasabi_> Let the speculation begin!
<wasabi_> "The Register reports that Google is working on a version of Ubuntu, known internally as Goobuntu. Google has confirmed it is working on a desktop linux project, but declined to supply further details, including what the project is for. Is Google about to release this as an alternative to Windows?"
<Lathiat> ogra: not even that, just the actual version of the intended firmware
<ogra> to get strong encryption working ...
<Lathiat> wasabi_: did you read about google os last week too? ;)
<Lathiat> ogra: well,yeh
<Lathiat> ogra: that was a pretty cool hack
<Keybuk> wasabi: more like Never Let Research Or Facts Stand In The Way Of El Reg's Quest For A Story
<wasabi_> No, just heard about "ie"
<Lathiat> and its not strong, just 'stronger' :)
<wasabi_> "it"
<Lathiat> i was reading APC mag today and read about google os
<wasabi_> Keybuk: oh I know. I'm just fishing. ;)
<Lathiat> and wanted to shoot myself :)
<Lathiat> (APC mag being a computer mag in .au)
<wasabi_> I'd be nice if google just hired some engineers and sent them here.
<Lathiat> mildly more technical nature than some of the others
<mjg59> The fact that Google have a project called Goobuntu doesn't indicate that they're planning on releasing it as a product...
* Lathiat wonders why a dist-upgrade is holding back kmail, yet apt-get install kmail simply remoes libmimelib1c2 and installs libmimelib1c2a and upgrades kmail
<Keybuk> http://people.ubuntu.com/~scott/20060131_language-packs_pitti.ogg
<wasabi_> I woldn't be suprised if they were just working on a flavor for internal desktops.
<Keybuk> ^ could people let me know whether that's watchable; in particular the audio
<mjg59> wasabi_: That's pretty much what the situation is
<Lathiat> wasabi_: pretty much aiui
<Kinnison> Keybuk: fetching
<mjg59> Keybuk: Works fine in totem
<Keybuk> yeah, mostly whether it's loud enough :)
<mjg59> Seems ok
<Lathiat> could do with a slightly better res
<Lathiat> since we're looking at a whiteboard and not just a person
<Keybuk> Lathiat: we could do with better upstream bandwidth :p
<mjg59> Yeah, picture quality is poor
<wasabi_> I really think that link itself hilights a problem. =(
<Keybuk> the original is DVD quality, but to get it from my camera to somewhere servable is hard on 250kb/s
<wasabi_> I should be able to click on it in XChat and Totem should open and stream it. Heh.
<Lathiat> Keybuk: surely even a 25M video would be ok 
<Lathiat> heh faces<->irc, weird :)
<Keybuk> Lathiat: that would require slightly more finesse on theora conversions than I am capable of :)
<Keybuk> if you know runes, let me have them and I can recode
<Lathiat> sounds complicated ;p
<Lathiat> so, anyon got any ideas on above kmail/apt situation?
<Lathiat> there is 1 other package (unrelated) being held back due to missing dep (gnome-system-monitor dep missing gksu) - don tsee why thatd be confusing it tho
<wasabi_> darnit that .ogg froze totem
<wasabi_> hmm. actually it looks like Open Location... itself freezes totem
<jbailey> mjg59: Apparently you want us to all run gnome-power-manager.  Now that I'm doing so, is there anything you want from me?
<mjg59> jbailey: Does it work?
<jbailey> mjg59: It appears to have a number of menus.  Is there something about it in particular I should try?
<mjg59> jbailey: You have battery status?
<mjg59> Does hibernate work on your machine? If so, does it work when you trigger it from g-p-m?
<jbailey> It's got a power cord wrapper around a battery that's full right now, which is true.
<jbailey> Lemme flip to battery to test the difference.
<jbailey> It took a bit longer than the regular applet to notice that I'm on battery, but that's probably just polling cycle.
<Lathiat> IIRC by default GNOME disables the reboot/shutdown options
<jbailey> I haven't tried hibernate yet.  suspend doesn't work.
<Lathiat> if its not running under gdm
<Lathiat> that doesnt happen with the new stuff
<jbailey> on this laptop, I mean.
* jbailey tries hibernate.
<Kinnison> Keybuk: the sound is fine
<Kinnison> Keybuk: the video is a touch low bitrate
<Keybuk> Kinnison: yeah, the video suffers simply from I have to upload it
<Keybuk> so I made it small enough to do that
* Kinnison nods
* Kinnison listens to this because he needs to know about how langpacks work
<jbailey> mjg59: Clikcing on "Hibernation" (fr_CA) causes my network manager to lose sync with the network, but nothing else seems to happen.
<jbailey> mjg59: Does it put a log file somewhere that I can see what it thinks it was meant to do?
<mjg59> jbailey: You have /var/run/console/jbailey:7 or whatever?
<Keybuk> Kinnison: the original would just fit on a CD
<Kinnison> Keybuk: how long was the talk?
<jbailey> mjg59: I have nothing under /var/run that begins with "console" or "jbailey"
<mjg59> jbailey: So when I said "Install libpam-foreground, log out, log in", that bit wasn't communciated? :)
<mjg59> BenC: I've sent you a patch to add rtl stuff
<jbailey> mjg59: Correct, was not. =)
<BenC> ok, thanks
<jbailey> mjg59: Battery status seems to be more aggresively updated that the standard gnome battery.
<jbailey> But otherwise both show as 94%
<mjg59> jbailey: Ok, for now mkdir /var/run/console and then touch that file (assuming jbailey is your username and you're on vt 7)
<Keybuk> Kinnison: 15-20mins ish
<Kinnison> Keybuk: Hmm, videocd quality should be ca. 300 megs then
<Keybuk> Kinnison: dunno, it's standard DVD 16:9 MPEG-2 off the camear
<Keybuk> AC3 audio
<jbailey> mjg59: Installed the package (should it be a dependancy?)
<jbailey> I've touched the file as root.;
<Kinnison> Keybuk: hmm
<mjg59> jbailey: It'll be part of desktop
<jbailey> Cool.
<mjg59> BenC: Somebody probably needs to find out if we can distribute the Marvell wireless firmware
<BenC> mjg59: hell, still working on the bcm43xx firmware :/
<mjg59> BenC: Heh. The Marvell stuff is probably easier.
<mjg59> BenC: Also, must push you an updated driver for the sdhci stuff
<BenC> ok
<mjg59> It's /almost/ working perfectly here now - I'm just not getting all eject/inserts
<Kamion> BenC: Theo had no luck with that either :(
<Kamion> BenC: (bcm43xx working great for me now, btw)
<BenC> I think we may have a chance
<simira> who chased Mithrandir away? :-/
<Kamion> mjg59: can I have a preference for "don't tell me when I switch to battery"?
<Kamion> mjg59: also it would be nice if it were clear whether "Put ... to sleep after" is "after x minutes of inactivity" or just "after x minutes"
<Keybuk> "You have just had an accident..." "YES, I KNOW!"
<mdz> mjg59: what is the failure mode for swsusp like if it doesn't have enough swap?
<mjg59> Kamion: Pls file bugs kthxbi
<mjg59> Kamion: (Yeah, the UI is a bit rough)
<mjg59> mdz: It should just bounce back
<mdz> I was having inexplicable swsusp failures last week where it would hang on the way down, but it's working OK this week oddly enough
<mjg59> pitti: mmc cards still don't seem to be getting automounted
<mjg59> pitti: "Error: device /dev/mmcblk0p1 is not removable
<mjg59> Keybuk: We have two drivers for sd readers (sdhci and wbsd). Both of them need mmc_block to be loaded beforehand in order to be useful.
<Keybuk> mjg59: then they should both depend on it, no?
<Keybuk> sdhci depends mmc_core
<mjg59> Keybuk: No - they don't actually call any functions from it
<Keybuk> wbsd depends mmc_core
<Keybuk> I see
<mjg59> Yeah
<mjg59> But you need mmc_block to actually get a block device
<Keybuk> so the mmc subsystem should generate a MODALIAS that matches an alias that the mmc_block declares support for
<Keybuk> (we have the same with i2o_block at the moment)
<mjg59> I don't really care how it's fixed, but it would be nice if it was fixed :)
<Keybuk> file a bug
<Keybuk> assign it to kernel, and subscribe me
<mjg59> Ok
<Keybuk> mjg59: do you have a machine with this in there right now?
<mjg59> Keybuk: Yup
<Keybuk> and without mmc_block loaded?
<mjg59> Keybuk: I can unload mmc_block if you want 
<mjg59> On boot, sdhci gets loaded, mmc_block doesn't
<Keybuk> is there a /proc/bus kind of stuff?
<Keybuk> mjg59: right, there's nothing to say "load mmc_block"
<mjg59> No, nothing in /proc/bus
<Keybuk> /proc/mmc ?
<mjg59> No mention of mmc in /proc
<mjg59> There's a /sys/bus/mmc
<Keybuk> /sys/bus/mmc ?
<Keybuk> right
<mjg59> And a sys/class/mmc_host
<Kamion> mjg59: filed
<Keybuk> what's in that
<Keybuk> a single devices?
<mjg59> sys/bus/mmc contains drivers and devices
<Keybuk> yeah, how many devices?
<mjg59> devices is empty
<Keybuk> *blink*
<mjg59> As is drivers
<mjg59> If I load mmc_block, drivers gains mmcblk
<Keybuk> can you rip all the modules out, and run "udevplug" again
<Keybuk> are you sure you have an mmc device plugged in? :)
<mjg59> I've just been reading off it
<jbailey> mjg59: Even after I touched that file, I didn't actually do it.  I'll try a log out and back in to make sure that it's not something I did wrongly.
<Keybuk> mjg59: ok, unplug it -- rip out all the modules, then run "udevmonitor -e" and plug it back in
<mjg59>  /sys/bus/mmc seems to only contain stuff when mmc_block is loaded
<mjg59> Keybuk: It's a built-in PCI device
<jbailey> When I plug in the power cord again, the battery now looks shattered with a power cord around it.
<Keybuk> did mmc_block create anything in /sys/bus/mmc/devices ?
<Kamion> mjg59: otherwise, g-p-m seems to work fine for me
<mjg59> jbailey: That's supposed to be a lightning bolt
<mjg59> Keybuk: Without a card in, no
<mjg59> Keybuk: With a card in, yes
<Kamion> mjg59: suspend works, hibernate doesn't, but that's no surprise (powerbook)
<Keybuk> ah
<jbailey> mjg59: Yes, dear. =)
<Keybuk> is there anything in /devices *with a card in* when mmc_block is *not* loaded?
<mjg59> Keybuk: No
<mjg59> Keybuk: Oh, I tell a lie - yes
<mjg59> lrwxrwxrwx 1 root root 0 2006-01-31 17:17 mmc0:0001 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:00.1/mmc0:0001
<Keybuk> *beats you*
<Keybuk> right
<Keybuk> now what's in that?
<mjg59> bus  cid  csd  date  fwrev  hwrev  manfid  name  oemid  power  serial  uevent
<Keybuk> readlink bus ... and cat everything else but uevent
<mjg59> ../../../../../bus/mmc
<mjg59> Keybuk: None of the files look terribly interesting - just seems to be information about the card
<Keybuk> right
<Keybuk> and nothing in /proc for mmc at all?
<mjg59> Correct
<Keybuk> see, nothing tells us to load mmc_block
<Keybuk> I bet there's not even a char-major for it
<mjg59> It seems to end up with 253
<mjg59> Which is dynamic, presumably?
<mdke> does anyone know if gnome-app-install will be capable of installing any program in the repository, or is it limited to only some programs still?
<Keybuk> mjg59: indeed
<Keybuk> mjg59: so, this is clearly a kernel bug
<LaserJock> mdke: doesn't it have an advanced button or something (I can't remember right now) that launches synaptic?
<Keybuk> "oh that device doesn't work unless you load *this* module?" "and how was I supposed to know to do that?!"($*(UASFJA"
<mdke> LaserJock, yes, but I'd like to know what it does without using that button
<mjg59> Keybuk: Why? 
<mjg59> Keybuk: SD slots aren't limited to block devices
<Keybuk> mjg59: my point exactly
<LaserJock> mdke: oh sorry, no idea there
<Keybuk> so the subsystem should expose *something* to say what's plugged in
<mjg59> Ah, I see
<Keybuk> otherwise how do we know whether to load mmc_block, mmc_audio, mmc_net, et. al.
<Keybuk> usually this is dealt with through MODALIAS
<Keybuk> it should generate a modalias that includes a hint about the type of device
<Keybuk> and the "catch all" modules should match mmc:?????t01 type thing
<Keybuk> then we can blacklist mmc_bug :p
<mjg59> Keybuk: The problem is likely to be that this stuff was all written by embedded people...
<Keybuk> mjg59: yes
<Keybuk> they can be taught the right way
<mjg59> Keybuk: As a workaround, would it be acceptable to just unconditionally load mmc_block before these drivers?
<mjg59> We don't actually support SDIO right now, so...
<Keybuk> mjg59: could you write up something about MMC and how it works, and what the drivers mean, what's in sysfs, etc. and send it to linux-hotplug-devel@lists.sourceforge.net
<mjg59> Keybuk: Ah, hang on. The hotplug event appears to add a command class field to MMC_CCC
<Keybuk> then we can sic gregkh on them (usually by providing patches)
<Keybuk> if there's anything in the hotplug event that's not in sysfs, it needs to be driver core'd
<mjg59> And mmc_block checks whether cmdclass claims it's a block device
<Keybuk> huh?
<mjg59> Via a private data structure
<Keybuk> eeeevil
<Keybuk> write this stuff up :)
<mjg59> Hang on
<mjg59> Looks like this may be exposed through sysfs
<mjg59> It's just you have to parse a hexidecimal string
<Keybuk> yeah, the lack of modalias still needs fixing though
<Treenaks> mjg59: I'm at home now -- I can test the smart battery stuff if you need it
<Treenaks> ooh
<mjg59> Treenaks: I've sent a patch to Ben - should show up in the next kernel with luck
<Treenaks> and I have a non-working MMC thingy as well :)
<mjg59> Treenaks: Can you lspci -n it and see if it's pci class 0805?
<Treenaks> 0000:02:06.4 0805: 104c:8034
<mjg59> Treenaks: Yeah, should work then
<Treenaks> mjg59: it is detected, but when I insert a card, nothing happens
<mjg59> Treenaks: Load mmc_block and things should be better, but it'll still be flaky with the version in the kernel right now
<mjg59>                 csd->cmdclass     = UNSTUFF_BITS(resp, 84, 12);
<Treenaks> mjg59: still nothing
<Treenaks> mjg59: interrupt count in /proc/interrupts doesn't update either
<mjg59> Is there a type that can hold a 128 bit value?
<Treenaks> mjg59: two int64's ;)
<mjg59> Keybuk: Check mmc.c, line 546. It gets 12 bits from bus/mmc/device/csd (starting at bit 84)
<mjg59> And then mmc_block.c checks whether that matches CCC_BLOCK_READ (include/linux/mmc/protocol.h)
<Treenaks> mjg59: I also have a laptop with a class 0180 SD/MMC/SM reader (also TI, but 104c:8033)
<mjg59> If it's not class 0805, you're out of luck right now
<Treenaks> mjg59: hm, ok
<Treenaks> (btw, any news on my 'crack' keys ( and $ near the arrows)
<janimo> Treenaks, that class  180 is flashmedia controller
<janimo> it's the hp 8240 laptop I presume?
<Treenaks> janimo: no, that's my Acer
<Treenaks> janimo: the 8240 has a 0805
<janimo> oh, great so the TI controller will be supported
<Treenaks> janimo: (hey! on the 8240 I _also_ have the 0180 device)
<Treenaks> (and a 0780 / smart card reader device) 
<janimo> Treenaks, what I said. that is a flashmedia controller
<janimo> the SD one is 805
<janimo> the TI chip controls many kinds of interfaces
<Treenaks> janimo: I know
<Treenaks> janimo: but I only have a SD slot, and a SmartCard slot (and a PCMCIA/CardBus slot)
<janimo> me too
<Treenaks> janimo: so the rest is 'not connected' I guess
<Treenaks> janimo: but on my other laptop, with a mixed SD/MMC/SM slot, there's only the FlahsMedia controller
<Keybuk> mjg59: ok, write all this up and send it to the list please!
* Keybuk beats ogra to a pulp
<mjg59> Keybuk: Do I need to be subscribed?
<Keybuk> mjg59: not sure, if doesn't work, mail it to me
<mjg59> Keybuk: Mailed to the list, if it bounces I'll send it back your way
<Keybuk> it did
<Keybuk> (not bounce)
<Keybuk> it got through
<mjg59> Cool
<mjg59> I think I've got that right - let me know if it doesn't seem to match the code
<poningru> slightly annoying question
<poningru> did we know about goobuntu?
<Keybuk> what about it?
<Keybuk> most of what you heard is probably wrong
<poningru> oh
<poningru> but it does exist?
<poningru> and did canonical know about it?
<Keybuk> e.g. is Google were putting together something based on Ubuntu, it'd be almost certainly for internal use only and not yet another distro on the racks
<zyga> hello
<poningru> oh
<LaserJock> I have a debian/copyright question. I am trying to fix the debian/copyright for ubuntu-docs. All but one of the docs have a FDL/CC-SA dual license.
<LaserJock> since FDL and CC-SA are not in /user/share/common-licenses/ should I include a complete copy of the licenses in debian/copyright?
<lucas> what's the license of the doc which isn't dual-licensed ?
<LaserJock> the Ubuntu Packaging Guide I'm working on, its GPL
<Keybuk> LaserJock: yes.
<lucas> Keybuk: what's Ubuntu's position regarding GFDL and CCs ? (they are non-free according to debian-legal)
<Kamion> poningru: suffice to say it isn't particularly news to us
<Keybuk> lucas: Ubuntu ships GFDL and CC-licenced material
<Keybuk> (* note: possible lie on the second, I _think_ we do, but could be wrong)
<lucas> ok
<LaserJock> well we are shipping ubuntu-docs 
<Kamion> in the case of documentation our stance is that we do not necessarily hold them to the standards of free software licences; instead we judge on a licence-by-licence and package-by-package basis
<Kamion> see http://www.ubuntu.com/ubuntu/licensing, which is quite clear about this
<LaserJock> hmm, so this is going to be a little messy
* Keybuk hands LaserJock a small towel
<LaserJock> ok so I say that all documents are dual licensed under FDL/CC-SA (an have the complete licenses) except for the Ubuntu Packaging Guide which is GPL?
<sivang> LaserJock: what's the status of Ubuntu Packaging Guide , is it near completion? :-)
<sivang> Keybuk: can I ask you some hal related questions?
<Keybuk> if you like
<Keybuk> but you really want sjoerd or pitti
<Keybuk> I may still be able to help though
<LaserJock> sivang: not terribly complete doc.ubuntu.com has what I have so far.
<LaserJock> sivang: I've been busy but after this week I should have more time for it
<sivang> Keybuk: just trying to confirm, if I Have a usb drive with 2 partitions on it, they will be reported by hal as 2 volumes with the same parent node as the Usb device ?
<Keybuk> yes
<sivang> Keybuk: ok, so my storage device detection code no really needs a good rewrite :)
<sivang> s/no/now/
<sivang> Keybuk: thanks :)
<Keybuk> http://people.ubuntu.com/~scott/20060131_dropping-pre-i686_jbailey-doko.ogg
<sivang> Keybuk: videos from the sprint?
<LaserJock> sivang: btw, if you have any suggestions for the Ubuntu Packaging Guide I'd love to hear them
<sivang> LaserJock: currently I'm overly busy, but if you discuss cdbs I might be able to toss something for free :)
<sivang> Keybuk: fascinating
<LaserJock> sivang: I do plan on having a cdbs section and I'm not terribly familiar with it so I might be bugging you in the future ;-)
<sivang> LaserJock: I just have one small tip. I'm no expert :)
<zul> Keybuk: where is that from?
<sivang> zul: I'd bet on the distro sprint , or something close
<zul> i thought the sprint hasnt started yet
* zul is so out of it 
<Keybuk> zul: here is what from?
<zul> Keybuk: the ogg video
<Keybuk> the distro team sprint
<zul> ah ok..
<Keybuk> Technical Board Meeting in 1 minute
<mantiena-baltix> Kamion, did you got my email ?
<mantiena-baltix> from mantas@akl.lt
<Keybuk> mantiena-baltix: Kamion's been a combination of ill and busy so far this week
<Keybuk> I wouldn't expect an immediate reply
<mantiena-baltix> Keybuk, oh
<eeejay> are there any efforts being made ti integrate Xen?
<tseng> not at this time
<eeejay> ok
<eeejay> i'll give it a go
<ogra> eeejay, there are several people offering packages from personal repos iirc ... but its not included 
<dredg> good luck. there's a distinct lack of patches for recent kernels for xen 2.0, and xen 3.0 is where all the development seems to be. except 3.0 is unstable
<eeejay> ogra, so there is no point in rolling my own debs, right?
<dredg> i had a look at it for something work-related but gave up cos i was busy with something else and just wasn't happy with the lack of it working the way i wanted 
<ogra> i dont think so ... but on the other hand i never looked at the existing ones ...
<eeejay> xen 3.0 was released
<dredg> was it? right
<dredg> might look at it next week when i get a chance
<eeejay> thats why it would be a worthy attempt :)
<dredg> interesting
<trulux> evolution-2.6 is a bit unstable, isn't it?
<trulux> :)
<sivang> trulux: yep, I'm also experiencing this :)
<trulux> sivang: heap overflows around
<trulux> let's hope for the best so bad kids don't sell them :)
<sivang> trulux: well, I didn't investiage that deep, I just expreince the pain :)
<trulux> sivang: HTML processing code is worst and worst on each new milestone
<sivang> trulux: HTML should be banned in emails :-D
<trulux> sivang: well, disable malloc checking in your glibc, then attach gdb and have fun
<trulux> sivang: heh
<sivang> trulux: I think that could eventually consume all my RAM or hammer my swap , I think I'll pass
<trulux> sivang: any way to go back?
<trulux> sivang: I mena once you get it to crash
<sivang> trulux: you mean, to downgrade the package?
<trulux> yeah
<trulux> I don't want this 0day shit :)
<sivang> trulux: I usually dpwnf ohhh I like crappy net connections
<sivang> trulux: I usually dpkg -i /var/apt/archives/pkg-ubuntu${N-1} but it does not always help.
<trulux> sivang: hmm, how's that this unstable thing gets into dapper that easy?
<sivang> trulux: it's dapper :) btw, what does your backtrace tells you? (top of it)
<trulux> #12 0xb796b34a in free () from /lib/tls/i686/cmov/libc.so.6
<trulux> #13 0xb6a8fdcc in g_free () from /usr/lib/libglib-2.0.so.0
<trulux> last calls
<trulux> :)
<sivang> trulux: we need to compare and report a bug. did you rebuild evo with debug symbols? (it takes ages)
<sivang> trulux: let's move this to #u-desktop , shall we?
<trulux> nope, well, I was working on some POC, so I didn't report anything yet
<trulux> no need, I'll to work this out
<sivang> trulux: POC ?
<trulux> sivang: proof of concept, call it exploit
<sivang> trulux: ah, for the security team?
<trulux> I don't have the time anyways, this evolution stuff makes me feel sick
<trulux> sivang: no, for myself :|
<sivang> trulux: I'm on the evo stuff, the rebuild time just pisses me off :)
<trulux> I can help you, but I would like to get email working first :)
<sivang> trulux: evo started crashing for  me at start due to bug 28640
<trulux> sivang: link to malone?
<trulux> sivang: most of the issues are related to html processing, really weird
<Ubugtu> malone bug 28640 in glibc "libc6 crash on certain UTF8 encoded filename" [Major,Fix released]  http://launchpad.net/bugs/28640
<zyga> sivang: interesting
<sivang> trulux: he had created a patch for this that appears to have solved the issue on one of my machines,
<sivang> trulux: but still not for the other. I'll just make sure it's not the same thing 
<sivang> zyga: indeed.
<sivang> trulux: this also affects my gaim on this system, so it seems.
<zyga> sivang: I'm still reading the bug page
<trulux> nope, that isn't the issue
<trulux> this one is a nice issue on html processing of some objects
<trulux> I'll fill a bug report anyways
<zyga> sivang: bah it's fixed already
<sivang> zyga: supposed to be 
<sivang> zyga: it WAS fixed for one of my mahcines, this doesn't seem to have helped my home machine
<trulux> *** glibc detected *** free(): invalid pointer: 0x087a8850 ***
<sivang> zyga: this also broke gaim for me, which is still broken here.
<zyga> sivang: queer, maybe incomplete upgrade?
<sivang> zyga: hmm
<sivang> zyga: I'll check
<sivang> zyga: nope
<trulux> ok, got another one
<zyga> hmm
<zyga> I'd like to file a bug on alacarte :-)
<zyga> the image in the about dialog should be ubuntu human themed
<Amaranth> zyga: Why should the applications own internal logo be human themed?
<trulux> http://rafb.net/paste/results/DOzPW794.html
<zyga> Amaranth: because it shows a screenshot of the application menu 
<Amaranth> zyga: so small you can't really see it
<zyga> Amaranth: it could be brownish ':-)
<Amaranth> it is
<zyga> ?
<Amaranth> it's clearlooks, which is a sort of tan color
<zyga> Amaranth: I've got a blue color
<Amaranth> ah, the selected one
<Amaranth> btw, it's not actually a screenshot
<Amaranth> zyga: i'd end up rejecting the patch, it's not worth it to me
<zyga> Amaranth: right but it's close
<Amaranth> patch/bug, whatever is supplied
<zyga> Amaranth: even if all you had to do was to apply a changed .png to the tree?
<Amaranth> zyga: yes, because about dialogs are generally left alone
<Amaranth> plus it's my app :P
<zyga> Amaranth: ooooh
<zyga> Amaranth: would you like a comitted polish translator then?
<Amaranth> zyga: once i get it into gnome cvs, please
<Amaranth> which won't make it into dapper...
<zyga> Amaranth: even before, I'd love to get it via rosetta but it's not there yet
<Amaranth> yeah, i don't have any source management setup for it
<Amaranth> so rosetta can't get to it
<zyga> Amaranth: not even bzr?
<Amaranth> nope
<zyga> Amaranth: local bzr is worth a fortune :-)
<zyga> Amaranth: why won't you go for it then?
<Amaranth> i'm too lazy to type "bzr commit"
<Amaranth> go for?
<zyga> Amaranth: would you allow me to submit current alacarte template to rosetta?
<Amaranth> sure
<zyga> Amaranth: k, in progress :-)
<Amaranth> you'll have to ping seb128 on getting the package updated until the end of february though
<zyga> Amaranth: what do you mean?
<zyga> Amaranth: the UVF?
<Amaranth> no, i don't have ubuntu installed anywhere right now
<Amaranth> or a copy of alacarte :P
<zyga> Amaranth: :-))
<Amaranth> and he has been handling things with it
<zyga> Amaranth: that's fine I already got the source, I'll talk with seb about this tommorow
* Amaranth kicks school and bills
* Treenaks kicked school years ago ;)
* sivang made it for pre-university :)
* zyga looks left
* zyga looks right
* zyga is a calm person and rejects kicking
<rob^^^> Am I the only one who has concerns about users being able to find shut down on the new GDM theme?
<tseng> that is a question for #ubuntu-desktop
<rob^^^> thanks, I've asked there
<delire_> crimsun: what was the workaround for snd-hda-intel on a 2.6.10 kernel? have a person here that runs breezy on 2.6.10 not 2.6.12 due to showstopper bug 15031.. snd-hda-intel isn't in the 2.6.10 sources.
<trulux> sivang: mostly anything makes it to crash
<trulux> sivang: any temp. solution? :(
<sivang> trulux: it finished building now :) let's see where it crashes
<trulux> great
<trulux> sivang: two upgrades available now for gtkhtml
<trulux> sivang: I guess those are related to evolution
<sivang> trulux: how new are they?
<trulux> today
<sivang> trulux: already tried them. my evo is hanging on CalDAV Eplugin starting up ...
<sivang> oh well, I'll leave it fo rnow I think :)
<trulux> jeesh
<trulux> sivang: well, the issues are somehow solved
<trulux> sivang: I'll check for a security notice, or maybe they patched silently the stuff
<trulux> :)
<sivang> trulux: you mean, the POC for exploiting evo?
<trulux> sivang: yep, the issues have been removed from the lib
<Wibble-> I'm interested in hacking the source code for one of the packages I have installed in a ubuntu-friendly way.  Are there any guides which might poke me in the right sorts of directions for the ubuntu side of things?
<\sh> moins
<\sh> can someone explain me, why suddenly my upgraded amd64 dapper is throwing out bootp messages?
<\sh> 23:09:10.565659 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:14:85:51:5b:7a (oui Unknown), length: 300
<\sh> 23:09:10.569101 IP 192.168.1.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 548
<\sh> ok...dhclient3 is the man
<mjg59> They're DHCP requests, not bootp ones
<\sh> well..yes
<\sh> and I wonder why dhclient3 is throwing them like mad...even if dhclient3 already requested the ip from the dhcp
<\sh> mjg59: btw..I had some nasty things happening 2 hours ago with latest dapper upgrades from today
<\sh> 1. sky2 loaded as marvell yukon driver, instead of sk98lin
<\sh> 2. sk98lin loaded manually didn't work at all anymore
<Amaranth> zyga: I've got mail. :)
<zyga> Amaranth: k, I'll also send you a minor patch for missing i18n
<\sh> and I couldn't write down the error messages, because no pen&paper and no ways to access my network or my second partition
<Amaranth> zyga: msgstr "Edytor menu Alcarte"
<Amaranth> typo?
<zyga> yes,
<\sh> and now let me try to get my madwifi card running again
<zyga> sorry :-)
<\sh> brb
<zyga> Amaranth: how about that bzr branch for both of us?
<zyga> Amaranth: I used dapper sources
<Amaranth> zyga: i figure once i find my USB stick i'll get it into gnome cvs (just need to create the module, already been approved and i have an account), then get launchpad to mirror it into bzr
<Amaranth> zyga: dapper sources is all i have too
<zyga> Amaranth: okay, I'll send you the .po again along with the patch
<zyga> what was that apt-cache command that showed you all versions of a package?
<zyga> ma... something
<zyga> mosomething?
<sivang> night all
<\sh> at last
<zyga> sivang: night
<\sh> sivang: sleep tight
<sivang> \sh: thanks :)
<sivang> \sh: you too
<sivang> zyga: back
* sivang is off
<zyga> :-)
<\sh> sivang: well, I have a lot of "Dude, where's my dapper" questions to answer :)
<delire> hehe
<\sh> 2h at least to determine that I wasn't the fault...
<\sh> actually a good day
<zyga> Amaranth: almost done, just one test away
<\sh> 1. fixed a j4log problem in a servlet, 2. fixed a problem with "how does imap actually work, and why is it totally crap to open several imap session when you don't close them" 
<\sh> 3. explain to some java devs, why tomcat and all java servlet containers do have session handling and why you should use them, even in midlets 
<\sh> 4. wrote an invoice and earned money...
<ajmitch> hi \sh 
<\sh> moins ajmitch 
<ajmitch> part 4 is good ;)
<MisterN> n8
<\sh> ajmitch: yes...7 days of work, and earned at least the same money as working for ish for one month :)
<\sh> ajmitch: now they have to transfer the money to my account..and I can pay at least my rent and car and phone :)
<ajmitch> yeah, I've got a short (2-3 week) job in a few days 
<\sh> ajmitch: oh btw...wrote the invoice with the lx-erp software, a german fork of sql-ledger :) 
<ajmitch> heh
<\sh> need to setup a complete table of accounts for this thing...and somehow add some digital signature functionality to the "send invoice by email" function
<zyga> Amaranth: do you want a diff against orig.tar.gz or orig.tar.gz + debian.changes
<Amaranth> i forgot what the changes were
<Amaranth> afaik it's only changes to the packaging
<zyga> Amaranth: a minor change with gnome 2.12 compatibility
<Amaranth> err
<Amaranth> where?
<Amaranth> the only thing i can think of that you'd be talking about is the debian version
<Amaranth> which loads gnome-applications.menu and uses reversed(foo) instead of foo.reversed()
<Amaranth> or vice-versa, i forget which one is new in python 2.4
<zyga> Amaranth: in debian/patches
<Amaranth> what version are you looking at?
<Amaranth> i'm seeing nothing in the archives...
<Amaranth> -s
<zyga> Amaranth: 0.8-0ubuntu2
<zyga> Amaranth: you can have a look at my bzr branch if you'd like
<Amaranth> yeah
<Amaranth> 0.8-0ubuntu2 doesn't have any patches which change the orig
<Amaranth> that i can see here
<zyga> http://ubuntu.suxx.pl/2006--1/bzr-archive/alacarte--zk
<zyga> Amaranth: yes you're right
<zyga> Amaranth: it's in debian/patches
<zyga> sorry I got confused
<Amaranth> heh, my last changelog entry is funny
<zyga> argh.. I'm dumb :-)
<zyga> copying .diff from mc's virtual directory was ... silly
<Amaranth> yeah, i'm seeing that :P
<Amaranth> all these diff files in debian/ :P
<zyga> Amaranth: pull, I fixed that
<Amaranth> oh, i'm just browsing with firefox :P
<Amaranth> i'm at school
<zyga> Amaranth: basically the real fix is: add missing translatable="yes" in .glade
<zyga> add pl.po
<zyga> move "Other" out of translatable strings
<Amaranth> what was missing in the glade file?
<zyga> mark some missing strings in the source (just one AFAIR)
<zyga> the window title :)
<Amaranth> bleh
<Amaranth> that's the title of the app
<zyga> yes but it has to be translated :)
<zyga> Amaranth: oh and I've also added X-Ubuntu-Gettext-Domain to .desktop.in
<Amaranth> yeah, what's up with that?
<zyga> Amaranth: gettext support :)
<Amaranth> *shrug*
<zyga> Amaranth: ideally for ubuntu .desktop files should have no translations at all
<Amaranth> bzr works on OS X, right?
<zyga> that pulls translations from .mo files
<zyga> Amaranth: yes
<Amaranth> ok
<zyga> Amaranth: on 10.4.3 at least
<Amaranth> 10.4.4, same thing
<zyga> Amaranth: todo, add focus on 'applications' after startup
<zyga> I need to look at other projects
<zyga> take care :-)
<Amaranth> zyga: will you be here in 2 hours?
#ubuntu-devel 2007-01-29
<lamont> keescook: you planning to put bind9 9.3.4-1ubuntu1 into feisty?
<geser> lamont: could you please give-back mod-mono. thanks
<lamont> geser: what, everywhere?
<geser> yes, on all archs
<geser> apache2.2 was uploaded after mod-mono was synced
<lamont> and launchpad failed to drop it into depwait.  go LP
<lamont> man I hate web interfaces.
<lamont> done
<geser> thanks
<sponix> anyone working on Smart Card Access (CAC) -- coolkey ?
* lamont sleeps
<fabbione> morning
<LaserJock> morning fabbione 
<fabbione> Adri2000: i have done it, but next time look at the merge first.. it was really simple to do and didn't require sparc at all
<keescook> lamont: yup, that's the goal.  It's on my list for monday.
<pitti> fabbione: there's no way to detect with which md version the volume has been created?
<fabbione> pitti: what would that achieve?
<fabbione> you will still have byte swapped version written somewhere in the SB it self
<pitti> fabbione: comparing both endianesses will work of course, but wouldn't that catch a corner-case of non-md devices as well?
<pitti> fabbione: oh, there will always be a 0.9 *and* a 1.0 header?
<fabbione> pitti: no.. you will endup just checking another byte the same way you check the sb magic
<fabbione> it won't solve anything other than making the check more complex
<pitti> ok
<fabbione> < 1
<fabbione> typedef struct mdp_superblock_s {
<fabbione>         __u32 md_magic;         /*  0 MD identifier                           */
<fabbione>         __u32 major_version;    /*  1 major version to which the set conforms */
<fabbione>         __u32 minor_version;    /*  2 minor version ...                       */
<fabbione> > 1
<fabbione> struct mdp_superblock_1 {
<fabbione>         /* constant array information - 128 bytes */
<fabbione>         __le32  magic;          /* MD_SB_MAGIC: 0xa92b4efc - little endian */
<fabbione>         __le32  major_version;  /* 1 */
<fabbione>         __le32  feature_map;    /* bit 0 set if 'bitmap_offset' is meaningful */
<fabbione> so if you look at major_version
<pitti> fabbione: my only concern is that this might consider a normal partition as a md volume which just happens to have the magic there in reverse byte order
<fabbione> you will still endup doing a if foo = 1 || foo = xlate(1)
<fabbione> pitti: i already checked that.. it's almost impossible to do that
<fabbione> most FS do round the end of the device in the exact same way
<fabbione> i can give you a test case for it if you want
<pitti> fabbione: true, if that could happen, then a normal fs could also accidentally have the little-endian md magic
<fabbione> (there is another bug open for that, that we should NOT confuse with what we are fixing here)
<pitti> so it shouldn't be a concern
<pitti> fabbione: alright, thanks for the explanation
<pitti> fabbione: approved (also noted so in the bug), please upload
<fabbione> it's already uploaded
<fabbione> as i wrote in the bug :)
<fabbione> pitti: you just need to change hat and approve the upload :P
<\sh> moins
<pitti> fabbione: sorry for my unnerving questions, I'm just paranoid
<pitti> hi \sh
<fabbione> pitti: that's ok :) you have the right to be paranoid :)
<pitti> fabbione: both accepted
<fabbione> pitti: thanks
<\sh> moins pitti :) 
<dholbach> good morning
<Mithrandir> seb128: good morning, I was just looking for you.
<seb128> hey Mithrandir
<Mithrandir> seb128: serpentine seems to build-dep on muine, which isn't in main.  Can you fix that?
<seb128> what's up?
<seb128> sure
<Mithrandir> (as in, write a MIR or change the build-dep)
<Mithrandir> thanks.
<seb128> np
<Mithrandir> :-)
<somerville32> \o_
<Mithrandir> seb128: there seems to be a bunch of GTK themest which are no longer depended on by anything in main (gray-theme, industrialtango-theme, outdoors-theme, resilence-theme, silicon-theme).  Should I keep them nevertheless or can they be put in universe?
<seb128> Mithrandir: because to ask dholbach or artwork team about themes, as far as I'm concerned those can go to universe, I'm not sure of why they were to main
<seb128> s/because/better
<Mithrandir> seb128: ok, thanks.
<seb128> (need to wake up :p)
<Mithrandir> dholbach: there seems to be a bunch of GTK themest which are no longer depended on by anything in main (gray-theme, industrialtango-theme, outdoors-theme, resilence-theme, silicon-theme).  Should I keep them nevertheless or can they be put in universe?
<seb128> np ;)
<dholbach> Mithrandir: universe is fine
<Mithrandir> dholbach: coolie, thanks.
<Mithrandir> .mvo: you're aware that update-manager ftbfs?
<dholbach> Mithrandir: I asked the ubuntu-art list a while ago and it was fine for them - I just never managed to tell you or other archive admins what to do about them
<Mithrandir> s/^.//
<Mithrandir> dholbach: that's fine, they've been in the anastacia output for a while, so I figured I'd better decide what to do with them.
<Mithrandir> dholbach: same with the edgy themes and wallpapers and such?
<dholbach> Mithrandir: yes
* dholbach hugs Mithrandir
<Mithrandir> dholbach: yay!
<mvo> Mithrandir: yes
<Mithrandir> pitti: postgresql-8.2 doesn't seem to be seeded, is it about time to change -8.1 to -8.2 in the seeds?
<Mithrandir> mvo: thanks.  Are you planning on making anything depend on apt-transport-https or can it be demoted to universe?
<mvo> Mithrandir: why would we want to demote it? its just a seperate package so that the dependencies of apt do not inflate.
<Mithrandir> mvo: because nothing depends on it, and we don't keep stuff in main if we don't explicitly want it (in which case it's seeded) or something we want needs it (in which case germinate pulls it in)
<pitti> Mithrandir: right, I'll care for the remaining bits RSN
<Mithrandir> pitti: cheers.
<mvo> Mithrandir: I would rather want to seed it explicitely then
<elmo> uh, why is it in a separate package?
<mvo> elmo: to keep apt from having a libcurl-gnutls lib dependency
<pitti> carlos: time for new langpacks for dapper?
<carlos> pitti: yeah, I was talking with you about it in another channel :-P
<elmo> mvo: meh
<Adri2000> fabbione: ok, I just didn't want to upload because I couldn't be sure that it would build fine or not
<pitti> Mithrandir: did you commit your avahi upload into the bzr?
<Mithrandir> pitti: nope, sorry.
<Mithrandir> the source package isn't a branch, for some reason.
<pitti> Mithrandir: just toss me the debdiff, I can do it for you quickly
<Mithrandir> pitti: http://rafb.net/p/yEdLMj68.html
<Mithrandir> pitti: thanks
<sivang> pitti: I hope this time you got the pivmsg :)
<sivang> (I forgot to identify just before)
<pitti> hi sivang 
<pitti> yes, I got it
<sivang> pitti: cool, thanks
<pitti> Mithrandir: postgresql-8.2 transition is complete for main, I changed the seeds and will do the pro/demotion soon
<Mithrandir> pitti: cheers.
<stub> yay
<pitti> stub: btw, I built an 8.2 package for dapper for niemeyer
<Tonio_> seb128: ping ?
<seb128> Tonio_: no content ping warning
<Tonio_> seb128: yes sorry, I was jsut doing something else
<Tonio_> seb128: I'm just about to sync the fonts settings you changed in gnome in kubuntu
<seb128> I didn't change anything yet
<Tonio_> seb128: what are the exact settings you used (font, size...)
<Tonio_> seb128: okay, I just noticed dejavu sans condensed isn't there on a native feisty installation
<Tonio_> seb128: ttf-dejavu changelog talks about removing -condensed suffix
<seb128> That apparently require discussion before being changed
<seb128> I think I'm going to wait for the artwork team to decide something
<Tonio_> okay, it would be nice that we stay sync conerning this, I'll follow the discussion
<Tonio_> seb128: do you see Condensed in the font list ? I can't see it here, and I was confirmed it is the same for all people with kubuntu-feisty
<pitti> hi sabdfl, how's it going?
<sabdfl> guuuurd
<pitti> Mithrandir, cjwatson: grabbing lock for doing syncs
<sabdfl> how's the apport-meister?
<pitti> sabdfl: I'm great, thanks!
<pitti> sabdfl: check out apport 0.45, just uploaded today, now with 21.5% more love :)
<sabdfl> dl'ing
<Tonio_> seb128: I'd like to get a confirmation because it seems like a kde bug, since the ttf file is installed here...
<seb128> Tonio_: DejaVu have "Condensed" style listed with the GNOME capplet
<seb128> Tonio_: that's not a different font, that's a variant like "italic"
<Tonio_> seb128: yeah but I don't get it.... probably a kde issue I'll have to fix
<seb128> maybe
<Tonio_> seb128: thanks for the info, that'll help
<seb128> works fine from the GNOME capplet
<seb128> np
<Tonio_> seb128: the point is if you ls /usr/share/fonts/truetype/ttf-dejavu/ it looks like a different font, not a style.... I'm a bit lost to be honnest ;)
<Tonio_> seb128: a style should be named DejaVuSerif-Condensed.ttf not DejaVuSerifCondensed.ttf
<kwwii> seb128: I do not think that it is only a style, it is a font
<Tonio_> kwwii: true, and the point is there is a conflict name between the condensed and the "normal"
<seb128> kwwii: well, the GNOME capplet list it as a style
<seb128> kwwii: that's all I know about it ;)
<Tonio_> when I install the tff manually, they both overwrites each other
<kwwii> seb128: in gnome(edgy) I can select it as a font and then change the style
<Tonio_> kwwii: yup condensed is supposed to have its own styles (bold...)
<kwwii> erm, at least I think I can
<kwwii> one second
<seb128> kwwii: on my feisty desktop, the left pane list only 3 variants, and the middle pane (style) has the "condensed"
<seb128> ExtraLight, Condensed, Book, etc
<kwwii> yeah, it is different on edgy
<kwwii> so how do you set condensed bold?
<Tonio_> kwwii: in the third panel probably :) kde only has 2 panels, that may explain the trick
<seb128> kwwii: I pick "Condensed Bold" as style
<kwwii> ahaaa
<seb128> there is 10 styles listed there
<seb128> Condensed Bold is one of them
<Tonio_> hum....
<seb128> Tonio_: there is only 2 panes there
<seb128> the 3 columns is the font size
<Tonio_> seb128: okay so it looks like the kcm module is broken somehow
<kwwii> but you see all the variants as options in the second pane
<seb128> right
<Tonio_> but what is very strange is that the naming of the ttf shows condensed as a different font
<seb128> I don't say that's correct
<jsgotangco> #iosn
<seb128> I don't know much about font
<Tonio_> seb128: well the naming is supposed to be <fontname>-<style>.ttf
<Tonio_> that's why I'm a bit lost :)
<Tonio_> seb128: it would be interesting to know if "condensed" is a different font or a style on ubuntu edgy in fact
<seb128> kwwii said that's listed as a different font for him
<Tonio_> seb128: with kde it appears that way yes, I assume it should be the same with gnome
<seb128> on edgy it is, on feisty it's not
<Tonio_> seb128: looking at ttf-dejavu.defoma-hints in the source package, it looks like a different font, I'll try to get the infos and fix this...
<seb128> I don't think the font capplet code changed recently
<seb128> I would say that's a font change then
<Tonio_> seb128: so that's probably a bug in the font
<Amaranth> dejavu?
<Amaranth> almost certainly a bug in the font
<seb128> yep
<seb128> why?
<Amaranth> past experience :)
<Tonio_> Amaranth: hehe
<Tonio_> seb128: FamilyName: DejaVu Sans Condensed
<Tonio_> seb128: that confirms the bug, it is clearly not a style
<seb128> Amaranth: we are trying to figure what is wrong there, please don't make random assertion because you already bugs with the font, that's not really useful
<Tonio_> seb128: the issue looks like the saming of the font. gnome seems to merge the styles while kde probably uses the latest ttf loaded only
<Tonio_> seb128: fixing the name should resolve the issue, I'm testing this
<seb128> please talk to doko before doing changes to the package though
<Tonio_> of course
<Tonio_> seb128: I wouldn't touch something impacting not only kde before pinging the good personns for this
<seb128> k
<ogra> cjwatson, thanks for making the g-p-m patch will upload it during the afternoon ...
<pitti> mdz: since bug 74004 seems to be your's, want to upload to edgy-updates? the bug is not yet closed in feisty and feisty's changelog does not mention this either, is this still relevant in feisty?
<Ubugtu> Malone bug 74004 in udev "Doesn't include qla2xxx firmware" [High,Confirmed]  https://launchpad.net/bugs/74004
<pitti> ah, seems to be relevant for feisty
<mdz> pitti: I thought it was fixed in feisty by BenC
<mdz> pitti: could you finish off the SRU for me for edgy?
<pitti> mdz: can do
<Tonio_> seb128: debian has ttf-dejavu-2.14, while we have 13, I'm building to see if the issue is resolved
<pitti> mdz: done
<seb128> Tonio_: I've looked at the .deb from Debian this morning, the name has no "-" neither
<tepsipakki> rodarvus: ping, i810 on dapper
<Tonio_> seb128: yes, which makes sense has it is a different font
<mdz> pitti: thank you
<Tonio_> seb128: what is important is the name inside the ttf, which should not be "Dejavu Sans" but "Dejavu Sans Condensed" as on edgy
<seb128> k
<Tonio_> there is the bug, several fonts have the same name
<seb128> We will probably sync the new package from Debian
<seb128> I want to ask doko before doing a sync request though
<Tonio_> seb128: yup, I'm reloading kde to test the package
<cjwatson> ogra: you're welcome - I obviously had incentive
<Tonio_> seb128: same issue :)
<seb128> ok :/
<seb128> maybe have a look to the upstream bug tracker or list
<Tonio_> seb128: yes, I'll investigate and let you know
<carlos> pitti: http://people.ubuntu.com/~carlos/language-packs/dapper/rosetta-dapper-2007-01-29.tar.gz
<pitti> carlos: yay
<Tonio_> seb128: okay that's a debian change via ttf-dejavy.defome-hints
<Tonio_> seb128: easy to fix though, I'm giving an attempt
<seb128> k
<Tonio_> seb128: they have changed all "family" tags to group them, when it is supposed to be different fonts..... dirty....
<seb128> they probably did it for a reason
<Tonio_> seb128: probably to reduce the font numbers and group them as styles, which can make sense, except that breaks kde :)
<seb128> fix kde then ;)
<Tonio_> seb128: well I don't think there is a kde bug on that point
<Tonio_> seb128: I think their changes have an issue somehow, since kde recognize styles correctly on all fonts
<seb128> it doesn't list all the variants no?
<Tonio_> seb128: so we have to improve what debian does, or switch back to what dejavu is supposed to be
<seb128> k
<Tonio_> seb128: in that case kde doesn't, no, but probably because something misses for the variant to be correct
<Tonio_> if that was a bug that would bug on all fonts, not only that patched one :)
<seb128> could be, right
<seb128> anyway lunch time for me
<seb128> bbl
<Tonio_> seya
<mvo> Mithrandir: is there a way to see the source NEW queue for feisty? http://people.ubuntu.com/~tfheen/unapproved-queue/feisty/ seems to be empty currently
<Mithrandir> mvo: yes, it's not in unapproved, it's in NEW.
<Mithrandir> mvo: https://launchpad.net/ubuntu/feisty/+queue should show it to you, though
<mvo> Mithrandir: cool, thanks
<cjwatson> hmm, how strange, today's daily desktop CD comes up without panels
<cjwatson> DISPLAY=:0 gnome-panel from tty1 works though
<Mithrandir> the panel doesn't start at all?
<Mithrandir> anything interesting in the xsession log?
<cjwatson> when started by hand, it's fine
<cjwatson> practically nothing in .xsession-errors - nothing of interest
<Mithrandir> hm, weird
<owh> pitti: Do you have a moment?
* StevenK kicks ld.
<StevenK> If I specify a -l option, please do what I say and actually link in the library!
<tepsipakki> openoffice.org-voikko is uninstallable for some strange reason.. it depends on oo.o-core (>= 2.0.4), but refuses to install when 2.1-2u4 is installed
<Mithrandir> it's probably conflicted against by something else
<tepsipakki> oh
<tepsipakki> I'll check
<tepsipakki> err
<tepsipakki> Conflicts: openoffice.org-core (>= 2.0.4.1)
<tepsipakki> so, that's the reason then ;)
<tepsipakki> I'll contact the maintainer
<lamont> keescook: uh, you'll want 9.3.4-2 :-(
<lamont> keescook: 9.3.4-2 will be in today's dinstall run
<lamont> bind9 (1:9.3.4-2) unstable; urgency=high
<lamont>   * Actually really do the merge of 9.3.4.  Sigh.
<siretart> Mithrandir: are you still at syncing stuff from debian?
<Mithrandir> siretart: we do process sync requests filed in launchpad, yes.
<siretart> Mithrandir: I filed a sync request for openarena, which (persumably you) just processed. I think forgot to request openarena-data to by synced as well :( 
<siretart> If you're already done with it for today, I'll file another bug, no problem
<Mithrandir> siretart: pitti does syncs too now, but just file a bug about it.
<siretart> Mithrandir: aah, okay. willdo
<StevenK> Mithrandir: Correct me if I'm wrong, but usplash also needs a .a file if uswsusp is compiling with -static
<Mithrandir> StevenK: uswsusp shouldn't compile with -static.  IMO.
<Mithrandir> StevenK: or usplash could grow a .a
* StevenK is currently test building the latter
<mjg59> Why would uswsusp be static?
<mjg59> We're already carrying most of the libraries it needs in initramfs
<StevenK> I could swear it is, and that upstream has made it so.
<Mithrandir> it is, and upstream has made it so.
<mjg59> Well, that's trivial to fix
<Mithrandir> it works just fine dynamically for me.
<StevenK> Indeed.
<mjg59> Building it statically makes sense for end-users
<mjg59> Integrating initramfs stuff is hard
<kylem> let's go shopping
<StevenK> So should I junk my usplash .a stuff and make it dynamic, or keep the usplash .a and leave it static?
<mjg59> Make it dynamic
<mjg59> Otherwise we'll be carrying two copies of libusplash in initramfs
<StevenK> Aye
<StevenK> I note I just got libusplash.a generating correctly and installed in my test. :-)
<Mithrandir> heh
<StevenK> dpkg-deb: building package `uswsusp' in `../uswsusp_0.5-1ubuntu1_amd64.deb'.
<StevenK> Hurray!
* StevenK as yet, has no ideas how to test it, short of upgrading his laptop.
<Tonio_> seb128: the change from font to style is upstream in ttf-dejavu, and the problem with kcontrol looks likea kde bug, reported in opensuse too....
<seb128> ok
<pitti> re
<pitti> siretart: I synced openarea this morning, it should be in NEW now
<siretart> pitti: I forgot to request openarena-data to be synced as well :(
<siretart> pitti: I've reopened the bug now. - thanks for  syncing!
<visik7> hi 
<visik7> I'm trying to figure out how to use python-apt 
<visik7> but I can't find any docs about it
<crimsun> pitti: yes, please reject the azureus upload for edgy-proposed
<pitti> crimsun: yup, will do
<crimsun> pitti: thanks
<pitti> crimsun: oh, there is also a azureus/2.5.0.0repack1-0ubuntu0.6.10~proposed1 upload now
<somerville32> crimsun: Did you see that report of regression on the xubuntu-devel ml?
<crimsun> pitti: oh, ok. I just now read your earlier email regarding the version conflict.
<crimsun> somerville32: no, -> #x..-devel?
<somerville32> Sure
<zul>  /msg pitti can you check to see the 2.6.12 upload got accpted i havent gotten any feedback yet
<pitti> crimsun: removed, updated bug
<pitti> zul: doing
<crimsun> pitti: thanks!
<zul> pitti: merci
<pitti> zul: heh:
<pitti> 2007-01-29 14:10: linux-source-2.6.12_2.6.12-10.43_source.changes
<pitti> linux-source-2.6.12_2.6.12-10.43_source.changes
<pitti> REJECT
<pitti> Rejected: Unknown distribution `UNRELEASED'.
<zul> whoops
* kylem chuckles.
<fabbione> zul: you better not fuck up breezy kernel
<fabbione> zul: i am still running my server on breezy
<zul> fabbione: i havent yet
<fabbione> zul: or you will hear from me.. :)
<zul> fabbione: heh
<fabbione> tho hopefully i will manage to upgrade to dapper in 3 weeks
<kylem> better do it soon, only 3 more months of breezy. ;-)
<zul> thank god
<fabbione> kylem: yeah that too.. but to dist-upgrade that box i need a day off and at least a month at home to make sure it won't crash
<Mithrandir> mvo: can you please do your GnomeAppInstallDesktopDatabaseUpdate thing?
<pitti> crimsun: accepted, bug updated (fixcommitted, added tag)
<crimsun> (thanks again :)
<mvo> Mithrandir: what needs to be added?
<Mithrandir> mvo: just do the update, we're getting close-ish to a herd.
<mvo> Mithrandir: ah, ok. I will do that now then
<Mithrandir> thanks
<mvo_> does anyone knows what happend to acroread in multiverse in feisty? lp says it got removed, but I can't see (in LP) why
<somerville32> mvo_: License issues
<mvo_> ok, thanks
<mdz_> ogra: I'm having a lot of problems with power management now; is this due to the new g-p-m?
<mdz_> ogra: my backlight keeps forcing itself to the lowest setting, even on AC or when I move the slider in gpm preferences, e.g.
<bddebian> Heya
<ogra_> mdz, thats either hal, the kernel or g-p-m
<mdz> ogra_: I just downgraded gpm and now it works properly
<ogra_> hmm, ok i think there is a bug about thet 
<ogra_> *that
<cjwatson> ogra_: for the next g-p-m, could you remember to package it with an .orig.tar.gz? I noticed it was native-style
<ogra_> huh ? 
<cjwatson> you should be able to fix that without having to wait for a new upstream version or anything
<cjwatson> -rw-r--r--  1 cjwatson cjwatson     964 2007-01-24 19:03 gnome-power-manager_2.17.90-0ubuntu2.dsc
<cjwatson> -rw-r--r--  1 cjwatson cjwatson 2515755 2007-01-24 19:03 gnome-power-manager_2.17.90-0ubuntu2.tar.gz
<ogra_> gra@edubuntu:~/packages$ ls gnome-power-manager_2.17.90*gz
<ogra_> gnome-power-manager_2.17.90-0ubuntu1.tar.gz  gnome-power-manager_2.17.90-0ubuntu2.tar.gz  gnome-power-manager_2.17.90.tar.gz
<ogra_> mmmpf, sorry
<cjwatson> mv gnome-power-manager_2.17.90.tar.gz gnome-power-manager_2.17.90.orig.tar.gz
<ogra_> yeah
<mvo_> pitti: pmount is no longer a rdepend off any package installed by ubuntu (only kubuntu). what happend ?
<ogra_> i usually wget it and mv it to _*.orig.tar.gz ... seems i missed the orig .... grr
<pitti> mvo_: we don't use it any more
<seb128> mvo_: gnome-mount happened
<mvo_> oh, good
<pitti> mvo_: and I switched the hal backend from pmount to upstream's
<mvo_> because it means the autoremove code in apt did the right thing, I was worried :)
<Riddell> Mithrandir: is herd 3 happening this week?
<Mithrandir> Riddell: yes, I've sent the pre-freeze announcement to u-d-a, but I don't think it's been approved yet.
<cjwatson> can fix that
<cjwatson> moderated
<Mithrandir> cheers
* cjwatson makes PackageInconsistencies a redirect to the appropriate bit of UbuntuDevelopment
* bddebian hits himself in the head with a hammer
<cjwatson> Mithrandir: todo for herd 3 after this ubiquity upload: deliberately break ubiquity and check that the apport hook works smoothly (a) if you have to login to an existing account (b) if you have to create a new account
<cjwatson> (a) is more important for now
<cjwatson> (but (b) should be fixed before release)
<Mithrandir> cjwatson: cheers
<pitti> cjwatson: I tested (a) with a normal crash, works fine
<cjwatson> great
<pitti> it even preserves the title
<cjwatson> ubiquity 1.3.14 has the apport hook as we discussed, but untested
<crimsun> ogra_: may I merge pulseaudio 0.9.5-5 from Debian unstable (pending Mithrandir's ACK) to pull in the fix for Debian 405869?
<Ubugtu> Debian bug 405869 in pulseaudio "/etc/init.d/pulseaudio may call chown on non-existing file" [Normal,Closed]  http://bugs.debian.org/405869
<crimsun> ogra_: or do you feel it's low enough priority that it's deferrable?
<ogra_> crimsun, feel free, we dont use the initscript by default anywayx
<Mithrandir> crimsun: why would you wait for a ack from me?
<ogra_> right, just merge it :)
<crimsun> Mithrandir: it's a main package and I just read the u-d-a post regarding Herd 3?
<Mithrandir> crimsun: well, we're not frozen yet, so just don't break anything. :-)
<bddebian> break it!!
<ogra_> meh, herd freeze ...
<ogra_> bad timing
<mdz> Mithrandir: network-manager->desktop for herd 3?
<ogra_> lets next release not have a milestone freeze a week before feature freeze ...
<pitti> mdz: it's already seeded
<mdz> pitti: it isn't in ubuntu-meta
<mdz> and it wasn't removed from ship
<ogra_> mdz, we dont have an UI freeze this time on the release schedule, was that an oversight ?
<ogra_> crimsun, what about the libasound split ?
<seb128> Mithrandir: could you give a build retry on all archs for gnome-python-desktop ?
<crimsun> ogra_: meaning the alsa-plugins split?
<ogra_> yeah
<crimsun> ogra_: if you don't mind, deferred til post-Herd 3
<ogra_> do you plan to do it ? else i'll just disable jack and do a MIR
<ogra_> ok
<crimsun> ogra_: that's fine (disable jack and do an MIR)
<pitti> if you talk about an MIR for jack, that won't happen with the current package
<crimsun> pitti: no, alsa-plugins.
<ogra_> as long as no jack users show up at my door at least :)
<ogra_> pitti, i need alsa-plugins ... for ltsp ... but you wont like jack in main i guess :)
<pitti> right, otherwise we have to cripple it again
<ogra_> the proper solution would be a package split but we wont manage that before FF ... so i'll just disable jack
<dholbach> Mithrandir: just FYI gtkmm2.4 and telepathy-idle updates are not important to herd3
<mvo_> Mithrandir: new app-install-data uploaded, thanks for reminding me about it
<Mirv> is there any eta when approved packages in MainInclusionQueue are actually going in main? malaga/voikko packages have been there in accepted for a bit over 1,5 months now.
<Riddell> mvo_: when does the cdrom progress stuff get used in dist-upgrade tool?
<Riddell> Mirv: a core-dev has to add them to a seed and request they get promoted
<Mirv> Riddell: yeah, I noticed this new MainInclusionProcess-page which mentions the seed. so after acceptance it's still up to the "driver" of the main inclusion to poke a proper core-dev to actually add the packages into a seed? otherwise they'll just stay in the Accepted queue?
<Riddell> Mirv: yes
<Mirv> Riddell: thanks.
<mvo_> Riddell: when the user runs the upgrader from a cdrom 
<Riddell> mvo_: so user puts in a new alternate CD and the dist-upgrade tool gets run?
<mvo_> Riddell: yes
<mvo_> Riddell: he can run it manully with /cdrom/cdromupgrade
<Riddell> mvo_: what does that run?
<mvo_> Riddell: the dist-upgrader gets put onto the cdrom, the script extracts it and runs it
<Mirv> pitti: Poke. bug #82143. concerning openoffice.org-voikko, a rebuild should be commenced to update the (because-of-ooo-problems-with-extensions) package's conflicts-dependencies. possibly the dependency generation should be also adjusted to most optimal value for feisty if needed.
<Ubugtu> Malone bug 82143 in language-support-fi "Add main-accepted Voikko packages to a seed, language-support-fi should depend on Voikko spellchecking libraries in 7.04" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82143
<Riddell> mvo_: clever
<Riddell> mvo_: apart from the cdrom stuff being missing, kde dist-upgrader seems to be working well, I've some tidying up to do and the packaging to sort out but then I may merge and upload if that's good with you
<mvo_> Riddell: let me knwo when I should merge. the upload is a bit special, its a special target to get it into the "dist-upgrader" repository
<Riddell> mvo_: where is the dist-upgrader repository?
<mvo_> Riddell: https://code.launchpad.net/~ubuntu-core-dev/+branch/update-manager/main
<mvo_> Riddell: that is the code
<mvo_> Riddell: http://archive.ubuntu.com/ubuntu/dists/feisty/main/dist-upgrader-all/
<mvo_> that is the binary
<Riddell> mvo_: ok, I'll let you know when
<mvo_> thanks
<gnomefreak> guys nice job on apport i love it.
<heno> Mithrandir: I've posted a draft of the testing instructions here: https://wiki.ubuntu.com/Testing/ForumProject/Instructions Please check it for sanity at your leisure
<givre> gnomefreak: wanted to say the same things. Apport rocks :)
<gnomefreak> i just wish it didnt bring you to LP but i guess it kind of has to
<pochu> hi heno :)
<heno> pochu: hello :)
<pochu> i'm looking at your instructions page
<heno> pochu: cool, please make changes as you see fit
<ogra_> mdz, found the g-p-m brightness bug, thanks for pointing
<ogra_> (fixed in the next upload)
<mdz> ogra_: cool, thanks
<pitti> cjwatson, Mithrandir: how do I update syncs/Debian_incoming_main_Sources on drescher?
<doko> hi
<pitti> Mirv: can you please add that to the bug, so that I won't forget?
<cjwatson> pitti: it's done by hand using dpkg-scansources whenever somebody asks us to sync from incoming
<cjwatson> i.e. grab the source package with lftp and then scansources it so that sync-source will work
<pitti> ah, there's no script for it then
<cjwatson> right
<pitti> cjwatson: thanks
<cjwatson> likewise Debian_snapshot_*_Sources
<cjwatson> kwwii: do you have any thoughts as to what image format you'd like to use for ubiquity-slideshow? svg, png, jpg, something else?
<kwwii> cjwatson: png or svg would be good
<kwwii> cjwatson: it would depend on what they look like vs. file size/quality
<Mirv> pitti: ok
<cbx33> any ubuntu-archive members around?
<cbx33> I have a licensing question
<Mirv> (done)
<cjwatson> ogra_: http://cdimage.ubuntu.com/edubuntu/daily/current/
<ogra_> whee !!!
<ogra_> 7M already ? wow ...
<ogra_> i thought tuxtype was smaller :)
<cjwatson> there's probably some junk in the images
<ogra_> i'll check then
<cjwatson> actually, no, very little junk
<cjwatson> -r--r--r--   6    0    0         6752204 Jan 24 2007 [    105 00]   tuxtype-data_
<cjwatson> 1.5.6.dfsg1-3ubuntu4_all.deb
<cjwatson> it just is about that big
<ogra_> heh
<cbx33> cjwatson, just looked on the pyvnc2swf site
<cbx33> License
<cbx33> Vnc2swf comes with ABSOLUTELY NO WARRANTY. This software is distributed under the GNU General Public License. 
<ogra_> then they are likely wrong
<cbx33> indeed
<ogra_> i dont think the at&t part works with the gpl
<cjwatson> 17:38 <cjwatson> either upstream resolves it (perhaps by talking to the original copyright holders, perhaps by deciding that there's nothing left in the code to which that copyright applies, or perhaps by
<cjwatson>                  rewriting the offending portions of code), or we get specific permission from the named copyright holder (which is going to be pretty difficult as that AT&T lab in Cambridge doesn't exist any
<cjwatson>                  more), or we use something else
<cjwatson> 17:38 <cjwatson> or we find something distributed by the copyright holder with a clearer and more permissive licence
<cjwatson> 17:38 <cjwatson> (you may find that it was just badly quoted)
<cjwatson> (from conversation with cbx33)
<ogra_> yeah
<cbx33> sorry cjwatson I should have done it in here
<mdz> mvo,iwj,seb128: I just tried out easy-codec-installation. nice!
<cjwatson> I don't recall AT&T Cambridge normally using restrictive licences like that
<seb128> mdz: good :)
<mdz> mvo_: what is the behaviour if the user doesn't have multiverse enabled?
<cjwatson> so you may find that it's just a mistake
<mvo_> mdz: it will offer you to automatically add it for you
<seb128> mdz: I will send a mail about it soon, I wanted to do it this morning but gnome-app-install was "just crashing" due to python-dbus change
<mdz> mvo_: when? and with what caveat?
<seb128> which mvo fixed quickly ;)
<seb128> what is the appropriate list for mails like that?
<mdz> seb128: yes, I had to install 0.3.9 to fix that
<ogra_> cjwatson, hmm, btw, that makes me wonder if its really that clever that i copyright new code i write with "Canonical Ltd."
<mdz> pitti: apport caught the crash and directed me straight to the bug report :-)
<cjwatson> ogra_: if you're doing it on work time, you don't have an option
<mvo_> mdz: when multiverse is not enabled the codec will be displayed. when the user clicks on it it will tell him that he needs multiverse to actually get it and offer to automatically add it. then it runs a apt-get update (via synaptic) to make it available
<cjwatson> ogra_: unless your contract differs rather radically from mine
<ogra_> nope, it doesnt
<mdz> mvo_: what if it's enabled in sources.list, but the user hasn't "enabled" it yet (a la enabling-additional-components)?
<ogra_> just the " (which is going to be pretty difficult as that AT&T lab in Cambridge doesn't exist any mopre)" made me think about it ...
<cjwatson> ogra_: if you're releasing code under a free licence, it's not a problem
<ogra_> rigfht
<ogra_> *right even
<mvo_> mdz: when we enable universe/multiverse by default, there will be a message when the first universe/mutliverse program is added.. the messages will tell the user that the support for this application is limited. this is not yet enabled though because the switch in the installer is now yet flipped
<pochu> heno: ping?
<heno> pochu: pong
<pochu> heno: would be possible to change the bug contact for ubuntu iso test tracker to the iso testing team, in order to receive the mails about bugs?
<mdz> mvo_: sounds good.  is the rest of enabling-additional-components done, with only the installer remaining?
<heno> pochu: Are you sure that's wise? There will be *very* many emails. Easily several hundred in 2-3 days
<pochu> heno: hundred?
<heno> as images are posted, tested and rejected
<mvo_> mdz: kde changes are pending, otherwise we should be ready
<pochu> heno: then I'm not sure :)
<heno> 30odd images posted, then rejected and/or accepted, commented on, etc
<heno> When you subscribe you get mail just for that image
<heno> and only while it's active
<heno> we should probably have all the messages go to some email address, a list with a public archive perhaps
<pochu> maybe you can create a ML in lists.ubuntu.com
<mdz> mvo_: excellent
<heno> If there really is a need. Herd 4 feature request IMO
<heno> pochu: could do, but the list is already quite long there
<pochu> heno: not sure what you want to say
<mvo_> Mithrandir: when can we except the freeze for herd-3 (roughly)? tonight? tomorrow morning? later?
<heno> pochu: one should be slightly restrictive about creating lots of mailing lists, as the tend to pile up
<pochu> heno: oh, ok
<pochu> now I understand you :)
<heno> one for ISO testing discussion is probably useful though
* pochu should improve his english skill :)
<heno> no worries :)
<pochu> sure
<heno> pochu: any comments on the howto?
<pochu> and if a testing discussion is made, then we maybe should change the contact address for the iso testing team
<heno> I should post it today
<pochu> heno: i'm doing a few changes
<pochu> 5 minutes :)
<pochu> well, they are links
<heno> pochu: ok, I'm off to eat, bbl
<pochu> if you don't mind
<pochu> ok
<pochu> :)
<pitti> mdz: yay :)
* mvo grumbles about his network
<pochu> heno: done :)
<heno> pochu: that looks good, thanks
<tkamppeter_> pitti, can you quickly upload HPLIP 1.7.1, so that it makes it into Herd 3 (we are shortly before freeze, see "Herd 3 freeze imminent" on mailing list), fixes bug 60242, bug 66830, bug 74809, bug 77307 (and probably more).
<Ubugtu> Malone bug 60242 in hplip "Removing hplip encounters errors: scanner group not empty" [Low,Fix committed]  https://launchpad.net/bugs/60242
<Ubugtu> Malone bug 66830 in python-qt3 "Problem with Socket Inter-Process Communication" [Medium,Confirmed]  https://launchpad.net/bugs/66830
<Ubugtu> Malone bug 74809 in hplip "dpkg -P hplip fails in ubuntu-6.10-desktop live cd" [Low,Fix committed]  https://launchpad.net/bugs/74809
<Ubugtu> Malone bug 77307 in hplip "hp-setup fails with setupform import" [High,Fix committed]  https://launchpad.net/bugs/77307
<pitti> tkamppeter_: doing so now; you forgot -sa when building the .changes, BTW
<kwwii> cjwatson: first we should make a decent list of what exactly needs to be presented
<BenC> $ ps ax | grep dbus-daemon | wc -l
<BenC> 17
<BenC> wtf?
<beuno> hey, I'm trying to cook up the "Herd 3" changes page, can anyone give me the highlights from "Herd 2"?
<somerville32> beuno, Just take a peak at the Herd 2 page :)
<mdke> somerville32: he means the highlights *since* herd 2 :)
<somerville32> ah, lol
<somerville32> Lots in the Xubuntu department ;] 
<jdong> good answer
<jdong> "There's been lots of shiny buttons and ..... "
<jdong> supertux 0.3! :D
<pochu> beuno: I think the uwn has the weekly highlight, maybe you can take a look there
<keescook> Mithrandir: (or other archive admins) it looks like due to a packaging change in the acroread security update for dapper/breezy, the binary package "acroread-escript" entered NEW.  Can someone fix that up?
<beuno> pochu, yes, I have all those, I do the writeup every week  ;)  just wanted to know if there is anything specific you want to highlight
<beuno> mdke, I did mean *since*, sorry it wasn't clear enough
<mdke> :)
<pochu> beuno: ok, didn't know it :)
<beuno> pochu, np, I should of read through what I wrote before sending  ;)
<Mithrandir> mdz_: network-manager -> desktop has happened, but needs -meta upload, I'll do that.
<Mithrandir> keescook: investigating.
<Mithrandir> mvo: thanks.  Freeze starts tomorrow.
<Mithrandir> heno: thanks, I'll poke
<keescook> Mithrandir: thanks
<Mithrandir> heno: can we add a irc nick/email column to the "Signed up for testing" table on https://wiki.ubuntu.com/Testing/ForumProject
<gota> hola
<gota> speacjing spanish?
<gota> speacking*
<nedko> hi guys, i'm looking for someone that would create ubuntu package for jack_mixer (jack audio mixer)
<nedko> i really dont use ubuntu but ubuntu users often ask me for instructions how to build it
<heno> Mithrandir: can do, or LP ID even? As that is what will appear on the bug comments
<Mithrandir> heno: LP id is good.
<TheMuso> nedko: Might want to ask in #ubuntu-motu
<nedko> TheMuso: thanks
<Mithrandir> hmm, there's an ancient lrm in breezy-security's new queue.
<Mithrandir> but only for sparc
<Mithrandir> keescook: both accepted.
<keescook> Mithrandir: cool, thanks
<gnomefreak> is jono on holiday?
<pochu> gnomefreak: no, I talked to him this afternoon
<gnomefreak> mvo_: g-a-i 3.10 fixes the dbus error right?
<gnomefreak> pochu: ty
<pochu> gnomefreak: np ;)
<mvo_> gnomefreak: yes, it should
<gnomefreak> ty :)
<gnomefreak> btw update-manager is fixed thank you for that :)
<heno> Mithrandir: done, and cleaned it up a bit too. I guess I should clean up Testing/Current too with sensible links and such
<Mithrandir> heno: thanks.
<mvo_> gnomefreak: cheers :)
* mvo_ goes to bed
<gnomefreak> night
<heno> Mithrandir: are the bugs at the end of Testing/Current still relevant or should I flush them all (or leave the still open ones?)
<Mithrandir> heno: just flush them
<Mithrandir> and with that, I'm off to bed
<heno> ok
<slomo> Mithrandir: hi... there will be a new tomboy release in an hour or something... can i upload it before herd 3 freeze? it fixes a bad note corruption bug that some people had
<mdke> sfllaw: around?
<pochu> gnomefreak: ping?
<gnomefreak> yeah?>
<gnomefreak> jono_: you busy?
<jono_> jono_: a little, but shoot :)
<gnomefreak> jono_: can you join #nunstuff for a bit
#ubuntu-devel 2007-01-30
<bhale> Mithrandir: could you please process beagle in new before herd3?
<bddebian> Heya
<Tonren> Hey guys, can anyone humor me for a few minutes while I ask a few questions about why Ubuntu networking works the way it does?
<shackan> everybody's asleep and I'm not the right person to answer, but what do you mean ?
<Tonren> shackan: Well, I've done a lot of configuring and re-configuring on multiple Ubuntu setups (server, desktop, laptop, etc.), and I've installed, been disgusted with and uninstalled numerous GUI helpers, and in general, I'm just a little fuzzy on why networking is such a pain in the ass on Ubuntu.
<Tonren> (I don't have much experience with other distros, so it may be Linux in general, but I haven't heard nearly as many horror stories from users of other distros.)
<Fujitsu> I find the GUIs (especially NetworkManager) to be fine.
<Tonren> Fujitsu: NetworkManager *literally* became a nightmare for me.  I had so much trouble with it that it actually disturbed my sleep one night.
<Fujitsu> I've not had trouble since 0.5 or so.
<Tonren> It was slow, buggy, inconsistent, crash-prone and unclear.
<Fujitsu> (which was ages ago)
<Tonren> When I tried it again a few weeks ago, it still was.  :\
<Fujitsu> I've never had it crash or be buggy.
<Fujitsu> Nor slow...
<shackan> Tonren, I have to agree on network manager
<Tonren> I would create a "Home" location, but the next time I logged in, my location was "".  I tried changing it to "Home", but when it tried to configure eth0, it sat there for ten minutes and then crashed.
<Fujitsu> Unsuitable in some cases, perhaps. But in quite a number of cases, it's great.
<Fujitsu> Oh, that's not Network Manager...
<shackan> but I've just saved three profiles and occasionally switch between them
<Tonren> shackan: I couldn't even get it working right with two profiles.
<Fujitsu> That's gnome-system-tools' network configuration thing, and the profiles are known to be totally screwed.
<Tonren> Okay... so, gnome-system-tools' networking is the actual GUI thing, and NetworkManager is the systray applet.  Right?
<Fujitsu> NetworkManager is completely independent from the g-s-t application.
<shackan> well, the applet is just the NetworkManager applet, there's a daemon behind it
<Fujitsu> It sits in the systray, but isn't a panel applet.
<Tonren> Right, so there's a NetworkManager daemon and nm-applet.  Is that right?
<Fujitsu> Correct.
<Tonren> Anyway - I tried to get the systray applet working for about a week (I must have spent between 1 and 2 hours on it a day, in #ubuntu and browsing the forums), and it just would not play nice with any of my network connections.  The same story - lag, error.  Lag, crash.  Lag, lag, nothing.
<Tonren> Manually configuring my network interfaces on teh command line has *always* worked flawlessly
<Fujitsu> I've not had issues.
<Fujitsu> It seems that NetworkManager and g-s-t behave fairly well together in Feisty, which is good.
<Tonren> Once I login, I can do sudo -su; ifconfig eth0 up; dhclient -1 eth0; or ifconfig wlan0 up; iwconfig wlan0 ap any; iwconfig wlan0 essid any; dhclient -1 wlan0;
<shackan> Tonren, that's still the only way to get it done right
<shackan> (at least for me)
<Tonren> Those two things are like charms - they ALWAYS work.  But as soon as I try to get anything configured *automatically*, be it through /etc/network/interfaces, or g-s-t or NM, everything goes to hell.
<Tonren> shackan: Same here
<Tonren> What shocks me is this.
<mjg59> Could people please have this discussion somewhere else?
<Fujitsu> mjg59, probably a good point.
<mjg59> If there are specific bugs, please report them
<mjg59> Mentioning them in here at this time of day isn't likely to result in any devs picking up on them
<Tonren> mjg59: Sorry... I'm not sure where else to talk about this.  It's not *development*, per se, but it doesn't really belong in #ubuntu which is mainly a one-to-one support channel.
<Tonren> shackan: Fujitsu: Are you guys both in #ubuntu-offtopic?
<shackan> no way, irc is already a great waste of time per se, no need for offtopic channels :)
<Tonren> shackan: That's what I think, too.  ;P
<Tonren> mjg59: With all due respect, while our discussion isn't strictly dev-related, I don't think it is really negatively affecting the channel.
<mjg59> Tonren: With all due respect, you're welcome to feel that :)
<Hobbsee> uh oh, udev update.  wonder if it breaks
<shackan> so we can stop it here and not bug mjg59 further, as far as I'm concerned some wonderkind needs to rewrite a g-s-t done right from scratch, and it's not going to happen, I'm happy typing commands, I don't care if my aunt can't configure her network, she's not using ubuntu anyway
<Tonren> Wow.
<mjg59> But the fact that the channel is fairly idle isn't a great excuse for off-topic discussion
<Hobbsee> shackan: Tonren Fujitsu try #ubuntu-networking
<Tonren> Fair enough.
<Tonren> Hobbsee: Thank you.
<Hobbsee> mjg59: yay, quiet :)
<Hobbsee> mjg59: offhand, do you know who moderates kubuntu-devel?
* Hobbsee needs that message to go thru *now*
<Hobbsee> er, more like when i sent it
<Hobbsee> ah, Riddell only
<Hobbsee> yay, OK, we're not frozen yet
<Hobbsee> any core devs around to sponsor an upload?
<fabbione> morning
<fabbione> Hobbsee: what package?
<Hobbsee> fabbione: kopete
<fabbione> Hobbsee: do you have a debdiff somewhere
<fabbione> ?
* Hobbsee watches fabbione say "oh please no, i dont deal in kde"
<Hobbsee> fabbione: yup.  http://wedontsleep.org/~sarah/kdenetwork.debdiff
<fabbione> +--- kdenetwork/kopete/plugins/latex/kopete_latexconvertnew.sh	2007-01-30 15:07:41.000000000 +1100
<fabbione> ++++ kdenetwork/kopete/plugins/latex/kopete_latexconvert.sh	2005-09-10 18:20:16.000000000 +1000
<fabbione> +@@ -1,4 +1,4 @@
<fabbione> +-#!/bin/bash
<fabbione> ++#!/bin/sh
<fabbione> why not fixing the script to be POSIX shell compliant?
<Hobbsee> argh, dammit.  i diff'd teh wrong way around there?
<fabbione> that too..
<Hobbsee> it doesnt work as /bin/sh
<fabbione> right but that's because the script is not portable..
<fabbione> why not fixing the script instead of forcing bash?
<Hobbsee> hrm.  i suppose "lazyness" isnt a good answer
<Hobbsee> neither is "i dont know how to"
<Hobbsee> https://launchpad.net/ubuntu/+source/kdenetwork/+bug/71665 is the corresponding bug
<Ubugtu> Malone bug 71665 in kdenetwork "Problem with kopetex" [Undecided,Fix committed]  
* Hobbsee updates the diff to be the right way around.
<fabbione> Hobbsee: well i understand the bug, but it would be more wise to fix the script in the long run.. anyway it's ok to change sh to bash.. 
<fabbione> it's just better to make the script portable as general case and where possible
<Hobbsee> fabbione: yeah, of course.  i sent it upstream.  i'm not versed in latex though
<fabbione> i stay away from latex.. it sounds too much like some BDSM thingy
<Hobbsee> hehehe, *exactly*
<fabbione> well ping me when you have the debdiff
<Hobbsee> fabbione: the updated one with /bin/bash and /bin/sh around the right way?  i'ts there now.
<Hobbsee> [16:08]  * Hobbsee updates the diff to be the right way around.
<Hobbsee> was there 8 min ago :)
<fabbione> oh well i thought you were still doing it
<Hobbsee> nope
<fabbione> hey i just woke up and didn't finish my first cup of STFU yet..
<Hobbsee> hehe :)
* Hobbsee has icecubes...
<fabbione> did you fix the patch manually?
<Hobbsee> yeah
<Hobbsee> then tested it
<Hobbsee> ie, it does patch
* Hobbsee wishes her desk would stop growing paper.
<fabbione> Hobbsee: do you realize that ubuntu3 has been uploaded by Jonhatan?
<fabbione> patch -p1 < ../kdenetwork.debdiff 
<fabbione> patching file debian/control
<fabbione> Hunk #2 FAILED at 130.
<fabbione> Hunk #3 succeeded at 141 (offset 1 line).
<fabbione> Hunk #4 succeeded at 276 (offset 1 line).
<fabbione> 1 out of 4 hunks FAILED -- saving rejects to file debian/control.rej
<fabbione> patching file debian/changelog
<fabbione> Hunk #1 FAILED at 1.
<fabbione> 1 out of 1 hunk FAILED -- saving rejects to file debian/changelog.rej
<Hobbsee> fabbione: dammit.  didnt know it existed, it hasnt been published.
<fabbione> well i just did apt-get source kopete
<fabbione> and that's what i got
<fabbione> it is published.. i am sure about it
<fabbione> otherwise it wouldn't be on my local mirror
<Hobbsee> fabbione: what was the full versoin?
<fabbione> kdenetwork_3.5.6-0ubuntu3.diff.gz
<fabbione> that's what i have here
<Hobbsee> dammit.  not on the gb. mirror yet
<fabbione> use archive.ubuntu.com directly
<fabbione> gb. is a mirror
<fabbione> gotta go for a while now...
<Hobbsee> thought that gb. was the data centre
<Hobbsee> okay
<Hobbsee> will have to redo that patch anyway.
<Hobbsee> sod.
<fabbione> Hobbsee: send me an updated debdiff and i will upload later
<fabbione> i need to feed my son :)
<Hobbsee> fair enough :)
<pitti> Good morning
<ajmitch> morning pitti 
<Fujitsu> Hi pitti, and thanks for the azureus acceptance.
<fabbione> hey pitti
<pitti> hey ajmitch 
<pitti> moin Fujitsu 
<Mithrandir> slomo: tomboy> please upload.
<Mithrandir> bhale: new beagle> will do
<pitti> cjwatson: I need a minute to talk with you about bug 78862
<Ubugtu> Malone bug 78862 in gnome-volume-manager "automatically mounts created file systems on live CD" [Critical,In progress]  https://launchpad.net/bugs/78862
<pitti> cjwatson: in particular, I'd like to know whether/how ubiquity disables g-v-m and unmounts already mounted partitions
<Mithrandir> pitti: it pokes some gconf key.
<pitti> Mithrandir: right
<pitti> Mithrandir: do you know whether it unmounts hard disks from /media?
<pitti> before attempting to repartition
<Mithrandir> I'd think so, but I'm not sure.
<dholbach> good morning
<pitti> hey dholbach 
<dholbach> hey pitti
* dholbach hugs pitti
<pitti> hey seb128! *hug*
<seb128> hey hey pitti
* seb128 hugs pitti
<seb128> grumpf
<seb128> most of backtraces are "??"ish
<pitti> that's so weird
<seb128> yeah :/
<Treenaks> is there a way to find which module would be loaded if I inserted a device with USB id 'X' ?
<Treenaks> or should I just modinfo everything and grep?
<pitti> seb128: do you want to upload edgy-proposed nautilus for bug 73021?
<Ubugtu> Malone bug 73021 in nautilus "fm_tree_model_unref_node fails ref_count > 0 assert" [Unknown,Fix released]  https://launchpad.net/bugs/73021
<seb128> pitti: yep, thank you for the reminder, Colin replied during the sprint and I didn't have an edgy box handy to do it
<pitti> seb128: great; please update the description a bit for people who are looking at that bug
<seb128> well
<dholbach> ogra_: did you look into the pulseaudio fix?
<seb128> pitti: "nautilus crash in random circumstance for users, see upstream number of duplicate"?
<seb128> pitti: I'm not sure on what is useful to the description out of the fact that's a crasher and upstream is getting many duplicates which means it happens for many people
<pitti> seb128: something like that, 'nautilus crashed unbearably often'
<seb128> ok
<pitti> seb128: I'm just reviewing the current huge pile of SRUs and see what can be cleaned up
<seb128> pitti: updated description is ok?
<pitti> seb128: WFM, thanks!
<seb128> pitti: np, package uploaded as well
<seb128> thank you for the reminder ;)
<pitti> will process it in a minute
<seb128> excellent
<pitti> LaserJock: ping
<pitti> LaserJock: can you please upload your fix to bug 75021 to edgy-proposed?
<Ubugtu> Malone bug 75021 in python-imaging "SRU: python-imaging missing dependencies (edgy)" [Unknown,Fix released]  https://launchpad.net/bugs/75021
<pitti> ah, no, you can't
<pitti> hi mvo
<LaserJock> pitti: nope, I can't, it isn't already in the queue for ubuntu-archive approval?
<pitti> LaserJock: no, I'm just preparing/doing the upload
<pitti> LaserJock: it has been approved a month ago
<LaserJock> hmm, I had thought ajmitch had uploaded it for me
<LaserJock> oops
<ajmitch> I thought I had, maybe not?
<pitti> LaserJock: uploaded, I'll accept the -proposed one in some minutes
<ajmitch> sorry, LaserJock 
<LaserJock> ajmitch: np
<pitti> LaserJock: but please do the QA bits
<LaserJock> pitti: thanks
<LaserJock> pitti: will do
<ajmitch> pitti: so how much are we allowed to bug you about archive stuff? is it back to regular archive days for people?
<pitti> argh, phone
<pitti> ajmitch: I shall mainly care for SRUs now, but also doing syncs etc.
<pitti> ajmitch: Mithrandir, Keybuk, cjwatson, seb128 and me need to sit down and do a new 'archive days' schedule and talk about responsibilities
<ajmitch> ok
<pitti> mvo: can the feisty task be closed on bug 75273? (I assume so, SRUs should be fixed in feisty first, but still...)
<Ubugtu> Malone bug 75273 in apt "Apt constantly sigsevs on edgy" [Unknown,Fix released]  https://launchpad.net/bugs/75273
<pitti> mvo: also, please upload your fix for bug 47044
<Ubugtu> Malone bug 47044 in apt "apt cant work with disable proxy" [Unknown,Fix released]  https://launchpad.net/bugs/47044
<mvo> pitti: I updated the bug status for bug 75273
<Ubugtu> Malone bug 75273 in apt "Apt constantly sigsevs on edgy" [Unknown,Fix released]  https://launchpad.net/bugs/75273
<mvo> pitti: and will now do bug 47044
* pitti hugs mvo, thanks!
* mvo hugs pitti for taking care of all this
<tepsipakki> rodarvus: ping, i810 on dapper
<pitti> seb128: urgh @ the patch for bug 56610 
<Ubugtu> Malone bug 56610 in firefox "Automatic search from address entry doesn't work anymore" [Unknown,Fix released]  https://launchpad.net/bugs/56610
<seb128> pitti: well, it's basically "trust upstream and the fact it's working in feisty for months now"
<seb128> pitti: and epiphany browser is not the default browser anyway
<pitti> seb128: first that, and second the bug doesn't seem to fall into the 'the sky has fallen' category we usually fix for stables
<seb128> well, it fall into the "it really annoys epiphany users and they would appreciate to get it fixed"
<pitti> seb128: ok, if you are confident that it works, I'll trust you
<seb128> as said it has got plenty of testing on feisty
<seb128> (and other distro which updated to GNOME 2.16.2)
<pitti> seb128: it's just that the patch itself is unverifyable (e. g. domWindowPrivate ptr is not checked for NULL, etc)
<pitti> ok
<seb128> well, if you prefer we can drop the update
<pitti> seb128: well, go ahead then, having it in -proposed would be nice
<seb128> but I think it's not a real risk and it'll make users happy
<seb128> ok, thank you
<pitti> mvo: can you please add proper backport tasks to bug 68553, point out the feisty status, and explain whether both the dapper/edgy or just the dapper update of python-apt is needed?
<Ubugtu> Malone bug 68553 in update-manager "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Confirmed]  https://launchpad.net/bugs/68553
<visik7> hi
<visik7> is there any plan to build a package of vmware-server like the one for vmware-player ?
<visik7> for feisty ?
<pythonmaster> hie everyone
<Chipzz> vmware player doesn't even work with feisty or edgy
<pythonmaster> i have a big problem
<Chipzz> not the current release
<Chipzz> the joys of dbus crap
<pythonmaster> i want to upgrade dapper to edgy from live-install cd 
<pythonmaster> someone can help me?
<pythonmaster> this is very important
<visik7> Chipzz: there is the package for vmware-player 
<pythonmaster> coz i amke some mistakes and that now my dapper look like very bed
<visik7> is it not working ?
<pythonmaster> plz help me i am googling for hours
<Chipzz> visik7: that doesn't work
<siretart> could anyone please point me to the procedures on how to edit the Maintainer field when merging debian packages with ubuntu-local changes?
<visik7> oh ok
<pythonmaster> how can i upgrade from edgy cd?
<thom> pythonmaster: #ubuntu is the channel for support requests
<pythonmaster> but they arent help me !!
<visik7> strange a friend of mine use vmware player (the packaged version
<pythonmaster> its very strong problem
<thom> pythonmaster: it doesn't matter. this is not the correct channel for support.
<pythonmaster> you thing so simple
<siretart> https://wiki.ubuntu.com/DebianMaintainerField
<pythonmaster> and easy
<Chipzz> visik7: it works on dapper. not on edgy or feisty
<visik7> let me see
<pitti> mvo: FYI, I added some more comments to bug 68553
<Ubugtu> Malone bug 68553 in update-manager "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Confirmed]  https://launchpad.net/bugs/68553
<Chipzz> pythonmaster: no, people here are trying to get work done. it's as simple as that
<mvo> pitti: thanks, I'm updating the diff now
<visik7> Chipzz: actually here works on edgy 
<visik7> I'm running it right now
<mvo> pitti: bug 68553 updated
<Ubugtu> Malone bug 68553 in update-manager "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Confirmed]  https://launchpad.net/bugs/68553
<pythonmaster> hmm
<pitti> mvo: apt/dapper-proposed accepted
<mvo> pitti: thanks!
<pitti> mvo: the update-manager task is for the dist-upgrader patch?
* mvo hugs pitti for going over those SRUs
<mvo> pitti: yes
<pitti> mvo: and it's not fixed and tested in feisty yet?
<mvo> pitti: its fixed and tested in feisty, let me update the tasks. I used only milone targets for those bugs
<pitti> sorry for being anal about it, but I'd like to see the bug statuses in good shape so that I can keep track properly
<mvo> it was when the "backport to release" link disappeared
<mvo> and I had not yet discovered the new one
<pitti> 'target to release'
<mvo> I know
<mvo> now
<mvo> pitti: being strict about this is fine, I will update the status
<visik7> Chipzz: I can't find any bug on launchpad about problems running vmware-player in edgy or feisty, and actually I haven't any problem with vmware-player
<pitti> mvo: ok, if you wish, please go ahead with 68553
<mvo> pitti: thanks, I uploaded the package to dapper-proposed and edgy-proposed
<Mithrandir> mvo: care to poke at 77620 today?
<Mithrandir> siretart: regarding your openarena sync requests, they were done over a week ago, they've just not been NEWed.
<mvo> Mithrandir: yes
<siretart> Mithrandir: oh. Sorry, I didn't notice that NEW processing is currently lagging a bit
<cjwatson> visik7: the live/desktop CD doesn't support upgrades; you need the alternate install CD for that
<cjwatson> pitti: I set /desktop/gnome/volume_manager/automount_drives and /desktop/gnome/volume_manager/automount_media to false
<pitti> cjwatson: right
<cjwatson> pitti: I don't believe anything unmounts stuff from /media
<pitti> cjwatson: I added a bug comment, it seems to be an inconsistent handling of gconf key setting in ubiquity
<cjwatson> hmmm
<cjwatson> it's not impossible I guess, but that's really really weird
<cjwatson> it's definitely done in code common to both auto and manual partitioning
<cjwatson> pitti: want to eyeball it for me? ubiquity/frontend/gtkui.py in the ubiquity source package, search for 'def progress_loop'
<cjwatson> that's the only function that calls install.Install() which is what actually copies stuff to disk, so it's definitely called
<pitti> cjwatson: will do, after breakfast; thanks
<cjwatson> pitti: oh, would g-v-m notice partitions being created even before filesystems are created?
<cjwatson> pitti: gparted will create the partition and then partman will mkfs ...
<cjwatson> but the gconf fiddling is done in between those two
<cjwatson> I think the right answer is probably to disable g-v-m for the duration of ubiquity
<cjwatson> Mithrandir: what do you think about turning the new partitioner on by default for Herd 3?
<cjwatson> we talked about it briefly at Oslo - the more testing it gets early, the better
<cjwatson> but its UI is still incomplete
<Mithrandir> cjwatson: how incomplete is it?
<cjwatson> it's got the partition list but no pretty disk UI at the top
<cjwatson> so it's basically "double/right-click on items in this here listbox to do stuff"
<cjwatson> I'd suggest trying it out - ubiquity --new-partitioner
<Mithrandir> you want to test it so we can find out about stability problems, I presume?
<Mithrandir> since testing the UI wouldn't be useful at this point
<cjwatson> well, half the UI is there
<cjwatson> but yes, basically
<cjwatson> the underlying partman interaction is roughly the way I want it, modulo optimisation and features
<cjwatson> so if that's breaking for people, I'd like to know
<Mithrandir> ok
<cjwatson> maybe a couple of core-devs other than me should try it first
<Mithrandir> I could try it in a bit
<cjwatson> pitti: I've committed an alleged fix, but I'm in the London office today and I'm not sure I have any means to test it
<cjwatson> it's in sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubiquity/trunk/
<mdz> seb128: thanks for looking after my bug 82153.  who is maintaining ubuntulooks now, if anyone?
<Ubugtu> Malone bug 82153 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV (dup-of: 66222)" [High,Confirmed]  https://launchpad.net/bugs/82153
<Ubugtu> Malone bug 66222 in ubuntulooks "gnome panel segfault/crash " [Medium,Confirmed]  https://launchpad.net/bugs/66222
<seb128> mdz: no real maintainers, the guys who work on it at the London sprint last year fix a bug every now and then and that's about it
<mvo> pitti: apport-gtk crashs currently and when I close it, I get a crash again and the dialog pops up
<mvo> pitti: hm, clicking on report problem makes it crash too
<pitti> mvo: traceback appreciated
<mvo> pitti: bug #82267
<Ubugtu> Malone bug 82267 in apport "apport-gtk keeps crashing" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82267
<mvo> pitti: I leave it in the state for now if you want me to test anything
<pitti> mvo: great, thank you!
* netjoined: irc.freenode.net -> brown.freenode.net
<pitti> argh, 18 unapproved things in dapper-updates
<Mithrandir> you can probably reject most of it, if it hasn't gone through the usual process.
<pitti> right, will cross-check with bugs
<pitti> cjwatson: just took a look at the ubiquity commit; I agree that it seems safer to disable gvm entirely while ubiquity runs
<pitti> cjwatson: folks can still mount their USB stick manually by clicking on the icon if they really want
<Hobbsee> pitti: at the kopete removal request - the kopete source that was used to build kopete-dev.  i think the kopete from that package has been superceded from the package built from kdenetwork
<bhale> Mithrandir: thanks!
<pitti> Hobbsee: ah, I see, kopete is now built from kdenetwork, too
<Hobbsee> pitti: indeed.  
<pitti> Hobbsee: alright, will remove the entire source package then
<Hobbsee> pitti: we forked, then added it back
<Hobbsee> pitti: as upstream was using an ancient version of kopete with lots of bugs in it, and distributing it with kde.
<pitti> Hobbsee: can you please put that into the bug report?
<Hobbsee> pitti: done
<Riddell> well, upstream did a separate release which we packaged
<Riddell> Hobbsee: kopete-meanwhile source and binary packages are also obsolete if you want to file a bug to remove them
<pitti> Hobbsee, Riddell: just add that to the same bug report, since it's related
<Hobbsee> Riddell: that's in mainstream kopete now, isnt it?
<Riddell> Hobbsee: yes
<Hobbsee> cool
<Hobbsee> pitti: done
<pitti> cjwatson: there are some installer-ish old dapper-updates uploads which haven't gone through SRU (apt-setup, germinate, installation-report, kickseed); what shall I do with them?
<heno> Gah, what to do with people filing their own tracker bugs? https://bugs.launchpad.net/ubuntu-iso-tests/+bug/82248
<Ubugtu> Malone bug 82248 in ubuntu-iso-tests "20070130: amd64, desktop, live, no network (vmware)" [Undecided,Unconfirmed]  
<heno> It's well intended, just not quite right, Mithrandir ^
<heno> I guess I should close it with some helpful advice
<cjwatson> pitti: probably reject them, I'll put them through the proper process if necessary
<pitti> cjwatson: alright
<pitti> cjwatson: shall I keep debdiffs for you, or do you have them?
<jwendell> will feisty be LTS?
<Hobbsee> jwendell: no
<jwendell> thanks, Hobbsee 
<maswan> will feisty+n be LTS?
<ogra_> maswan, fsvo n :)
<Treenaks> ogra_: and n>1 ;)
<maswan> Well, is it known that n will be >1 yet? How about >2?
<maswan> It came up in a discussion recently, how long we should stay off backporting newer kernels to dapper in the hope that there will be a new lts "soon". :)
<Mithrandir> personally, I think feisty+2.  Bigger will cause transition problems for organisations which need a bit of time to test the new one.
<Mithrandir> cjwatson: this morning's livefs failed due to ubiquity-frontend-gtk, care to investigate?
<elmo> Mithrandir: he'd have to be able to boot his machine first ;-)
<Mithrandir> elmo: ah, he's in London today.  I forgot.
<mjg59> elmo: I ought to be getting hold of an MBP shortly, so I'll be able to deal with most of the remaining issues
<cjwatson> pitti: it's ok, I've got them all
<cjwatson> Mithrandir: already dealt with - will upload shortly
<cjwatson> Mithrandir: (missing /usr/share/apport/ubiquity.py in the ubiquity binary)
* pitti makes a mental note to add a raise somewhere to check out the apport bits
<cjwatson> Mithrandir: had a chance to check out the new partitioner?
<cjwatson> maswan: it will be >1
<pitti> cjwatson: I prepared and tested new dapper langpacks (we need to re-roll the -base packages, because the current update tarballs from Rosetta are missing lots of stuff); do you have some time in the next days to walk me through the process of uploading/silently approving?
<pitti> s/approving/accepting/
<Mithrandir> cjwatson: no, sorry.   I'll do that now.
<maswan> Mithrandir: that will be good for us yes, >2 will probably become a bit too long
<maswan> cjwatson: *nods*
<cjwatson> pitti: probably not today, but tomorrow, yes
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for herd 3
<pitti> cjwatson: thanks
<cjwatson> Mithrandir: shall I upload ubiquity now to fix livefs generation, or wait for a new-partitioner decision? I haven't tested the fix for bug 78862 :(
<Ubugtu> Malone bug 78862 in ubiquity "automatically mounts created file systems on live CD on manual partitioning" [Critical,Confirmed]  https://launchpad.net/bugs/78862
<Mithrandir> cjwatson: but the fix for 78862 should be trivial?
<cjwatson> it's relatively simple but involved shuffling code around to completely different places
<Mithrandir> ok
<Mithrandir> cjwatson: I'm still rsyncing down the images, so if it's ok for you to wait an hour or so before a decision on the partitioner, that'd be good.
<cjwatson> sure
<fabbione> cjwatson: i think #81782 might be either udev or something in the installer.. would you mind (when you have time) to just look at it?
<cjwatson> fabbione: what's the correct module for this device?
<cjwatson> r8169 apparently
<fabbione> cjwatson: seems like it yes
<fabbione> the strange thing is that there is an interface entry but no auto?
<cjwatson> you're very quick to claim it isn't a kernel bug
<mvo> could someone please approve g-a-i for feisty? I uploaded it 4min after main was frozen and it contains some fixes for the EasyCodecInstall spec
<cjwatson> it's entirely possible that it is
<Mithrandir> mvo: looking
<Hobbsee> Mithrandir: how frozen is main?
<seb128> Hobbsee: frozen like uploads need review to be accepted
<Mithrandir> Hobbsee: depends on what you want to upload.
<fabbione> cjwatson: well d-i or the installer did find the interface and configure it. The driver works if configured manually or with dhcp (when adding auto eth0)
<fabbione> cjwatson: the driver is in the udeb
<cjwatson> fabbione: the kernel emits udebs. if the udebs are wrong then it's a kernel bug.
<Hobbsee> seb128: well, yeah.  was more a question of "how much persuading will be needed for it to be reviewed, instead of straight declined
<Hobbsee> "
<cjwatson> you do not have the evidence to claim that it is not a kernel bug
<fabbione> cjwatson: so for what i can see it's not a kernel bug. tho i might be wrong.. but the last comment was referred to brian reassining it to the kernel
<seb128> Hobbsee: well, what sort of change do you want to get accepted and why?
<Hobbsee> seb128: changes to kdenetwork
<Mithrandir> Hobbsee: for KDE stuff, I'll generally accept it if Riddell's happy with it.
<fabbione> cjwatson: it can still be a kernel bug.. but it has been reassigned to the kernel without proofs that is a kernel bug. basically the opposite of what you are trying to tell me
<cjwatson> then say "we don't know whether this is a kernel bug yet", not "This isn't a kernel bug"
<Hobbsee> fabbione: the latex guys dont want to make the script with sh, as apparently it breaks on bsd, if it's not bash.  go figure.
<fabbione> Hobbsee: well ok.. just send me a new dediff once you are ready
<fabbione> cjwatson: fair enough.
<Hobbsee> fabbione: Riddell's awake - might make more sense to get him to?  *shrug* - thanks for the offer
<fabbione> Hobbsee: ok even better
<cjwatson> fabbione: netcfg never emits an iface line without an auto line right above it. If that iface line was written automatically, then it wasn't by the installer. Personally I think it's much more likely that they added it by hand
<Mithrandir> mvo: accepted.
<fabbione> cjwatson: ok, thanks for looking into it.
<mvo> thanks Mithrandir!
<fabbione> cjwatson: mind if i quote you there?
<fabbione> oh you already did
<fabbione> nevermind
<pitti> seb128: eyed3 MIR approved
<seb128> pitti: danke ;)
<cjwatson> fabbione: see my update to the bug
<fabbione> cjwatson: good catch..
<fabbione> cjwatson: did you also notice my last comment?
<cjwatson> fabbione: yeah
<fabbione> ok
<Mithrandir> cjwatson: the new partitioner is.. fiddly.  I'll be happy to have it if I get a blurb I can insert into the announcement telling people about it and what you want to get bugs about and what you don't want to get bugs about.
<cjwatson> Mithrandir: fiddly> agreed
<cjwatson> help making it less fiddly also appreciated :-))
<cjwatson> I can give you a blurb, also including instructions on how to disable it
<Mithrandir> yes, please
<Tonio_> pitti: I fixed bug 75017, should be okay this time
<Ubugtu> Malone bug 75017 in kubuntu-default-settings "SRU: remove /.hidden file " [Undecided,Needs info]  https://launchpad.net/bugs/75017
<Mithrandir> cjwatson: we have a new kernel incoming too, so I'll need a d-i upload in a bit.
<cjwatson> sure, I can do that
<cjwatson> ubiquity's uploaded
<cjwatson> new kernel as in new ABI?
<Mithrandir> yes. :-/
<Mithrandir> ubiquity already approved
<pitti> Tonio_: ah, great
<pitti> Tonio_: ah, that looks better
<pitti> Tonio_: approved, see my latest bug reply
<Tonio_> pitti: thanks, I'll follow next step
* Mithrandir sighs.  Alternate oversized.
<Mithrandir> and -desktop ppc oversized.  Why does that keep growing?
<Mithrandir> cjwatson: got any idea for stuff to drop from the ppc alternate CD?  It's 6MB oversized.
<cjwatson> meh. give me a bit.
* jdub fists his home server
<Mithrandir> we could drop cvs from ship, it'd save about 1.6MB
<pitti> ++ :)
<pitti> we should maintain a 'FirstAgainstTheWall' page
<Mithrandir> pitti: we've done this too many times for that to really be useful.
<pitti> true
<kylem> heh
<pitti> tkamppeter: m2300w is FTBFS, thus I cannot yet approve for main; the other two drivers are ok
<bddebian> Heya
<Mithrandir> hmm, dropping foo2zjs and xfsprogs would get us more than 2MB
<cjwatson> please don't drop xfsprogs
<cjwatson> I get enough complaints about filesystems as it is
<Mithrandir> hm
<Mithrandir> got any other ideas?  ppc is becoming more and more of a problem. :-/
<cjwatson> I sort of question the usefulness of the ISDN stuff on powerpc
<Mithrandir> how would it save us?
<Mithrandir> I'm also wondering if we can do something about the eog/gthumb/f-spot duplication
<cjwatson> cue minefield
<Mithrandir> yeah.
<Mithrandir> can we drop the ltsp stuff from regular ship?  It doesn't save much, though..
<cjwatson> ogra: ^--
<cjwatson> ogra: as in non-Edubuntu
<Riddell> Mithrandir: daily-live kubuntu CD from today in decent shape
<Mithrandir> Riddell: the one where the livefs build failed due to ubiquity breakage?
<ogra> Mithrandir, why ?
<Riddell> Mithrandir: the one that ended up on cdimage
<cjwatson> ogra: the question is always "why not"
<Mithrandir> ogra: because the ppc CD is too big.
<cjwatson> there needs to be a reason for each item on the CD
<ogra> well, there are business reasons i think ... mdz always insisted to have it on regular ubuntu CDs as well
<cjwatson> Mithrandir: bzip2ing ttf-arphic-uming and ttf-baekmuk would save about 2.5MB
<ogra> ltsp itself is less than 200k
<ogra> or around 200k
<Mithrandir> ogra: no, it's closer to 1.25MB with dependencies.
<ogra> it pulls in a bunch of server bits though
<Mithrandir> cjwatson: that'd help a fair bit, yes.
<cjwatson> which of the deps aren't there already? mdz thought there were none
<cjwatson> Mithrandir: I'm about to be dragged into a meeting; if you want it now, doit, otherwise I can do it in a bit
<Mithrandir> dhcp3-server, for instance
<ogra> openbsd-inetd 
<ogra> openssh-server
<Mithrandir> mknbi, nbd-{client,server}
<Mithrandir> pulseaudio
<ogra> nfs-kernel-server
<cjwatson> ssh is already there
<ogra> thats about it
<cjwatson> Mithrandir: another 1.5MB from bzip2ing ttf-kochi-{mincho,gothic}
<cjwatson> obviously none of that helps desktop in the slightest
<Mithrandir> yeah, ship-live is even worse
<Mithrandir> but that has a bunch of langpacks still, I can make it not have that on ppc
<elmo> how about we just drop the fonts
<cjwatson> huh? ship-live has no langpacks
<Mithrandir> cjwatson: live has.
<Mithrandir> elmo: that'd make our CJVK users unhappy.
<cjwatson> oh, right, that's where they went
<cjwatson> our CJVK users already have no langpacks on powerpc ;-)
<cjwatson> but seriously, we mostly ship the fonts so documents are readable even if the desktop isn't translated
<Mithrandir> no langpacks and no fonts make them even less happy, I imagine.  But I guess we could move them to supported.
<cjwatson> which apparently somebody at some point thought was more important
<cjwatson> bzip2ing should get us the space back, given that I found 4MB there without trying too hard
<Mithrandir> being able to write and read documents in your native language is far more important than having the desktop translated.
<cjwatson> yeah
<cjwatson> tkamppeter: why are all the PPDs compressed independently
<cjwatson> ?
<cjwatson> <cjwatson@cairhien ~>$ for x in `dpkg -L linuxprinting.org-ppds | fgrep .ppd.gz`; do cat $x; done | wc -c
<cjwatson> 3943574
<cjwatson> <cjwatson@cairhien ~>$ for x in `dpkg -L linuxprinting.org-ppds | fgrep .ppd.gz`; do zcat $x; done | gzip -9c | wc -c
<cjwatson> 3503382
<cjwatson> oh, meh
<cjwatson> <cjwatson@cairhien ~>$ for x in `dpkg -L linuxprinting.org-ppds | fgrep .ppd.gz`; do zcat $x; done | wc -c
<cjwatson> 25091054
<cjwatson> tkamppeter: I guess that's too much of a space hit on installed systems, so ignore me
<cjwatson> Mithrandir: turns out I'm not in a meeting after all, so I'll upload these bzip2ings now
<Mithrandir> cjwatson: I just did -uming
<Mithrandir> but feel free to do the rest.
<cjwatson> meh, that was the only one I had built so far
<Mithrandir> do -kochi- and I'll do bakmuk?
<cjwatson> I'm mid-download of baekmuk
<cjwatson> did you add Pre-Depends: dpkg (>= 1.10.24)?
<Mithrandir> hm, no.
<Mithrandir> I should probably do that.
<cjwatson> ttf-baekmuk (2.2-1ubuntu2) feisty; urgency=low
<cjwatson> ttf-baekmuk (2.2-1ubuntu1) hoary; urgency=low
<cjwatson> that just looks wrong
<Mithrandir> I'll do -kochi- now
<Mithrandir> there, new arphic-uming uploaded
<Mithrandir> mvo: what's in the dist-upgrader?
<ogra> cjwatson, hmm, i seem to have live and desktop isos ... is that a temporary overlap or a bug ?
<mvo> Mithrandir: mostly fixes and apport integration. but a fix for the cdromupgrade thing too
<Mithrandir> mvo: cheers.
<mvo> Mithrandir: I can do you a (fake) debdiff if you want one
<Mithrandir> mvo: nah, it should be fine.
<mvo> thanks
<cjwatson> ogra: temporary, I'll clean it up, thanks
<cjwatson> <cjwatson@cairhien ~>$ for x in `dpkg -L gnome-applets-data | xargs ls -ld | grep ^-r | tr -s ' ' | cut -d' ' -f8`; do cat $x; done | gzip -9c | wc -c
<cjwatson> 6159826
<cjwatson> <cjwatson@cairhien ~>$ for x in `dpkg -L gnome-applets-data | xargs ls -ld | grep ^-r | tr -s ' ' | cut -d' ' -f8`; do cat $x; done | bzip2 -9c | wc -c
<cjwatson> 4486855
<cjwatson> seb128: could you make that bzip2ed, please? dh_builddeb -- -Zbzip2 and Pre-Depends: dpkg (>= 1.10.24)
<amep> I am going to try to squash the usplash on AMD64 bug (gray splash screen, etc). But I know very little aboue usplash. Can anyone point me to some developer docs for usplash? I can't get it to run on a fully booted system for testing.
<Mithrandir> amep: then don't bother, it has a known fix.
<Mithrandir> just a matter of finding time to fix it.
<amep> Could I help push it through?
<amep> I'm sick of getting emails about the bug. ;-)
<Mithrandir> heh
<Mithrandir> we're in a freeze now.  I can try to fix it friday.
<amep> OK.
<seb128> cjwatson: ok, will do
<amep> Thanks to everyone, by the way. I love Ubuntu. And I really appreciate all the work that goes into it.
<cjwatson> BenC: could you consider bzip2ing linux-headers-$ABI, please?
<cjwatson> $ compare-gzip-bzip2 linux-headers-2.6.20-5
<cjwatson> gzip: 7192873
<cjwatson> bzip2: 5980068
<BenC> cjwatson: In the .deb?
<cjwatson> BenC: dh_builddeb -- -Zbzip2, Pre-Depends: dpkg (>= 1.10.24)
<cjwatson> to get data.tar.bz2 rather than data.tar.gz
<BenC> cjwatson: Didn't know we supported that, cool
<cjwatson> the numbers above aren't totally reliable but they should be pretty close
<cjwatson> since hoary or so :)
<cjwatson> can't be used in Debian until etch releases
<BenC> I had it working like 6 years ago, but no one wanted it :)
<cjwatson> heh
<cjwatson> Scott probably reinvented it
<cjwatson> vim-runtime will gain us another 1MB
<lifeless> has defaulting that to bzip2 been considered ?
<cjwatson> yes, and rejected
<cjwatson> (we considered it very early on)
<cjwatson> it takes considerably more CPU to unpack, particularly on lower-power machines, so we only do it selectively
<thom> and on most debs it doesn't make much difference
<cjwatson> right, it only gains you much on the big packages
<Keybuk> I can't remember
<Keybuk> I think it was based on an existing patch
<pitti> hi Keybuk 
* thom remembers breaking the world with diveintopython back in hoary
<bdmurray> pitti: I was wondering if apport has any duplicate detection abilities when submitting bugs
<pitti> bdmurray: we provide a default bug title, LP's bug dup proposals should catch on that
<pitti> bdmurray: in addition, we can add manual bug patterns
<bdmurray> pitti: I don't think lp did then
<pitti> then apport will say that it's a dup right away
<cjwatson> in fact, bzip2 makes some packages bigger
<cjwatson> $ compare-gzip-bzip2 vim-common
<cjwatson> gzip: 181406
<cjwatson> bzip2: 198831
<bdmurray> pitti: if you look at bug 81727 I manually marked a lot of the dupes
<Ubugtu> Malone bug 81727 in gnome-app-install "[apport]  gnome-app-install crashed with DBusException in __call__()" [High,Fix released]  https://launchpad.net/bugs/81727
<geser> Keybuk: is there somewhere an explanation for the different colors in the listings from the Merge-o-Matic?
<pitti> bdmurray: hm, it seems that people who file bugs do not actually stop filing it and/or do not look at the dup list
<bdmurray> pitti: ah! that explains a lot then
<pitti> bdmurray: maybe we need to point this out stronger on the +filebug page
<Keybuk> geser: package priorities
<geser> Keybuk: and how are the computed?
<bdmurray> pitti: that's an idea
<geser> Mithrandir: can you increase the timeout for latex-cjk-chinese-arphic (the buildd timed out after 150 minutes of inactivity)?
<fabbione> cjwatson: actually.. there is something that doesn't match in #81782
<pitti> is there a command which displays me the currently active library search paths?
<fabbione> cjwatson: how can it be a missing pci id if the booting kernel in dmesg is still edgy?
<fabbione> (and it loads the driver)
<cjwatson> fabbione: no idea, maybe some other driver handled it
<cjwatson> fabbione: have fun hunting it down :)
<cjwatson> that other driver might not have been in the right udebs or something
<fabbione> cjwatson: that's ok.i am just trying to understand how you got to the conclusion that it was a pci/id
<fabbione> but yes it's possible
<cjwatson> I looked at what driver currently handles that pci id and checked modinfo output to see what the drivers in edgy and feisty provided
<Mithrandir> geser: no, but infinity can
<fabbione> cjwatson: yeps.. r1000 in edgy and r81whatever in feisty
<fabbione> cjwatson: now everything matches
<fabbione> thanks
<cjwatson> np
<Keybuk> geser: from the Priority: field in the source package
<Keybuk> (and thus the binary)
<geser> Keybuk: thanks
<elmo> geser: err, are you sure it's actually doing anything?
<elmo> 150 minutes of build time on our buildds is a _lot_ of CPU time
<geser> \sh build it successfully on his  2xdual core amd64 16GB machine in 3 hours
<elmo> ugh, ok
<elmo> (then like mithrandir said, infinity is the  man to talk to)
<Mithrandir> geser: make it output a dot or something every so often, then.
<elmo> oh yeah - or that might be a better idea
<cjwatson> Mithrandir: have you released that greasemonkey script for auto-responses to bugs anywhere yet?
<Mithrandir> cjwatson: http://err.no/src/lp_stockreplies.user.js
<Mithrandir> needs source code hacking to change the replies, but that should be easy enough
<dholbach> b!z!r! :)
<pitti> cjwatson: seb128 has a version on his people page, too
<Mithrandir> dholbach: doesn't integrate well into firefox.
<siretart> fabbione: is bug #38409 a duplicate of bug #81598?
<Ubugtu> Malone bug 38409 in Debian "creation of snapshots fails unpredictably" [Unknown,Unconfirmed]  https://launchpad.net/bugs/38409
<Ubugtu> Malone bug 81598 in lvm2 "[SRU]  lvm2 check if device is md is broken on big endian machines" [High,Fix committed]  https://launchpad.net/bugs/81598
<dholbach> Mithrandir: what? bzr?
<fabbione> siretart: no
<siretart> ok
<Mithrandir> dholbach: yes.
<Mithrandir> dholbach: as in, storing greasemonkey script in bzr doesn't really fit, since greasemonkey has a directory where stuff's stored, including a metadata-file
<dholbach> right... I just thought that people would want to hack on it, change it, etc - where bzr is a better fit
<dholbach> but I understand what you're saying
<\sh> hmmm...debuild -S bugs me because of UTF/unicode chars in the debian/changelog..how can I tell him to be unicode clean? ,-)
<\sh> anyways...going home
<BenC> cjwatson: This bzip2 thing for linux-headers-* isn't going to be easy
<BenC> cjwatson: It's built by make-kpkg, and there's no way to pass arguments to "dpkg --build" for the package creation
* BenC chalks up another reason to ditch kernel-package for feisty+1's kernel build
<cjwatson> BenC: ah, ok
<BenC> cjwatson: feisty+1 I'll do it
<maswan> BenC: out of curiosity and not keeping up with stuff, how's systemtap support doing?
<BenC> maswan: KPROBES is enabled so the kernels support it (as far as I can tell)
<gus_m> s
<maswan> BenC: well, it needs DEBUG_INFO too, AIUI
<BenC> maswan: We have that too :)
<maswan> BenC: ah, ok. just me not keeping up then. :)
<BenC> the linux-image-debug packages have the raw -g kernels
<maswan> BenC: no, the conf option DEBUG_INFO, bloats the kernel quite a bit
<BenC> yes, I know
<maswan> BenC: but yes, I did look at that and oprofile works neatly now. thanks. :)
<BenC> that's why they aren't installed by default
* maswan nods
<BenC> DEBUG_INFO does enable -g and disables -fomit-frame-pointer too I think
* maswan nods again
<BenC> like zero runtime change, but helps in backtracing and stuff
<maswan> Ah, right. I'm just talking, last thing I looked at was edgy, not current stuff.
<maswan> Sorry, will try to look at testing new stuff out too. :)
<cypher1> Keybuk, hi
<Keybuk> cypher1: hi
<cypher1> Keybuk, i had been look at NoUsplashTimeout Specification
<cypher1> Keybuk, can i pm you for that ?
<Keybuk> sure
<cjwatson> Mithrandir: vim-runtime saves another 1MB, so I'll upload that
<tkamppeter> cjwatso, there was already discussion about making the PPDs occupying less space. See bug 39847.
<Ubugtu> Malone bug 39847 in foomatic-db "Getting (more) manufacturer-supplied PostScript PPDs onto the Ubuntu desktop CDs" [Undecided,Confirmed]  https://launchpad.net/bugs/39847
<cjwatson> BenC: bzip2 saves nearly 3MB out of linux-image-2.6.20-5-powerpc
<cjwatson> tkamppeter: thanks
<alex-weej> are there any Human design guidelines?
<alex-weej> a bit like Tango's
<MacSlow> mdz, ping
<_ion> Seems like i hit bug #80938 while installing Xubuntu.
<Ubugtu> Malone bug 80938 in ubiquity "do_remove BrokenCount assertion can fail" [Medium,Confirmed]  https://launchpad.net/bugs/80938
<cjwatson> _ion: only if do_remove was in the traceback; if it was mark_install instead, then it's a different bug that's been fixed
<cjwatson> the do_remove case is a lot more complicated and I haven't worked out the correct fix yet
<_ion> cjwatson: It was.
<phish> if I was to request a module (specifically pata_atiixp) be included in feisty, where should I make such a request?
<cjwatson> phish: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+filebug
<phish> cjwatson thanks
<Riddell> bdmurray: beastie 80444 should be fixed with kdenetwork -0ubuntu4
<bdmurray> Riddell: How is that?
<Riddell> bdmurray: because we included a fix for it
<Riddell> but it would be useful if you could check that it works
<bdmurray> I meant I didn't understand the relationship between the kcontrolcenter being empty and kdenetwork
<Riddell> bdmurray: oh sorry, I ment kdebase -0ubuntu4
<bdmurray> ah, okay cool. I'll let the reporter know.
<cjwatson> Mithrandir: I've accepted vim since that was for CD size too (1MB off vim-runtime); hope that's OK
<enrico> epiphany on edgy started saying that it can't load https because encryption support is not installed.  So I tried to go to launchpad to report it as a bug.  And it told me that encryption support is not installed, so I can't see launchpad <g>
<enrico> openssl, libssl and whatnot seem to be all installed
<pinskian> exacly why was ubuntu ppc support withdrawn?
<Amaranth> err, it wasn't?
<pinskian> it has
<pinskian> there isnt even a channel for it now
<pinskian> why?
<Amaranth> there are still downloads
<Amaranth> people just decided having a special channel wasn't worth it, i guess
<pinskian> oh
<Amaranth> it wasn't an "official" channel or anything
<pinskian> but ik mean there's no suppport for it right?
<pinskian> cause most of us dumped it for debian as there was no support for it i heard
<pinskian> debian ppc
<Amaranth> it's just as supported as x86 and amd64
<pinskian> not quite as debian ppc's right?
<pinskian> had some difficult with it
<pinskian> thats when i switched
<pinskian> difficulty
<Amaranth> it is no more or less supported than debian's ppc builds
<Amaranth> if you had problems with the the solution was to file bugs :)
<pinskian> i could never get 5 to boot on the imac i had
<pinskian> but really without imac im doing much better with ubuntu
<Amaranth> 5?
<pinskian> basically couldnt get it to run ubuntu on it
<Amaranth> *shrug*
<pinskian> yeah
<Mithrandir> cjwatson: yes, thanks.
<Amaranth> /join #ubuntu-ppc :)
<pinskian> was an old mac
<pinskian> 233 mhz or something
<pinskian> it redirects
<pinskian> :P
<Amaranth> yes
<Amaranth> support questions go to where it redirects :)
<pinskian> hehe
<pinskian> never mind its off my system
<pinskian> ubuntu plain and simple is elegant
<pinskian> Amaranth: you recommend using all x86 machines?
<Amaranth> i've got ubuntu on a mac mini
<pinskian> sweet
<ulaas> hi, is there any process that is going on for unsupported fn keys on specific laptops. i have one laptop maybe i can help...
<Adri2000> sabdfl: I'm not sure to have understood in -meeting, ubuntu-devs are approved as usual during this meeting or not? (except EtienneG)
<sabdfl> Adri2000: yes
<sabdfl> i asked etienneg to go to motu specifically because he's canonical and i didn't want any shortcuts
<sabdfl> he's good but not yet known to the motu
<Adri2000> ah, ok :)
<pinskian> heck, i think for everything else ubuntu is a lot nicer to use than windows
<pinskian> i even was burning an iso yesterday.. the file was on my desktop, i right clicked it and clicked burn, and that was that
<pinskian> :P
<trappist> when is UVF for feisty?
<bdmurray> kylem: ping
<Amaranth> trappist: a couple weeks ago, i think
<trappist> Amaranth: oh :/
<ajmitch> Amaranth: nope, feb 8th
<Amaranth> trappist: oh, no, it's the 8th
<Amaranth> yeah
<Amaranth> so if i want my app in universe i should have it ready by the 8th then :)
<ajmitch> Amaranth: new apps get until the 22nd for universe (iirc)
<trappist> Amaranth: thanks
<kylem> bdmurray, yo.
<Amaranth> ajmitch: wiki sas 8th
<Amaranth> err, says
<Mithrandir> iwj: the trigger stuff looks very interesting.
<ajmitch> Amaranth: no, feature freeze for universe is 22nd on the wiki
<ajmitch> Amaranth: that's what we decided as the date for new packages
<Mithrandir> Amaranth: note that you should have it in the NEW queue well before then, since the queue sometimes is lagging a little.
<Amaranth> oops
<Amaranth> not going to happen unless i write 1000 lines of bugfree code in 24 hours then :)
<Mithrandir> featurefreeze means it should have the features, not the lack of bugs.
<Amaranth> that's not a feature, that's a bug fix! :D
<bdmurray> kylem: I was looking at this wiki page https://wiki.ubuntu.com/DebuggingACPI .  Have you looked at it at all?
<kylem> bdmurray, no, i've not. reading now.
<bdmurray> I says to report acpi bugs against the kernel
<kylem> that's right.
<bdmurray> okay, then from there do they go to acpi and acpi-support ?
<bdmurray> and do the more info requests look good to you?
<Mithrandir> no, "acpi" is almost certainly the wrong package.  It's just a small shell script.
<bdmurray> Mithrandir: thanks, that's good to know
<kylem> yeah, the more info requests are fine. might want to add about asking for their dsdt but that's about it.
<kylem> and the dsdt is usually not needed...
<bdmurray> kylem: so bug 82188 should really be linux-source-#
<Ubugtu> Malone bug 82188 in Ubuntu "Brightness control via ACPI in HP notebooks" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82188
<kylem> that looks like a problem with user tools if the kernel is able to change the brightness.
<bdmurray> got it
<kylem> mjg59, ping? can you shed a bit of light for us, o laptop god? :)
<mjg59> Yeah, give me a sec
<mjg59> Ok, that interface has historically not worked at all
<mjg59> So I don't think hal will attempt to use it
<bdmurray> the /proc/acpi interface?
<mjg59> Yes
<Mithrandir> seb128: gnome-applets accepted; thanks.
<seb128> np, thank you
<Simira> does that mean I need to test it again? :)
<Hobbsee> hey Simira 
<Simira> good evenin
<Simira> well, not testing anything today. I'm off to bed. G'night
<sfllaw> fabbione: Bug 81125 is approved for an upload on Friday.
<Ubugtu> Malone bug 81125 in glibc "libc6 update for Edgy fails due to sanity check" [High,Fix committed]  https://launchpad.net/bugs/81125
<fabbione> sfllaw: ok. you can remind me at the office :)
<sfllaw> fabbione: This was merely me following SRU procedure.  I'll likely forget before you do.  :)
<geser> mdz: can I ask you a question about the source maintainer mangling we are supposed to do?
<seb128> Mithrandir: please accept the gnome-control-center update for herd3, it fixes a bug which wipes the user directory
<Mithrandir> ouch
<Mithrandir> (looking)
<seb128> Novell guys did something stupid
<seb128> they add and remove autostart apps from their new shell
<elmo> !
* Mithrandir blinks
<seb128> and they do it based on a gconf key with user_dir, gconf_dir, filename
<seb128> when gconf_dir is not set they basically rm -rf user_dir
* Mithrandir blinks.  Again.
<Mithrandir> accepted.
<seb128> thank you
<Hobbsee> Mithrandir: did kdenetwork never get accepted, or did Riddell not upload it?
<LaserJock> ahh, was that the "OMG Control Center ate my ~/"?
<ajmitch> seb128: that's disturbing
<Mithrandir> Hobbsee: it hasn't hit the unapproved queue, ttbomk
<mdke> haha
<seb128> LaserJock: that was https://launchpad.net/control-center/+bug/78500
<Ubugtu> Malone bug 78500 in control-center "gnome-control-center wipes out /home/user" [Unknown,Unknown]  
* mdke makes a mental note to backup before any future upgrades
<Mithrandir> seb128: in which case did it do that?
<Gman> seb128, sweet jeebus.
<Hobbsee> Mithrandir: right, i'll bug the relevant people then
<seb128> Mithrandir: when left clicking on a shell item and using "remove from the startup list" if the program was not to the startup list
<seb128> or maybe even if it was, I'm not sure sure now
<seb128> (if you don't have gnome-main-menu installed)
<Mithrandir> I wonder why it'd add the -r
<seb128> (they shipped the gconf schemas with gnome-main-menu, but not with libslab which is used by the shell)
<seb128> well, they don't call "rm -rf"
<seb128> they call gnome_vfs_xfer_delete_list on the dir
<seb128> which does the same job :/
<Mithrandir> it should call something which tries to remove files, not directories.
<Mithrandir> IMO
<sladen> mjg59: remind me again what exactly the amd64 framebuffer usplash grayscale issue is---it's just not possible to program the palette entries over 16 ?
<seb128> that code should probably be changed to use delete_uri on the item rather
<seb128> Mithrandir: yeah, I was thinking the same
<seb128> I'll fix it probably
<sladen> bug #67545 really needs a good answer lif [ "$HAL_PROP_LAPTOP_PANEL_ACCESS_METHOD" = "sony" ] ; then
<Ubugtu> Malone bug 67545 in usplash "usplash appears black and white (grayscale) on amd64" [Low,Confirmed]  https://launchpad.net/bugs/67545
<mjg59> sladen: No clue, don't care. It's going to stop using vga16fb.
<sladen>         # echo "{1..8}" > /proc/acpi/sony/brightness
<sladen> cack
<Mithrandir> sladen: it's using the vga framebuffer for various reasons.
<sladen>         # http://popies.net/sonypi/2.6-sony_acpi4.patch
<sladen>         echo "$((value + 1))" > $HAL_PROP_LINUX_ACPI_PATH
<sladen> "various"---suspend related, setup related?  What can I shove in the bug report.
<sladen> Mithrandir: ^^can you remember any of the reasons?
<Mithrandir> sladen: yes.
<sladen> Mithrandir: "with specificity" ?
<sladen> (other than the contents of the changelog;  which shows the change to bogl/vga16fb, but not the reason)
<Mithrandir> the current x86emu in the usplash source tree doesn't work correctly on amd64
<sladen> Mithrandir: thanks, that'll do, ta
<elmo> does anyone know if lvm has to be a module to do root-lvm?
<Hobbsee> Mithrandir: ping?
<Mithrandir> Hobbsee: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
<Hobbsee> Mithrandir: bleh.
<bddebian> Don't you love those? :-)
<Hobbsee> yep :)
<Hobbsee> particularly when i use them myself
<Hobbsee> just not automatically
<TheMuso> Hobbsee: hehe
* Hobbsee loves error code -12263
<Hobbsee> that tells me *nothing*
<tkamppeter> cjwatson, ping
<cbx33> hey guys
<TheMuso> Hey cbx33.
<cbx33> hi TheMuso 
<cbx33> who knows much about DES here?
<TheMuso> I'd say nothing because I don't even know what DES is.
<ogra> Mithrandir, i have two fixes for pulseaudio i'd like to upload, debdiff is here: http://people.ubuntu.com/~ogra/pulse.debdiff
<seb128> Mithrandir: I uploaded an another gnome-control-center which uses g_unlink on a file rather than gnome_vfs_xfer_delete_list on an uri, that can go after herd3 though, the previous version already fixed the problem, the new one is just cleaner
<cbx33> ogra, having problems with the DES
<ogra> cbx33, did you try to switch to python-crypto ? 
<cbx33> using the Crypto.DES
<ogra> it should offer the same functionallity
<cbx33> they encrypt to different ciphers
<elmo> what on earth are you using DES for in this day and age?
<cbx33> >>> des=DesCipher('01234567')
<cbx33> >>> des.encrypt("01234567")
<cbx33> '\x16\xdbs\xceb\xd5\xb7q'
<cbx33> >>> des=DES.new('01234567')
<cbx33> >>> des.encrypt("01234567")
<cbx33> '\xc5\n\xd0(\xc6\xda\x98\x00'
<cbx33> >>> 
<cbx33> vnc authentication
<ogra> even though the sngle functions might differ
<ogra> elmo, there is a vnc wrapper cbx33 wants to use in the thin-client-manager ... seems vnc needs DES
<ogra> the vnc wrapper shipped its own DES code, stolen fron an at&t source with a wonky license ... so he needs to reimplement it in python-ltsp ...
<ogra> *from
<ogra> err
<ogra> *python-crypto
<cbx33> but it's not giving the same results
<cbx33> and I don;t know enough about DES to understand why
<cbx33> I found another project who nicked the same code
<cbx33> that's 3 projects
<ogra> that doesnt make the license more valid
<cbx33> no
<cbx33> just funny is all
<cbx33> I wasn't using it to validate
<cbx33> so any DES experts here?
#ubuntu-devel 2007-01-31
<pochu> one question: does every version of Ubuntu uses utf-8 for the filenames?
<sladen> bah, missed seb
<cbx33> ogra, ok....
<cbx33> found a way we can use pycrypto
<cbx33> crippled_des is stupid...
<cbx33> probably why it's crippled
<cbx33> there is some swapping of bits going on
<cbx33> meaning that the two only give the same results if the bits in the keys and passwords are symmetrical
<ogra> cbx33, have a look at the mode switch of DES.new() as well ...
<cbx33> ok
<ogra> i.e. des=DES.new('01234567', 4) is pgp mode, DES.__dict__ shows a list ...
<cbx33> hmmm
<cbx33> ogra, no
<cbx33> that doesn't help?
<cbx33> tried all modes
<cbx33> ogra, please read
<cbx33> this is the reason that that des is crippled ;)
<cbx33> http://www.vidarholen.net/contents/junk/vnc.html
<ogra> ah, so you just need to flip the bytes :)
<cbx33> yes
<cbx33> but internally
<cbx33> so recompiling python-crypto
<cbx33> i dunno
<cbx33> stupid VNC
<elmo> hey since you guys are all about VNC
<elmo> is there any sort of VNC recorder?
<elmo> instead of viewing dumps the output to a file for later playback?
<jdub> vnc2swf
<elmo> swf == flash?
<jdub> yeah, though it's pretty much the best of a bad bunch
<jdub> there's one called vncrec which uses its own special format
<jdub> hmm, which can now be transcoded, interesting
<jdub> http://www.sodan.org/~penny/vncrec/
<jdub> your other option is an X-based recorder, kicked off *via* vnc... that might work
<jdub> depending on the reqs
<elmo> jdub: I'm trying to capture something scrolling off screen on a KVM-over-VNC, I suspect my best bet is VNC recorders
<elmo> thanks, I'll try vncrec and vnc2swf if I get desparate
<kylem> elmo, it's probably ok. i should be able to debug with this.
<elmo> kylem: it's got other use cases tho :)
<kylem> one this git checkout finishes. sigh.
<mjg59> elmo: uk.archive supposed to be down?
<kylem> 4200rpm is not good for git.
<elmo> mjg59: nope
<mjg59> elmo: Hm. Can't get at it from here.
<elmo> mjg59: it is down tho
<elmo> it's just not supposed to be, ho hum
<mjg59> Ah, ok
<elmo> mjg59: archive.u.c is still in the uk in the meantie, FWIW ;-) - I'll contact the people hosting gb/uk
<mjg59> elmo: Yeah, hitting it up now
<cbx33> if you're talking about pyvnc2swf then
<cbx33> hehe that's the one that's using the crippled_des that is breaking the GPL and giving me a headache ;)
<enrico> siretart: python-debian uploaded to unstable!
<elmo> mjg59: (it's back - thanks for letting us know)
<mjg59> elmo: No problem
<elmo> zul: ping
<zul> elmo: pong
<bddebian> Heya
<zul> elmo: whats up?
<elmo> zul: got any xen 3.0.4 packages around yet?
<zul> playing with it but not really..had too many problems with it
<elmo> oh?
<elmo> zul: like what?
<elmo> does anyone know where fedora keep their feisty equiv?
<kylem> elmo, they call it rawhide. most of their stuff is in cvs.
<zul> elmo: like domU not starting
<kylem> http://cvs.fedora.redhat.com/viewcvs/?root=core
<elmo> kylem: cool, thanks
<elmo> zul: ok
<kylem> np.
<jdong> ogra: ping; were you the one trying to bring fuse to 2.6.0?
<jdong> unping; I think it was givre
<jdong> fabbione: ping regarding fuse 2.6.0
<Mithrandir> ogra: it doesn't seem urgent to me?
<pitti> good morning
<Hobbsee> hey pitti 
<Hobbsee> Mithrandir: ping @ kdenetwork.
<Mithrandir> Hobbsee: hiya
<Hobbsee> hey Mithrandir :)
<Hobbsee> Mithrandir: can you accept yesterday's kdenetwork please?  (0ubuntu4)
<Hobbsee> Riddell: was happy with it
<Mithrandir> Hobbsee: you have forgotten to mention the addition of the sms plugin, it seems
<Mithrandir> anyway, accepted
<Hobbsee> Mithrandir: cool, thanks.  
<pitti> Mithrandir: I have two easy, but important apport bug fixes: http://paste.ubuntu-nl.org/3558/
<pitti> Mithrandir: it would be nice to get them in to get more testing for package install/upgrade failures
<pitti> Mithrandir: ok for you for herd-3?
<Mithrandir> pitti: looking.
<Mithrandir> pitti: approved, please get in in ASAP
<pitti> Mithrandir: thanks; uploaded
<siretart> enrico: THANKS! :) - and I already merged it and uploaded to feisty :)
<pitti> mvo: I fixed your apport bugs, but I'd like confirmation from you for bug 82267
<Ubugtu> Malone bug 82267 in apport "apport-gtk keeps crashing" [Undecided,Fix released]  https://launchpad.net/bugs/82267
<pitti> cjwatson: good morning Colin
<mvo> pitti: good morning
<Mez> quick question... if something needs a depend on the source version it should be
<mvo> pitti: what kind of confirmation?
<pitti> mvo: that your python-apport package is indeed outdated
<Mez> Depends: package (= ${Source-Version})
<Mez> not
<Mez> Depends: package (= ${source:Version})
<Mez> right ?
<pitti> Mez: IIRC it's ${Source:Version}
<Mez> hmm - dh_make uses ${Source-Version}
<Mez> but this package I'm looking at uses ${source:Version}
<pitti> Mez: yup, you are right, sorry
<Mez> but that errors out with
<Mez> dpkg-deb: parse error, in file `debian/nagios2/DEBIAN/control' near line 6 package `nagios2':
<Mez>  `Depends' field, reference to `nagios2-common': error in version: version string is empty
<Mez> I'm wondering how it ever built
<Mez> (it's synced from debian)
<Mez> unless debians systems aren't correct ?
<Mez> aha ...
<Mez> ok... I get it now .. :D
<Mez> have the standards changed ?
<pitti> seb128: good news!
<seb128> pitti: oh?
<pitti> seb128: I played a while with fakechroot yesterday and started working on an apport-retrace version which can build a sandbox for retracing with just user privileges
<pitti> seb128: IOW: this would enable us to set up an automatic retracing service on porter's boxes
<seb128> that is good news indeed ;)
<Mez> hmmles, pitti, some advice.
<Mez> Is it worth making an ubuntu-specific change just for a backport (changing ${source:Version} to ${source-Version}
<pitti> Mez: if the package doesn't build, then it's definitively worth making the change
<pitti> Mez: but it should be filed as an important debian bug as well
<Mez> pitti: it builds against newer dpkg-dev though
<pitti> ah
<seb128> what package is that?
<Mez> having a small debate over it on OFTC #debian-devel
<Mez> seb128, nagios2
<Mez> ok, apparently the ${Source:Version} is specifically for binNMUs.
<Mez> but wont work with dappers dpkg-dev...
<seb128> right
<seb128> they didn't change the sementic just for changing it
<Mez> so is it worth making the ubuntu specific change?
<Mez> 1) theres a request for backporting
<seb128> the new Source:Version doesn't contain the revision
<Mez> 2) we dont do binNMUs in ubuntu
<seb128> well, I thought you guys could do changes for backport no?
<seb128> there is no real reason to create extra diff with Debian only for backport
<Mez> seb128, I've no clue ;)
<Mez> apparently so, but I dont know if it's been done
<Mez> cjwatson, elmo, mdz, care to confirm or deny if we can now ?
<Mez> (or anyone else who knows - anyone from ubuntu-archive I guess)
<Mithrandir> can, yes, but no, we don't do it as a matter of policy.
<Mez> Mithrandir, I believe it was agreed at some point that we were allowed as long as a main dev sponsored us in the changes. The last I knew, it was just impossible to actually put the changes in physiclaly
<dholbach> good morning
* pitti hugs dholbach 
* dholbach hugs pitti back
<dholbach> hey mvo_
<mvo_> hey dholbach!
<mvo_> looks my network is unstable today 
<mvo_> looks like
<Mithrandir> mvo_: gdebi-core needs versioned conflicts+replaces on gdebi.
* mvo_ stares at iwj
<mvo_> Mithrandir: I will fix that
<Mez> Mithrandir, so I'm assuming that you wont let this be backported? (If so I'll just reject it)
<Mithrandir> Mez: sorry, I'm in herd release mode, I'd need to make up something up on the fly.
<Mez> Mithrandir, slightly confused by that ;) cant tell if it's a yes or no ;)
<Mithrandir> Mez: it's neither. :-P
<Mez> Mithrandir, thats how i read it ;)
<cjwatson> Mez: it would be the first time it had been done. Frankly I think it depends how important the backport is; if it's just nice-to-have then I would recommend moving on to something else.
<Mez> cjwatson, put simply, if it was anything other than "nice-to-have" it'd be an SRU ;)
<Chipzz> mvo_: ping :)
<Mez> I cant really think of a situation where a backport would be "important" enough in that case without it being an SRU
<mvo_> Chipzz: pong
<Mez> cjwatson, so - just move on ? :P
<Mithrandir> if you needed the same fix for, say, usplash to it to use vesafb on amd64, I'd say it'd be a backport, not a SRU.
<mvo_> Chipzz: looking at the bug now
<Mez> Mithrandir, surely thats the ONLY time it could be used ? :P
<Mez> I'll move on
<Mez> oh, and scim ;)
<mdz> Mez: yes
<Mez> mdz: but do you agree with cjwatson about the whole "it depends how important the backport is"
<tkamppeter> cjwatson, ping
<tkamppeter> Any tar expert around?
<seb128> tkamppeter: ask your question
<seb128> if somebody knows the answer he'll probably reply
<cjwatson> tkamppeter: hello
<tkamppeter> Hi, cjwatson and seb128, I have tried to make CUPS extracting the PostScript printer PPDs from a tarball on-the-fly, see bug 39847.
<Ubugtu> Malone bug 39847 in foomatic-db "Getting (more) manufacturer-supplied PostScript PPDs onto the Ubuntu desktop CDs" [Undecided,Confirmed]  https://launchpad.net/bugs/39847
<cjwatson> tkamppeter: (I didn't mean to imply yesterday that this was urgent)
<tkamppeter> To try to make it as fast as possible I have put the index file into the begiinning of the tarball, so that CUPS lists the PPDs quickly.
<tkamppeter> The problem is that tar goes on reading after it has already found the requested file and so it takes always the time for reading the full tarball, independent which and how many files I extract.
* cjwatson investigates
<tkamppeter> Is there a possibility to make tar stop reading when it has found the requested file?
<pitti> Mithrandir: oh, new kernel is for herd-3?
<cjwatson> Mithrandir: d-i uploaded, Ubuntu seeds modified (merge needed)
<tkamppeter> cjwatson, so if there is no simple solution for this tar problem I think I will leave the PPDs as they are and simply do "gzip -9" on the PPDs when I make the next foomatic-db package.
<tkamppeter> seb128, if you have a solution for my tar problem would be great.
<seb128> tkamppeter: no idea about that one :/
<cjwatson> tkamppeter: looking at the tar source code, I don't see a way to do that. extract_archive returns void and has no way to communicate meaningfully with the loop over all files in read_and.
<cjwatson> tkamppeter: the saving would only have been a couple of hundred kilobytes, so there is certainly lower-hanging fruit elsewhere - we saved about 6MB yesterday by recompressing other .debs with bzip2
<tkamppeter> So as I do not want to modify or re-implement tar, I think we must live with the splitting of linuxprinting.org-ppds and linuxprinting.org-ppds-extra, as we do on current Feisty.
<cjwatson> ogra: could you update the status of your Edubuntu specs, please? a lot of them are "unknown" at the moment
<cjwatson> tkamppeter: likewise for your printing specs (see https://launchpad.net/ubuntu/feisty/+specs) to reflect whatever progress is in the Ubuntu archive at the moment
<Mithrandir> cjwatson: thanks.
<Mithrandir> Riddell,ogra: please merge seeds.
<ogra> cjwatson, will do
<cjwatson> Mithrandir: what was the result of your grub2 discussion with Ian at the sprint?
<ogra> MikeSmith, on my way ...
<Mithrandir> pitti: yes.  I had hoped we would have it a bit earlier, but we didn't.
<Mithrandir> cjwatson: just that he'll take it over and do what's in the spec.
<ogra> MikeSmith, and no, its not urgent ...
<cjwatson> Mithrandir: I'll change the assignee, then.
<Mithrandir> cjwatson: thanks.
<mvo_> Mithrandir: I uploaded a new gdebi with propper C/R line. and a new g-a-i that updates two codec lines. I hope those are ok for herd-3
<MikeSmith> ogra - ?
* MikeSmith thinks ogra might be auto-completing and catching MikeSmith before Mithrandir ...
<ogra> MikeSmith, heh, yes, sorry 
<MikeSmith> ogra - np
<Treenaks> mikerandir ;)
<MikeSmith> heh
<Mithrandir> mvo_: it's in NEW and has been for a week, I'm not sure I'd want to let it out now.
* MikeSmith is at this moment installing Ubuntu 6.10 under Parallels on a Mac OSX box
<Mithrandir> mvo_: I could take a look at the changes and see how big they are.
<mvo_> Mithrandir: oh, I misunderstood then. keep it in NEW, that should be fine
<tkamppeter> cjwatson, updated the status of all specs which are approved and assigned to me https://blueprints.launchpad.net/~till-kamppeter
<cjwatson> tkamppeter: thanks. I think printer-sharing is probably Blocked rather than Needs Infrastructure, although it's a minor point.
<cjwatson> tkamppeter: printerdrake status is concerning given that another spec is blocked on that
<cjwatson> pitti: can you comment
<cjwatson> ?
<cjwatson> ajmitch: could you update the status of the network-authentication spec, please?
<tkamppeter> cjwatson, changed printer-sharing to Blocked
<pitti> cjwatson: I agree, it was just changed
<pitti> cjwatson: and it has proper dependencies
<cjwatson> pitti: right, I'm more wondering whether it will make feature freeze
<pitti> cjwatson: 99% not, printerdrake is just not there yet
<tkamppeter> As I suggested the replacement of gnome-cups-manager by printerdrake I thought one could simply take in some libs from Mandriva to make it working and then later replace the GUI.
* siretart preannounces https://wiki.ubuntu.com/BzrBuildpackage, a bzr plugin for maintaining debian packages in bzr. If you have a minute, please have a look at the wiki. feedback welcome
<pitti> siretart: this is mainly/only useful if you maintain the upstream bits in bzr, too, right?
<siretart> pitti: no, it supports both merge and nonmerge mode
<tkamppeter> Then pitti told me once by e-mail that there is no chance to get Mandriva's libraries into Feisty and the user interface HAS to be replaced. Then he asked me for screenshots and docs and I made these available.
<siretart> pitti: together with the bzr-svn plugin, you can even have the upstream branch maintained in svn and your debian/ dir maintained in bzr, if you prefer
<siretart> pitti: see https://wiki.ubuntu.com/BzrBuildpackage#head-1cb3f99dcc67a9b9b372e7252af55ac673b372ae
<cjwatson> mvo_: you don't seem to have ever responded to my review comments on dist-upgrader-arch-any - could you do so?
<cjwatson> mvo_: have you talked with Celso/Kiko about that?
<mvo_> cjwatson: sorry for that, I will do that today
<tkamppeter> pitti, you have rejected moving m2300w into main due to FTBFS, as it builds for me I want to know why it does not build for you.
<pitti> tkamppeter: it doesn't build on the buildds, please see the logs
<tkamppeter> pitti, where can I find these logs?
<pitti> tkamppeter: https://launchpad.net/distros/ubuntu/+source/m2300w -> latest source version -> Builds
<pitti> http://librarian.launchpad.net/5799737/buildlog_ubuntu-feisty-i386.m2300w_0.51-0ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> tkamppeter: it seems you need 'gs' as build dependency
<tkamppeter> Thanks.
<cjwatson> tkamppeter: you can always find the build logs from https://launchpad.net/ubuntu/+source/SOURCEPACKAGENAME, click on version, click on link for appropriate architecture
<cjwatson> tkamppeter: you should be familiar with this sort of thing
<TheMuso> What is the story re espeak promotion to main? Does it need to be seeded before that happens? The main inclusion report on the wiki says its approved.
<TheMuso> dholbach: Once espeak moves into main, I'm happy to look at gnome-speech to get it building with espeak.
<cjwatson> TheMuso: packages always need to be seeded, or (build-)depended upon by something that's seeded, in order to be promoted
<TheMuso> cjwatson: Right.
<TheMuso> I understand you guys are in freeze right now, but just wondering.
<dholbach> TheMuso: I wrote the main inclusion report and I have the gnome-speech package prepared to build with it (once it's approved)
<TheMuso> Been talking to heno .
<TheMuso> dholbach: Bah you are too quick.
<heno> Yeah, it looks on track :)
<dholbach> TheMuso: excusez-moi :)
* heno hugs dholbach
* dholbach hugs heno and TheMuso back :)
<Riddell> Mithrandir: seeds merged by the way, I also uploaded a fixed kdenetwork
<dholbach> TheMuso: I'll leave the next a11y tarballs for you, I promise :)
<TheMuso> This also means that we can drop festival and get some 10s of MB back for the CD>
<Mithrandir> Riddell: the one I accepted this morning or another one?
<TheMuso> dholbach: Its alright.
<dholbach> yoohoo
<heno> TheMuso: until we add huge espeak voices like Russian and Chinese ;)
<TheMuso> heno: Are they supposed to be big?
<heno> (which for some reason are bigger)
<TheMuso> Probably don't come close to festival however.
<heno> Lot's of exceptions I guess (really don't know)
<Riddell> Mithrandir: another one, 4:3.5.6-0ubuntu4 failed to build
<Mithrandir> Riddell: ok, accepted
<cjwatson> Mithrandir: I uploaded xorg to fix bug 59618 at long last, but it can be post-herd-3 if you like
<Ubugtu> Malone bug 59618 in xorg ""Safe graphics mode" doesn't use VESA" [High,Fix committed]  https://launchpad.net/bugs/59618
<Mithrandir> cjwatson: I was just going to investigate who did it, so thanks.  I guess it can be herd-ed in
<cjwatson> Mithrandir: up to you
<Mithrandir> already accepted
<Mithrandir> looked safe enough
<bSON> hi
<gpocentek> Mithrandir: I've just merged the xubuntu seeds with ubuntu, could you build both daily and daily-live isos for us?
<Mithrandir> gpocentek: once we have l-r-m which doesn't ftbfs, yes.
<StevenK> Woot
<gpocentek> Mithrandir: ok, thanks
<bSON> ubuntu should drop it's gnome-cups-manager .desktop file and use the one upstream
<bSON> and more important, it shouldn't install it in /usr/share/control-center-2.0/capplets but in /usr/share/applications
<Mithrandir> bSON: any reason why it shouldn't be in both places?
<bSON> Mithandir, it isn't in both places, it is just in the legacy directory
<Mithrandir> : tfheen@golem ~ > dpkg -L gnome-cups-manager| grep desktop
<Mithrandir> /usr/share/control-center-2.0/capplets/gnome-cups-manager.desktop
<Mithrandir> /usr/share/applications/gnome-cups-icon.desktop
<Mithrandir> so no, it's not.
<bSON> Mithrandir, gnome-cups-icon.desktop is not gnome-cups-manager.desktop, those are two different things
<bSON> gnome-cups-icon.desktop is from upstream that's why it's in the correct folder
<Mithrandir> oh, true, different names.
<bSON> (gnome-cups-icon is the notification area icon)
<bSON> Mithrandir, i think the fix is as simple as dropping debian/gnome-cups-manager.desktop and going with upstream
<xerxas> Hi all 
* Mithrandir idly wonders why the buildds are happily chugging away at stuff and if infinity did a mass giveback or something
<iwj> So allegedly we have a xen dom0 kernel in feisty now.  Let's see how bad it is.
<wasabi_> the default kernel?
<wasabi_> -generic?
<zul> iwj: thanks...love you too
<iwj> :-)
<Mithrandir> wasabi_: no, it's in universe.
<zul> iwj: works for me
<iwj> zul: No insult intended.  If you know me you'll know I have a natural distrust of software - all software.
<iwj> Excellent.
<zul> iwj: none taken..
<iwj> By and large I find that software is terrible, sadly.
<Mithrandir> it's less bad than hardware, because fixing hardware takes more effort.
<Treenaks> iwj: you must hate hardware
<cjwatson> Riddell: Scott says you reckon you're entirely blocked on me for kubuntu-feisty-ubiquity - but surely there's lots of stuff in there that you can do independently of advanced-partitioner and slideshow?
<kylem> it's just cheaper to fix sw than hardware.
<Treenaks> kylem: unless your RAID-disks start to break ;)
<wasabi_> hopefully you're using software raid. :)
<iwj> Hardware is bad in different ways.  I quite like hardware I built myself.  Unfortunately even the software I write myself is buggy.
<webben> The Scribus folks seem very very unhappy. http://bugs.scribus.net/view.php?id=4423 Would it be possible to select a "non-random" font and theme for QT apps?
<wasabi_> Not sure what you mean by "random"
<Riddell> cjwatson: I think it's all been done except for those and the missing translation strings
<cjwatson> Riddell: I'm sure I haven't seen merges for a big chunk of those
<cjwatson> unless it *all* went in with the qt4 port
<cjwatson> I'll have a look at the next opportunity
<sfllaw> kylem: Ping?
<kylem> sup
<sfllaw> kylem: How does one debug problems with ACPI buttons not showing up?
<mjg59> sfllaw: What hardware?
<sfllaw> kylem: Thinkpad T60p.
<mjg59> sfllaw: Not showing up in what way?
<kylem> apply matthew garret liberally to the problem.
<kylem> ;-)
<sfllaw> kylem: lshal -m doesn't respond when I hit SLPB.
<mjg59> sfllaw: And is there a /proc/acpi/ibm directory with contents?
<sfllaw> mjg59: Indeed there is.
<mjg59> kylem: Hm. Does sudo acpi_fakekey 142 generate one?
<sfllaw> Ah, strange, it's back.
<mjg59> Ah
<Mithrandir> is it just for me that pages in launchpad seems to return bin files for every second or third click now?
<webben> Sorry, my X froze if anyone replied about Scribus, and default theme and font for QT apps.
<sfllaw> mjg59: Strange, it's disappeared again after setting the hotkey back to its default 0xff9f and then to 0xffff again.
<sfllaw> mjg59: Or rather, it's very intermittent.
<sfllaw> After hitting it about 30 times, I get one response.
<mjg59> sfllaw: Hm.
<sfllaw> acpi_fakekey works.
<mjg59> sfllaw: Does the acpi_fakekey thing work reliably?
<sfllaw> Yes.
<mjg59> Ok. Is stuff appearing in /var/log/acpid ?
<sfllaw> Yes.
<sfllaw> Am I looking for something?
<sfllaw> mjg59: acpid doesn't respond to SLPB very often...
<mjg59> sfllaw: Can you stop acpid, then cat /proc/acpi/events and see if anything is being generated?
<sfllaw> mjg59: Only every 50 keypresses or so.
<mjg59> sfllaw: Kernel boog, then
<sfllaw> That was my intuition...
<sfllaw> kylem: What kind of help would you need to track this down?
<sfllaw> kylem: I'm willing to file a bug with as much information as you need.
<kylem> i dunno, acpi isn't really my bag. but file a bug and i'll look at it.
<bddebian> heya
<kylem> sfllaw, you going to be in the office on friday?
<sfllaw> kylem: Probably.
<pitti> kylem: just a question, when will the new stable-security kernel be ready for upload approximately?
<kylem> pitti, today. in an hour or two.
<pitti> \o/
<kylem> had some build troubles yesterday, but those are better now.
<sfllaw> kylem: It takes around 60 seconds to register the next SLPB press.
<sfllaw> Suspicious.
<sfllaw> seb128: Does gnome-power-manager now handle ButtonPressed = sleep?
<seb128> sfllaw: what is "ButtonPressed"?
<sfllaw> [button_pressed_cb]  gpm-info.c:435 (09:55:09):   Button press event type=sleep
<seb128> (note that ogra maintains that package and he might be the right person to ask)
<sfllaw> Ah, sorry.
<sfllaw> ogra: ^^^?
<mjg59> sfllaw: Yes
<seb128> is that the "When the power button is pressed" config option?
<iwj> zul: You mean with xen-image-xen0-2.6.17.6 et al ?  ISTR reading about a 2.6.19 somewhere.
<zul> iwj: yeah im just about to upload a newer version, i can put it up for you somewhere if you wish so you can get it when im done
<sfllaw> seb128: No, it's when you hit the sleep button on your computer.
<seb128> ah ok
<sfllaw> ogra: It looks like SLPB is being eaten by gnome-power-manager in Feisty.
<sfllaw> ogra: Is that supposed to be the case?
<mjg59> sfllaw: If it's not appearing in /proc/acpi/events, it's never getting anywhere near g-p-m
<iwj> zul: I don't need a newer version unless you think I need one.  I'm happy to live not so near the bleeding edge provided it mostly works.
<sfllaw> mjg59: There are two bugs here.
<zul> ok but there will be a newer version today though
<sfllaw> mjg59: In that when button presses do get to g-p-m, nothing happens.
<zul> iwj: although it should work with 2.6.17
<iwj> zul: Right, that's great, thanks.
<mjg59> sfllaw: Just as a point of reference, if ibm-acpi is loaded, you won't get SLPB. It'll be an ibm/hotkey event.
<mjg59> Also, SLPB is just an internal identifier in the DSDT. Different hardware will have different names there.
<sfllaw> Ah, g-p-m is set to have it do nothing.
<mjg59> Yes, that seems like a plausible answer :)
<cjwatson> tkamppeter_: what's your expectation that the upstream changes for printerdriverautodownload can happen in the next week?
<cjwatson> tkamppeter_: (i.e. pre-feature-freeze)
<sfllaw> ogra: It looks like bug 63303 has regressed.
<Ubugtu> Malone bug 63303 in gnome-power-manager "No sleep button in edgy?" [Critical,Fix released]  https://launchpad.net/bugs/63303
<mjg59> sfllaw: You're testing a clean install?
<sfllaw> mjg59: Not completely.  But I'd expect /usr/share/gconf/defaults/10_gnome-power-manager to say something about that gconf key.
<sfllaw> Like, one day it worked, and the next day it didn't.
<sfllaw> mjg59: Let's check edgy's package to see what it says.
<sfllaw> mjg59: Oh, Edgy didn't have this file.
<tkamppeter_> cjwatson, in the next week I will not be able to do this upstream work. So I think we should move this to Feisty+1, especially for doing automatic downloads from Ubuntu we also need a printer setup tool which is maintained, so we better should make the driver auto download also dependent on the introduction of printerdrake.
<pitti> tkamppeter_: pd-autodownload is mainly about creating a magic source package that fetches drivers from upstream, tests them, and creates packages for them; how does that depend on printerdrake?
<tkamppeter_> pitti, one can perhaps make a PPD generator for CUPS 1.2 which checks whether the user is on the internet and if so it takes drivers from OpenPrinting into the PPD list
<cjwatson> tkamppeter_: this sounds like all of your specs are crashed-and-burned for feisty, then?
<cjwatson> tkamppeter_: that's ... concerning
<tkamppeter_> and if a user chooses a driver which is only available on OpenPrinting, the PPD generator downloads the driver package.
<pitti> tkamppeter_: right, but that does not seem to be related to the spec?
<cjwatson> if you can decouple it from printerdrake, that would be a very good idea, even if it has to slip past feature freeze a little
<pitti> please let's not have the automatic dl discussion again for now
<tkamppeter_> cjwatson, it seems that the introduction of printerdrake was more work than expected. On the Summit pitti asked me for the files and told me that he tries to make them running under Ubuntu. Later on he told me that it is nott possible to get the Mandriva GUI libraries running with Feisty and asked me for materials to work on that and after that I did not get any retrurn any more
<pitti> right, that's sort of stalled on UI redesign now, on mpt's table, but certainly not his first priority
<tkamppeter_> driver auto-download can be completely hiden into CUPS, as driver generator, but as there is no sample driver package yet on OpenPrinting one cannot develop and test very well a CUPS PPD generator to be launched in a week.
<pitti> tkamppeter_: but the spec is about a source package that downloads the drivers from openprinting and builts debs from them, not writing a cups backend
<cjwatson> the date of feature freeze isn't something that was established today ...
<pitti> althugh that would certainly be nice to have
<tkamppeter_> Also for the development of a source package which downloads and re-packages all drivers sample driver packages are needed ...
<iwj> Hmm, the trouble with testing adt-xenlvm-setup is that I have to wait for debootstrap each time.  I wonder if there's a quicker way.
<iwj> zul: Congratulations, it all works just fine.
<iwj> Thanks very much.
<cjwatson> the cups backend is not specced; the spec lists the openprinting-drivers magic source package (waiting for openprinting.org) and the printerdrake integration (which will have to be deferred)
<pitti> tkamppeter_: oh, openprinting does not export those yet? hm, too bad
* mdz hands tar(1) to iwj
<iwj> mdz: Yes, I might resort to that but really I need more RAM I think.
<cjwatson> tkamppeter_: I would suggest moving the openprinting.org changes as far forward in your schedule as possible, and getting the source package work done as soon after feature freeze as possible
<iwj> But in fact it's just worked so I don't need to debug it any more :-).
<tkamppeter_> cjwatson, I will do so.
<cjwatson> tkamppeter_: thanks
<tkamppeter_> cjwatson, should I mark printerdrake as Feisty+1 then?
<cjwatson> tkamppeter_: yes, with an explicit annotation of exactly whom it's blocked on so that we can come back to this later without losing information
<zul> iwj: cool
<iwj> zul: X is still broken but when I'm doing this I don't mind not using the machine's head.
<zul> iwj: might be the kernel then
<iwj> Ben thought it might be something to do with the way xen remaps video stuff.  I have to admit to not understanding how all of the X/Xen/kernel interaction works.
<Keybuk> the testing machine in the DC won't have X running, I suspect
<iwj> Keybuk: You mean to tell me elmo doesn't like standing in the DC pointyclicking at menus ?
<zul> iwj: which card is it again?
<kwwii> Keybuk: was my mail enough for the weekly report or should I do another with more info?
<Keybuk> kwwii: I don't have one yet?
<kwwii> hrm, sabdfl received it (and responded), perhaps it ended up in your spam filter or such
* pitti got it, too
<iwj> Hmm, the gdebi -> gdebi{,-core} change seems to be stuck in NEW for the binaries.
<pitti> Keybuk: he means the report for the sprint, not the Wednesday evening report for this week, I assume?
<iwj> AFAICT.
<iwj> zul: Some intel onboard thing.
<kwwii> pitti: actually, i do mean the wednesday evening report :-)
<pitti> kwwii: oh, hm, sorry
<iwj> 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G] /GE Chipset Integrated Graphics Device (rev 01)
<Keybuk> kwwii: Subject ?
<kwwii> Keybuk: have you received any mails from me yet? (scott at ubuntu dot com, right?)
<kwwii> "a few pics for Wednesday"
<Keybuk> ah,  I got that one
<Keybuk> a more summary-type mail would be appreciated for the meeting
<iwj> Mithrandir: Is the gdebi -> gdebi{,-core} split held up now because of the herd 3 freeze or for some other reason ?
<kwwii> Keybuk: cool, will do
<tkamppeter_> cjwatson, I have added an appropriate comment to the printerdrake spec now.
<iwj> The relevant source upload was on Wednesday but the most recent source upload was on Friday.
<Mithrandir> iwj: yes, the split meant NEW processing and we're frozen now, so I'm not going to approve it before Friday.
<davmor2> help please.  Does network-manager work with intel chipset wireless?
<lifeless> usually. But please use #ubuntu or the answer tracker or forums for support questions.
<iwj> Mithrandir: OK, thanks for the info and I'll work around it locally somehow.
<giskard> davmor2, yes it works 
<davmor2> giskard:  It does now I needed to remove the config that was set up i /etc/network/interfaces for it to work though.
<sfllaw> pitti: Bug 73617: Please make sure the right release is targetted.
<Ubugtu> Malone bug 73617 in digikam "SRU proposal" [Undecided,Fix committed]  https://launchpad.net/bugs/73617
<pitti> hi sfllaw 
* pitti looks
<sfllaw> I'll set it to Edgy and Fix Committed.
<pitti> ah, I see
<pitti> sfllaw: so it should be 'fixreleased', and an edgy task 'fixcommitted', I guess
<sfllaw> Yeah.
<sfllaw> Medium importance, I guess.
<pitti> BenC: here?
<iwj> BenC: I have a reproduceable oops in dm_snapshot in Chuck's 2.6.19 for feisty Xen.  Are you at all interested ?
<iwj> snap
<pitti> iwj: funny
<pitti> iwj: I just wanted to tell him that I'll have the apport kernel oops hook ready by tomorrow
<pitti> BenC: ^ does that make sense to ship already? i. e. can the kernel actually trigger it somehow
<pitti> ?
<iwj> pitti: *snort*
<pitti> BenC: also, which package shall these reports be filed against? is linux-meta okay?
<iwj> For now I think I'll Not Do That Then.
<pitti> iwj: just to prevent misunderstandings, my apport stuff has nothing to do with you reporting oopses to Ben
<iwj> pitti: I gathered.
<BenC> iwj: not at all interested in 2.6.19 :)
<iwj> BenC: Hmm.  OK.  I might have to debug it myself then.  Do you know of a crash in this area ?  I'm not doing anything very unusual: I have a snapshot which I fill up and keep trying to write to, and which I then deactivate.
<BenC> iwj: No idea...haven't heard of anything
<iwj> OK, thanks.
<pitti> BenC: also, would it be useful for you to have the output of 'dpkg -l|grep linux-'?
<BenC> pitti: No, just /proc/version_signature is good
<pitti> ok
<pitti> BenC: SourcePackage: linux-meta is ok for you? Or shall I figure out the actual linux-image-<version>?
* pitti -> dinner
<BenC> pitti: linux-source-<ver>
<Keybuk> seb128: totem is unhappy
<Keybuk> futex() won't return
<Keybuk> I don't think it likes glibc or something
<Keybuk> it locks up after saying that it detected glibc
<Keybuk> *** glibc detected *** totem: double free or corruption (out): 0x00000000005d6910 ***
<Keybuk> somewhere in gstogg
<iwj> Detecting glibc is a sure sign of trouble.
<geser> does somebody have an idea why xmms2 didn't find a  c-compiler? http://librarian.launchpad.net/6012813/buildlog_ubuntu-feisty-i386.xmms2_0.2DrHouse-3.1ubuntu1_FAILEDTOBUILD.txt.gz
<geser> xmms2 build without problems in my pbuilder
<cjwatson> Keybuk: that message confuses lots of people :-)
<cjwatson> it should be written as "glibc detected a double free or corruption in totem" or words to that effect
<cjwatson> valgrind usually nails it
<bddebian> love those
<Keybuk> cjwatson: it should be written as "double-free detected (core dumped)"
<cjwatson> that too
<bddebian> geser: I'm going to try to build now just to see what happens
<Keybuk> raise (SIGSEGV) in glibc would be sufficient
<keescook> mornin'
<bddebian> geser: FTBFSs for me:
<bddebian> E: Couldn't find package libfaad-dev
<bddebian> W: Unable to locate package libfaad-dev
<bddebian> E: Could not satisfy build-dependency.
<geser> bddebian: which source version of xmms2?
<bddebian> xmms2_0.2DrHouse-3
<bddebian> Oh, where'd you get 3.1 from?
<geser> bddebian: it got it from Debian
<geser> but you should get 0.2DrHouse-3.1ubuntu1 from Ubuntu
<bddebian> I pulled what was in feisty
<geser> bddebian: https://launchpad.net/ubuntu/+source/xmms2/0.2DrHouse-3.1ubuntu1
<bddebian> Damnit, OK, sorry, let me try again
<keescook> curious about a bzr workflow issue.  I have a branch of apport.  pitti frequently pulls changes from my tree (but not all).  How do I diff against his tree without pulling down a full copy?  (i.e. it seems I can use "bzr diff /path1 /path2" but I want to do something like "bzr diff . sftp://...")
<pitti> keescook: I merged your entire tree, btw
<pitti> keescook: you can probably get my tree and bzr diff ../otherbranch
<keescook> pitti: hi!  :)  well, but didn't you fix the Dep issues?
<keescook> pitti: yeah, I was curious if there was a way to do it without pulling the tree to my local system.
<bddebian> pitti: \o?
<pitti> keescook: I just changed your patch to add the dep to the right place
<bddebian> Gah \o/
<pitti> bddebian: ?
<bddebian> pitti: Cheers for helping with archive admining :-)
<pitti> bddebian: you're welcome
<keescook> pitti: ah, I see.  You pulled my whole tree, then further updated it, so when I pulled it back, it has the changes.  Cool.
<bddebian> geser: Builds OK for me.  Maybe ask for a give-back?
<pitti> keescook: s/pulled/merged/, right
<pitti> keescook: you can either pull from mine now, or just create another branch from trunk
<keescook> sneaky bzr.
<pitti> keescook: but since I merged your's, you should be able to pull
<keescook> yeah, I re-merge every day; I think this last time may have been the first time you pulled directly from me, so that's why I hadn't noticed bzr fixing stuff the Right Way before.
<pitti> keescook: btw, I noticed that you can subscribe to branches in LP; I didn't try that out, though
<pitti> but I guess/hope it'll mail commit logs and so on
<keescook> oh, interesting...
<cjwatson> any Intel Mac owners here?
<mjg59> cjwatson: You?
<mjg59> cjwatson: I'll have another in a week or so...
<cjwatson> yes, I know I do :-)
<cjwatson> but I'm wondering if anyone else has the incredible slowness booting from CD
<cjwatson> (live CD)
<mjg59> Hm. What IDE module has it ended up binding?
<mjg59> If piix is loaded, there's likely to be a problem
<mjg59> Also, check whether /proc/interrupts is increasing like mad
<cjwatson> it sounds like the CD is stopping and re-seeking all the time
<cjwatson> mm, yes, both piix and ata_piix are loaded
<nnonix> When you find a bug that is files against the wrong package, should you just add a comment to that fact and let the dev's modify the bug itself or should you actually modify the bug report?
<cjwatson> mjg59: ide-cdrom seems to have got the CD
<mjg59> cjwatson: Ok, that's not a good start.
<mjg59> cjwatson: This is feisty?
<cjwatson> yeah
<mjg59> Does dmesg have lots of failed dma stuff?
<cjwatson> mjg59: n
<mjg59> Or is /proc/interrupts showing a huge number of interrupts for the piix irq?
<cjwatson> no
<cjwatson> mjg59: I dunno, what's huge?
<cjwatson> ide0 says 6508
<mjg59> Hm. Ok, so no.
<cjwatson> the controller is PCI 8086:27df
<mjg59> But piix really shouldn't be binding to that - ata_piix should be
<mjg59> Not sure if it'd actually fix this case...
<cjwatson> driver -> ../../../bus/pci/drivers/PIIX_IDE
<mjg59> I suspect that unbinding that would be... awkward
<cjwatson> looks like piix
<cjwatson> I can munge the initramfs on the way up and see what happens
<bddebian> BenC: Do you have any specific love/interest in kexec-tools?
<mjg59> 27DF is in ata_piix.c
<BenC> bddebian: Yes
<bddebian> BenC: Do you intend to re-merge it?  I filed a sync request for it but maybe I'm missing something important?
<BenC> bddebian: I'm looking at some other patches that it may need, so I'll be messing with it soon
<bddebian> BenC: OK, thx
<mjg59> BenC: So there still seem to be some duplicate IDs in piix and ata_piix - is that deliberate?
<BenC> plus implementing a real kdump in our initramfs
<cjwatson> piix.c claims PCI_DEVICE_ID_INTEL_ICH7_21
<BenC> mjg59: I thought you said dupes were ok :)
<mjg59> BenC: Not if they're both ending up in initramfs
<BenC> mjg59: That's a blacklist issue...unless one breaks and the other doesn't, then it should be ok
<BenC> is there any broken?
<cjwatson> BenC: scroll up
<mjg59> BenC: Hm. But Colin has piix.c bound...
<BenC> mjg59: ok
<mjg59> So something's going wrong :)
<mjg59> cjwatson: I'm not sure that this will actually help you, but it's worth a go if you can hack it form initramfs
<cjwatson> having trouble with the USB keyboard vs. initramfs
<mjg59> cjwatson: Ah, yes...
<BenC> mjg59: can you blacklist piix and see if that helps you?
<mjg59> BenC: I can't
<cjwatson> BenC: it's me
<BenC> err, cjwatson I mean
<cjwatson> I'll have to hack the initramfs elsewhere and re-burn the CD
<cjwatson> I'll just remove piix, simpler
<seb128> Keybuk: could you get a valgrind log?
<gvinueza> hello
<gvinueza> anyone?
<gvinueza> someone?
<ScottK> Yes?
<cjwatson> gvinueza: ask - don't ask whether you can ask
<gvinueza> well if someone can help me, i'm looking for some reference about development apps for ubuntu
<gvinueza> ok cjwatson
<gvinueza> so you can help me?
<gvinueza> what do i need (dev-apps), where to get it, etc...
<cjwatson> no
<cjwatson> the fact that I made a comment helping you to ask your question better does not mean that I'm volunteering to help
<gvinueza> ok, so them just put me in the right direction...
<cjwatson> this channel is for development of Ubuntu itself, not for developing applications on Ubuntu
<cjwatson> #ubuntu may be able to help, but if not you'll need to search the web
<gvinueza> ok, i have that very clear and in time i will do so, but now i need some pointers for developing apps on ubuntu
<Keybuk> seb128: it worked ok on feisty; assuming it's an edgy bug
<seb128> Keybuk: ok
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for herd 3
<gvinueza> ok... then see you later this year, bye
<bluefoxicy> umm
<bluefoxicy> I have a Control Centre?
<bluefoxicy> Center is spelled wrong.
<bluefoxicy> I looked, my language support is incompletely installed
<bluefoxicy> It's set to English (United States of America)
<bluefoxicy> so I tell it to complete installation, it downloads 4 *-en-gb packages
<bluefoxicy> this isn't quite correct, is it?
<cjwatson> mjg59: killing piix from the initramfs doesn't seem to help
<mjg59> cjwatson: Hrm.
<cjwatson> still waiting for it to boot to see what bound
<mjg59> cjwatson: Ok
<mjg59> cjwatson: dmesg would be great once you can get it
<cjwatson> sure
<cjwatson> bug or mail?
<mjg59> pastebin or whatever is fine
* mjg59 goes to the shops
<cjwatson> mjg59: /wg 79
<cjwatson> oops
<cjwatson> mjg59: http://pastebin.com/872301
<cjwatson> mjg59: ata_piix definitely bound this time
<zul>  /msg Mithrandir hi...did my xen-source upload i did this morning disappear?
<zul> shoot..
<kylem> frozen
<Mithrandir> zul: as kylem says, it's frozen.
<Mithrandir> and I haven't approved it because I want to keep a clear shot at the buildds for the kernel builds we've been doing
<zul> yeah i just realized it
<zul> not a problem
<sacater> is ubuntu feisty available for general public yet?
<Burgwork> mdz: ping
<Burgwork> sacater: yes
<Burgwork> has been since day one
<mdz> Burgwork: pong
<sacater> Burgwork: then howcome I cant see it in updates / the ubuntu websute
<Burgwork> mdz: I wanted to draw your attention to https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01561.html and https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01616.html 
<Burgwork> sacater: it is publicly available but not yet released as stable
<Burgwork> ie: there are alphas out there
<sacater> kk
<sacater> might get it for my laptop
<mdz> Burgwork: interesting, in a kind of familiar way
<mdz> I don't see anything new or different in the descriptions of either of them
<Keybuk> NIHLHCP
<Keybuk> the way things are going at the moment, when asked for a list of Linux-compatible hardware, it's easier to just give people www.intel.com ;)
<Nafallo> :-P
<Burgwork> mdz: indeed. Hopefully their little bit of work and our little bit of work could become more than each could do
<sfllaw> mvo: For bug 81428, do you want me to test synaptic on Edgy as well?
<Ubugtu> Malone bug 81428 in app-install-data-commercial "sugarcrm needs update of app-install-data-commercial and a synaptic fix" [High,Fix committed]  https://launchpad.net/bugs/81428
<mvo> hello sfllaw
<sfllaw> mvo: Hello!
<mvo> sfllaw: no, thanks. the version in edgy has the bug unfortunately
<mvo> sfllaw: I have not issued a SRU for this yet
<sfllaw> mvo: All right.  So just in dapper-proposed.
<mvo> sfllaw: yes, thanks
<sfllaw> mvo: OK, should be done in a few hours.
<mvo> cool, thanks
<lamont> keescook: re bind9, thanks
<keescook> lamont: yawp, no problmo
<keescook> lamont: any news on ISC regression tester?
<lamont> keescook: it won't be general availablility in any case, I expect - still working through identifying the right victim inside  HP to talk to about  me getting access
<keescook> cool.  I'm concerned with the dapper and breezy backports.  especially breezy; that whole area of code is verry different
<Adri2000> could an archive admin (if any is around) process the universe packages waiting please? :)
<Mithrandir> Adri2000: some accepted; I'm holding back the xen-source to avoid loading the buildds.
<Adri2000> ok, thank you
<sabdfl> Mithrandir: do we need more buildd's?
<Mithrandir> sabdfl: elmo has ordered more parts for two of the ones we have already, but the supplier is being slow, AIUI.
<Mithrandir> sabdfl: more buildds (or rather, faster buildds) is always welcome, though.
<Mithrandir> (one of the i386 buildds is approximately twice as fast as the two others, so making sure kernel builds go to the right place is crucial when we're a bit tight on time)
<sfllaw> kwwii: You may be interested in http://lgm.scribus.net/
<kwwii> sfllaw: hi! yeah, I wish I could attend but my parents and one brother have tickets to germany at the same time
<kwwii> sfllaw: I missed the last one as well
<sfllaw> kwwii: Oh dear.
<sfllaw> kwwii: It's in our neck of the woods.
<sfllaw> kwwii: Also, UDS is close to that time, but I thought you might be able to get a special exemption.  :)
<kwwii> sfllaw: not that I want to miss a sprint or anything
<kwwii> ;-)
<sfllaw> kwwii: Ha!
<sfllaw> kwwii: LGM is pretty work relevant.
<sfllaw> Especially if you could raise the needs of distributions.
<sfllaw> And corner Inkscape developers and give them your opinion about their gradient tools.
<sfllaw> ;)
<geser> Mithrandir: can you look at the build failure for xmms2? http://librarian.launchpad.net/6012813/buildlog_ubuntu-feisty-i386.xmms2_0.2DrHouse-3.1ubuntu1_FAILEDTOBUILD.txt.gz
<geser> Mithrandir: it builds fine in a pbuilder
<Mithrandir> geser: missing build-depends on git?
<Mithrandir> sh: git-rev-parse: command not found
<kwwii> sfllaw: I can see inkscape devs running in fear
<Mithrandir> unsure if that's the fatal one, though.
<_ion> Actually, i happened to build 0.2DrHouse-3.1 from Debian today. It printed the error about git-rev-parse, but built just fine.
<geser> Mithrandir: it builds fine without git-rev-parse
<geser> Mithrandir: I reports it can't find a c compiler but I don't know why
<Mithrandir> let me check
<sfllaw> kwwii: Maybe you can convince someone else to represent us?  Maybe Cliff?
<sfllaw> kwwii: Someone else from #*ubuntu-artwork?
<kwwii> sfllaw: still no response from Cliff yet, not sure what is up there
<kwwii> sfllaw: that would be the best course
<sfllaw> It'd be good if we got someone to go.  Good artwork seems to be very important for us.
<kwwii> I would love to go personally
<sfllaw> kwwii: But you don't want to be disowned.  I understand.
<sfllaw> :P
<kwwii> so many people that I have talked to online and in lists, it would be great to meet them in person
<kwwii> hehe, yeah
<sfllaw> All right.  Well, look around for someone interested and maybe point them at LouisD.
<ajmitch> kwwii: corner keescook? :)
<sfllaw> kwwii: LouisD is the one organizing LGM.  They're at #lgm on irc.freenode.net.
<kwwii> sfllaw: cool, I'll do that
<sfllaw> kwwii: Thanks.
* keescook tries to figure out what I should be cornered for
<ajmitch> keescook: you still have some inkscape involvement?
<keescook> ajmitch: I do, yeah
<ajmitch> or ubuntu has drained all your time :)
<kwwii> oh keescook, you shouldn't have admitted that
<keescook> kwwii: heh.  what's up?
<ajmitch> I shouldn't drop him in it 
<keescook> ah! found it.  gradient tool, eh?
<kwwii> keescook: just kidding mainly, but as artist, I do have a lot of issues with inkscape
<kwwii> first thing, someone should fix the nasty gaussian blur stuff, it kills my export times :(
<keescook> kwwii: hehe.  patches welcome!  join #inkscape.  :)
<sfllaw> keescook: Going to LGM?
<keescook> sfllaw: since I don't know what LGM is, I guess not.  :)
<sfllaw> http://lgm.scribus.net/
<sfllaw> keescook: It overlaps a bit with UDS.
<sfllaw> But it's the big graphics conference here in Montreal.
<dem> i'm trying to get hal to know to work with hotplugable devices in the ultrabay in the new lenovo/ibm thinkpads, on sata chips
<keescook> ah!  nah, but we usually have a bunch of inkscape core-devs there
<dem> however i have one issue that on those machines i need ide-cd to ignore the the ide cdrom so it can get picked up by the sata drivers... as a part of the install
<dem> anyone know how to go about making that work?
<cjwatson> Mithrandir: oh, smeg, I think crash handling is fucked in ubiquity at the moment
<cjwatson> do we care enough? (i.e. have you already built semi-final livefses?)
<cjwatson>     raise
<cjwatson> TypeError: exceptions must be classes, instances, or strings (deprecated), not NoneType
* gnomefreak hasnt checked yet but im hearing libgtk1.2-dev and libglib1.2-dev are unsigned. i will check after updates are done
<Mithrandir> cjwatson: no, haven't built them yet.
<Mithrandir> cjwatson: so please.
<_ion> Oh, gtk-1 still exists? ;-)
<gnomefreak> :) _ion yeah :(
<gnomefreak> all i know is im hearing they are warrning when trying to install them
<ogra> any idea about the current size after all the seed changes ? 
<ogra> i see there was no fresh build during the day at all ...
<cjwatson> gnomefreak: that's usually transient and goes away with the next mirror push.
<gnomefreak> ah ty
<okaratas> jono, hello
<jono> hey
<sabdfl> what's the monster new debug kernel all about?
<kylem> sabdfl, enabling people to sensibly debug things
<sabdfl> eggsellent
<kylem> need the vmlinux (the uncompressed, unstripped image) to be able to gdb it, for instance.
<sabdfl> taint notwithstanding ;-)
<kylem> :)
<cjwatson> Mithrandir: hmm
<cjwatson> Mithrandir: update-notifier isn't running in the live session
<cjwatson> Mithrandir: so apport-gtk = not so much
<Mithrandir> cjwatson: ugh.
<cjwatson> Mithrandir: what were we trying to stop there? just update-manager?
<Mithrandir> yes, afaik
<Mithrandir> it should still catch normal crashes, shouldn't it?
<cjwatson> don't see how
<cjwatson> ubiquity basically is a normal crash now
<Mithrandir> hmm
<Mithrandir> anything we can do about that now, or should I just releasenote it?
<cjwatson> I'm trying to figure out if there's an obvious way to fix it quickly
<cjwatson> removing the right files from /usr/lib/update-notifier would probably do it
#ubuntu-devel 2007-02-01
<cjwatson> gaah, apport per-package hooks are broken
<Mithrandir> cjwatson: we'll releasenote that, then.
<cjwatson> and I'm going to back out the ubiquity change to use apport hooks
<cjwatson> otherwise I'm not going to get decent crash information
<Mithrandir> ok; you needed an apport upload anyway, didn't you?
<cjwatson> s/an apport/a ubiquity/
<cjwatson> yeah, there's a new-partitioner crash I'd like to fix, trivial
<cjwatson> https://launchpad.net/ubuntu/+source/apport/+bug/82566
<Ubugtu> Malone bug 82566 in apport "per-package hooks are broken" [Undecided,Unconfirmed]  
<Mithrandir> ok
<keescook> Mithrandir, cjwatson: anything I can help with in the apport department?  I've spent a good bit of time digging around in that code.
<Mithrandir> keescook: I don't think so, ETA for the herd release is tomorrow and I'd like to go to bed soonish
<keescook> Mithrandir: okay.
<Mithrandir> so unless you have a fix now, I'd rather just have ubiquity back out the changes.
<cjwatson> keescook: 82566 makes it pretty clear, I think, but as Mithrandir says ...
<Mithrandir> thanks for offering, though.
<cjwatson> we could have a fix now, but I'm not sure what else would go wrong
<cjwatson> I'm already two or three levels deep here
<keescook> yeah, that's why I was offering; the fix is quick
<keescook> cjwatson: okay, makes sense
<keescook> next cut.  :)
<cjwatson> if Mithrandir wants, I *can* try out a fix on the spot
<Mithrandir> sure, if the fix is simple and Kees has it ready.
<keescook> as I understand it just needs         m = __import__(self['Package'] .split(' ')[0] )
<cjwatson> exactly what I was about to suggest
<cjwatson> give me a few minutes and I'll trigger it again
<cjwatson> Mithrandir: for casper, I suggest diverting away /usr/lib/update-notifier/apt-check and replacing it with a symlink to /bin/true
<cjwatson> that seems to work in my tests, and makes sense from the code
<Mithrandir> ok, so you'd like a casper upload too?
<cjwatson> yes - preparing
<cjwatson> a ubiquity upload probably isn't strictly necessary at this point, unless we want to fix that easy crash while we're here
<cjwatson> the crash in question is that if you edit a partition and then press OK without changing anything, the partman component crashes
<Mithrandir> sounds useful to get fixed.
<Mithrandir> I presume it's low-risk
<cjwatson> -                        del partition['active_partition_visit'] 
<cjwatson> +                        try:
<cjwatson> +                            del partition['active_partition_visit'] 
<cjwatson> +                        except KeyError:
<cjwatson> +                            pass
<cjwatson> three of those
<Mithrandir> looks same to me
<keescook> cjwatson: if it turns out you want it, I've got apport 0.47 ready to upload with that change.
<cjwatson> just doing a test run
<Mithrandir> s/same/sane/
<Mithrandir> sure.
<cjwatson> so. tired.
* mdke hugs cjwatson
<Mithrandir> cjwatson: did you crash?
<cjwatson> not yet
<cjwatson> keescook: looking good
<keescook> cjwatson: neato!  :)
<keescook> And I got a chance to link my bzr tree to a bug for the first time.  wooo!  :)
<cjwatson> bug 82573
<Ubugtu> Malone bug 82573 in ubiquity "[apport]  ubiquity crashed with KeyError in __init__()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82573
<keescook> cjwatson: oh well.  :(
<keescook> or wait?
<cjwatson> no no, that's good
<keescook> yay! it's got logs!
<keescook> I misread!
<Hobbsee> Mithrandir: [11:12]  <Hobbsee> Mithrandir: can you give back libgpod on all arches please?  (in the right channel)
<Mithrandir> Hobbsee: it's dep-wait
<keescook> cjwatson: shall I upload 0.47 of apport with that fix?
<Mithrandir> so it'll be done automatically when the deps become available
<Hobbsee> Mithrandir: the deps exist though.  how long will it take before it's redone?
<cjwatson> keescook: please
* Hobbsee doesnt remember
<Mithrandir> Hobbsee: hmm, weird.
<Mithrandir> Hobbsee: given-back on i386, let's see if that helps.
<Hobbsee> Mithrandir: thanks :)
<Hobbsee> that's the arch i checked on :)
<keescook> cjwatson: done.
<Mithrandir> keescook: accepted
<cjwatson> casper uploaded
<Mithrandir> cjwatson: casper accepted
<Hobbsee> Mithrandir: it still failed :(
<Mithrandir> Hobbsee: prod me again tomorrow or when herd 3 is out?  I'm about to fall asleep here.
<Hobbsee> Mithrandir: okay, sure
<Mithrandir> thanks
<Hobbsee> Mithrandir: go sleep then!  :)
<Mithrandir> I'm waiting for cjwatson to upload a new ubiquity
<cjwatson> ubiquity uploaded
* Mithrandir waits for */5 * * * * to hit
<Mithrandir> alternate CD images building.
<cjwatson> I added a quick fix for console-setup running update-initramfs while ubiquity was running
<cjwatson> I've tested it
<cjwatson> I'm not sure it's the right fix, but it's not totally wrong
<cjwatson> without it the keyboard page hung for a minute or s
<cjwatson> o
<Mithrandir> ugh, ok
<Mithrandir> ok, new ubiquity accepted.
<cjwatson> thanks, sorry again
<Mithrandir> let's hope all this works and that the fresh ISOs we get tomorrow morning work correctly.
<Mithrandir> universe stuff accepted, publisher's back on auto.  This should look better in the morning, I hope.
<Mithrandir> and with that, I'm off to bed.
<poningru> writing the release notes for herd 3
<poningru> need help
<poningru> with what to write about
<_ion> "Ubuntu Feisty, herd 3. 'nuff said."
<poningru> lol
<_ion> Yay, 2.6.20-6 fixed IPv6.
<_ion>           inet6 addr: 2001:14b8:1d6:1:2e0:4cff:fe30:a7de/64 Scope:Global
<beuno> does anyone know the gnome version that's in herd3?
<stdin> beuno: it's not out yet
<beuno> stdin, but isn't it frozen already'
<Lathiat> _ion: what was the issue in <2.6.20-6?
<geser> beuno: the current gnome in feisty is 2.17.90 so it should also be in herd3
<beuno> thanks geser
<beuno> geser, I'm cooking up the Herd3 release wiki, care to comment on major changes in herd3?
<Hobbsee> beuno: the easy codecs spec has been implemented
<beuno> Hobbsee, that's huge!
* beuno goes lookup the spec
<Hobbsee> for ubuntu
<Hobbsee> part of kubuntu already had it
<_ion> lathiat: IPv6 autoconfiguration didn't work, i.e. the only address the box had was the link-local one. Specifically, the latest kernel update fixed it. The relevant line from the changelog might be this one:   * [IPV6]  MCAST: Fix joining all-node multicast group on device initialization.
<bddebian> Heya
<Lathiat> ah right
<beuno> thanks Hobbsee, anything else anyone has to offer would be great, it's due tomorrow and I'm diggin through forums and mailing lists to try and gather information
<Hobbsee> beuno: look on ubuntu-devel ML
<Hobbsee> beuno: forums wont tell you anything of use
<beuno> Hobbsee, I am, it's just not terrible beuno-friendly   ;)
<Hobbsee> sort by subject
<Hobbsee> i think the zeroconf stuff is in progress - being tested.  iirc it was in other herds to
<Hobbsee> o
<beuno> Hobbsee, yes, that was introduced in herd2
<_ion> beuno: tracker is universe stuff, so it's probably not relevant, right? Its newest release contains huge speed improvements.
<_ion> (and a deskbar plugin)
<beuno> _ion, might work under the Gnome section, doesn't deskbar come preisntalled?
<poningru> it doesnt matter re: tracker
<poningru> last time we put in wine
<_ion> beuno: ubuntu-desktop does depend on deskbar-applet. But tracker isn't gnome-specific.
<Hobbsee> _ion: why not add it, universe's still supported
<Hobbsee> beuno: kde 3.5.6 (new release) is in there now
<Hobbsee> (bugfixes)
<beuno> _ion, you have a link to somewhere where the improvements are described?
<_ion> beuno: http://mail.gnome.org/archives/tracker-list/2007-January/msg00249.html (0.5.4 is 
<beuno> Hobbsee, great, addind that too  (kubuntu seems to be a bit ignored in these announcments)
<Hobbsee> indeed
<Hobbsee> we're still waiting on a couple of the high noted apps for kde :(
<_ion> beuno: Oh, also xfce 4.4 seems to be there.
<poningru> anyone know if the feisty cds will be availble through shipit?
<beuno> _ion: that's right!   thanks
<stdin> poningru: I doubt it
<_ion> beuno: Improvements in xfce 4.4: http://www.xfce.org/about/tour
<poningru> stdin: do you know when they will start doing shipit again? for non-dapper cds I mean
* beuno keeps firing up tabs
<beuno> poningru, afaik, with the next LTS version
<stdin> yep ^^
<poningru> ah ok
<beuno> any idea where I can find info on Gnome 2.16.9 changes?   Gnome's ML doesn't have anything
* Nafallo 2&1> bed
<sistpoty> gn8 Nafallo
<beuno> oh, it's 2.17.9
<beuno> ignore me  ;)
<czr> anyone working with the ia64-port?
<poningru> already asked in -installer does ubiquity's new partition editor have a name? or is it still gparted
<Burgundavia> am I daft or is there no daily desktop x86 cd?
<jsgotangco> hey Burgundavia
<Burgundavia> hey jsgotangco
<Burgundavia> http://cdimage.ubuntulinux.org/daily/current/ <-- nothing
<Mithrandir> Burgundavia: daily doesn't have desktop, daily-live has desktop.
<Burgundavia> Mithrandir: oh right, I am being daft
<Mithrandir> but the current desktop CD is out of date, I'm building fresh ones now
<zakame> is it just me, or is /etc/networks not included in netbase?
* Mithrandir makes an executive decision to not ship cvs on ppc alternate due to disk space issues.
<Mithrandir> Riddell: your ppc cd is hopelessly oversized.
<Mithrandir> Riddell: (i386 didn't build because of a soyuz bug)
<Mithrandir> ogra: what have you done to your build process?  Is your alternate CD only server now?
<poningru> Mithrandir: thanks for the reminder emails to -marketing :)
<pitti> Good morning
<Burgundavia> morning pitti
<Burgundavia> your apport is going to cause lots of work I can see
<pitti> Burgundavia: hi
<pitti> Burgundavia: any idea appreciated how to further reduce duplicate bugs
<Burgundavia> not at midnight, nope :)
<pitti> Burgundavia: right now we should improve the LP interface to point out that the displayed dup list is to be taken seriously
<pitti> Burgundavia: heh :)
<mpt_> pitti, apport's still hooked into Launchpad?
<pitti> mpt_: 'still'?
<mpt_> pitti, what I should have said was: Is there a chance of CrashReporting being implemented for Feisty+1? :-)
<pitti> mpt_: ah, I see
<mpt_> or at least before the next LTS
<mpt_> so that the BugSquad aren't brought to their knees
<pitti> mpt_: not sure yet; we should discuss again whether we actually need this, or just keep improving Malone; we had a short discussion with Bjorn at the sprint
<pitti> if we can get automatic dup detection into that, and automatic retracing, then it doesn't make much of a difference any morer
<pitti> and I'm this --><-- close to getting automatic retracing work on the DC
<mpt_> Sure it does, it makes the database fat and slow and hard to search
<pitti> right, we didn't drop the idea yet
<mpt_> and requires people to register with some site they have no interest in, just to report a crash :-)
<pitti> and it's not so much a matter of the db, it needs to be stored somewhere anyway
<mpt_> Yes, but old crash reports can be deleted, whereas old bug reports can't
<pitti> mpt_: if it's set in stone to never remove attachments from Malone, then you are right
<pitti> asac: hi
<ajmitch> hi pitti, mpt_ 
<pitti> hi ajmitch 
<Mithrandir> Riddell: your amd64 desktop CD is oversized too.
<cjwatson> Mithrandir: Edubuntu live -> desktop, install -> server as of a few days ago
<Mithrandir> cjwatson: ok.
<cjwatson> Mithrandir: serveraddon should be released along with server
<Mithrandir> I guessed that much
* StevenK ponders attending the development meeting to talk about AboutUbuntu
<Treenaks> AboutAboutUbuntu
<StevenK> :-P
<ajmitch> StevenK: what time is the meeting?
<mpt_> hey StevenK 
* StevenK waves
<StevenK> ajmitch: 7am for me
<mpt_> StevenK, did you get it into Universe?
<StevenK> I haven't uploaded yet, since I haven't sorted out the menu issue
<mpt_> ah
<StevenK> Which is one of the things I want to talk about tomorrow.
<ajmitch> StevenK: hm, just checked time, isn't it 8am for you, or have you finished with daylight savings?
<mpt_> fair enough
<StevenK> ajmitch: According to the fridge, its in 12 hours
<mpt_> StevenK, if you manage to get seb128's attention for a couple of minutes, he may be able to tell you :-)
<StevenK> It isn't just seb128, though. Where it goes for Kubuntu and Xubuntu is also important.
<StevenK> And if the same .desktop file can be used.
<mpt_> StevenK, I don't think Kubuntu would use a GTK program in the first place
<Riddell> nope
<StevenK> I've been thinking about that. Abstracting out into a module isn't hard.
<StevenK> It also means I have to find something like glade for KDE.
<cjwatson> Qt Designer
<mpt_> Don't the various terminal commands it calls count as abstraction already? :-)
<cjwatson> (qt4-designer, etc.)
<StevenK> mpt_: Somewhat. :-)
<StevenK> mpt_: I'd rather not duplicate code if I can help it.
* StevenK wonders if qt4-designer can make his life easy and import a glade file.
<cjwatson> haha, I doubt it
<StevenK> It was worth a shot. :-)
<Amaranth> yeah, i don't see that happening
<mpt_> StevenK, not that I'm a programmer or anything, but this sounds like making things very complicated
<mpt_> for an About box
<StevenK> Personally, I'd rather not leave Kubuntu out
<StevenK> Just because they don't use GTK.
* StevenK wonders what other people think
<cjwatson> Mithrandir: ubiquity 1.3.17 uploaded
<Treenaks> StevenK: so you need a glade2qt converter ;_)
<Treenaks> StevenK: maybe XSLT can do it (glade files are XML.. right?)
<StevenK> Treenaks: Or I do it by hand, I don't really mind.
<Mithrandir> cjwatson: waiting for */5 * * * *
<mpt_> StevenK, do you speak Norwegian?
<StevenK> I have enough trouble with English
<mpt_> ok
<mpt_> this seems a wee bit like
<Riddell> StevenK: there's no glade to qt designer converter, it has to be done by hand
<mpt_> You're wanting to publish a short story, and the thing that's stopping you is that you won't be able to provide the Norwegian translation
* mpt_ wonders if he's making any sense
<Mithrandir> mpt_: but he knows Norwegians, so that's not a showstopper. :-P
<Riddell> StevenK: but if you're talking about AboutUbuntu, it hasn't been spec'ed for Kubuntu and you'd need to think about where it would be launched from
* Mithrandir kicks the queue thingy.
<Mithrandir> where's the ubiquity upload?
* Riddell wonders why kubuntu powerpc is so hopelessly oversized
<mpt_> StevenK, if it's any good, a Norwe^WKubuntu developer will turn up and port it
<cjwatson> mpt_: while I see where you're coming from, I think it's a poor analogy
<mpt_> And if it's not, they're no worse off than they were
<Treenaks> cjwatson: they don't speak Norwegian in .nz ;)
<StevenK> Last time I brought this up, it was raised that AboutUbuntu is all about the branding, so why not a QT front-end?
<cjwatson> Mithrandir: oops, unsigned, reuploading
<Mithrandir> cjwatson: cheers.
<Riddell> StevenK: Kubuntu has different branding, I'm not against it but we don't need it immediately and it needsa bit of thought
<mpt_> StevenK, the initial rationale was to make it easy to see what version of stuff you're using, in a window that doesn't contain a Bookmarks menu.
* StevenK nods
<StevenK> And I quite like the idea, which is why I got interested and started helping
<StevenK> And my second thought was, "Why does it have to be Ubuntu-only?"
<cjwatson> Mithrandir: uploaded
<mpt_> I'm all in favor of Kubuntu doing whatever the Kubuntu designers think best
<StevenK> Agreed.
<StevenK> Personally, I don't think it's much work to move to a module and two frontends.
<dholbach> good morning
<Riddell> StevenK: it's not, design for the possibility and we'll make a Kubuntu frontend when we work out what we want
<StevenK> The minimalist one in GTK doesn't do it for you? :-)
<cjwatson> Mithrandir: I processed the upload manually to speed things up
<mpt_> StevenK, needs a Preferences dialog ;-)
<Mithrandir> cjwatson: thanks.  I was wondering if I was dreaming here.
<StevenK> mpt_: And a About dialog. :-P
<Mithrandir> cjwatson: accepted.
<Mithrandir> cjwatson: I'll byhand the publisher.
<mpt_> haha
<Mithrandir> ogra: your i386 desktop is oversized.
<Mithrandir> building i386 + ppc alternate ISOs
<StevenK> Riddell: Should have bought this up yesterday, so you could have discussed it at the Kubuntu meeting...
<cjwatson> Mithrandir: I stuck stuff about the advanced partitioner in FeistyFawn/Herd3 on the wiki; if you want something longer you can probably crib it from https://lists.ubuntu.com/archives/ubuntu-installer/2006-December/000003.html
<Mithrandir> cjwatson: thanks.  I'll pull that into the announcement as well.
* StevenK fixes bacula
<StevenK> The tray-applet Recommends desktop-environment | kde, which means installing it using aptitude marks about 700Mb of stuff to be installed.
<zakame> is it just me, or is /etc/networks removed from netbase?
<pitti> zakame: it's installed by base-files
<pitti> zakame: from /usr/share/base-files/networks
* StevenK puts a gnome-session in there
<zakame> ah... /me checks
<Riddell> Mithrandir: new kubuntu-meta uploaded
<Mithrandir> Riddell: thanks.
<zakame> pitti: hmm seems to be missing in mine, on edgy
<pitti> zakame: yup, was added on feisty
<zakame> ah
<pitti> zakame: edgy didn't install a networks file by default, but now we want to add the 'link-local' name
<pitti> . o O { Never ask developers about stable releases -- they don't use them :-) }
<Mithrandir> Riddell: I presume this is to fix the ppc problem?  I'll just rebuild that once it hits, if that's ok?
<zakame> pitti: yeah
<zakame> pitti: I was asking since I had a link-local network I couldn't access via edgy, but it was ok through etch
<Riddell> Mithrandir: yep
<Mithrandir> Riddell: i386 alternate rebuild finished, publisher running for new -desktop.
<Riddell> would be nice if .list had file sizes in it so I could work out why powerpc is so much larger than the others
<zakame> is cowbuider --create working already on feisty?
<Mithrandir> cjwatson: ^^ does anything use .list so we can not extend it?
<StevenK> dpkg itself?
<Mithrandir> StevenK: this is the .list in http://cdimage.ubuntu.com/daily-live/current/ and similar directories.
<Mithrandir> not the .list in /var/lib/dpkg/info
<StevenK> Ah. Never mind me, then. :-)
* StevenK watches update-initramfs and g++ fighjt
<StevenK> s/j//
<cjwatson> Mithrandir: not AFAIK
<cjwatson> Mithrandir: oh, stuff within debian-cd does, but I think it's obsolete anyway
<cjwatson> the old pseudo-image-kit stuff, superseded AFAIK by jigdo
<Mithrandir> ah, ok
<cjwatson> I'm sure debian-cd/tools/pi-makelist could be abused somehow
<Treenaks> http://questionablecontent.net/view.php?comic=808 
<ogra> Mithrandir, still ? ... looking into it ... 
<Mithrandir> publishing new ubiquity and kubuntu-meta
<ogra> Mithrandir, seeds updated, ready for a rebuild i think ...
<elkbuntu> ogra, i believe you might have forgotten to do something the other day... :)
<gpocentek> hello
<gpocentek> I won't have time to work on herd 3, so unless Jani comes around, I guess we'll wait for herd4 for Xubuntu
<Riddell> Mithrandir: looks like kubuntu-meta is in the archive, want to rebuild?
<Mithrandir> Riddell: that should already have happened
<Riddell> Mithrandir: I don't see new CD images
<Mithrandir> Riddell: let me investigate
<Mithrandir> gpocentek: ok, thanks for telling me
<Mithrandir> Riddell: sorry, I'm a muppet
<Mithrandir> Riddell: building now.
* Hobbsee waves to muppet Mithrandir 
<Hobbsee> or is that Mithrandirmuppet>?
* Mithrandir waves back to alien Hobbsee
* Hobbsee widens eyes and commences world domination.
<Mithrandir> Riddell: ppc rebuilt
<Riddell> Mithrandir: want to do the live CDs as well?  kubuntu has oversized amd64 and no i386
<Mithrandir> Riddell: yes, once lithium isn't busy, I'll do those.
<Mithrandir> that is, now.
<Riddell> ta
<gnomefreak> pitti and /or Riddell is there a  reason apport isnt included with kubuntu? im seeing kubuntu doesnt have a central place for crash reports its up to user to save it somewhere (if they do) and than have to remember where they saved it.
<Riddell> gnomefreak: the reason is that there's no KDE port of apport
<gnomefreak> good reason
<Riddell> gnomefreak: which is partly just that I havn't got round to it yet and partly because KDE already has a crash handler and I'm worried about what upstream will think if we replace it with our own
<Riddell> (also I did hear that there could be a bounty for a kde apport, but it would need to be clearly spec'ed first)
<gnomefreak> kcrash is kdes crash handler right? is there aa way we can get it to make a /var/crash or something like that and have it auto save toa  file? that way upstream doesnt have to worry about loosing it? i have seen bugs reports where users cant find crash logs that we need to find out the issue. (personally i dont think they are saving them)
<givr2> ogra: i took the initiative to work on the merge of fuse (2.6.2). Since you are the last merger, it's could be great if you could review it.
<givr2> debdiff -> http://paste.ubuntu-nl.org/3668/
<pitti> Riddell: oh, if you principally want an apport-qt, it's easy to do; I thought you generally didn't want it
<givr2> ogra: thanks 
<pitti> Riddell: A friend of mine might actually be interested in doing it
<gnomefreak> pitti: well i agree with Riddell it may not be best to remove kcrash and replace with apport. but would be nice if there was  away to auto save crash logs with kcrash (if kde doesnt want to lose kcras
<Riddell> pitti: I'm entirely unsure if we want it
<pitti> Riddell: I think the basis for that decision should be: is upstream happy with the krash reports they receive?
<pitti> Riddell: if yes> we might want apport for crashes of non-KDE apps
<pitti> Riddell: if not>check if apport can do better
<gnomefreak> pitti: btw ty i love new apport :)
<pitti> gnomefreak: \o/
<Riddell> it's on my todo list to look into
<ogra> elkbuntu, sorry, sorry ... i'll try to get to it, really
<ogra> givr2, ugh, where doe that initscript come from ? i'm not convinced we want to use that
<elkbuntu> ogra, thanks
<cjwatson> pitti: crash reports aren't just for upstream, considering e.g. things we wrote
<ogra> givr2, and please dont switch udev scripts to /bin/bash ... if there is a bashism in it we need to fix that rather 
<givr2> ogra: upstream. It's use to load fuse module at startup & mount the control filesystem
<ogra> givr2, we have a udev script for that and i'd prefer to put something into /etc/modprobe.d to load the module if fuse-utils is installed thats what its for ...
<pitti> cjwatson: right, that too; that's why I'd still love to see apport in Kubuntu for at least non-KDE things
<Mithrandir> Riddell: amd64 is oversized.
<givr2> ogra: bashism -> it's a function, so i didn't know what to do
<Mithrandir> Riddell: are the others candidate ISOs or should I hold them off until you've fixed the problem?
<ogra> giv
<ogra> givr
<ogra> meh
<ogra> my keyboard fr
<ogra> eaks out
<ogra> grmbl
<Mithrandir> Riddell: actually, i386 is oversized too.
<ogra> hmm ... now its working again ... tab and enter were swapped .... how weird
<ogra> givr2, well, make it POSIX compliant ... :)
<Riddell> err, hmm
<givr2> ogra: ok ;)
<ogra> bash isnt our system shell anymore ...
<cjwatson> givr2: functions are in POSIX shell; just leave out the 'function' keyword, which is entirely redundant
<ogra> admins might uninstall it in favor of some other shell ... or if you want to have fuse in initramfs for whatever reason there wont be a bash ....
<cjwatson> i.e. 'foo () { ... }'
<cjwatson> admins can't uninstall bash because it's essential, but other shells are faster which is why we prefer to use POSIX shell where possible
<ogra> well, still initramfs wont have a bash :)
<cjwatson> indeed
<givr2> ogra: so for the initscript, do you think it's better to not use it at all, and reinstall the udev rule ? and reuse /etc/modules ?
<givr2> ogra: will be a big diff
<ogra> givr2, well, the /etc/modules piece should be moved to modprobe.d 
<givr2> cjwatson: ok, thanks
<ogra> why a big diff ? just dont install the initscript ... 
<ogra> and make sure the udev one does everythng we need
<givr2> ogra: ok, i'll have a look at it
<givr2> ogra: thanks
<mjg59> New liferea seems somewhat slower than the old one
<ogra> thanks for looking at it :)
<ogra> really appreciated
<Riddell> Mithrandir: that still seems to be using the old kubuntu-desktop on live amd64, but since i386 is also oversized I'll need to edit the seeds/do kubuntu-meta again anyway
* ogra cries about the unmaintained status of shfs
<Mithrandir> Riddell: that would surprise me.
<cjwatson> Mithrandir: oh, should note in the announcement that the new partitioner is only for GTK as yet
<cjwatson> Riddell: if you want to start porting that now, I wouldn't object; there will still be changes, but probably at a manageable level
<cjwatson> Riddell: I suggest just doing the partition list UI to start with, as in GTK
<Riddell> cjwatson: I'll put it on my TODO for next week
<cjwatson> I'm making progress with the disk view UI now
<carlos> seb128: hi
<carlos> seb128: Danilo implemented https://bugs.launchpad.net/rosetta/+bug/81281
<Ubugtu> Malone bug 81281 in rosetta "Visual tag to represent non-breaking spaces" [Medium,Fix committed]  
<carlos> seb128: and It should be on production now
<carlos> seb128: it's not full support for non-breaking spaces, but it's an start
<seb128> carlos: hey, ah, cool :)
<pitti> mvo: would you mind if I abuse update-notifier once again for the notification for https://wiki.ubuntu.com/IncreaseHardwareDatabaseParticipation?
<pitti> mvo: I could depend on libnotify-bin and use that, but that lacks i18n
<mvo> pitti: I have a look after lunch
<pitti> mvo: no, I'll do it
<pitti> mvo: well, unless you really want to, of course :)
<StevenK> mpt: Refactor done. :-)
<pitti> mvo: just asking whether you would generally object
<mvo> sure, use it
<pitti> mvo: ok, thanks
<Mithrandir> ubuntu desktop and alternate are ready, please read https://wiki.ubuntu.com/Testing/ReportingResults before testing.
<pitti> Mithrandir, cjwatson: do we have a standard interface or a robust method for processes to detect whether they run on a live system?
<pitti> Mithrandir: (uid==999 would catch too much AFAICS)
<Mithrandir> check /proc/cmdline for boot=casper
<pitti> ah, nice
<pitti> Mithrandir: thanks
<Riddell> Mithrandir: new kubuntu-meta uploaded
<Mithrandir> Riddell: I presume the removal of example-content is just a temporary measure?
<Riddell> Mithrandir: yes
<Mithrandir> accepted and publisher running
<pitti> ogra: oh, hwdb-client does not yet comply to the new python policy, I'll fix that while I touch the package
<ogra> thanks
<pitti> ogra: I guess you would hit me if I just converted debian/rules to cdbs? :)
<pitti> (nevermind, I do it the debhelper way)
<ogra> pitti, go ahead
<ogra> cdbs is fine for it ...
<seb128> could ~/bin be added to the default path?
<seb128> we have a bug "gnome-panel run app dialog doesn't use ~/bin"
* _ion prefers ~/.local/bin :-)
<Hobbsee> seb128: isnt it already?
<Mithrandir> seb128: that's slightly nontrivial.
<seb128> Hobbsee: it is for bash due to .bashrc only, no?
<cjwatson> .bash_profile actually
<seb128> Mithrandir: the bug was asking for gnome-panel to special case ~/bin
<seb128> like look to it
<seb128> I'm not convinced that apps should be patch for that
<cjwatson> should probably be moved to .bashrc with an extra guard to avoid adding lots of instances of it
<Mithrandir> no, they shouldn't.  IMO.
<seb128> if that makes sense to look to ~/bin by default then the PATH should probably list it
<cjwatson> maybe it should go in .gnomerc or .xsession or whatever
<seb128> well, .gnomerc is an user file
<cjwatson> so is .bashrc
<seb128> not something we write by default
<seb128> right
<seb128> by any reason it can't be done at the system level?
<Hobbsee> seb128: ahh, probably
<cjwatson> unfortunately it can't go in /etc/environment because we can't do environment expansions there
<seb128> right
<seb128> maybe somewhere to xorg then, so it's not desktop specific
<seb128> rather than .gnomerc
<Mithrandir> cjwatson: maybe pam_env should have $HOME available.  It would make sense for some bits.
<Mithrandir> Xsession.d would work too, but I don't think it should be X-specific.
<cjwatson> putting it in .xsession would be inconvenient, since having that file existing overrides x-session-manager etc.
<seb128> Mithrandir: should I reassign the bug as a pam wishlist?
<Mithrandir> seb128: yes, do that.
<cjwatson> it's probably more appropriate on pam than anywhere else
<seb128> ok, thank you
<Mithrandir> heno: are you coordinating testing etc now?
<pitti> ogra: diffstat -> debian/rules |  107 +++-----------------------------------------
<ogra> :)
<ogra> nice
<ogra> pitti, would you put up big objections to having sshfs in main ? 
<pitti> ogra: at first glance it sounds relatively harmless to me
<ogra> fine ....
<ogra> i thought i better ask before bombing you with MIRs :)
<heno> Mithrandir: yes, I can do. Do you have some images for me? :)
<givre> ogra: just a little question. with an /etc/modprobe.d/fuse we can get ride of one part of the init script, but how can we replace the second part : mounting the fusectl stuff
<Mithrandir> heno: yes, I've filed bugs about the ubuntu images.  They should be all good.
<heno> Mithrandir: OK, I see them, thanks
<givre> ogra: it seams to be a new feature of 2.6.*
<heno> Mithrandir: 'good' as in ready for testing, not ready for release obviously
<Mithrandir> heno: correct.
<pitti> argh, argh
* pitti larts doko 
<pitti> doko: I just converted hwdb-client's bzr trunk to new python policy and just saw that you already did it
* pitti merges
<pitti> doko: also, your version has the files in /usr/lib/python2.5/site-packages/hwdb_client/, mine in /usr/share/python-support/hwdb-client-common/hwdb_client/; which is correct?
<pitti> BenC: morning
<BenC> pitti: hey, good morning
<pitti> BenC: I got your kernel apport hook ready; calling /usr/share/apport/kernel_hook now does nice things
<pitti> BenC: it'll be in apport 0.48 after herd-3
<BenC> pitti: excellent, I'll try to do something useful with it for the next kernel upload. Thanks!
<pitti> BenC: could you figure out how to trigger it from the kernel? Or do we need an userspace hack for that?
<kylem> pitti, rock on!
<AlexLatchford> Howdy guys, anyone know who the best person to assign a bug in the Preferred Applications Window is?
<AlexLatchford> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/41849
<Ubugtu> Malone bug 41849 in firefox "Firefox with "Open in new Tab" as preferred application does not show" [Unknown,Fix released]  
<pitti> ogra: hwdb-client doesn't output sound for me; is there an easy way to fix this?
<pitti> ogra: ooh, do you happen to use esd for that? I don't have that installed
<doko> pitti: python-central is correct =)
<pitti> doko: that's what I'm using :)
<doko> pitti: then they should not appear in /usr/share/python-support
<Mithrandir> cjwatson: hmm, the i386 alternate seems to still be busted wrt i82365
<Mithrandir> and taking ages to install
<pitti> doko: oh, argh, I should of course call dh_pycentral, not dh_pysupport *blush*
<pitti> damn copy&paste
<pitti> doko: so, they land in ./usr/share/pycentral/hwdb-client-common/site-packages/hwdb_client/ now, but your package has them in ./usr/lib/python2.5/site-packages/hwdb_client/
<pitti> doko: but I /u/s/pycentral/ is correct now?
<doko> pitti: yes
<pitti> doko: danke
<ogra> pitti, hwdb uses gnome_sound_play() iirc
<pitti> ogra: ah, and that certainly uses libgnome, which uses esd
<ogra> which should be fixed :) .... but a subprocess call to aplay wont do any harm i guess
<pitti> ogra: I uploaded a version with the menu icon and the gettext and python policy fixes now
<pitti> s/uploaded/in the long process of uploading/, thanks isdn
<ogra> ok, i'll look into the aplay fix
<pitti> ogra: not urgent, we install esound by default
<pitti> it just breaks totem A/V, that's why I uninstalled it
<ogra> do we ?
<ogra> we should really take pulse :) 
* pitti -> lunch
<ogra> its so cool :)
<pitti> ogra: did you fix the skips by increasing the frame size?
<ogra> skips ? 
<pitti> it sounds horrible here, apart from breaking OSS apps and multiuser
<ogra> its running fine here
<pitti> whenever I move a window, music playback crackles
<ogra> with five concurring clients i hear no skips or lag or anythig
<ogra> but it use alsa emu
<pitti> hm, weird; I thought my amd64/3000 wasn't the slowest box you could imagine...
<pitti> ogra: hm, that might be it, alsa seems to use longer frames
<ogra> well, i have a turion 2000 here as server .... my laptop
<pitti> I never got these skips with alsa directly
<ogra> right
<ogra> and ltsp now uses the alsa pcm and ctl emulation which gives me volume control for free
<givre> ogra: my opinion on that (fuse) is that we should use the init script only to mount fusectl, and make use of domount for that (i just had a look at mountdevsubfs). And we load the fuse module with an /etc/modprobe.d/fuse
<ogra> the only thing i havent solved (and likely wont solve in feisty) is the selection of the input source on the client hw
<ogra> givre, you can use the udev script for that 
<ogra> so if the module is loaded, the fusectl mount is done automatically ...if you unload it, the tmpfs gets unmounted as well
<givre> ogra: oh oh
<givre> ogra: didn't really know that...
<cjwatson> Mithrandir: it's a kernel bug, I can't solve it
<cjwatson> Mithrandir: hw-detect/start_pcmcia=false is a workaround
<Mithrandir> cjwatson: ok. :-(
<ogra> elmo, ping
<cjwatson> AlexLatchford: leave it unassigned, please
<AlexLatchford> cjwatson: I assigned it to the desktop bugs team for now, I presumed that someone from there will know what to do with it
<Mithrandir> ogra: your i386 desktop ISO is oversized.
<ogra> Mithrandir, i dropped all langpacks this m,orning, that cant be
<Mithrandir> ogra: 5MB oversized.
<ogra> a current build ? 
<ogra> hmm
<cjwatson> BenC: have you made any progress on the i82365 modprobe loop Mithrandir mentioned?
<cjwatson> (you or kyle)
<BenC> cjwatson: You know what, that was one of the things I wanted to discuss with Keybuk at oslo...can we add it to the agenda for today?
<cjwatson> BenC: it has a significant negative effect on the installer on any system without PCMCIA unless you know the magic workaround, and it really needs to be fixed
<cjwatson> BenC: sure
<BenC> cjwatson: We're still not sure if it's udev or kernel that should be fixed...I'll have to find the lkm thread about it
<Keybuk> kernel
* Keybuk is sure :p
* Mithrandir doesn't care, he just wants it fixed.
<Keybuk> the kernel adds a device to the system, and instructs udev to load an explicit module for that device
<Keybuk> and then immediately removes that device again
<Keybuk> (and fails the module load)
<Keybuk> so udev just sees a never ending stream of "load this module; load this module; load this module"
<czr> any ia64-port users/developers around?
<BenC> czr: I'm a user
<BenC> not really a porter for the arch, but I do the kernels
<czr> BenC, cool. which hw/version are you running?
<BenC> i2k
<BenC> the worst of them :)
<czr> I tried getting 6.06 and 6.06.1 installed on rx2600 and end result was really bad
<czr> had to install centos of all things. made me sad :-)
<czr> i2k?
<ogra> elmo, unping
<Keybuk> the kernel's doing several things wrong here
<Keybuk> 1) adding a device to the system before checking whether the device even exists
<givre> ogra: something like that http://paste.ubuntu-nl.org/3680/ ?
<kylem> czr, you might want to wait a couple hours and ask lamont about it.
<Keybuk> 2) giving an explicit module name in the MODALIAS, instead of a subsystem alias (e.g. it's doing MODALIAS=i82365 when it should do something like MODALIAS=platform:i82365)
<czr> kylem, ok, thanks
<lamont> kylem: why wate?
<lamont> wait, even
<kylem> lamont, 'cause it's only 7am? :)
<lamont> heh
<Keybuk> (#2 doesn't cause this bug, it's what prevents blacklisting from working as a temporary work-around)
* lamont got the home shift today - sick
<BenC> Keybuk: I'm willing to accept that...guess the ideal thing is to fix the three drivers having this problem and make them probe before registering the device
<Keybuk> right
<czr> heh. lamont, is there any version that works better than the rest? are 6.06/6.06.1 known non-working ones?
<Keybuk> like every other driver in the kernel does ;p
<Keybuk> they register the device as a result of a successful probe
<lamont> czr: ia64 server install?
<czr> lamont, sure.
<lamont> 6.06 seemed to work well for me
<lamont> what did you run into?
<czr> 6.06.1 had problems finding a suitable kernel to install -> no go. 6.06 had problems loading mpt-driver after first reboot. no go.
<czr> which was funny because the installer loaded the driver just fine.
<czr> so basically the system just was waiting for "root to become available", which never happened obviously.
<lamont> yeah... booting from the CD and chrooting into the right partition, mounting things, installing a nice kernel, and rebooting might have been one of the ugly steps at one point... I ran into that during one of the pre-release 6.06 builds - couldn't reproduce it though
<czr> and the reason for mpt modprobe fail for kernel symbol problems (didn't find symbols)
<lamont> I wonder if there's a mismatch there.
* lamont tested edgy server as well - that should work
<lamont> otoh, there's that support thing
<czr> I couldn't find edgy iso anywhere
* lamont larts Mithrandir 
<mpt> A driver of my own would be rather nice
<czr> mpt, oh, sry :-)
<mpt> I could do without being probed, though
* mpt wanders off to sleep
<czr> lamont, "that support thing" = not officially supported?
<czr> I understood that :-)
<lamont> czr: dapper == 5 years on server, edgy == 1.5
<lamont> Mithrandir/cjwatson: uh... where did we put the edgy ia64 isos?
<czr> ah. that one. yeah. that's why I wasn't that worried about edgy not being there. but was wandering whether I'd have better success with edgy. didn't really know the state of the port so was just wondering about many things
<Mithrandir> lamont: did we release them?  I can't remember anybody having tested them.
* lamont grumbles
<lamont> where are the untested ones then?
<cjwatson> good question, I think as Mithrandir said nobody had tested them
* lamont thought he had
<cjwatson> nobody claimed to have done
<lamont> czr: eta to people.ubuntu.com/~lamont/ubuntu-6.10-server-ia64.iso being there: 28 minutes
<czr> lamont, hmm. well. it's too late :-)
<czr> no need really anymore.
<ogra> hmm, something is weird with my seeds 
<cjwatson> easiest approach might be to rebuild them
<czr> as said, I installed centos on my itaniums. just feel bad about it.
<ogra> language-pack-kde-ar is on the live image, but there is nothing in my seeds that could pull it in
<cjwatson> though the server ISOs are still on http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/ along with feisty due to a bug in cdimage ...
<ogra> as well as a lot other langpacks
<lamont> cjwatson: neato
<cjwatson> ogra: suggests the livefs hasn't been rebuilt since the seed change
* lamont looks to see if he muttered anything about testing edgy/ia64
<ogra> cjwatson, well ...
<czr> lamont, anyhow, thanks for the help
<ogra> thats why i asked Mithrandir if he's referring to a current build 
<lamont> czr: np - and thanks for pointing out that the isos disappeared.
<lamont> cjwatson: I actually have what I believe to be the release isos for ia64/edgy - I'll go retest them just to make sure we're happy
<czr> lamont, np. just wished that I wouldn't have been in such hurry, I could still give a spin or two, but I've already setup the systems and don't have extra itaniums to test on :-(
<lamont> that'll be monday-ish though
<cjwatson> ogra,Mithrandir: the livefs builder uses tasks based on what the archive's Packages file says, so you need to wait for a publisher run after changing the seeds before rebuilding livefses
<lamont> czr: understood
<cjwatson> it looks like it was simply rebuilt too soon
<ogra> cjwatson, ah
<Riddell> Mithrandir: able to make me new livefs and cds?
<Mithrandir> cjwatson: the latest livefs-es were built a little more than an hour ago.
<Mithrandir> Riddell: sure
<Mithrandir> sorry, a little more than an hour ago
<Mithrandir> Riddell: running
<givre> ogra: this one should be better : http://paste.ubuntu-nl.org/3681/ but i'm still not sure if it's fine...
<givre> ogra: anyway, you have probably other stuff to do, i'll dug on that
<givre> ogra: thanks :)
<cjwatson> Mithrandir: the archive seems to be in sync now so I'd suggest just retrying
<janimo> Mithrandir: hi, when you are done with the other livefs and iso runs could you give xubuntu a spin as well? thanks
<Mithrandir> janimo: sure.
<heno> Mithrandir, cjwatson: http://cdimage.ubuntu.com/daily/current/MD5SUMS seems to be missing amd64 sums
<Mithrandir> indeed it does.
<Mithrandir> cjwatson: the scripts are supposed to copy them over, aren't they?
<czr> lamont, I might be able to run some live-cd on them later on to make images and retry the installation, but that will take some months. is the ia64-port under active development?
<heno> FWIW I get 83ed692d9f3a7545139db72f93a9cb6c  feisty-alternate-amd64.iso
* pitti goes offline for a bit, having no proper internet anyway; please ring my mobile on urgencies
* pitti goes offline for a bit, having no proper internet anyway; please ring my mobile on urgencies
<lamont> czr: reasonably active devel, yes
<czr> lamont, good to know :-)
<lamont> that is, I make sure it runs at least on HP's ia64 boxen
* czr nods
<lamont> and they even let me do that on work time. :-)
<czr> I have one rx2600 and rx1600 (old hp ones, itanium 2 though)
<czr> heh. lucky you then :-)
* lamont has a zx2000 and a (turned off) i2000
<lamont> good space heater, that one is.
<lamont> zx2000 is not bad
<czr> zx2000 is newer one? I haven't really followed ia64 stuff
<czr> just wanted to replace couple of no-brand-desktop-boxes with something that at least looked like a server (and had couple of spare itaniums, so :-)
<lamont> deskside version of the rx2600
<ogra> cjwatson, could it be that ship gets installed on my live image instead of ship-live ?
<czr> one funny thing I didn't quite get is that rx1600/rx2600 don't come with integrated RAID. just normal non-raid fusion/mp-tee things. makes me sad
<czr> lamont, ah, more quiet I'd think :-)
<lamont> 0000:20:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
<lamont> 0000:20:01.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
<czr> yeah. those. no raid.
<lamont> not bad.  I also have an rx2600 here
<lamont> swraid doesn't totally suck these days.. :-(
<czr> it does when you try to make the partitions start at exact boundaries (the efi eats space at start)
* Mithrandir prods at lamont to make him send him a zx2000 so he can test ia64 ISOs
<czr> I almost managed to do it. but missed by a sector or two. damn parted.
<lamont> hrm... 
<lamont> heh
<czr> lamont, any idea how to replicate efipart over the disks (raid1)?
<lamont> I don't know that efi would like that very much....  dd??
<lamont> the good news is that the efi partition contents change very infrequently...
<czr> err. suppose you have two disks. one of them breaks. the one that contains efi.
<czr> or you suggesting that nothing on itaniums ever breaks? ;-)
<cjwatson> Mithrandir: sort of. ideally when you start building images with a different name, the old name would be zapped
<lamont> yeah - I think I'm using manual-raid :-(
<cjwatson> ogra: no
<cjwatson> ogra: I described the exact problem above.
<cjwatson> ogra: the solution is "rebuild livefs now"
<cjwatson> ogra: don't invent problems
<czr>   8     1     256000 sda1 |   8    17     255999 sdb1
<ogra> oh, sorry, missed that
* czr shows fist at parted
<czr> damn floating point units gah.
<ogra> i was already digging through the logs when you said that :)
<lamont> czr: I looked at my disks...  I'm using 'lalalalalala raid' :-)
<lamont> that is, if/when sda dies, I'll be booting from CD, and then rebuilding /dev/sda
<czr> lamont, that must be some very special raid level :-)
<czr> yeah, that's what I'm doing too.
<czr> but it seems silly.
<lamont> yeah
<lamont> I'll pester some folks about doing something about that
<czr> that would be very nice
<czr> I have no idea how GPT works, otherwise I could have said something. I mostly work with x86-boxes
* lamont wanders off for a bit
<seb128> tkamppeter: could you have a look to https://launchpad.net/ubuntu/+source/libgnomeprint/+bug/75858? the guy replied to your comment
<Ubugtu> Malone bug 75858 in libgnomeprint "regression: png to postscript -> black image" [Low,Confirmed]  
<bddebian> Heya
<heno> For those who are testing ISO images: Please read this: https://wiki.ubuntu.com/Testing/ReportingResults and report results here: https://bugs.launchpad.net/ubuntu-iso-tests/+bugs 
<heno> and poke me if you have a question about the new setup
<Riddell> Mithrandir: did the kubuntu livefs build happen?
<iwj> Can I expect /var/run to exist and be writeable in the initrd ?
<Mithrandir> Riddell: yes, new live images are ready.
<Riddell> thanks Mithrandir 
<Riddell> have we turned off new parallel ATA stuff?  I seem to be back to hdaX
<mjg59> Riddell: You probably want to talk to Ben about that...
<Mithrandir> ogra_: new live isos building, should be ready in a little bit.
* Mithrandir relocates to home.
<ogra_> thanks
<heno> Mithrandir: could you run the LP bug-injection script for kubuntu?
<cjwatson> Riddell: depends on the driver - not everything moved
<geser> sabdfl: is there a reason why the poll for crimsun for MC starts nearly 11 hours later than the other four?
<sabdfl> geser: fixed, thanks
<pitti> mvo: FYI, I uploaded the new update-notifier with the hwdb notification and pushed the bzr branch
<cjwatson> pitti: given an apport-filed bug with a coredump in it, is there an easy way to say "grab this coredump, suck down the dbgsym packages, and turn it into a useful stack trace"?
<cjwatson> pitti: apport-retrace --lpbug <blah> might be nice
<pitti> cjwatson: not at the moment, I'll do exactly this with dholbach's new python-launchpad-tools package
<cjwatson> aha
<dholbach> (a package of bughelper)
<pitti> cjwatson: for now you have to download the attachments manually and call apport-retrace on it with the 'external files' options
<pitti> cjwatson: these apport-retrace things are only on apport's bzr head unfortunately (yay freeze)
<dholbach> pitti: once I'm through a bunch of nautilus bugs, I'll improve some small bits of bughelper/python-launchpad-tools and upload it
<pitti> cjwatson: easiest thing is just to download the coredump and call 'gdb app coredump' on it, though, and install the dbgsyms manually
<mvo> pitti: ok
<mvo> pitti: is there a way to get auto-subscribed on all bugs filed with the apport package_hook ?
<cjwatson> pitti: how does apport know how to get ddebs, by the way? I can't find anything referring to your people.ubuntu.com directory
<pitti> mvo: not that I know of, you should add a bookmark for a canned search, I guess
<pitti> cjwatson: you have to have that in your normal apt sources ATM
<cjwatson> ah
<cjwatson> shouldn't be hard to use a custom sources.list ...
<pitti> cjwatson: FYI, I'm currently working on a crazy fakechroot implementation that will allow us to do that automatically on the DC's porter machines
<pitti> cjwatson: right, adding that to apport-retrace itself is trivial, I just didn't want to hardcode the apt source
<Mithrandir> ogra_: new desktop images for you
<Mithrandir> heno: filing them now
<heno> thx
<Mithrandir> (filed)
<ogra_> Mithrandir, 676M ? ... bought ... :)
<Mithrandir> ogra_: ok, filing testing bugs
<ogra_> Mithrandir, hmm, where is my i386 server CD ?
<givre> ogra_: (some news from the fuse front to let you know. i don't think an udev rules will work. fusectl fs use the fuse module, and so if we trigger the unmount only when fuse is unload, it will not work, fusectl need to be unmount before and i don't see other alteranatives than an init script to do that. but i might be wrong...)
* keescook waves hi
<seb128> hey keescook
<keescook> hiya seb128
<Keybuk> seb128: gnome power manager won't start
<seb128> Keybuk: tell ogra, he's maintaining it ;)
<carlos> mvo: hi, could you join #ubuntu-translators?
<cjwatson> ogra_: speaking of which, did you see my comment to the effect that the fix you backported for my crash on startup was incomplete?
<carlos> mvo: there is a user asking about ddtp-ubuntu deployment
<Keybuk> ogra_: ?
<cjwatson> ogra_: you only applied the patch I sent, but that patch was supplemental to one that Richard had already applied
<holycow> morning
<holycow> guys i'm looking for confirmation that sudoers doesn't work proiperly on dapper
<holycow> specifically adding 'username ALL = /usr/bin/time-admin' does not give a specific user access to a specific binary such as time-admin
<seb128> cjwatson: he did an another upload with that changelog entry "make sure we apply both parts of the fix for 65-fix-ppc-crasher", what version do you use?
<holycow> does anyone have a dapper install they can try to confirm?  i have 2 dapper installs here where that doesn't work at all
<ogra_> cjwatson, i fixed it the same day
<ogra_> seb128, i guess his version he developed that patch on :)
<janimo> ogra_: regarding g-p-m not starting are you sure there's an autostat file in /etc/xdg?
<Keybuk> ogra_: any ideas?  it doesn't seem to get started on login, starts manually just fine, but disappears after a while
<Keybuk> janimo: I have no file in /etc/xdg
<ogra_> Keybuk, in autostart
<janimo> /etc/xdg/autostart
<Keybuk> there is no g-p-m related file there
<seb128> no .desktop there
<janimo> ogra even if I remoe and reinstall g-p-m I still get no desktop
<Keybuk> bluetooth-applet.desktop
<Keybuk> evolution-alarm-notify.desktop
<Keybuk> gnome-volume-manager.desktop
<Keybuk> nm-applet.desktop
<Keybuk> update-notifier.desktop
<Keybuk> -- 
<Keybuk> the installed package does not contain one either
<seb128> janimo: reinstalling a package doesn't restore a deleted conffile
<seb128> though in that case that looks like a package but
<seb128> not a conffile deleted
<Keybuk> it's not deleted
<Keybuk> it's simply not in the package
<janimo> seb128: I was replying to a comment in a LP bug related to this, so you had no context :)
<seb128> Keybuk: that was for information, not about that bug ;)
<Keybuk> right
<mjg59> janimo: Removing and reinstalling wouldn't result in it appearing if you'd deleted it at some point, so that's not a helpful check
<seb128> janimo: I thought you were typing on #ubuntu-devel
<janimo> bug 81304
<Ubugtu> Malone bug 81304 in gnome-power-manager "autostart desktop file location" [Undecided,Fix released]  https://launchpad.net/bugs/81304
<seb128> janimo: if you write on a chan either give context or don't write on the chan :p
<ogra_> DEB_MAKE_INSTALL_TARGET += autostartdir=/etc/xdg/autostart
<ogra_> seems it ignores that one
<mjg59> Hm. Does the "Ignore future crashes of this program version" box in apport actually work for anyone?
<ogra_> Keybuk, thanks, i'll fix after herd3
<janimo> seb128: I was writing to ogra and he has extra context :p
<seb128> ogra_: what "autostartdir=" is supposed to do?
<seb128> that's not a cdbs magic
<seb128> is that something from upstream?
<janimo> ogra_: g-v-m does a mv in postins from /usr/share/gnome without telling configure anything
<seb128> I would rather mv the file from /usr/share to /etc/xdg from debian/rules, looks a better way
<janimo> maybe that's better for g-p-m as well
<ogra_> right
<seb128> janimo: no no no
<seb128> not in postinst
<seb128> do it in debian/rules or .install
<janimo> mjg59: even if I delete with --purge ?If so how can I get a conffile back ?
<ogra_> i will just mv it
<seb128> janimo: man dpkg
<janimo> seb128: yeah, in the rules file. Mistyped. Not in a hook obviously
<mjg59> janimo: Oh, if you purge, yes. But that's a different state.
<janimo> mjg59: right, forgot to specify I purged as well.
<mjg59> Does anyone else here use Liferea?
<zul> i use to
<kylem> tollef does, i believe
<cjwatson> ogra_: ah yes, so you did, thanks
<kylem> mjg59, i preferred the mozilla extension one.
<mjg59> Mithrandir: Do you use liferea, and if so have you noticed it becoming much slower since the upgrade to 1.2? (I'm using the gecko backend, not the gtkhtml one)
<iwj> Our software is too buggy.  There are too many security updates.  Maybe we should stop shipping a web browser.
<kylem> iwj, let's all go back to gopher.
<iwj> I was thinking FTP, but yes :-).
<iwj> As we know, all ftpds are 100% secure and always have been.
<cjwatson> let's default to proftpd
<Nafallo> I see... scary people :-)
<Riddell> Mithrandir: all 6 kubuntu CDs are good to go
<BenC> anyone actually have an i82365 pcmcia on their system?
<BenC> need to test this driver to make sure it still works
<kylem> i82365 means not yenta, right?
<mjg59> Yes
<mjg59> In theory it should still drive it
<mjg59> But I think it might have been hobbled to prevent that now
<Riddell> bddebian: do you have a bug id for the konqueror profile issue?
<bddebian> Me again or bdmurray?
<Riddell> bah
<bddebian> :)
<Riddell> bah tab
<Riddell> bdmurray: ^^
<_MMA_> Mithrandir: Im to get Cinelerra packaged. They currently have 1 license file in the root dir to cover their source. Is this sufficient get approval from you guys?
<Mithrandir> mjg59: yes, I use it, no, I can't remember it being much slower, but I use the gtkhtml frontend.  I think.
<Mithrandir> _MMA_: as long as it covers the source correctly, yes.
<mjg59> Mithrandir: Hm. I should try the gtkhtml one.
<_MMA_> Mithrandir: Its GPL licensed and could you clarify "correctly" this is what we're a little fuzzy about.
<_MMA_> We're getting different opinions.
<Mithrandir> _MMA_: if all of it is GPL, that's fine.  If bits are GPL, bits are LGPL, bits are random other licences, make sure they're compatible and all shipped in the source.
<_MMA_> Ok. Thats good enough for me. Thank you.
<crimsun> and we should ensure that it's consistent with debian/copyright.
<_MMA_> crimsun: I asked muzzol to hop on the channel so when he does Ill hit you up if you have the time. We can look at it then.
<Mirv> _MMA_: you should probably package the "community edition" of Cinelerra, unless you are already doing that?
<Mirv> _MMA_: http://cvs.cinelerra.org/ - it's more stable, more supported bugfix-wise
<_MMA_> Mirv: Yup.Thats what we're doing.
<glatzor> Riddell: hi, still working? I have add support for adding and changing custom mirrors and a "select best mirror" function in software-properties.
<Riddell> glatzor: aww, man, and I had nearly caught up with you :)
<Mirv> _MMA_: great, I applaude you in beforehand :) it's a great addition to Ubuntu packages.
<_MMA_> Thanx. We're tryin.
<Riddell> glatzor: I see you changed import AptSources to lower case in your branch, but that doesn't seem to have been changed in the python-aptsources branch I'm using
<glatzor> Riddell: are there any bottle necks?
<glatzor> Riddell: aptsources was merged with python-apt
<Riddell> ah, groovy
<glatzor> http://bzr.glatzor.de/python-apt/sebi/
<Riddell> glatzor: just Herd CD testing getting in my way, otherwise I'd be done by now
<glatzor> Riddell: whoa, you are really fast
<Riddell> glatzor: I had a question, where do update radio buttons get disabled/enabled at program start?
<glatzor> Riddell: basically from /etc/apt/apt.conf.d/10periodic
<Riddell> glatzor: I ment at the UI level, I don't see any code in SoftwarePropertiesGtk.py to do it
<glatzor> AFAIK get_update_automation_level
<glatzor> wait I will check it
<Riddell> glatzor: but that doesn't touch the widgets
<glatzor> Riddell:(UPDATE_MANUAL, UPDATE_NOTIFY, UPDATE_DOWNLOAD, UPDATE_INST_SEC) = range(4) or none it returns one of the values 
<glatzor> Riddell: you can find the code in show_update_auto_level
<glatzor> no, it is show_auto_update_level
<glatzor> Riddell: but it is a good question if adept uses the apt periodic stuff
<Riddell> it does
<glatzor> Riddell: wasn't there a different implementation?
<glatzor> Riddell: oh, fine
<glatzor> Riddell: should extend the packaging?
<glatzor> should I ...
<Riddell> glatzor: sure, please do
<glatzor> Riddell: cool. I will merge all branches tomorrow.
<Riddell> glatzor: the gtk package is missing depends on python-glade2 and python-gtk2
<glatzor> Riddell: oh thanks
<Riddell> the kde one will need just python-qt4
<glatzor> fine
<glatzor> Riddell: are there any kde specific terms in the user interface?
<Riddell> glatzor: no
<Riddell> glatzor: oh, you mean strings?
<glatzor> Riddell: strings/terms yes
<Riddell> glatzor: yes, a few, I've not looked at i18n yet
<glatzor> Riddell: hm. so perhaps we have to add different gettext domains
<glatzor> Riddell: or let us just see if there are any conflicts
<Riddell> glatzor: shouldn't be a need for a different domain, most of the strings are the same
<Riddell> I add a few dialogue titles is about all, but actually the GTK one would probably benefit from that too
<pitti> mvo: there?
<mvo> pitti: yes
<pitti> mvo: if I have an apt.Cache() object and mark some packages with markInstall(), can I get a list of packages that it's going to install? (i. e. with all dependencies)?
<pitti> mvo: or even better, is there an easy method to get the transitive dependencies of a package?
<Riddell> glatzor: does the popcon box to anything yet?
<glatzor> Riddell: yes. it is fully working.
<glatzor> it was already part in edgy
<Riddell> glatzor: doesn't work for me on the gtk frontend, but maybe that's just me
<glatzor> Riddell: perhaps I introduced a bug
<glatzor> Riddell: oh you need to have popcon installed
<mvo> pitti: use Cache.getChanges() -> that will give you a list of packages. those need to be checked for "markedInstall, markedDelete, etc"
<Riddell> glatzor: aah
<mvo> pitti: as for the easier way, what do you need exactly?
<Riddell> glatzor: should it be disabled then?
<glatzor> Riddell: it isn't?
<pitti> mvo: I want to install a package into a chroot, then figure out which dependencies it has, and install the corresponding -dbgsym pacakges
<Riddell> glatzor: not for me
<Riddell> glatzor: actually, I do have popularity-contest installed
<glatzor> Riddell: I will take a look at it. it should be set to insensitive
<mvo> Riddell: it should modify /etc/popularity-contest.conf
<mvo> if the box is ticket
<mvo> h
<mvo> make that "checked"
<Riddell> "ticked"
<Riddell> nope, doesn't seem to edit that file
<glatzor> Riddell: than it is a transitional bug
<mvo> pitti: right. in this case, the mentinoed method is proably easiest
<pitti> mvo: hm, right, .markedInstall of course doesn't catch stuff like libc6 which is already installed
<glatzor> Riddell: I will investigate it tomorrow. I am currently at a client's office :)
<pitti> mvo: hm, something like getDependencies()?
<pitti> dir() doesn't reveal anything like that, though
<mvo> pitti: you can use apt_pkg.Config.Set("Dir::State::status","some/empty/file")
<mvo> pitti: currently you have to fall back to the apt_pkg interface to get a full dependency access
<pitti> mvo: hm, I could just as well re-use my existing dpkg-query method after installing the package then :)
<pitti> mvo: thanks a lot!
<glatzor> Riddell: does the config file exist on your system?
<glatzor> Riddell: currently we only write the config if the file exists
<Riddell> glatzor: it does yes
<ogra_> Mithrandir, could i get an i386 server iso as well ?
<mvo> pitti: feel free. I can send you some code for getDependencies() if you rather prefer that. it would probably be good to have something like this in the apt interface at some point
<mvo> Riddell: strange, works fine for me on feisty
<mvo> Riddell: can you put the file on a pastebin please (the configfile)?
<Riddell> mvo: it's just the default from my feisty install this afternoon http://paste.ubuntu-nl.org/3705/
<mvo> Riddell: strange, I will test it on my next test-install 
<heno> Riddell: tested amd64 desktop (installs fine). See: https://bugs.launchpad.net/ubuntu-iso-tests/+bug/82687 Should I subscribe you to all the Kubuntu images so you can track them via bugmail?
<Ubugtu> Malone bug 82687 in ubuntu-iso-tests "20070201.2: kubuntu amd64 desktop" [Undecided,Unconfirmed]  
<Riddell> heno: can you subscribe kubuntu-team?  that way they go to the mailing list
<Riddell> heno: thanks for testing
<Riddell> heno: is it just the tags that decide what CD the bug is for?
<heno> Riddell: I can do that. I don't think there will be very much mail this time around, but later it might be
<heno> Riddell: and the title
<Riddell> glatzor: does the cdrom treeview ever get populated?
<glatzor> Riddell: it should :)
<Riddell> glatzor: I don't see any code to do so
<Riddell> show_cdrom_sources() just clears it
<glatzor> Riddell: Indeed. that is right. I made a mistake.
<glatzor> hey, it was a quite drastic change :)
<Riddell> glatzor: ok, I can ignore it for now and come back to that bit later
<glatzor> Riddell: let us care about the bugs after the 8th :)
<Riddell> exactly :)
<glatzor> Riddell: s-p-qt will be avaible in adpet only? do you plan to add it to the control centre?
<glatzor> Riddell: how do you handle universe+multiverse by default in kubuntu?
<Mithrandir> ogra_: sorry, I misread; rebuilding all of them.
<Riddell> glatzor: yes, only through adept
<Riddell> glatzor: not sure what you mean, we do universe+multiverse same as ubuntu
<glatzor> Riddell: oh, gnome-app-install is independent of the activated components and does only use its internal filter
<glatzor> so software-properites and gnome-app-install work on a completely different level
<glatzor> that is why I would like to remove software-properties from the menu
<Riddell> glatzor: so even if you don't have universe in sources.list it can install from it?
<glatzor> and make it only available in adept
<glatzor> Riddell: yes. this functionality is required to also support the ISV sources, e.g. the canonical one
<glatzor> adpet_installer only shows "installable" applications?
<Riddell> hmm, right, yes it does
<Riddell> I was going to ask why -commerical isn't an option to enable
<glatzor> Riddell: but we can work around this quite easily
<Riddell> glatzor: how?
<glatzor> we would just have to add "deb http://canonical.com/ubuntu feisty-commercial main #Canonical" to the sources.list
<glatzor> so it would be displayed in the third-party software tab
<glatzor> of course "#deb http://canonical.com/ubuntu feisty-commercial main #Canonical" :)
<glatzor> then you could enable it by just one click
<Riddell> if we can convince the relevent person to include that
<elmo> glatzor: ehm, archive.canonical.com, pls
<elmo> maybe you were just shorthanding, but plain 'canonical.com' won't work
<glatzor> elmo: it was only a proof of concept :)
<elmo> glatzor: ok
<glatzor> but thanks for notifying anyway
<Riddell> cjwatson: got an opinion on putting -commercial in the default sources.list?
<pina> http://paste.ubuntu-nl.org/3710/
<pina> any clues
<Riddell> pina: a description usually helps
<ogra_> Mithrandir, ta
<pina> ok Riddell
<glatzor> Riddell: cjwatson: software-properties will use the comment of a sources list line for its display name in the third-party software tab
<Riddell> so I've found out
<pina> odd very odd I cant update or open Synaptic 
<pina> errors errors heh
<pina> I just want to make a nice background hah
<pina> Failed to fetch http://snapshots.ekiga.net/ubuntu/dists/edgy/main/binary-i386/Packages.bz2  Sub-process bzip2 returned an error code (2)
<pina> Failed to fetch http://snapshots.ekiga.net/ubuntu/dists/edgy/main/binary-i386/Packages.bz2  Sub-process bzip2 returned an error code (2)
<pina> Reading package lists... Error!
<pina> E: Dynamic MMap ran out of room
<pina> E: Error occurred while processing audacious-dumb (NewVersion1)
<pina> E: Problem with MergeList /var/lib/apt/lists/morgoth.free.fr_ubuntu_dists_edgy-backports_main_binary-i386_Packages
<pina> etc etc
<pina> :D
<pina> Riddell: any ideas
<Riddell> pina: does apt-get work?
<plougher> exit code 2 indicates corrupt compressed file, rather than I/O error.  Don't know if that helps
<pina> Riddell: i tried it and i get the errors I pasted above
<pina> weird now its working http://paste.ubuntu-nl.org/3713/
<pina> something an ubuntu developer should be looking into :(
<glatzor> pina: Riddell: too many sources. I think that there is a memory limit in apt somewhere
<glatzor> pina: you should fine some hints on goolge
<pina> hmm
<elmo> jesus that paste bin is stupid
<elmo> "You appear to be spamming the pastebin. I hate spammers so I won't let you. If you're not attempting to spam, please enable javascript so you can pass the antispam check"
<pina> it is
<pina> wait are you being sarcastic
<Riddell> pina: does reverting to a default sources.list fix it?
<pina> why would i need to spam it
<pina> let me try
<kylem> elmo, are you one of those weirdos like me who disable javascript?
<pina> ok Riddell how can i revert it to default?
<Nafallo> <3 no-script
<elmo> kylem: yeah.  on some days, I even use browsers that don't even support javascript
<kylem> word.
<elmo> but clearly (at least to the lovely folks behind ubuntu-nl.org) I'm just an evil spammer
<pina> how do i revert to default sources.list
<kylem> elmo, did you get those xen issues sorted?
<elmo> kylem: yep, thanks - took like 12 hours, but we are now Xentastic
<kylem> sweet... i think.
<pina> Riddell: ping
<iwj> python--
<Riddell> pina: hmm?
<iwj> Why can't it tell me about more than one syntax error per invocation ?
<Riddell> pina: http://www.ubuntu-nl.org/source-o-matic/
<pina> thanks go tit
<pina> it
<pina> :D
<pina> besides my current issue, did ubuntu for server need array conf, for proliant ML 370 ??
<pina> what i mean is configuragion array to raid for scsi 
<Riddell> Bad command or file name
<Riddell> (user questions in #ubuntu)
<pina> ok sorry
<zul> elmo: what issues if i may ask?
<elmo> zul: I was trying to get 2.6.16.38 kernels running with 3.0.4 and having some grief.  some of it was pebkac, and some of it was packaging - you've got a bug about the latter
<zul> super
<iwj> elmo: You're using a fairly vanilla 2.6.16.38 in the DC then ?  I wonder if that has the dm-snapshot bug which I've found.  It might be worth my while trying to set up something more similar to what you have.
<iwj> Certainly you wouldn't want to use autopkgtest in the DC with a kernel affected by this bug.
<elmo> iwj: yeah, very vanilla.  2.6.16.38 straight from k.o with patches from xen 3.0.4
<elmo> iwj: well we haven't tried using any snapshoting yet, only plain lvm
<iwj> Right.  What kind of kernel config ?  Custom for the box or you have some standard version ?
<pina> Riddell: i just reverted
<pina> I did and i get the same error
<elmo> iwj: we have a custom config, which works for all of our boxes of that architecture.  I just used that with the extra bits needed for Xen (bridging, disabling SCSI, etc.)
<iwj> The dm-snapshot bug didn't seem to turn up when I tested it by hand with the lv commands.  autopkgtest does things slightly differently and drives dmsetup by hand.
<pina> iwj: so then what is the issue
<iwj> elmo: Aha.  Could you email me a copy of the .config for that kernel ?  I expect it'll work for me and then I can check.
<pina> i was just rtying what Riddell suggested still doesnt work
<iwj> pina: dm-snapshot has an oops on device removal.
<elmo> iwj: it's amd64, is that ok?
<iwj> I can reproduce it by filling the snapshot from inside my Xen guest and then shutting the guest down with xm destroy.
<iwj> elmo: Err, no, unfortunately.
<pina> before that you're talking to me right, or referring to elmo's issue
<iwj> I mean, I have only i386.
<elmo> iwj: ok, well I should be building an i386 kernel in the next couple of days, I'll send you the config when I do
<iwj> Right, thanks.
<iwj> pina: I don't know anything about any of elmo's other issues :-).
<pina> woah confusing
<pina> :D
<pina> ok dm-snapshot bug
<pina> Riddell: ping
<pina> i'll figure something out
<pina> thanks 
<Adri2000> Mithrandir: please give back guifications on ia64
<_ion> adri2000: If i used gaim, i'd use gaim-libnotify.
<Mithrandir> Adri2000: given-back
<Adri2000> Mithrandir: thanks, do you have time to look at this FTBFS please http://librarian.launchpad.net/6034262/buildlog_ubuntu-feisty-i386.sim_0.9.4.2-1ubuntu1_FAILEDTOBUILD.txt.gz ? same error as the previous version uploaded by gpocentek and it builds fine in a pbuilder
<Adri2000> "Error: Package: and Architecture: do not alternate in debian/control"
<Mithrandir> let me check
<Lure> pitti: does bug 75017 waits for your push?
<Ubugtu> Malone bug 75017 in kubuntu-default-settings "SRU: remove /.hidden file " [Undecided,In progress]  https://launchpad.net/bugs/75017
<Mithrandir> Adri2000: unsure.
<Adri2000> Mithrandir: no idea? :(
<geser> Mithrandir: have you had time to look at the build failure of xmms2?
<Mithrandir> geser: no, sorry.  Been busy with herd stuff
<bddebian> Hurd? Awesome! ;-P
<geser> Mithrandir: np
<cjwatson> Riddell: yes, I don't think we should do it
<cjwatson> Riddell: (commercial)
<ogra> cjwatson, i discovered that pam_mount isnt possible with openssh at all ... do you happen to know a fix or patch for that ?
<ogra> i couldnt find anything yet
<cjwatson> ogra: after meeting
<ogra> yep
<ogra> thanks
<Adri2000> iwj: I'm trying to figure out the libnspr conflict between firefox and xulrunner, why firefox builds this package instead of using the one from xulrunner?
<kylem> pitti, btw, i finally managed to get the security kernels uploaded, can you approve them so they can ftbfs for me? :)
<pitti> kylem: no need to approve them, they'll ftbfs fully automatically :-P
<kylem> hmm.
<kylem> i got no mail.
<pitti> linux-source-2.6.15 | 2.6.15-28.51     | source              | 6 hours old
<pitti> linux-source-2.6.17 | 2.6.17.1-11.35   | source              | 6 hours old
<pitti> no binaries yet after 6 hours? hmm
<pitti> oh, heh
<pitti> linux-source-2.6.15 | 2.6.15-28.51            | all amd64 hppa i386 powerpc sparc | 5 hours old
<pitti> linux-source-2.6.17 | 2.6.17.1-11.35          | all amd64 i386 powerpc sparc      | 3 hours old
<pitti> ^ in NEW
<kylem> heh.
<keescook> why is it in new?
<kylem> spiffy.
<kylem> keescook, abi.
<StevenK> I'm guessing the ABI of the kernel changed
<pitti> kylem: ok, since they bump the ABI, we have to go to that crazy NEW/half-publish/NEW again/upload l-r-m/l-meta/NEW/half-publish dance again
<kylem> apparently people who write CVE fixes haven't grasped the concept of a stable kernel.
<pitti> kylem: does l-r-m actually need to build against the new kernel, or is it just the debian/control dependencies?
<kylem> pitti, the latter, likely.
<pitti> kylem: oh, no, they b-dep on l-headers
<tkamppeter__> pitti, have you got my mail about the corrected m2300w package?
<pitti> tkamppeter__: I replied with a complaint/question about the cupsys b-dep
<pitti> tkamppeter__: is that really necessary?
<pitti> cjwatson: any chance you could NEW the -security kernels on jackass?
<cjwatson> pitti: sure
* cjwatson dusts off his dak knowledge
<kylem> pitti, probably best to wait, i don't have lrm uploaded yet.
<elmo> don't bother
<elmo> I'm already on it
<pitti> elmo: thanks
<pitti> kylem: no, I need to publish them to the jackass archive before you can b-dep on them
<cjwatson> elmo: I'd only just managed to remember the script name. Thanks :-)
<pitti> kylem: will do in a minute
<kylem> ugh. complicated.
<pitti> kylem: breezy kernel ftbfs'ed on all but ia64 and powerpc; I sent zul the log a while ago
<kylem> haha.
<kylem> that's pretty backwards.
<pitti> kylem: yup, due to having two archive management systems here
<pitti> kylem: but the breezy one doesn't seem to change the abi, so that should be quicker
<kylem> uhh.
<pitti> cjwatson: btw, I guess we don't release a breezy point release any more? so we could get rid of the 8 month old d-i/installation-report security uploads?
<kylem> i don't see how that's possibly, unless he just ignored patches which did.
<pitti> kylem: probably exactly this happened
<sfllaw> mvo: Bug 81428 is ready for upload.
<Ubugtu> Malone bug 81428 in app-install-data-commercial "sugarcrm needs update of app-install-data-commercial and a synaptic fix" [High,Fix committed]  https://launchpad.net/bugs/81428
<tkamppeter__> pitti, I have seen the mail now. configure check for /usr/share/cups/model and this dir is provided by the cupsys package. I don't think that we should split cupsys for that.
<pitti> kylem: which CVE was the complicated one again?
<pitti> tkamppeter__: I agree
<tkamppeter__> pitti, simply upload it.
<pitti> tkamppeter__: alright
<kylem> 4572 and 5753 changed the ABI.
<pitti> tkamppeter__: can you please put the source.changes on your page?
<pitti> tkamppeter__: I'm on strings-and-cans internet ATM and down/uploading the entire package would take a while
<cjwatson> pitti: yeah, it's pretty unlikely at this point
<pitti> kylem: right, neither are fixed in the current upload
<Lure> pitti: any chance to accept bug 75017 in edgy-proposed?
<Ubugtu> Malone bug 75017 in kubuntu-default-settings "SRU: remove /.hidden file " [Undecided,In progress]  https://launchpad.net/bugs/75017
<pitti> Lure: I'll do some archive admin tomorrow morning
<kylem> pitti, sigh. ok.
<kylem> pitti, maybe i'll do it. there's only likely one or two breezy uploads after this before we EOL it going by the current timelines.
<Lure> pitti: thanks
<pitti> kylem: OTOH the local DoS in iso9660 wasn't that critical/urgent either
<pitti> keescook: claiming USN-416-1 for the currently pending kernel upload
<keescook> pitti: go for it.
<pitti> keescook: I probably won't release before next week, though
<tkamppeter__> pitti, sorry, mistyped the filename when creating it and so it did not go up with the package upload. Now it is on my site.
<keescook> pitti: that's fine.  :)
<pitti> tkamppeter__: thanks; uploaded
<pitti> tkamppeter__: oh, argh
<pitti> tkamppeter__: please do not build with -sa
<ogra> cjwatson, so any suggestions about openssh and pam_mount ? i only found debian bug 242119 but that seems not to fix pam_mount
<kylem> pitti, should lrm be targetted at -security too?
<pitti> kylem: yes, and -meta
<Ubugtu> Debian bug 242119 in ssh "ssh - password authentication never uses pam" [Grave,Closed]  http://bugs.debian.org/242119
<kylem> okies.
<pitti> tkamppeter__: I mangled the .changes and uploaded for real now
<elmo> kernel's out of NEW
<kylem> elmo, thanks.
<kylem> did it build everywhere?
<pitti> kylem: yes
<kylem> excellent.
<pitti> kylem: ok, published those to jackass' archive; please upload l-r-m and l-meta now, then l-r-m need to go through jackass' NEW
<kylem> ok.
<pitti> kylem: thanks
<tkamppeter__> pitti, what is the correct command line for the _source.changes file then?
<pitti> tkamppeter__: 'debuild -S' in that case
<tkamppeter__> Thanks, I used always dpkg_genchanges.
<pitti> tkamppeter__: oh, that's pretty low-level and usually not necessary
<tkamppeter__> pitti, also thanks for the upload.
<pitti> debuild is easiest, some people use dpkg-buildpackage (same options)
<pitti> tkamppeter__: you're welcome!
* pitti -> bed, cu tomorrow
<cjwatson> ogra: ok, sorry, I know I said I'd look after the meeting but I think it's going to have to be tomorrow morning now - hope that's ok
<cjwatson> ogra: a bug reference or reproduction recipe would be appreciated
<ogra> sure, totally fine 
<cjwatson> know that openssh and pam is historically a can of worms, though it's mostly settled down now
<ogra> seems its a longstanding bug with openssh and privilege separation
<cjwatson> the bug you refer to may not be the same thing
<ogra> pam_mount doesnt seem to get the right password handed over ...
<ogra> Feb  1 23:33:03 edubuntu sshd[23777] : pam_mount(pam_mount.c:453) error trying to retrieve authtok from auth code 
<ogra> Feb  1 23:33:03 edubuntu sshd[23777] : pam_mount(pam_mount.c:159) conv->conv(...): Conversation error 
<ogra> Feb  1 23:33:03 edubuntu sshd[23777] : pam_mount(pam_mount.c:456) error trying to read password 
<cjwatson> anyway, it's complicated, let's please look at it in the morning
<ogra> i'll go on diggin
<ogra> yep
<keescook> Ack... can someone push the gtk+2.0 security upload through LP?
<Mithrandir> keescook: which queue?
<keescook> main
<Mithrandir> wrong answer.
<Mithrandir> which suite?
<Mithrandir> (edgy, dapper, ..)
<keescook> breezy, dapper, edgy
<kylem> ok, lrm and linux-meta uploaded.
<ogra> security
<Mithrandir> ogra: that's a pocket, not a suite.
<ogra> i know
<gnomefreak> has anyone pushed kernel or X uploads for edgy the past couple of days?
* mdke points at the changes mailing list
<keescook> gnomefreak: I don't see any in the edgy-changes mailing list.
<Mithrandir> kylem: whereto?
<kylem> Mithrandir, -security
<Mithrandir> keescook,kylem: publisher running.
<keescook> Mithrandir: thanks
<Mithrandir> we should really split the publisher runs so -security isn't affected by regular freezes.
<keescook> kylem: I thought you weren't doing a publish of the kernel updates yet?
<kylem> eh? why not?
<keescook> I thought pitti said you had to do some dance with publication/NEW or something
<kylem> well. someone might have to, but that person isn't me. :)
<keescook> heh
* kylem doesn't touch any of this stuff...
<Mithrandir> kylem: you might want to poke an archive admin, then.
<keescook> Mithrandir: just to double-check: there weren't any kernel updates in the queues for publication, right?
<Mithrandir> let's see
<kylem> oh. pitti is already gone. nevermind.
<keescook> Mithrandir: if there is, we need to freak out a little -- they're not all done.
<keescook> I'm pretty sure they're just on jackass right now, but kylem got my worried.  :)
<keescook> s/my/me
<Mithrandir> keescook: which suite?
<keescook> Mithrandir: I wouldn't know; I wasn't expecting a kernel to be published to LP yet.
<Mithrandir> kylem: suite?
<kylem> no sugar for me, thanks
<kylem> Mithrandir, que?
<keescook> I'm going to assume there isn't one, and will calm down now.  :)
<Mithrandir> kylem: where did you upload that kernel?
<kylem> i'm going to assume suite means distro, and {edgy,dapper}-security.
<Mithrandir> suite is {warty,hoary,breezy,dapper,edgy,feisty}, yes.
<Mithrandir> {release,updates,proposed,security} are pockets.
<Mithrandir> kylem: what'd the version be?
<Nafallo> 2.6.15-28.51 2.6.17.1-11.35
#ubuntu-devel 2007-02-02
<Adri2000> when is the freeze ending?
<Nafallo> when herd 3 is released
<Adri2000> Nafallo: right, ETA was today I believe, delayed?
<Nafallo> oh. right. it must be. hadn't struck me yet :-)
<kro> I'm trying to use the netboot images for fiesty located here http://archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386/current/images/netboot/ubuntu-installer/i386/
<kro> I start booting the installer, and it craps out with a message about not being able to find the kernel
<kro> this is after detecting the keyboard.
<orkid> i hope you don't mind me asknig in devel, but ubuntu wasn't much insight yet, but why is port 32768 open?
<orkid> (feisty)
<orkid> hmm, i'll try the forums
<pitti> Good morning
<mneptok> arr, pitti 
<zakame> yo pitti
<pitti> hey mneptok, good morning!
<mneptok> morgen!
<rideout> dbus-uuidgen is giving me the following error in feisty, 
<rideout> symbol lookup error: dbus-uuidgen: undefined symbol: dbus_internal_do_not_use_create_uuid
<dholbach> good morning
<pitti> heno: good mornign
<pitti> heno: it would be nice if the iso test bug summaries could mention a list of test cases
<heno> pitti: ! Thanks for testing with the new tracker How is it working for you?
<pitti> heno: takes a bit to get used to, but not bad
<cjwatson> kro_afk: we just changed the kernel ABI, so you need to make sure that you have a very current installer
<pitti> heno: my biggest struggle is actually finding installer bugs I filed ages ago and which I now re-detect
<heno> pitti: would a link to https://wiki.ubuntu.com/Testing/InstallMethods suffice?
<heno> right
<Mithrandir> pitti: do you have any idea why sim ftbfs?  It seems to be pkgstrip-tingabob related.
<pitti> heno: probably, but why not just add it to the summary? I guess you have a script which creates those reports anyway?
<pitti> Mithrandir: will look at it
<pitti> mvo: good mornign
<pitti> mvo: thanks for the nice apport demo on the live system :-P
<mvo> good morning pitti!
<heno> pitti: Tollef does, yes
<Mithrandir> pitti: thanks.
<heno> Hm, I think I'll make a wiki page for feedback like this 
<heno> and then review before Herd 4
<Mithrandir> pitti: sfllaw promised me a text to put in the bug reports.  He has so far failed to do so, but improvements are certainly welcome.
<pitti> heno: another thing is that it is now pretty hard to see what still needs testing
<pitti> heno: maybe bughelper can help us with creating a table-like report, similar to the Testing/Current page?
<heno> pitti: my idea for that was to (ab)use the importance setting
<pitti> heno: I meant 'oh, amd64/alternate still needs OEM tested'
<dholbach> pitti: we have a format_wiki() function already - I was never sure which format to use, but if anybody wants to hack that, that's cool
<heno> High for still needs testing, Critical for failed (needs fixing), Wishlist for tested plenty already
<pitti> heno: ah, that's a good first step
<pitti> dholbach: yay :)
<heno> pitti: yes, more important for Beta and onwards, but we should get it working. Perhaps a separate bug for each test case 
<pitti> hmm, did anyone try live/check? it boots straight into the live system for me
<cjwatson> heno: once this has all settled down, a post to ubuntu-devel-announce about how developers can process the results would be good
<heno> cjwatson: yep, and some thoughts on improvements
<macd> bug #78282 is there someone I can contact as to an ETA>?
<Ubugtu> Malone bug 78282 in vnc4 "vnc4server does not start Desktop environment after security update" [High,Confirmed]  https://launchpad.net/bugs/78282
<givre> ogra: hello. i think i'm ok with the fuse merge. debdiff -> http://paste.ubuntu-nl.org/3808/
<pitti> macd: it's known and it's veery ugly, will take some time to fix
<macd> I was digging through it some, yes its definetly no quick hack.
<macd> pitti, tyvm btw.
<givre> ogra: i use the udev rules to mount the fuse control filesystem, but i don't unmount it with the rule, because 1. it's impossible (AFAIK). 2. It's done anyway by /etc/init.d/umountfs
<givre> ogra: what do you think ?
<pitti> macd: we could do some nasty hacks to put back the original edgy debs into -security, but it would be better to actually track down the toolchain/library regression that caused this mess
<cjwatson> we're not going to downgrade
<macd> well since edgy gets a feature feeze soon, I dont think nasty hacks are the best plan of action, and nor do you ;)
<cjwatson> macd: er ... feisty is the one feature-freezing, edgy is released
<macd> yeah, my mistake.
<macd> 3:30am here.
<pitti> cjwatson: no, re-label the edgy .debs with a higher -security version number, but that's really something I'd try to avoid
<cjwatson> 9:30am doesn't make me any more awake than you, believe me :-/
* mneptok laughs
<mneptok> screw you all ;)
<macd> well, not any more awake, but surely more aware, 20 hours in front of a PC tends to take its toll on your minds sharpness
* mneptok looks at the clock reading 0427 and realizes his workday is half over ;)
<macd> ohh, thats a nasty shift.
<mneptok> in at 2300, out at 0800. your complaints of "it's late!" fall on deaf ears here. :)
<mneptok> (of course, when i complain that it's late at 1700UTC you can all point and laugh) ;)
<macd> If I spent less time in #ubuntu answering questionbs and more time working, well....we all know
<macd> yes, its 5pm somewhere, right now.
<Kano> hi Mithrandir
<Kano> hi niktaris
<Kano> is there something wrong with pbuilder now?
<Kano> it stops at
<Kano> I: Configuring console-setup...
<Kano> I: Configuring ubuntu-minimal...
<Kano> I: Base system installed successfully.
<pitti> Mithrandir: sim> 'Error: Package: and Architecture: do not alternate in debian/control' -> ah, that's pretty clear then; duplicate Architecture: field or so
<heno> Mithrandir: are you monitoring the 'ISO bug' comments for found bugs and/or should I copy them over to Testing/Current?
<Kano> is there a tool to create current snapshots of alternative/desktop images?
<Kano> would need that...
<Kano> btw. openoffice draw lacks a kde menu entry
<Riddell> Kano: hmm, so it does
<Riddell> "NoDisplay=true"  that'll be why
<Kano> hi Riddell
<Kano> do you know why i cant create a pbuilder environment?
<Kano> i deleted the old, need a new...
<Riddell> "Base system installed successfully" sounds like a success to me
<Kano> Riddell: nope, it stops
<Kano> thats wrong
<Kano> i guess debootstrap is somehow wrong
<cjwatson> seems unlikely
<seb128> do we use wodim instead of cdrecord as Debian do?
<cjwatson> debootstrap's hardly changed in ages and it works in lots of other situationsn
<cjwatson> seb128: yes
<seb128> ok
<seb128> so I need to update nautilus-cd-burner
<Mithrandir> pitti: it is?  I can't find it.
<seb128> it tries calling readcd by example
<cjwatson> I thought we had a wrapper scripts
<Mithrandir> heno: just about to investigate
<cjwatson> script
<Kano> well not the debootstrap package itself, but maybe some main tools
<seb128> cjwatson: I've no readcd on my feisty apparently
<cjwatson> ah
<seb128> hum
<seb128> that has been fixed with 9:1.1.1-1 to Debian
<pitti> seb128: hi
<seb128> hey pitti
<pitti> seb128: new installs currently have both n-m and the gnome network monitor in the panel
<pitti> seb128: against what shall I file that bug?
<seb128> pitti: you want the network monitor applet to be dropped probably?
<seb128> pitti: gnome-panel
<Kano> it is debootstrap that hangs, just tested
<pitti> seb128: right
<pitti> seb128: ok, will do
<seb128> danke
<Kano> debootstrap feisty feisty-test http://de.archive.ubuntu.com/ubuntu
<Kano> try yourself
<Kano> you might need to do
<Kano> ps aux |grep deboot|awk '{print $2}'|xargs -r kill -9
<Kano> umount feisty-test/proc feisty-test/sys
<Kano> in case it locks for you too...
<cjwatson> I maintain debootstrap in Ubuntu insofar as anyone does; I know how to clean up after it :-)
<cjwatson> Kano: works fine for me
<cjwatson> Kano: I suspect your system is misconfigured somehow, although I don't know how
<_ion> kano: pgrep deboot | xargs ...
<cjwatson> jeez, pkill
<_ion> Argh, such a brainfart. :-)
<cjwatson> after the message you mention seeing, debootstrap does: kill old temporary sources.list and set up a new one; save log file; sync; clean up $TARGET/debootstrap
<cjwatson> I suppose sync might hang if your kernel oopsed in the meantime
<Kano> does not matter, it stops
<fabbione> morning 
<Kano> i will not fix it manually...
<Kano> i need it for pbuilder
<Kano> well maybe sync is the problem
<Kano> will test it later
<Mithrandir> pitti: if you could actually verify that installs worked, etc, (in the ubuntu-iso-testing bugs), that'd be good.
<pitti> Mithrandir: oh, ok
<pitti> Mithrandir: I thought 'no news is good news'
<Mithrandir> well, true, but I'd like an explicit confirmation so it's not just "pressed submit too early and forgot"
<pitti> Mithrandir: right, will do from now on
<Mithrandir> thanks
<Kano> Mithrandir: can you tell me how to build install/desktop iso snapshots?
<Mithrandir> Kano: use debian-cd
<Kano> is it for livecds too?
* Mithrandir chuckles over https://bugs.launchpad.net/ubuntu/+source/gnome-app-install/+bug/80589
<Ubugtu> Malone bug 80589 in gnome-app-install "daily live comes with crash report - pre-populated!" [High,Confirmed]  
<Kano> Mithrandir: are you sure it is for feisty? i only see etch entries..
<Kano> also itis from universe
<Kano> so what tool do you use
<Mithrandir> we use debian-cd.
<cjwatson> the debian-cd in the archive is Debian's, not ours
<Kano> and where is yours
<Kano> bzr something?
<cjwatson> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and references in configs/devel having checked that out
<cjwatson> it's a pain to set up, though. Don't waste your time on it unless you really really have to
<cjwatson> you need a full local mirror and all sorts of stuff
<Kano> why doent it work with a internet mirror?
<cjwatson> I'm not going to attempt to support it; folks using it need to be smart enough to support themselves :-)
<cjwatson> because it doesn't
<cjwatson> deal :)
<Kano> ok, need a new hd first then ;)
<Kano> cjwatson: and when i juse fuse to mount an ftp server to local dir?
<Kano> curlftpfs can do that
<Mithrandir> it'd be bloody slow and you need to hardlink stuff, so it still wouldn't work.
<cjwatson> debian-cd *can* use a symlink farm (see its README) but it's not well-tested because everyone using it for serious CD-building installations just has a big disk with a local mirror
<cjwatson> which is by far the most efficient option if you're doing it seriously
<Mithrandir> ogra: how are your images?
<cjwatson> heno: re braille-support, brltty's bluetooth driver doesn't seem to need a PIN
<Kano> cjwatson: will keep this in mind. how big is ubuntu main currently?
<cjwatson> or indeed know how to accept it
<cjwatson> ^[[Acjwatson@lithium:~$ du -s cdimage/ftp
<cjwatson> 90917604        cdimage/ftp
<cjwatson> so 90GB
<Kano> hmm but not only feisty i think
<cjwatson> sure, but cdimage doesn't bother selecting by release because that's more effort than just rsyncing the lot
<cjwatson> I have no idea how big feisty/main is and it isn't entirely trivial to find out
<Kano> rync all is a bit much...
<cjwatson> sum up the Size fields in all the relevant Packages and Sources files
<Mithrandir> use debmirror and then du it, but why care?  Disk space is cheap.
<TheMuso> cjwatson: Thats about right. The config file has nothing relating to bluetooth pins in it, only to do with the BlueTooth address.
<TheMuso> WOuldn't hurt to consult upstream about that, which I'll do now.
<Kano> Mithrandir: do you optimize the desktop isos for speed later?
<cjwatson> TheMuso: I'm just attempting the integration now
<Mithrandir> Kano: no, that's done earlier.
<Kano> so you get a sortlist before
<TheMuso> cjwatson: I have a serial display here, so I can't test bluetooth, but would be happy to test in general.
* Mithrandir throws a rock at ogra to make him wake up.
<heno> cjwatson: well, if it will work without a PIN that's better I guess
<cjwatson> TheMuso: plan is to blat brltty-udeb.sh and the udev rules into the regular brltty package as well, make braille-setup use /lib/brltty/brltty.sh so that it can kill any running brltty if need be, and hook it in from init scripts and the like to be used if you give brltty=ask on the kernel command line
<TheMuso> cjwatson: Sounds good.
<mvo> Mithrandir: a quick question on ia32-libs-gtk. I fixed a pango problem in it and refreshed them with "BUILD=0 ./fetch-and-build" along the way. is that sufficient? or is there more that needs to be doen before a upload?
<Mithrandir> mvo: you probably want to build the orig.tar.gz too
<cjwatson> heno,TheMuso: instead of a USB port, brltty seems to want the serial number of the display (or empty to autodetect)
<cjwatson> (just answering a comment in braille-setup
<cjwatson> )
<mvo> Mithrandir: _24_ seems to not have a orig.tar.gz. how do I build the orig.tar.gz for this package?
<Mithrandir> mvo: with tar and gzip
<cjwatson> I think it's then just /lib/brltty/brltty.sh -b auto -d "bluetooth:$b_address", /lib/brltty/brltty.sh -b "$s_model" -d "serial:ttyS$s_port", /lib/brltty/brltty.sh -b "$u_model" -d "usb:$u_serial" as appropriate
<heno> cjwatson: so for USB it shouldn't need any port info, but for a serial display conected to a USB-Serial dongle it would need the Serial port # 
<cjwatson> actually I think I'll add -E to that
<cjwatson> heno: brltty(1) doesn't document any way to do that though?
<cjwatson> heno: oh, are we talking about /dev/ttyUSB$n here?
<heno> cjwatson: if that is serial via USB, then yes
<cjwatson> aha, right
* heno brings up the spec
<cjwatson> I'll make it clearer in braille-setup, then, and say that other USB devices will be autodetected
<heno> right, thanks
<heno> cjwatson: Dave Mielke and I are actually working on a better version where we clarify some of these things
<cjwatson> heno: heh, I've already forked the script ;)
<heno> ok, go with that then :)
<cjwatson> perhaps I can upload what I've got and you guys can tweak
<heno> cjwatson: sounds great
<TheMuso> So this script will be run if the accessibility script in casper finds anything on the command line right?
<cjwatson> brltty=ask specifically
<TheMuso> yeah I know.
<cjwatson> I wasn't planning to do it via casper, actually
<TheMuso> ah ok
<cjwatson> reason is that it needs to interact with the user via read(1), and by the time casper runs usplash is up
<TheMuso> point
<cjwatson> so instead, I suggest doing it in the initramfs, right after console configuration
<Mithrandir> cjwatson: why does it need read(1) and can't use the usplash input infrastructure?
<cjwatson> well, casper's in the initramfs too, but earlier in the initramfs
<Mithrandir> hm, because the user can't see, maybe?
<cjwatson> I think in this case it's best for it to be as simple as possible
<bhale> can anyone tell me why the ubuntumembers team in launchpad has marked me as 'expired'? i am still somewhat active since the very begining
<TheMuso> Mithrandir: According to heno, this is for deaf blind people who may have assistance.
<TheMuso> ...I think
<cjwatson> if somebody wants to move it into usplash, fine, but we can do it before usplash starts
<cjwatson> bhale: all memberships are for a term of two years - the intent is to renew explicitly if the person's active
<bhale> cjwatson: i see, i understood them to lapse only in the event of inactivity. thanks
<cjwatson> bhale: unfortunately I'm not sure what the renewal process is because I've sort of been phasing out of the CC - I can renew it for a week to cover the next CC meeting though
<bhale> cjwatson: that would be cool, iirc mail is linked to that group
<cjwatson> I don't know if Mark wants to do explicit turn-up-to-meetings-type renewals or what
<bhale> alright, ill put myself on an agenda
<bhale> hm, the topic of expiring members in general is the topic of the next CC
<TheMuso> haha
<cjwatson> yes, preferably the CC should handle this when members are about to expire rather than waiting until they do
<cjwatson> heno: I'm renaming it to brltty-setup to make it clearer what package it belongs to
<Kano> would it be possible to get latest ati (8.33.6 currently), latest nvidia 9746 and 9631 and 7184 in the restriced package? btw. nvidia-legacy driver does not need any udev hack anymore
<Kano> 3 nvidia drivers would be best...
<Mithrandir> I doubt we'll do three drivers.
<bhale> it takes 3 drivers to support all hardware
<Kano> but they are needed if you want to support full range
<pitti> hi tkamppeter 
<Kano> i can easyly detect and switch between em,but currently i would have to package em manually or download the installers
<Kano> i have a working script but would like to seemlessly integrate
<Kano> pc linux os has 3 packages... nvida-71xx, -96xx , -97xx 
<Kano> just for example for a better naming scheme
<Kano> btw. do you patch the avm drivers to add support for the compatible hardware?
<Kano> one driver can be patched
<Kano> (just differnt usb id needed)
<tkamppeter> pitti, hi
<tkamppeter> pitti, did you upload the fixed m2300w yesterday? Or did you wait because of the Herd 3 freeze?
<Kano> http://kanotix.com/files/fix/fxusb_cz.patch
<Kano> basically you copy the fxusb source and apply that patch
<Kano> then you get a fxusb_cz too... that works
<pitti> tkamppeter: I uploaded it, but it's stuck in unapproved due to the freeze
<Kano> mv fxusb_cz/lib/fxusb-lib.o fxusb_cz/lib/fxusb_cz-lib.o
<Kano> dont forget to rename the precompiled part for that change...
<janimo> Mithrandir: hi, can you roll xubuntu images when you have soem time? thanks
<Mithrandir> janimo: "roll out" meaning publish or create or what?
<janimo> Mithrandir: roll, like whatever it takes to have iso-s on cdimage :)
<janimo> last ones are for Jan 30th
<Mithrandir> janimo: alternate images being created, livefs creating too running.
<janimo> thanks
<Kano> what the preferred way to disable that bootsplash thing after boot?
<Kano> i really dislikethat i see nothing when i stop kdm
<Seveas> Kano, #ubuntu for support
<bhale> Seveas: is the next CC scheduled? the wiki page says no
<Seveas> bhale, I just poked the CC about it for the third time
<bhale> ok.thanks
<Kano> Riddell: there is even twice NoDisplay=true in /usr/share/applications/ooo-math.desktop ...
<Riddell> doko: I presume NoDisplay in ooo-maths and ooo-draw are deliberate?
<Kano> Riddell: how about: Categories=Application;Office;VectorGraphics
<doko> Riddell: was decided when we cleaned up the menu structure for dapper
<Kano> stupid decision...
<cjwatson> TheMuso: hmm, brltty doesn't *strictly* need to be started in the initramfs, does it? only configure
<cjwatson> d
<Riddell> makes sense, I don't see much need to run ooo maths as a separate application
<TheMuso> cjwatson: No. It has an init script.
<Kano> math ok, but graphics
<Riddell> although it's a bug not to include a ; at the end of the Categories list
<carlos> pitti: btw, I just disabled language pack exports to do another Feisty opening test
<cjwatson> TheMuso: starting persistent processes in the initramfs is a pain, so if possible I'd like to just configure it and then have the init script start it up
<cjwatson> ok, great
<carlos> pitti: so we will not get daily updates this weekend
<pitti> carlos: ok for me; I'm just uploading new dapper packs, btw
<pitti> carlos: that's fine, cronjobs are off anyway
<carlos> base ones?
<heno> cjwatson: right, Dave wanted to just add some entries at the bottom of /etc/brltty.conf
<carlos> ok
<TheMuso> cjwatson: Howd you plan to do that?
<pitti> carlos: right, the ones from Monday
<carlos> ok
<TheMuso> As in, let the init script know what we want
<cjwatson> TheMuso: write out /etc/brltty.conf
<heno> cjwatson: and then have ubiquity copy the modified script over
<TheMuso> RIghto.
<carlos> did you get a confirmation from people complaining about missing translations, that those packages fixes their issue?
<cjwatson> it'll take two initramfs hooks because usplash starts before the root filesystem is mounted, but whatever
<TheMuso> WHich means we can get the casper ubiquity stuff to copy it over at install time.
<cjwatson> 'zactly
<heno> \o/
<doko> Kano: ranting doesn't help; if you want to change it, write a new menu spec for feisty+1
<cjwatson> or even just have brltty install a ubiquity hook, maybe
<TheMuso> Sounds good.
<cjwatson> I'm all for splitting this stuff out into separate packages to make it easier to mix and match
<Mithrandir> http://err.no/herd-3.txt proofreading needed.
<cjwatson> The requested URL /herd-3.txt was not found on this server.
<Mithrandir> http://err.no/tmp/herd-3.txt
<cjwatson> hah, I guessed right
<tkamppeter> pitti, thanks for the info, thought already about a thing like this
<TheMuso> heno: DO you think this is a good time to discuss transitioning to espeak and getting things set for using espeak's different voices for languages?
<cjwatson> Mithrandir: please add the hw-detect/start_pcmcia=false workaround for the install CD han
<cjwatson> g
<cjwatson> Mithrandir: also please mention that if the new partitioner doesn't work then you can fall back to the old one by running 'ubiquity --old-partitioner' from a terminal
<heno> TheMuso: we should look at the patches Gilles made. Those should take care of it
<Mithrandir> cjwatson: looks good?
<TheMuso> heno: What patches?
<heno> Have all his patches to gnome-speech and the newest espeak made it into the repos?
<TheMuso> hang on, going to -accessibility
<janimo> Mithrandir: is it worth mentioning that gnome-power-manager does not start by default in herd3?
<Mithrandir> janimo: it does not?
<janimo> Mithrandir: it got ist autostart file dropped in a recent upload
<janimo> by accident
<Mithrandir> ok
<Mithrandir> what's the easiest way to start it by hand?
<janimo> gnome-power-manager from the console I guess
<Mithrandir> janimo: looks good now?
<janimo> Mithrandir: yes
<janimo> it'd be good if someone else who tested recent livecds confirmed this though
<janimo> Scott noticed it yesterday
<ogra> Mithrandir, sorry, sorry, sorry .... edubuntu is ready indeed
<cjwatson> Mithrandir: no, not gksudo
<pitti> janimo: confirmed; is there a bug about it already?
<cjwatson> Mithrandir: just 'ubiquity --old-partitioner'. It raises privileges in the appropriate way itself
<Mithrandir> cjwatson: oh, ok
<DHGE> hi! anyone to confirm that the texlive/tetex dependencies are fixed like in debian? i am having problems apt-getting packages with texlive installed
<Mithrandir> cjwatson: ok now?
<cjwatson> Mithrandir: "The primary focus ... have been" -> has been
<janimo> pitti yes there;s ab ug, ogra knows about it
<cjwatson> Mithrandir: rest looks fine
<Mithrandir> cjwatson: I think I can blame Hobbsee for that, she proofread it last time.
<Mithrandir> cjwatson: thanks a lot.
<Mithrandir> janimo: alternate xubuntu ready.
<pitti> Mithrandir: ah, heh, I found the reason for the sim FTBFS; debian/rules defines a variable that pkg-create-dbgsym expects to be empty initially
* pitti blushes
<Mithrandir> pitti: *cough*. :-P
<pitti> Mithrandir: will fix p-c-d and ask for a give-back after it reaches the archives next wek
<pitti> week
<ogra> janimo, the gpm doesnt start bug ? 
<janimo> ogra: yes
<janimo> Mithrandir: thanks
<ogra> a fixed package is sitting on my disk ... waiting for the archive lock to go away
<DHGE> in feisty: tex4ht (20060913-1) depends: tetex-bin OR texlive-base-bin     :-)
<Mithrandir> janimo: -live ones ready too.
<DHGE> the html in http://cdimage.ubuntu.com/releases/feisty/herd-3/ is broken
<Mithrandir> DHGE: how so?
<Mithrandir> ah, fixed.
<DHGE> look and see
<Mithrandir> it'll be visible on the next mirror run
<heno> Mithrandir: I've used the Status field to indicate how an image is doing. 'In Progress' means several successful installs reported, 'Need Info' means just one test (and we would ideally like more) Unconfirmed is no testing reported or heno doesn't know if the reports are good enough (or if the bugs reported are RC)
<Mithrandir> heno: ok, sounds useful.
<Mithrandir> heno: I'll mark a couple of them as fix released, though
<pitti> ooh, the new ubiquity partitioner! if it only would allow me to create a /home partition
<heno> Mithrandir: cool
<cjwatson> pitti: hmm?
<pitti> cjwatson: I attempted it three times, each time making the partition slightly smaller, it just ignores it
<cjwatson> pitti: trying it under ubiquity --debug would be good
<pitti> cjwatson: will do, and file a bug
<cjwatson> thanks, this is exactly the sort of thing I want to hear about
* cjwatson -> lunch
<pitti> cjwatson: I guess you aren't yet interested in quarrells about the UI?
<cjwatson> pitti: well, not of the form "it's ugly and hard to use", but things like "that text field should really be a spinbutton", sure
<TheMuso> Is it the LANG or LANGUAGE environment variable that should be checked for determining the language used on the system?
<_ion> Among others.
<janimo> Mithrandir: thanks for the isos
<Mithrandir> oh, np
<pitti> TheMuso: LANG is the default value for unset LC_* (except LC_ALL); I didn't yet figure out what LANGUAGE is good for
<TheMuso> pitti: Thanks, I thought LANG was it, but when I saw LANGUAGE referred to in some source code, I wasn't entirely sure.
<Treenaks> pitti: Gnome has some stuff about LANGUAGE
<pitti> TheMuso: one difference is that LANG specifies one locale, and LANGUAGE is a list of fallback (like de:en)
<pitti> google might help here
<TheMuso> ok
<Treenaks> pitti: it's a gnu extension
<janimo> it is used by gettext in preference of LC_ALL and LANG
<pitti> janimo: ugh, it dominates $LC_ALL?
<janimo> pitti according to info gettext it does
<_ion> For example, my settings are: LANG=fi_FI.UTF-8, LC_MESSAGES=en_US.UTF-8, LC_NUMERIC=en_US.UTF-8, LANGUAGE=en_US:en, i.e. programs should use the Finnish locale settings for things such as day and month names, paper size etc. but speak English. They should also print numbers with a decimal dot instead of the stupid Finnish comma.
<janimo> export LANGUAGE only and start mc
<pitti> $ LANGUAGE=en locale still gives me all German locales
<janimo> weird
<siretart> pitti: I'm just curious but has the MainInclusionQueue stalled? there doesn't seem to be much activity there lately.
<pitti> siretart: I approved a whole lot yesterday, and iwj approved something today
<givr1> ogra: do you have some time to have a look at the fuse merge ? -> http://paste.ubuntu-nl.org/3808/ ;) . Thanks 
<cjwatson> LANGUAGE is only used to override LC_MESSAGES
<cjwatson> see locale(7)
<siretart> pitti: aah, okay, then just false impression on my side :)
<pitti> siretart: but if you have something urgent in the queue, please IRC-poke me
<cjwatson> it does dominate LC_ALL, but only if you're querying the LC_MESSAGES category
<siretart> pitti: it's not that important, I'm rather curious if cryptsetup and ffmpeg are going to make it into ubuntu 7.04/main
<pitti> siretart: I don't really dare to judge about ffmpeg, I'd appreciate a verdict from TB or so
<TheMuso> heh I didn't expect this to turn into such a big discussion. Thanks folks, I'll see whether its worth changing the code to refer to LANG rather than LANGUAGE.
<siretart> pitti: err, the TB told me to file a MIR and look if it was fine. So I cannot go to the TB before not having a successful MIR for ffmpeg
<siretart> pitti: looks like there is a deadlock
<ogra> givr1, the udev stuff looks nice now ... how about switching from modifying /etc/modules to installing a file into /etc/modprobe.d/fuse instead :)
<pitti> siretart: ah, ok
<pitti> siretart: so I'll ignore the patent stuff and just look at it from the technical side
<siretart> pitti: that would be great! thanks
<cjwatson> TheMuso: it's usually best to use setlocale() rather than checking environment variables directly
<TheMuso> cjwatson: Ok thanks.
<cjwatson> though there are special cases that that doesn't cover
<siretart> pitti: regarding the patent stuff, I don't really see the legal difference between shipping ffmpeg in main, universe or multiverse. they are just other directories in the archive after all. However, I see that shipping it on pressed CDs makes a BIG difference. I still think that we are better off having it in main (if it fulfills the technical requirements, of course)
<pitti> siretart: what was the primary reason for having it in main again? getting rid of the xine-lib package split?
<cjwatson> TheMuso: do we want this to be usable on an installed system too?
<siretart> pitti: reducing code duplication, and stop using the internal ffmpeg copy in the xine-lib sources
<TheMuso> cjwatson: The scrip? I think there is debconf foo to handl configuration on a running system.
<cjwatson> TheMuso: hmm, on reflection, ignore that, I think it might be a bad idea because it would override an existing /etc/brltty.conf
<TheMuso> Well debconf writes out a config fie anyway.
<siretart> pitti: so in the end, ffmpeg is already in main somehow, with the consent of the TB
* TheMuso checks
<cjwatson> debconf isn't used any more
<TheMuso> ah ok
<cjwatson> it's just a conffile now
<TheMuso> I just remember seeing something to do with BrlTTY and debconf on the debian accessibility list.
<cjwatson> which of course means that it's tricky for the installer to edit it ...
<TheMuso> Yeah
<Kagou> tkamppeter: can you have a look at on Bug #82187 ?
<Ubugtu> Malone bug 82187 in cupsys "[feisty]  USB printers not detected - user "lp" not in group "plugdev"" [Medium,Confirmed]  https://launchpad.net/bugs/82187
<ogra> givr1, the udev stuff looks nice now ... how about switching from modifying /etc/modules to installing a file into /etc/modprobe.d/fuse instead :)
<ogra> givre, ^^
<ogra> Mithrandir, how about releasing the lock ? 
<givre> ogra: didn't really know how to do so
<tepsipakki> mdz: re: your post about util-linux. I remember it being forked, since Adrian Bunk doesn't cooperate with anyone :I
<pitti> cjwatson: ah, it wasn't so bad after all, just a miscalculated/misdisplayed free space; I filed a bug with the logs
<tepsipakki> mdz: http://uwsg.iu.edu/hypermail/linux/kernel/0612.2/0348.html
<tkamppeter> kangu, this is due to the introduction of a new method to create device files when hot-plugging the device. The /dev/usblpX files are created with ownerships root.plugdev.
<tkamppeter> So we must add the user as which CUPS is running (cupsys, lp? pitti?) to the group plugdev, probably in the post-install script of the cupsys package.
<pitti> tkamppeter: hm, the /dev/usblpXX are supposed to have group 'lp', that looks like an udev bug
<pitti> tkamppeter: but we can put cupsys into plugdev, no big deal
<Kagou> pitti: tkamppeter  ok so later i will test thi sworkaround to confirm
<cjwatson> pitti: thanks, I'll try to trudge through the debug log :)
<pitti> Kagou, tkamppeter: ah, I see
<pitti> ./20-names.rules.dpkg-old:BUS=="usb", KERNEL=="lp[0-9] *",               NAME="usb%k"
<pitti> tkamppeter: hm, 40-permissions.rules first assigns plugdev to SUBSYSTEMS=="usb", and later SUBSYSTEM=="usb", KERNEL=="lp[0-9] *",   GROUP="lp"
<pitti> tkamppeter: not sure why that fails
<pitti> oh, and the first rule doesn't even match, it's only for block devices
<Kagou> pitti: it's a typo ? : SUBSYSTEMS=="usb"   <->  SUBSYSTEM=="usb"
<Kagou> with or without "S3
<Kagou> with or without "S"
<givre> ogra: you're back :)
<givre> ogra: i understand that /etc/modprobe.d can be use to configure module, but i don't see how you can load stuff from here
<ogra> yeah, flaky DSL heer today
<ogra> givre, yeah, that was a bad idea .. lets keep the /etc/modules variant
<pitti> Kagou: no, that's correct AFAIK; -S traverses parents, too
<Kagou> oh, thanks pitti 
<givre> ogra: ok, great. So what the next step. I fill a bug and subscribe ubuntu-main-sponsors to it, or you take care of everything...
<ogra> what exactly is the problem with unmounting the fusectl fs ? 
<ogra> i will take care of everything ...
<givre> no problem
<ogra> why dont you just add
<ogra> ACTION=="remove", KERNEL=="fuse", \
<ogra> GROUP="fuse", RUN+="umount_fusectl"
<tkamppeter> pitti, so it is a bug in udev?
<givre> ok sorry, i though you saw my first message :
<givre> givre: ogra: i use the udev rules to mount the fuse control filesystem, but i don't unmount it with the rule, because 1. it's impossible (AFAIK). 2. It's done anyway by /etc/init.d/umountfs
<pitti> tkamppeter: yes, somewhere in the rules
<ogra> why should that be impossible ? 
<Keybuk> ogra: GROUP= is kinda irrelevant in a remove rule
* pitti -> offline for a bit to test-reinstall his desktop 
<ogra> i dont like the idea of having a mounted contol filesystem until we reboot
<givre> because fusectl need the fuse module
<ogra> Keybuk, ah, right
<ogra> we still should run umount fusectl to properly clean up 
<givre> so we can't unload fuse if fusctl is still mounted
<givre>  2. It's done anyway by /etc/init.d/umountfs
<ogra> right, but you have it hanging around until you shut down ...
<givre> ogra: no it's unmounted with all local filsystem
<ogra> on shutdown
<givre> right
<givre> i checked that yesterday
<ogra> oh wait, you cant unload at all ...
<ogra> hmm
<givre> ogra: no
<givre> until fusctl is not unmount, you can't
<ogra> right
<fabbione> Mithrandir: could you be so kind to add herd-4 milestone to LP so i can actually target bugs? thanks
<Mithrandir> fabbione: herd-3 isn't officially released yet, I'll get to it on my checklist.
<fabbione> Mithrandir: cool thanks
<^robertj> howdy all. Over the weekend I decided to mv xorg.conf and was surprised by how well everything worked without it. Only question is, how does it choose the default resolution. I've got a 1650x01050 display but it pulled out a 1400xsomething resolution. I noticed that this was also the same resolution suggested by Windows before I installed the NVidia driver, so that made me curious.
<Mithrandir> ^robertj: it asks you display
<Mithrandir> your, even
<^robertj> Mithrandir: via DDC?
<Mithrandir> ^robertj: yes.
<^robertj> why would it report back the "wrong" resolution?
<Mithrandir> maybe your monitor lies or is confused, or maybe the driver doesn't know what resolution your card supports.
<^robertj> Mithrandir: I think the first would be more likely, as 1400xsomethign seems like a bad "safe" resolution when in doubt
<Ng> ^robertj: the X server log will most likely list in extraordinary detail which modes it got from the monitor and why it rejected any of them
<^robertj> I'll look into that tonight, worked fine with my old conf, which came from, err, I don't remember.
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Herd 3 released.
<Treenaks> \o/
<Kagou> ^robertj: may be you have Bug #76054 ?!
<Ubugtu> Malone bug 76054 in xorg "Installer fails to detect monitor correctly" [Medium,Confirmed]  https://launchpad.net/bugs/76054
<^robertj> but err, kudos to yall and the upstream for the fact that something showed up at all without the config file :)
<^robertj> Kagou: doesn't seem to fit, but thanks.
<Kano> Mithrandir: is there a logic  in the MD5SUM file? why is -b option not used for md5sum, so i always get a warning with cfv
<Kano> warning: file(s) tested in textmode
<Mithrandir> Kano: huh?
<Kano> -b adds a * in front of the name, no space
<Kano> sed -ri 's/  / */' MD5SUMS
<Kano> then the wanning is away
<Kano> btw
<Mithrandir> why would we?
<Kano> -b option add that 
<Kano> -b is for binary md5sum as flag
<Kano>        -b, --binary
<Kano>               read in binary mode
<Mithrandir> that's not relevant on unix.
<Kano> i know,but tools like cfv find it as warning
<Mithrandir> then don't use those tools.
<Mithrandir> use md5sum to check.
<Kano> i like cfv
<Mithrandir> *shrug*
<ogra> givre, /etc/modprobe.d/fuse http://paste.ubuntu-nl.org/3821/
<givre> ogra: wha great idea :)
<ogra> drop udev and lets just take that fine 
<ogra> *file
<ogra> saves the whole initscript stuff and is dynamic
<crimsun> ogra: hi, do you plan to package libflashsupport from revolutionlinux's svn?
<ogra> crimsun, it was in NEW already ...
<ogra> but there were license issues iird
<ogra> *iirc
* ogra digs for the rejected mail
<crimsun> ogra: ok, thanks
<ogra> I've rejected your libflashsupport upload.  It build-depends on
<ogra> libssl-dev and libpulse-dev (which while being LGPL uses GPL-ed libs,
<ogra> so effectively is GPL).  The OpenSSL licence and the GPL are
<ogra> incompatible.  Please resolve this and upload again.
* lamont looks around for Keybuk mdz or mjg59
* pitti sees that herd-3 was released while he was offline due to testing; congrats, Mithrandir!
<Keybuk> lamont: ?
<Mithrandir> pitti: congrats to you too. :-)
<mjg59> Laser_away: Mm?
<mjg59> Erm.
<mjg59> lamont: ?
<cjwatson> Kano: I hadn't been aware that that option was interesting. I've made it use md5sum -b now, thanks; though if it causes problems for mirrors etc. I may well back that change out again.
* lamont received warning email telling him his ubuntu-core-dev membership is due to expier
<lamont> expire, even
<elkbuntu> ogra, if you have a moment, please see pm
<Mithrandir> doko: is https://launchpad.net/ubuntu/+source/python-central/+bug/56779 still a problem?
<Ubugtu> Malone bug 56779 in python-central "Error during Dapper-->Edgy update, problem removing python2.3" [High,In progress]  
<pitti> Mithrandir: that means I can do unlimited archive crack again, right? publisher is back to auto?
<Mithrandir> pitti: yes and no, not yet.  (I'll do it soonish, but something has locked the distrorelease table so we can't flip feisty back to development)
<pitti> ok, thanks
<Mithrandir> but just go ahead with your shiny.
<heno> Mithrandir: Shall I fix release all the tracker bugs or will you run your script?
<Mithrandir> heno: I can do it.
<heno> Mithrandir: new tracker bugs for the actual Herd 3 images would be sweet too
<Mithrandir> heno: I need a list of test cases, then.
<heno> Oh, so not just one per image as we have done?
<heno> You're right, I guess that's what we agreed
<Mithrandir> iirc, it was one per test, but if you just want what we have, that's easy.
<heno> Mithrandir: No, I'll email you a list. It will stay up for 2-3 weeks so we might as well try to encourage more varied testing
<Mithrandir> heno: ok
<mdz> lamont: people get mail about upcoming expiry now? neat
<lamont> mdz: yeah.  and if it actually expires, then the first mail promises them another mail telling them that it happened.
<bddebian> Heya
<ogra> crimsun, hmm, looking at alsa-plugins, it seems we never installed the jack plugin (the corresponding lines in rules are commented) ...
<crimsun> ogra: -rw-r--r-- 1 root root 9952 2006-11-22 20:05 /usr/lib/alsa-lib/libasound_module_pcm_jack.so
<ogra>         dh_install
<ogra>         #install $(INSTALL_UAG) jack/.libs/libasound_module_pcm_jack.so \
<ogra>         #       debian/libasound2-plugins/usr/lib/alsa-lib/libasound_module_pcm_jack.so.2.0.0
<ogra>         #ln -s libasound_module_pcm_jack.so.2.0.0 \
<ogra>         #       debian/libasound2-plugins/usr/lib/alsa-lib/libasound_module_pcm_jack.so
<ogra>         dh_installdocs
<ogra> ...
<ogra> weird
<crimsun> ogra: that's old; it no longer uses libasound_module_pcm_jack.so.2.0.0.
<crimsun> hence the commenting in debian/rules
<ogra> ah
<ogra> k
<ogra> anyway, jack is disabled now in alsa-plugins
<crimsun> rockin'
<ogra> now the MIR and ltsp sound is done ... even though for feisty+1 i need to find a way for dynamically switching input sources on the client
<crimsun> pavucontrol doesn't cut it?
<dholbach> yooohoooo, herd3!!!
<ogra_> grmbl
<ogra_> crimsun, i need something that reacts on pluggin in a usb headset and switches the source underneath the pulse server ... i cant interact with the client so it must happen automatically
<ogra_> for hal and dbus there is no space on a thin client 
<crimsun> hmm.
<crimsun> I know someone hacked up a udev rule to do that via a shell script, but it's ... ugly.
<ogra_> yeah
<ogra_> but likely the only way
<ogra_> it still needs to work on 32MB clients with network swap 
<ogra_> so scripts or C  ... or very tiny python scripts ...
<Mithrandir> mjg59: hmm, I think liferea might have become slower, yes.  It's sometimes just hanging or lagging.
<givre> ogra_: finaly : http://paste.ubuntu-nl.org/3830/
<givre> ogra_: works great. Thanks :)
<ogra_> looks nice as well :)
<ogra_> can you put the full package anywhere so i can grab it for upload ? 
<ogra_> givr1, can you put it somewhere so i can grab and upload it ? 
<givr1> ogra_: (in case you didn't get it, i have been disconnected) : http://flomertens.keo.in/merge/
<givr1> sorry ;)
<ogra_> thanks a lot !!!
<ogra_> :))
<Keybuk> pitti: errrr.... where are my core dumps?
<givr1> ogra_: ok, i have to go to work. Thanks !
<pitti> Keybuk: look under the sofa?
<pitti> Keybuk: -v ?
<Keybuk> pitti: debugging a program, it core dumps -- yet there's no core dump in the working directory
<pitti> Keybuk: '/etc/init.d/apport stop' then
<Keybuk> pitti: I did that, and that's what brought my core dumps back
<pitti> Keybuk: core_pattern is a pipe to apport if apport is running
<Keybuk> which is why I'm blaming you
<Keybuk> it shouldn't prevent ordinary core dump generation
<pitti> that's Linux upstream's prefered way of doing this...
<Keybuk> especially not in people's home directories
<Keybuk> otherwise it makes ubuntu pretty useless as a development platform
<Keybuk> is there nothing apport can do to signal to the kernel to dump core as it used to?
<pitti> Keybuk: apport could write the core dump on its own if we wanted, but core_pattern basically defines the name
<pitti> we might need to rethink the current kernel patch then
<Keybuk> yes ...
<Keybuk> right now I'd rather we shipped with this disabled than in its current form
<Keybuk> it's going to confuse and annoy a *lot* of developers
<Robot101> Keybuk: what happens when your random app crashes and apport catches it too?
<pitti> Robot101: not much, non-packaged apps are ignored by apport
<Robot101> ok, so could it write the core dump as usual in those cases?
<pitti> Robot101: that would certainly be doable if we want that
<Keybuk> right, there should be some way to do that
<Keybuk> e.g. if the pipe command exits non-zero, the kernel should do the default behaviour
<Robot101> (ulimit permitting, I guess)
<pitti> the kernel would need to pass the process' ulimit -c to apport, but that's no problem
<Keybuk> that'd work too
<pitti> Keybuk: doesn't work in that generality, because usually core_pattern specifies the filename
<pitti> we can default to core.<pid>, though
<Keybuk> "core" is the default in Linux, no?
<pitti> right, core_uses_pid is off by default
<Robot101> what about adding core_pipe or something?
<pitti> Robot101: at some point you need to decide whether to pipe or to write a file
<pitti> Robot101: I think the general idea of core_pattern is sane
<pitti> and normal users don't want their fs cluttered with core dumps
<Keybuk> I agree you don't want core dumps for packaged apps
<pitti> I like the 'write core file for unpackaged programs if ulimit -c permits' approach best so far
<maswan> BenC: btw, I just checked feisty, and kernel-wise systemtap works great. just needs a newer systemtap than packaged. :)
<elmo> maswan: really?  sweet
<crimsun> maswan: will 0.0.20070113-1 (in sid) suffice?
<crimsun> n/m, just read 82817
<maswan> crimsun: yeah
<maswan> elmo: yup, I just had to rebuild the systemtap stuff from sid, rename the vmlinux from linux-image-debug (I guess systemtap could be taught to search for it in the right place too though)
<maswan> then at least the examples run fine. :)
<maswan> but the important thing is that I don't have to build a custom kernel for it
<glatzor> Riddell: hi, you haven't added a script to call software-properties-qt from the command line. 
<glatzor> Riddell: By the way thanks for fixing my awkward English grammar :)
<glatzor> Riddell: don't you need one? or should I add one?
<Riddell> glatzor: hang on
<Riddell> glatzor: added, along with the start of the mirror dialgue
<Riddell> glatzor: might take a while to get to the launchpad http archive, I'm not sure
<dholbach> TheMuso: new lsr release for you :-)
<pitti> hmm, publisher still seems to be inactive
* cypher1 is away: I'm busy
* cypher1 is back (gone 00:00:02)
<pitti> there, sync queue down from 75 to 3 bugs
<bddebian> w00t, thx pitti
<Mithrandir> cypher1|away: please turn off public away.
<pitti> Mithrandir, cjwatson: would you object if I unsubscribed ubuntu-archive from all SRU bugs, so that ~ubuntu-archive/+subscribedbugs actually becomes readable again?
<Mithrandir> pitti: I find ~u-a/+ss quite ok already but yeah, I guess we can track them as soon as they show up in the queue
<pitti> Mithrandir: it's just that most of ubuntu-sru/+subscribedbugs are bugs we cannot process right now (I processed all that can be)
<pitti> OTOH, ubuntu-archive bugs can (in general) be processed any time
<Mithrandir> pitti: 'k
<bddebian> *cough* NEW *cough* :-)
<Mithrandir> bddebian: NEW doesn't show up in bug listings.
<fabbione> seb128: bug #82871 is all your
<Ubugtu> Malone bug 82871 in gnome-app-install "Bomb appears after rebooting from Feisty herd 3 alternate" [High,Confirmed]  https://launchpad.net/bugs/82871
* bddebian submits a bug report ;-P
<pitti> Mithrandir: ok, let's see what cjwatson's opinion is
<bddebian> Mithrandir: I'm just being a smart alec, ignore me.  You guys do great stuff! :)
<seb128> fabbione: why?
<Mithrandir> bddebian: so we have less time to process new and fix bug.  Useful.
<seb128> fabbione: mvo is upstream for that software, don't you think he would be a better idea to have him look at the problem?
<fabbione> seb128: oh is he? cool
<fabbione> seb128: i though it was some random gnome crap :P
<seb128> gnome-app-install ... that's the add/remove program he wrote for Ubuntu
<seb128> and that bug report is useless
<seb128> attaching the crash file would be useful
<fabbione> seb128: yeah i didn't know about mvo being upstream... and yes i already told Marc about needinfo :)
<seb128> the bomb indicates there is a crash file to /var/crash
<seb128> ok
<pitti> seb128: the crash file is attached (several times)
<pitti> there was a nice python backtrace
<seb128> pitti: https://launchpad.net/ubuntu/+source/gnome-app-install/+bug/82871 ?
<Ubugtu> Malone bug 82871 in gnome-app-install "Bomb appears after rebooting from Feisty herd 3 alternate" [High,Confirmed]  
<heno> sfllaw: can you look at this page and fill in some blanks: https://wiki.ubuntu.com/Testing/InstallMethods ?
<fabbione> sfllaw: can you please give me time to process bugs before you close reject them? there is no need to file another one
<seb128> pitti: my browser doesn't list any attachment, weird
<heno> and possibly expand some of them too
<fabbione> pitti: mine neither...
<pitti> seb128: hm, doesn't sound like the but I meant, it seems that one is a dup
<fabbione> seb128: it's pitti's suppah powah
<seb128> pitti: likely, there is not enough information to say though ;)
<pitti> seb128: yup, bug 80589
<Ubugtu> Malone bug 80589 in gnome-app-install "daily live comes with crash report - pre-populated!" [High,Fix committed]  https://launchpad.net/bugs/80589
<pitti> that's the good one
<seb128> ok
<seb128> thank you for the pointer ;)
<pitti> de rien
<pitti> seb128: that's the bug that is mentioned a hundred times in the iso testing bugs, btw
<seb128> ok
<fabbione> pitti: our is from alternate install.. i assume that's the same in this case
<pitti> fabbione: yup
<cjwatson> pitti: ok, but if you do, change StableReleaseUpdates to match
<pitti> cjwatson: of course; I'm just interested in the opinions so far
<pitti> and what the other admins would prefer
<fabbione> dholbach: do you feel comfy to fix bug #82874 ? it's usually a one line change in the pci.id file.. should be very easy
<Ubugtu> Malone bug 82874 in discover-data "Graphic controller not detected properly on Dimension 9150 for Feisty herd 3" [High,Unconfirmed]  https://launchpad.net/bugs/82874
<cjwatson> pitti: if those people who are actually processing SRUs are monitoring ~ubuntu-sru/+subscribedbugs, then it's OK
<dholbach> fabbione: why don't you do it? you know more about that than I do...
<pitti> cjwatson: that would be Mithrandir and me, according to new standards; and yes, due to team membership I'm monitoring
<poningru> heno: ping
<heno> poningru: hi
<poningru> heno: quick question were you the one that moved the herd3 to ubuntu.com?
<poningru> can i ask for a small favor?
<heno> poningru: yes, and probably yes
<pitti> yay, my first source NEW
<poningru> can you upload the latest version of herd3 from the wiki?
<poningru> https://wiki.ubuntu.com/FeistyFawn/Herd3?action=recall&rev=31
<poningru> some guy had removed the ekiga
<heno> poningru: ok, are you maintaining these pages these days?
<poningru> heno: err sure kinda
<poningru> heno: actually thats another thing is there anyway for us to lock these pages down?
<poningru> or something
<heno> I ask because we need to speak with the webmaster about a more robust process for this move
<poningru> oh yes please
<heno> sec
<poningru> heno: convo >> #ubuntu-marketing ?
<poningru> heno: actually there were a few edits that I would like to get in there before you actually move it is that ok?
<heno> poningru: can you join #ubuntu-matt
<heno> ?
<sfllaw> seb128: Bug 60277 is ready for edgy-updates
<Ubugtu> Malone bug 60277 in nautilus "Windows Network entries use a text icon instead of a computer one" [Unknown,Fix released]  https://launchpad.net/bugs/60277
<seb128> sfllaw: thank you
<^robertj> where should email regarding minor layout issues with ubuntu.com go?
<Seveas> ^robertj, you can file them as bug on http://bugs.launchpad.net/ubuntu-website
<^robertj> ah silly me
<cjwatson> (or ubuntu-cdimage if it's cdimage.u.c or releases.u.c)
<seb128> sfllaw: could you look at bug #76301 as well? That would be easier to accept both proposed updates together
<Ubugtu> Malone bug 76301 in gnome-vfs2 "patch from CVS to fix crash triggered when closing ekiga by example" [Medium,Fix committed]  https://launchpad.net/bugs/76301
<derjoerg> hi everybody
<alex-weej> is the ubuntu web open source?
<pitti> Mithrandir: do we generally require that debian/copyright has the short standard GPL blurb? bzr-pqm in NEW only has a pointer to /usr/share/common-licenses, and that looks suspicious to me
<Mithrandir> pitti: no.
<Burgwork> alex-weej: in what sense?
<alex-weej> can i make it look better?
<Burgwork> you are talking about ubuntu.com?
<alex-weej> and submit a patch
<alex-weej> aha
<Burgwork> right, currently ubuntu.com runs on a modified moin engine
<derjoerg> does anybody now how to build vanilla kernel 2.6.19.2 with the ubuntu specific patches?
<Burgwork> it is being moved to a joomla-based system
<Burgwork> however, there is no timeframe on that
<twb> Mithrandir: hey, does feisty's casper do netbooting yet?
<pitti> bddebian: here?
<bddebian> Yessir, what'd I break now?
<pitti> bddebian: nothing yet :)
<pitti> bddebian: just reviewing libticables
<bddebian> Ah, OK
<pitti> bddebian: that has an internal copy of gettext
<pitti> bddebian: does the package actually configure to use glibc's one?
<pitti> (I guess the internal copy is for the windows build)
<bddebian> Aye
<pitti> bddebian: ok, then I already ran out of excuses to reject it :)
<bddebian> Heh
* bddebian feels the love
<bddebian> Kickin'.  Libticonv and I can start on tilp2 :-(  Thx pitti
<pitti> argh, when doing 'view file | view -' it's time for weekend...
<ogra_> doubleview :)
<pitti> argh, ubuntu-desktop now depends on network-manager-gnome
<ogra_> wasnt that intended ? 
<Mithrandir> pitti: yes, that's intentional
<ogra_> just switch to edubuntu :)
<seb128> pitti: why "argh"?
<keescook> mornin' folks
<dholbach> heya keescook
<pitti> well, it's fairly useless for desktops
<pitti> mvo: hmm, if I purge network-manager from my system, shouldn't that auto-remove dhcdbd and friends (libs?) as well?
<keescook> hiya dholbach
<keescook> today bdmurray has joined me at the "east side" portland office.  :)
<dholbach> yooohooo :)
<dholbach> go Ubuntu Portland Office :-)
<pitti> hey keescook 
<keescook> hiya pitti :)
<mvo> pitti: yes, let me check
<bddebian> Hey, I think you need a Philly office! :)
<pitti> mvo: still here?
<pitti> mvo: I rejected synaptic/a-i-d-commercial, see bug 81428
<Ubugtu> Malone bug 81428 in app-install-data-commercial "sugarcrm needs update of app-install-data-commercial and a synaptic fix" [High,Fix committed]  https://launchpad.net/bugs/81428
<glatzor> Riddell: do you plan to make the kde port depend on KDE?
<glatzor> Riddell: or will it be qt only in the future? 
<mvo> pitti: ok, I check
<mvo> pitti: argh, right
<Lure> pitti: thanks for sru accept
<pitti> mvo: and please don't forget correct -v (I didn't check the .changes)
<mvo> pitti: I had it in the initial upload, I almost forgot it now :)
<bddebian> doko: Do you know much about kimwitu++ or did you just upload it last to fix it?
<doko> bddebian: the latter
<bddebian> Damn, OK, thx
<pitti> mvo: oh, synaptic is a Debian native package?
<mvo> pitti: yes
<pitti> mvo: synaptic accepted, waiting for a-i-d
<mvo> pitti: rock! thanks
<GateWar> http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html#introduction
<pitti> mvo: hm, I need to leave nowish; maybe you can ask Mithrandir or cjwatson to accept the a-i-d upload?
<Riddell> glatzor: no immediate plans for that
<dholbach> ogra_: new genius release
<mvo> pitti: the upload should already be available :/ but no problem, I will ask them for it!
<ogra_> genuius ? 
<Riddell> glatzor: feel free to rename the file if you want, but my rationale is that margionally more people will recognise KDE than qt
* ogra_ digs his brain ...
<mvo> pitti: thanks a lot for the work!
<glatzor> Riddell: I was just wondering why it was named qt
* ogra_ stumbles over jdub ...
<ogra_> dholbach, aaah, genius
<dholbach> :)
<glatzor> Riddell: I hope that most people using KDE don't have to install it manually :)
<mvo> # ldconfig
<mvo> Segmentation fault
<mvo>  ^--- that sounds serious :)
<pitti> mvo: checkign queue again...
<pitti> mvo: nope, nothing there
<Riddell> glatzor: how come DialogMirror is copyright FSF-E?
<mvo> pitti: oh, it took a bit until I got the mail. but no worries, I will pester cjwatson or Mithrandir about the app-install-data-commercial upload
<pitti> mvo: ok, we just decided for watching a movie, so I'll still be around a bit (with some interruptions) :)
<mvo> pitti: haha, ok
<pitti> mvo: ah, it's there now; twice! o_O
<mvo> heh :) I uploaded it once more just to be sure
<pina> any processor geeks
<pina> whats the amd64 k2 like
<pitti> mvo: I reject the duplicate upload, don't be scared; I accepted the other one
<mvo> :)
<Mithrandir> mvo: please don't upload multiple times, it creates extra work for the admins.
<pitti> ok, have a nice weekend everyone!
<Mithrandir> see you, pitti 
<glatzor> Riddell: completely written by me :) but we can change this without any problem
<dholbach> good night everybody - have a nice WE!
<bddebian> You too dholbach
<dholbach> thanks bddebian
<ogra_> night dholbach 
<dholbach> bye ogra_
<mvo> bye dholbach!
<mvo> have a great WE!
<dholbach> thanks
<juliux> hi, is it a knowen problem that the herd3 installer is not working on core duo?
<cjwatson> juliux: no, bug#?
<cjwatson> and which installer?
<juliux> cjwatson, i try to find it i report it allready for herd3
<juliux> herd2
<cjwatson> don't necessarily assume that it's the same bug
<cjwatson> I'm pretty sure I fixed *one* issue affecting core duos from herd2
<juliux> hey no it is working
<juliux> after 3-4min 
<cjwatson> oh, that's in the release announcement, which you should read
<juliux> but i get always a kernel not found
<cjwatson> at hardware detection?
<juliux> and now it is workind
<cjwatson> yes, see the release announcement
<juliux> ok
<cjwatson> that's not actually "kernel not found", it's "kernel: not found", i.e. a message "not found" emitted by the kernel
<cjwatson> the message could do with being a touch more verbose ...
<cjwatson> anyway, workaround is hw-detect/start_pcmcia=false if you don't need PCMCIA
<juliux> i will test it
<juliux> cjwatson, thxs it's working
<cjwatson> excellent
<juliux> i was wondering because on my athlon xp it work's without this workaround
<bddebian> Anyone know how I fix something like this appropriately?  "sh compile-foo.sh"  then compile-foo.sh has 'sh libtool ...' which fails 
<bddebian> sh compile-gtk2im.sh
<bddebian> /bin/sh: Can't open libtool
<davmor2> heno: are you there
<cjwatson> juliux: your athlon xp probably happens to have the i82365 pcmcia chipset for some reason
<bddebian> I know I can change 'sh libtool ...' to 'sh /usr/bin/libtool ..' and it will work but it seems like a hack
<cjwatson> juliux: if that's not present, a kernel bug means that we get into a udev/modprobe loop
<juliux> cjwatson, my core duo is also a desktop pc
<heno> davmor2: hi
<cjwatson> juliux: yeah, I expected that
<juliux> cjwatson, i will test it also on my notebook;)
<cjwatson> juliux: anyway, point is the processor isn't the relevant thing in this case
<davmor2> heno: discovered a usability flaw with herd 3 listed on the testing forum
<juliux> cjwatson, i never stop learning
<davmor2> heno:Basically you get two icon for networking on a laptop which will be confusing as hell for a new user.
<heno> davmor2: yes, I think network-monitor is meant to be removed
<davmor2> heno: should it be reported as a bug though?
<heno> davmor2: if it's still there on wednesday file a bug in Malone 
<heno> I think there is one already
<Mithrandir> yes, there is.
<cjwatson> davmor2: known, was discussed here earlier
<davmor2> okay cool
<heno> davmor2: just curious did you try a search in Malone
<heno> (because that still needs some work)
<heno> and we should probably document that better as well
<siretart> cjwatson: are there plans to readd raid and lvm support to the livecd?
<heno> when you see a new bug appear, have a look at bugs filed ijn the past two days 
<heno> ... or something
<cjwatson> siretart: it's never supported those
<cjwatson> siretart: I do plan to build that on top of the new partitioner eventually, though
<siretart> cjwatson: the dapper live cd does both out of the box, and works fine!
<bddebian> grr
<pina> what is a .core file ? core dump?
<Nafallo> cjwatson: that would rock :-)
<pina> its created in the home dir i know but it's created when a program crashes?
<Mithrandir> siretart: that's by accident rather than by design.
<davmor2> heno:No but only because I wasn't sure whether to report it as a bug.  Yo are right though the search needs some help.  I often fill out a new report because the original is under something completely different.
<cjwatson> siretart: only because mdadm and lvmwhatsit happened to be in the dapper standard seed
<cjwatson> Nafallo: feel free to help out with the new partitioner ...
<sfllaw> seb128: SRU for bug 76301 is approved.
<Ubugtu> Malone bug 76301 in gnome-vfs2 "patch from CVS to fix crash triggered when closing ekiga by example" [Medium,Fix committed]  https://launchpad.net/bugs/76301
<siretart> Mithrandir: It's a really helpful accident, since it allows me to actually repair my system and restore my lvm metadata, which is on a md raid
<Nafallo> cjwatson: might be better for our users if I don't really :-P
<siretart> cjwatson: what's the problem with adding mdadm and lvm2 back to the live seed?
<Mithrandir> siretart: just install them on the live cd when you want to recover stuff, then?
<siretart> Mithrandir: I tried that, but for some reason, it didn't get my volume group started
<heno> sfllaw: re-ping - Can you look at this and fill in some blanks: https://wiki.ubuntu.com/Testing/InstallMethods ?
<siretart> I think I already filed a lp bug about that.. lemme search
<cjwatson> siretart: at the moment, ubiquity will fail if you have active MDs or VGs
<cjwatson> well, LVs
<davmor2> I think that people with some technical proficiency tend to select the exact package the bug affects where as users just go this is broken.  With apport now you get a nice bug-report but quite often people just leave it to the program.
<cjwatson> siretart: this is a bug, but I don't overly want to trigger it deliberately until I have time to add full support to ubiquity
<siretart> cjwatson: aah, I see. would you accept a patch to ubuiqity which searches for active vg, deactivates lvm and continues with it?
<cjwatson> siretart: sure
<cjwatson> siretart: on the understanding that it will be obsoleted in time
<sfllaw> heno: Ah, missed that.  Sorry.  Will do.
<heno> cool, thanks
<cjwatson> well, when I say "will fail", I mean "I got bug reports about it in the dapper cycle", but I haven't knowingly fixed it
<siretart> cjwatson: if we can have mdadm and lvm2 back in the live seed, sure!
<cjwatson> siretart: I dunno. If installing them after boot doesn't work for you, then there's something else wrong
<cjwatson> you might have to run some of the usual tools, but ...
<siretart> I see, I'll retry with herd3 with manually installing them then
<cjwatson> the problem with adding them back is that I'm pretty sure they'd be first against the wall as soon as there's any size pressure
<cjwatson> which there will be
<cjwatson> if the installer supported LVM and RAID, there would be a stronger case for having them there
<siretart> hm.. ic
<somerville32> Mithrandir, ping
<Mithrandir> somerville32: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
* kylem gives Mithrandir a contentless kick in the arse.
<somerville32> Mithrandir, Is there any reason Xubuntu Herd 3 hasn't been released yet? :)
<bddebian> hehe kylem
<Adri2000> somerville32: gpocentek said he didn't have time to test it, and then I don't know what happened
<somerville32> Jani seems to think it is ok to release them (I assume she tested them)
<somerville32> I'll do some more poking to make sure.
<phanatic> somerville32: she!?
<somerville32> phanatic, he, she... it's all the same on the internet ;] 
<phanatic> somerville32: i've met him is person, so i do care ;)
<somerville32> haha
<somerville32> We all know he is a guy but my brain sees "Jani" and thinks female
<_ion> Well, Jani is *obviously* a male name. ;-)
* phanatic agrees
<kylem> somerville32 is just mentally replacing "jani" with "janeway"
<somerville32> hehe
<zul> im mentally undressing janeway
* somerville32 mentally dresses janeway back up.
<phanatic> lol
<kylem> really didn't need to know that, zul.
<zul> yeah i probably should have kept that to msyelf
<joejaxx> hello _TomB 
<hackeron> hi, I'm trying to install ubuntu, but it seems there's a version mismatch between the available version of nvidia-kernel-source (1.0.8774) and nvidia-glx (1.0.8776) - is this a known issue?
<hackeron> just did another apt-get update, looks like it's fixed already :)
<Riddell> glatzor: how's the packaging getting on?
<Riddell> glatzor: I think I'm about done
<somerville32> Riddell: Do you think you could test the Xubuntu PPC build for us again for Herd 2, please? : )
<Riddell> herd 2?  that's obsolete
<maxamillion> anyone know who maintains the libapache2-mod-python package?
<somerville32> *Herd 3
<glatzor> Riddell: fine. nearly done. I just perfrom a final test
<Riddell> glatzor: I just pushed some more changes
<Riddell> that's me done with it until after 
<Riddell> feature freeze
<Riddell> somerville32: URL?
<somerville32> Riddell: http://cdimages.ubuntu.com/xubuntu/daily-live/current/
<glatzor> Riddell: ok. do you want to have a dist-upgrader-kde package? or should we just skip the kde frontend in the update-manager bianry packages
<somerville32> Riddell: http://cdimages.ubuntu.com/xubuntu/daily/current/
<somerville32> Riddell, desktop and alternative ISOs respectively
<BrendanM> Hello, somebody told me you could request Ubuntu rebuilds of software here. Could somebody point me in the direction to do that?
<Riddell> glatzor: is there a dist-upgrader package for gnome?
<BrendanM> I found a Debian package but it's not working right on my system.
<Riddell> BrendanM: if there's a source package ask in #ubuntu-motu for someone to consider it for upload
<BrendanM> ok
<glatzor> Riddell: no. it is part of update-manager. If there is a complex dependency situation the update will be performed by dist-upgrader
<Riddell> glatzor: oh, not needed there I think
<glatzor> Riddell: I think so too. So I will just not provide binary packages for the KDE view
<twb> Mithrandir: hey, does feisty's casper do netbooting yet?
<Riddell> glatzor: I pushed another change (making it use datadir)
<cbx33> Can i ask guys, what is this channel for discussing specifically?
<cbx33> just dev of Ubuntu and not apps specific to ubuntu?
<glatzor> Riddell: I already fixed this
<glatzor> Riddell: to test you need both of these two: http://bzr.glatzor.de/python-apt/sebi and http://bzr.glatzor.de/software-properties/sebi
<Riddell> glatzor: has python-apt updated today?
<glatzor> Riddell: it was a broken one.
<geser> keescook: hi, would you sponsor an upload of gnupg2 again? I've packages ready for the new upstream release (2.0.2)
<keescook> geser: cool, sure.  where can I find it?
<geser> keescook: http://members.ping.de/~mb/gnupg2/
<keescook> geser: any particular changes to the packaging or is it just an upstream release bump?
<geser> primary only the new upstream version, I've done only 3 small fixes
<keescook> okay, cool.  I'll get to it in a bit.  thanks for getting it packaged!
<geser> all stated in the new changelog entry
<tepsipakki> oh crud, xscreensaver was in main
<tepsipakki> tried to upload it :)
<Riddell> glatzor: works perfectly
<glatzor> Riddell: fine.
<Riddell> glatzor: so... shall we upload to ubuntu?
<glatzor> which files should I add to the POTFILES.in? can gettext deal with ui files?
<Riddell> no it can't
<Riddell> but all the strings should be the same as the GTK UI
<glatzor> Riddell: oh, I would like to fix some issues before.
<Riddell> ok :)
<Riddell> glatzor: just add the four .py files
<glatzor> there seems to be a problem with special chars. The German ones, e.g. , are broken in the KDE frontend
<Riddell> meh, I tested it with french
<Riddell> all of them?
<glatzor> oh, seems to work now.
<glatzor> the strings from the iso country codes were broken
<Riddell> where? in the mirror dialogue?
<glatzor> Riddell: yes. but it is ok now.
<Riddell> umm..  something funny going on 
<glatzor> Riddell: night. I have to get up early tomorrow
<Riddell> ok, sleep well glatzor, thanks for everything
<glatzor> Riddell: you are welcome
<kro> cjwatson: Should the netboot version of debian installer located at http://archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386/current/images/netboot/ubuntu-installer/i386/ work?
<kro> cjwatson: thats what I used.
#ubuntu-devel 2007-02-03
<keescook> what's the right why in python to do the html encoding conversions (i.e.  ':' -> '%3a') ?
<keescook> ah-ha   urllib.quote("string")
<sfllaw> ogra_: Is there a known problem with gnome-screensaver and LTSP?
<joejaxx> _MMA_: /win 15
<joejaxx> bah
<deltab> keescook: that's URL percent-encoding  nothing to do with HTML
<keescook> deltab: yup, you're right.  I never get the name right.  :)
<Seveas> keescook, urllib.urlquote()
<Seveas> actually, urllib.quote / urllib.quote_plus
<keescook> Seveas: that's what stumped me originally, that function is for dictionaries, not strings.  yeah.  .quote is what I found.  :)
<Seveas> urllib.quote is for strings... :)
<Seveas> >>> urllib.quote('foo bar kees@ubuntu')
<Seveas> 'foo%20bar%20kees%40ubuntu'
<zul> hey
<GateWar> UBUNTU KICKS ARSE MAN THANK YOU FOR ALL YOUR EFFORTS LETS TAKE DOWN MICROSOFT AND BILL GATES AND ALL THE MOTHER FUCKERS THAT USE WINDOWS THIS SHOUlD BE OUR AIM I THINK BILL GATES TAKES IT UP THE BUM ALL NITE LONG AND FUCK HIM HE SMELLS LIKE A WET DOG I SHOULD SAY HEY YOU FUCK HIM..MY ASS IF A CHINESE RESTURANT I HAVE THE POOH POOH PlATTER.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@125-236-173-92.broadband-telecom.global-gateway.net.nz]  by Hobbsee
* GateWar was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<stdin> hmm
<Hobbsee> heh
<Nafallo> gn{att,ight}
* mode/#ubuntu-devel [+b *!*@88.232.*]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<lamont> keescook: you around?
<keescook> lamont: a bit delayed.  what's up?
<imbrandon> cjwatson, still arround/awake ?
<imbrandon> err nvm
<imbrandon> man i was way off on my time
<imbrandon> any archive admins awake this hour
<Mithrandir> yes, why?
<imbrandon> Mithrandir, can you manualy promote python-eyed3
<imbrandon> MIR approved etc, so libgpod 0.4.2 will build
<imbrandon> ( and do a giveback on libgpod 0.4.2 please )
<imbrandon> if needed ^^
<imbrandon> both are needed so i can poke the amarok 1.4.5 release up
<imbrandon> Mithrandir, pweeease and thank you :)
<imbrandon> https://launchpad.net/+builds/+build/296789  <-- dunno if that needs a giveback or not
<Mithrandir> imbrandon: done and np
<imbrandon> thanks
<Mithrandir> no, depwaits are handled automatically
<imbrandon> kk cool
<Mithrandir> it requires a publisher run, but one just started, so you should have built libgpod in an hour or so
<imbrandon> cool ok, thanks
<imbrandon> then in about 2 hours i can poke up amarok 1.4.5 ;)
<cjwatson> imbrandon: 8:50am would normally be OK, but not so much on a Saturday morning :)
<imbrandon> cjwatson, hehe right on, Mithrandir got me hooked up though ;)
<StevenK> Mithrandir: Please give-back php4 on all arches.
<Mithrandir> StevenK: given-back
<StevenK> Mithrandir: Thanks
<heno> Mithrandir: if you are around: cold you run your bug-tracker script (or send me a copy)? People don't have anywhere to file their ISO testing bugs
<heno> I sent you a mail with a list of tests cases
<heno> Mithrandir: desktop: erase disk, auto-resize, custom partitioning, winfoss
<heno> Mithrandir: alternate: erase disk, auto-resize, custom partitioning, OEM, expert
<heno> Thanks :)
<heno> Mithrandir: FYI I've closed the old tracker bugs, just not created new ones
<bddebian> Heya
<cypherbios> heya bddebian :)
<bddebian> Heya cypher
<bddebian> Err cypherbios
<cypherbios> too many cyphers here :)
<bddebian> :-)
<bluefoxicy> I just have to know
<bluefoxicy> how is it that I run synaptic, update my system, and synaptic crashes
<bluefoxicy> immediately following, Firefox crashes
<bluefoxicy> 100% correllation between recent firefox crashes and recent synaptic crashes; Firefox only ever crashes with synaptic
<poningru> heno: ping
<soundray> I've tested Herd 3 according to https://wiki.ubuntu.com/Testing/Long and written a report -- should I submit this somewhere or just file the bugs?
<somerville32> jdub, ping-a-ding-dong
#ubuntu-devel 2007-02-04
<twb> Mithrandir: hey, does feisty's casper do netbooting yet?
<Hansin321> I read somewhere (links from Ubuntu Developers Conference in Mtn. View I think) that one goal is to get a smoother transition from start-up to actually being in the system (whether GDM/KDM/XDM or in the DE itself).  I have a multi-boot system and threw on OpenSUSE 10.2 to just check it out.  I feel Ubuntu is a better overall experience, but OpenSUSE does have a nice boot sequence screen, where you can show/hide the details of the boot process in a n
<Hansin321> ice font.  I assume this uses the framebuffer.  Something like this would probably go a long way to make Ubuntu look more professinal and polished as a first impression.  Let me know if I am out of place posting this in this IRC channel.  Thanks.
<kylem> opensuse is probably using rhgb, i'd guess?
<Hansin321> Not sure what is uses, but it does look pretty nice.  I'll have to some digging and figure that out.
<Amaranth> rhgb is a hack
<Hansin321> I was told it is from www.bootsplash.org
<Hansin321> I just verifed in the opensuse directory that it is using this.
<tenco> hi
<tenco> i wanted to test gnome beta 1 aka 2.17.90 without going through garnome hassle
<tenco> are there already 2.17.90 gnome debugging packages for feisty available?
<jrib> tenco: you want #ubuntu+1 for support with feisty
<tenco> ok
<bddebian> Heya
<Keybuk> why the hell isn't there an execvpe() ?
<Mez> Keybuk, usually the answer to questions like that is "to annoy you"
<whoppix> hey all :) im just wondering if there is a special reason, why "libpoe-perl" is in version 0.3203 (edgy), while the official stable version is 0.9917? (CPAN) the old version in the repositorys is kinda outdated, the api has changed, and its not really compatible to the new POE modules.
<cypher1> !seen
<bddebian> Heya
<nox-Hand> Hey
<nox-Hand> When installing from a 6.06 CD, can I update the installer inside the liveCD?
<pochu> nox-Hand: join #ubuntu :)
<nox-Hand> pochu: Already there :-) I guessed it'd be a dev question
<pochu> nox-Hand: it isn't ;)
<nox-Hand> pochu: Laters then ;) Cheers
<lotusleaf> nox-Hand: #ubuntu-offtopic #ubuntuforums have fun ppl
<nox-Hand> lotusleaf: It was not a fun question. It was an install upgrade question ;)
<lotusleaf> nox-Hand: they field questions, too very often ;)
<nox-Hand> Hehe
<lotusleaf> :D
* nox-Hand runs off toanother channel
<Q-FUNK> is there an e-mail address for ubuntu-printing team via which they can be reached?
<gnomefreak> Q-FUNK: it should be on their LP page
<Q-FUNK> gnomefreak: no e-mail address there.
<gnomefreak> Q-FUNK: can i see the link pleas
<gnomefreak> e
* gnomefreak can find anything :)
<gnomefreak> except a local team
<Q-FUNK> https://bugs.launchpad.net/~ubuntu-printing
<ivoks> Q-FUNK: what's the problem?
<Q-FUNK> ivoks: I need to poll the opinion of the team on a certain issue.
<ivoks> about what? :)
<Q-FUNK> ivoks: cups-pdf.
<Q-FUNK> ivoks: but it would be simpler to just send an e-mail to the whole team than to explain now to you and re-explain later.
<gnomefreak> i only found doko's address not a team address. maybe file a bug report as the poll?
<ivoks> well, i really don't know how you could do that, except sending email to all members
<ivoks> i don't say you should do that, but... nothing else comes to my mind...
<Q-FUNK> ivoks: that's why I was askign if there is any mailing list for that team.
* gnomefreak would talk to dok^o (without the ^) about it
<ivoks> gnomefreak: i think martin or till would be better option, cause they are involved in development, triage and planing of printing
<gnomefreak> i went with matthias because he is owner
<BenC> anyone running latest feisty and have an atheros card?
<BenC> Someone willing to test some new lrm packages with updates madwifi
<gnomefreak> nope sorry :(
<Orby> could someone tell me what version the herd3 .iso has on it.
<Orby> *kernel
<pochu> Orby: 2.6.20-6, I think
<Orby> ah perfect :)
<Orby> thanks
<Nafallo> .11
<pochu> :)
<Orby> ah
<Orby> even better :D
<farruinn> sorry this isn't exactly development related, but how can I find out what kernel modules are included for an install disc w/o burning the disc?
<Nafallo> loopmount it
<Nafallo> or ignore me btw :-)
<farruinn> Nafallo: I did, but I'm not seeing the filesystem that the installer uses. 
<farruinn> is it loaded from boot/initrd.gz or boot/isofs.b?
<farruinn> or is there somewhere I can see what packages are used to make the installer cd?
<bluefox_> meh.
* bluefox_ looks at Windows XP and its ability to spin down hard disks after 3 minutes; turn off the monitor after 5; enter suspend mode after 15 minutes; and hibernate after an hour
<bluefox_> why can't I do that with gnome vo.ov
<bluefox_> We've got great ACPI
<Kano> man hdparm
<Kano> or install laptop-mode-tools
<Kano> laptop-mode-tools - Scripts to spin down hard drive and save power
<bluefox_> Kano:  hdparm lets me do it 'now"
<bluefox_> not in X minutes or Xd minutes if on battery
<Kano> well use the laptop-mode-tools
<bluefox_> also I'm more thinking of standbying and low-powering desktop machines
<geser> keescook: you missed to include the orig.tar.gz in the new gnupg2 upload
<keescook> geser: yeah, I just re-up'd it now.  :P
<geser> keescook: thanks for uploading
<keescook> sure, sorry I took so long!
<geser> I got the mail just now
<geser> keescook: np, you got it uploaded before the UVF
<keescook> :)
<pitti> hey keescook 
<keescook> hiya pitti!
<pitti> hi zul 
<mooey> howdy. im trying to fix a bug in an ubuntu package, but rebuilding it with dpkg-buildpackage fails, is this the correct place to ask for some help?
<sistpoty> mooey: #ubuntu-motu is more appropriate
<mooey> thanks, sistpoty 
<sistpoty> np
<troy_s> Sorry if this is the wrong forum, but how do I force Ubuntu to display the update manager with a baloon hint? (for testing)
<pitti> troy_s: downgrade a package
<rc-1> how do you get in the GNU/Linux repos? (my servers not done yet but when it is i would like to put it/the client in there if possible)
<Burgundavia> rc-1: sorry, I don't understand what are you looking for
<Burgundavia> are you looking to help with development of Ubuntu?
<Burgundavia> are you looking to mirror the ubuntu repositories?
<rc-1> Burgundavia, nothing yet, but when i finish my project i was wondering how i would apply to be in the ubuntu repository
<rc-1> no how to apply to be included in them
<Burgundavia> you want to help mirror the ubuntu repositories?
<rc-1> to add a new program to them
<Burgundavia> ah
<Burgundavia> in that case, go to #ubuntu-motu
<Burgundavia> they can help you get a new program into Ubuntu
<rc-1> Burgundavia, thanks :)
<Burgundavia> rc-1: no worries
#ubuntu-devel 2008-01-28
<LaserJock> asac: there is some flexibility via ~ubuntu-sru that's true, but the process seems to dissuade quite a number of people from even trying
<jcastro> bryce: I think it might be a good idea to bring this up in the -devel mailing list.
<LaserJock> and although i can see somewhat of a point in making it hard enough to do an SRU that people need to find a good reason for doing it, it can also have a negative effect on how upstreams look at Ubuntu, IMO
<jcastro> bryce: some gnome'rs have brought up the same issues
<jcastro> bryce: I am sure you're as jet lagged as I am
<jcastro> so going to move on at this point...
<asac> LaserJock: why do they get dissuaded? because they cannot set the right switches in launchpad, or because they don't want to provide patches that are properly documented for each individual issue?
<jcastro> and I think I am sick now; here comes the ubuflu
<crimsun> likely a combination.
<asac> jcastro: get well soon :-P
<bryce> jcastro: take some airborne; I find it really helps
<LaserJock> asac: because they feel they did the responsibility of releasing a bug-fix and are being told that they now need to fill out Ubuntu paperwork
<bryce> jcastro: I make it a habit of bringing a tube of it when I'm out of town and take one a day
<LaserJock> I think the situation would be very much different if we had enough eyes and hands to actively keep up with upstreams
<jcastro> bryce: lots of liquids seem to help
<asac> LaserJock: usually the paper work is done by ubuntu devs or contributors that want to see those fixes in it. so somehow you are right that we don't have enough hands to do that. but changing the policy won't help here imo
<LaserJock> well, a know that we've had problems in the past where devs and contributors were not filing SRUs because it was excessive paperwork
<LaserJock> it depends on somebody actually caring enough to do it, and at present I'm not sure we have enough people to even cover Main well if it's a "well if you care so much why don't you file a SRU" kind of thing
<bryce> asac: I disagree; there are many, many cases where people request an Xorg / driver fix be put out for Gutsy, that I don't do because of all the paperwork.
<bryce> asac: In fact, I've pretty much given up on the idea of SRU's for Xorg driver updates, and have been working on building something on Envy
<bryce> which I think is going to be a better solution all around, but it's admittedly working around the sru process, not fixing it
<asac> bryce: hmm ... imo if they are not critical enough to do that paper work it might be a good indicator that they shouldn't go in imo. and drivers usually have a high risk to come with hard-impact regressions. if they break they might just break a previously working system completely.
<bryce> asac, yes this is the circular logic that irritates the heck out of me - "If it's important enough, you ought to be willing to do 3 days worth of paperwork to get it in.  If you're not willing to do 3 days worth of paperwork, then obviously it isn't important enough."
<bryce> if you're not a terrorist, then why should you have a problem with being cavity searched each time you fly?  If you have a problem, then maybe you are a terrorist?
<asac> bryce: for you a driver fix takes 3 days? how many bugs do they fix?
<bryce> and yes, driver changes obviously carry more significant risk than a package like inkscape.  but at the same time the bugs they fix tend to be more severe as well - usually solving "I can't get Ubuntu to work on my computer anymore due to X problems" compared with "Inkscape crashes when I cross my eyes"
<bryce> asac, 3 days is a best case; obviously usually a driver SRU takes much, much longer
<asac> you mean it consumes 3 days of work or takes 3 or more days of your attention
<bryce> asac, and "has a non-zero chance of breaking a previously working system" is why driver SRU's have proven impossible to file.
<bryce> asac, packaging, building, and thoroughly testing a driver change can easily consume a day by itself.  The paperwork takes additional time - maybe an afternoon, as does summarizing bug report commentary into problem descriptions and test cases, and then additional time/attention responding to review requests, usually requiring modifying the packaging and going through the rebuild/retest process a few times, then a whole bunch of
<bryce> time spread over several days or weeks recruiting other people to also test the package and respond to their questions
<bryce> so I would estimate 3 days of effort to be a minimum for filing a sru for a driver bug
<bryce> but more likely it would take several week's of attention
<bryce> and after this, it would almost always be denied.
<asac> bryce: yeah ... i see. imo the process is right still. if we cannot guarantee that there is no regression, we cannot really upload drivers
<bryce> asac, ah and I gather you do not see this as an issue?
<asac> so it does the right thing .... under the assumptions that we follow a "stable release policy" as we currently define it.
<asac> bryce: of course, but not an issue that can be easily fixed
<bryce> asac, and in any case, wouldn't it save more time and angst to simply say, "Our policy is no changes to drivers in a Ubuntu release due to risk of regressions," rather than elaborating this extremely lengthy SRU process document with all this paperwork?
<bryce> asac, it seems like the process is documented with the idea of handling something severe and high risk like Xorg, but is being applied even in cases like Inkscape where really there isn't such a high risk
<bryce> so it ends up being inapplicable for the former, and too complicated to bother with for the latter
<asac> well ... we have two big classes of regressions that we care about: 1. complete system breakage ... 2. feature breakage.
<asac> if 1. can happen we cannot upload at all (as we found out for the drivers)
<asac> 2. we can only prevent by thoroughly reviewing and not letting in bug fixes that are not high-impact or whose patches don't look reasonably minimal imo.
<asac> maybe really raise this on ML. maybe we can really find something we can improve
<bryce> well, I return to my original point - solving this by imposing a lot of paperwork to the point that people stop bothering to try doing sru's is just sweeping problems under the rug, not really solving the problem.
<asac> bryce: the paparwork is done to take load from rare resources: sru reviewers
<asac> you cannot expect the reviewer to figure out how to get the patches to review them et al
<asac> (i don't say that all is perfect, but in general it does what we want imo)
<bryce> I can understand that.  What I'm saying is that pushing that workload back onto the sru requestor ends up reducing the number of sru requestors
<bryce> so yes, in a way it solves the problem of the sru reviewer's workload
<asac>  ... which can or cannot be a bad thing ...
<bryce> sigh
<asac> :)
 * asac hugs bryce 
<asac> ok i am off going to bed. we should go ahead on ml
<bryce> in any case, it feels like the process is broken, and trying to get it fixed is just wasted breath
<bryce> night
<bryce> well, like I said, for my own issues (both inkscape and xorg) I'm just bypassing using sru's to get the work done
<bryce> I just hope that other people's complaints about the sru process get listened to and not just dismissed as "whining"
<bryce> since I think long term it could hinder Ubuntu in general
<asac> i think nobody declares this discussion as whining ... if we can improve things, we should improve them. but i don't see how we can lower the documentation bar because its essential for reviewers. only accepting high-impact bugs is in some way a measure to overcome that we don't have endless resources and the vague definition of high-impact already gives us enough flexibility to approach special cases imo.
<theunixgeek> How do I make my own window border theme?
<theunixgeek> How do I make my close button be red and the minimize button blue without writing a completely new theme? (GNOME, GTK, etc)
<pitti> Good mornign
<RAOF> Afternoon, pitti
<LaserJock> hi pitti!
<LaserJock> back from the Sprint?
<pitti> LaserJock: yeah, got home Saturday evening
 * Fujitsu was wondering how jcastro got his photo of a couple of distro-teamers recovering from NM 0.7.
<pitti> well, he walked into the room and pointed his cam at us, easy :)
<LaserJock> pitti: was it a pretty productive sprint?
<Fujitsu> pitti: Well, yes, but I didn't realise there was a sprint.
<pitti> LaserJock: I'd say so; lots of ad-hoc discussions, hands-on trainings, hacking, and clearing the TODO list
<geser> good morning
<pitti> hey geser
<geser> Hi pitti
<LaserJock> pitti: so we may get Hardy out the door after all? ;-)
<pitti> possibly :)
<warp10> Heya all
<l0wrd> i need some help.  im appear to be missing glade-2.0
<l0wrd> i keep getting a message "ld: cannot find -lglade-2.0"
<l0wrd> can someone help me?
<l0wrd> i have installed glade3 and done "apt-get install glade"
<RAOF> l0wrd: Off topic for this channel (it's not development *of* Ubuntu).  Also, you probably want libglade-dev, or somesuch package.
<l0wrd> RAOF: i see your point.
<l0wrd> RAOF: thank you for your help, everything is working now.
<dholbach> good morning
<asac> hi
<pitti> hey asac, hey dholbach
<dholbach> hey pitti, hey asac
 * asac hugs pitti + dholbach 
<asac> pitti: have you read the SRU discussion we had from 00:00 -> 02:00 yesterday?
<asac> aeh today :)
<pitti> asac: no, seems my proxy had some trouble with freenode connection
<asac> oh unfortunate :) ... i saw you online iirc
<asac> but maybe that was at the end
<asac> pitti: starts at 23:11 here: http://irclogs.ubuntu.com/2008/01/27/%23ubuntu-devel.txt ... and continues on http://irclogs.ubuntu.com/2008/01/28/%23ubuntu-devel.txt
<pitti> asac: ugh, that's a lot -- what was the problem and conclusion?
<pitti> and I don't agree that it's overly bureaucratic
<pitti> if you can demonstrate the problem, have a patch, and someone to test the upgrade, then you can just do an upload
<asac> i agree
<pitti> and if you fail any of these three, then an SRU is absolutely not appropriate
<asac> its bryce, jcastro and laserjock that disagreed
<pitti> [23:31] <bryce> I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through.
<pitti> bryce: ^ please tell me where the SRU process is labor-intensive which is not related to testing and necessary QA
<pitti> bryce: attach a patch and justification to a bug, upload a fix, coordinate testing (or ask sru-verification), that's it for you
<seb128> I've to admit the wiki page is not inviting
<pitti> bryce: I don't see how it could become any less bureaucratic
<pitti> I saw a lot of people doing SRUs in 'fire and forget' mode
<pitti> and the process is deliberately designed to not move these into -updates automatically
<pitti> bryce: I'm always open to suggestions how to improve it and make it less bureaucratic, so please tell me :)
<seb128> pitti: the wiki description takes several pages, I would not say it looks easy for people who wants to contribute
<asac> seb128: maybe we can polish the wiki ... like make the main document leaner and put the details in kind of a "check-list" that is kept separate.
<seb128> asac: would be nice
<pitti> seb128: right, it's very detailled, since it's documentation
<pitti> but people already do it incorrectly even with the current level of detail
<pitti> and it's not nice to push all the work to me, to fix bug states, repeatedly bother people about "is it fixed in hardy yet?" and "please fix it in hardy first", "how can I reproduce", etc.
<seb128> do you think they read it? or they run away because that looks too complicated?
<seb128> pitti: I don't think anybody wants to push the work to you
<seb128> but the wiki description should be something like
<seb128> * describe the issues and how to trigger it easy
<pitti> no, not 'want', but it ends up being me who does the work because people don't follow the documentation
<seb128> * attach your changes
<pitti> so I can always point them to '2.3 of policy' etc.
<seb128> * subscribe the team and get testing
<seb128> we discussed the wiki documentation with ogra at the bar some days ago, and I sort of agree with him, we have things too complicated and that scares users away sometimes
<seb128> we should have a small and easy description
<pitti> users shouldn't be concerned about this at all
<seb128> and an another page with details
<pitti> we communicate to them through bug reports
<pitti> i. e. 'Please test the fix in -proosed and tell us how it goes'
<seb128> users -> contributors
<pitti> <blatantly candid mode>if a contributor is not able to understand this policy, we should not leave him anywhere near SRU
<asac> pitti: i think one special case that was discussed and for which the process (righly) is too complex is that of pushing new upstream "bugfix-only releases" ...
<pitti> those instructions are not at all difficult; they are particularly easy and detailled
<asac> my comment was: ...  upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments.
<seb128> well, I've to admit I already delayed SRUs because I didn't do some for some months and I opening the wiki page was enough to make me not want to do it
<pitti> asac: I see; well, that's orthogonal to the process document, though
<pitti> seb128: you delayed some SRUs because nobody bothered to do at least a single test
<seb128> I don't want to read complicated text, I just need to basic actions
<pitti> seb128: i. e. the 'fire and forget' mode
<pitti> which just doesn't work for SRUs
<pitti> seb128: I did; I followed up with 'please test the package in -proosed'
<seb128> no, when I said delayed, it's a SRU I had to do
<pitti> ah
<seb128> and honestly I find the wiki page too complicated and discouraging
<pitti> so would it help to split it into a 'process' and a 'checklist for each step'?
<seb128> I just want the: do the patch, subscribe sru, add a testcase
<seb128> yes
<pitti> the problem that i see is that nobody would bother to read the checklist any more
<seb128> do you really think they do now?
<pitti> and the SRU team would end up with getting a lot of bad or wrong SRUs
<pitti> which in the end stalls the process much more
<pitti> seb128: some don't
<seb128> I think they just decide "it's too complicated, let's upload and tag"
<seb128> and some other are discouraged and run away
<seb128> some other do read it most likely too
<pitti> I don't think that there's a brilliant solution to this TBH
<seb128> but I'm not sure that those who read the pages would not look at the checklist if they have a doubt
<pitti> an SRU process is inherently complicated, so you cannot really come up with a trivial three-line document to describe it
<seb128> right, I'm not sure either
<pitti> the current policy hasn't been invented out of thin air
<seb128> it's not really complicated
<pitti> we started with a very small process, got breakage, and added checks to it to fix that breakage in the future
<seb128> it's basically: you have an easy patch which would make things nicer for lot of users, apply it to the stable package, test, write a testcase, upload
<pitti> seb128: what we can do immediately is to split the process into one for the developer and one for the SRU team
<pitti> seb128: right, that plus having a bug# and fixing it in hardy first
<pitti> seb128: I specifically added the 'upload immediately without ack' case a few months ago
<pitti> since that 'wait for SRU ack' was a discouraging delay
<pitti> and it works well so far
<seb128> right, I don't think SRU are too complicates
<seb128> I think the wiki page is though
 * pitti will split the process accordingly (dev vs. SRU team)
<seb128> you have 6 sections there and up to 7 items in those
<seb128> right, would be nice to split between what the uploader has to do
<seb128> and what SRU team, etc have to do to validate
<cjwatson> soren: feel free to send me a patch for the openssh host key thing you mentioned; I guess my only concern is that entropy might be scarce at init time and it could slow down boot substantially, and so it would still be better to generate them in the postinst if possible
<cjwatson> \sh_away: the decision-tree stuff in console-data has been there for a while now, but you can drop it on merge if you like; we don't use console-data any more
<cjwatson> CarlFK: you can if you like, but it won't make any difference since I'm already auto-notified of openssh bugs
<cjwatson> CarlFK: I've followed up to your bug
<soren> cjwatson: Well, the postinst invokes the init script, so they'd be generated at install time regardless.
<cjwatson> soren: right
<soren> cjwatson: The change just makes the process of distributing a VM with ssh installed in it much simpler. Currently, it needs to do various trickery to replace the host keys (so that not every instance of the vm shares their secret keys) on first install. With the change, you just remove the host keys as one of the last things before shutting down the vm and distributing it, and they'll get generated on boot.
<cjwatson> soren: *nod*
<soren> Cool. I'll whip up a patch.
<cjwatson> soren: though, I still think that stands a decent chance of having the VM sit there at boot trying to gather entropy - I'd still recommend regenerating the keys before shutdown
<soren> Erm.. How would that work?
<soren> I mean.. In the context of a use case where you want to create a vm image with ssh installed and distribute said image while avoiding that each instance will have the same secret key installed, I don't see how you can do the generation bit at shutdown?
<soren> cjwatson: ^
<cjwatson> soren: err, yeah, guess not
<cjwatson> fair point
<soren> Unless you freeze the vm just before shutdown and distribute that, but that would be quirky, and the entropy would be the same for anyone who fires it up, and you'd have lost anyway :)
<soren> cjwatson: FWIW, I believe Fedora and RedHat have used this approach for a long time and it seems to work for them.
<soren> I'll run a few tests and see if it gets stuck on entropy starvation.
<pitti> asac: ffox 3.0 for hardy-4?
<pitti> asac: ^ ... alpha ...
<geser> soren: as you touched iptables last, would it be possible to include the patch from Debian bug #358637 to get a static library compiled with -fPIC?
<ubotu> Debian bug 358637 in iptables-dev "libip* should be compiled with -fPIC; attempt to link the current libiptc.a binary into a shared library on amd64 causes an R_X86_64_32S relocation error" [Important,Open] http://bugs.debian.org/358637
<asac> pitti: i will try to do mono today ... if that works well, then yes. otherwise after alpha4 ... but ill try
<pitti> asac: what does mono have to do with it?
<asac> mono is in main and has a gecko binding
<soren> geser: /me looks
<asac> pitti: so we could not dump firefox to universe
<pitti> asac: isn't that pretty independent of making ffox-3.0 the default?
<pitti> asac: or you mean mono will pull in ffox to the CDs, too?
<geser> soren: I see that the patch is for libiptc.a but I need a libipq.a with -fPIC. I guess a similar patch might work there too.
<soren> geser: I've not worked my way through all of it yet, but the patch I'm looking at right now adds a libipq_pic.a compiled with -fPIC?
<soren> geser: ...and I can't spot any other patches in it?
<geser> soren: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=003-dev_lib_fPIC.patch;att=1;bug=358637 adds only libiptc_pic.a
<asac> pitti: haven't looked ... i would like to have transition complete in main before replacing/conflicting firefox-3.0 on firefox. if you want it the way its now, i can do it though.
<soren> geser: Ah, so it does. My mistake.
<pitti> asac: I'm just concerned about doing it RSN, for testing
<soren> geser: If you make a patch, I'd be happy to review and upload it.
<geser> ok
<soren> geser: I've got an iptables upload pending anyway.
<asac> pitti:  personally, i don't have much concerns about a lack of testing. the package is pretty mature and we have had a bunch of users for quite some time already. but i understand the concerns from the release-managers point of view
<asac> pitti: let me try to get this mono thing done today. then we can decide
<asac> ok?
<pitti> souds good
<_StefanS_> BenC: you there?
<_StefanS_> BenC: I was wondering if the acpi/hal problem that reports the double number of batteries will be fixed in the final hardy ?
<cjwatson> StevenK: bit early for him as yet
<pitti> _StefanS_, BenC: you mean the problem that CONFIG_ACPI_PROCFS_POWER=y is enabled?
<pitti> _StefanS_, BenC: (which causes hal to pick up the battery from both /proc and /sys)
<_StefanS_> pitti: yep something like that
<_StefanS_> pitti: yes thats the one.
<_StefanS_> pitti: I saw it was fixed in the final 2.6.24 kernel (atleast partially)
<pitti> _StefanS_: then we'll get the fix
<_StefanS_> pitti: sweet. Thanks
<crimsun> No, it's still present in 2.6.24 final.
<_StefanS_> crimsun: only on some systems, right?
<_StefanS_> crimsun: I think they patched it to just return an empty list in proc
<_StefanS_> crimsun: maybe a userspace app needs to changed (e.g. g-p-m / guidance-p-m) to make it skip the empty one (?), thats how I understood it anyways
<pitti> seb128, thekorn: I found out why apport gets stuck in an endless loop, producing bug spam like bug 184306
<ubotu> Launchpad bug 184306 in totem "totem-xine-video-thumbnailer crashed with SIGSEGV in xine_list_get_value()" [Undecided,New] https://launchpad.net/bugs/184306
<pitti> seb128, thekorn: I reported it as bug 186599; any idea?
<ubotu> Launchpad bug 186599 in python-launchpad-bugs "fails to remove tags sometimes" [Undecided,New] https://launchpad.net/bugs/186599
<seb128> pitti: good
<mvo> soren: is it known that the generic hardy kernel does not boot in kvm?
<soren> mvo: Er... No.
<soren> mvo: -v
<mvo> soren: let me poke a bit more, but currently it looks like I can not boot the hardy generic kernel in my kvm (I haven't tried -virtual or -server yet)
<soren> What happens?
<mvo> soren: not sure, the kernel hangs and the last message is "time: pit clocksource has been installed"
<soren> mvo: Kernel version?
<mvo> but let me ensure that everything is up-to-date here first
<soren> Cool.
<pitti> Hobbsee, Riddell: do you have some minutes for checking/uploading the debdiff on bug 133944?
<ubotu> Launchpad bug 133944 in kdepim "package kitchensync 4:3.5.6-0ubuntu6 failed to install/upgrade: trying to overwrite `/usr/share/apps/ksync/ksyncui.rc', which is also in package ksync" [Low,Confirmed] https://launchpad.net/bugs/133944
<emgent> keescook, ping
<Riddell> pitti: the gutsy one?
<pitti> Riddell: yes
<thekorn> pitti: hmm, looks strange, will have a closer look in about half an hour
<pitti> thekorn: awesome, thanks
<Riddell> pitti: looks all good, want me to upload?
<pitti> Riddell: would be great, I'll accept it right away then
<Riddell> pitti: done
 * Hobbsee waves
<pitti> hi Hobbsee!
<Hobbsee> pitti: that fix should be fine
 * Hobbsee hugs pitti 
<mvo> soren: my kernel is 2.6.24-5-generic and I try to boot a 2.6.24-5-generic
 * soren sighs heavily at git
<geser> soren: http://members.ping.de/~mb/tmp/iptables.debdiff is the debdiff for iptables. I've adapted the patch from the Debian bug for libipq and tested the new iptables-dev with building perlipq and nepenthes on AMD64
<mvo> soren: same problem with the virtual kernel image it seems, let me know if I can help you further (e.g. screenshot of the hang etc)
<geser> pitti: the delo FTBFS looks like a bug in pkg_create_dbgsym: http://launchpadlibrarian.net/11490461/buildlog_ubuntu-hardy-i386.delo_0.8-2.2_FAILEDTOBUILD.txt.gz
<geser> do you agree?
<soren> mvo: I'll be all over it as soon as I manage to beat git into submission.
<thekorn> pitti: it seems that removing tags does not work for bugreport which have a 'nickname'
<pitti> geser: yes, I do; can you please open a bug for it?
<pitti> geser: might even be the same one as we had for that ocaml package; it's again -X
<pitti> thekorn: ah
<geser> pitti: the file it complains about isn't -X in the dh_strip call
 * Hobbsee curses the evil keyboard bug
 * Fujitsu does too, and fails to work out what triggers it.
<soren> mvo: How exactly do you invoke kvm?
<mvo> soren: kvm -m 512 -hda root.qcow2
<soren> mvo: Ok, nothing fancy I can blame it on, apparantly. :)
<mvo> soren: I tried -no-acpi for the fun of it, but it does not make a difference
<soren> mvo: Exactly which kernel version is it?
<mvo> soren: meh, I'm an idiot, ignore me. the "problem" is that the name of root changed from hda to sda in hardy (/me is hit by the plague apparently)
<soren> mvo: And the UUID magic doesn't work?
<geser> pitti: filed as bug 186610, looking at the meaning of dh_strip -X again it's an other incarnation of the same bug like in the ocaml package.
<ubotu> Launchpad bug 186610 in pkg-create-dbgsym "pkg_create_dbgsym fails if objcopy can't recognize the file format" [Undecided,New] https://launchpad.net/bugs/186610
<geser> soren: is the debdiff for iptables enough for you or should I file a bug about it?
<soren> geser: It's fine. It's compiling as we speak.
<mvo> soren: yes, that seems to be the case, vol_id returns the right ID_FS_UUID number and /etc/fstab looks good too
<thekorn> pitti: I committed a fix to the .main branch of py-lp-bugs
<pitti> thekorn: many thanks! I'll apply that to the retracers
<mvo> soren: I take a closer look after lunch
<soren> mvo: Awesome. Thanks.
<soren> geser: Uploaded.
<asac_resurrected> jcastro: there?
<asac> jcastro: oh i see you are on holidays ... enjoy
<pitti> pedro_, seb128: FYI, p-lp-bugs fixed locally with thekorn's patch and restarted
<seb128> pitti: rock on, thanks
<pedro_> pitti: great, thanks :-)
<geser> soren: thanks
<pitti> hi lamont
<lamont> morning Pici
<lamont> pitti, even
<Pici> Morning :p
<soren> geser: Oh, thank *you*.
<pitti> StevenK, Mithrandir: hildon-fm-l10n promoted by your request, but please keep in mind that this won't actually give you anything but an useless empty package
<pitti> StevenK, Mithrandir: TBH I'd much rather keep this in universe (since it doesn't make sense in main) until this is sorted out; if you prefer that, I can demote it agaih
<pitti> s/h$/n/
<\sh> bryce, ping bug #17601
<ubotu> Launchpad bug 17601 in xterm "[xterm] add better charclass map" [Wishlist,Confirmed] https://launchpad.net/bugs/17601
<\sh> pitti, what do you need from me to include some more libs to ia32-libs? :)
<bryce> hi \sh
<\sh> hey bryce
<pitti> \sh: a list of packages and a poke to do it :)
<\sh> pitti, ok...I just need at least 2 or 3 more libs to have wine on amd64 working like on x86_32
<\sh> bryce, we introduced this change in xterm during breezy, now it's gone completly ... I re-added it...mind using it? :)
<bryce> \sh yes it looks good
<\sh> bryce, do we have something like a bzr branch for xterm?
<bryce> \sh nope, not for xterm
<bryce> \sh, I believe it's contained in one of the x11- packages, I can check for you, one sec...
<bryce> hmm, nope, looks like it's a discrete package
<bryce> so it's just a straight upload
<\sh> bryce, yepp...it went from the X packages a long time ago :)
<bryce> \sh actually we recently re-merged them into some collections of apps.  But looks like this was retained as separate
<tjaalton> bryce, \sh: xterm is separate in debian as well
<tjaalton> \sh: please push that change to debian as well
<bryce> tjaalton: any idea on why the patch got dropped?  I don't see a mention of the bug# or 'charclass' in the changelog, so wonder if it just got accidentally dropped in a sync or something?
<jwendell> gdm in hardy is not playing the sound... is that an know issue?
<tjaalton> bryce: don't know, I'll check
<\sh> bryce, when I introduced the patch I wonder if I used the LP bug number these days
<bryce> \sh ah, that could explain it too
<tjaalton> bryce: seems that it was uploaded to feisty in Dec. 2006, way before me :)
<\sh> bryce, ah now
<tjaalton> um, "before I did anything related to X"
<seb128> jwendell: ogra mentionned it some days ago but nobody really looked at why it's broken yet
<\sh> bryce,    + Excluded patches:
<\sh>       - charClass patch is merged to upstream
<\sh> xterm (208-0ubuntu1) dapper; urgency=low
<\sh> upstream dropped it somehow
<\sh> bah it was me too ,-)
<jwendell> seb128, should I fill a bug?
<seb128> jwendell: if there is none yet feel free to open one
<ogra> seb128, dint you say there would be hal involved ?
<seb128> jwendell: that's likely an upstream issue though
<ogra> after looking
<seb128> ogra: that was for the login sound
<_MMA_> seb128: I think its related to the sound issues you and I had talked about.
<seb128> _MMA_: I don't think so, gdmplay just calls aplay
<seb128> it doesn't use libgnome
<ogra> seb128, ah, k .... i just remembered that asac had ahl probs as well and was wondering if our hal pobably starts to late
<jwendell> seb128, maybe something related to esd->pulseaudio migration?
<_MMA_> Ahh..
<seb128> jwendell: not likely, it uses aplay directly
<jwendell> seb128, ok, i'll find any related bug in upstream (when b.g.o is back)
<asac> ogra: apparently hal startup has been moved back at some point ... i had 15 here ... while other users have 23
<ogra> asac, ah
<asac> strange though.
<jcastro> asac: I am around
<asac> jcastro: good ... currently talking in #mono on irc.gnome.org
<_MMA_> ogra: Have you done a clean Edubuntu install lately? Ubuntu Studio mirrors how Edubuntu sets things up but currently gets no login/out sounds. Im wondering if its the same for you on Edubuntu.
<ogra> _MMA_, the edubuntu CD is going away in that form, so i dint test ... i had the prob on my classmate image which is a very specific setup and not really comparable to a normal install
<_MMA_> Ahh... Ok. Ill have to poke around more. Maybe tie crimsun down at some point.
<seb128> pitti: there is a hal dependency issue somewhere, I did apt-get upgrade my desktop and now hal doesn't start
<seb128> pitti: hal has been put on hold by I guess something else has been updated that doesn't work with the old hal or something
<seb128> ah
<seb128> I've libpolkit 0.7 installed with policykit 0.6
<pitti> seb128: can you please give some details? it works here
<pitti> seb128: maybe because I introduced the Breaks: of policykit-gnome and policykit?
<seb128> pitti: no, I think it's a lack of break
<seb128> I've libpolkit 0.7 and policykit 0.6
<seb128> I guess the lib should not be updated without policykit
<seb128> hal error is "Could not init PolicyKit context: (null)"
<seb128> let me get libpolkit 0.6
<seb128> pitti: bingo, downgrading libpolkit and libpolkitdbus to 0.6 fixes the issue
<seb128> pitti: either libpolkit 0.7 should Depends on policykit >= 0.7 or Breaks policykit <= 0.7
<pitti> the latter, I think
<seb128> ok
<seb128> should I file a bug about it?
<pitti> it's about as fast to just fix it IMHO
<seb128> that's a partial upgrade issue so not high importance
<seb128> do you have that in bzr or should I just do the change?
<pitti> seb128: already at it (no bzr)
<seb128> pitti: ok, thanks
 * seb128 hugs pitti
<pitti> seb128: uploaded
<seb128> excellent ;-)
<mantiena-baltix> hi all
<mantiena-baltix> maybe someone knows why there are not translation templates for brasero CD/DVD burner ? brasero is in main
<mantiena-baltix> see https://translations.edge.launchpad.net/ubuntu/hardy/+source/brasero
<seb128> mantiena-baltix: likely because there has been no upload building a template since it has been promoted in hardy
<seb128> mantiena-baltix: should be fixed when somebody does the 0.7.1 update
<mantiena-baltix> seb128: it seems so, tnaks
<mantiena-baltix> seb128: lmedinas should do that ;)
<seb128> you are welcome
<mantiena-baltix> lmedinas already packaged 0.7.1
<seb128> mantiena-baltix: so it just require sponsoring?
<mantiena-baltix> maybe, if Lois isn't ubuntu developer ;)
<seb128> mantiena-baltix: bug #186443
<ubotu> Launchpad bug 186443 in brasero "New upstream version: 0.7.1" [Undecided,New] https://launchpad.net/bugs/186443
<seb128> mantiena-baltix: should be uploaded soon I think
<mantiena-baltix> seb128: I too ;)
<seb128> I meant that it'll likely been uploaded soon since dholbach already commented on the bug
<mantiena-baltix> seb128: btw, ppa build daemons still removes translations from debs without universe in section ?
<seb128> mantiena-baltix: no idea about this one
<seb128> pitti: can you also backport the change from bug #184594 to the retracer? it fails retracing some bugs and just untag those due to it
<ubotu> Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594
<pitti> seb128: I'd love to, yes
<seb128> or tell me how to do it maybe so next time I can do it myself rather
<_MMA_> seb128: Who should I talk to about Bug 186365?
<ubotu> Launchpad bug 186365 in kdelibs "Please move xdg-user-dirs depend to "recommend"" [Undecided,New] https://launchpad.net/bugs/186365
<seb128> _MMA_: kdelibs? the kubuntu team most likely
<_MMA_> Ok.
<Riddell> _MMA_: not having xdg-user-dirs installed does bad things to kde apps
<_MMA_> Riddell: Many apps K apps are relying on these dirs now?
<Riddell> _MMA_: well kdelibs does
<_MMA_> Does xdg-user-dirs do more that stick those 5 dirs in a users home dir?
<_MMA_> s/that/than
<evand> Riddell: indeed, he also posted to the whiteboard on ubiquity-slideshow and to the ubuntu-installer ML.  Thanks for the heads up, I'll be following up to his post on the ML.
<_MMA_> Riddell: Does xdg-user-dirs do more that stick those 6 dirs in a users home dir? And if they rely so heavily on them, why is one allowed to remove the folders? I'm just trying to figure out what it does.
<Riddell> _MMA_: that and xdg-user-dir to answer where the directories are
<bryce> _MMA_ good questions; I've wondered the same
<_MMA_> Riddell: We're getting our users doing the same thinga as Bug #158146. "From what I have seen, a lot of new Ubuntu users moves half of the xdg dirs into trash right after installation." So we just decided to not take on this package from Ubuntu. Now it looks like we're forced to because our our inclusion of a K-app.
<ubotu> Launchpad bug 158146 in xdg-user-dirs "xdg-user-dirs should ignore ~/.Trash" [Undecided,New] https://launchpad.net/bugs/158146
<_MMA_> Riddell: If its moved to a "recommend" anyone installing from the repo should get it right? And xdg-user-dir is already in the kubuntu-desktop seed. Isnt this enough?
<Riddell> _MMA_: maybe, looking for the bug that made me make that change
<_MMA_> Ok.
<Riddell> _MMA_: https://bugs.launchpad.net/ubuntu/+bug/175982
<ubotu> Launchpad bug 175982 in ubuntu "Kdesktop in Kubuntu Hardy shows / icons rather than icons from /home/'usr'/Desktop" [Undecided,Confirmed]
 * _MMA_ looks.
<\sh> pitti, do you have any clue about dh_strip and those error messages? BFD: /home/shermann/packages/hardy/wine/0.9.54/new/wine-0.9.54/debian/wine-dbgsym/usr/lib/debug/./usr/bin/wine-kthread: section `.note.ABI-tag' can't be allocated in segment 2 ?
<Riddell> so it breaks kdesktop not having it installed
<pitti> \sh: ergh, no; I never saw anything like that, I'm afraid
<_MMA_> Riddell: Even if set as a depend in kubuntu-desktop? (I dont know if thats how you currently have it set up for Gutsy) And this is mostly an annoying cosmetic bug. Id like a better solution if there can be one but understand your position.
<Riddell> _MMA_: two options, the proper way would be to fix our xdg patches to do something sensible when xdg-user-dirs isn't installed, an easier way would be to make xdg-user-dirs a recomends on kdelibs and a depends on kdesktop (I'd just worry it would break other kde apps)
<_MMA_> Riddell: Yes. The latter is something like what I was hoping for as a quick solution but like I said, I understand your position.
<Riddell> _MMA_: lets do the latter then and see what breaks
<_MMA_> Ok. Let me know after the change if you want me to test thing. If it has to revert, I understand.
<_MMA_> s/thing/something
<Riddell> _MMA_: what kde app are you shipping?
<_MMA_> Rosegarden I believe. Might be another.
 * _MMA_ looks.
<_MMA_> Riddell: Rosegarden and creox. Both sound apps we've shipped for 2 releases.
 * soren hugs pedro_ 
<soren> pedro_: Thanks for checking the bind9 updates.
<pedro_> soren: you're welcome  :-)
<seb128> pitti: retracers fixed now
<pitti> seb128: yay you
<seb128> pitti: I've changed the gutsy and hardy on i386 and amd64 and verified it retraced correctly a bug which failed before
<\sh> pitti, when do you have time to work with me for the octave3.0 transition? :)
<\sh> s/for/on/
<pitti> \sh: what do I need to do for that?
<\sh> pitti, first, we need to sync octave3.0 from debian sid :) second, get rid of octave2.1 and octave2.9, when octave3.0 is build we need to sync some other packages, and I'll upload some more :)
<\sh> pitti, and as a third point, get rid of  koctave... there is a removal report pending :)
<\sh> pitti, there is a reference on https://bugs.edge.launchpad.net/ubuntu/+source/octave2.9/+bug/185959
<ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed]
<pitti> \sh: I can do that any time; just tell me what to do in IRC, and I'll do it
<\sh> pitti, cool :)
<\sh> pitti, so I think as a start, sync octave3.0 from debian sid (see bug #185653)
<ubotu> Launchpad bug 185653 in octave3.0 "[MoM SYNC] octave3.0 3.0.0-1" [Wishlist,Confirmed] https://launchpad.net/bugs/185653
<pitti> \sh: shall I remove the older ones now?
<\sh> pitti, nope...let octave3.0 build first...we have enough time to get rid of 2.1 and 2.9
<pitti> \sh: ok
<\sh> pitti, thx a lot :)
<pitti> you're welcome!
<cjwatson> ogra: could you commit the final debian/changelog diff from livecd-rootfs 0.48, please? the changelog still says UNRELEASED
<pitti> mathiaz: hi
<mathiaz> pitti: hi !
<pitti> mathiaz: do you still plan to switch dhclient to an AA profile, so that we can drop the client derooting patch?
<mathiaz> pitti: hum... not in the short term
 * Mithrandir is unhappy about dropping derooting patches just because you can use apparmour instead.
<slangasek> seb128: you said there was a new seahorse upstream pending, right?  does it fix the 64-bit issues when building with openldap 2.4 due to upstream API deprecation?
<pitti> Mithrandir: I'm not talkign about droping the dhcp server side one, that's much more robust than anything you can get with AA
<pitti> Mithrandir: but the client-side patch is horrible and still breaks things occasionally
<seb128> slangasek: doesn't look like so, no, do you have a bug about this issue?
<pitti> Mithrandir: and besides I think the client script suid root wrapper is buggy (you can probably inject environment variables and thus circumvent the derooting)
<slangasek> seb128: I have the ia64 w-b state for seahorse in Debian :/
<slangasek> well, in the build log rather - http://buildd.debian.org/fetch.cgi?pkg=seahorse&arch=ia64&ver=2.20.3-1%2Bb1&stamp=1201299907&file=log&as=raw  , last line
<slangasek> the issue is that ldap_init() (and many other functions) are deprecated upstream, and prototypes are only available if you specify -DLDAP_DEPRECATED
<seb128> slangasek: can you open a bug about that? I'm busy with other things right now but I can have a look and send that upstream later
<slangasek> seb128: yes
<seb128> thanks
<\sh> pitti, how can I say pkg_create_dbgsym to exclude some items like dh_strip -X is doing?
<pitti> \sh: -X is actually meant to work; however, it currently doesn't (bug 180364)
<ubotu> Launchpad bug 180364 in pkg-create-dbgsym "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,In progress] https://launchpad.net/bugs/180364
<\sh> pitti, well, I think wine is having a similar problem...as mentioned earlier with the ".note.ABI-tag" symbol somehow...objcopy fails and -X doesn't work ;)
<vrodic> tried running latest 2.6.24 package on a Vaio VGN-N31S, got a hang on boot with ACPI: EC: acpi_ec_wait timeout, status=0, expect_event=1
<vrodic> and ACPI: EC: read timeout, command=128
<\sh> pitti, adding some libs to ia32-libs just needs to add the i386 binary packages to pkgs/ and adding the needed source packages, right?
<pitti> \sh: no
<pitti> \sh: just add it to the list in fetch-and-build
<pitti> \sh: then run that script, add changelog, upload
<pitti> \sh: I can do it on ronne in the DC, though; the source is incredibly big
<\sh> pitti, yeah, I just need to test my theory first, so I need to add some libs to it to verify :)
<pitti> ah
<pitti> \sh: you can verify by copying the i386 libs from the i386 debs to /usr/lib32/
<\sh> pitti, right ;) just need to think about easier ways next time :)
<pitti> bdmurray: can you please moderate my 'bugpatterns in bzr now' mail to -qa@?
<ogra> cjwatson, thats weird ...
<ogra> ogra@laptop:~/livefs/trunk$ bzr st
<ogra> ogra@laptop:~/livefs/trunk$ grep hardy debian/changelog |head -1
<ogra> livecd-rootfs (0.48) hardy; urgency=low
<cjwatson> ogra: have you pushed?
<cjwatson> I'm at revision 160
<ogra> ogra@laptop:~/livefs/trunk$ bzr push
<ogra> Using saved location: bzr+ssh://ogra@bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/
<ogra> No new revisions to push.
<cjwatson> ogra: oh, er, *blush*, somehow I have a hardy -> UNRELEASED diff in my local copy
<cjwatson> wonder how that happened
<ogra> ah, phew
<ogra> was worried alrready
<bddebian> pitti: Hey, sorry to keep bugging you about plr but luk is now asking me if it is even worth keeping in the repo.  Do you happen to know of any users?  Do you use it?
<pitti> bddebian: I know that there are quite a few users in Debian, but no idea about Ubuntu
<pitti> bddebian: and I have never personally used it myself
<bddebian> pitti: Hmm, OK, thanks
<pitti> bddebian: I ended up being the Debian maintainer because in ancient versions plr was built from the postgresql source package
<pitti> bddebian: I split it out, but I haven't found an interested maintainer so far
<bddebian> Aye
<keescook> oooh... that's fun -- recent gnome pops a file window for every automounted NFS mount I have.  :)
<seb128> keescook: right, you can go to nautilus properties, media tab, and unselect the option there
<seb128> keescook: that's the "browse media when insered"
<soren> It also pops up when sbuild runs :)
<ion_> And when my camera (which uses PTP) is connected, it opens an error dialog about not being able to mount it.
<ion_> Iâd suggest changing the default value for that setting.
<seb128> ion_: I suggest trying to fix the bugs and making it smarter in what it mounts rather
<bdmurray> pitti: done
<pitti> bdmurray: cheers
<keescook> heh, but I like it when CD/DVD insert.  I need an "ignore NFS" option.  ;)
<\sh> keescook, me needs an ignore lvm snapshot mounts ;)
<\sh> but this key for "browse media when inserted" set to false helps a lot
<mdz> tracker is bringing my machine to its knees again
<Mithrandir> I think tracker has been bestowed on us as a compensation for the work we're doing to bring power consumption down.
<mdz> it apparently churned all weekend, though I didn't add anything new to my home dir
<seb128> it's buggy
<mdz> 979M	/home/mdz/.cache/tracker
<mdz> that's >10% of my home dir :-)
<seb128> I tend to agree that it has bugs and doesn't bring a lot and should probably not be installed on hardy by default
<ogra> ubuntu hardy minimal requirements for laptops: 4Gig of ram and at least a RAID0 array with 10000rpm disks :P
<ogra> seb128, did we ever had that many probs with beagle ?
<ogra> *have
<ogra> we should probably just switch back to not lose features
<ogra> (desktop searching was promoted pretty loud in gutsy, people might expect it)
<seb128> ogra: beagle is to universe, has no maintainer in ubuntu and we basically didn't test it, I would not recommend switching right now before a lts
<ogra> ah, bad ... i didnt know nobody takes care for it aymore
<ion_> All things considered, iâve always had a better experience with tracker. It also has the whole generic metadata DB thing, which will be teh awesome when programs start using it.
<ogra> ion_, well, after gutsy release i had a lot of ltsp people complaining ... while we dont install it in edubuntu, there are setups out there where people use ubuntu-desktop in an ltsp setup with nfs mounted homedirs and 200 users logging in in the morning ...
<ogra> i bet you can imagine what tracker does to your network in such a case
<jamiemcc> ogra: its designed to ignore nfs by default however there is a bug in the index mounted option
<jamiemcc> we are working on resolving all serious bugs
<jamiemcc> mdz: do you have any details on your problem?
 * ogra goes for dinner and caring for his cold ...
<\sh> ogra, gute besserung
<ogra> \sh, danke
<ogra> \sh, i'm appaernly better than the others that catched something, so i won moan :)
<\sh> ogra, oh sprint flu? ;)
<ogra> just a cold here
<ogra> others seem to have a flu
<mdz> jamiemcc: apart from this?
<mdz> 24644 mdz       39  19 1049m 641m 1644 S 14.9 42.3   1915:33 trackerd
<mdz> jamiemcc: I'm not sure how to determine what it's doing
<mdz> jamiemcc: the applet says intermittently "indexing completed" and "indexing in progress"
<Spenser309> Can anyone tell me how to run an shell command automatically when a cd is inserted?
<jamiemcc> mdz: is anything being modified file wise?
<mdz> jamiemcc: I'm reading mail, which means files are being moved around within my maildirs
<mdz> jamiemcc: xchat is writing to its logfiles
<mdz> but the total size of the files being updated should be miniscule
<jamiemcc> mdz: yeah
<jamiemcc> mdz: what about cpu?
<jamiemcc> is trackerd consuming tons?
<mdz> jamiemcc: it seems to take a much longer time to update the index for small changes than I would expect
<\sh> ogra, huehnerbruehe should be good for that, as my grandma said :)
<mdz> jamiemcc: right now it's holding 15-20%, but I've seen it much higher
<keescook> soren, \sh: yeah, I hadn't gotten to the snapshot mounting yet either.  Heh.  Maybe a "ignore paths: /var/schroot/mount, ..." option
<mdz> it's consuming gobs of memory too
<jamiemcc> mdz: yeah its beacuse ext3 really sucks when doing lots of small writes
<mdz> jamiemcc: is the size of my index normal?
<jamiemcc> mdz: 900mb?
<mdz> jamiemcc: for a ~13G /home
<mdz> mostly photos and music
<jamiemcc> mdz: for text files (source and emails) its usually no more than 20%
<jamiemcc> mdz: is file-meta.db huge?
<mdz>  12K email-contents.db  293M file-contents.db  1.8M file-update-index.db
<mdz> 1.2M email-index.db     489M file-index.db
<mdz> 100K email-meta.db      195M file-meta.db
<\sh> pitti, looks like that I need libjack, libcapi20 and unixodbc in ia32-libs...let's see when the build is finished and hopefully when wine starts
<jamiemcc> 195MB seems a bit high - a file normally eats about 1K so unless you have 200,000 files it might be too high?
<mdz> jamiemcc: I might, I have tens of thousands of emails
<mdz> 193001 files
<jamiemcc> mdz: thats a lot
<mdz> I should probably exclude my maildirs; it isn't very useful to have them indexed anyway
<jamiemcc> mdz: it seems to be indexing your emails as files though
<jamiemcc> mdz: because your email-* is very small
<mdz> jamiemcc: yes, I assumed that was normal.  is it supposed to recognize maildirs as email?
<jamiemcc> mdz: not yet - we only support evolution mbox and imap
<mdz> jamiemcc: imap? how does that work?
<jamiemcc> mdz: i would recommend adding maildirs to ignore paths in tracker-preferences
<jamiemcc> mdz: if imap files are stored locally under .evolution we index them as emails
<mdz> I've excluded them now, will see if that makes a difference
<jamiemcc> mdz suggest you do trackerd -R to reindex so that it cleans it up
<jamiemcc> you will have much smaller dbs then
<Mithrandir> seriously, does it use a gigabyte for only 300k files?
<jamiemcc> Mithrandir: no worst case (if files contain a lot of metadata)
<jamiemcc> a text file has maybe a 100bytes of metadata
<jamiemcc> an mp3 might have 1kb+
<\sh> pitti, please get rid of koctave (see bug #185989) (source and bins for hardy) thx :)
<ubotu> Launchpad bug 185989 in koctave "[REMOVAL REQUEST] koctave" [Undecided,Confirmed] https://launchpad.net/bugs/185989
<mdz> jamiemcc: changing my preferences restarted trackerd, and now it's grinding away again, "indexing in progress" "1/2 folders"
<jamiemcc> mdz: yeah its probably deleting all the files in that ignored directory
<mdz> my index just grew another 50M
<jamiemcc> mdz: if you had a ton of files there its better to reindex
<Mithrandir> jamiemcc: well, I have about 1.9M files in ~..
<mdz> ok
<mdz> Mithrandir: mostly source code? that should be fun
<jamiemcc> Mithrandir: heh
<jamiemcc> Mithrandir: its why we have the ignored folder setting
<Mithrandir> mdz: mostly emails.
<Mithrandir> I have 12 years of emails, in maildirs.
<mdz> Mithrandir: my mail from pre-2003 is compressed and archived
<mdz> because I never look at it
<jamiemcc> I guess i need to make sure tracker does not treat mail dirs as files
<mdz> jamiemcc: maybe better to exclude them until they're properly supported, if that's simpler
<jamiemcc> mdz: yeah makes sense
<\sh> jamiemcc, do you actually know what could it be, that even I disabled trackerd from my gnome-session completly, that it's re-starting...even when told not to start at all? I wonder what's the trigger is, mostly it does it after upgrading
<jamiemcc> \sh: could be activated by nautilus
<jamiemcc> \sh: disable tracker in tracker-prefs (set watch dir to something bogus)
<\sh> jamiemcc, ok..done
<pitti> \sh: koctave removed
<\sh> pitti, you rock..thx :)
<Spenser309> can anyone point me to a hal example
<pitti> seb128: oh, argh, it needs ggz-server, too
<seb128> pitti: ups
<pitti> seb128: I'll upload a new package with a fixed libdb dep and take a look
<seb128> pitti: thanks
<warp10> Heya all!
<slangasek> is anyone working on bug #184585 in gnome-mount?  this seems to happen quite regularly for me on hardy :/
<ubotu> Bug 184585 on http://launchpad.net/bugs/184585 is private
<\sh> pitti, could you un-NEW octave3.0 binaries for i386 and amd64, pls? :)
<slangasek> hrm, "private", perhaps that's its own answer...
 * ScottK mumbles something about sylpheed-claws-gtk2 stuck in dapper-backports NEW ..
<slangasek> ah, did pitti not get to that one?
<ScottK> slangasek: No.  I forgot to ask for it.
 * ScottK forget that sylpheed-claws spawns new packages at a rate of several per release.
<ScottK> forget/forgot
 * slangasek hehs
 * ScottK hopes that was funny enough to rate getting his package binary NEWed.
<slangasek> I think so. :)
<slangasek> but first I have to un-bork grub
<ScottK> Great.
<tmccrary> Does ubuntu support multiarch?
<Mithrandir> no
<tmccrary> Are there any plans to support in the near future?
<Mithrandir> not in the near future, no.  Long-term, hopefully.
<daxroc> Evening all
<daxroc> Is this the channel to discuss hardy suspected bugs ?
<LaserJock> not really, #ubuntu-bugs might be a better place or maybe #ubuntu+1
<daxroc> Thanks LaserJock
<tjaalton> slangasek: b.edge.lp.net doesn't like my sync requests (getting an Oops every time).. could you sync xserver-xorg-video-nv from unstable, there was a new bugfix release on Friday, includes the only patch in our package
<slangasek> tjaalton: any chance that b.lp.net works better than b.edge.lp.net?  I'm happy to do the sync but can't promise that my memory is longer than my todo list at the moment
<pochu> tjaalton: bug 186564
<ubotu> Launchpad bug 186564 in malone "OOPS with edge.launchpad.net while submitting a report without an attachment" [High,Fix committed] https://launchpad.net/bugs/186564
<tjaalton> slangasek: I bet it works there, will do
<tjaalton> pochu: ok, nice to know it's fixed already :)
<tjaalton> slangasek: done, u-a subscribed
<slangasek> tjaalton: cheers
<\sh> cjwatson, ping a question concerning your gpg key and the signatures on your subkey
<lamont> hrm... can one Pre-Recommends, I wonder?
<slangasek> how is that going to be different than a regular Recommends?
<slangasek> if it's a recommends, it's not enforced; so what difference if it fails to be enforced before or after unpacking? :)
<lamont> point
 * lamont wonders what the failure mode is that caused lzma to be a pre-depends of dpkg in hardy
<StevenK> lamont: calc
<ScottK2> slangasek: How's grub?  Standing up again on it's own?
<slangasek> ScottK2: yeah, I'm just about to upload my changes
<slangasek> after a morning-long foray into setting up my first lp bzr project
<ScottK2> Yummy.
<seb128> grrr tracker eating 100% CPU when the laptop is on battery
<seb128> ah, it's broken again, the applet doesn't indicate what it's doing
<lool> seb128_: lalala tracker lalala :)
<lool> seb128_: But you were right, one can get rid of the icon completely by removing all tracker packages
<cjwatson> \sh_away: pong
<cjwatson> lamont: dependencies of essential packages generally need to be pre-depends instead in order to enforce that the package works even while unconfigured
<cjwatson> hence why coreutils and libc6 are pre-depends too
<lamont> cjwatson: yeah. OK.
<lamont> just makes what I'm banging my head against more painful
<cjwatson> (gzip and bzip2 aren't there because dpkg links statically against zlib and libbz2. you probably know this but I mention it for completeness.)
 * lamont needs an lzma packaged package
<ScottK2> lamont: I think python-qt4 is, but I'm not certain.
<lamont> er. source or bin?
<slangasek> nothing in the archive will be.  I think the test subject for lzma is OOo...
<lamont> ah, ok
<lamont> DOH
<lamont> slangasek: thank you for the cluebat
<slangasek> lamont: for pointing out that there are no such packages in the archive because we're waiting on what you're doing? :-)
<lamont> got it in one
 * LaserJock wondered
<lamont> slangasek: so, um, my python-apt is not for non-english-speakers. :-P
<cjwatson> grab some random small package and do dh_builddeb -- -Zlzma on it
<slangasek> lamont: ...ok?
<lamont> dh_builddeb -Zlzma
<lamont> Unknown option: Z
<lamont> cjwatson: please tell me we don't need debhelper for this... that's way scary
<slangasek> double-dash
<lamont> oh
<slangasek> you can do it with dpkg-deb too, I suppose?
<cjwatson> indeed
<cjwatson> dh_builddeb -- OPTIONS-TO-DPKG-DEB
<lamont> x - data.tar.lzma
<lamont> Unpacking ed (from .../lamont/ed_0.7-1build1_i386.deb) ...
<lamont> Setting up ed (0.7-1build1) ...
<lamont> win
 * lamont finds a certain amount of humor in gutsy's dpkg + lzma being able to unpack the .deb too
<lamont> slangasek: in the end, my solution to python-distutils-extra was, um, a crowbar.
<lamont> if someone cares, they can give me a patch. :-P
<slangasek> I think caring about that is your department, not ours :)
<lamont> given the target audience, ENOPROBLEM
<TheMuso> cjwatson: Thanks for the ubuntustudio seed merge, however joejaxx could have easily taken care of it.
 * ScottK idly mentions that someone earlier said something about NEWing something in dapper-backports after grub was fixed ...
<cjwatson> TheMuso: oh, I was just merging everything at once, not specifically ubuntustudio
<ScottK> ... and then runs off to untangle the necklace his 4 year old just handed him.
<TheMuso> cjwatson: Fair enough.
<cjwatson> due to being up to my armpits in seed reorg stuff at the moment
<lamont> ScottK: btw, 2.5.0-1 uploaded to experimental if you want to have fun with it
<lamont> (and like see if you see any major b0rkage, etc)
 * milli will try out 2.5.0-1, thanks
<lamont>    postfix |    2.5.0-1 |  experimental | source, i386, sparc
<lamont> milli: oh, thanks.
<milli> ã©ããããã¾ãã¦
<lamont> cjwatson: slangasek: lest you think we're too far along, there is still a bit of testing to make sure we didn't break anything horribly elsewhere, etc, etc.
<milli> although best I can do is build from source, it seems..
<lamont> milli: yeah.  let me get you a gutsy version?
<milli> feisty :)
<lamont> milli: SLACKER
<milli> on the main mail server..
<milli> I resemble that remark!
 * lamont builds gutsy for his home machine first
 * lamont just nuked the local feisty mirror, you see.
 * milli is grabbing source for feisty box
<lamont> ok.  just please remember to tweak changelog to say '2.5.0-1~feisty1', mk?
<milli> vi changelog...
<lamont> apt-get install devscripts; dch -i
<lamont> or you could just vi
<lamont> or we could read the manpage and see how to tell dch to get the ~feisty1 version without changing it in vi
<lamont> ii  postfix                                    2.5.0~rc2-0~gutsy1                   High-performance mail transport agent
<lamont> heh.  I think this should wokr
<ScottK2> dch -v
 * lamont wanders off
<jdong> urr.... launchpad is not accepting my bug report?
 * jdong screams scandal
<crimsun> jdong: see the topic of #launchpad
<jdong> crimsun: thanks :)
<crimsun> yw
<jdong> kk tx gl hf gg nr20 tvb no zerg
<ScottK> lamont: I'm going to throw Postfix 2.5.0 up in my ppa.
 * LaserJock wonders if ScottK will throw it hard enough to break
<ScottK> We're about to find out.
<StevenK> pitti: I've run ./update for -meta and it's removing restricted-managed -- baaaaad?
<cjwatson> restricted-manager got renamed
<jdong> aww I was hoping for a more sensational explanation :(
<StevenK> cjwatson: Ahh. What's the new name, so I can check it still exists?
<TheMuso> jockey-gtk/jockey-common
<StevenK> Jockey? Oh man.
<bigon> mmm I have a question shouldn't libasound2-plugins be installed by default to make pulseaudio works by default on hardy?
<StevenK> Which isn't in debian/control
<TheMuso> bigon: Um, pulseaudio gets installed and gets used by default, without the need for that package.
<TheMuso> bigon: That package has a plugin to allow alsa apps to be sent through pulseaudio however.
<StevenK> cjwatson: Should I be worried that jockey-{gtk,common} isn't in debian/control of -meta?
<bigon> TheMuso: aplay doesn't work without it
<TheMuso> bigon: hrm. I'd need to confirm that myself, which I currently can't do.
<crimsun> is pulseaudio-utils in the desktop seed?
<crimsun> if so, aplay "not working" is moot, since you can just use paplay.
<lamont> Unable to find distroseries: fiesty
<lamont> ScottK: it's spelled 'fisty'
<lamont> or something liek that
<cjwatson> StevenK: sounds odd, worth checking
<bigon> paplay is not installed here
<ScottK> Hmmm
<cjwatson> StevenK: should be showing up in desktop-recommends or whatever it is
<crimsun> bigon: then pulseaudio-utils needs to be massaged in[to] the seeds.
<bigon> ok
<ScottK> i before e, except after c.  I know.
<StevenK> cjwatson: Interesting. jockey-gtk is in desktop-recommends-i386, but not in debian/control
 * ScottK tries again.
<cjwatson> StevenK: err. did you look at debian/control, or are you just grepping? :-)
<cjwatson> StevenK: it uses substvars rather extensively ...
<StevenK> cjwatson: I was just grep'ing, so I'm a dork. :-)
<cjwatson> StevenK: that's a relief ;-)
<lbathnc> what programing language should one learn to program in Ubuntu
<Nafallo> python
<ScottK> lamont: It's in my PPA for dapper/edgy/feisty (now spelled correctly)/gutsy.  Now I wait to see if it builds.
<ToyKeeper> Heh, generally a good choice anyway...  easy to learn, yet has a high abstraction ceiling.  :)
 * LaserJock recommends C++ :-)
<LaserJock> just to be different
<lamont> ScottK: it'll need to have had s/binary:Version/Source-Version/ in debian/control, as well as the db hackery
<lbathnc> why choose Ubuntu over Fedora core 8
<lamont> LaserJock: my coding is a mashup of C, python, and sh, actually
<lamont> sh for trivial stuff, python when it gets a bit more complex, and C when it has to be.
<lamont> or I'm working on a package.
<LaserJock> lamont: that's about what I do, except I guess s/C/C++/ but that's sort of trivial
<lamont> C++ is on my list of 'gonna learn that thar thang someday'
<lamont> actually started reading a book a little.
<milli> C++ ain't that hard
<lbathnc> why C++ over python
#ubuntu-devel 2008-01-29
<Mithrandir> lamont: mashup of C, python and sh.. that explains a lot of your code. :-P
<Mithrandir> "hm, didn't work, where's the big hammer?"
<Nafallo> lol
<LaserJock> lbathnc: it's more of using the proper tool for the job
<cjwatson> lbathnc: this channel is for coordination of Ubuntu development, and is not really the best place for introductory questions; https://wiki.ubuntu.com/ContributeToUbuntu might be a place to start, though you should also be able to Google for things like comparisons between programming languages
<lamont> Mithrandir: rock.
<cjwatson> or indeed for comparisons between distributions
<Mithrandir> lamont: yeah, I assume you can use a rock as a hammer. :-D
<lamont> Mithrandir: "because once you have tac-nukes, everything begins to look like a small city"
<Mithrandir> indeed
<slangasek> Mithrandir: next you'll tell me that lamont's igloo/bungalow/skyscraper/sod house is not the height of avant garde architecture
<Mithrandir> slangasek: his rock cave, you mean?  It's got wireless, though
<Mithrandir> and ia64-powered heating.
<Nafallo> :-)
<ScottK> lamont: Thanks.
<ScottK> lamont: It looks like you didn't do my IPv6 localhost patch yet?
<lamont> ScottK: didn't do any real patches.
<ScottK> OK.  Makes sense for the first one.
<lamont> I need to run into town now, either toss me email or remind me when I'm back online in a couple 3 hours
<ScottK> Will do.
<cjwatson> mr_pouit: could you please merge seed changes properly, using 'bzr merge', rather than by copy-and-paste?
<cjwatson> mr_pouit: if you don't know how, ask :)
<cjwatson> mr_pouit: (Doing it the way you do it causes unnecessary conflicts and means that other people typically end up redoing part of the work later.)
 * LaserJock looks at his seed change and hopes it was ok
<cjwatson> LaserJock: which one?
<cjwatson> LaserJock: r681 in edubuntu.hardy from six days ago or so?
<cjwatson> LaserJock: if so, looks fine
<cjwatson> though you might want to use 'bzr whoami' to set a real name as well as an e-mail address
<LaserJock> bah
<LaserJock> thanks
<articpenguin3800> is it too early to suggest features for hardy +1
<ion_> On IRC, theyâll most likely be lost in the noise. Better write a spec at launchpad, or something.
<articpenguin3800> where would i write it?
<ion_> https://blueprints.launchpad.net/ubuntu/
 * Hobbsee waves
<LaserJock> hi Hobbsee
<bddebian> Hi Hobbsee, LaserJock
<zul> hey Hobbsee
<Hobbsee> hiya zul!
 * lamont wanders back in
<lamont> bouncy bouncy hobbse
<lamont> hobbsee, even
<ScottK> Tab completion sucks when the person isn't on.
<bddebian> heh
<lamont> ScottK: it does at that
 * lamont blames Hobbsee 
 * Hobbsee blames lamont back
<lamont> Hobbsee: how's things?
<Hobbsee> doing OK
 * Hobbsee has the day off - woo!
<ScottK> slangasek: Thank you for the NEWing (yeah.  clamav on dapper-backports is done)!
<slangasek> ScottK: no problem
<mdomsch> s
<mike__> Does anyone have a make file for a usb_skeleton.c project?
<warp10> Heya all!
<dholbach> good morning
<\sh> pitti, I filed a removal request for octave2.1/2.9 (bug #186944) I'm dealing with the other package uploads and syncs this afternoon when I'm coming back from city shopping :) just for reference :)
<ubotu> Launchpad bug 186944 in octave2.9 "[REMOVAL REQUEST] octave2.9 and octave2.1" [Wishlist,Confirmed] https://launchpad.net/bugs/186944
<stgraber> moin
<superm1> bryce, ping
<Kano> hi, what is the tool used to create the initramfs for the desktop cd?
<superm1> Kano, the same tool that creates the initramfs on normal systems.  you may want to take a look at livecd-rootfs to learn more about its build process
<Kano> but you nee dmore hooks
<superm1> yes, see what casper adds
<Kano> so still named caspar?
<superm1> yeah
<Kano> but thats universe?
<superm1> and additionally there are some more hooks added in ubiquity-casper
<Kano> not main
<superm1> capser is in main
<superm1> http://paste.ubuntu.com/3968/
<Kano> ok, wrote it wrong
<Kano> there are even .swp files in caspar...
<Kano> ./ubiquity-hooks/.30accessibility.swp
<superm1> i'd imagine that's a mistake
<superm1> but you'd have to check with colin on that
<Kano> how about modding it the same way like live-initramfs to support union=... option
<superm1> not too sure on that, sorry
<Kano> thats not a big diff
<Kano> you basically have to change unionfs 2 times to a var, add the unionfs cheatcode and add aufs as hook
<superm1> aufs hasn't been added in yet to our kernel
<superm1> laga was going to work on a patch for that
<Kano> what i currently dont get is that network-manager works with unionfs on hardy but not when i use unionfs with live-helper
<superm1> live-helper on debian?
<ln-> keescook: ping. can you tell me what "Declined for Dapper by Kees Cook" means in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631 ?
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed]
<Kano> superm1: i use live helper backported from sid to etch + ubuntu kernel compiled on etch
<superm1> Kano, well i was gonna say maybe missing some of our (hefty) unionfs patchset, but hmph
<Kano> well i can patch casper with ease to support aufs
<superm1> i'm sure everyone would be very open to that
<superm1> additionally if you wanted to do the patch to add aufs support, i don't believe laga started it yet, but you can check with him
<Aloha> whats this channel for? if not application development?
<soren> Ubuntu development
<soren> Development *of* Ubuntu, not *on* Ubuntu.
<Aloha> like advocacy?
<soren> Er.. no.
<soren> Development.
<soren> Y'know. Computers and stuff.
<soren> :)
<Aloha> like ubuntu core?
 * Aloha is confused
<Kano> superm1: compared to live-initramfs caspar has really no options...
<Kano> no toram, nothing
<persia> Aloha: The development of the applications that make up Ubuntu, as opposed to the development of applications that run on Ubuntu.
<superm1> Kano, yeah its a bit specialized for the purposes its used for
<Aloha> Aloha, can you give me an application for an example?
<Aloha> oops
<Aloha> s/Aloha/persia/
<Aloha> heh
<persia> Aloha: X
<Aloha> persia, gotcha so like the packaging of the main upstream components?
<persia> Right.
<Aloha> so like the opposite of MOTU kinda
<soren> I would certainly not call it opposite. They complement each other.
<Aloha> well i mean in the case that MOTU is for extra stuff while devel is for core stuff. opposite was the wrong word
<soren> That's sort of the idea, yes.
<Kano> superm1: what a huge patch ;)
<Kano>  casper                |   12 ++++++++++--
<Kano>  casper-bottom/12fstab |    2 +-
<Kano>  2 files changed, 11 insertions(+), 3 deletions(-)
<superm1> :), well if you want to publish that branch somewhere, someone in ~ubuntu-core-dev can merge and add that patch
<Kano> well i prefer to try that first
<superm1> well of  course :)
<Kano> but the patch should be correct
<Kano> hmm one thing is missing
<Kano> i forgot the hook
<Kano> but thats only one line more
<Kano> what package is used to add unionfs-tools?
<Kano> http://kanotix.com/files/thorhammer/updates/casper/casper-aufs.patch
<Kano> to casper this should be enough
<superm1> Kano, I believe just the 'unionfs' package
<superm1> its in universe
<Kano> hmm
<Kano> maybe they dont need it
<Kano> as they only use mount
<pitti> Good morning
<Kano> btw. did you notice that ntfs-3g was updated... i updated my package yesterday
<pitti> \sh_away: octave is already NEWed
<pitti> ScottK: just looked, apparently someone took care of sylpheed in dapper-backports NEW
<pitti> \sh_away: old octaves removed and blacklisted
<Kano> new ntfs-3g is independend of fuse, as it has built-in fuse-lite
<Kano> btw. fuse-utils would be too old in hardy, as it would need 2.7.2 when you want to use external fuse
<Kano> http://www.ntfs-3g.org/releases.html
<Kano> #
<Kano> # Fix: the SIGTERM signal may caused deadlock which could block for instance the shutdown process. If NTFS-3G is used with an external FUSE library, which is not the default, then FUSE 2.7.2 package is required.
<pitti> carlos: so I assume it's ok when I add code to langpack-o-matic to ignore all country specific locales except en_*, zh_*, and pt_BR?
<carlos> pitti: yeah, please. I will tell you when Launchpad is fixed to do it directly
<Kano> well maybe the panic message could use the var too
<Kano> updated the patch
<superm1> Kano, i posted the url to it in the installer channel.  when one of the other folks in there steps in they'll get a chance to look at it.
<Kano> well you need aufs in lum
<superm1> yeah like i said laga is supposed to work on that
<superm1> :)
<Kano> yesterday aufs cvs was updated
<geser> good morning
<tkamppeter> pitti, hi
<Kano> superm1: that casper seems to be broken, it does not copy the casper script itself in the hook
<Kano> only function and helper
<Kano> has your initramfs that implicit?
<cjwatson> Kano: initramfs-tools copies everything in /usr/share/initramfs-tools/scripts by default; the explicit copy of casper-functions and casper-helpers is in fact unnecessary
<cjwatson> your patch looks fine but I'll let Evan look at it
<MacSlow> Amaranth, https://answers.edge.launchpad.net/launchpad/+question/19394 did you suggest that?
<Kano> cjwatson: the problem is the initramfs utils from debian did not add casper at all...
<Kano> only the casper.conf somehow
<MacSlow> Amaranth, I think the term "ubuntu-desktop-effects" is meant to be a more general umbrella for things like window-level effects (which means compiz mostly) and at some point toolkit-level effects.
<cjwatson> Kano: I can't help you with the initramfs utilities from Debian
<Amaranth> MacSlow: If the team should be kept around the people currently on it should be purged
<cjwatson> perhaps they broke compatibility
<Amaranth> MacSlow: It was actually originally "people who help with beryl even though its not in the repo" but it ballooned into "i like beryl, why not join?"
<Amaranth> Because it was originally open membership
<MacSlow> Amaranth, while we don't have toolkit-level effects yet to "justify" this umbrella-term, we certainly will in some not too distant future.
<Kano> cjwatson: i guess i know the problem..
<Kano> busybox-initramfs
<Kano> is a depend in a special version
<Kano> and thats not installable...
<Kano> will add that and see..
<cjwatson> yeah, IIRC busybox is packaged differently in Debian
<Kano> /tmp/buildd/busybox-1.1.3/networking/libiproute/ipaddress.c:25:27: error: linux/if_addr.h: No such file or directory
<Kano> funny
<Kano> what stupid build-dep do you have got in u
<cjwatson> Kano: the kernel headers are hardly an exotic build-dependency; indeed, they're in build-essential
<cjwatson> (linux-libc-dev)
<Kano> when does somebody add hardy to search for files template in packages.ubuntu.com
<Kano> cjwatson: hmm that header does not seem to be in etch
<cjwatson> Kano: packages.ubuntu.com is a third-party service, not provided by us. You should mail the address linked to at the top of the page.
<Kano> how about using the debian busybox package instead as depend?
<cjwatson> linux-kernel-headers (the old name) in etch doesn't seem to have linux/if_addr.h; I assume you need to back out the changes in the Ubuntu diff which were needed to cope with newer kernels
<cjwatson> I rather strongly suspect that Debian's busybox doesn't have all the necessary bits (e.g. awk, the mount patches I did for FUSE, pidof, etc.) but you are of course free to find that out for yourself ...
<Kano> also why do you add busybox-initramfs depends to casper, usually busybox is a depend of initramfs-tools?
<cjwatson> different (smaller) build
<cjwatson> it hardly matters; busybox-initramfs is a dependency of initramfs-tools too
<cjwatson> (note, we did all this *before* Debian, you should be asking why they changed it ;-))
<cjwatson> the casper dep on busybox-initramfs is because it needs newer features in the specified version
<Kano> which ones
<cjwatson> we document this in the changelog so that you don't have to ask the developers
<Kano> well it would be more to tell if the standard debian busybox has em or not
<Kano> i think backporting caspar is not that easy...
<Kano> has ubuntu something like live-helper to create images from scatch easyly?
<cjwatson> Kano: livecd-rootfs is what we use
<Kano> but that creates only the rootfs
<Kano> isnt there a tool that combines all into an iso?
<saispo> hi all
<cjwatson> seb128: could you (get somebody to) have a look at bug 184137?
<ubotu> Launchpad bug 184137 in gtk+2.0 "please backport support for switching input method on the fly" [Undecided,New] https://launchpad.net/bugs/184137
<seb128> cjwatson: oh, right
<seb128> lool: ^
<seb128> cjwatson: lool started to work on the new version today,
<cjwatson> cool, thanks
<Ubulette> slangasek, is there anything blocking bug 185178 ? (I see you've been assigned to it)
<ubotu> Launchpad bug 185178 in libpng "Please sponsor libpng 1.2.24" [Undecided,New] https://launchpad.net/bugs/185178
<pochu> soren: thanks for the gtk-vnc upload
<soren> pochu: Thanks for preparing it! :)
<soren> pitti: Didn't we agree to /not/ make "Erase disk" the default when using the auto-crypto-lvm thing?
<TheMuso> cjwatson: evand managed to get the a11y stuff done in ubiquity last week during the sprint, but since the privelages changes still need to go in, it can't properly be tested yet. However, when testing is possible, and issues need fixing, I will endever to fix these myself.
<TheMuso> I'll reply to the list, so there is a paper trail.
<Kano> how about using icedtea for java (because it has a amd64 firefox plugin)?
<Kano> hmm in universe
<mok0> Is there a 32 bits libg2c for hardy-amd64?
<mok0> Ah, lib32g2c0...
<DktrKranz> pitti, regarding https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev2=81&rev1=80, does it mean low severity bugs could be sru-worthy too?
<tjaalton> asac: the latest version of n-m works fine here, the previous one failed completely :)
<cjwatson> soren: erase disk is the default again because Debian implemented a cancel button
<cjwatson> TheMuso: right, I just mentioned for completeness, bearing in mind that people may be reading ubuntu-installer@ who weren't at the sprint :)
<TheMuso> cjwatson: yep fair enough
<asac> tjaalton: the previously started to early for some ... thanks for the info
<tjaalton> asac: yeah, thanks for packaging the snapshow, now I can test ppp support
<tjaalton> uh, -shot
<asac> tjaalton: let me know
<ogra> asac, my NM misbehaves :/
<asac> ogra: define misbehave? like what i do all day:)?
<ogra> doesnt let me connect to the most powerful network on this floor but insists on connecting to the one in the basement
<ogra> which indeed isnt stable over time due to the fact that the signal needs to go through three steel concrete ceilings
<asac> ogra: does NM tell you that it found a better connection?
<ogra> no, it just ignores the strong one
<asac> whats the reason stated in syslog (when nm gives up)?
<asac> just timed out?
<ogra> i wonder if i connected to a net called "linksys" during travel recently and it has a wrong key ...
<asac> ogra: you are still using wep?
<ogra> yes
<asac> if so, that might indeed be the case
<Kano> tjaalton: do you really want to close the X700 SE bug?
<ogra> and actually i used 64Bit ... now the ui says 40Bit
<asac> wep doesn't tell anythinga bout why something isn't working ... previously nm assumed that you have wrong key ... but people complained iirc
<Kano> when there is no fix in the mesa -4 debian package
<asac> so maybe they switched to prefer the assumption that you cannot connect
<ogra> ah
<asac> look in keyring
<tjaalton> Kano: sure is
<tjaalton> oh crap
<Kano> tjaalton: it is not, you are blind
<asac> ogra: and look whether you have something in /system/networking/
<asac> in gconf
<ogra> i'll just remnove the linksys network with gconf-editor ;)
<ogra> right, did that before
<tjaalton> Kano: no, just that the -4 changelog is missing
 * ogra considers giving his networks proper names now :)
<tjaalton> Kano: the patch is upstream, and the package contains it
<asac> ogra: the key is in the keyring
<ogra> i wonder how many WLANs called "default" exist in the world :)
<asac> ogra: i don't even know if thats a problem :)
<asac> ogra: but you should switch to wpa
<asac> most likely your router supports it
<Kano> tjaalton: but when i apply the patch it works... and it was not there before and it is not in patches dir
<Kano> so where should it be?
<tjaalton> Kano: in the diff...
<tjaalton> it's maintained in git you know
<ogra> asac, half of my APs are so old they dont know WPA
<tjaalton> Kano: "Update to mesa_7_0_branch head (commit 48ae5cf0)."
<asac> ogra: dump them :) ... a new one costs 25 EUR or something similar ridiculous
<Kano> tjaalton: when it is in the diff then why can i apply it?
<ogra> asac, indeed
<Kano> tjaalton: you can not find the comment,thats impossible
<ogra> asac, no way ... still switches back
<ogra> what bothers me here is that i dont even get a new question for the key
<tjaalton> Kano: ok, so it's not in the stable branch
<tjaalton> duh
<Kano> tjaalton: i wrote that it will be in NEXT version not in stable
<asac> ogra: show me syslog
<tjaalton> Kano: next version will be 7.0.3, please be more specific next time :)
<asac> ogra: http://paste.ubuntu.com <- remember
<ogra> asac, !
<Kano> sure next is 7.0.3 your first comment was ok,but you wrote that 7.0.2 would fix it in the bugreport
<tjaalton> Kano: nitpicking, I already said that it didn't include the changelog from -4
<ogra> asac, http://paste.ubuntu.com/3971/
<Kano> tjaalton: just add the patch for next upload
<Kano> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/151974
<ubotu> Launchpad bug 151974 in mesa "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Fix committed]
<tjaalton> Kano: why not ask upstream to include it in the stable branch instead?
<Kano> thats not fixed till then
<Kano> you can not fix it in the past
<tjaalton> why?
<Kano> 7.0.3 will have it
<ogra> there is nothing else apart from some dhclient noise
<Kano> tjaalton: the orig file will never change
<Kano> so add it to patches dir
<asac> ogra: thats a successful connect ... you need to provide more context ;)
<tjaalton> Kano: you don't seem to understand how the XSF packages are maintained...
<Kano> tjaalton:it would be highly dangerous when you upload a modified .orig file
<Kano> add a patch to the dir and you are done
<Kano> whats your problem?
<tjaalton> Kano: changes are pulled from git, and the changes are visible from the diff
<Kano> tjaalton: well it is not in the diff
<tjaalton> you just pointed out that the patch _will_not_ be in 7.0.3 (which the current version is ubuntu is tracking)
<tjaalton> right
<tjaalton> and I reopened the bug
<ogra> asac, http://paste.ubuntu.com/3972/
<ogra> asac, linksys (the one i want) doesnt even show up there
<asac> ogra: do a tail -f /var/log/syslog > /tmp/log ... then press on linksys
<asac> does it actually spin?
<ogra> yes
<ogra> oh
<asac> ;)
<ogra> its not in the list in the UI anymore
<ogra> i cant select it
<ogra> hmm
<ogra> the classmate sees it though
<ogra> (same NM version)
<ogra> not back after restarting the applet ...
<ogra> sigh
<ogra> oh
<ogra> now its there again
<ogra> that seems wonky
<Kano> tjaalton: why do you look at pre 7.0.3 changes and upload 7.0.2?
<ogra> asac, http://paste.ubuntu.com/3973/
<asac> ogra: ok it asks you for a key?
<ogra> nope
<tjaalton> Kano: we just do our changes on top of debian, so what's the point?
<asac> ok according to log it receives a secret ... so most likely in your keyring
<asac> ogra: have you removed that?
<asac> 1. Jan 29 13:55:19 laptop NetworkManager: <info>  Activation (wlan0_rename/wireless): access point 'Auto linksys' has security, but secrets are required.
<asac> 2. Jan 29 13:55:19 laptop NetworkManager: <info>  Activation (wlan0_rename/wireless): connection 'Auto linksys' has security, and secrets exist.  No new secrets needed.
<ogra> i removed all data related to linksys in /system/networking in gconf
<asac> (line 31)
<asac> ogra: you need to remove it from keyring
<asac> gconf doesn't have any secrets
<asac> ogra: gnome-keyring-manager :)
<ogra> asac, no change
<asac> ogra: you are stiill not asked for a key?
<ogra> yup
<ogra> it silently switches to netgear
<asac> kill nm-applet ... remove gconf stuff ... remove key ... restart NM ... start nm-applet
<asac> it _should_ ask you for a key
<ogra> nope
<ogra> same behavior
<ogra> (the classmate uses that network right away and sits about 20cm away from the other laptop that exposes the prob)
<ogra> and there is nothing related to linksys in gconf or the keyring  ...
<ogra> not even after a connection attempt
<ogra> does dbus cache such data ?
<ogra> s NM would get it out of a cache
<ogra> *so
 * ogra tries a reboot with all the data deleted
<asac> ogra: no idea ... sounds like a bug somewhere else (like keyring doesn't wipe cache et al)
<ogra1> asac, no changes
<asac> ogra1: strange ... you sure there is no key in the keyring atm?
<ogra1> yes
<ogra1> 100%
<ogra1> at least not in the ui
<ogra1> not sure there is another way to acce3ss the keyring data
<asac> and nm still tells in syslog that it has a secret avail?=
<ogra1> its also not listed in gconf anymore
<asac> scary
<asac> maybe paste syslog again ... so i can check that its not something else now
<ogra1> Jan 29 14:15:11 laptop NetworkManager: <info>  Activation (wlan0_rename/wireless): connection 'Auto linksys' has security, and secrets exist.  No
<ogra1> new secrets needed.
<pitti> soren: we did, but nowadays the installer should allow you to cancel it (which is better IMHO)
<ogra1> thats the last attempt
<pitti> DktrKranz: yes, if they have trivial and obvious patches, and the regression potential is low
<ogra1> Jan 29 14:15:12 laptop NetworkManager: <info>  Activation (wlan0_rename/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wirele
<ogra1> ss network 'linksys'.
<ogra1> hmm, intresting
<soren> pitti: Oh, does it? TBH, I didn't check, I just had a friend complain to me about it,.
<pitti> soren: it should, at least; if not, that's a bug
<soren> pitti: Noted. Thanks.
<ogra1> http://paste.ubuntu.com/3974/
<ogra1> asac ^^^
<ogra1> Jan 29 14:15:43 laptop NetworkManager: <info>  Activation (wlan0_rename) failed for access point (linksys)
<ogra1> Jan 29 14:15:43 laptop NetworkManager: <info>  Marking connection 'Auto linksys' invalid.
<ogra1> i dont see why though
<asac> ogra1: it5 still tells you that it has secrets
<ogra1> hmm, beyond the fact that dhcp doesnt seem to get through ... weird ...
<asac> ogra1: "connection 'Auto linksys' has security, and secrets exist."
<ogra1> oh, right
<ogra1> i looked to far down
<ogra1> its probably my system that wants me to work in the basement rather than in the office :P
 * ogra1 pokes evo in the guts for that silly recovery dialog
<asac> ogra1: can you see a passphrase in keyring now?
<ogra1> nope
<ogra1> the other two networks are theeeeeeeeeeeeeeeeeeeeeeeeeeeeeeere though
<ogra1> oops
 * ogra1 pokes x2x for being evil
<ScottK> pitti: Yes.  slangasek took care of sylpheed-claws-gtk2 in dapper-backports last night.  Thanks for looking.
<ogra1> asac, success !
<dktrkranz> pitti: thanks.
<asac> ogra1: he?
<ogra1> asac, selecting "connect to a different network" from the nm menu worked
<ogra1> before i tried the "create new network" option, that didnt
<asac> strange
<asac> he?
<ogra1> yeah
<asac> so is your AP hidden or what?
<ogra1> nope
<asac> (create new network tries to create "ad-hoc")
<ogra1> as i said the other wlan clients here work fine
<ogra1> hmm, now i have a small arrow in the menu next to linksys
<ogra1> popping up a menu saying "linksys Auto" twice
<ogra1> err
<asac> ogra1: thats two different bssid
<ogra1> Auto linksys
<ogra1> intresting
<asac> you can now force NM to stick to one if you have multiple bssids with the same essid
<ogra1> well, i dont have more than one here
<asac> maybe you have a neighbour that you don't know about?
<ogra1> hmm
<asac> ogra1: please look in gconf /system/networking/connections
<asac> are there now two connections for linksys?
<ogra1> if i wouldnt have to reconfigure half the world i'd just change the name right away
<asac> whats the difference?
<sjoerd> it really is segv day today
<ogra1> lol
<ogra1> there is nothing in there
<sjoerd> hrm, wrong channel
<ogra1> (no linksys at least)
<ogra1> oh, wait .. just in "networks" there is nothing
<ogra1> seems i have two new entries in "connections"
 * ogra1 deletes all entries and starts over
<asac> ogra1: i remember that nm tried to avoid default essids ... because they where too common. but it doesn't look like you are hit by that from your log
<asac> just a wrong key somewhere
<ogra1> i didnt evennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn look in the connections before, just in networks
<ogra1> hrm
 * ogra1 pokes x2x even more
<ogra1> that turns into an evil thing on unstable connections
<asac> ogra1: yes ... everything beneath /system/networking :)
<ogra1> heh
<ogra1> now it just connected ... no passphrase asked
<ogra1> but there is still nothing in the keyring
<ogra1> cjwatson, regarding all these recurring fuse group credentials bugs we have, how about adding a reboot notification to the package so we make sure people are actually in the fuse group after installing it
<ogra1> (especially for dapper->hardy)
<\sh> re-moins
<\sh> pitti, thx
<pitti> gpg: skipped `Ubuntu automatic language-pack builder <language-packs@ubuntu.com>': unusable secret key
<pitti> ???
<pitti> oh, I bet it expired
<cjwatson> ogra1: a reboot notification sounds wrong (should be log out/in), and it would be nice if there could be a check that the user is in the group
<cjwatson> ogra1: I also think we shouldn't incessantly nag non-admin users who shouldn't be in the group
<cjwatson> ogra1: but if you can figure out a way to satisfy all of that, go ahead
<ogra1> we dont have a log in/out notification yet, do we ?
<ogra1> all i know of is the reboot one
<cjwatson> that's just a stock notification; doesn't prevent packages from adding their own
<ogra1> k, i'll take a look
<ogra1> it just struck me that we dont even install fuse in ltsp environemnts in dapper
<ogra1> (no localdev support back then)
 * ogra1 wonders if fuse was even in main back then ... goes checking
<\sh> pitti, mind adding the libs to ia32-libs mentioned in bug #161030, when you have some time? :)
<ubotu> Launchpad bug 161030 in ia32-libs "ia32-libs is missing libcapi20 and libjack" [Wishlist,Confirmed] https://launchpad.net/bugs/161030
<ogra1> bah, all universe
<pitti> \sh: yep, I noticed the bug mail; on my list
<ogra1> (teh module was in the kernel package though iirc)
<\sh> pitti, I owe you several pints of good beer or some bottles of wine :)
 * pitti â not a wine drinker
<pitti> but mmmmm beer :)
 * \sh makes a note -> pitti => beer 
<cjwatson> soren: hmm, is it possible to get a virtual machine to boot from CD at any point other than initial creation?
<cjwatson> (virt-manager)
<soren> cjwatson: Not from virt-manager, no.
<soren> cjwatson: (yet)
<cjwatson> OK, known issue?
<soren> cjwatson: Yes.
<cjwatson> ah, bug 182050
<ubotu> Launchpad bug 182050 in virt-manager "no easy way to choose a temporary boot device" [Undecided,New] https://launchpad.net/bugs/182050
<soren> cjwatson: I'm not sure upstream considers it a bug, actually.
<soren> cjwatson: The assumption is that the CD is only meant to be used for installation.
<soren> I consider that a rather sub-optimal assumption.
<cjwatson> from the point of view of somebody doing installation testing, I agree it is extremely suboptimal ;-)
<cjwatson> perhaps you could pass that use case on to them?
<soren> I could.
<cjwatson> is there a hand-hacky way to slam the virtual machine back to the initial state?
<soren> cjwatson: Not really.
<soren> cjwatson: You might find the virtinst cli interesting, though?
<cjwatson> python-virtinst? happy to give it a go ...
<cjwatson> soren: am I supposed to install dnsmasq to get DHCP?
<soren> cjwatson: To get DHCP on a virtual network you need dnsmasq, yes.
<cjwatson> worth mentioning that in the wiki page?
<soren> cjwatson: I tend to use static addresses on virtual networks and otherwise hook them up to a bridge.
<soren> cjwatson: Point.
<cjwatson> with regard to hand-hacky ways to boot the VM from CD again, this is necessary in order to test anything interesting with partitioning scenarios that involve a non-blank disk
<cjwatson> I'd be happy (for now) with just editing some configuration file or something
<soren> cjwatson: Well, you can invoke kvm from the commandline if you like. You just lose the ability to detach and reattach as easily as when using libvirt.
<soren> cjwatson: If you're used to qemu, you should feel at home with kvm's cli as well.
<soren> cjwatson: "qemu-img create 4G hda.img ; kvm -cdrom foo.iso -hda hda.img -m 1024" or whatnot.
<cjwatson> mm, I'd be a lot happier with virt-manager if I can get it to play nicely
<\sh> pitti, uploaded all packages needing changes for octave3.0 ... it's time to sync the rest...
<pitti> \sh: great
<\sh> pitti, should I file LP reports, or just give you the src pkg names and versions?
<pitti> \sh: isn't there already a bug about the octave transition?
<pitti> \sh: if you put the list there (or add appropriate tasks), that would be best
<\sh> pitti, yes there is...bug #185959 ..
<ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] https://launchpad.net/bugs/185959
<\sh> pitti, all packages which are "confirmed" can be synced now...all "wontfix" don't do anything with them, the others are "fix released" and already uploaded...
<\sh> pitti, changelogs are in the comments
 * \sh hates phonecalls where people are telling him to buy a service which costs more money then the service he has already
<slangasek> Ubulette: I discussed that bug with a few people during the distro sprint last week; it seems that the diff introduces a patch for a non-standard extension that's not been accepted by libpng upstream and has been rejected by the standards body
<pitti> \sh: great, thanks
<slangasek> Ubulette: so I'm not really comfortable with introducing that as an Ubuntu-local diff; I'll follow up to the bug with this
<\sh> pitti, no thank you :)
<xivulon> TheMuso I am designing an accessibility page for wubi
<xivulon> would like to know if the boot options in ubuntu are mutually exclusive
<xivulon> so if I boot with v1 v3 m1 m2 which one ends up being active?
<cbx33> hey guys, anyone seen the python-samba support since feisty?
<pitti> carlos: can you please mark the full export on https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs as used?
<pitti> carlos: (sorry, forgot to ask earlier)
<carlos> pitti: sure
<carlos> pitti: done
<pitti> carlos: thanks
<carlos> np
<cjwatson> ogra1,mr_pouit,joejaxx: would you organise updates and uploads of edubuntu-meta, xubuntu-meta, and ubuntustudio-meta respectively?
<cjwatson> (system-config-printer -> system-config-printer-gnome, required for installability)
<ogra1> do i need to merge the seeds still ?
<slangasek> cbx33: python-samba was deprecated upstream due to lack of maintainer
<cbx33> slangasek, :(
<cbx33> damn it
<cbx33> and I really needed that too
<cbx33> I guess I'll have to grab the source
<cbx33> I know there was a security risk with it
<cbx33> but that's damn inconveinient
<slangasek> not a security risk, it was a maintenance problem; the code would simply stop building from source randomly with upstream point releases, because the code wasn't being test-built and had no upstream maintainer
<cbx33> :(
<cbx33> slangasek, ok....any thing else similar
<cjwatson> ogra1: oh, also, I took edubuntu-addon-light out of ship-addon as it depends on XFCE stuff which is now there
* slangasek changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 4 | Hardy Alpha 3 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> ogra1: no, you don't need to merge the seeds
<ogra1> oki
<ogra1> cjwatson, we missed to discuss consolekit integration in ssh :/
<cjwatson> ogra1: any references I can read for context?
<ogra1> i'll assemble a mail describing the prob ...
<cjwatson> thanks
<cjwatson> does consolekit integrate with PAM at all?
<ogra1> there is a pam module
<cjwatson> still in universe apparently
<ogra1> but according to mccann who is ck upstream its not working with ssh X sessions
<ogra1> (i suspect due to privilege separation)
<cjwatson> privsep and PAM is often an issue depending on exactly how the module is structured
<ogra1> right
<ogra1> his suggestion was to make ssh call ck directly like gdm does ... which sounds quite evil
<cjwatson> anyway, yeah, send me mail and I can have a look at some point
<ogra1> will do
<joejaxx> cjwatson: sure
<joejaxx> though i will need someone else to upload it as i am not motu
<joejaxx> i will see if TheMuso is not busy :)
<alex-weej> bryce: ping
<alex-weej> i think i has a bug in xorg fonts that is driving me insane can i chat for a min to figure it out?
<asac> carlos: when did you plan to work on mozilla langpacks? was it in february?
<alex-weej> asac: need testing for your NM PPA?
<carlos> asac: starting this week, yes
<carlos> asac: https://edge.launchpad.net/rosetta/+milestone/1.2.2
<asac> carlos: good ... keep me updated.
<carlos> asac: there you can see the tasks I'm planning to work on
<asac> alex-weej: your choice. it already received a good amount of testing, but more exposure is never bad :)
<alex-weej> does it support static configuration yet?
<asac> alex-weej: but please post issues to the forum thread (not yet as bugs)
<carlos> asac: it will not support ububox but Firefox or Thunderbird should work, the needed bits for ububox will be done next cycle (March)
<bryce> alex-weej: what do you need?
<alex-weej> bryce: give me 30 seconds while i finish writing this on launchpad
<alex-weej> it's a problem with dejavu sans introduced in hardy
<asac> carlos: hmm ... sounds pretty tight ... please focus on firefox 3 and xulrunner-1.9
<carlos> asac: mainly, missing feature will be multiple languages in the same package
<alex-weej> where the Italic style seems to be matching DejaVu Sans Condensed Oblique instead
<carlos> asac: is Hardy going to ship only Firefox 3 ?
<alex-weej> buit there are more problems i have discovered
<asac> carlos: yes
<carlos> asac: will it be ready at that time?
<asac> it has to be ready. we have no choice
<asac> firefox will be gone in alpha 5
<carlos> asac: anyway, we are adding infrastructure after that is just a matter of cover corner cases or specific details per package we want to support
<carlos> asac: I see
<asac> carlos: you always sound pretty optimistic ... i would really love to share that optimism :) ... but haven't seen a single thing, which scares me a bit ;)
<asac> carlos: we have a split: xulrunner-1.9 + firefox-3.0 ... upstream won't distribute split up langpacks though - so that you know
<alex-weej> bryce: https://bugs.launchpad.net/ubuntu/+bug/176392
<ubotu> Launchpad bug 176392 in ubuntu ""Sans Italic" is noticably thinner than "Sans"" [Undecided,Confirmed]
<carlos> asac: my only tasks for this cycle is Firefox (or at least bigger tasks to work on) so I would say it's my main focus :-)
<asac> sounds good. but ubufox is more important as it doesn't have any translations. firefox i could manually do in worst case :)
<alex-weej> bryce: and there's a simple HTML test case on there for you to try
<alex-weej> http://launchpadlibrarian.net/11623398/test.html
<asac> carlos: anyway ... start soonish ... then all will be fine i guess
<carlos> yeah
<bryce> alex-weej: hmm, I'll see if I can recreate the issue myself
<alex-weej> asac: does it support static config yet? i'm still using old-style configuration (and it doesn't come up on boot, i have to restart the networking service every time - go figure)
<asac> alex-weej: give it a try.
<asac> i haven't tested ... you might need to start the connection editor by hand
<asac> alex-weej: hmmm doesn't look like the configuration dialog is functional yet
<asac> you might be able to do it by manually tweaking gconf settings though
<bryce> alex-weej: meanwhile, can you look into where we need to make a configuration change?  Font issues generally have not been a priority for me so I'm not certain about changes needed with them.
<alex-weej> the static config is stored in gconf!??!
<alex-weej> bryce: i have really no idea -- can you at least give me a pointer? is it fontconfig or something do you think?
<asac> alex-weej: well ... if the user configures it yes ... the system config will be read from interfaces
<alex-weej> you are the xorgiest person i know
<bryce> hmm, unfortunately not fontiest ;-)
<alex-weej> do you know any fonty people?
<bryce> alex-weej: let me look into this a bit first to see if I can identify a good troubleshooting direction for you
<alex-weej> bryce: actually i've just found something that might be part of the problem -- the metadata for the dejavu sans fonts is wrong in places
<Ubulette> slangasek, i expected something like that. so what are the options ?
<alex-weej> DejaVuSansCondensed-Oblique.ttf's metadata claims it is style "Condensed Book"
<bryce> alex-weej: interesting.  I also notice that the test case displays differently on hardy vs gutsy
<alex-weej> bryce: yeah this was a new problem in hardy
<alex-weej> i noticed it as soon as i upgraded
<bryce> alex-weej: can you please post screenshots of what you're seeing, as well as (if possible) what the expected correct font rendering should look like?
<alex-weej> bryce: already done so, the pngs are on the bug
<slangasek> Ubulette: the preferred option would be to propose it upstream to the libpng maintainers first, and get a consensus that this patch is a good thing to have
<bryce> alex-weej: hmm, I'm still not certain what things *should* look like
<alex-weej> see in the test case on gutsy?
<alex-weej> :)
<alex-weej> the italic font should be selected as "DejaVu Sans" style "Oblique"
<bryce> on gutsy all three lines in the test case look identical.  Is that what it's supposed to look like?
<alex-weej> yes
<alex-weej> because the italic font is selected correctly as DejaVuSans-Oblique.ttf
<Ubulette> slangasek, providing they already rejected it 10 against 8, it's a dead end. problem is there's no valid alternative, MNG, JNG, mPNG, etc.  APNG will gain some momentum now that Firefox 3 and Opera are shipping it.
<adrock359> #ubuntu-devel
<slangasek> Ubulette: why is MNG not a valid alternative?  And what do you mean, "10 against 8"?  I don't remember libpng being maintained by a committee of 18 people...
<slangasek> (also, I don't think it's a given that a format will gain momentum just because FF and Opera support it...)
<Ubulette> slangasek, http://sourceforge.net/mailarchive/message.php?msg_name=3.0.6.32.20070420132821.012dd8e8%40mail.comcast.net
<xivulon> slangasek did you have a look at #140458?
<slangasek> Ubulette: that's about whether the PNG group adopted it as an extension, it doesn't appear to be a statement from libpng upstream that they won't support it?
<Ubulette> slangasek, FF3 will be much more popular than FF2 (easy guess) so if all win/mac users start to play with animated PNG, then APNG should gain momentum
<slangasek> Ubulette: and according to the statements in the thread you pointed me to, that would be a bad thing because it's a bad spec.
<slangasek> xivulon: not yet, sorry
<adrock358> can someone throw me a bone?   Can not write log, openpty() failed (/dev/pts not mounted?)
<xivulon> slangasek: let me know if there anything I can do to help there. I tested the script, as mentioned in the bug, and looks good to me.
<slangasek> xivulon: no, it just needs me to slot it into my schedule one of these days :)
<xivulon> slangasek: that does not need to be in the ISO build process
<adrock358> Anybody? how do i mount pts?
<slangasek> xivulon: well, as I haven't looked at it, I couldn't say :)
<MacSlow> seb128, did you happen to have a chance to look at the patch I supplied here http://bugzilla.gnome.org/show_bug.cgi?id=512649
<ubotu> Gnome bug 512649 in general "display of (metacity's) accelerator in window-action-menu" [Enhancement,Unconfirmed]
<Ubulette> slangasek, ok, i'll patch the mozilla lib then. fell free to nuke the bug. we'll have several copies of that lib. I don't mind
<MacSlow> seb128, that's part of what we need for the hardy-desktop-effects-shortcuts spec
<adrock358> ANybody?
<seb128> MacSlow: no, I'm busy packaging GNOME 2.21.90
<MacSlow> seb128, k
<MacSlow> ok
<slangasek> Ubulette: uh. have I missed something? why would any mozilla libs need patched, I thought you said ff3 was already shipping a patched libpng for this reason?
<adrock358> this is prolly a real simple Q
<Ubulette> slangasek, i'm not talking about apng related patches
<xivulon> slangsek: 140458 is about generating metalinks (partial checksums) as part of the ISO build process. But it could well be on a separate cron job processing whatever ISO is available
<xivulon> so that we do not slow down the building itself
<Ubulette> slangasek, libpng seems unmaintained anyway (both debian and ubuntu). nm, i'll revert my changes in the mozilla packages i maintain to use private copies like before.
<bryce> alex-weej: I seem to have narrowed it down; see my latest comments on the bug
<bryce> alex-weej: it is indeed fontconfig
<alex-weej> bryce: my system selects DejaVuSansCondensed-Oblique.ttf: "DejaVu Sans" "Condensed Book"
<alex-weej> it wouldn't surprise me if our /etc/fonts differed somehow -- my system has been through many upgrades and i frequently have to sort that all out
<bryce> add to bug report
<alex-weej> done
<Lutin> pitti: could you give-back delo please ?
<geser> Lutin: got the bug in pkg_create_dbgsym fixed already?
<geser> Lutin: see bug #186610 and bug #180364
<ubotu> Launchpad bug 186610 in pkg-create-dbgsym "pkg_create_dbgsym fails if objcopy can't recognize the file format" [Undecided,New] https://launchpad.net/bugs/186610
<Lutin> geser: ah, didn't know it was the problem. my bad
<ubotu> Launchpad bug 180364 in pkg-create-dbgsym "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,In progress] https://launchpad.net/bugs/180364
<Lutin> geser: thanks
<slangasek> Ubulette: being conservative about updating to new upstream versions of libpng doesn't mean it's unmaintained. rather the contrary, upstream has a history of breaking the world
<bryce> hrm, alex left just when I finally have an answer for him
<Ubulette> slangasek, no real upload (except security NMUs) for 13 months, last being a beta, despite 10 versions released upstream, I call that unmaintained. even without the APNG patch, it should be upgraded
<kagou> Hi
 * cjwatson blinks at http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt - did I break Extra-Include?
<kagou> For Bug #181561 I'm searching repository with hardy alpha1 and 2 . WHere can i found them ?
<ubotu> Launchpad bug 181561 in linux "Hardy alpha 3 daily-live i386 don't boot" [Unknown,Confirmed] https://launchpad.net/bugs/181561
<geser> ogra1: tuxtype (main) depwaits on libsdl-pango-dev (universe). Do you plan to move sdlpango to main?
<koko___> (kiba-dock:2839): GLib-GObject-WARNING **: invalid (NULL) pointer instance
<koko___> (kiba-dock:2839): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed, hello
<koko___> anybody knows what does that mean ?
<slangasek> koko___: are you on amd64?
<koko___> no
<slangasek> oh, (NULL), then I have no idea anyway :)
<slangasek> but this isn't a support channel; perhaps you should ask in #ubuntu?
<koko___> lol
<seb128> likely that the application you are using has a bug
<koko___> seb128 may be
<koko___> it is not in the packages anymore
<bryce> alex-weej: in case you review logs, for bug 176392, I found that ArneGoetje appears to have put in a fix for ttf-dejavu for Gutsy, but that fix is missing on Hardy.  I've assigned the bug to him to take a look at; I think it's simply needed to port those fixes to Hardy (and maybe push them upstream)
<ubotu> Launchpad bug 176392 in fontconfig ""Sans Italic" is noticably thinner than "Sans"" [Medium,Confirmed] https://launchpad.net/bugs/176392
<koko___> but i like kiba-dock
<jwendell> pochu, is there any reason to not having gdm 2.21 in hardy yet? If not I can make one...
<pitti> Lutin: done
<pochu> jwendell: not that I know of. You can ask in #ubuntu-desktop too, perhaps someone knows of one there.
<geser> pitti: a give-back for delo won't help unless you fixed pkg-create-dbgsym in between.
<jwendell> pochu, I think I know why: gdm is very complicated, it has a lot of patches
<pitti> asac: firefox-3.0 moved to main
<pitti> asac: thanks for the MIR
<mdz_> mjg59: are you available for TB?  Keybuk is away on holiday and sabdfl has disassembled his computer
<lool> cjwatson: I didn't understand the request for a Gtk+ backport of the im thingy as something urgent as in "I want it for yesterday", if it was meant for alpha 4, I can work on it tonight; otherwise, I prefer having a look tomorrow
<lool> (I had a surprize conference with folks at the mobile sprint this afternoon and was kept otherwise busy with GNOME updates until now)
<seb128> lool: I don't think that's that urgent, they are not likely to do ubiquity changes today
<seb128> lool: he opened the bug before the distro sprint
<lool> Ok
<lool> Since it was mentionned today, I thought this might be overdue
<seb128> I think that's a would be nice to have ubiquity thing
<lool> seb128: Did you upload Gtk+ yet?
<seb128> no
<lool> seb128: I'll ported the patch; let me do a test build and I'll hand an updated dsc to you if you don't mind
<seb128> not at all
<seb128> is there still the arch all and any issue?
<seb128> I was waiting to not break other GNOME builds
<lool> seb128: It's not
<seb128> ok, I was not sure if you did change it because of the changelog thing
<lool> seb128: I've added transition code and we still use an unversionned depends now
<lool> The symlinks?
<seb128> the copyrights need to be uptodate thing
<lool> seb128: Well I could happily upgrade my hardy box, but I didn't test downgrades indeed
<lool> But with the way the transition code is written, it should work in both the Debian and the Ubuntu case
<pitti> \sh_away: hm, cannot update ia32-libs ATM, since the kernel is FTBFS (source/binary mismatch); I'll stack this for later
<changelog> Is this the channel I should use to report bugs?
<lool> changelog: See topic
<changelog> It's not a support issue, I know what's wrong.
<Mithrandir> changelog: please report bugs in Launchpad.
<lool> changelog: Did you file a bug?
<lool> Right
<changelog> https://launchpad.net/linux
<changelog> This one?
<Mithrandir> probably not
<Mithrandir> what is the problem?
<changelog> Well, I have a RAID 5 partition
<changelog> Which keeps getting reseted because the kernel fails to negotiate the speed.
<changelog> So I get
<changelog> Jan 29 19:22:51 zeus kernel: [88872.317250] ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x780100 action 0x2
<changelog> And a few lines later
<changelog> Jan 29 19:22:51 zeus kernel: [88872.799468] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310) and Jan 29 19:22:51 zeus kernel: [88872.821938] ata7.00: configured for UDMA/33
<changelog> From what I've read, it's an issue with the .22 kernel
<Mithrandir> https://launchpad.net/ubuntu/+source/linux-source-2.6.22/+filebug is probably where you want to file it
<changelog> OK. Thanks Mithrandir
<Mithrandir> np
<changelog> You don't happen to know any repos I can find .23 or .24 (not that zen one, that doesn't work), do you?
<Mithrandir> hardy has 2.6.24
<changelog> Yeah, but I really shouldn't install that because this is a work-critical machine :)
<changelog> I've installed it in my laptop and I've noticed increased speed. It's really awesome
<cjwatson> lool: it's a customer request, so I would like to be sure it makes it for hardy, but it's not urgent for alpha-4
<lool> cjwatson: I have it here, but can't figure how to set xsettings easily
<lool> cjwatson: I'm trying to xprop -set _XSETTINGS_SETTINGS on the root window, but it can't parse it
<lool> seb128_: I uploaded a gtk+ with the changes
<seb128_> lool: ok, same location?
<lool> Yes
<Joe_CoT> any core devs bored and wanna sign off on a debdiff? 15051 and 186187
<Joe_CoT> heh, ubotu didn't pick it up
<cjwatson>         settings = gtk.settings_get_default()
<cjwatson>         try:
<cjwatson>             settings.set_string_property('gtk-im-module', cfg['GTK_IM_MODULE'])
<cjwatson>         except TypeError:
<cjwatson> lool: ^-- is what I'm using in python
<cjwatson>             pass
<Joe_CoT> bug 15051 and bug 186187
<ubotu> Launchpad bug 15051 in pcre3 "grep -P is not supported" [Medium,Triaged] https://launchpad.net/bugs/15051
<ubotu> Launchpad bug 186187 in pcre3 "Please merge pcre3 7.4-1 (main) from Debian unstable (main)" [Undecided,Triaged] https://launchpad.net/bugs/186187
<lool> cjwatson: Thanks, for some reason I was starting a C version pff
<pitti> Joe_CoT: we can just sync that package, no need to merge AFAIR
<pitti> Joe_CoT: (Debian now also ships the example file, which was our only delta)
<pitti> Joe_CoT: but I wouldn't like to sync it until after alpha-4
<Joe_CoT> Debiab moved libpcre to /lib ?
<cjwatson> lool: of course I haven't yet seen it working ...
<pitti> Joe_CoT: http://changelogs.ubuntu.com/changelogs/pool/main/p/pcre3/pcre3_7.4-1ubuntu1/changelog
<pitti> Joe_CoT: either keescook dropped the patch, or it's not relevant any more, or Debian took it
<slangasek> pitti: or it's a bug that's never actually been addressed in Ubuntu?
<pitti> maybe; but it doesn't look like it's a current delta
<Joe_CoT> pitti, look at the bugs. Appended to the libpcre one is moving libpcre to /lib , so that grep can be compiled with preg support
<slangasek> I don't see that anyone said it was, though?
<pitti> Joe_CoT: ah, so it's a *new* patch, not a merge
<Joe_CoT> yeah. I'm not the one who added that debdiff to that bug, but I would like to see it go in
<Joe_CoT> since that grep bug's been sitting there since warty i believe. noticed the bug #
<Joe_CoT> *notice
<Joe_CoT> pitti, g2g for now. I'll be back in about 1 1/2 if you want to talk about it
<pitti> seb128_: uploading hardy langpack update now, including fixed evo translations (FYI)
 * seb128_ hugs pitti
<daxroc> Is the tracker broken, has been indexing for two days here ?
<daxroc> * In hardy
<pitti> seb128_: I also enabled the cron'ed auto-upload to hardy now
<pitti> carlos ^ FYI
<carlos> pitti: cool, thanks
<pitti> carlos: I tested the locale filtering, seems to work, so it should be safe noew
<pitti> s/noew/now
<carlos> ok
<seb128_> pitti: ok
<lool> cjwatson: Whatever I try, I can't change IM
<lool> Even with GTK_IM_MODULE
<lool> Even in a Xnest
<cjwatson> colour me confused then, I talked with Murray and he seemed to think that was how it worked
<cjwatson> (though I didn't get the code from him)
<lool> cjwatson: Your snippet is probably correct, but I can't figure out how to get anything to change the IM working
<cjwatson> try ubiquity/im_switch.py in the ubiquity source
<cjwatson> and make sure to install say language-pack-zh first so that you have an interesting locale generated
<lool> I took entry.py from pygtk and added your snippet first
<lool> cjwatson: I used LC_ALL=C to disable locale im selection
<cjwatson> err, sorry, lib/im_switch.py in the oem-config source
<cjwatson> I'd recommend os.environ['LC_ALL'] = 'zh_CN.UTF-8'; locale.setlocale(locale.LC_ALL, ''); im_switch.start_im()
<cjwatson> and im_switch.kill_im() before exiting the interpreter
<cjwatson> you'll also need at least scim-chewing, scim-pinyin, scim-tables-zh installed
<cjwatson> then fire up a gtk.Entry() or something and try shift-space
<lool> cjwatson: Does it work if you set GTK_IM_MODULE in the env?
<lool> cjwatson: (I'm pulling all this, taking a while)
<cjwatson> im_switch will deal with setting GTK_IM_MODULE
<cjwatson> err - you will also need os.environ['OEM_CONFIG_FRONTEND'] = 'gtk_ui'
<cjwatson> otherwise it won't :)
<lool> cjwatson: I'm sorry, but I'm completely lost in what I'm actually testing
<cjwatson> lool: sorry, it is a touch confusing - if you have a package prepared, you could send it over to me and I'll hook it into the stuff I know how to test?
<cjwatson> as I say, it's not critical for alpha-4
<lool> cjwatson: http://people.ubuntu.com/~lool/packages/gtk+2.0/2.12.6-1~hardy1/hardy/
<lool> cjwatson: it's in seb's sponsoring queue
<lool> cjwatson: I'm afraid I'm too tired to keep up testing
<lool> cjwatson: I'll try to look at it with fresh eyes tomorrow morning, ATM I'm unable to understand anything
<lool> I don't even know why I still get scim running when I commented out all the os.environ and settings.set_string_property
<lool> I guess it's the default for chinese
<seb128_> lool: already uploaded
<cjwatson> lool: OK, I'll have a look, thanks, though probably also tomorrow
<lool> cjwatson: I'll have a new look tomorrow too
 * lool 
 * lool &
<seb128_> cjwatson: I've sponsored the upload to hardy so it should be available tomorrow
<cjwatson> seb128_: great, thanks
<pitti> soren: hm, submittodebian created a great template mail, but I don't see any attachment by default in mutt; where is it?
<keescook> pitti: did I screw up pcre3?  from scroll-back it sounds like not, but the "problem" isn't clear to me.
<geser> keescook: there is an other proposed merge for 7.4-1ubuntu1 in bug #186187 with an new change (move the lib to /lib)
<ubotu> Launchpad bug 186187 in pcre3 "Please merge pcre3 7.4-1 (main) from Debian unstable (main)" [Undecided,Triaged] https://launchpad.net/bugs/186187
<keescook> geser: ah, okay.  once freeze clears, I'll look at it.
<soren> pitti: It doesn't show.
<soren> pitti: Or... erm... mvo made the mutt integration. If it behaves like the normal reportbug thing, it won't show the attachment, but now that I think about it, i haven't actually used it with mutt.
<dmb> hmm, why is gmake not a symlink to make?
<geser> what's the best VM to boot an iso for testing?
<TheMuso> Real hardware? :p
<stgraber> geser: Looking at what is used in the testing team, it's : virtualbox-ose, qemu, vmware
<geser> TheMuso: I want to reproduce bug #184681 by updating from alpha3
<ubotu> Launchpad bug 184681 in mono-addins "Some missing /usr/share/cli-common/policies.d/libmono-addins*/*.dll break mono installatsions (! Assembly /usr/share/cli-common/policies.d/libmono-addins-gui0.2-cil/policy.0.2.Mono.Addins.Gui.dll does not exist)" [High,Triaged] https://launchpad.net/bugs/184681
<TheMuso> geser: Right.
<geser> there are currently no virtualbox-ose-modules for the current kernel in hardy :(
<TheMuso> geser: You sure? I remember seeing an upload for them at some point.
<stgraber> IIRC the module is in binary new
<TheMuso> That sounds about right.
<geser> TheMuso: virtual-ose-modules 8 (uploaded today) FTBFS
<TheMuso> ah
<geser> I tried kvm but get only a black window when I try to boot the iso
<stgraber> geser: you can use a standard qemu but that'll be slow ...
#ubuntu-devel 2008-01-30
<asac> pitti: thanks.
<blueyed> geser: I'm working on virtualbox-ose-modules.. I wasn't aware that 7 already FTBFS when uploading version 8. Currently waiting for the testbuild in ppa.
<geser> blueyed: good, I just wanted to look at it myself
<geser> blueyed: you need some special case for i386/amd64 as linux-headers-{i386,virtual} doesn't seem to exist on amd64
<dcode> this isn't a specific question about ubuntu, but I figured you guys could point me in the right direction.....how can I get the source for Launchpad?
<RAOF> dcode: You'd be after #launchpad, and you can't.
<dcode> the URL for hte project on launchpad is sftp...which obviously requires a user/pass
<TheMuso> dcode: The source for launchpad is not available
<dcode> drat
<dcode> okeyday....
<dcode> thanks for the infos
<blueyed> geser: yes, that's what I have in my ppa already. The FTBFS however seems to occur because of KDIR vs. KERN_DIR.
<geser> blueyed: I could successfully build a slightly modified package (changed flavours for amd64) on amd64
<geser> blueyed: what was the problem there as I didn't need to change here nothing
<blueyed> geser: seems specific to the buildds, because it worked in my pbuilder, too. See http://launchpadlibrarian.net/11610543/buildlog_ubuntu-hardy-i386.virtualbox-ose-modules_7_FAILEDTOBUILD.txt.gz
<geser> blueyed: looking at your -9~blueeyedppa2 packages: you need to change dh_gencontrol -a to dh_gencontrol -s as else dh_gencontrol will complain that some packages aren't for amd64
<geser> the same for dh_builddeb
<blueyed> geser: ok, anything else?
<geser> blueyed: that seems to be the only change between your rules and mine
<geser> blueyed: my package build successfully in my amd64 pbuilder but not in the i386 pbuilder, it failed during the -generic flavour
<geser> at least I've packages for amd64 so I can play with virtualbox tomorrow :)
<blueyed> geser: fine.. :) i386 does not  fail for me.. I'll reupload to my ppa and to universe, if it works out ok. Thanks.
<geser> Thank you.
 * Hobbsee waves
<bddebian> Heya Hobbsee
<TheMuso> Heya Hobbsee.
<Hobbsee> hiya luke!
<warp10> Good morning
<Hobbsee> morning
<warp10> Hobbsee: :)
<dholbach> good morning
<pitti> Good morning
<Hobbsee> pitti!
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back
<warp10> Good morning pitti! :)
<pitti> hey warp10
<StevenK> Hey pitti!
 * pitti waves towards Australia again and sends hugs to StevenK
 * StevenK isn't in Australia right now. Please leave a hug after the beep.
<Hobbsee> oy!
<pitti> StevenK: oh. sprint. right
<StevenK> pitti: Right :-)
<superm1> doko, are you around?  I wanted to chat with you re vnc4's src package.
<superm1> doko, particularly regarding bug 184225 whenever you return.
<ubotu> Launchpad bug 184225 in vnc4 "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/184225
<juliank> aufs support for casper - patch now available - bug #187259
<ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
<cjwatson> asac: so, network-manager in your PPA doesn't seem to manage to support either my wired or my wireless interface. Where do you want me to start with debugging?
<Mez> hmm - and my PC now no longer has permission to set an IP address by DHCP
<asac> cjwatson: intersting ... what do you mean by "manage" ... not detected, or just cannot connect?
<asac> what chipsets do you have?
<cjwatson> asac: as soon as I upgraded, it brought the running wired interface (managed by n-m 0.6) down, and the applet now only offers manual configuration as an option
<cjwatson> asac: tg3 (wired), b43 (wireless)
<cjwatson> it recognises both and says "eth0: Device is fully-supported using driver 'tg3'." and "eth1: Device is fully-supported using driver 'b43'." respectively
<cjwatson> for the latter, it says "eth1: driver does not support SSID scans (scan_capa 0x00)."
<cjwatson> (pretty sure it used to though)
<asac> odd
<asac> i think our kernel lacks the linville scan_capa patches ... but that shouldn't make the interfaces completely unusable
<cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  eth0: Device is fully-supported using driver 'tg3'.
<cjwatson> that's just weird, too :)
<cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  Now managing wired Ethernet (802.3) device 'eth0'.
<cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  Bringing down device eth0
<cjwatson> followed by:
<cjwatson> Jan 30 08:52:10 sarantium NetworkManager: <info>  Bringing up device eth0
<cjwatson> Jan 30 08:52:10 sarantium kernel: [21713.328605] ADDRCONF(NETDEV_UP): eth0: link is not ready
<cjwatson> Jan 30 08:52:10 sarantium NetworkManager: <info>  Deactivating device eth0.
<asac> hmm ... do you have the right applet version?
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/nm-syslog
<asac> is it 0.7 as well?
<asac> cjwatson: Forbidden :)
<asac> ah now
<cjwatson> network-manager-gnome   0.7~~svn20080121t194048-0ubuntu0~pre6
<cjwatson> 403 fixed
<asac> i assume you tried to restart nm-applet multiple times already?
<cjwatson> *** glibc detected *** nm-applet: munmap_chunk(): invalid pointer: 0x0807ac8e ***
<cjwatson> I don't think it likes me
<asac> yes ... that happens sometimes on startup
<asac> just try another time ... should come up then
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/nm-applet-crash
<cjwatson> seems to be in the code to migrate gconf from 0.6
<asac> oh it crashes while migrating
<asac> hmm
<asac> maybe backup your gconf database and wipe everything below /system/networking in gconf
<cjwatson> ok, good call, after restarting nm-applet it detects the wired interface again
<asac> (backup to keep it reproducible)
<cjwatson> pretty messy upgrade issue though
<asac> cjwatson: was the previous start your first start?
<cjwatson> oh, err, I've already restarted nm-applet, so it might be too late; taken a backup now
<cjwatson> yes
<asac> damn :)
<asac> well ... i assume that your previous nm-applet instance running was still the old one then.
<cjwatson> it was
<asac> next start was your first start (migration crashed) ... and now it works
<cjwatson> looks like we need to arrange to restart it though, somehow
<asac> cjwatson: any pointers appreciated :)
<cjwatson> since it takes out networking otherwise
<asac> seb128: i think nm-applet is started by gnome session ... can i somehow trigger a restart for specific apps on upgrade?
<seb128> asac: no
<seb128> asac: you can get nm-applet react to signals and have the postinst using that though
<cjwatson> seb128: got a handy time machine? :)
<asac> lol
<cjwatson> you could have the postinst search for processes called nm-applet, kill them, switch to the corresponding user(s), and restart them
<cjwatson> (UGLY AS SIN)
<asac> ouch
<cjwatson> ... with the right command-line arguments
<asac> then we should just restart twice as on first start it will crash :-P
<cjwatson> have you tried something like: basic gutsy install, connect to wireless network, save that gconf database?
<asac> yeah ... but at least we could do it somehow
<asac> (restarting)
<asac> cjwatson: nope ... I haven't really looked into this as its just a random snapshot from a quick progressing svn tree.
<asac> if it doesn't go away in next snapshot i know where and how to look now
<asac> unfortunately, i have to stop everything and do mozilla security now ... an exploit leaked so the release was rescheduled to be next mon/tue.
<asac> :(
<Kano> hi
<superm1> hi Kano. juliank ended up adding aufs to lum today
<Kano> i know, i use that kernel already
<Kano> but casper is not yet patched
<superm1> yeah there is a bug filed regarding it
<Kano> live-helper worked however
<superm1> just needs a sponsor from core-dev
<superm1> bug #187259
<ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
<cjwatson> asac: disassembly says it's the g_object_unref after reading a wireless connection, btw
 * asac looking
<cjwatson> (there are two in that function)
<Kano> superm1: i updated my patch a little bit
<superm1> Kano, juliank is the one that attached it to the bug.  any differences you have you may just want to attach to that same bug
<Kano> panic "Unionfs mount failed" is now panic "${UNIONTYPE} mount failed"
<Kano> because then you see what ovfs you used
<Kano> rest is still the same
<Kano> not huge, but looks better
<juliank> Kano: it is ${UNIONFS} now, not ${UNIONTYPE} used in Debian.
<Kano> call it like you want
<asac> cjwatson: can you see if its the wireless ... or the vpn one?
<Kano> but use it at this point
<cjwatson> asac: fairly sure it's the wireless one; it's well under halfway through the function (lots of inlined stuff)
<cjwatson> and the calls before it look to be from the inlined wireless code
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<Kano> basically some more options from live-helper should be backported, casper is really very primitive against it...
<cjwatson> asac: it might be relevant that the most recent change to gconf-helpers.c was labelled as fixing memory leaks
<tkamppeter> pitti, about bug 185602, you fixed the ghostscript documentation issues once, with this bug they reappeared, can you fix this again?
<ubotu> Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602
<Kano> like live-media-path option
<pitti> tkamppeter: it doesn't have anything to do with the toolchain; I suspect the patch was dropped during the last merge, or so
<TheMuso> evand: You are a bloody legend! I have been meaning to do that in casper for quite a while now! I owe you a beer at the next event!
<Kano> or how do you combine more than one live cd on dvd?
<pitti> tkamppeter: yes, it's in my ubuntu mbox, I'll have a look
<pitti> tkamppeter: (feel free to beat me to it :) )
<tkamppeter> pitti, and if you fix that one, can you also apply the proposed patch of bug 183628
<ubotu> Launchpad bug 183628 in ghostscript "ghostscript crashes after loading 20 page repeatedly" [Undecided,New] https://launchpad.net/bugs/183628
<pitti> tkamppeter: ok
<tkamppeter> pitti, I have marked the bug 185602 as an alpha 4 milestone, as it can break the distro's consistency.
<ubotu> Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602
<tkamppeter> pitti, thanks in advance
<cjwatson> asac: for the record, wireless works too having restarted nm-applet, so I'm happy for the time being
<juliank> Kano: Updated the patch
<Kano> fine
<Kano> now you only need a number for the new kernel/lum and casper
<Kano> and then you can autobuild it
<Kano> do you know live-helper?
<juliank> Kano: I wrote the patch to add aufs support to live-helper/live-initramfs.
<Kano> juliank: well the change is not really huge ;)
<Kano> how about adding some things from live-helper back
<Kano> toram, media*
<juliank> Kano: toram is already in casper
<Kano> i think it had a problem in live-helper, then something went wrong
<Kano> i think the cd could not be used
<TheMuso> juliank: Perhaps it might be better to branch casper trunk, add your patch, and add the URL to your branch on the bug.
<Kano> to burn then
<Kano> did you try?
<TheMuso> Then its a matter of a core-dev merging your changes.
<juliank> TheMuso: The branch is not working.
<cjwatson> a patch is usually fine, FWIW
<Kano> the patch is so small, hard to make any huge mistakes ;)
<TheMuso> cjwatson: Yeah I know. I just remember back in the day when I started the a11y stuff, I was asked to do a branch. :)
<cjwatson> yeah, I think that was larger and more complex, and possibly needed a few iterations of merging and such
 * ogra wonders why he finds his laptop hardlocked every morning :(
<TheMuso> cjwatson: There is truth to that.
<juliank> TheMuso, cjwatson: "KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
<juliank> "
<cjwatson> well, today's alternate CDs seem happier
<cjwatson> juliank: blink; I can only say it works fine for me and suggest #bzr for debugging
<TheMuso> juliank: Where are you getting that branch from?
<cjwatson> could be genuine network data corruption I suppose
<cjwatson> Arch-1:matt.zimmerman@canonical.com%casper--main--0--patch-21 is in the tree I have
<Kano> also is it really hard to add a very small patch to mesa?
<cjwatson> (corresponding to r22)
<Kano> until you add that i can not boot ubuntu
<Kano> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/151974
<ubotu> Launchpad bug 151974 in mesa "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Fix committed]
<Kano> that patch is not in the debian package,but debian does not enable compiz by default
<cjwatson> Kano: our X maintainer is GMT-0800 and unlikely to be around right now ...
<juliank> TheMuso, cjwatson: lightweight checkout worked - I am also not able to view files using codebrowse.launchpad.net for this project, gives 500 internal error
<juliank> debian/changelog
<cjwatson> Kano: (oh, well, tjaalton is in a convenient timezone, I didn't realise he was dealing with this one)
<Kano> he added 2 debian patches, a 3rd one would not hurt...
<Kano> err 2 ubuntu ones
<TheMuso> cjwatson: re the initramfs error handling spec: I have managed to reproduce the behavior reported in bug 31126, however unlike what one comment in that bug says, dpkg now fails, due to no space left on device. However, the initramfs is still corrupted. So in terms of the spec, I guess aborting is bhappening somewhat, but I am now not sure how part of the spec applies...
<ubotu> Launchpad bug 31126 in initramfs-tools "Doesn't check for failure due to full filesystem" [High,Confirmed] https://launchpad.net/bugs/31126
<Kano> it is really bad when you boot a system and see a chess board only
<cjwatson> TheMuso: software should recover from out-of-disk-space without corrupting data, as a general rule
<cjwatson> TheMuso: it does indeed abort, but it should leave you with a working initramfs
<TheMuso> cjwatson: Yes, but how do we do that if there is no room?
<cjwatson> TheMuso: see the design in the spec :)
<cjwatson> it should write the new initramfs and move it into place
<cjwatson> that approach defends against this problem
<TheMuso> But thats what happens now is it not?
<cjwatson> no, it is not
<davmor2> is Ubuntu safe for iso testing?  Are there any major bug fixes in process?
<TheMuso> cjwatson: Oh, it gzips it straight into boot?
<cjwatson> TheMuso: right
<Kano> juliank: do you work with live-helper on ubuntu?
<cjwatson> TheMuso: the standard approach is gzip -c > foo.new and then move foo.new to foo
<cjwatson> but mkinitramfs just does this:
<cjwatson> (cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip -9 >"${outfile}") || exit 1
<cjwatson> that's guaranteed to leave a corrupted initramfs if anything goes wrong
<cjwatson> which is what the first part of the suggested code changes in the spec address
<cjwatson> es
<juliank> Kano: I don't build ubuntu live disks, I just provided this patch for casper.
<TheMuso> cjwatson: But how does symlinking the .bak help here? (From reading the code in the spec)
<cjwatson> http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/files seems to work for me, FWIW
<juliank> cjwatson: Click on debian/changelog
<cjwatson> TheMuso: that's not a symlink
<Kano> cjwatson: did you see that left over swp file in the casper package?
<cjwatson> Kano: yes, I don't care, it'll go away next upload
<TheMuso> cjwatson: Ah right, I see that now
<Kano> not that you forget that ;)
<cjwatson> evand: ^-- .swp presumably in your tree
<cjwatson> Kano: it doesn't matter, it makes no difference to anything
<cjwatson> TheMuso: let me try to remember, I know that logic was important
<cjwatson> TheMuso: oh, right, it was because the existing initramfs logic tries to leave a .bak file
<TheMuso> cjwatson: So, let me try and get this right in my head. It hard links to a .bak file, conserving some space. The new initramfs is built, and moved into place... If it fails, theres still a useful initramfs?
<cjwatson> TheMuso: at the moment, it moves the old one to .bak first and then regenerates
<TheMuso> cjwatson: Right, I noticed the .bak file using up space on /boot which seemed pointless
<cjwatson> well, it would still be a separate file, but let's not worry about that right now; simplest approach is to preserve existing behaviour while making it safer
<cjwatson> the ln/mkinitramfs/mv approach means that at most 2x the size of the initramfs is used in /boot at any one time
<cjwatson> cp would work as well as ln, but would use 3x the size of the initramfs for a short period
<cjwatson> so hardlinking is more efficient in this case
<cjwatson> the point where the initramfs generation can fail is when it's writing to .new
<TheMuso> cjwatson: Right, So we hard link, generate new initramfs, copy over, if all is well, remove hard link?
<cjwatson> but that's fine, because the boot process doesn't look at it
<TheMuso> oh right .new
<cjwatson> mv (on the same filesystem) is atomic; it either succeeds or fails, but cannot fail part-way through
<TheMuso> right
<cjwatson> don't need to remove the hard link because the mv breaks it
<cjwatson> but safely, so that .bak is still the old fine
<TheMuso> Ah of course.
<cjwatson> file
<pitti> tkamppeter: fixed
<TheMuso> cjwatson: Ok, thanks. Things are much clearer, I've got something to go from now. Will hack on it tomorrow and go from there.
<cjwatson> TheMuso: this is all done under 'set -e', so any failures will cause the shell script to terminate immediately
<cjwatson> well, update-initramfs is set -e at any rate; mkinitramfs isn't, but it checks errors in the important places here already
<TheMuso> Right.
<cjwatson> under set -e, you basically get try/catch ;-)
<TheMuso> cjwatson: Yeah I know. I've done a lot of my own stuff under -e.
 * cjwatson nods
<TheMuso> And of course, at set -x would have helped me find that gzip dumps straight to boot. :p
<cjwatson> juliank: good point; I'm not sure whether that's a matter for #bzr or #launchpad but it'll be one of those
<cjwatson> juliank: like I say, a patch is fine for now
<tkamppeter> pitti, thanks
<Mez> cjwatson, your issues with NM - for some reason I have issues with NM too ... and now can only select manual configuration to have it work properly, as it seems that dhclient is recieving permission denied errors when trying to configure the card (however, when I manually set things up - everything's fine)
<Mez> but setting up things manually for wireless isn;t going to be fun
<cjwatson> Mez: unless you're using asac's hardy PPA, it's unrelated
<Mez> cjwatson, oh, damn - then I have an issue which I need to fix :( and have no idea where to start
<tkamppeter> pitti, important HPLIP bug fix for Alpha 4, biff
<pitti> tkamppeter: while you are at touching/testing hplip, could you please make it stop using the 'scanner' group?
<pitti> tkamppeter: in theory your user should have an ACL on whichever devices are created for this, so that you can access them without a particular group
 * TheMuso will do CD testing in the morning, and notify accordingly. Need sleep now. :)
<tjaalton> Kano: as I told you it would be nice if you first make sure that the patch will get in 7.0.3. I'm not sure there's time for a new upload for alpha4 though
<davmor2> having massive issue's with gvfs.  I'm an iso tester and I can't burn more than one cd without needing to restart the machine to burn the next :(  That's a major regression
<awalton__> and that's a GVFS issue.. how exactly?
<davmor2> awalton__: never happened before gvfs was introduced
<awalton__> that's not really an answer, that's a coincidence.
<awalton__> hal problems perhaps?
<awalton__> if it's really a GVFS issue, we've gotta know because it'd be a pretty serious bug.. but from my POV it's hard to see gvfs doing anything special in this regard.
<davmor2> awalton__: I've been having serious issues with gnomes reliablity sinse gvfs was introduced.  I'm no expert by any shape or means but it has only been since it's introduction.  Before hand everything worked fine.
<awalton__> have you tried removing gvfs and seeing if the problem still presents?
<davmor2> If you can tell me how to track it down I can help.  But I have no idea at all
<awalton__> removing the hal backend?
<davmor2> I'll give it a bash
<davmor2> is it just gvfs I need to remove?  What is the hal backend called?
<awalton__> the first thing I'd try is just plain removing all of gvfs.. apt-get remove it
<Kano> tjaalton: agd5f merged it, ask him if you don't believe me
<awalton__> if the problem goes away, then we can pin it down from there
<davmor2> awalton__: ok nps need to reboot I'm running in kubuntu live at the moment so I could get some discs burnt
<Kano> tjaalton: i gave him another patch, he made this one, i tested it and he added it to mesa
<Kano> tjaalton: as long as the patch is not applied i can not boot ubuntu with enabled compiz, thats clear or not?
<tjaalton> Kano: ok, that was 20h ago according to the logs
<tjaalton> Kano: uploaded
<Kano> fine
<Kano> maybe i can test u sooner or later on real hardware then...
<Kano> vbox is abit boring ;)
<Riddell> evand, cjwatson: ubiquity install fails with "The installer needs to remove operating system files from the install target, but was unable to do so.  The install cannot continue."
<cjwatson> Riddell: evand was working on that yesterday
<cjwatson> 16:41 <evand> ah, so my logic in clear_partitions completely fails to account for the fact that you cannot remove a directory that's a mountpoint.
<cjwatson> I believe it's on the alpha-4 milestone list
<Riddell> cjwatson: ok thanks
<Kano> cjwatson: do you think you could modify initramfs to support a blacklist option BEFORE udev is started. i see no hook to get started before udev
<tkamppeter> pitti, about HPLIP, can you upload my package and I remove the scanner group stuff with the next HPLIP upload, as this HPLIP fixes an urgent bug for Alpha 4.
<pitti> tkamppeter: I can do that
<tkamppeter> thanks, pitti.
<cjwatson> Kano: I don't maintain initramfs-tools routinely; I just edit it when I need to
<pitti> tkamppeter: done
<cjwatson> slangasek: I synced debconf 1.5.19; should help with grub/ucf
<zero-9376> hi can someone tell me if the bug where nautilus doesn't fall back on default search if tracker is removed has been resolved please ive been searching the forums but there's no definitive answer that i can see and i dont have the data allowance to download the alpha
<zero-9376> and the closest matching launchpad bug i can see is wishlisted?
<zero-9376> ahh sorry wrong channel :-[
 * Hobbsee stomps on tomboy
<jwendell> morning, seb128
<seb128> hey jwendell
<jwendell> seb128, do you plan to package new gdm to hardy?
<seb128> jwendell: no
<jwendell> seb128, :(
<seb128> jwendell: it's not tested, has no themed login, no setting migration, no autologin, no graphical config tool, etc
<seb128> jwendell: hardy will be a lts, that would not be a smart move, why do you need this one?
<jwendell> seb128, you mean gdm 2.21.5 ?
<seb128> jwendell: no, I mean 2.21 SVN
<seb128> jwendell: they should be in freeze and debug bug, not writting thousand of lines of code every week now
<jwendell> seb128, actually I don't need that version. It's just that I'd want to fill a bug about not playing the sound, and I'd like to test newer version before doing this...
<seb128> jwendell: 2.21 is a rewrital, but you can still open 2.20 bugs, it's still maintained and they will another tarball
<seb128> they will roll another tarball
<jwendell> seb128, ok, thanks
<seb128> you are welcome
<Kano> how about updateing fuse+ntfs-3g?
<Kano> until it is frozen again ;)
<Kano> btw. fuse has a newer version in debian. for ntfs-3g you could look at my package if needed...
<cjwatson> Kano: I already updated fuse
<Kano> when?
<cjwatson> yesterday
<Kano> good
<Kano> then only ntfs-3g remains
<cjwatson> I'll do ntfs-3g once the Debian maintainer does it; he's usually pretty quick
<Kano> well i am quicker, i had even the rc packaged ;)
<cjwatson> that's nice
<Kano> it is a bit different
<Kano> because you dont need fuse as build-dep
<Kano> has integrated fuse-lite
<cjwatson> I don't see a reason to avoid the fuse build-dep
<Kano> i see it
<Kano> when ntfs-3g would need an fuse update then you need to update 2 package, so only 1
<cjwatson> that doesn't count
<Kano> well if you dislike it you can enable external fuse
<Kano> as you have 2.7.2 this should do too
<cjwatson> a much more important reason *not* to do that is that if a security problem is found in fuse then the security team would have to run around finding everything that's copied it.
<cjwatson> we dislike it and already have enabled external fuse. you do not need to tell us that :)
<Kano> http://ntfs-3g.org/releases.html
<Kano> New: the --with-fuse=external configure option makes NTFS-3G to be compiled with an external FUSE library. For non-Linux operating systems this is the default and the only compilation option currently.
<Kano> then use that option
<cjwatson> I'm sure the Debian maintainer will do so
<cjwatson> I am quite happy to wait
<Kano> i am sure he will not
<cjwatson> if he doesn't, the Debian security team will ask him to change
<cjwatson> (as soon as they notice)
<Kano> btw. it makes it more easy to backport
<cjwatson> please leave me alone
<cjwatson> I have said no and I mean no
<Kano> as long as you update it...
 * cjwatson applies /ignore, as he is getting bad-tempered
<ogra> who is doing release notes for alpha4 ?
<seb128> do we add users to the fuse group nowadays?
 * ogra hopes not 
<Hobbsee> ogra: slangasek
<seb128> ogra: why?
<seb128> ogra: that's required to get gvfs using fuse which is very handy (allow all GTK applications to use network shares transparently)
<ogra> seb128, well, i rely with ltspfs on the fact that users have no local device access by default on thin clients ...
<ogra> i would have to rework that model
<ogra> my users want this access to be off by default ...
<ogra> the fuse group was my switch until now, as nothing else used it by default
<seb128> ogra: just don't install gvfs-fuse on ltsp then
<ogra> seb128, its not about gvfs ... but the group membership
<ogra> an admin has to enable it deliberately currently
<seb128> can't you have different membership on ltsp then?
<seb128> right
<seb128> and I just noticed that's why gvfs fuse mounting is not working
<ogra> no, i'd need hacks to ltspfs
<ogra> its not designed for extra ACL stuff yet
<seb128> and I think transparent access to network share for all gtk applications is something we should have
<seb128> that would allow acroread, etc to open files on smb shares
<ogra> i bet i can do it easily on a per client base ... but thast not how its documented and would need changes in my users habits
<seb128> I take acroread as an example because that's one we can't hack to make it use gvfs ;-)
<ogra> since we currently do it on a per-user base
<seb128> maybe that should be something to discuss on the mailinglist
<ogra> seb128, if thats really decided to be done, please notify me and i'll ask the ltsp community how they like to have it
<seb128> well, that's how gvfs work
<ogra> probably they would even be happy with all users being able to use localdev out of the box :)
<seb128> we can decide to use the feature or not now
<stgraber> ogra: I would :) I never was requested to turn local devices off
<Mirv> Hi. If someone would have time, please do a rebuilt / binary-only upload of openoffice.org-voikko to have bug #187083 fixed for Alpha 4 testers.
<ubotu> Launchpad bug 187083 in openoffice.org-voikko "[hardy] openoffice.org-voikko needs a rebuild" [Unknown,Fix released] https://launchpad.net/bugs/187083
<ogra> stgraber, right, when i defaulted to having it on for everyone jammcq and sbalneav complained it should be an opt-in feature and no default
<ogra> so i'll return to tehm to discuss it
<stgraber> ogra: it should be something we can turn on or off for everyone (or eventually a lts.conf option), having to add all the users to the fuse group isn't really admin-friendly
<ogra> the prob here is that you cant steer it through the group membership anymore (which is documented everywhere in the edubuntu docs)
<ogra> it will tear down other features as well
<ogra> thats waht worries me most here
<ogra> stgraber, right, but that would work only on a per-client-machine base, not per-user anymore
<ogra> lts.conf doesnt know about users
<ogra> and i hope it will naver have to :)
<ogra> *never
<tjaalton> Mirv: I can do that
<tjaalton> Mirv: uploaded
<stgraber> ogra: indeed, but are people really using it as a per user filter ? or just as an on/off switch for all the users ?
<tjaalton> Mirv: I didn't even notice that l-s-fi isn't on my systems currently :)
<ogra> stgraber, no idea, i have to rely on jammcq and sbalneav, i onlyheard complaints from users that it wasnt on by default
<ogra> so having it might actually please people
<ogra> what i'm worried abotu is that rther is no way to disable it on a per user base anymore
<Mirv> tjaalton: ah, thanks! yep, l-s-fi was probably uninstalled (if it was installed before) when upgrading to OOo 2.3.1, because of this.
<tjaalton> indeed
 * ogra would love to know what hardlocks his laptop as soon as DPMS kicks in :/
<ogra> grmbl
<Kano> maybe update gfx driver
<ogra> and that should hardlock the kernel ... ? i dounbt it
<Kano> then update kernel too ;)
 * ogra suspects g-p-m rather
<stgraber> ogra: or maybe acpi ?
<ogra> stgraber, hmm
<ogra> i never had acpi probs on that laptop
<ogra> but a place to look at i guess
<stgraber> ogra: oh btw, do you have an idea of why is my g-p-m detecting 3 batteries, 2 of them being the same when I only have one plugged in ? :)
<ogra> hal bug
<stgraber> ogra: I can understand the second one as I have an extra battery slot, but having the first 1 reported twice is hmm, weird :)
<ogra> i think its known upstream ... ask ted gould if he's around
<pitti> stgraber: this is pretty well understood already
<ogra> he's doing powermanager and screensaver now
<pitti> stgraber: primary reason is that current kernel duplicates battery information in /sys and /proc
<ogra> ah, right
 * ogra remembers that thread from the hal list
<pitti> ogra, stgraber: no, it's got nothing to do with gpm; hal picks up and reports the battery twice
<ogra> pitti, yup
<stgraber> pitti: hmm, and hal is checking both places ?
<pitti> stgraber: yes, to work with older and newer kernels
<stgraber> pitti: ok, I'll have a look at hal as it also shouldn't report a battery with present=no ...
<stgraber> or if it should, then g-p-m shouldn't as having two battery slots usually means it's some kind of docking station slot and then not likely to be used by the average user
<cjwatson> pitti: do you think we should be having PolicyKit constrain device access to local users only?
<stgraber> (and should only appear when you actually plug a battery in it)
<ogra> cjwatson, eeek
<cjwatson> pitti: I'm looking at adding ConsoleKit support to ssh (somehow) for ogra, and am concerned about the effect on the security model
<pitti> cjwatson: which kind of device?
<ogra> dont do that to me ...
<cjwatson> ogra: LTSP would have to count as local somehow
<cjwatson> err
<cjwatson> 13:25 <ogra> seb128, well, i rely with ltspfs on the fact that users have no local device access by default on thin clients ...
<ogra> ltspfs wouldnt
<cjwatson> ogra: what exactly do you mean by the above?
<cjwatson> I am very confused about LTSP's requirements :-)
<pitti> block devices?
<cjwatson> pitti: err, not sure
<ogra> local == device attached to the thin client
<Kano> ogra: what do you use for sound via network?
<cjwatson> ogra: here, local == local to the PolicyKit instance in question
<ogra> we have a udev rule that attaches to the ssh tunnel and fires a fuse mount script on the server ...
<cjwatson> ogra: do you expect users to have access to e.g. a pluggable USB stick? if so from where?
<pitti> hal currently grants access to the current user for USB devices like printers, scanners, cameras, and mass storage
<ogra> which then establishes a ltspfs/fuse mount towards the client
<cjwatson> pitti: let's phrase it differently; what would happen to the security model if sshd were to activate a ConsoleKit session?
<ogra> cjwatson, physically on the client ... session management wise on the desktop
<cjwatson> this would mean you could no longer assume that active sessions are local
<ogra> Kano, alsa
<pitti> cjwatson: the ssh session would be able to drive power management, mount local removable block devices, etc.
<cjwatson> ogra: OK, let me have this conversation with pitti so that I understand the model, and then we can think about how LTSP fits in
<cjwatson> ogra: without the former I cannot do the latter
<Kano> ogra: alsa has network support?
<cjwatson> pitti: do you think that is desirable?
<pitti> the privs are currently granted under the assumption that local session  == physical access
<stgraber> Kano: alsa plugin for pulseaudio, pulseaudio for the network part and back to alsa on the thin client
<Kano> ah
<stgraber> Kano: so any alsa compatible apps should work
<cjwatson> pitti: as far as I can see, the current set of privileges are oriented around active sessions, not local sessions
<pitti> cjwatson: in general the idea is to *not* open a *local* CK session for ssh
<ogra> stgraber, wrong way round :)
<pitti> cjwatson: you can have a CK session with "is-local = FALSE" if that helps
<cjwatson> pitti: yes; does any of our current policy actually look at that, though?
<pitti> depending on whether the problem is that no CK session exists at all, or whether it's local
<ogra> alsa with puls plugin in the backend emulates a virtual alsa card ... pulse sits only on the client ... listening
<cjwatson> I can't find anything that does, though I see code in PK that checks
<cjwatson> pitti: well, the immediate problem is the former, but I want to avoid breaking things while fixing it
<pitti> cjwatson: it's supposed to; if not, that would be a bug
<stgraber> ogra: hmm, by alsa plugin I mean the thing redirecting the output of a software to pulse, pulse running on the thin client and having alsa as output to the speakers
<cjwatson> $ grep local /usr/share/PolicyKit/policy/*
<cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <description>Monitor local virtualized systems</description>
<cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <message>System policy prevents monitoring of local virtualized systems</message>
<cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <description>Manage local virtualized systems</description>
<cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <message>System policy prevents management of local virtualized systems</message>
<cjwatson> should I be looking at something else?
<pitti> cjwatson: give me a minute to find where it evaluates locality
<ogra> stgraber, ah, then you are right :)
<pitti> cjwatson: one place where it is checked is the dbus policy, but that shouldn't be the only place ideally
<pitti> cjwatson: (<policy at_console="true">) in /etc/dbus/system.d/)
<ogra> stgraber, i'm just trying to avoid the name pulse at all because users start to play with it session side and break stuff usually (overriding teh alsa setup with some pulse tweaks etc) ... thats hard to debug
<pitti> cjwatson: the hal addon which adds ACLs to /dev/* stuff checks it
<cjwatson> pitti: the pam_console compat patch doesn't seem to check locality anywhere? it's just done in the session leader code
<pitti> cjwatson: good point; I should add a check for this, thanks for spotting
<cjwatson> ok, if that's the design, then it doesn't sound like it should break too much
<cjwatson> (that isn't already essentially broken)
<cjwatson> just using pam-ck-connector already spots PAM_RHOST and turns off is-local, so that much is fine; just need to get the rest to work
<pitti> ok; I can commit to unbreaking stuff that silently assumes that any CK session is local and shouldn't
<cjwatson> ogra: ok, so does LTSP want to pretend that the ssh session is equivalent to a local console?
<ogra> hmm
<pitti> cjwatson: I'll do that CK fix right now
<cjwatson> pitti: great, thanks
<ogra> cjwatson, sounds like the right thing to me ... and like how ts currently handled
<ogra> i'd like to do some testing how that affects things like FUSA
<ogra> (which we need to disable atm since CK support is required in gutsy for it already)
<ogra> Riddell, seems nixternal did get that across right ... KdeEdu apps have no startup notification at all on gnome desktops atm with the missing entry in .desktop
<ogra> *didnt
<ogra> its not a matter of timeout values but about having it at all
<Riddell> ogra: is this a recent thing?  is it specific to the classmate at all?  why can't it do something more intelligent that doesn't involve editing every .desktop file?
<ogra> Riddell, not classmate specific
<ogra> classmate is just wheer it really hurts
<ogra> i never noticed it before though
<ogra> but then i probably didnt look close enough
<ogra> to me it looks like we could just omit X-KDE from StartupNotuify and it works on both desktops
<ogra> cjwatson, does that model work for multiple logins as well ? upstream just noted each client should have its own seat
<jdong> lookie that, new version of transmission
<pitti> cjwatson: fixed CK uploaded, thanks again for spotting
<slangasek> cjwatson: debconf 1.5.19> w00t, thanks
<cjwatson> ogra: err, pass, would have to investigate
<ogra> cjwatson, well, we can get mccann involved for details ... getting basic support is already a huge advantage
<ogra> he asked that we look at gdm's xdmcp handling
<ogra> that should gain us waht we want
<cjwatson> I really don't want to c'n'p that code; would rather use the PAM module if at all possible
<cjwatson> I've replied to your mail; if it seems a bit confused that's because I was investigating the software stack while writing it
<ogra> cjwatson, hmm, i think the latter option is actually what the majority of users uses nowadays ....
<ogra> ssh user@host sh -c 'DISPLAY="12.34.56.7:6.0 sudo time-admin'
<ogra> i'll think about a solution on ltsp side for that one
<cjwatson> consolekit needs to be passed DISPLAY; I think it uses its value to distinguish seats
<ogra> (its not the default mode so i can tell them they needs some ldm-server-helper package or so on servers where they want to drop X encryption)
<cjwatson> and, as I say, you'll need to remove sudo from that in hardy
<ogra> i just copied from the mail :)
<ogra> i understood that
<cjwatson> one alternative might be to forward the DISPLAY environment variable using SendEnv/AcceptEnv
<ogra> given the fact that thin client device access isnt handled by hal or dbus i think we can ignore it for now as long as gvfs still monitors /media for mounts
<ogra> i can trigger something from the ommand ldm issues in that case as well ...
<ogra> *command
<ogra> in: ssh user@host sh -c 'DISPLAY="12.34.56.7:6.0 time-admin' everything between the quotes is configurable on my side
<cjwatson> hmm, the PAM session is opened before setting environment variables in the child
<ogra> i think thats what upstream meant about privilege separaation probs
<cjwatson> that's the least of the problems, actually
<cjwatson> actually, no, ignore that
<cjwatson> ogra: from my reading of this, it'll need some small modifications to openssh certainly, but basically just to ensure that the proper environment variables are set before opening the PAM session
<ogra> ok
<ogra> if thats enough i'm fine
<cjwatson> i.e. fish out the things that would be set for the tty and DISPLAY from the Session structure, and fill those into CKCON_blah
<ogra> yep
<ogra> lets do that then and let me test how my clients behave ... it moght already be enough
<ogra> *might
<ogra> we surely dont need to csre for local devices beyond gvfs having to monitor 7media
<ogra> */media
<cjwatson> ogra: at the moment, sshing in twice (with -o ControlPath=none) gives me two separate sessions on two separate seats
<cjwatson> FYI
<ogra> we use ControPath iirc
<ogra> and the second ssh attaches to that
<cjwatson> obviously if you multiplex then it's all one session
<cjwatson> by definition
<ogra> oh, you refer to my last qestion
<cjwatson> logins from separate people won't (can't) multiplex that way so will be separate seats
<cjwatson> was referring to:
<cjwatson> 14:30 <ogra> cjwatson, does that model work for multiple logins as well ? upstream just noted each client should have its own seat
 * ogra was thinking you look at ldm source :)
<cjwatson> no, not yet
<ogra> thats great, then even FUSA should work :)
 * ogra is afk until the meeting ...
<\sh> pitti, ia32-libs problem...If I see it right, there is no shlibs entry for libxml2 inside of ia32-libs.shlibs
<pitti> ia32-libs has a shlibs??
<\sh> pitti, it has, yes ;)
<\sh>  /var/lib/dpkg/info/ia32-libs.shlibs
<pitti> wow, wasn't aware of that
<\sh> pitti, and everything seems fine...but not with libxml2...where I'm running now into problems with wine ;)
<pitti> I certainly never bumped the shlibs fine, and TBH I think it's crack
<pitti> because as it is it is unmaintainabe
<ogra> slangasek, https://lists.ubuntu.com/archives/edubuntu-users/2008-January/003218.html would be good if we could hint the ltsp changes for alpha4 users in the release notes
<\sh> pitti, looks like debian/rules in ia32-libs should do this automagically...
<ogra> not that wordy though :)
<pitti> it should be bumped autoamtically, not manually
<slangasek> ogra: release notes draft are publically editable at https://wiki.ubuntu.com/HardyHeron/Alpha4, if you'd like to add something there
<ogra> oki, thanks :)
<pitti> \sh: but I still don't see what it's good for; it shouldn't be a build dependency
<\sh> pitti, well, for wine on amd64 we need ia32-libs as b-d...
<\sh> pitti, because some .so inside the wine universe are using those libs..e.g. msxml*.dll.so which links against libxml2 which can't be found now during shlibdeps call :)
<\sh> pitti, everything is fine afaiks, but this ;)
<ScottK> pitti: Do you know if openldap is going to be gotten off of libdb4.2?  If so, it looks reasonable to think about removing DB 4.2 entirely instead of just demoting it.
<slangasek> it's not
<slangasek> unfortunately, openldap + db4.6 gives performance issues
<ScottK> OK, so trying to get Universe stuff off of it isn't likely to help then.  Thanks.
<pitti> ScottK: unknown; I was told that something was fixed upstream in 4.6, but it's at least not in Debian yet
<slangasek> ScottK: getting universe stuff off it is probably worthwhile anyway, so that people not using openldap only need one bdb version?
<slangasek> pitti: hmm, is it fixed upstream?
<pitti> slangasek: no idea; wasn't it you who mentioned this?
<\sh> pitti, dpkg-shlibdeps: failure: no dependency information found for /usr/lib32/libxml2.so.2 (used by debian/wine/usr/lib32/wine/msxml3.dll.so).
<\sh> argl
<\sh> ia32-libs: shlib-missing-in-control-file libxml2 usr/lib32/libxml2.so.2.6.16
<pitti> \sh: I'd rather drop ia32-libs' .shlibs file completely
<slangasek> pitti: I think we may have misunderstood each other, then; I only said that it /needs/ to be fixed by bdb upstream, not that it has been
<jwendell> when building gnome packages we pass to configure --with-gconf-schema-file-dir=/usr/share/gconf/schemas right?
<ScottK> It's fewer than half a dozen packages in Universe, so it should be doable.
<pitti> slangasek: ah
<ScottK> 4.3 is less than 20...
<\sh> pitti, and adding the deps manually into debian/control of the package needing the ia32 libs?
<pitti> \sh: yes; it's just ia32-libs itself, after all
<pitti> \sh: if you can fix ia32-libs' .shlibs and rules to not be on crack, that works, too, of course
<\sh> pitti, sure...I just need to find out, what's the best to fix this damn problem :)
<pitti> but I don't have time to do this today
<pitti> \sh: I can tell you
<\sh> pitti, well, it looks like that the problem is inside libxml2
<pitti> \sh: throw away this ia32-libs abdomination and either make the required lib sources build a lib32* package, or make a more generic facility to depend on _i386 .debs on amd64
<slangasek> ScottK: and pushing the changes to Debian, so everybody wins? :-)
<ScottK> slangasek: Sure.
<\sh> pitti, I wonder why we didn't do it by default...adding a lib32<insert name here> shouldn't be so hard at all
<pitti> \sh: it's insanely painful to introduce multibuild into a lot of source packages
<pitti> \sh: and even the lib32foo_amd64.deb is a nasty hack
<pitti> it should just use the libfoo_i386.deb somehow
<\sh> pitti, and what would make "depending on _i386.deb" happening? I really don't know how to tell dpkg to use it on amd64
<pitti> \sh: neither apt nor dpkg support this ATM
<\sh> pitti, so we should discuss it for hardy+n somehow...
<pitti> \sh: I think this has been discussed several times already (jbailey, Mithrandir, doko?), but I don't know the current status
 * \sh hates wine ,-9
<slangasek> \sh: really, the solution is that you only have to use libfoo_i386.deb because you only need to *build* wine once, and can then install the 32-bit binaries directly on amd64; but now we're talking about multiarch :)
<doko> ohh, who did implement it? ;-)
<\sh> slangasek, as long there is no "real" solution for everyone (reading debian + ubuntu) I don't see any possibility to go away from the ia32-libs approach...
<\sh> -ETOOMANYHACKSINVOLVED
<\sh> the other problem I have now is why libxml2 doesn't provide a usable shlibs file ,)
<slangasek> doko: some day...
 * \sh shouls switch off the computer and should go and fetch some new clothes 
<Riddell> pitti: I've got patches to allow new flash to work in konqueror, when you get a moment let me know if they're suitable for SRU https://bugs.edge.launchpad.net/ubuntu/+source/kdebase/+bug/184149
<ubotu> Launchpad bug 184149 in kdebase "[hardy]xembed and flash support patches doesn't work for konqueror" [Medium,New]
<pitti> Riddell: ooh, that means that we can finally update the flash downloader in stables and put an end to this insane bug thread?
<Riddell> pitti: well, there's still Opera, I don't know if we care about it or not
<Hobbsee> claim ignorance about -commercial.  problem solved.
<pitti> well, it seems that much more people are whining about broken flash in stables than broken opera...
<pitti> and if new flash plugin breaks opera, then it should be fixed in flash or opera; not much we can do about it, AFAICS?
<Riddell> pitti: the kdebase patches for edgy and dapper are quite big, I had to backport the whole of nsplugin viewer
 * \sh should go and have a drink somehow instead of understanding ia32-libs system to write and not to write shlibs from a to b
<sistpoty|work> have some wine, \sh :P
<\sh> sistpoty|work, lol
<calc> cjwatson: i'm guessing that wouldn't work though since you already run ubiquity as root
<cjwatson> calc: (from #ubuntu-platform) the problem is that EDD involves real-mode BIOS calls
<cjwatson> calc: so there are two basic approaches that stand any chance at all
<calc> cjwatson: hmm could that be done via a kernel module at boot time?
<cjwatson> calc: one is to do it very early in kernel init
<cjwatson> calc: the other is to do it from userspace with libx86
<cjwatson> calc: the former was tried in the past, but has been known to wedge certain machines
<cjwatson> calc: unfortunately this is in a stage where there is no space to add anything fancy like a blacklist; it's right at the start of kernel bringup
<cjwatson> calc: so libx86 held out some hope of being able to do it in a more controlled fashion
<cjwatson> calc: but not unless we can make it work :)
<calc> ah :\
<calc> EFI ftw ;-)
<calc> well in all seriousness this may eventually become a dead issue (in several years) if companies start taking advantage of Vista SP1 support of EFI (at least i think it will support EFI in SP1)
<Mithrandir> I wouldn't hold my breath.
<calc> Mithrandir: yea
<calc> it will be a while from now in any case
<StevenK> People were talking about EFI by default "in several years" several years ago if I recall correctly. :-)
<Mithrandir> given that the APIC specification is 11 years old and we are still seeing various bugs related to it..
<StevenK> For an advanced interrupt controller, it's pretty dumb
<elmo> EFI is the IPv6 of the hardware world
<TheMuso> We'll only use EFI once windows uses nothing else. :p
<calc> Mithrandir: APIC bugs are fun :) (had a very buggy APIC laptop a few years back)
<calc> APIC bugs, ACPI bugs, bugs in everything :\
<TheMuso> Hrm. I have a ksoftirqd process here, thats consuming 24% CPU usage. This is gutsy.
<thom> elmo: that's pretty generous to EFI
<calc> thom: apple and ia64 use it or so i hear
<calc> but nobody else, heh
<TheMuso> Apple uses 1.1 I think.
<thom> call it the perl6 of the hardware world... :P
<Mithrandir> it should be called efi6
<Mithrandir> or bios6
<\sh> doko, pitti: should the `sed` change in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456914 be attached, it helps to generating sane shlibs file for ia32-libs, leaving out the udeb: lines
<ubotu> Debian bug 456914 in ia32-libs "ia32-libs: Missing shlibs entry for libxml2" [Serious,Open]
<\sh> doko, pitti: which are not used anyways, afaik
<doko> \sh: adding a shlibs file doesn't make sense for me. it's not used for development, you should just manually add a dependency on ia32-libs if needed
<IntuitiveNipple> Can someone give me some advice on how to ensure, when patching a package, that a source file is removed? I've been looking at the new version .diff and I can't see any sign that the file is removed.
<\sh> doko, k...let's workaround it :) thx
<Mithrandir> IntuitiveNipple: rm it in the rules file
<ScottK> IntuitiveNipple: I don't think you can actually remove a file.  You can just make it empty.  If you want to remove it, do it in debian/rules
<IntuitiveNipple> Mithrandir: In the 'build' section? It's a Makefile that shouldn't be there.
<IntuitiveNipple> ScottK: Yeah, it has to 'disappear' :)
<Mithrandir> IntuitiveNipple: build or clean
<IntuitiveNipple> Mithrandir: Ahh! clean would make sense!
<IntuitiveNipple> Thanks!
<IntuitiveNipple> I found the bug in mysql-query-browser that was causing the amd64 build to create 32-bit libraries and when run, cause SIGSEVs in gtksourcview
<IntuitiveNipple> It's taking me longer to work out the repacking than finding the bug!
<dmb> i strongly recommend we use uvesafb in hardy
<Mithrandir> dmb: why?
<dmb> it seems to work a lot better, especially with buggy bioses
<dmb> i think its in the mainline kernel now
<Mithrandir> a lot better than the VGA console?
<dmb> well, its a framebuffer console
<Mithrandir> yes, you have yet to say which problem you're trying to solve. :-)
<dmb> in gutsy, vesafb is broken
<Mithrandir> we're not using vesafb, though.
<Mithrandir> unless you ask for it explicitly.
<dmb> Mithrandir: well, i just mean being able to ask for uvesafb explicitly then
<dmb> i think its in the mainline 2.16.23, so it will probably be in hardy anyway
<evand> slangasek: so if I trigger a CD build tonight it will mess up your work, correct?
<slangasek> no
<evand> oh
<evand> fantastic then
<slangasek> I can still float earlier images as alpha candidates, or if the later ones fix key bugs you can tell me that and I'll push those instead :)
<evand> noted
<IntuitiveNipple> Can someone remind who should be subscribed to a bug report once a -proposed debdiff has been attached?
<lool> Depends whether it's an update for main or universe
<IntuitiveNipple> I suspect it's universe, since the maintainer is MOTU
<IntuitiveNipple> I was just looking in the control file but I can't recall how to determine it :(
<slangasek> by apt-cache policy; control is not authoritative
<IntuitiveNipple> thanks
<IntuitiveNipple> Yup, universe
<Mithrandir> or rmadison -u ubuntu $pkg
<IntuitiveNipple> Are you trying to confuse me?! :)
<IntuitiveNipple> Ok, so who is it I subscribe for a universe bug-fix debdiff?
<IntuitiveNipple> I've set it to gutsy-proposed, and am doing one for hardy too
<geser> IntuitiveNipple: ubuntu-universe-sponsors
<ogra> geser, i was planning to get the lib to main for tuxtype ...
<IntuitiveNipple> geser: Oh! the Wike said motu-sru
<IntuitiveNipple> s/Wike/Wiki/
<ogra> (to answer your question from last night)
<geser> IntuitiveNipple: it's for a SRU? then the wiki page is correct
<ogra> i just didnt have the time to write a MIR yet
<ScottK> IntuitiveNipple: Also for an SRU it has to be fixed in Hardy first if it's not.
<geser> ogra: no problem, I was just checking the FTBFS page and saw that tuxtype is in depwait
<ogra> on my radar ... just pushed down on my prio list
<IntuitiveNipple> geser: Ok, good.
<IntuitiveNipple> ScottK: Yes, I've published a debdiff for hardy too
<IntuitiveNipple> Maybe, if you have a few moments, you could check I've done it correctly? bug #2382
<ubotu> Launchpad bug 2382 in mysql-query-browser "mySQL Query Browser segfaults on AMD64" [High,Confirmed] https://launchpad.net/bugs/2382
<glatzor> hello bryce
<bryce> hi glatzor
<LaserJock> I need some advice from an archive admin. I need to completely replace the packaging of a set of packages in Multiverse. Would filing removal bugs and the uploading the new packages to NEW be OK?
<sistpoty|work> LaserJock: why not just upload your new packages?
<LaserJock> well, because it's a real mess
<LaserJock> the packages are changing names
<sistpoty|work> as in source packages are changing names?
<LaserJock> yes
<LaserJock> and source package names mixing with binary package names
<sistpoty|work> ah... I guess then there is no real other option, is there?
<LaserJock> that was my guess, but I wasn't sure
 * sistpoty|work isn't 100% sure either
<exarkun> If I think the latest gcc package in hardy is misbehaving, who's the best person to tell?
<ScottK> LaserJock: How does removal help?
<LaserJock> ScottK: well, I was thinking it would clean the slate
<ScottK> LaserJock: You'll still have to provide a transition for users that have the old ones installed.
<LaserJock> yeah ... well I'm figuring that out later
<ScottK> OK
<LaserJock> with FF looming I just need to get the new packaging in
<crimsun> exarkun: filing a bug report using Launchpad is recommended.
<exarkun> crimsun: Okay, thanks!
<exarkun> When I click the "Report a bug" button on bugs.launchpad.net/gcc/ I get a confusing page
<IntuitiveNipple> Anyone here familiar with gtksourceview_marshal used in gtksourceview?
<evand> exarkun: assuming you're using gcc-4.2: https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+filebug
<exarkun> evand: thanks
<evand> no problem
<\sh> cjwatson, do you want to fix some things on your gpg-key? :)
<IntuitiveNipple> Is there a way to get pbuilder to not delete the build image in the same way --save-after-exec works for execute?
<pitti> cjwatson, slangasek: do you have an idea why restricted-manager, and now jockey aren't getting on the CDs? did we have a change in germinate or cdimage to silently drop stuff from restricted?
<pitti> evand: also, can you please remind me again why r-m needed to go into restricted?
<james_w> IntuitiveNipple: I don't think so. http://blog.madism.org/index.php/2006/06/27/93-pbuilder-custom-configurations might get you what you want
<evand> pitti: gobuntu
<pitti> evand: since jockey is not limited to restricted drivers any more, I'd like to see it in main, so that we can use it for free driver updates in the future, too
<pitti> evand: right, I know that much, but why exactly?
<evand> oh, because at the time it only managed restricted things, something that gobuntu wanted to avoid entirely
<pitti> evand: at least jockey will remain completely silent (no notifications) and just don't display anything if you don't have restricted enabled
<IntuitiveNipple> Thanks.. I'm just trying to use a kvm 32-bit image now - I need to trap the build autogenerated files
<evand> fantastic, I see no problem with that going in main then
<pitti> evand: it currently Recommends: linux-restricted-modules-...
<pitti> evand: if I drop that to Suggests:, would that suffice?
<evand> yes, I believe so
<pitti> slangasek: ok for me to move jockey from restricted to main to circumvent whatever makes it disappear from the CDs?
<pitti> evand: ok, thanks
<slangasek> pitti: well, no problem for me
<popey> I know this is a premature question, but does anyone have any clues as to the location of the next UDS?
<popey> (for those of us that need to think about budgets)
<james_w> how about popey's house?
<popey> yay!
<popey> might be a _bit_ of a squash
 * popey imagines the wifes reaction
<popey> "Few friends coming over.. nah, they're not staying long.. few days.. I'll get my coat"
<slangasek> popey: "Europe" is next on the rotation; there's a tentative venue selected, but I hesitate to spread it too widely before it's confirmed
<popey> is it? I thought Asia would be next
<popey> ah well, Europe is easier for me, so if that comes off, that would be smashing.
<cjwatson> LaserJock: it would be best not to remove the package, otherwise you can end up downgrading by accident which would be bad
<cjwatson> \sh: tell me what's wrong with it
<\sh> cjwatson, your subkey has some sigs on it and breaks some apps which are not ignoring them like gpg
<cjwatson> feel free to refer me to documentation
<\sh> cjwatson, we (misa from rpath.com and I) were tracking this problem down to your key, because something went wrong during my test of foresight linux .. http://lists.gnupg.org/pipermail/gnupg-devel/2008-January/024232.html is what gnupg guys are saying...
<\sh> cjwatson, documentation about it: rfc4880 section 12.1 :)
<LaserJock> cjwatson: ok, I was just afraid of having multiple source packages producing the same binaries, but it seems that's not a problem
<StevenK> slangasek: Will you hate me if I upload a new libhildon?
<\sh> cjwatson, no worries about it, just wanted to inform you
<TheMuso> popey: I doubt that Asia will be considered any time soon.
<cjwatson> I don't have a problem with removing them, but am not convinced that me doing so will have any effect on keyservers
<cjwatson> \sh: ^--
<cjwatson> LaserJock: nope, that's fine
<cjwatson> (ish)
<\sh> cjwatson, yepp...that's one true problem...but hopefully, most software will ignore those sigs
<LaserJock> cjwatson: I think it should only be temporary, I'll file removal requests for the deprecated packages after the new packages are in
<cjwatson> gpg says "gpg: moving a key signature to the correct place" six times when I run it and seems to have shuffled them over
<cjwatson> \sh: I've sent it; that's all I can do
<\sh> cjwatson, as I said, just FYI :)
<cjwatson> \sh: doing a --recv-keys adds them straight back again
<cjwatson> \sh: so if it's actually breaking something, somebody's going to have to make software more lenient, or get a keyserver admin to fix it on the keyservers; I am powerless
<elmo> you can't do the latter
<elmo> it needs to be the former
<\sh> cjwatson, yepp...keyservers will preserve the sigs ... so nothing to worry about, we just stumbled upon it...and software is going to be fixed for rpath :)
<elmo> the keyserver network is too distributed for fixing individual keys to be viable
<cjwatson> elmo: I thought not, but they stood a better chance than the poor key owner ;)
<cjwatson> so this means that every time I run gpg --edit-key --send-keys --recv-keys I'm going to grow six signatures on my key
<cjwatson> which seems, er, suboptimal
<slangasek> StevenK: is libhildon seeded on any CDs?
<StevenK> slangasek: Nope
<StevenK> slangasek: Just seeded by -mobile
<slangasek> StevenK: then it's all you
<StevenK> slangasek: Cool, I'll upload it.
<\sh> cjwatson, I wonder why someone signed your subkey at all? :)
<cjwatson> \sh: I didn't tell them to :-P
<\sh> cjwatson, :)
<james_w> StevenK: any thoughts on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452687 ? I realise it may just be pulling up a one off patch from the distant patch.
<ubotu> Debian bug 452687 in bacula "bacula: Catalog backup fails: incorrect parameters format for make_catalog_backup" [Normal,Open]
<james_w> distant past, sorry.
<calc> how big is a full mirror of a.u.c?
 * calc ponders buying a server to mirror the full archive
<calc> or an extra hard drive to do it
<jpatrick> calc: more than 120GB I think
<calc> jpatrick: ah thats not too bad
<jpatrick> calc: last time I read what archive.*'s size was
<elmo> bigger
<calc> hmm mirror page says 220GB
 * calc might need an extra hard drive
<elmo> that's out of date now
<elmo> it's closer to 250GB
<elmo> roll on edgy being obsolete
<Nafallo> when edgy becomes obsolete hardy should be stable though... and there will be another release cycle ;-)
<calc> ah ok
<calc> phasing out releases won't reduce the amount required...
<calc> Nafallo: it will just keep growing :)
<Nafallo> calc: yea, I know.
<calc> hmm i should get a 750gb from fry's when i see one on sale
<Nafallo> calc: soon two LTSes in the archive to start off with :-)
<calc> Nafallo: yea
 * calc is lucky to have 3 fry's within an hour of where he lives
<LaserJock> calc: 3 Fry's?
<LaserJock> that's pretty good. I've got 2 within 2hrs
<articpenguin> how can i request for an updated package
<calc> LaserJock: at least iirc we have 3 in houston
<calc> LaserJock: 1 about 10m away
<calc> LaserJock: of course Houston is pretty big there is a much higher concentration of them in the valley
<LaserJock> articpenguin: file a bug, make it "wishlist", and tag it "upgrade", I believe
<LaserJock> calc: ah, I've got 2 in Sacramento
<IntuitiveNipple> Is there a standard method in Makefiles to switch between building shared libraries and static (I'm trying to cause AR to put some .o files into a .a rather than creating .so) ?
#ubuntu-devel 2008-01-31
<slangasek> crimsun: AFAICS you're not currently subscribed to bugs for pulseaudio; but perhaps you could take a look at bug #187469 since you're the last uploader?
<ubotu> Launchpad bug 187469 in pulseaudio "pulseaudio should have versioned dependency on sysv-rc for use of update-rc.d multiuser" [Medium,Confirmed] https://launchpad.net/bugs/187469
 * TheMuso checks whether he is on the audio team, but doesn't think so.
<TheMuso> Ok, the kernel team is a member of the audio team, but crimsun deactivated himself a while ago.
<slangasek> right; that didn't stop him from uploading the package 5 days ago ;)
<TheMuso> I know, I think he just tracks debian and upstream.
<TheMuso> And has a look at the buglist from time to time.
<TheMuso> But I'm only guessing here.
<slangasek> if you're saying you'd rather take care of the bug yourself, be my guest :-)
<TheMuso> No, I'm just saying that unless he's around now, he may not get to it for another day or so, so I'll take a peak, since I intend to get more involved with audio work in Ubuntu anyway.
<TheMuso> slangasek: I'd do it, however it may be quicker for a core-dev to do it, as I don't yet have core-dev membership.
<TheMuso> Since its only a small change.
 * ScottK2 wonders when the Tech Board will get to processing applications....
<TheMuso> ScottK: I was supposed to be on Tuesday, but only mdz was around, so it was a no go.
<ScottK2> So it's in two weeks then ...
 * ScottK2 hopes more people get added to the agenda.
<TheMuso> DOn't know. mdz said he'd contact the others and see what could be sorted.
<TheMuso> ScottK: Have you been emailed to ask if you can attend a meeting?
<TheMuso> I don't remember seeing one.
<TheMuso> If it was CCd to the mc list.
<ScottK2> TheMuso: No.  I haven't.  I'm waiting on that still.
<ScottK2> IIRC I was the next applicant after you, so I was expecting to hear something maybe after your meeting.
<IntuitiveNipple> Is there a way to remove unnecessary binary files from a source package?
<IntuitiveNipple> The diff doesn't cover it; seems like it'd need a new source archive.
<Mithrandir> IntuitiveNipple: rm it in the rules file
<IntuitiveNipple> Mithrandir: but how would that change what's in the original tgz ?
<Mithrandir> IntuitiveNipple: it wouldn't
<Mithrandir> but why is that important?
<ScottK2> For that you need to repack the tarball.
<IntuitiveNipple> I discovered in fixing these bugs in the mysql-query-browser package that it has been shipped with the .lo and .o 32-bit binaries in the gtksourceview sub-package
<IntuitiveNipple> Well, it's a lot of space for one, not good practice for two, and the 32-bit static stuff was causing various SIGSEGVs for amd64 and once those were fixed, causing failed 32-bit builds!
<IntuitiveNipple> I'll push the debdiff for now but it'd make sense to clean it up, although I'm not sure how to go about and I've wasted a day on this already
<Mithrandir> sure, tell upstream to fix it
<crimsun> slangasek: / TheMuso: on it, I'll upload a new one with a couple other bug fixes.
<TheMuso> crimsun: Ok.
<IntuitiveNipple> upstream would be... debian, or mysql?
 * TheMuso needs to get onto pulse's lists and bug tracker. :)
<Mithrandir> IntuitiveNipple: mysql, I'd say.
<IntuitiveNipple> Hmmm, that'll be fun :)
<IntuitiveNipple> I've built 32 & 64 bit here now, I'm just confirming it on my PPA before I publish the debdiff
 * TheMuso -> getting lunch.
<dholbach> good morning
<stgraber> moin
<dholbach> hi stgraber
<pitti> Good morning
<TheMuso> Morning pitti.
<pitti> hey TheMuso
<pitti> soren: oh, oops; libvirt is in main, but needs xen; xen-3.1 is in universe, and the newer xen-3.2, too
<pitti> soren: since I understood that we only want to support kvm in hardy
<pitti> soren: any idea what to do about this?
<pitti> soren: (and libvirt still uses xen 3.1)
<stgraber> pitti: When will the first Alpha4 candidates be released ?
<pitti> stgraber: I don't know, that's slangasek's now
<pitti> stgraber: the current live images are out of date
<pitti> maybe because of the gnome-control-center and gnome-settings-daemon file conflict, I haven't checked yet
<warp10> Good morning
<soren> pitti: libxen3.1 at least used to be in main?
<pitti> soren: yes, it was
<pitti> hi warp10
<soren> pitti: It was needed for libvirt which in turn was needed by redhat-cluster-suite.
<warp10> hey pitti!
<dholbach> bdmurray: do you plan to get new versions of py-lp-bugs and bughelper uploaded soon?
<soren> pitti: What changed?
<pitti> soren: if the server team is really ready to support and endorse xen-3.2, I can promote it again
<pitti> soren: changed> first, we got xen-3.2, and second I was told by mdz that we should have never really had xen in main in the first place
<soren> pitti: Well, afaik, we were never ready to support and endorse xen-3.1, which is why most of it stayed in universe. Only libxen was in main.
<pitti> soren: and thirdly someone told me that 'kvm it is!' for hardy
<pitti> soren: ok, I see
<soren> pitti: I see.
<soren> pitti: Erm..
<pitti> soren: so, is it possible to build libvirt against xen-3.2?
<pitti> soren: then I'll promote the client libs to main and leave the rest in universe
<soren> pitti: I'll try.
<soren> pitti: Er... It's still stuck in NEW.
<soren> mvo: What CPU do you have in that KVM-able AMD machine?
<pitti> soren: what exactly?
<soren> pitti: xen 3.2
<pitti> soren: hm, it only built on i386 so far
<soren> pitti: Yeah. I'll poke zul about it this afternoon, when he shows up.
<soren> pitti: It seems to fail because the binary-arch target assumes latex is present, but texlive is int b-d-i.
<pecisk> gnome-settings-daemon broken in last updates
<mvo> soren: a am2 X2 (model 107, stepping 2) - let me know if you need the full /proc/cpuinfo output
<soren> mvo: Hm... I'm looking at a AMD Athlon 64 X2 5600+
<soren> mvo: That wouldn't happen to be the same, would it?
<mvo> soren: no, mine is just a 4400+ :)
<mvo> soren: are you looking into buying one?
<soren> mvo: I'm strongly considering renting one.
<coyctecm> Is Jono Bacon here?
<mvo> I'm very happy with mine, upgrade testing runs nice and smooth now
<soren> Awesome.
<soren> There. Ordered.
<cjwatson> coyctecm: sometimes, though not right now
<coyctecm> cjwatson, ok
<cjwatson> pitti: FYI, I edited Bugs/HowToFilter to add locking to the rules that deliver mail to actual folders rather than /dev/null, as otherwise you can corrupt folders if you're unlucky
<pitti> cjwatson: oh, is that the final : in :0: ?
<pitti> cjwatson: thanks, I wasn't aware of that actually
<cjwatson> yeah, it is
<pitti> cjwatson: wow, I hadn't expected procmail to be dangerous by default
 * pitti fixes his local .procmailrc then
<TheMuso> pitti: What exactly needs fixing? Mine seems to work fine.
<pitti> so does mine; TBH I'm not sure what can go wrong
<cjwatson> if two procmails try to deliver to the same folder concurrently and you haven't specified a lockfile (just putting ':' at the end of the rule header uses a default folder-specific lockfile) then you can get the usual corruption you might expect from two programs trying to write the same file at the same time
<cjwatson> probably lost mail, but if you're really unlucky I suppose interleaved mail is just about possible
<soren> Maildir ftw!
<cjwatson> (I'm not sure exactly how procmail opens files)
<cjwatson> soren: a lockfile's hardly rocket science :)
<soren> cjwatson: True that.
<soren> Nevertheles.... Maildir ftw!
<pitti> I prefer maildir on my desktop/laptop, too, but on the server mbox is nicer for backup
 * TheMuso never runs more than one procmail at a time here, well at least doesn't think so, with using fethcmail.
<soren> pitti: You think?
<pitti> soren: ten files, one for each folder, is much easier to handle/check/move around than a million subdirectories
<soren> pitti: I found that having to back up a multi-GB mbox just because one mail was edited was quite annoying.
<pitti> soren: yeah, huge mboxes are painful; I don't have them, though
<soren> pitti: Well, I used to host mail for quite a few people. I couldn't just tell them to "please don't use large folders" :)
<soren> WEll, I could, but they wouldn't listen.
<pitti> heh
<TheMuso> soren: lol
<dholbach> pitti: thanks for checking the apport mail (attachments being patches)
<pitti> dholbach: gern geschehen
<SlimG> Will Alpha 4 be released today?
<stgraber> SlimG: yep
<cjwatson> TheMuso: on my system, fetchmail delivers to exim, which can process multiple mails concurrently
<cjwatson> (sorry, pinged out, you may have got that twice)
<TheMuso> cjwatson: No I didn't, and I understand what you're getting at.
<SlimG> stgraber: Any knowhow on when? 1 hour? 5 hours or 11 hours from now? :)
<stgraber> SlimG: well, the release manager is in the US timezone + we haven't really done any important testing yet (ISO aren't even on the tracker)
<stgraber> SlimG: so it'll likely be late today
<SlimG> mkay, thanks for the info stgraber, I apprechiate it
<pitti> way cool. fully noninteractive self tests of the jockey GTK interface
<TheMuso> Is synaptic ever likely to use policykit for hardy?
<mvo> TheMuso: no, very unlikely
<mvo> pitti: with dogtail?
<pitti> mvo: no, just with using .response() for dialogs and .emit('clicked') etc. for buttons
<pitti> mvo: it's not 100% functionality coverage, but it runs through all widgets and dialogs at least
<pitti> mvo: since the GTK UI implementation does not have any logic, just an implementation of AbstractUI (which does have the logic and has its own full test suite), that's enough for my purposes
 * mvo nods
<TheMuso> mvo: Ok thanks. What about gnome-app-install?
<mvo> TheMuso: it uses synaptic as its backend (for all the operations that require root)
<TheMuso> mvo: Oh ok then.,
<mvo> TheMuso: any specific reason that you ask? I haven't looked what it would take yet
<TheMuso> mvo: Just wanting to know so that I can 1) recommend a tool for people to use for package installation who use assistive technology, and 2) be able to target testing for gnome-app-install to find any accessibliity bugs relating to the use of assistive technology.
<cjwatson> ooh, I nearly have vim omnicompletion for Launchpad bugs working
<pitti> seb128: did you notice the gnome-settings-daemon vs. gnome-control-center file conflict for /usr/bin/gnome-settings-daemon?
<seb128> pitti: yes, I'll upload a fixed version
<pitti> seb128: awesome, thanks; so I won't report it
<seb128> pitti: that's just an upgrade issue, new g-c-c doesn't contain this one
<seb128> apt or dpkg could handle that better
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/lp-omnicomplete.png
<pitti> cjwatson: cool!
<soren> cjwatson: Awesome!
 * soren drools uncontrollably
<Hobbsee> hi soren
<soren> Hello.
<soren> 'zup?
<Hobbsee> soren: taking over the world.  pondering what to do, if anything, about MOTU.
<warp10> Hi all!
<cjwatson> Riddell: fancy some support for non-ASCII manual pages in konqueror?
<Riddell> cjwatson: in the man:/ ioslave?
<cjwatson> yeah
<Riddell> cjwatson: could do, what needs changed?
<cjwatson> about to attach a patch to bug 44548, just wanted to know if you cared :)
<ubotu> Launchpad bug 44548 in kdebase "Problems with accentuated characters in man pages" [Medium,Confirmed] https://launchpad.net/bugs/44548
<Riddell> cool
<jwendell> Hi, seb128. Did pidgin crashed today with you? (I guess it's glib related)
<seb128> jwendell: it does crash on one of my boxes but not on the one I'm using right now
<ogra> seb128, is g-s-d wanting to overwrite /usr/bin/gnome-settings-daemon in g-c-c known ?
<ogra> (upgrade error here)
<jwendell> seb128, I've got a trace, gonna fill a bug
<seb128> ogra: yes and the fix has been uploaded some hours ago
<seb128> jwendell: where?
<jwendell> seb128, launchpad? :)
<seb128> jwendell: I doubt anybody reads piding bugs on launchpad, in case you want to file there
<ogra> seb128, thanks
<jwendell> :(
<seb128> jwendell: k, feel free, don't expect a quick reply though
<seb128> jwendell: and I doubt it's a pidgin issue, it didn't change for weeks now
<jwendell> seb128, my guess is glib
<jwendell> seb128, look at the crash line:
<jwendell> IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=0xb77b0cd4 "%s: assertion `%s' failed", args1=0xbfe9cd8c "?G\216Â·\nÃ\215Â·PÃÃ´Â·\027") at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:503
<jwendell> 503	/build/buildd/glib2.0-2.15.4/glib/gmessages.c: No such file or directory.
<jwendell> 	in /build/buildd/glib2.0-2.15.4/glib/gmessages.c
<seb128> that usually means it hits an assert
<jwendell> seb128, maybe that define in glib being deprecated?
<seb128> what do you mean?
<jwendell> seb128, G_GNUC_[PRETTY_]FUNCTION ?
<seb128> why would that create a crash?
<seb128> that's a build time thing
<jwendell> seb128, ok, I'm sorry
<seb128> no need to be sorry
<seb128> but I don't think it's due to that ;-)
<seb128> jwendell: looks like there is no bug on launchpad about that yet, maybe use apport to send it?
<jwendell> seb128, apport is ignoring the pidgin crash
<seb128> what do you mean?
<jwendell> seb128, does it ignore a crash after three times hitting 'don't send the bug' button?
<seb128> yes
<jwendell> hehe
<jwendell> seb128, anyway I got a backtrace with gdb
<jwendell> seb128, just filled the bug upstream
<seb128> you can still send the crash using apport
<seb128> ok
<seb128> just go to /var/crash
<seb128> and double click in nautilus on the crash you want to report
<jwendell> nice
<seb128> or use apport-cli or apport-gtk
<jwendell> seb128, the backtrace contains my password. Is there any way to hide it after the bug is filled?
<seb128> apport bugs are marked private by default
<seb128> and you can edit the description after sending it
<seb128> the coredump is removed when the bug is retraced
<jwendell> seb128, but can't edit an attachment :(
<seb128> hum, right
<seb128> did you send it already?
<jwendell> seb128, nope
<seb128> you can remove an attachment though
<seb128> don't send it if you don't like that
<jwendell> seb128, sent *edited" backtrace to upstream
<seb128> ok
<soren> Wow... a debhelper-less package. That's something you don't see every day.
<seb128> soren: I've plenty of cdbs packages ;-)
<soren> seb128: cdbs uses debhelper, too. This one is *actually* debhelper-less.
<Seveas> soren, which one?
<seb128> heh, is that something still maintained?
<soren> Seveas: dnsmasq
<soren> Seveas: Oh, yes.
<soren> Er..
<seb128> soren: I wrote a debian/rules without debhelper once, not again ;-)
<soren> seb128: Oh, yes.
<Riddell> pitti: I've uploaded the konqueror flash SRUs ready for your next archive day
<Riddell> pitti: I can't work out what the status of the flashplugin-nonfree SRUs is
<jwendell> ohhhh
<jwendell> i just did a 'rm *' on my $HOME. is there an 'undelete'?
<persia> jwendell: Restore from backups
<cjwatson> jwendell: no, sorry
<cjwatson> there are some low-level methods for doing it on some filesystems but they are much less likely to work on ext3
 * persia notes that there are data recovery tools, but they are not easy to use, and installing them can cause data corruption
<cjwatson> if you want to try, you should remount the filesystem read-only immediately
<ogra> if you want to use them though i'd suggest hitting the power button immediately
<ogra> oh, right
<jwendell> fortunately I have a backup, from last week. And, for my luck, I didn't '-rf'
<ogra> colins suggestion is better :)
 * ogra did that recovery thing once ... massively painful
<Riddell> asac: I think we should just do a quick SRU for
<Riddell> flashplugin-nonfree now
<persia> Riddell: Even if it breaks konqueror (or did that get fixed)?
<Riddell> persia: that's been fixed noew
<asac> Riddell: how?
<Riddell> now
 * persia agrees with Riddell that's it's time for the SRU
<Riddell> asac: update the md5sum and whatever else needs done
<asac> where? by adobe or konqueror?
<Riddell> asac: konqueror has a workaround for adobe's changes
<asac> Riddell: could you do it this time? ... i am completely swamped because moz has changed sec release date from "in two weeks" to "now"
<asac> i could do it tonight ... or tomorrow
<Riddell> asac: I can probably do it, but is it just the md5sum that needs changed?
<Riddell> brandon did an upload previously but I can't see any debdiffs from him
<Riddell> imbrando1: alive?
<asac> ok lets wait a bit ... if he isn't avail we can talk about plan B :)
<asac> have to go for lunch anyway now
<cjwatson> seb128: do you know the internals of yelp much?
<seb128> cjwatson: no, why?
<cjwatson> seb128: I'm trying to make it support UTF-8 manual pages by calling out to 'man --recode UTF-8'
<cjwatson> err, support any non-ASCII manual pages that is
<cjwatson> seb128: but weirdly, with my patch it says it can't find the file and then displays it anyway :)
<seb128> cjwatson: maybe attach the patch upstream and mention the issue? they are usually quite responsive
<cjwatson> it's not an upstreamable patch unfortunately
<cjwatson> as in it depends on man-db which is distro-specific
<seb128> ah, ok
<cjwatson> whom would I be best off talking to?
<mitsuhiko> hi all
<mitsuhiko> completely offtopic question but hopefully answers :)
<seb128> cjwatson: maybe ask mdke when he's around, he's often in contact with DonS who is upstream
<mitsuhiko> say you want to develop a gpl application which uses tango icons which are licenses under the cc-sa
<mitsuhiko> and the application is a web application and the icons used as part of the theme
<mitsuhiko> is that possible?
<seb128> cjwatson: open a bug in launchpad with the patch so it's easy to point upstream to it
<cjwatson> I'll attach it to bug 154829, which is the relevant one
<ubotu> Launchpad bug 154829 in yelp "Yelp uses wrong encoding for localized manpages" [Low,Triaged] https://launchpad.net/bugs/154829
<cjwatson> thanks
<seb128> thank you
<jwendell> seb128, definately it' a glib bug. I got exactly same backtrace for a crash in evolution
<seb128> jwendell: do you have the backtrace online somewhere?
<seb128> jwendell: what do you do to crash evolution?
<jwendell> seb128, I was about to create a filter based on mailing list
<jwendell> seb128, wow, there are similar bugs
<jwendell> bug #187603
<ubotu> Bug 187603 on http://launchpad.net/bugs/187603 is private
<jwendell> bug #187637
<ubotu> Bug 187637 on http://launchpad.net/bugs/187637 is private
<seb128> jwendell: those are totally different backtraces
<jwendell> seb128, but the title is the same :)
<jwendell> seb128, Bug #187667
<ubotu> Bug 187667 on http://launchpad.net/bugs/187667 is private
<jwendell> seb128,  this is mine
<seb128> jwendell: right, which means that a g_return_if_fail_warning() condition has been hit
<jwendell> seb128, exactly
<seb128> jwendell: but any program or library can use g_return_if_fail_warning() on any condition
<seb128> that doesn't mean it's a glib bug or that they are similar
<jwendell> seb128, indeed, but it's a bit weird to have various programs crashing *today* with this same assert
<seb128> dholbach: is pidgin crashing on your hardy box where evolution doesn't work?
<pochu> jwendell: and your liferea crash too, bug 187622
<ubotu> Launchpad bug 187622 in liferea "liferea-bin crashed with signal 5 in IA__g_return_if_fail_warning()" [Medium,New] https://launchpad.net/bugs/187622
<seb128> jwendell: can you try if downgrading glib fix your issue?
<jwendell> pochu, yes
<seb128> ah
<jwendell> seb128, sure, if you tell me how :)
<seb128> let me try something
 * jwendell thinks seb128 found the problem :)
<seb128> jwendell: how to trigger the evolution crash?
<seb128> jwendell: not really
<jwendell> seb128, right click on a message, create an rule->based on mailing list
<seb128> jwendell: does opening the properties dialog work correctly?
<jwendell> seb128, what properties? you mean preferences window?
<seb128> jwendell: yes
<jwendell> seb128, oops, crash again
<Lutin> pitti: can you give-back rtfm please ?
<pitti> Lutin: done
<Lutin> pitti: thanks
<\sh> hmmm
<\sh> pitti, did you have any problems with gtk+2.0 sources fetching with ia32-libs/fetch-and-build?
<pitti> \sh: if source/binaries are out of sync, that happens
<\sh> pitti, hmm..let me update my local system...apt-get source gtk+2.0 works for me until now ;)
 * jwendell wonders if seb128 has 2 machines, one for daily use and other for tests and crashes :0
<jwendell> :)
<\sh> pitti, na, it will fetch a nwe version, yes but works
<\sh> ah i386
<seb128> jwendell: no, not due to the new gtk
<seb128> jwendell: what architecture do you use?
<jwendell> seb128, i386
<ion_> Btw, has anyone considered making dpkg use a faster database than plaintext sequential files?
<Riddell> asac, pitti: flashplugin-nonfree updates uploaded for gutsy and feisty, edgy and dapper are harder to do
<\sh> nope i386 works as well
<seb128> jwendell: https://launchpad.net/ubuntu/+source/glib2.0/2.15.3-0ubuntu1/+build/496254
<seb128> jwendell: you can get binaries from there, download those you need and sudo dpkg -i *.deb
<Lutin> pitti: why don't the buildds install the build-depends-indep (or at least seem not to) ?
<jwendell> seb128, same thing. (must i reboot?)
<seb128> jwendell: no need to reboot, just restart the application
<seb128> jwendell: or try to start pidgin
<pitti> Lutin: the i386 one does; other arches don't (they just do dpkg-buildpackage -B)
<jwendell> seb128, same crashes in pidgin and evolution
<seb128> jwendell: ok, so that's not glib
<seb128> jwendell: want to try downgrading gtk? https://launchpad.net/ubuntu/+source/gtk+2.0/2.12.5-1/+build/495133
<Lutin> pitti: what's the reason for this ?
<pitti> Lutin: Arch: all should be built just once, not 5 times in vain
<pitti> Lutin: so in Ubuntu, the i386 buildds build Arch: all packages, and the other arches do -B
<pitti> Lutin: that's why we have one more i386 buildd
<jwendell> seb128, I quit, same crashes
<seb128> jwendell: that is weird
<cjwatson> pitti: is anyone working on adding consolekit support to login?
<Lutin> pitti: eek, I was looking at the wrong build log. got it, thanks
<cjwatson> I'm a bit surprised that isn't there
<pitti> cjwatson: not to my knowledge ATM; there is a PAM integration package for CK, but I never tested it; do we need it?
<jdong> are there any archive admins online that can shove transmission 1.00-1~gutsy1 through binary NEW?
<jdong> it's causing repo breakage for backports users (bug 187526)
<ubotu> Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526
<asac> Riddell: why?
<asac> Riddell: konqueror not updated yet? (thanks btw)
<mpt> dholbach, remind me, how do you tell whether a bug is in the sponsoring queue?
<dholbach> seb128: yes :)
<dholbach> mpt: if ubuntu-{universe,main}-sponsors is subscribed
<jdong> dholbach: can you handle the archive issue I mentioned above?
<mpt> dholbach, excellent, thanks
<dholbach> jdong: no, I'm afraid I'm not an archive admin
<dholbach> (which is probably a good thing)
<jdong> dholbach: oh, I could've sworn you were! oops :)
<seb128> jdong: I'm one, what do you need?
<jdong> seb128: it seems like i386 gutsy-backports transmission is stuck in binary NEW while everything else went through
<jdong> bug 187526
<ubotu> Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526
<seb128> jdong: everything else had no need binaries likely?
<Riddell> asac: edgy and dapper are harder to do because they need updating from flash 7 and there's debconf stuff.  it didn't work when I tried at any rate, probably I just missed somehting
<jdong> seb128: yeah, that's what I'm guessing. the transmission metapackage seems new
<jdong> seb128: though it's really odd it seems like only i386 had the problem?
<seb128> jdong: no, what is new is the transmission-common
<jdong> ah
<mpt> dholbach, would it make sense for the sponsoring queue to be handled more explicitly by Launchpad, rather than by subscribing/unsubscribing a particular team?
<seb128> jdong: only i386 build arch all
<jdong> well that explains that too :)
<dholbach> mpt: how do you think that should happen?
<seb128> jdong: accepted
<mpt> dholbach, I don't know -- I'm sure you or someone has explained to me how the queue works at some stage, but I've forgotten
<mpt> but Launchpad should make easy the process of getting stuff fixed
<dholbach> mpt: in the perfect world we'd have NoMoreSourcePackages and everything would be in one or the other bzr branch :-)
<jdong> seb128: thanks :)
<seb128> you are welcome
<mpt> dholbach, ah, so sponsoring would be replaced by merging?
<dholbach> mpt: yes
<mpt> ok
<mpt> Is NoMoreSourcePackages likely to happen in the next, say, 3 years?
 * jdong gives mpt the optimism award of the day
<cjwatson> mpt: maaaaaybe
<mpt> jdong, no no, I'm being pessimistic, that's about how long it would take to implement anything sponsorship-queue-specific in LP ;-)
<\sh> pitti, requestsync is broken ;) There is no project named 'distros' registered in Launchpad. ;)
<ogra> if we all work towards it it should be achievable ...
<\sh> pitti, forget it, I'm using an old one
<jdong> it's a lot of infrastructure change, but I can't wait for it to happen :)
<pitti> \sh: it's in ubuntu-dev-tools nowadays
<\sh> pitti, yepp..I just had the old one still in my all the time in svn ~/bin/ dir ;)
<sistpoty|work> mvo: can you sponsor me nvidia-settings again? bug #178255 (though I must admit, that I didn't test-build it since I added the debdiff)
<ubotu> Launchpad bug 178255 in nvidia-settings "NVCtrl.h and NVCtrlLib.h should be installed in /usr/include/NVCtrl not /usr/include" [Undecided,Confirmed] https://launchpad.net/bugs/178255
 * ogra kicks evo in the guts  .... with run-up 
<ogra> evil thing ...
<Hobbsee> mpt: ah yes, but how long for it to be fixed, after it being *broken* in LP?
<Hobbsee> :)
<mpt> eh?
<Hobbsee> mpt: first implementations are often wrong :)
<seb128> ogra: what did it do?
 * ogra cries ... why does my mailer have to be so mean to me *sniff*
<ogra> seb128, it decided to collapse all threads after the last crash
<mpt> because no-one's implemented a good one yet? :-)
<ogra> and obviously the 2exapnd all threads" function always only expands one level
<seb128> ogra: ctrl-T
<ogra> i'm clicking my ass off to get to the last (new) message in a thread here
<ogra> seb128, yay, now all collapsed again
<ogra> ctrl-t wasnt such a good idea
<seb128> do it again
<ogra> it switches threading off/on but doesnt expand the threads
<Hobbsee> does * do anything?
<ogra> actually if i expand one it collapses it again
<ogra> i'll just click my way through
<ogra> oh, another restart helped :)
<\sh> ogra, use claws ,-)
<ogra> \sh, or balsa :)
<seb128> evolution is good
<\sh> ogra, hmm..balsa...tested it only once....I like claws now ;) it works ;)
<ogra> balsa doesnt have much overhead ... thats what i like about it
<ogra> claws ... to many options i'll never need ...
 * ogra remembers times where mail clients were 300k big :)
<\sh> cjwatson, how do I tell your new "show LP bugs" addon to sort for importance e.g.? :)
<ogra> which gui mail client comes with less than a meg nowadays .... ?
<\sh> ogra, these days all mail clients were named mail, elm, pine (or mutt) ;)
<stgraber> ogra: telnet is 90k here :)
<ogra> stgraber, gui :)
<\sh> ogra, gnome-terminal -e telnet <your mailserver> 110|143 is gui ,-)
<ogra> :P
<cjwatson> \sh: you edit it
<pochu> \sh: gnome-terminal -e is broken :P
<cjwatson> it ought to be possible to make the sorting cleverer; I didn't because I had already spent too much time on it
<\sh> cjwatson, and when I'm on it, I could add a "stop adding bugnumbers when hitting ESC"
<\sh> cjwatson, but cool stuff, I have to say...thx for that :)
<bdmurray> dholbach: today or tomorrow
<dholbach> bdmurray: rock and roll
<\sh> pochu, gnome-terminal -e "telnet whereever 143" works for me :)
<cjwatson> \sh: yeah, it's not interruptible at the moment
<cjwatson> I'd be entirely happy for somebody to take it on and improve it
<cjwatson> ':help complete-functions' has some advice on making completion functions interruptible
<\sh> cjwatson, I'll have a look :)
<cjwatson> cheers
<jwendell> seb128, can it be possible that glib or similar package was built with fatal asserts flag on?
<jwendell> seb128, so, instead of just a warning, it crashs?
<pedro_> jwendell: may you check the G_DEBUG environment variable?
<pitti> seb128: hm, did you notice that nautilus recently started to create icons for internal drives/mounts? that can also be seen on the live CD
<jwendell> pedro_, fatal_criticals
<jwendell> pedro_, is that?????
<pedro_> aham!!
<pedro_> tha's the guilty!
<jwendell> putz
<pitti> seb128: I've got it on my desktop, too, and ogra had a similar problem on edubuntu last week
<jwendell> pedro_, where the hell did I put this???
<pedro_> yeah that's it
<pedro_> i don't know!
<pedro_> just found that a few minutes ago
<pitti> seb128: I'll have a look into this next week, but I might have some questions
<pedro_> got the same crashes and i just looked in case of
<pedro_> but don't know what package defined it recently
<pedro_> it shouldn't be
<pedro_> i mean not for normal users
<jwendell> pedro_, yeah
<pedro_> gotta run now, my food is waiting me
<jwendell> pedro_, thanks
<seb128> pitti: right, nautilus started using gvfs instead of gnome-vfs
<seb128> pitti: and I didn't port the patch to ignore mnt mounts for example
<pitti> seb128: ah, so I guess our previous patches to adopt the showd mounts doesn't work any more
<jwendell> seb128, found the problem
<jwendell> G_DEBUG variable
<seb128> jwendell: ah?
<jwendell> seb128, where is it being set?
<seb128> jwendell: ah, gnome-session
<jwendell> seb128, hard-coded?
<seb128> jwendell: they set it during unstable branch to get bugs about critical warning, we usually patch it out but I didn't look at that when I did the update
<jwendell> seb128, hehe
<\sh> cjwatson, CTRL+E is just that what it needs to end completion :) I wonder how to map it to esc in this case
<pochu> jwendell: will you close your liferea bug or shall I?
<jwendell> pochu, let me do it
<pochu> jwendell: thanks
<seb128> jwendell: unset G_DEBUG
<seb128> jwendell: then run your application
<seb128> dholbach: ^
<cjwatson> \sh: I think the completion function needs to call complete_check occasionally
<jwendell> seb128, yes, I did this ;)
<seb128> jwendell: I'll fix it now
<jwendell> seb128, thanks
<seb128> jwendell: thank you for the work there
<dholbach> seb128: all "good" again
<dholbach> :-)
<seb128> so those are not new bug
<seb128> but what GNOME looks like when warning are crashers ;-)
<seb128> and that's why I do patch this out usually
<jwendell> seb128, I've got a headache, really :)
<jwendell> seb128, I'm going to open a bug against gnome-session and mark all these kind of bugs as dupe
<seb128> jwendell: they are not, they are valid bugs
<seb128> jwendell: they are just warning, not crashers
<jwendell> seb128, well, those kind of bugs should be forwarded upstream btw
<seb128> jwendell: that's just that nobody bother about those usually, that's why GNOME guys make gnome-session set G_DEBUG during unstable cycle
<cjwatson> ogra: sigh, I see what mccann means about privsep causing issues - PAM is just called too early
<slangasek> stgraber: hardy alpha 4 candidates for ubuntu are up, finally; sorry for the delays
<cjwatson> no way am I changing that though
<stgraber> slangasek: ok, how long do we have for testing ?
<slangasek> stgraber: uh, as long as necessary; if the milestone release has to be pushed back until tomorrow, then that's what it'll be
<seb128> ok everybody, gnome-session was setting G_DEBUG to make application crash on warnings since yesterday, that's something upstream do during unstable serie and that we don't usually
<seb128> so if you received crashers in g_return_if_fail_warning(), those are warnings
<slangasek> seb128: er. that means this is on the CDs, I guess?  Will that cause problems in practice?
<slangasek> i.e., how much is crashing with this?
<dholbach> evolution and pidgin are for me
<seb128> slangasek: well, pidgin and evolution were crashing for some people here
<slangasek> sigh
<seb128> slangasek: but that doesn't seem to happen to everybody, might be config dependent
<slangasek> see, /now/ you're in trouble for uploading this during the alpha freeze ;)
 * seb128 hides
<slangasek> well, it is what it is.  I guess the fixed gnome-session will be available from the archive soon after?
<seb128> slangasek: yeah, sorry about that, fixed version has just been uploaded, that should not be too bad for the CD
<slangasek> ok
<slangasek> release notes then
<pitti> evand: btw, any idea why ubiquity's icon on the live CD is broken?
<seb128> slangasek: thanks
<evand> pitti: off the top of my head, no.  It and the installation method for it haven't changed, so I imagine I need to update it with respect to changes in GNOME.
<pitti> soren: virt-manager just offers me xen and qemu as hypervisors; do I choose qemu for kvm?
<soren> pitti: Yeah, libvirt consider them sort of the same.
 * pitti sees it complain about a missing virtd and scratches head
<soren> pitti: Eh?
<soren> pitti: What's the exact error message?
<pitti> soren: "Unable to open connection to hypervisor URI 'qemu:///session':
<pitti> soren: then some backtrace
<doko> seb128: are gnome-terminal / gnome-vfs build failures known to you?
<pitti> then 'libvirtError: virConnectOpenReadOnly() failed'
<doko> gnome-vfs-mime-handlers.c: In function 'gnome_vfs_mime_application_get_desktop_id':
<doko> gnome-vfs-mime-handlers.c:1601: error: 'G_GNUC_FUNCTION' undeclared (first use in this function)
<seb128> doko: yes, there is new tarballs available upstream
<seb128> doko: G_GNUC_* have been deprecated
<doko> ok, not filing any reports about those
<soren> pitti: If you're connecting to qemu:///session, libvirt is supposed to start a libvirtd for you. I'm not sure what could cause that to fail.
<pitti> soren: do I need to start virt-manager as root? (the .desktop file doesn't)
<soren> pitti: No, not at all.
<soren> pitti: I recommend you connect to the system-wide libvirtd, though.
<soren> It allows you to set up all the interesting networking options.
<soren> Namely brigded and virtual networks rather than just usermode networking.
<pitti> it doesn't seem to ask me which virtd to connect to
<soren> That's what you tell it with the uri.
<soren> qemu:///system is the system wide one.
<pitti> ah, -c qemu:///system ?
<soren> Yes.
<pitti> same error message, though
<shaya> does anyone know what broke pidgin in hardy?
<soren> Are you a member of libvirtd?
<pitti> soren: no, I'm not
<soren> pitti: Then you won't be allowed to connect to qemu:///system
 * pitti sings "KVM is not enough" âª
<soren> qemu:///session should still be fine, though.
<pitti> soren: that group doesn't exist
<soren> Then you don't have libvirt-bin installed.
<soren> ...and that explains the other problems as well.
<pitti> . o O { dependency? }
<soren> I'm considering iit.
<pitti> soren: ok, thanks a lot for your support
<pitti> ah, there goes the daemon
<soren> It's perfectly reasonable to use virt-manager to only connect to xen or remote qemu instances.
<pitti> true
<soren> So a hard dependency seems wrong.
<soren> I'd like to add a meta package for this, though.
<soren> So there'd be an ubuntu-virtualisation-node and ubuntu-virtualisation-admin or -manager or something.
<soren> The former depending on libvirt-bin and kvm, the latter depending on virt-manager, openssh-client, etc.
<elmo> how big is libvirt-bin?
<pitti> soren: for 80 kB?
<elmo> yeah, what pitti said
<soren> It's 380 kb installed.
<elmo> just add the dep
<soren> I didn't think the appropriateness of hard dependencies had much to do with the size of the dependencies.
<elmo> sure it does
<elmo> adding new packages isn't free
<elmo> which seems to be your proposed solution
<elmo> trying to avoid adding a dep on an 80Kb package with nothing but binaries isn't overly sane
<soren> It could also just be a task.
<elmo> (given the other context)
<elmo> soren: apt-get install should DTRT
<soren> apt-get install my-task-name^  :P
<cjwatson> libvirt-bin actually ships an init script and such, but I would be inclined to agree that it'd be a lot more straightforward to just depend on it
<cjwatson> once apt installs recommends by default, it could reasonably be downgraded to a recommends
<elmo> cjwatson: oh, ok - I assumed from the name that it wouldn't do such things, my bad
<cjwatson> it's rather unconventional naming
<cjwatson> struct _CkConnecter;
<cjwatson> typedef struct _CkConnector CkConnector;
<cjwatson> go consolekit
<soren> Well, I'll probably be adding those tasks anyway. We want at least the stuff that's needed to function as a virtualisation node to be selectable in the server installer.
<jdong> cjwatson: it's an abstraction layer ;-)
<slangasek> cjwatson: xubuntu dailies seem to have failed today; germinate issue?
<cjwatson> jdong: complete with misspelling?
<cjwatson> slangasek: which daily?
<slangasek> cjwatson: 20080131, daily and daily-live, both archs
<cjwatson> Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/hardy/main/binary-amd64/Packages.bz2  MD5Sum mismatch
<cjwatson> odd ...
<slangasek> I can retry it shortly if you think it's likely transient
<pitti> soren: virt-manager looks great!
<cjwatson> the universe mirror seems rather out of date, and none of the rsync logs mention it
<soren> elmo, cjwatson: libvirt-bin contains a daemon and a single cli tool (virsh) that exposes most of libvirt's functionality. What would be the conventional way to name it? "libvirtd" and keep the virsh in there even though it's essentially unrelated to the daemon? "libvirtd" and move virsh to a new package called libvirt-bin (yay, new binary)? Or "libvirtd" and move virsh to libvirt0 (erk)?
<cjwatson> out of date> except for the way I apparently don't know what date it is. er.
<cjwatson> slangasek: hard to say, but I think there's a decent chance it's transient; give it another try?
<soren> pitti: Yeah, once it gets going, it's pretty neat. :)
<cjwatson> I updated germinate for good measure, but I don't think that'll matter
<mr_pouit> there's something weird on http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/xubuntu/latest/livecd-20080131-i386.out: the seeds have been updated to libgoffice-gtk-0-5
<mr_pouit> *g*
<mr_pouit> the seeds have been updated to libgoffice-gtk-0-6 long ago
<cjwatson> mr_pouit: as we told you guys last time this happened, you need to update livecd-rootfs too
<cjwatson> I'll go and do that now
<Hobbsee> mr_pouit: did you upgrade the other one?
<Hobbsee> bah.  too slow
<cjwatson> it has a special hardcoded bit for libgoffice due to apt craziness of some kind that we should probably revisit
<cjwatson> mr_pouit: fixed livecd-rootfs uploaded; may take up to a day to propagate without admin help though
<cjwatson> mr_pouit: it's even in a comment in the seed
<cjwatson>  * (libgoffice-gtk-0-6)   # explicitely seed this for abiword and gnumeric gnomeless variants
<cjwatson>                           # any changes here need to be done in the livefs build script, too, ping infinity about this/send an RT
<cjwatson> though the action described is wrong now and I'll update it
<shaya> is there a way to get gdb to tell you what lib an unresolved symbol (in a backtrace) is coming from?
<seb128> shaya: look at the address and what lib is using it, not sure if gdb can do the matching for you though
<seb128> shaya: apport crashes have those informations
<shaya> seb128: apport isn't catching pidgin crash
<seb128> why not?
<shaya> anyway I can run pidgin under apport?
<shaya> have no clue
<shaya> it catches many other things
<seb128> are you sure?
<shaya> pretty
<seb128> ls /var/crash
<seb128> shaya: does piding crash on startup on hardy for you?
<shaya> yes
<shaya> just started today
<seb128> shaya: try to unset G_DEBUG and run it
<shaya> no crash
<Kano> hi, why is stil no casper update online?
<seb128> good
<shaya> what happened?
<mr_pouit> cjwatson: thanks (never heard of livecd-rootfs before, but that'll be ok now)
<seb128> shaya: gnome-session set warning to crasher in unstable series
<shaya> hmph
<seb128> shaya: we disable that in ubuntu usually but the patch was not listed in the series
<shaya> ah
<seb128> shaya: I've uploaded a new version fixing that some time ago
<shaya> ok, thanks
<seb128> you are welcome
<Kano> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/187259
<ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New]
<Kano> maybe it is not needed to change the default to aufs
<Kano> as you can use it like unionfs=aufs too
<Kano> differnt to that patch
<Kano> hmm that patch sees a bit wrong, not the one i wrote
<Kano> that fallback is at a stupid position
<slangasek> cjwatson: xubuntu daily looks good this time
<Kano> juliank: you may not add the fallback in the unionfs=... case, thats stupid
<Kano> juliank: as it would require a unionfs option!
<slangasek> and xubuntu daily-live failing for the reason just identified, so
<Kano> look at my patch
<slangasek> cjwatson: how many pulses does it take before the livecd-rootfs changes will be visible to xubuntu daily-live?
<Kano> juliank: it has to be outside of case
<\sh> pitti, libfaad (faad2) when was it moved from multiverse to universe?
<berto-> hi everyone, no one in #ubuntu seems to know, so i hope you don't mind me asking here.  after booting into a Xen kernel, my Quantum DLT-V4 SATA tape drive stopped working.  the kernel has the st and sg modules, but dmesg doesn't show it.  any idea what module i'm missing _or_ if ubuntu adds patches to get SATA tape working?
<berto-> i compiled the 3.0.4 xen kernel, btw.
<geser> \sh: according to LP on 2007-11-16 18:33:22 CET
<\sh> geser, oh wow
<soren> pitti: I'd love to hear more about your kvm+ISO testing woes. It works fine for me.
<cjwatson> slangasek: if you want it guaranteed, I'd get #is on irc.c.c to update it
<cjwatson> slangasek: I think it's a (real) daily cron job but I don't know for sure
<slangasek> cjwatson: ok
<berto-> anyone know where to get linux kernel support ?  the kernel not recognizing my tape drive is getting to me.
<slangasek> stgraber: all ISOs should be posted now for testing, with the exception of xubuntu live which is waiting for livecd-rootfs propagation
<stgraber> slangasek: cool, thanks
<_MMA_> slangasek: I see nothing for Ubuntu Studio. Is it still in-process?
<slangasek> _MMA_: http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all ?
<slangasek> hmm, download link seems broken.  stgraber?
<_MMA_> Hmm... http://cdimage.ubuntu.com/ubuntustudio/releases/hardy
<slangasek> _MMA_: the images are built, in any case, and available for download directly via http://cdimage.ubuntu.com/ubuntustudio/daily/
<slangasek> _MMA_: releases/hardy is only updated when the alpha is released, not during the ISO vetting
<_MMA_> Sure. Wasnt that today?
<stgraber> slangasek: yes, it's broken for UbuntuStudio, known issue ...
<slangasek> _MMA_: not unless you've seen a u-d-a mail and a topic update ;)
<_MMA_> I have not.
<_MMA_> stgraber: Can you link me to something showing its broken?
<slangasek> it may still be today if the ISO testing goes well (and quickly), otherwise the alpha will be pushed tomorrow
<stgraber> slangasek: I'm waiting on bug #148944 to have a working download info page
<ubotu> Launchpad bug 148944 in ubuntu-cdimage "File list on cdimage for the Ubuntu QA Tracker" [Undecided,Confirmed] https://launchpad.net/bugs/148944
<Riddell> siretart: any plans for xine 1.1.10?
<geser> has an archive admin time to move aspectwerkz2 from universe to multiverse as it build-depends on sun-java6-jdk?
<_MMA_> stgraber: Can you link me to something showing its broken?
<Mithrandir> geser: done
<stgraber> _MMA_: http://iso.qa.ubuntu.com/qatracker/info/1259
<slangasek> stgraber: ah. :)  Ok, I have some plans in that area; ultimately, I want a manifest that declares the current set of testing candidates, that I can also use as input to the release publishing
<geser> Mithrandir: thanks.
<slangasek> stgraber: so then not only would you not have to poll for images, we wouldn't have to update the list of test targets by hand through the website either :)
<stgraber> slangasek: having a manifest file on cdimage.u.c would make possible to have a well working download info page + builds automatically added on the tracker
<_MMA_> stgraber: That doesnt really tell me anything. :( cjwatson: Can you shed some light on the Ubuntu Studio disks being broken?
<stgraber> _MMA_: what's broken is the info page pointing on your ISOs, because I haven't hardcoded the path to those (I was waiting on a full rewrite of that part of the tracker)
<slangasek> _MMA_: that's not about the disks being broken.  we don't know if the disks are broken, y'all need to test them and tell us. >;)
<_MMA_> stgraber: No, no. Im talking about why theres no: http://cdimage.ubuntu.com/ubuntustudio/releases/hardy/alpha-4
<_MMA_> Yeah
<cjwatson> _MMA_: err - I wouldn't expect there to be a releases/hardy/alpha-4 for anything yet!
<slangasek> _MMA_: um, I just said that alpha4 hasn't happened yet
<cjwatson> _MMA_: as I read stgraber's comment, the thing which is broken is the ISO test tracker, not the disks
<stgraber> _MMA_: read slangasek comment above
<_MMA_> Damn. I misread the page. Man, I gotta stop looking at these screens. Gonna make my vision worse.
<cjwatson> slangasek: assigning 148944 to you, since you seem most on top of it
<slangasek> cjwatson: cheers
<_MMA_> slangasek: Yeah. I saw the testing page was miffed. I got that. I misread the releases webpage for Ubuntu. Figured if there was one there I shoulda.
<_MMA_> Though I swear I saw it with so odd "Updating" message at the top of the page. :P
<_MMA_> s/so/some
<slangasek> hmm, ok :)
<Riddell> tjaalton, bryce: I'm still being hit by bug 133192 testing alpha 4 candidates
<ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Blank screen or distorted image because of wrong default AGPMode value" [High,Confirmed] https://launchpad.net/bugs/133192
<Riddell> reading your last comment thought there might not be a fix for everyone, nasty
<bryce> Riddell: I'll put it on my todo list, but I'm completely swamped so may be a while before I can look into it
<tjaalton> Riddell: that's because upstream tried to be clever, but seems that they reverted the behaviour back to what it was
<tjaalton> ..two days ago
<tjaalton> unfortunately it went unnoticed, so alpha4 still has that bug
<paran> why are the repositories for -dbgsym packages on ddebs.ubuntu.com not gpg-signed?
<seb128> because nobody created the key, etc yet
<Riddell> tjaalton: that sounds like there's hope on the horizon
<paran> seb128: ok. what is wrong with the normal archive key? the debug packages would have to be built at the same time as the normal ones.
<slangasek> paran: the normal archive key sits on a different server in a different security context
<tjaalton> Riddell: well, then those who benefited from the current version are going to be pissed :P
<tjaalton> but they just need to play with bios settings
<Riddell> hmm, "just"
<tjaalton> yes.. there's no way to do this work automatically for all users
<tjaalton> *make it work
<bryce> tjaalton: should the bug be closed as won't fix then?
<tjaalton> bryce: no, that bug will get fixed, but others probably reopened :)
<tjaalton> ..which then could be marked as won't fix
<bryce> ok
<bryce> let me know if there's anything I should look at with any of it... de-todo'ing it for now
<tjaalton> we'll get the fix when a new release is out
<tjaalton> although I have no idea when that'll be
<paran> slangasek: couldn't the "master version" of the dbgsym-packages repository be created on that same server and context, then synced to ddebs.ubuntu.com?
<slangasek> paran: many things "could" be; I don't think that's the right way to do it though, and I don't think that's the solution the archive admins are going to work on
<Mithrandir> paran: no, since the master mirror doesn't have the space for it.
<slangasek> (having it signed on the master archive server is the wrong answer because the master archive has no other reason to see the ddebs at all)
<paran> slangasek: well, I find it quite strange that the dbgsym packages are not in the normal archive to begin with... but I guess that is because of disk space issues on mirrors? :)
<seb128> paran: package index pollution, not interesting for most users, the mirror usage, etc
<paran> seb128: you could put them in components like main-dbgsym for main which solves the first two points
<seb128> that's not much different than having a different source
<luisbg> hey ompaul
<ompaul> luisbg, hi there
<luisbg> :)
<paran> seb128: maybe not, but it would at least be easier to find. had to search a while to find ddebs.ubuntu.com
<slangasek> stgraber: how does one map reporter names on iso.qa.ubuntu.com to launchpad IDs (or something else that would let me request more info)?  http://iso.qa.ubuntu.com/qatracker/result/1258/54 is reporting a bug that is marked fix released, and I want to confirm that the tester was using the current image
<berto-> are there any ubuntu kernel channels on IRC?
<kylem> yes. #ubuntu-kernel.
<stgraber> slangasek: this user hasn't filed his profile and we don't have the LP integration (yet)
<stgraber> slangasek: let me see if I can get you an email
<slangasek> ok, thanks
<stgraber> slangasek: https://edge.launchpad.net/~svenboden
<stgraber> (same e-mail addi)
<slangasek> aha
<slangasek> sorry, same email as what?
<stgraber> LP account and tracker account
<slangasek> I don't see any email addresses listed for him under LP?
<stgraber> no, but you the search function seems to work if you enter the e-mail addi
<slangasek> uhm, I don't understand. what e-mail address am I to enter where?
<stgraber> slangasek: I entered the e-mail address I found in his profile on the tracker in the search field. Do you have access to the admin part of the QA Tracker ? (You should have an Admin link next to the Welcome ... in the top-right corner)
<slangasek> stgraber: oh, no, I don't have any admin link there
<musther_> Hello,  I'm hoping to discuss the fsck problem (periodic boot checks), and possibly find a dev willing to help me implement a solution.
<stgraber> slangasek: you should now have the right to access user profiles
<slangasek> stgraber: I still don't see any 'admin' links; could you /msg me the email address in question, for the immediate issue?
<stgraber> slangasek: sent
<slangasek> stgraber: received, thanks
<stgraber> slangasek: Access rights to user profiles seem to be a difficult thing to set on Drupal, it'll be better once we'll have our own implementation of user profiles (ideally linked to LP and containing some usefull information for the RM/admins)
 * slangasek nods
<TheMuso> stgraber: Have you looked at all the various user access modules that are available?
<bdmurray> Anybody running an alpha 4 Live CD at the moment?
<siretart> Riddell: sure. c.f. bug #181949
<ubotu> Launchpad bug 181949 in xine-lib "Please sync xine-lib (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/181949
<slangasek> bdmurray: I have one to hand that I can test with?
 * TheMuso is burning images now for testing.
<bdmurray> I was trying to "unlock" the gnome network settings and the application just quit on me
<bdmurray> I haven't seen anything like this before - it ends with "Trace/breakpoint trap" and I'm uncertain how to track it down
<FrankQ> bdmurray, a lot of people are reporting bugs like that today
<FrankQ> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-January/003193.html
<slangasek> bdmurray: oh, that sounds like the gnome-session G_DEBUG bug, then
<slangasek> bdmurray: can you upgrade gnome-session in the liveCD, log out and log back in, and see if it goes away?
<seb128> or just unset G_DEBUG on a command line and run the software
<bdmurray> slangasek: okay, upgrading the package fixed it
<FrankQ> I'm not on LiveCD but I'm on the latest versions and it's still there
<bdmurray> FrankQ: and which version of gnome-session do you have installed?
<slangasek> FrankQ: have you logged out and logged in since upgrading gnome-session?
<slangasek> gnome-session sets the environment variable for your *whole* session, so upgrading the package is not enough to clear it
<bdmurray> slangasek: is there a master bug for that issue?
<slangasek> bdmurray: none that I'm aware of, seb128 handled the bug + upload via IRC
<seb128> bdmurray: that's technically not a bug ;-)
<bdmurray> seb128: How is that?
<seb128> the G_DEBUG things make the software crash on warning to get those reported as bug
<slangasek> ehm, I would certainly say that causing the desktop environment to suddenly treat all warnings as fatal errors is a bug
<seb128> so technically all the crash are applications bug, they just don't usually lead to a crash
<slangasek> hence, "warning"
<seb128> anyway no there is no bug about that, it has been handled by IRC
<seb128> and closing those crashers are duplicates would be wrong
<seb128> they are bug on the concerned applications
<slangasek> if gcc suddenly enabled -Wall -Werror by default, I would call that a toolchain bug. :)
<cjwatson> somebody might need to add comments on those bugs to indicate that even though the applications no longer crash the bug is that they emit a critical warning
<cjwatson> s/the bug/the real bug/
<cjwatson> otherwise somebody will probably come along and close them sooner or later ...
<seb128> cjwatson: I did comment on some this afternoon
<cjwatson> good stuff
<FrankQ> sorry, back. 2.21.90-0ubuntu1
<seb128> FrankQ: that's not the new version
<FrankQ> hmm, weird.
<bdmurray> slangasek: will edubuntu be rebuilt?
<FrankQ> Yeah, getting a new one now. Wasn't when I asked. apologies
<slangasek> bdmurray: for this issue, you mean? I wasn't planning to, I intended to release note it
<bdmurray> Wouldn't apport automatically submit them though?
<seb128> automatically submit what?
<seb128> the crashers due to G_DEBUG?
<slangasek> I didn't think apport ever submitted anything automatically?  Also, these processes are dying with the wrong signal so apport doesn't trap them
<seb128> slangasek: I think it does
<bdmurray> Okay, perhaps I'm not understanding the issue
<seb128> the issue is that gnome-session set G_DEBUG which makes applications crash when they usually display a critical warning
<bdmurray> There seem to be a lot of apport reported bugs with crashed with signal 5 though
<seb128> how much is a lot?
<slangasek> seb128: apport handles SIGSEGV, SIGFPE, SIGABRT, SIGPIPE, SIGBUS, SIGILL; according to the email just cited, G_DEBUG is triggering a SIGTRAP
<slangasek> hrm, no; that's apport's own signal handler, ignore me
<seb128> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/synaptic/+bug/187875
<seb128> one example
<bdmurray> seb128: 79 by querying on return_if_fail_warning
<FrankQ> Apport definitely didn't fire up with these crashes, for me.
<seb128> looking at launchpad there has been one every hour or so today
<seb128> and I expect most people run hardy and not CDs and will get the update gnome-session
<slangasek> ok, I can see that having everyone filing automatic crash reports between now and alpha5 would be a bad thing...
<seb128> bdmurray: you count duplicates?
<seb128> I really think that's not an issue
<bdmurray> seb128: maybe my launchpad query isn't the best
<seb128> there is not so many people using alpha for something else than testing
<seb128> and installation will be updated
<seb128> installations
<bdmurray> but if somebody has a statically configured network what will happen?
<seb128> what do you mean?
<seb128> you mean if somebody uses the alpha CD to do an install?
<bdmurray> Right
<seb128> and needs to configure the network then?
<bdmurray> yep
<seb128> well, I don't think many people rely on alpha CDs
<seb128> and you can unset G_DEBUG and run the software
<seb128> which will be in the notes
<seb128> and an easy enough workaround
<seb128> I think that's really a corner case and users running alpha CD should be able to understand how to unset an environment variable
<cjwatson> my worry is just that we'll get less good feedback, really
<slangasek> bdmurray: do you have a feeling for how effective the release notes are at preventing duplicate bug reports, particularly where apport is involved?
<bdmurray> I see your point but personally I would rather err on the side of less bug reports
<cjwatson> depends on the amount of work involved in respinning really
<seb128> cjwatson: feedback from who?
<seb128> bdmurray: I really doubt we will get that many bugs which will not be autoduped
<seb128> there is not so many critical warnings around
<slangasek> there's at least enough to take out evolution, pidgin, and gnome network settings
<FrankQ>  and gnome-settings-daemon, I think
<slangasek> anyway, we're already pushed back to Friday for the alpha release at this point, so I'd also rather err on the side of caution
<bdmurray> slangasek: I'm of the opinion that the release notes are not widely read but don't recall the specifc bug that makes me think this
<bdmurray> slangasek: actually it's bug 145382 from gutsy development
<ubotu> Launchpad bug 145382 in busybox "[Gutsy] broken 70-persistent-net.rules" [Undecided,Fix released] https://launchpad.net/bugs/145382
<slangasek> ah, that bug looks familiar :)
<bdmurray> I seem to recall it getting a lot of dups even after the bug was mentioned in the release notes
<stgraber> indeed :)
<TheMuso> Do the release notes get announced anywhere besides -devel-announce?
<slangasek> not by me; where else should they be released?
<slangasek> (are the alphas announced somewhere else?)
<TheMuso> I don't know. bdmurray's point about people not reading them could have something to do with that though.
<mathiaz>  /bye bbl
<TheMuso> I believe they are announced on the fridge, but can't remember whether the release notes are linked to or not.
<bdmurray> Maybe if we reorganize http://www.ubuntu.com/testing/hardy/alpha3
<bdmurray> so Caveats comes before download
<FrankQ> if you look at the forums/#hardy+1 not much people read anything at all, even alpha testers
<bdmurray> It is probably wishful thinking but isn't much work
<cjwatson> seb128: the purpose of the alpha releases is to get feedback from testers on how we're doing
<cjwatson> seb128: if the testers all just say "well, lots of GNOME applications crash" and give up at that point, that could be a net loss
 * Gnine nods
<seb128> cjwatson: right, without the crashs would be nicer
#ubuntu-devel 2008-02-01
<emgent> hello there, in #ubuntu-hardened is avaiable a bot (nick ubuSecurity) that paste in realtime CVE advisory, bugtraq advisory and milw0rm POC. if someone is interested please join. :)
<Hobbsee> youch.  broken gnome.
<TheMuso> Hobbsee: Its not so bad if you have the latest updates.
<TheMuso> Not so bad, as in, working properly.
<TheMuso> However, I don't know what you are meaning by broken.
 * Hobbsee is updating again, in the hope that it goes away
<ScottK2> Gnome would go away if you'd switch back to Kubuntu ...
<Hobbsee> heh.  there is that
<ScottK2> Sorry.  Couldn't resist.
<Chipzz> Hobbsee: update gnome-session and logout
<Chipzz> Hobbsee: alternatively, unset G_DEBUG in a terminal and run the crashing application from there
<Hobbsee> gnome-session said it fell over
<Hobbsee> Fetched 60.3MB in 7min47s (129kB/s)
<Hobbsee> sob.
 * Hobbsee prefers fetching at 3006kB/s
<Chipzz> Hobbsee: seb128 forgot to patch out what makes fatal warnings crash applications; it's fixed in the last upload
<Chipzz> but since it's an environment variable set by gnome-session you need to log out
<Hobbsee> that's fine.  i have bip :)
<Chipzz> bip?
<Hobbsee> bip irc proxy
<Chipzz> ah
 * Chipzz just uses screen/irssi :P
<Hobbsee> terminal lover :P
<Chipzz> you betcha :)
 * Chipzz also uses mutt ;P
 * realist wonders if Chipzz also uses lynx
<Chipzz> realist: are you crazy? :P
<Chipzz> at the very least, links :P
<Chipzz> and even then preferable elinks :P
<Chipzz> but no, I do not, or allmost not :)
<Chipzz> except when I need to download something on a remote server (like from sf)
<realist> wget/curl :-)
<Chipzz> which does not work for sf
<Chipzz> just gives you some nice html :P
<realist> html2text
<Chipzz> I'm really sure tar will grok that :P
<realist> I'd forgotten sf did that
<Chipzz> well I guess you *can* download directly from sf
<Chipzz> except most links are links to the download.php pages and not direct links
<Chipzz> which still leaves you nowhere
<Chipzz> realist: also, wget lacks a feature to save some downloads under the correct filename
<TheMuso> If you want text mode browsing, elinks is the only one worth considering.
<Chipzz> ie if you have a php page which adds information about the file name (forgot what the exact http header is), wget will not use that and save your download as bla.php
<realist> TheMuso: reason being?
<Chipzz> realist: support for https for starters
<realist> lynx has that doesn't it?
<Chipzz> compared to plain links, that is
<Chipzz> but lynx doesn't do tables. at all.
<Chipzz> which... sucks. big time
<FrankQ> you mean you don't use the Stallman method??
<FrankQ> http://lwn.net/Articles/262570/
<realist> FrankQ: we were joking about that at LCA yesterday
<FrankQ> I would get so agitated with a method like that
<Chipzz> realist: but really, mutt *does* have some extremely handy features which I have not found in any other mailer yet
<realist> Chipzz: such as?
<Chipzz> realist: do you know about link-threads and break-thread in vim?
<Chipzz> very convenient for people with broken mailers you'ld like to give a kick on the butt :P
<realist> in vim?
<Chipzz> errr
<Chipzz> in mutt
 * realist nods
<Chipzz> you can join threads which get broken by people with broken mailers which fail to add references headers
<realist> I like the pattern tagging, and tag commands too
<Chipzz> and you can break threads for those bloody morons who have to hit reply on a random message in a thread instead of just copy/pasting the to: and starting a new one
<realist> It does gpg out of the box too, these days
<Chipzz> don't really care about pgp atm though
<Chipzz> maybe at some point in the future
<Chipzz> but you don't happen to know another mailer that has these features?
<TheMuso> realist: Customizable keyboard commands, tables, javascript thanks to libmozjs0d/xulrunner, https, bookmarks, cookies, and a lot more that I haven't thought of. :p
<realist> TheMuso: nice, I'll have to try it out.
<Chipzz> TheMuso: but regular links also has a lot of those features
<realist> Chipzz: no, I use mutt.
<Chipzz> TheMuso: cookies, bookmarks, tables...
<realist> Chipzz: lynx doesn't :-)
<TheMuso> Chipzz: WHich links? links2, links, or lynx?
<TheMuso> Chipzz: But no javascript
<TheMuso> ChipzzOh thats right, elinks also allows you to use $EDITOR for editing multi-line form fields.
<Chipzz> TheMuso: I don't use elinks *that* much ;)
<TheMuso> Chipzz: Well I do, so thats why I love what it can do compared to the rest of the text mode browsers.
<Chipzz> TheMuso: anyway: 06:56 < Chipzz> and even then preferable elinks :P
<TheMuso> heh
<pitti> Good morning
<Hobbsee> morning pitti!
<pitti> Good morning Hobbsee!
<superm1> is update-manager-core going to be entering dapper-proposed for testing dapper-hardy server upgrades, or is there a different plan?
<superm1> well i guess i see bug 186694
<ubotu> Launchpad bug 186694 in update-manager-core "update-manager-core dapper backport" [Undecided,New] https://launchpad.net/bugs/186694
<warp10> Good morning
<superm1> i dont suppose it's been released into dapper-proposed yet then
<emgent> warp10, morning
<warp10> hi emgent ;-)
<superm1> yeah its sitting in the NEW queue yet. https://launchpad.net/ubuntu/dapper/+queue?start=20
<dholbach> good morning
<goobsoft> Does anyone know why I'm getting a 404 error on my PPA on launchpad?
<goobsoft> http://ppa.launchpad.net/goobsoft/ubuntu
<goobsoft> I just set it up... is there a delay?
<pitti> soren: hm, did you ever try virt-manager with compiz? they don't seem to like each other very well :/
<stgraber> moin
<soren> pitti: Yeah, there's a bit of focus-oddness going on there.
<soren> pitti: I assume that's what you're talking about?
<pitti> soren: by default the window title bar of a VM is invisible, then I have *two* mouse cursors, and fullscreen doesn't work
<soren> pitti: I'm not sure how much of that is compiz-specific?
<pitti> hm, and now the kernel just panicked again, darn
<soren> Guest, I assume?
<pitti> no, the host
<soren> Erk.
<pitti> soren: might also be bugs in the vnc viewer, not sure
<pitti> should try with metacity
<pitti> soren: (don't worry, that kernel panic happens to 2.6.24 about twice a week on my laptop, nothing kvm specific as it seems)
<soren> phew..
 * soren wipes the sweat off his brow
<pitti> soren: FYI, xen-3.2 NEWed
<soren> pitti: Thanks.
<borschty> pitti: hello, i have a short question about the esd-multiuser-patch you wrote some years ago (http://people.ubuntu.com/patches/esound.multiuser.diff)
<pitti> borschty: hello
<borschty> https://bugs.launchpad.net/ubuntu/+source/esound/+bug/177072 i have described it in the last post
<ubotu> Launchpad bug 177072 in esound "AUDIODEV should be exported when using pulseaudio" [Wishlist,Invalid]
<pitti> borschty: that bug is still on my TOOD list, haven't found time to look at it yet
<borschty> well the bug itself is closed now, but i think the patch might contain a small leak
<borschty> not really important stuff, if you have to smash some real bugs, this can wait
<TheMuso> pitti: What is involved to get that AUDIODEV environment variable exported? Does that have to be done within pulse itself?
<seb128> TheMuso: why do you need that? looks like that was a workaround when libesd what broken but it's fixed now
<TheMuso> seb128: pitti said its somethign that still needs doing, or so I thought...
<borschty> yes, it was a workaround, i guess i should have changed the description, but i did not want to spam the subscribers
<borschty> the actual bug is fixed, but i suspect the patch to introduce a small memory leak
<pitti> ok, if the AUDIODEV one was fixed with the re-applying of the libesd patch, great
<pitti> borschty: ok, thanks for pointing out; I'll have a look and fix the memleak
<xivulon> evand did you see my msg yesterday night?
<seb128> soren: is kvm known to not install correctly?
<seb128> soren:  * Module kvm_intel failed to load
<seb128> soren: Operation not supported
<carlos> seb128: is it known that latest evolution in Hardy crashes after sending an email? (I'm not sure it would be related, but I use SMTP + SSL). The email is not sent and it's lost
<seb128> carlos: upgrade gnome-session and restart GNOME or unset G_DEBUG
<seb128> carlos: that has been fixed yesterday, we had the warnings crashers code enable by mistake for a day
<carlos> hmm, I think I had that fix already installed... but let me restart it, just in case...
 * carlos restarts
<soren> seb128: Does your machine support kvm?
<soren> seb128: (grep vmx /proc/cpuinfo)
<seb128> soren: I supposed so, that's a D630
<seb128> I didn't enable the bios option most likely though
<seb128> but the package install should not fail anyway
<soren> seb128: dmesg will tell you if that's the case.
<seb128> what should I look for there?
<soren> kvm: Disabled in BIOS
<soren> or something like that.
<seb128> $ dmesg | grep kvm
<seb128> [ 1516.217209] kvm: disabled by bios
<soren> There you go.
<seb128> soren: that was expected, still the package should install?
<soren> Should it?
<seb128> soren: well, I see no valid reason to break installations
<carlos> seb128: seems like that's it. At least that also fixed pidgin :-P
<soren> Well, if you don't have the hardware, it can't be configured.
<seb128> soren: if I install the intel video driver on a box using nvidia it doesn't fail ;-)
<pitti> the package should always succeed to install
<mvo> ++
<seb128> soren: you should display a warning but not break the install
<pitti> and if it doesn't work, the init script would ideally point out why
<carlos> also, for some reason, all emails I sent appear in the outbox folder so I didn't lose data
<carlos> seb128: thanks for your help
<seb128> carlos: you are welcome
<soren> I'm certain there was a discussion about this at some point where the opposite conclusion was reached.
<seb128> weird
<pitti> soren: I guess at some point you want to ship the package by default on the server image?
<mvo> on a list or in a channel?
<mvo> I have very strong opinions about failing maintainer scripts
<soren> mvo: Yes :)
<seb128> is there anybody here who argued for breaking installation?
<soren> seb128: Come on..
<seb128> me too, package installation should never break
 * mvo looks around to see if he can find his stick-of-doom
<seb128> just add a || true in the postinst
<seb128> and display a warning
 * Hobbsee offers mvo the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢
<pitti> whoever proposed that should be sentenced to one week of triaging apport package inst failure bugs
<soren> "So, guys, what do you think? I think we should break isntallation of stuff."
<soren> seb128: I'm perfectly aware of the mechanics involved.
<mvo> and update-manager bug triage too
<seb128> soren: I'm surprised you seem to argue that's not a bug
<soren> seb128: I'm surprised to see you argue the way you do. Can we please focus on the problem rather than resort to stuff like "is there anybody here who argued for breaking installation?"
<soren> Ok, the argument, as I remember it, went:
<soren> If the package will be unable to function after installation, it's wrong to have dpkg claim that it's configured, since.. well... it's not.
<davmor2> Guys just to say that the nautilus-cd-burner patch has fixed only being able to burn one cd :)
<pitti> but configuring a package just means that it's properly installed, not necessarily working
<pitti> otherwise we could not install any printer or X.org graphics driver by default either
<seb128> soren: well, as said you can install the intel video driver on a nvidia machine, it'll not work but that's alright
<pitti> the init script should fail, sure
<davmor2> What causes two windows to open when ever you insert a cd or pen drive though.  Is there anything I can do to track it down or is it already being worked on?
<seb128> davmor2: that's a feature, nothing to track down, go to nautilus preferences, media tab and uncheck the option if you don't want it
<soren> It's not something I feel very strongly about.
<seb128> davmor2: ah, the duplicate window, that's known
<pitti> seb128: two windows for one driver?
<pitti> drive
<seb128> pitti: I read too quickly
<pitti> ah, ok
<davmor2> seb128: okay cool :)
<pitti> 118 sync bugs? ugh
<seb128> basically gvfs mount drivers on first access now
<soren> Where is the dpkg status semantics documented? I can't seem to find it.
<mvo> soren: I see your point, but I think with the tools we currently have we can not follow that for practical reasons. we have no good recovery mechanism for package failures, we can not do rollbacks and a package failure during a complex upgrade causes cascadigng errors or stop of the upgrade
<seb128> pitti: I didn't do syncs because of the freeze ...
<pitti> soren: ... that, and it would forbid us to install that package by default
<mvo> I think even if we wanted to follow that definition we would first have to fix the tools
<pitti> seb128: np; you've been busy enough
<seb128> but we have too many sync requests I agree
<seb128> we should really consider this automatic sync new revisions for universe packages
<davmor2> I'm just happy I can burn all the iso's again without resorting to rebooting the machine :)
<seb128> davmor2: you can use brasero now if n-c-b is broken
<seb128> you should not need to reboot
<soren> IIRC, it was iwj that was making the point I'm trying to make now, so it's not entirely inconceivable that it was more of a "this is how things are supposed to be" rather than "this is how we should actually do it" :)
<seb128> soren: right
<seb128> soren: the current situation is not nice because it'll let apt in a broken state you can't resolve with graphical tools easily
<soren> seb128: True.
<seb128> and will prevent you to install anything else
<seb128> which will lead to pretty bad users comments
<seb128> anyway, rebooting to set the bios option now ;-)
<soren> \o/
 * soren has amd hardware now for testing kvm.
<mvo> well, it let you install stuff, but you always get the error and stuff. I think that the package level is the wrong layer for this kind of tests
<davmor2> seb128: brasero didn't work for the same reason as n-c-b as far as I could figure.  It would burn one cd perfectly but the next cd you put in would fail.  Not sure if it was the n-c-b fix or gvfs but it is working now which is the good news :)
<pitti> soren: yay new toys!
<soren> mvo: I think the argument could be made both ways. However, as the tools are now, I can see why making the install succeed makes sense.
<stgraber> I'm going through the bugs reported on the tracker, we have bug 187898 and bug 186711 looking quite similar, can some confirm that I can set bug 187898 as dupe of bug 186711 ?
<ubotu> Launchpad bug 187898 in ubiquity "Stuck on "Removing conflicting operating system files"" [Undecided,New] https://launchpad.net/bugs/187898
<soren> pitti: Yeah, and it's on a decent pipe, too :)
<soren> 09:26:05 (9.67 MB/s) - `hardy-desktop-amd64.iso' saved [721704960/721704960]
<ubotu> Launchpad bug 186711 in partman-target "The installer needs to remove operating system files from the install target, but was unable to do so. The install cannot continue" [Undecided,Fix released] https://launchpad.net/bugs/186711
<pitti> soren: WANNAHAVETOO
<mvo> soren: woah!
<soren> It's not that expensive, really. â¬59/month.
<soren> Deductible, even :)
<seb128> re
<seb128> soren: better now ;-)
<mvo> I get a bit agitated about failing maintainer scripts, they just come up way too often in failed upgrades where it could have been avoided
<soren> I hear you, I hear you. It's changed in the next upload.
 * mvo hugs soren
<soren> O_O
 * soren eyes netcat-openbsd in Debian
<soren> \o/
<seb128> soren: waouh, kvm is very easy to use once installed, good work ;-)
<seb128> current hardy image booted correctly
<pitti> seb128: you used virt-manager?
<seb128> pitti: I did what is written on the wiki page
<seb128> yes
<seb128> it's on my D630 and work like charm, out of usplash which is not displayed
<seb128> but it took less than one minute to boot and I've the standard desktop usuable now
<seb128> hum
<seb128> the virtual network thing might not be what I want, I've not internet access from the image
<stgraber> We have very little results on the tracker, so when you guys are doing testing please think of reporting your results : http://iso.qa.ubuntu.com/qatracker/build/all/all
<pitti> seb128: argh, syncbugbot gets this "AssertionError: Wrong XPath-Expr in InfoTable.parse()" exception
<pitti> seb128: was it that one which you recently fixed in the retracers?
<seb128> pitti: somebody should upload a new python-launchpad-bugs
<seb128> pitti: yes, that's fixed in bzr for some time now
<pitti> dholbach, thekorn: any plans for uploading a new p-lp-bugs?
<seb128> that's a one line change
<pitti> seb128: ok, I'll dig into the bzr
<pitti> I need to manually roll it out to drescher anyway
<seb128> pitti: http://launchpadlibrarian.net/11477436/184594.diff
<dholbach> pitti: I asked bdmurray he said "today or tomorrow"
<soren> seb128: usplash will work when the new kernel lands, by the way.
<pitti> dholbach: thanks
<pitti> seb128: merci!
<seb128> soren: good
<seb128> pitti: you are welcome
<soren> seb128: What type of networking did you choose?
<soren> seb128: Virtual (the default)?
<seb128> soren: the one you recommend, virtual, it's not on the right network though and the preferences dialog doesn't let me edit that
<seb128> I need to change the .122
<soren> seb128: I don't quite follow..
<pitti> seb128: hm, that didn't help
<seb128> soren: the virtual network use 192.168.122.0, shouldn't it be on the same network than my router if I want to go on internet?
<seb128> pitti: weird, that did the trick for the retracers
<soren> seb128: No, it's separate. It sets up nat by default, though.
<seb128> pitti: maybe you have a pyc?
 * pitti pokes it harder
<soren> seb128: If you install dnsmasq, dhcp will be enabled in the virtual network.
<soren> (install dnsmasq and restart libvirtd, that is)
<seb128> soren: doing that
<soren> (I'm adding dnsmasq as a dependency of libvirt-bin real soon, by the way)
<soren> Whose archive day is it?
<seb128> pitti's
<seb128> hum
<seb128> soren: I get a non bootable device error in the vm now
<soren> pitti: Will you be able to look at bug 187983 and bug 187986 today? And do the subsequent binary new for netcat and source+binary new for netcat-openbsd?
<ubotu> Launchpad bug 187983 in netcat "Please sync netcat (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/187983
<ubotu> Launchpad bug 187986 in ubuntu "Please sync netcat-openbsd (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/187986
<pitti> soren: yes, I'm currently processing sync bugs
<soren> seb128: Right. The CD is only attached when you run it the first time, and it will only boot from CD the first time as well.
<pitti> soren: and as soon as I fix that python-launchpad-bugs thingy, I'll be able to commit the syncs
<seb128> soren: so I need to recreate the machine every time?
<soren> pitti: Cool. It's the final piece of the puzzle to enable remote libvirt management.
<soren> seb128: You can tweak the xml by hand.
<soren> seb128: Otherwise, yes. There's a bug open about it upstream.
<soren> seb128: If they don't get around to it soon, I'll be looking into it myself.
<seb128> ok, thanks
<pitti> thekorn: hm; on p-lp-bugs main head I still get "Wrong XPath-Expr in InfoTable.parse()" for bug 186856
<ubotu> Launchpad bug 186856 in apache2 "Please sync apache2 2.2.8-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/186856
<seb128> soren: can you point me to what to change exactly?
<soren> seb128: I'm writing it for you already. Hang on :)
<seb128> good ;-)
<seb128> thanks!
<soren> seb128: http://paste.ubuntu-nl.org/54315/
<davmor2> what's jockey-gtk?
<seb128> davmor2: restricted manager renamed
<seb128> soren: where is the xml? .virt-manager only has a .log
<davmor2> seb128: ah okay so the fix released will be effective after the release of alpha4 then?
<soren> seb128: /etc/libvirt/qemu
<seb128> davmor2: what fix released?
<davmor2> seb128:  bug 187139
<ubotu> Launchpad bug 187139 in jockey "jockey-gtk crashed with AssertionError in __init__()" [Undecided,Fix released] https://launchpad.net/bugs/187139
<thekorn> pitti: ok, can reproduce this, will have a closer look at this in about an hour
<pitti> thekorn: thank you muchly!
<seb128> virt-manager doesn't play nicely with compiz
<pitti> heh, just what I said above :0
<soren> If any of you have any clever hints about that, please don't hesitate to enlighten me.
<seb128> soren: bug mvo until he fixes compiz? ;-)
<soren> seb128: Sounds like a plan :)
<pitti> seb128: ok, I prepared the current syncs as syncbugbot list in ~pitti/s; not committing, since (a) we are still in freeze, and (b) we need a fixed p-lp-bugs
<seb128> pitti: ok
<pitti> Riddell: why did you remove the ((qApp) && (qApp->type() == QApplication::Tty)))
<pitti> Riddell: in the gtk-qt-engine SRU?
<Riddell> pitti: which distro release?
<pitti> Riddell: gutsy
<pitti> http://launchpadlibrarian.net/11630805/gtk-qt-engine_0.8~svn-rev36-2ubuntu2.1.debdiff
<Riddell> pitti: looks like an error, please reject and I'll upload a fixed one when my machine is done with this test install
<pitti> Riddell: ok
<pitti> Riddell: also, it would be helpful to describe the "why" of that patch in the changelog
<pitti> Riddell: stl. like 'nspluginviewer crashes when using the gtk-qt engine' or whatever the reason is
<Riddell> pitti: ok
<Riddell> (it stops it freezing)
<pitti> Riddell: rejected
<pitti> Riddell: gutsy's kdelibs update has a vast debdiff, mostly just +X-Ubuntu-Gettext-Domain and a changed files list; that's confirmed to not hurt, or break the .desktop/other files?
<pitti> Riddell: I don't think that the X-Ubuntu-Gettext-Domain tags make sense in most of the .desktop files
<Riddell> pitti: hmm, sorry, they should all get cleaned out, reject it and I'll take a look in a minute
<pitti> Riddell: the patch itself looks reasonable
<pitti> Riddell: will do, thanks
<pitti> wow -- kdebase b-deps on libglib2.0-dev now?
<pitti> seb128: I wasn't aware that gnome world dominance was that close already :-P
<ogra> evolution ... the app that has a new exciting bug for you every day ....
<Riddell> pitti: mm, well it's a workaround for flash requiring it
<pitti> Riddell: (just kidding)
 * ogra sighs ... and installs the evolution-dbg package to provide something useful to seb128 
<seb128> pitti: joke aside glib has no gnome depends and is nice, KDE could be using it for other things ;-)
<seb128> ogra: what happens now?
<ogra> seb128, chrashes while sending
<seb128> ogra: that's so yesterday's, did you update gnome-session and restart GNOME?
<ogra> it bumps up to 100% CPU usage for a while and then crashes
<seb128> ogra: is G_DEBUG set?
<ogra> hmm, i had to update 25 packages this morning, let me restart the session (even though i think i did that yesterday evening)#
<seb128> ogra: look if G_DEBUG is set
<ogra> doesnt seem like
<pitti> Riddell: ugh, heavy patch; there's no way I can eyeball this for correctness; I think we just need to test it very thoroughly
<seb128> ogra: env | grep G_DEBUG?
<ogra> nope
<seb128> k, weird
<seb128> so maybe you have an another bug
<seb128> get me the backtrace ;-)
<seb128> a non debug one will do for a quick glance
<ogra> meh, apport didnt have it :/
 * ogra sends another mail to reproduce
<ogra> hmm
<ogra> send/recieve worked this time ... it crashed before
<pitti> Riddell: flashplugin-nonfree isn't updated yet in hardy, right?
<seb128> ogra: did you restart your session between?
<ogra> yup
<seb128> ogra: so that was the G_DEBUG issue
<ogra> the mail that made it crash was sent but also still sitting in oubox
<Riddell> pitti: yes it is
<seb128> ogra: unstable gnome-session set G_DEBUG to turn critical warnings to crashers, we usually disable that but the patch was not in the series
<ogra> ah
<pitti> Riddell: nothing obvious in the changelog
<ogra> well, seems to work now
<seb128> ogra: I fixed that yesterday, that took only effect after you restarted the session though
<seb128> ogra: yeah, likely that was due to it
<ogra> yeah
<ogra> thanks
<seb128> you are welcome
<asac> bryce: are there still known dpi issues in X (if so, what would be the right X bug for bug 178558)?
<ubotu> Launchpad bug 178558 in firefox-3.0 "Firefox 3.0 makes everything annoyingly huge" [Undecided,Confirmed] https://launchpad.net/bugs/178558
<Riddell> pitti: it's version 9.0.115
<pitti> Riddell: ah, thanks; marking as fixed then
<pitti> Riddell: gtk-qt-engine> dapper looks fine, edgy and feisty have the same problem; I'll keep track of it in the bug
<ogra> hmm, why did nautilus stop to display the gartoon icons :/
<seb128> ogra: where?
<ogra> on my recently upgraded laptop
<seb128> I meant what icons?
<seb128> are the menus using correct icons?
<ogra> (the one that just had the evo issue)
<ogra> yes
<ogra> places shows the gartoon folders
<ogra> panel icons are fine as well
<ogra> in a nautilus window everything above the location bar is correct
<ogra> below it shows the fallback icons
<ogra> hman theme seems to work ... i bet gartoon is missing a change
<ogra> *human
<tjaalton> asac: dpi issues don't increase the size of the images afaik :)
<asac> tjaalton: hmm ... reading the bug it appears that setting the dpi value explicitly in firefox fixes this
<tjaalton> asac: ok, maybe it's because 3.0 uses cairo for everything?
<asac> tjaalton: maybe it was true in the past that dpi issues didn't affect firefox, but now they zoom images as well.
<asac> s/firefox/firefox images/
<thekorn> pitti: py-lp-bugs is broken, parsing of bugreports in edge.launchpad.net is impossible,
<pitti> ugh
<thekorn> due to a change in edge.lp.net (bug 137448)
<asac> tjaalton: maybe; but i think they calculate a scaling factor in firefox itself. most likely cairo just does what they tell it to do
<ubotu> Launchpad bug 137448 in malone "New UI is confusing and counter inuitive for changing affected package" [High,Fix committed] https://launchpad.net/bugs/137448
<tjaalton> asac: sure. if other apps look normal then I'd say it's indeed an issue with xulrunner
<pitti> thekorn: you mean Bjorn's recent fix changed the HTML?
<tjaalton> reading the upstream report
<asac> thekorn: do you know the page of maybe duplicates you get when reporting a bug. i couldn't get a similar search result using the standard search form, so i wonder whether that search facility is already supported in py-lp-b
<thekorn> pitti: yes
<thekorn> asac: no such a search is not implemented in py-lp-bugs
<xivulon> OT microsoft tries to buy yahoo
<Riddell> pitti: gtk-qt-engine and kdelibs re-uploaded
<xivulon> now on bloomberg
<pitti> Riddell: hm, I just accepted kdelibs/feisty, that looked goo
<pitti> d
<Riddell> pitti: kdelibs for gutsy only
<pitti> ah, good
<pitti> Riddell: bug tasks states are up to date ATM
<pitti> Riddell: argh, queue tool fooled me; can you please reupload gtk-qt-engine for edgy with bumping the version number?
<pitti> sorry
<pitti> Riddell: ok, now we have everything except gtk-qt-engine for edgy (the fixed one, see above) and kdebase for edgy and feisty
<Riddell> pitti: what's wrong with kdebase for edgy and feisty?
<pitti> Riddell: feisty: https://bugs.edge.launchpad.net/ubuntu/dapper/+source/kdebase/+bug/184149/comments/22
<ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed]
<pitti> Riddell: and for edgy it is not in the queue
<emgent> !info wordpress
<ubotu> wordpress (source: wordpress): an award winning weblog manager. In component universe, is optional. Version 2.2.2-1ubuntu1.2 (gutsy), package size 783 kB, installed size 4196 kB
<thekorn> pitti: I added a fix to Bug 188018
<ubotu> Launchpad bug 188018 in python-launchpad-bugs "Latest changes in edges.launchpad.net breaks py-lp-bugs" [High,Fix committed] https://launchpad.net/bugs/188018
<pitti> thekorn: \o/
<pitti> thekorn: I get a bit further now:
<pitti>   File "/home/lp_archive/python/launchpadbugs/lptime.py", line 59, in __new__
<pitti>     raise ValueError, "Unknown date format (%s)" %time_str
<pitti> ValueError: Unknown date format (2008-01-29 00:39:09 CET)
<soren> Muhahahah..
 * soren has a cunning plan..
<dholbach> MOTU Q&A session in 15 minutes in #ubuntu-classroom
<thekorn> pitti: oha :(
<thekorn> hi dholbach
<dholbach> hey thekorn
 * pitti hugs thekorn
<pitti> Riddell: can you please re-upload edgy gtk-qt-engine with bumping the version number?
<Riddell> pitti: done
<pitti> Riddell: thanks
<Riddell> pitti: working on kdebase, sorry for the delay, it would help if ubiquity would stop deleteing my hard disk
<pitti> ugh
<Hobbsee> Riddell: well, it would help if you stopped running windows, i'm sure..
<Riddell> Hobbsee: hmm?
<Hobbsee> Riddell: you were talking a while ago abotu a feature of ubuntu deleting your windows for you, during the install
<Hobbsee> the last time that some people's data got wiped out, iirc
<_MMA_> seb128: Did TheMuso contact you re: GDM sound issue? He figured out why the little drum noise wasn't playing on new installs.
<seb128> _MMA_: no he didn't
<_MMA_>  /usr/lib/gdmplay was not executable.
<_MMA_> After a "sudo chmod 755 /usr/lib/gdmplay" things worked fine on a Ubuntu and Studio install.
<seb128> _MMA_: ok, good, thanks, i'll fix that with the next upload
<_MMA_> seb128: Cool. And he found that Studio's login/out, caching error is specific to us. But we're not sure why we get the error on this one file. Maybe there's a play length or file size limit now. I don't know. Worked in Gutsy. :-/
<cheguevara> bryce, hi, are you around?
<thekorn_> pitti: I'm looking at your last date/time error, can't reproduce this for the given date,
<thekorn_> can you give me a bugnumber of a bug where this error occurs
<pitti> ok, hang on
<cheguevara> or tjaalton
<pitti> thekorn_: it's indeed bug 186856
<ubotu> Launchpad bug 186856 in apache2 "Please sync apache2 2.2.8-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/186856
<pitti> hah
<pitti> thekorn_: it seems to fail on    print b.reporter
<pitti> thekorn_: where b is a Connector.ConnectBug().Bug() instance
<pitti> thekorn_: the actual tasks seem to be ok
<thekorn_> pitti: let me check...
<davmor2> Xubuntu alternative installs are failing :( bug 188030
<ubotu> Launchpad bug 188030 in pkgsel "xubuntu hardy alternative alpha 4 cd fails to install" [Undecided,New] https://launchpad.net/bugs/188030
<stgraber> broken deps for libxine1-ffmpeg
<pitti> thekorn_: ok, I updated bug 188031; I think I'll just hack around it on drescher; sorry for the noise
<ubotu> Launchpad bug 188031 in python-launchpad-bugs "crashes with "ValueError: Unknown date format" on .reporter property" [Undecided,Invalid] https://launchpad.net/bugs/188031
<pitti> oh noes, another p-lp-bugs exception
<mvo> APIs ftw
<ScottK> pitti: If you have a few minutes today, I'd appreciate a chance to discuss the amavisd-new MIR.  There's some tasksel integration work that's blocking on it and with FF two weeks away... https://wiki.ubuntu.com/MainInclusionReportAmavisd-new
<pitti> thekorn_: another one for you, sorry: bug 188044
<ubotu> Launchpad bug 188044 in python-launchpad-bugs "AttributeError: 'change_obj' object has no attribute 'change_obj__action'" [Undecided,New] https://launchpad.net/bugs/188044
<pitti> ScottK: alright; please give me some minutes for this sync wreckage, then I'll do some MIR
<ScottK> pitti: No rush.  It's still early morning here.  Thanks.
<pitti> thekorn_: ok, another workaround later I could now circumvent above bug and syncs are finally running \o/
 * thekorn hugs pitti 
 * pitti hugs thekorn, master of LP
<thekorn> pitti: If I would be the master of LP, then ... ;)
<pitti> argh, more of the above; there's another place that uses change_obj__action
<pitti> thekorn: you don't happen to have a quickfix for that? I guess it's something trivial, but I can't figure it out without reading the entire code
<thekorn> pitti: I'm sorry, this is code from the very beginning of my python experience, let me check the code
<tokok> are you accept mono based d-bus?
<pitti> thekorn: if I change "change_obj__action" to __action, I get "AttributeError: 'change_obj' object has no attribute '_Attachments__action'"; hmm
<thekorn> pitti: give me a second, testing a fix
<pitti> StevenK: libosso reviewed, bug updated
<pitti> Riddell: so, only kdebase for feisty-proposed is missing now, rest is in -proposed
<pitti> Riddell: what an update, that must have cost you ages to prepare *hug*
<thekorn> pitti: added patch to Bug 188044
<ubotu> Launchpad bug 188044 in python-launchpad-bugs "AttributeError: 'change_obj' object has no attribute 'change_obj__action'" [Undecided,New] https://launchpad.net/bugs/188044
<thekorn> pitti: I have to leave now, I will have a closer look at the bugs over the weekend
<pitti> thekorn: you rock
<pitti> thekorn: thank you! and enjoy the weekend
<thekorn> you too
<zul> pitti: ping
<pitti> zul: pong
<zul> for ibmasm there was no source for it so it is sitting in new
<pitti> zul: ah, I see; let me take a look at it then
<zul> pitti: thanks
<zul> ill file a MIR after you have a look
<Riddell> pitti: kdebase for feisty-proposed uploaded now
<pitti> zul: NEWed
<zul> pitti: thank you
<zul> ill do the mir report right now
<geser> pitti: Hi, please give-back aspectwerkz2. It failed to upload. Thanks
<pitti> geser: done
<davmor2> guys I've just tried an encrypted lvm install of Ubuntu it's been 2 hours and it's still erasing the drive
<pitti> davmor2: don't you have a cancel button there?
<pitti> you should be able to skip this
<stgraber> pitti: why has this setting been changed ? wasn't it set not to entirely erase the disk on Gutsy ?
<davmor2> pitti: The gutsy version takes no longer than a normal install.
<pitti> stgraber: it was; but since it's still useful for paranoia reaons, adding a 'skip' button seemed better
<pitti> davmor2: right; my Q is, do you actually have a cancel/skip button there and does it work?
<davmor2> pitti:  I've hit cancel now yes.  Maybe change cancel to skip might be better.  I didn't want to cancel the install
<pitti> davmor2: that's a good point; can you please file a bug about this?
<davmor2> pitti no probs
<pitti> davmor2: thanks a lot for testing
<davmor2> well can't code, the bug reports are getting too technical it's about the only way left for a dyslexic to help out :)
<davmor2> pitti: what do you want the bug filing against d-i
<pitti> davmor2: hm, not sure; evand? partman-something?
<pitti> davmor2: d-i is fine as a default target
<davmor2> np
<pitti> davmor2: thorough testing and bug reporting are a great contribution, so no need to be shy about it :)
<pitti> davmor2: (my wife can't code either, and I still love her :-P)
<evand> partman-lvm?
<evand> d-i is fine though, it'll get moved where it needs to be
<davmor2> evand: pitti: bug 188085
<ubotu> Launchpad bug 188085 in debian-installer "debian-installers encrypted erase disc cancel button should read Skip" [Undecided,New] https://launchpad.net/bugs/188085
<davmor2> is that okay?
<evand> davmor2: looks good
<davmor2> okay cool leave it with you then :)
<davmor2> Is it safe to start testing the Live cd's or is ubiquity being updated?
<slangasek> ubiquity is being updated
<davmor2> okay thanks I'll check back latter then :)
<pitti> ah, seems I fixed the i386 retracer to properly process duplicate checks for python bugs again
<pitti> (I applied a p-lp-bugs which made them throw exceptions)
<pitti> ...patch...
<jwendell> Hi, seb128. Vino installs its executable in /usr/libexec. Why does ubuntu package install it in /usr/lib/vino/ ?
<slangasek> because libexec is not part of the FHS
<seb128> jwendell: because on debian and ubuntu libexec=/usr/lib/binary
<slangasek> it's subsumed into /usr/lib according to the standard
<seb128> binary being the name of your software
<jwendell> ok
<slangasek> (I wish we /did/ have a separate libexec, but it's a little late to change our minds now :)
<seb128> jwendell: is that an issue?
<jwendell> seb128, no, I was just trying to debug vino and noticed that I was looking at wrong directory
<seb128> ah ok
<tjaalton> cheguevara: yes?
<cheguevara> tjaalton, sorry was away wanted to talk to you about the intel driver
<LaserJock> pitti: do you have an ETA on the next lang pack update?
<soren> pitti: Please let me know if there's any problem with the netcat-openbsd package.
<pitti> carlos: ^ for gutsy you told me it would be better to do a full export, right? can you trigger this over the weekend?
<carlos> pitti: yes, I told you that
<pitti> LaserJock: next Monday would be the next regular update
<pitti> soren: it's in the sync buffer, I just need to flush; flushing needs to happen after alpha-4 release, though
<carlos> pitti: you are able to do it, although I cannot force Gutsy export, it will happen in its next scheduled time (I think it's tonight)
<LaserJock> pitti: will they go up on the PPA before?
<pitti> LaserJock: they are already
<pitti> carlos: ah, right; I'll flip that checkbox
<LaserJock> oh, ok
<LaserJock> I checked a day or two ago
<carlos> pitti: do you remember the page to do it?
<soren> pitti: Oh, ok. I just noticed the netcat package getting synced, so I thought you had specifically skipped the -openbsd one.
<pitti> carlos: yes, already done
<pitti> carlos: I just keep forgetting that I'm now able to do that myself :)
<carlos> pitti: ;-)
<pitti> soren: hm, indeed
<tjaalton> cheguevara: ok, what about?
<pitti> soren: right, I didn't process new package syncs yet (need to flush first)
<pitti> soren: if it's very urgent, I could cowboy it, but otherwise I'd just do it on Monday
<soren> pitti: No, it's not *that* urgent :)
<soren> pitti: Monday it is.
<soren> Thanks.
<pitti> ok, great
<carlos> pitti: confirmed, full export will happen tonight
<pitti> \o/
<mvo> does anyone has a idea what https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/187889 is about (is that polish?)
<ubotu> Launchpad bug 187889 in update-manager "NovÃ© nÃ¡vrhy na pÅeklady v balÃ­ku upgrade-manager" [Undecided,New]
<geser> mvo: not polish, from the look and the timezone of the submitter I'd say it's czech
<tjaalton> yep
<slangasek> yes, it's czech.  "New suggestions for the translation of the upgrade-manager package"
<slangasek> ... and then a link to a page that mentions no Czech translations being available, so, er
<slangasek> oh, apparently you have to click to see all the translations, n/m :)
<geser> slangasek: which language do you don't understand? :)
<slangasek> geser: Xhosa
<cheguevara> tjaalton, abot exa and xaa thing
<cheguevara> i really think switching to xaa is a bad idea
<cheguevara> the drm modules are getting merged in .25 they can be backported
<superm1> pitti, are you still going to go through the new queue again today?  we (mythbuntu team) were hoping to roll new live disks at some point this weekend (preferably with those builds)
<slangasek> stgraber: I've failed at getting builds disabled in a timely manner when we knew we'd be rerolling, but FYI I'm pushing a full set of new images because of the partman "eat my old OS" bug identified yesterday
<stgraber> k
 * mathiaz just finished testing 18 test installation of the isos. Now he can start over.
<tjaalton> cheguevara: well, it's a tough decision..
<cheguevara> tjaalton, yeah i understand, what does the kernel team say?
<tjaalton> cheguevara: it was discussed at UDS and turned down, I'm not sure anything has changed since
<cheguevara> tjaalton, i see, is there any possibility of it happening though? xaa is deprecated, has video problems and doesn't support compiz on 965 (i am sure you know all that though)
<cheguevara> compiling mm sources right now to see the diffference
<Amaranth> but isn't EXA still slower than XAA even with ttm?
<tjaalton> cheguevara: I watched the presentation by cworth at lca, and while they have been able to get the performance better, rendering text is still maybe 40% slower
<tjaalton> Amaranth: ^^
<tjaalton> :)
<MacSlow> Amaranth, depends
<Amaranth> The only thing EXA is really better at is large fills or whatever
<MacSlow> Amaranth, following Carl Worth's blog regarding his work with EXA and related bits of the i965 driver is always very interesting
<cheguevara> tjaalton, when was that?
<tjaalton> cheguevara: a sec
<tjaalton> cheguevara: http://mirror.linux.org.au/pub/linux.conf.au/2008/Wed/mel8-167.ogg
<tjaalton> slides from http://linux.conf.au/programme/wednesday
<tjaalton> we have linux-backports-modules package now.. maybe the new versions could be shipped there?
<tjaalton> um, new drm modules
<cheguevara> yeah that would be better then nothing
<cheguevara> and may be specifiy somewhere that if you wanna try experimental drm modules install this package for increased performance etc
<tjaalton> but compiz would still be disabled by default
<tjaalton> for i965
<tjaalton> (i have one)
<MacSlow> gee... intels GPU docs were released to the public
<cheguevara> tjaalton, new_exa is the batchbuffer git branch right?
<MacSlow> LCA seems to be growing and growing... some major conference... not that it was small before.
<tjaalton> cheguevara: yep. I tried that two weeks ago, but something went wrong and the driver failed to load. Now that anholt has pushed more stuff to master things should be easier..
<tjaalton> hm, maybe I'll pull all the trees now
<cheguevara> there seems to be some minor screen corruption with the current hardy driver as well
<tjaalton> with exa?
<cheguevara> no xaa
<tjaalton> mine works fine..
<tjaalton> dinner, bbl ->
<cheguevara> i had to put xaa in my xorg.conf, 'cause exa is just that crap atm lol
<oojah> I'm filling out a MainInclusionReport and I don't know what to put for "Packaging system (debhelper/cdbs/dbs) ?  Patch system ?  Any packaging oddities ?". Any suggestions where I can find information about that?
<jpatrick> oojah: in the source package
<jpatrick> oojah: apt-get source packageName and take a look in the debian/ dir
<oojah> jpatrick: I'm not on ubuntu ;)
<oojah> But that's fine, I know where to look now. Thanks.
<slangasek> er, you're requesting a package's inclusion in main but aren't running Ubuntu?  That's seems a bit strange to me
<StevenK> And if you're unsure about how to fill out a MIR, you shouldn't be, IMO
<oojah> Well that's a fair point, but you've got to start somewhere, right?
<davmor2> bug 173130 still affecting alpha 4
<ubotu> Launchpad bug 173130 in xserver-xorg-video-nv "edubuntu hardy 64bit live cd issues" [Medium,Triaged] https://launchpad.net/bugs/173130
<jpatrick> oojah: what exactly is the MIR for?
<StevenK> oojah: Sure, but don't start with MIRs
<oojah> jpatrick: libggz, a build dep of gnome-games.
<slangasek> oojah: libggz is already in main
<oojah> Well that certainly shows me up...
<oojah> Does everything that goes into main remain in universe?
<slangasek> no, each package is in one or the other for each given release
<oojah> Fair enough. I checked universe on archive.ubuntu.org and as it was there assumed it wasn't in main.
<sistpoty> btw.: motu-meeting in #ubuntu-meeting now... for anyone interested
<slangasek> oojah: right, it'll still be in universe for past releases
<oojah> Sure
<oojah> Well that certainly makes life easier. I was asked to look at the gnome-games ggz deps last week when they weren't in main and now they all are as of a few days ago.
<stgraber> slangasek: Are all the ISOs on the tracker ready for testing (I finally managed to have my test computer back so I'll be able to do some tests now) ?
<slangasek> stgraber: desktop images are not rerolled yet, just disabled those; alternate images are ready for testing
<stgraber> ok
<Chipzz> 11:12 < soren> (I'm adding dnsmasq as a dependency of libvirt-bin real soon, by the way) >> sounds wrong to me?
<soopurman> stgraber, which tracker were you referring to? when slangasek mentioned that the alternate images are ready for testing
<stgraber> soopurman: http://iso.qa.ubuntu.com
<slangasek> desktop images are also back up by this point, for all but xubuntu
<soopurman> so the contents of 20080201.1 are candidates for the alpha4 release ?
<stgraber> yes
<soopurman> alright! i'm about to perform the install (manual partitioning) of the 20080201.1 image of hardy-alternate-amd64.iso... i'll report my results on the tracker in about half an hour
<soopurman> see you then :-)
<slangasek> oh how nice, 3 new updates.
<slangasek> presented to me after booting into my newly-installed hardy, which was rolled mere hours earlier. while still in a freeze.
<LaserJock> slangasek: "soft" ;-)
<slangasek> right... maybe I should try different language for the next one, maybe call it a "retaliatory freeze". :)
<StevenK> Haha
<StevenK> "If you upload, I'll retaliate."
<stgraber> slangasek: first result from Ubuntu desktop i386 : Jockey crashing at session opening (why is it starting on the livecd ?), rofs and cdrom shown on the desktop, ubiquity missing its icon, update-manager showing an update available icon when no updates are available + hovering it shows a "A package maanger is working" label
<superm1> slangasek, would you be able to release mythtv binaries from NEW at some point before the end of day?  we were looking to roll our alpha this weekend with them and do some testing over the weekend
<slangasek> stgraber: yes, similar to my own experience.  But I don't think any of those are blockers, so I guess it'll just be a little rough around the edges
<stgraber> slangasek: I'm installing now, those are not blockers though really annoying bugs (especially when the first thing you see is an apport report :))
<slangasek> oh, I didn't see any apport reports here :/
<slangasek> well, so be it though
<stgraber> I have a nvidia graphic card in my test computer
<slangasek> yeah, I'm testing in a VM, no hardware to manage ;)
<stgraber> hehe, solves a lot of problem :)
<slangasek> stgraber: 188221 for the generic install icon issue
<slangasek> I'm fairly certain the rofs icon is a gvfs issue; I haven't checked for open bugs
<stgraber> does it disappear when you start ubiquity ?
<slangasek> er, I didn't pay attention
<stgraber> it did here and I didn't really understand why
<slangasek> the update-manager bug has also been reported as #188201
#ubuntu-devel 2008-02-02
<slangasek> superm1: so I think my time today is pretty much booked; I would suggest trying to grab an archive admin over the weekend (maybe me again)
<superm1> slangasek, i wasn't too sure about anyone sticking around for the weekend so i was going to try to ask before end of work day.  thanks, i'll keep my eyes peeled
<slangasek> stgraber: is there a reasonable way to locate test results for previous isos?
<stgraber> slangasek: no, archives are still broken :(
<slangasek> stgraber: I don't see any tests for the current xubuntu or ubuntustudio yet; if there were some for the previous iteration, we could probably run with it
<slangasek> hmm, ok
<stgraber> I don't think those were tested (at least ubuntustudio, not sure for Xubuntu)
<stgraber> the order of testing for the day was like : Ubuntu, Edubuntu, Kubuntu, Xubuntu, UbuntuStudio (Kubuntu had a lot of testing yesterday)
<slangasek> TheMuso, joejaxx, persia, _MMA_: around?  anyone able to test ubuntustudio images so we can bless the alpha?
<_MMA_> Sure.
<stgraber> slangasek: I tried some keyword on LP and wasn't able to find a bug number for the icon thing on the livecd (or I'm just bad at searching on LP)
<_MMA_> What image? link?
 * persia hunts qa.ubuntu.com
<stgraber> http://cdimage.ubuntu.com/ubuntustudio/daily/20080201/
<slangasek> that one, yes :)
 * _MMA_ downloads.
<persia> _MMA_: Which arch are you taking?
<Riddell> doesn't ubuntu i368 desktop need testing too?
<_MMA_> persia: i386
<stgraber> Riddell: doing it
<stgraber> well, it's actually installed, just need to reboot and test the desktop
<_MMA_> persia: AMD64 would be hard to do this very second. Would require more time.
<persia> _MMA_: I'm grabbing it now.
<_MMA_> persia: AMD64?
<persia> _MMA_: Yes.
<_MMA_> Cool.
<persia> (needs another 4 minutes to finish the download)
<stgraber> Who are the Xubuntu guys ? It would be good to have Xubuntu tested too
<_MMA_> somerville32: ping ^^^
<stgraber> slangasek: Do you want to file the device shown on desktop bug or can I ? the next question being against what ? nautilus ?
<slangasek> stgraber: please go ahead; yes, nautilus seems a good starting point
<slangasek> somerville32, stgraber: I'm trying to grab the xubuntu amd64 desktop for a test, but it'll be a while on the download
<stgraber> ok
<stgraber> slangasek: bug 188229
<ubotu> Launchpad bug 188229 in nautilus "[Hardy] rofs and cdrom icons shown on LiveCD desktop" [Undecided,New] https://launchpad.net/bugs/188229
 * stgraber takes Ubuntu Desktop i386 - OEM as last test for the day (01:30 here)
<slangasek> thanks for your perseverance :)
<_MMA_> slangasek: It will be about 60 mins or so 'till I can bless the disk as our full install is pretty big.
 * joejaxx goes to install
<slangasek> _MMA_: understood
<selckin> what package makes the folders Documents & stuff in $HOME?
<joejaxx> selckin: i think that is related to xdg-user-dirs
<joejaxx> the packages anyway
<_MMA_> It is.
<joejaxx> package*
<stgraber> slangasek: OEM install seems broken
<selckin> thanks
<stgraber> slangasek: after reboot I have no oem-config installed
<slangasek> stgraber: hmm, ok.  also not a blocker
<slangasek> somerville32: mm, booting xubuntu amd64 desktop gives me a blank desktop screen, please advise
<stgraber> slangasek: it didn't ask for a password although I have set one and just auto-logged in
 * joejaxx pokes wget to move more bytes faster
<stgraber> slangasek: what package is the best for OEM install bugs ? oem-config, ubiquity ?
<stgraber> slangasek: as oem-config isn't installed I would bet on ubiquity but I'm not sure of how that stuff works :)
<slangasek> stgraber: I guess assigning it to either is fine
<stgraber> evand: ^^
<evand> oem-config
<stgraber> Can anyone do an auto-resize test ? According to http://iso.qa.ubuntu.com/qatracker/testcases we don't have any single result for it
<_MMA_> stgraber: I can help tomorrow. Though, that might be too late. :(
<_MMA_> slangasek: Im still here. @ 65% now. If this installs just push both Ubuntu Studio disks. I should know in 25 mins.
<slangasek> ok
<slangasek> superm1: can you advise on the fact that xubuntu desktop ISO gives me a blank screen on amd64?  I'm inclined to push the alpha out with just alternates for xubuntu, if that's alright with you
<slangasek> (and if the alternates work better, which I'm still in the process of downloading to verify)
<superm1> slangasek, i dont have an amd64 unfortunately
<superm1> so i wouldn't be able to test
<slangasek> ok. has xubuntu desktop been tested on i386?
<superm1> i was assuming somerville32 was doing the testing on it (i've been away from the project for some time)
<slangasek> mm, ok
<slangasek> oh, sigh
<slangasek> superm1, somerville32: libxine1-ffmpeg: Depends: libavcodec1d (>= 0ecvs20070307) but it is not installable
<superm1> slangasek, on what source package was this?
<_MMA_> slangasek: Is tomorrow (east-cost of the states here) too late for your testing? I can easily do any i386 testing.
<slangasek> somerville32: sorry, we can try to roll out a xubuntu alpha after the weekend if you guys can get this fixed
<slangasek> superm1: not a source package, that's the xubuntu alternate install
<superm1> slangasek, so a broken seed then?
<slangasek> _MMA_: yes, I want to pull the trigger on this when your 25 minute counter is up :)
<slangasek> superm1: well, libxine1-ffmpeg appears to be uninstallable, perhaps it needs a rebuild or something
<_MMA_> slangasek: On Ubuntu Studio sure. Im talking about other testing.
<_MMA_> Other disks.
<_MMA_> (97% cleaning up)
<superm1> slangasek, well that's odd since it's installable locally
<slangasek> _MMA_: oh, well, additional testing and feedback is welcome of course
<slangasek> _MMA_: but at that point it will no longer factor into the decision to release :)
<_MMA_> slangasek: I see.
<_MMA_> Ill hop on -testing tomorrow.
<Fujitsu> Hmm, none of pitti's syncs of about 12 hours ago seem to have worked.
<slangasek> Fujitsu: they're still held up because of the alpha
<Fujitsu> Hardy doesn't look frozen...
<_MMA_> slangasek: Push the Ubuntu Studio disks. Thanx for the work.
<Hobbsee> Fujitsu: apparently everything is built.  taht doesn't look right
<Hobbsee> Fujitsu: the name of one of the syncs?
<Fujitsu> Bug #187737, bug #187311..
<ubotu> Launchpad bug 187737 in ghemical "Please sync ghemical 2.95-2 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/187737
<ubotu> Launchpad bug 187311 in pari "Please sync pari 2.3.3-2  (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/187311
<slangasek> _MMA_: pushing, cheers
<slangasek> Hobbsee, Fujitsu: the bugs have been closed, the syncs haven't been flushed yet
<Hobbsee> looks worrying
<Hobbsee> slangasek: where are they?
<Fujitsu> Aha, I wondered if there was some extra thing that had to be done at the end.
<slangasek> Hobbsee: they're in the sync queue, they were held back on account of the alpha still being in progress. I'll flush them this evening.
<ryanakca> cjwatson: oooh, that vim + launchpad bug thing is sharp/nice/fancy/<positive adjective> :D
<slangasek> superm1: here's the problem in the build log:
<slangasek> ? Package libavcodec1d blacklisted in ship but seeded in desktop (libxine1-ffmpe
<slangasek> g)
<superm1> slangasek, her that's interesting.
* slangasek changed the topic of #ubuntu-devel to: Archive: open for development | Hardy Alpha 4 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<zoke> who do I talk to if a component of linux-ubuntu-modules needs to be synced with upstream ?
<zoke> ie a really awesome super duper patch was introduced in upstream and it would be very good if it could be let in for Hardy
<ScottK> zoke: Sounds like you'd want #ubuntu-kernel
<zoke> thanks ScottK
<TheMuso> slomo__: SOrry I haven't been around. Been out most of the day.
<TheMuso> ugh
<TheMuso> slangasek: ^^
<jdong> mjg59: poke. When you wake up, please look at bug 188261. Hopefully my night of frustration will save someone else some time.
<ubotu> Launchpad bug 188261 in pm-utils "[debdiff] pm-utils modunload nonfunctional" [Medium,Triaged] https://launchpad.net/bugs/188261
<warp10> Good morning
<soren> Chipzz: Why?
<freepenguin> now I've finally the page of ubuntu free penguin edition: http://www.freepenguin.it/ubuntufp-download-en.html
<slangasek> TheMuso: you're allowed... :)
<TheMuso> slangasek: I know, but I still have a vested interest in the UbuntuStudio project.
<slangasek> TheMuso: right, well we seem to have managed to get the testing done that was needed
<slangasek> and it's not your fault that the testing window was so short because of the need to reroll all images :/
<TheMuso> slangasek: heh right. I tested an image of ours yesterday, from Thursday, and it seemed to be alright, appart from a few little things that need to be worked on, which are not sstudio specific anyway.
<slangasek> yeah, the re-roll was primarily for the global "eat my old OS" bug in partman-target
<slangasek> anyway, I'm off for the night now
<stgraber> anyone with power on www.ubuntu.com ?
<stgraber> The OEM install functionality does not work in this alpha. Investigation of this issue is ongoing.  https://bugs.launchpad.net/188240
<stgraber> the link should be /bugs/188240
<Chipzz> soren: because it's not strictly needed for the correct functioning of your package, ie if you use bridged networking?
<superm1> doko, bug 103929 was assigned to you a long time ago.  have you put any more thought towards it?
<ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress] https://launchpad.net/bugs/103929
<mjj29> if I (as a DD) want to start taking a more active role in getting my packages into ubuntu (rather than just waiting for the sync from sid) how is it best to go about it?
<mjj29> (just prompting the migration is probably sufficient)
<jeromeg> mjj29: what are your packages ?
<mjj29> jeromeg: an assortment. javatools (source) being the current one
<mjj29> although I don't want to push than until the revised version I just uploaded hits
<mjj29> s/than/that/
<jeromeg> ok
<mjj29> everything's in universe atm
<jeromeg> if it can be synced and you don't want to wait for the automatic sync
<jeromeg> you can fill a sync request
<mjj29> (although that one might be a candidate for main)
<mjj29> ok
<jeromeg> https://wiki.ubuntu.com/SyncRequestProcess
<sistpoty> erm... since we're past debian import freeze, no packages gets synced automatically any longer for hardy
<jeromeg> sistpoty: yep, but I thought that by saying "waiting for a sync" he meant the automatic syncs
<sistpoty> ah, yeah
<sistpoty> mjj29: btw.: would be good to add to the sync request, that you maintain it in debian ;)
<mjj29> sistpoty: "archive: open for development" doesn't mean what I think it does then?
<sistpoty> mjj29: well, currently hardy is still in no freeze, apart from that no automatic syncs are getting processed any longer
<mjj29> right, but manual syncs are still ok?
<sistpoty> sure
<sistpoty> btw: https://wiki.ubuntu.com/HardyReleaseSchedule
<pitti> mjj29: as sistpoty says; syncs can be done without restrictions, but upon manual requests, so that we avoid syncing large library transitions without notice, etc.
<mjj29> sure
<mjj29> so I've got until valentines day for anything I want synced?
<pitti> mjj29: you can always poke us here if you want a particular package synced, or something uploaded to Ubuntu directly
<pitti> mjj29: in theory much longer even
<pitti> mjj29: in Feb we have feature freeze
<mjj29> sure
<pitti> after that we can still sync/upload, but only for bug fixes
<pitti> or after getting a feature freeze exception from our release manager
<sistpoty> pitti: btw.: we decided to rename motu-uvf to motu-release in last nights motu meeting
<pitti> sistpoty: ah, makes sense
<pitti> ok, I'm off again, happy weekend everyone
<sistpoty> happy weekend pitti
<alefteris> where can I modify the translation of the list of languages used by the language-support configuration applet?
<mr_pouit> cjwatson: xubuntu builds don't ship any xfce package (that's why slangasek got a blank screen after gdm) ;/
<Hobbsee> mr_pouit: ...yay!
<mr_pouit> Hobbsee: oh, I'm sure there's worse ^^'
<Hobbsee> probably
<zoke> bug 186062
<ubotu> Launchpad bug 186062 in linux-ubuntu-modules-2.6.24 "please update linux-wlan-ng (prism2_usb) to latest upstream version (>=1847)" [Undecided,New] https://launchpad.net/bugs/186062
<Hobbsee> !ping
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
<realist> pong!
<mantiena-baltix> Hi all
<mantiena-baltix> Hi all
<mantiena-baltix> maybe someone knows why there are not translation templates for brasero CD/DVD burner ? brasero is in main
<mantiena-baltix> see https://translations.launchpad.net/ubuntu/hardy/+source/brasero
<__mikem> Can someone here help me with wubi-cdboot.exe. I am trying to use it, but when it gets to the part where I have to select a partition, the virtual disk doesn't show up as a choice to install ubuntu on
<__mikem> win 3
<__mikem> oops
<realist> mikem235: take note of the topic.
<mikem235> realist, I am using IRSSI and can nolonger see the topic
<realist> mikem235: /topic
<realist> Basically, #ubuntu for support
<pochu> mantiena-baltix: perhaps a rosetta admin needs to accept the template.
<__mikem> realist, basically, you are not an op in here, so you should follow the defacto standard of irc ediquite that if you don't know the answer to somebodys question, you keep your trap shut
<evand> ...
<_MMA_> sigh
<realist> __mikem: perhaps you'd prefer I ignore you in future.
<evand> __mikem: You might as well leave, I seriously doubt anyone is going to help you now.
<__mikem> evand, thats fine
<mantiena-baltix> pochu: how I can ask rosetta admins to accept ?
<ScottK2> mantiena-baltix: I think in #launchpad, but admins there aren't very active on the weekends.
<pochu> mantiena-baltix: I guess ask them in #launchpad. But I'm not sure that's the reason the are no templates yet...
<pochu> mantiena-baltix: although as the package is using cdbs, it should have created them, as we patch cdbs to do so
<pochu> mantiena-baltix: carlos or danilos in #launchpad might know
<mantiena-baltix> pochu: yea, they are not active, I don't see nor Carlos nor danilos in #launchpad
<pochu> mantiena-baltix: it's Saturday... I suggest you either mail launchpad-users@ or try on Monday
<soren> Chipzz: When you install libvirt-bin, you automagically get a virtual network set up. It'll fail completely without bridge-utils, and not behave as configured without dnsmasq.
<Treenaks> soren: speaking of the virt stuff.. IT ROCKS!
<Treenaks> soren: now all I'm waiting for is beta, so I can run it on my servers as well ;)
<Chipzz> soren: shouldn't it be a recommends then?
<IrishDavid> hey, im trying to get alpha4 but the server is rather slow, are there any mirrors, I've tried looking and the torrent has no seeds
<slangasek> somerville32: so, daily builds are re-enabled now; if you guys get the xubuntu seed fixed for the libavcodec issue (which seems to require pulling libxine1-ffmpeg, given that libavcodec is blacklisted due to a TB resolution), I'm happy to tag one of them as an alpha-4 if you guys get one you'd like
<slangasek> IrishDavid: we don't mirror the alphas; the torrent tracker was late to be activated but should be up now, which image are you trying to get?
<IrishDavid> i386 altho i also intend to get amd64 eventually to test
<slangasek> IrishDavid: so http://cdimage.ubuntu.com/releases/hardy/alpha-4/hardy-desktop-i386.iso?
<IrishDavid> yeah
<slangasek> ok, checking
<IrishDavid> its downloading at 200kb/s which i guess isnt really slow :) but my connection normally does 1500kb/s off the ubuntu server so i was wondering about a mirror
<crimsun> http://se.archive.ubuntu.com/mirror/cdimage.ubuntu.com/releases/8.04/alpha-4/hardy-desktop-i386.iso and http://se.archive.ubuntu.com/mirror/cdimage.ubuntu.com/releases/8.04/alpha-4/hardy-desktop-amd64.iso
<Joe_CoT> hey, now that alpha 4 is out, any chance a core dev could look at bug 15051 and bug bug 186187 ?
<ubotu> Launchpad bug 15051 in pcre3 "grep -P is not supported" [Medium,Triaged] https://launchpad.net/bugs/15051
<IrishDavid> thanks crimsun
<IrishDavid> thats more like the network utilisation i like to see :D
<mr_pouit> slangasek: the previous builds didn't ship any xfce packages (that's why you experienced a blank screen). Is that fixed? I'll fix the seeds then.
<slangasek> mr_pouit: oh, I have no idea if that's fixed. where did this bug manifest?
<mr_pouit> slangasek: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/xubuntu/latest/ <<< grep xfce returns nothing
<mr_pouit> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/xubuntu/hardy/daily-20080201.log same here ;/
<slangasek> oh, well I guess that could be a problem, couldn't it
<mr_pouit> it didn't like the move to universe maybe...
<slangasek> hrm? I see plenty of references to xfce in the daily log for the alternate; but maybe not the right ones?
<slangasek> but yes, I suppose something's gone wrong with the universe move and the seeding
<slangasek> probably in either germinate or debian-cd; cjwatson is probably the best person to look at this
<mr_pouit> I told him this, but I guess he's off now.
 * slangasek nods
<superm1> slangasek, do you think you can get a moment today to release those binaries that i mentioned yesterday possibly?
<mr_pouit> where are the logs of the alternate builds?
<slangasek> mr_pouit: that's the cd-build-log you're looking at
<slangasek> superm1: yes, I believe so
<superm1> slangasek, great thanks a bunch
<mr_pouit> slangasek: ah ok, thankx ^^
<mr_pouit> -x+s
<slangasek> superm1: lintian reports that libmyth-perl is installed to the wrong path, are you aware of this?
<mr_pouit> yes, the alternate seems to be well generated...
<slangasek> superm1: also, libmyth-0.21-0 would be a more appropriate package name for the given sonames
<superm1> slangasek, there has been no errors with libmyth-perl thus far in our testing
<superm1> let me check something.
<slangasek> superm1: could you perhaps fix the latter and reupload?
<superm1> yeah i can do that
<slangasek> superm1: you won't find an error in testing, but /usr/lib/perl/5.8.8 is a reserved directory for the perl implementation itself, and libmyth-perl will stop being seen in the path if/when we upgrade to perl 5.8.9
<superm1> slangasek, yeah upstream has a few things hardcoded with that regard.  i'll need to bug them to clean that up then
<StevenK> slangasek: 5.8.10, i think you mean
<superm1> slangasek, i'll get a new upload in a few minutes
<slangasek> StevenK: whichever :)
<slangasek> StevenK: you're awake, then I see
<StevenK> slangasek: Yeah. Have been for about two hours - slowly packing
<slangasek> ok
<stgraber> slangasek: can you update the release notes on www.ubuntu.com ?
<stgraber> slangasek: https://bugs.launchpad.net/bugs/188240 instead of https://bugs.launchpad.net/188240
<ubotu> Launchpad bug 188240 in oem-config "[Hardy] OEM install from Desktop CD doesn't work" [Undecided,New]
<slangasek> stgraber: oops, yes, passing this on
<soren> Chipzz: How do you figure that?
<soren> Treenaks: I'm glad that you're glad :)
<jm> If upstream seems uninterested in a patch, should I try to get it into the -ubuntuX patchset, or are those patches reserved for special Ubuntu-only compatibility things?
<ScottK2> They are not reserved for that, but if upstream is uninterested, we'd have to be convinced it was worth the long term extra maintenance burden.
<jm> So the patches would have to be for something important, then? I'm trying to add support for embedded cover art to Rhythmbox/GStreamer, but patches in bugzilla have gone unreviewed and mails to the lists unanswered.
<ScottK2> It depends.  For a package that already has an Ubuntu diff, the barrier is lower.
 * ScottK2 is a Kubuntu person, so I've really no opinion on gstreamer
<pochu> Our gstreamer packages are almost in sync with Debian
<pochu> We have a small diff in debian/rules in all of them, which will be sorted out soon using lsb_release so we can sync them.
<pochu> jm: will the patches land in gstreamer and rhythmbox, or only rhythmbox?
<ScottK2> jm: Which means Debian is probably your best entry point.
<jm> Both
<jm> Gstreamer patches are for creating the "image" tag for FLAC and Ogg/Vorbis files
<jm> Rhythmbox patch is for detecting "image" tag, and storing it as metadata.
<pochu> jm: if they got unanswered upstream, perhpaps it's a matter of resources instead of they don't wanting the patches.
<pochu> jm: have you tried #gstreamer and #rhythmbox on GimpNet?
<pochu> Perhaps you find someone to review the patches there
<jm> Yes, am in them now, but I've asked for devs to take a look and there's been no response.
<jm> Best response was a dev assigning the Ogg/Vorbis patch, but since the latest -base was just released a few days ago I'm guessing it wouldn't be in a stable release in time for Hardy.
<pochu> Unless it's committed to the 0.10.17 branch, I don't think so
<jm> Should I put my patches up on Launchpad with a debdiff? I don't mind if they get rejected, as long as somebody actually sees them.
<pochu> For the gstreamer one, ask slomo when he's around.
<pochu> Rhythmbox one, wait to see if the gstreamer one is accepted, I'd say ;)
<jm> OK, I'll try to go poke the RB devs some more, then.
<pochu> Good luck
<Riddell> jm: if something makes ubuntu better feel free to add an ubuntuX patch, just make sure to pass it upstream as well
<jdong> 666llkjhgffhgfhgfgffddssxcll;;'
<jdong> err... disregard that. cleaning keyboard
<sistpoty> jdong: you forgot some keys :P
<jdong> sistpoty: meh only the home row was really bothering me ;-)
<sistpoty> heh
<jdong> it's only while writing C code that you realize the semicolon has some stuff underneath it.
<mjg59> jdong: Please reping or email me - I'm travelling for the next 20 hours or so
<jdong> mjg59: ok that's fine, you've got bugmail on pm-utils when you get back then :)
<mjg59> jdong: Ok, thanks - which module did you need to deal with?
#ubuntu-devel 2008-02-03
<jdong> mjg59: ath_pci from madwifi trunk
<mjg59> Oh, loss
<jdong> mjg59: after resume the radio appears dead (no scan results, unable to associate)
<mjg59> Yeah, atheros failure
<jdong> mjg59: on another suspend related note....
<jdong> mjg59: after resume on my macbook 3.1, the brightness hotkeys seem to lose function till I restart X
<jdong> this didn't seem to happen on Gutsy
<mjg59> I blame X
<Fujitsu> Speaking of brightness hotkeys... since a week or so ago, g-p-m can control my backlight. However, since then my backlight brightness will often spontaneously increase to maximum (quickly, not over several minutes like it used to). This is an i915.
 * StevenK waves to Fujitsu from Portland
<Fujitsu> StevenK: Portland, Vic?
<StevenK> Fujitsu: Heh, no. Portland, Oregon. :_)
<Fujitsu> Bah,
<jm> I'm trying to create a new version of gst-plugins-base, but for some reason the /debian/control file keeps getting its Build-Depends and Architecture lines changed. If I submit a debdiff with these changes, will it be a problem?
<TheMuso> jm: Does the package have a debian/control.in?
<jm> Yes
<TheMuso> Modify that.
 * StevenK looks forward to being in a country that isn't in the grip of winter.
<TheMuso> StevenK: I hear ya. London wasn't that cold, but it was nice to get back to summer.
<jm> My modifications don't touch control or control.in at all, but they are still changed.
<TheMuso> ah ok
<StevenK> TheMuso: Portland has been averaging about 3 degrees C, which I think is too cold.
<TheMuso> StevenK: I'd agree with that assessment.
<jm> Is it a problem? Whatever's changing control doesn't seem to be under my control.
<sladen> cold is good.
<TheMuso> jm: At this point, all I can say is submit a debdiff, and take things from there.
<jm> K, will do.
 * StevenK does some NBS work to pass the time
<TheMuso> StevenK: Pass the time until when? :p
<StevenK> TheMuso: About 5:45pm local
<TheMuso> ah ok
<TheMuso> StevenK: When do you fly out
<StevenK> A little after that :-)
<zul> evening
<TheMuso> heh right. Enjoy your flight.
<StevenK> TheMuso: That's only the first hop from Portland to San Francisco :-/
<TheMuso> StevenK: Oh even more fun.
<StevenK> After a few more hours in San Francisco airport, then back to Sydney
<TheMuso> Oh fun. The good old 13 hour flight. I had a couple of those recently. :)
<mjg59> StevenK: Ha. I'm about to head in the opposite direction
<StevenK> It hits 14.5 hours back from the US, due to the prevailing wind blowing toward you
<StevenK> mjg59: Heh
<TheMuso> StevenK: Well, enjoy.
<slangasek> StevenK: you found the lounge, then?
<Hobbsee> yay, he eventually obeyed the invite, so the forward wasn't necessary.
<TheMuso> Hobbsee: What was that all about?
<Hobbsee> TheMuso: apparently he thought it was valid not to obey channel topics, because there were no ops active in there at the moment, so no one could tell him off
 * Hobbsee has since enlightened him.
<TheMuso> Right.
<jdong> Hobbsee the enlightener :)
<Hobbsee> !jdong | jdong
<ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<Riddell> bryce: do you know iRon is working on bullet proof X for kdm?
<bryce> Riddell: is iRon == Eudege Tretyak?
<bryce> Eugene and I have been exchanging emails today about kde and bpx.
<Riddell> bryce: ah, excellent
<Riddell> he is yes
<bryce> cool
<bryce> he says he'll be sending me some patches, and I'll review/integrate after that
<superm1> bryce, have you considered integrating something like xf4vnc into the xorg tree by chance?
<bryce> superm1: why?  no I've not considered that
<superm1> bryce, well realvnc stopped working against xorg 1.4
<superm1> yet xf4vnc is tracking the 1.4 tree actively
<superm1> and there aren't any other projects that i've heard of that provide libvnc.so (by building in the xorg tree)
<superm1> additionally upstream has no indication that they will be updating it to work against xorg 1.4, since they are still actively supporting builds against monolithic xfree86
<bryce> hmm, I've not really been involved with support for realvnc, so not sure why I'd have an iron in the fire for xv4vnc..
<superm1> bryce, wasn't sure if it was you who had a hand in it (since the source package ships with xorg in the package)
<superm1> well i'll try to leave some comments on the bug at least then for whomever will be responsible for realvnc with the research i've gotten around upstream and my attempts to resolve issues
<bryce> ok cool
<warp10> Good morning
<pitti> hi warp10
<warp10> hey pitti!
<Hobbsee> heya pitti!
 * pitti hugs Hobbsee
<tuxist> hi
<tuxist> have anybody get kde_luks runnable under gutsy ?
<tuxist> i have download source and packaged them
<ScottK2> tuxist: For packaging new packages, #ubuntu-motu is the best channel.
<tuxist> so i got only the encrypt dialog and nothing happsa
<pygi> siretart, poke
<theunixgeek> Is there a GTK interface designer that can generate source code for you?
<thegodfather> 16:21 -!- cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has quit [Read error: 110 (Connection timed out)]
<thegodfather> 16:22 -!- DRebellion [n=DRebelli@unaffiliated/drebellion] has quit ["leaving"]
<thegodfather> crap
<thegodfather> sorry
<thegodfather> my son got hold of the mouse
<zul> i hate that when it happens :)
<kieran__> hi there, has there been any reports of compiz hardlocking computer in hardy?
<hunger> Anyone working on a fix to aptitude?
<superm1> !weekend > hunger
<siretart> pygi: not really around. email is much more likely to reach me
<pygi> siretart, ah, ok, will bug some other time then
<siretart> k
<slangasek> hunger: at any rate, it's hard to know what you're referring to when the aptitude bug list shows no open bugs of higher than 'medium' importance
<superm1> slangasek, if you get a few minutes again today, I made both those changes to those debs in hardy NEW.
<slangasek> superm1: done
<superm1> thanks a bunch slangasek
<slangasek> doko: har, you requested the sync of siege?  (FTBFS on 9 archs in Debian for > 30 days, now FTBFS in Ubuntu on all archs)
<jm> slomo: I heard you're the guy to go to about GStreamer questions. What are the chances of my patch to bug #188488 getting into Hardy?
<ubotu> Launchpad bug 188488 in gst-plugins-base0.10 "Support embedded cover art in Ogg/Vorbis files" [Undecided,New] https://launchpad.net/bugs/188488
<jdong> anyone know if powertop 1.9 is compatible with Gutsy?
 * lamont chuckles at 463758
<zoke> bug 456758 ?
<lamont> and off to fix Teh Intarwebs.
<lamont> yeah
<zoke> err
<zoke> bug 463758
<lamont> "fdisk doesn't like devices without partition tables'
<zoke> lol
<ion_> :-D
<zoke> but ubotu tells me the bug doesn't exist
<pochu> Debian bug 456758
<ubotu> Debian bug 456758 in libcucul-dev "Whatis for libcucul-ruby-api.3caca.gz exceeds 2048 bytes" [Minor,Open] http://bugs.debian.org/456758
<pochu> Not that one :)
<lamont> debian bug 463758
<ubotu> Debian bug 463758 in util-linux "MP3 players: can mount(1) fine, but [cs]fdisk say "unknown partition table"" [Normal,Open] http://bugs.debian.org/463758
<lamont> that one
<pochu> I misstyped it :/
<lamont> basically gnome-volume-manager etc is not recognizing devices without partition tables (see any current-generation mp3 player - thanks guys)
<lamont> anyway, this guy is out for a few hours, probably bouncing a bit while he messes with upstream connectivity
<TheMuso> c/
<TheMuso> ugh
<emgent> hyea
#ubuntu-devel 2009-01-26
<HorizonXP> i need to recompile a package. how do I figure out what configure options were being used in the default package?
<RAOF__> HorizonXP: Probably better asked in #ubuntu-motu, but the answer will be in debian/rules.
<HorizonXP> RAOF__: thanks. but what's motu stand for?
<NCommander> Any archive admins around?
<calc> is the new motd package update information buggy?
<calc> it claims i can update package but when i go and try to do so apt-get claims there is nothing to update
<calc> apparently update-motd isn't being run when it should be
<calc> hmm perhaps it just hadn't been 10m since i updated, i'll have to watch it more closely next time
<pitti> Good morning
<dholbach> good morning
 * slangasek waves
<dholbach> hiya slangasek
<tkamppeter> Is there a GUI tool to configure ufw in Ubuntu?
<iulian> gui-ufw IIRC.
<iulian> It's gufw.
<tkamppeter> iulian, thanks. Strange is that it is in universe, but ufw is in main. So the standard installation ships with firewall but without config ttol.
<stdin> ufw is a config tool
<stdin> the firewall is in the kernel (iptables)
<slangasek> tkamppeter: it's intended that the primary mode of operation for ufw should be entirely hands-off to where users don't have to configure it for the common case; the GUI wasn't part of the original spec (though eventually we ought to support full configuration through some GUI)
<dholbach> thanks pochu :-)
<pochu> yw :)
<pochu> nice page btw
<dholbach> it's been there for ages :)
<dholbach> not exactly used muchly, I guess :)
<pochu> was it linked from the header too?
<dholbach> pochu: yes
<cody-somerville> slangasek: Can you allow libxfcegui4 through the NEW binary queue? Its holding up the new xfce4.6 from building.
<slangasek> cody-somerville: I'm processing the new queue this morning ,yes.
<Riddell> kees: did you do the security review of quassel?  bug 317892
<ubottu> Launchpad bug 317892 in quassel "Quassel main inclusion report" [Undecided,Incomplete] https://launchpad.net/bugs/317892
<Riddell> asac: poke on bug 314778
<ubottu> Launchpad bug 314778 in google-gadgets "Main inclusion for Google Gadgets" [Undecided,New] https://launchpad.net/bugs/314778
 * asac looks
<Riddell> asac: also polite poke on bug 319571 319998 320012 320028 :)
<ubottu> Launchpad bug 319571 in policykit-kde "policykit-kde inclusion to the main repository" [Undecided,New] https://launchpad.net/bugs/319571
<asac> Riddell: please upload gadgets with the patch
<Riddell> asac: ok
<asac> Riddell: err
<asac> +debian/google-gadgets/usr/lib/google-gadgets/modules/smjs*.so usr/lib/google-gadgets/modules
<asac> isnt that exactly the part we dont want?
<asac> Riddell: ^?
<Riddell> asac: would have thought it was the gtkmozilla bits that were the problem
<Riddell> asac: that file isn't linked to anything unusual
<asac> Riddell: the problem is the js/
<asac> Riddell: its using the js glue that is shipped in source
<asac> hence you wont see any libs with ldd
<asac> Riddell: please check whether the smjs module interfaces with jsapi.h et al
<Riddell> asac: yes looks like it does
<asac> Riddell: the gtkmozembed stuff should be ok
<asac> the ./extensions/smjs_script_runtime is the problem here
<Riddell> asac: and remind me again what the problem is?
<asac> Riddell: https://bugs.edge.launchpad.net/ubuntu/+source/google-gadgets/+bug/314778/comments/1
<ubottu> Launchpad bug 314778 in google-gadgets "Main inclusion for Google Gadgets" [Undecided,New]
<Riddell> asac: so it does runtime loading of the mozjs library?
<asac> Riddell: yes. it loads the mozjs library and assumes ABI/API stability - for which there exists no policy
<Riddell> asac: they really should have used webkit :)
<Riddell> asac: oh well, it doesn't work without that smjs bit so best just reject the MIR
<asac> Riddell: what would be the loss if we dont have that in main=
<asac> ?
<Riddell> asac: people couldn't use google gadgets inside KDE's plasma, no major problem currently for users, might make upstream upset that they added support for something which doesn't get shipped but we can live with that
<asac> Riddell: i talked to the google gadget guy about this a while a go
<asac> at that time i didnt know it would become a kde lib
<asac> Riddell: he understood the problem and said he didnt care for now.
<Riddell> asac: that's fine, it's not a big loss at all
<asac> Riddell: we also had discussion about this with spidermonkey folks ... who weren't aware that ABI/API policy is important to have. but now they know so hopefully they'll fix it soonish
<asac> Riddell: complaining to them that something didnt made it into ubuntu might help to increase priortiy
<asac> Riddell: so in case upstream gets upset tell them to file a bug about this against spidermonkey
<asac> to reemphasize the point
<Riddell> asac: can it be fixed?  surely it would take mozilla to create the stable ABI?
<Riddell> oh, spidermonkey is mozilla upstream
<asac> Riddell: yes.
<ogra> cjwatson, i'm a bit confused, looking at config.initramfs in busybox tells me that we dont enable stty, but trying out a debian etch arm initramfs in qemu stty is available, do we have a delta here (i cant seem to find a big difference)
 * ogra is writing an initramfs script for arm that relies on stty in some functions
<ogra> no mention of stty in our changelog either
<cjwatson> ogra: probably comes from some other package than busybox
<ogra> (initramfs) help|grep stty
<ogra> 	strings stty swapoff swapon sync sysctl syslogd tac tail tar
<ogra> doesnt look like
<ogra> though thats debian etch
<cjwatson> don't know then, sorry. it's not in my initramfs according to 'help'
<ogra> ah, k, probably debian just puts a different busybox in there
<cjwatson> Debian doesn't have a busybox-initramfs
<cjwatson> that's something jbailey added for us that never got merged
<ogra> or *did* put a diffenrent one there
<ogra> ah, right, that would explain it
 * ogra would like to see stty enabled in ours then, do you think thats a prob ? 
<cjwatson> ogra: no, could you please file a bug with the reasons so that we have a record though?
<ogra> yep, though the spec that relates to isnt completely up to date yet but i can explain in the bug
<soren> cjwatson: Waht do they have instead, then?
<ogra> cjwatson, bug 321424 (sorry for the longish explanation, that will need to go into https://wiki.ubuntu.com/Specs/ARMSoftbootLoader actually)
<ubottu> Launchpad bug 321424 in busybox "please enable stty in busybox initramfs" [Undecided,New] https://launchpad.net/bugs/321424
<ogra> soren, we'll need to talk about vm-builder arm images in berlin :) ... (i'd like to replace http://people.ubuntu.com/~ogra/arm/build-arm-rootfs by it if possible)
<soren> ogra: Sure.
<ogra> great
<ogra> i'm not sure it can fulfill all purposes, but surely replace a lot already
<cjwatson> soren: not sure, I think it's an ordinary unreduced busybox package
<soren> cjwatson: Oh.
<soren> cjwatson: I thought you meant they didn't have a busybox in their initramfs. :)
<soren> It *did* sound odd :)
<cjwatson> I really don't approve of this plan to run update-grub for arm
<cjwatson> other architectures have their own bootloader configuration schemes; there is no reason why arm cannot
<ogra> cjwatson, well, why reinvent the wheel ?
<ogra> we can call it differently but its only a script
<cjwatson> there is already more than one wheel of different shapes and sizes :-P
<ogra> the advantage is that we dont have to modify the kernels at all
<cjwatson> lazy
<ogra> no, cautious about maintenance overhead
<ogra> we have a workinf system, why not use it
<cjwatson> also, if you focus on mimicking grub in every last detail, then you'll find that you get screwed when we switch to grub2 - suddenly you'll look old
<ogra> *working
<cjwatson> this is not a problem for powerpc (yaboot/kboot) hppa (palo) sparc (silo) ia64 (elilo)
<cjwatson> implement your own configuration scheme - don't hijack grub's
<cjwatson> at least not unless you are actually using grub
<ogra> well, it doesnt need to be called menu.lst at all :)
<cjwatson> the kernel hook for this stuff is trivial, which is why I said "lazy"
<Keybuk> then the script does not need to be called update-grub
<ogra> i wouldnt like to rewrite update-grub just to have something that produces the actually same output
<ogra> Keybuk, thats what i say
<doko_> lool, seb128: plesae could you apply the two recent pulseaudio patches seen here (http://cvs.fedoraproject.org/viewvc/devel/gstreamer-plugins-good/) afaiu these are taken from upstream.
<ogra> i want the identical functionallity with identical output and dont want to add a new source package for that to the archive, so we dont have to maintain the same thing twice
<ogra> (and arm benefits from fixes of that script on x86)
<cjwatson> you clearly aren't going to implement all of grub's commands
<ogra> nah
<cjwatson> I'm concerned that if you emulate update-grub, people will be misled
<ogra> there is no grub shell
<Keybuk> what if the fix on x86 changes the output in a way that you can't parse?
<ogra> i fix the parser
<Keybuk> I bet you won't
<Keybuk> I'll bet you'll file a bug on update-grub
<cjwatson> what if it's an emergency fix for i386 two days before release?
<cjwatson> by the way, other bootloaders have a *much* simpler configuration file format than grub does
<cjwatson> and of course grub2 has a completely different configuration file format
<ogra> hmm, that would be bad indeed, but i doubt update-grub will just change its output format, i somewhat rely on the backwards compatibility it will have to have
<cjwatson> it only needs to have backwards compatibility for grub itself
<slangasek> and if we're talking about menu.lst, the format is a source of longstanding bugs in Ubuntu anyway
<cjwatson> right, it's an awful thing to emulate
<cjwatson> (I'm happy to add stty and have done so)
<ogra> if you look at my script, all it does is read "default", "hiddenmenu", "timeout" and the various "kernel", "title" and "append" data
<Keybuk> ogra: so you're _not_ handling the full grub configuration?
<slangasek> asac: hmm, I think maybe in jaunty NM is finally really letting me store my wireless settings as a system connection ("available to all users"); in the process, it also seems to disappear from the list of connections I'm allowed to edit from the GUI :)
<ogra> nah, its not a grub shell
<Keybuk> then you shouldn't copy update-grub
<ogra> but i rely on the format of menu.lst
<Keybuk> write yourself a much simpler format
<ogra> and it indeed helps to have it using kopt etc on the update-grub script side
<slangasek> yes, those are the broken things that you should avoid emulating at all costs
<ogra> i dont emulate anything on that side
<ogra> i planned to raly on update-grub for this
<slangasek> s/emulating/inheriting/
<ogra> *rely
<cjwatson> you're talking as if update-grub is something good
<cjwatson> it's actually a pile of historical cruft that is the source of many bugs
<ogra> the only thing i care for is to parse the uncommented lines of menu.lst
<slangasek> kopt is the single largest reason I want us to switch to grub2
<ogra> and i dont want to care for the side that generates it
<cjwatson> carrying it over to a new architecture is saddling that architecture with a bunch of complex history right from the start
<cjwatson> every single other architecture that doesn't use grub created its own simple file format
<cjwatson> I see no reason for armel to be different
<ogra> writing the whole update-grub side *additionally* is a waste of manpower imho
<cjwatson> so don't do something as complex as update-grub
<ogra> but indeed i can do that
<cjwatson> there is absolutely no need for it
<ogra> note that the script is also supposed to read syslinux.cfg (as i noted in the bug description)
<slangasek> most of update-grub is a crutch for a broken file format.  If you get your format right (by not copying grub's), you don't need it.
<cjwatson> you've had a bad case of feature creep before you've even got started!
<lool> ogra: Err right I have to agree with cjwatson about menu.lst parsing
<lool> I thought that was just for experimentation
<ogra> the trampoline initramfs script side doesnt care at all what is in the target system it just wants a kernel, initrd and append line from a file
<cjwatson> syslinux's format is certainly more the sort of thing I would aim for if I were doing this, but I'd only implement *one* format
<lool> ogra: Also I'm rather unconfortable with having a custom implementation of a boot menu based on stty
<ogra> lool, well, i wanted to keep the implementation work as low as possible
<lool> I'd rather either have it very dumb or integrate some lib such as libreadline or libncurses to do it
<ogra> lool, well, the script is done
<ogra> but i can throw it away if you prefer
<lool> I can look at it and tell you whether I think we should throw it away; without looking at it I think we should, but perhaps I'll change my mind
<asac> slangasek: so i guess the settings are properly saved? can any user use it afterwards?
<lool> But I need to go for lunch
<lool> bbl
<ogra> lool, feel free to do so :)
<slangasek> asac: they are properly saved; I'll let you know on next reboot whether it comes up automatically before login
<ogra> lool, http://people.ubuntu.com/~ogra/arm/bootmenu (for post lunch inspection) :)
<ogra> lool, it is executable on any x86 system in a terminal for testing atm ...
<asac> slangasek: do you see the connection in the applet at all? or just not in the editor?
<slangasek> asac: it shows up in the applet, just not in the editor
<asac> ah ok.
<slangasek> asac: but, er, killing nm-applet kills the connection
<slangasek> so apparently upstream and I still have jarringly different definitions of a "system" connection. :P
<cjwatson> hm, http://launchpadlibrarian.net/21642741/buildlog_ubuntu-jaunty-lpia.busybox_1%3A1.10.2-2ubuntu2_FAILEDTOBUILD.txt.gz looks like a libc6-dev/linux-libc-dev bug
<cjwatson> busybox doesn't redefine iphdr
<ogra> oh
 * ogra wonders why that didnt show up before 
<doko_> TheMuso: any idea about http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=284 ?
<cjwatson> linux-lpia only recently went to 2.6.28
<ubottu> icedtea.classpath.org bug 284 in IcedTea "fails to build with pulseaudio-0.9.14" [Normal,New]
<cjwatson> so, recent change
<ogra> ah, right
<asac> slangasek: so what did you do: take a currently connected user connection and made a system one out of it;)?
<cjwatson> amitk: could you look at http://launchpadlibrarian.net/21642741/buildlog_ubuntu-jaunty-lpia.busybox_1%3A1.10.2-2ubuntu2_FAILEDTOBUILD.txt.gz? it looks as if the lpia headers are a bit broken
<slangasek> asac: right, my "auto" wireless connection still doesn't come up until nm-applet is launched.  Gar.
<slangasek> asac: yes, that's what I did.  Is there any reason that shouldn't work?
<cjwatson> amitk: oh, hmm, never mind, now I get an identical build failure on i386 too
<slangasek> (it didn't interrupt my connection until killing nm-applet)
<asac> slangasek: well. if you didnt reconnect, the connection would still be a user one
<slangasek> asac: from a UI standpoint, that makes no sense whatsoever
<slangasek> and from a functionality standpoint, I still want to punch NM for Doing It Wrong
<ogra> cjwatson, our busybox isnt linked against klibc atm, right (so we need glibc in the initramfs) ?
<asac> i think the idea is that you dont want to break network when user is flagging stuff as system
<asac> once the applet disappears it should automatically go to the system one
<slangasek> asac: but even after killing NM, nm-system-settings, and nm-applet, then restarting NM, the connection doesn't come up until I launch nm-applet
<asac> slangasek: thats a bug. a system connection that is set to auto should show up. maybe it just takes a while=
<slangasek> oh, and the user-level profile is back again
<asac> ?
<cjwatson> ogra: yes. everyone else is following the same trend
<slangasek> asac: how long of a while should it take?  If I launch nm-applet, the connection is instantaneous
<asac> slangasek: it could be that starting applet triggers scanning.
<cjwatson> ogra: because many initramfses need things like mdadm, devmapper utilities, or whatever as well, and as soon as you include one of them you need glibc anyway - or else you need two versions of everything, and the klibc one gets much less testing and ends up being buggier
<asac> slangasek: but first thing you should check out is if it connects ata ll without nm-applet ;)
<slangasek> asac: ah.  how could I trigger a scan manually w/o nm-applet, to confirm whether that's the case?
<slangasek> asac: ok, how long should I wait for it to connect w/o nm-applet before declaring it broken?
<asac> slangasek: not through nm ... but you can send a dbus message to wpasupp
<ogra> cjwatson, yes, i know the reason, but its unlikely we need it in that setup
<asac> slangasek: assuming that you kill/restart all i would suggest that you tail the syslog
<asac> and see if something is happening
<cjwatson> ogra: I'm even less keen on using klibc extensively on arm
<ogra> and we have very limited space in the flash usually
<asac> should be easy to identify whether NM does something ... or just nothing
<cjwatson> testing is light enough as it is
<ogra> agreed
<ogra> though 77k vs 1.1M is quite a difference
<slangasek> Jan 26 04:23:37 dario NetworkManager: <info>  (wlan0): bringing up device.
<slangasek> Jan 26 04:23:37 dario NetworkManager: <info>  (wlan0): preparing device.
<slangasek> Jan 26 04:23:37 dario NetworkManager: <info>  (wlan0): deactivating device (reason: 2).
<slangasek> asac: ^^
<slangasek> asac: then some other stuff, again, doesn't bring the connection up until nm-applet is started
 * pitti discovers https://addons.mozilla.org/en-US/firefox/addon/5817 (SQLite manager), nice tool
<slangasek> asac: should I file a bug report at this point with the full grep NetworkManager /var/log/syslog?
<asac> slangasek: yes. can you also leave instructions which steps you used to create the system connection
<slangasek> asac: sure.  That part should either work or not, though, shouldn't it?  I.e., if there's a config under /etc/Network/system-connections, that should do it?
<asac> slangasek: in theory yes. but also attach that system connection file then please
<asac> sanitize your psk or other secrets ;9
<slangasek> ok
<asac> thanks
<slangasek> asac: how about the nm/hal/openvpn bug, btw?  Do you agree that keying on the device is correct, or disagree, or are you still thinking it over?
<lool> ogra: it's not remotely as ugly as I feared, but I remain unhappy that we start a mini UI lib in shell and in the initramfs
<lool> The sed foo is awful though
<ogra> lool, hey, its my first attempt :)
<ogra> i just wanted it to work for now ... beutification can happen later
<lool> I'm referring to this line: cat ${FILE}|grep ^kernel|sed -s 's/^kernel//g'|sed -s 's/ /_/g'|sed -s 's/\t//g'|tr '\n' ' '
<ogra> yes
<ogra> there are more like this
<slangasek> sed -n -e's/^kernel//p' $FILE | ...
<ion_> slangasek: No, the following substitutions can be added to the same sed invocation as well.
<Chipzz> lool: I was thinking the same thing :)
<Chipzz> but hey, if it works, it's good enough for a first try :)
<slangasek> ion_: not without quite a bit of pain, due to the /p
<ion_> slangasek: Easy: /foo/ { s/foo/bar/; ...; p }
<ogra> right, after beautification it should be a single sed command
<asac> slangasek: hmm. maybe we should look at the driver info field. In syslog NM spits out a driver for each device it looks at ... what do you see there?
<asac> is that NULL?
<ogra> lool, though if we drop the menu.lst support anyway we can as well drop the ugly stuff ;)
<slangasek> asac: Jan 26 04:54:56 dario NetworkManager: <info>  tap0: driver is 'NULL(info.linux.driver)'.
<slangasek> asac: ... because that information comes from traversing net.originating_device :)
<asac> slangasek: yeah. but now that i see that log entry i remember that there were even bogus drivers out there that didnt have a linux.driver
<asac> so lets really use the parent
<asac> and hardcode /computer
<asac> i will ask upstream what they think
<lool> ogra: I don't quite know what you had in mind with the _ transliteration, I don't see how you get the original _ back
<lool> sed -rn '/^kernel[[:space:]]/ { s/kernel[[:space:]]+//; y/ /_/; p }' /boot/grub/menu.lst
<lool> /vmlinuz-2.6.28-5-generic_root=/dev/mapper/raid1-root_ro___crashkernel=384M-2G:64M@16M,2G-:128M@16M
<ogra> lool, its only substituted for the UI, that surely needs a cleaner solution
<lool> ogra: But back to the stty concerns
<ogra> tell me
<lool> ogra: Consider ^?: that's not necessarily the backspace char in all terms AFAIK
<ogra> well, it only has to work in intramfs
<ogra> *init
<lool> What if I press a function key?  Is the sequence swallowed or does it generate stuff?
<ogra> and i havent even tried it there yet
<ogra> its swallowed
<ogra> try it out :)
<lool> How do you tell how many chars to swallow?
<ogra> if there need to be adjustments for the tty in initramfs i'll do them
<ogra> the dd only reads one byte ...
<ogra> and i capture only the last piece of that
<lool> ogra: With bash I get garbage and can't do anything but ^C
<lool> With busybox sh I don't get a kernel list
<ogra> its not written in bash
 * ogra tried with ash
<ogra> as thats the compiled in shell
<ogra> you should also probably call it with LANG=C ....
<ogra> there wont be translations in initramfs
<lool> It flashes when I change lines with /bin/sh
<ogra> it redraws, indeed, flashing isnt avoidable if you do it in shell ... that would require C
<ogra> lool, thats not a final implementation and it only has to work in one single environment
<ogra> its just a proof of concept weekend hackery
<slangasek> asac: bug filed (321442)
<lool> ogra: If I press B, the cursor goes down
<ogra> right, thats a bug i will need to tackle ... but not really bad
<lool> ogra: I think flashing would be avoided if you would draw on top of it and clearing until the end of the line instead of clearing the screen
<ogra> it doesnt do any harm
<lool> ogra: Anyway my point is your point: let's not reinvent the wheel
<ogra> thats actually a good idea
<lool> There are libs to do exactly this
<lool> Starting with readline and ncurses
<ogra> which we need to pull into a way to big initramfs
<ogra> i strongly disagree
<ogra> we dont have the space
<ogra> if it needs to be in C thats fine, but adding additional libs is a nono imho
<lool> So let's link it statically since this is basically part of the boot loader
<ogra> which makes it big as well
<ogra> no way how you link it, you will have added size
<ogra> *s/way/matter/
<lool> But it will be maintainable, stable, and best of all maintained by someone else
<ogra> my target was to eep it as small as possible and work with the available bits and pieces
<ogra> *keep
<ogra> size is our biggest concern in that whole setup
<ogra> which is why i went with an ash script
<lool> I don't think having a complex menu is critical
<primes2h> pitti: Thanks for accepting my patch.
<lool> For instance the MBR from the mbr package only allows you to press 1234AD or something similar
<ogra> lool, surely not ... neither is line editing
<lool> Do we need line editing?
<ogra> if ou want to drop splash for a kernel line
<ogra> if find the line editing one of the biggest grub features we have
<lool> The more hacks keep piling, the more I think that the whole shim idea should die
<ogra> if i mess up with a broken kernel *and* update-grub didnt do the right thing, i can still hit ESC and edit manually to get my system booting
<ogra> lool, yes, but what do we do then ?
<lool> If we had 1 MB to spend in the NOR flash for something, we could spend it in redboot drivers for the display and usb keyboard
<lool> I realize it's not the same type of development, but I definitely think we're piling hacks to solve the problem in the wrong way
<ogra> that doesnt help with an inaccessible flash
<lool> An inaccessible flash?
<ogra> my concern is that o enduser should have to use serial ports ... and we have boards where we dont have access to the flash at all
<ogra> my current solution would allow you to boot a livesystem from USB or CD ... and would be able to fall back to an internal disc
<lool> We don't know what space constraints or driver we have on other boards; we don't even know whether we will have the room to store a kernel or an initramfs in the flash
<ogra> without having to add much more to the script (beyond stealing some detection mechanisms from casper)
<ogra> i totally agree that all we do here should be done by the bootloader in a proper way
<ogra> but as it is today we have at least three different boot methids and none of them will be able to grow the support we want
<lool> ogra: What bothers me is that we're piling hack on hack to make this a more standard user friendly experience, but the result is a more fragile, more complex, and imperfect result
<ogra> i dont see the fragility in my attampt though ... its not more fragile than casper
<lool> This is combined with the fact that we're loading two kernels and using kexec
<ogra> i have concerns about kboot and petitboot
<ogra> kexec is a method even out kernel team uses
<ogra> so it gets testing in the right place
<lool> Consider 1) a safe validated kernel which we update from time to time in the flash, and QA before releasing Ubuntu and 2) one first static kernel, + special initramfs, with custom shell library to draw a menu and detect the root which kexecs another one
<ogra> how do you achieve 1 ?
<lool> kexec was broken a week ago and nobody noticed
<ogra> i'm fully with you if you have a solution
<lool> 1) is how we got the board
<ogra> lool, dont forget i was the biggest opponent to the softbootloader in the beginning (if you remember) but not seeing any better solution made me change my mind
<ogra> i think its a crazy solution that sucks ... but its the one that sucks least
<ogra> at least if it comes to user experience, liveFS handling and updates
<pitti> primes2h: thanks for fixing it :)
<apw> tseliot, about?
<tseliot> apw: ?
<apw> tseliot, hi ... been looking at some panics which upstream is blaming on the nvidia driver
<apw> wanting to go back to the users and ask them what drivers they are using and get them to test with the latest
<tseliot> apw: in which distribution?
<apw> and am coming up short understanding how we decide which one is installed
 * directhex is wondering when to expect an nvidia driver with support got gtx 285 and 295
<apw> ubuntu, intrepid and jaunty
<apw> and i guess it makes sense to say ... have you heard anything on them
<apw> these are all Eeek! jobs
<tseliot> apw: I wrote nvidia-common for that
<apw> aha, so like linux-meta?
<tseliot> well, it depends on the modaliases generated by each driver version
<tseliot> and these modalias files can be found in /usr/share/jockey/modaliases/
<tseliot> so that I can see whether a driver supports a certain pci-id of a card or not
<tseliot> if more than one driver supports the same card or more than one card is available then nvidia-common decides which driver version is better for you
<apw> so they should have all of the versions of nvidia driver listed on the depends line, and be using the latest of those that supports their card
<apw> and is there anything newer than 180 that they could test with to help elimintate/confirm the driver as the issue?
<tseliot> only the nvidia-VERSION-modaliases packages
<apw> tseliot, ahh i miss understood.  so what decides which actual packages are  installed
<tseliot> no, not yet
<tseliot> apw: in Jockey, do you mean?
 * apw actually isn't sure what Jockey is :/
<tseliot> Jockey (aka Restricted Drivers Manager)
<apw> oh i see
<apw> so jockey decides which drivers to install based on the modalias info
<apw> so the statment "they should have the latest which supports their card" is accurate?
<apw> and right now that includes everything upto 180 and that is the latest
<tseliot> Jockey uses nvidia-common to do that and adds a small [Recommended] tag to the driver it deems  more appropriate
<tseliot> yes, if you have only one card
<apw> yeeks, more than one, error :)
<tseliot> and yes 180 is the latest
<tseliot> well, you could have 2 cards
<directhex> even better, 2 cards with no common driver support
<tseliot> which are both supported by the same driver (which is not the latest)
<tseliot> but one card supports the latest version
<tseliot> and nvidia-common will choose the driver which supports both
<apw> i presume if there is no common driver jockey throws in the towel
<tseliot> or, in the case suggested by directhex, the card supported by the latest driver wins
<tseliot> ^^
<apw> ahh
<directhex> it's a real scenario!
<tseliot> I think it makes sense to use the newer card
<apw> when did 180 release?  date wise?
<apw> yeah given an impossible situation that seems logical choice
<directhex> [root@clearspeed ~]# lspci | grep nVidia
<directhex> 07:00.0 VGA compatible controller: nVidia Corporation Unknown device 05e7 (rev a1)
<directhex> 0c:02.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)
<apw> heh
<tseliot> 180.22 was released on 01-08-09
<apw> so i assume we see the nvidia drivers in dkms land
<tseliot> http://www.nvnews.net/vbulletin/showthread.php?p=1897256
<tseliot> apw: ?
<apw> tseliot, given a machine how do i find out which driver jockey has chosen
<tseliot> type: dkms status
<tseliot> which, in my case, says: nvidia, 180.22, 2.6.28-5-generic, i686: installed
<apw> nice .. will ask for that
<tseliot> apw: keep in mind that nvidia has yet to release a driver which works well with Jaunty's Xserver
<apw> mostly i have intrepid users complaining, but i see a common thread of Tained: P in the panics, and upstream is attributing the current spate of Eeek! with nvidia being installed
<apw> so i want to ask those affected if they have nvidia and if so which version
<tseliot> ok
<apw> to see if they are all that or not
<apw> would be nice to find half don't have it to elminate that
<tseliot> yes, but it could also depend on the BIOS
<tseliot> which not always plays well with the nvidia driver
 * directhex blames kernel panics on sky2.ko
<stefanlsd> im using jaunty with the 180 nvidia drivers and the ignoreABI setting, no problems so far
<apw> tseliot, is there any workable alternative OSS driver for any of these cards, even if its a lot crap without 3d or whatever, that we could use for elimination purposes?
<tseliot> apw: "nv"
<apw> so i could also ask them to try running with that instead
<apw> that sounds like a good plan
<apw> then we'll have something contrete as a test plan
<tseliot> stefanlsd: yes, I was referring to something which doesn't require the IgnoreABI option
<tseliot> good
<directhex> tseliot, is 180.22 coming to intrepid-updates? it seems odd to have 180.11 beta in there
<tseliot> directhex: I would like to use the backports for future driver updates
<directhex> or perhaps superm1 should be asked instead
<tseliot> using -updates can break things
<directhex> tseliot, well, either way. actually, i want >180.22 since i'm interested in buying a gtx285 :p
<apw> its sounding like directhex should be directnv
<tseliot> I'm a bit busy but I'll update the drivers in jaunty and intrepid ASAP
<tseliot> hehe
<apw> tseliot, that might help me diagnose this kernel issue too ...
<apw> could you let me know when you get an updated version in, subscribe me to the bug or whatever (apw in launchpad)
<tseliot> apw: ok
<apw> you are a star
<apw> tseliot, this is bug #252977 if you are interested
<ubottu> Launchpad bug 252977 in linux "Hardy and Intrepid freeze with kernel error: "Eeek! page_mapcount(page) went negative! (-1)"" [High,Incomplete] https://launchpad.net/bugs/252977
<tseliot> apw: now, that I think about it, I'll have to use -updates in intrepid because I need to fix another bug. I'll let you know when it's done
<apw> thanks
<maxb> nvidia-180 in -updates is a bit of a special case because it's an outright new package, hence less breakage potential
<ebroder> Where can I find a package that actually activates a trigger? All of the initramfs-tools-related packages I can find just call `update-initramfs -u` instead of having a DEBIAN/triggers file
<slangasek> ebroder: if you have a look inside the update-initramfs script, I believe you'll see that this script turns the call into a trigger centrally
<ebroder> slangasek: Yeah, I got that. Is that the only supported way to do triggers, though?
<maxb> ebroder: man deb-triggers
<slangasek> ebroder: no, it's just convenient in this case because it lets us use triggers without having to fix up all the third-party kernel packages
<slangasek> s/use triggers/get the full benefit of triggers/
<ebroder> maxb: I don't have a deb-triggers manpage
<ebroder> slangasek: Right - I'm working on some site-local packages where I want to use triggers, and at the moment the triggers don't seem to be triggering, and I'm looking for an example to compare to
<maxb> ebroder: the manpage should be shipped in dpkg-dev package
<ebroder> maxb: Ok - I see it, but it didn't in Hardy
<ebroder> Yeah - I think I'm doing this right. I have one package that has "activate $trigger". Another package has "interest $trigger" and does something in the postinst if $1 is "triggered"
<lool> seb128, doko: I don't intend to look at GStreamer patches; would be best if either slomo or one of you would
<ebroder> I should be able to test the trigger with "dpkg-trigger --no-await $trigger", right? Because that returns 0 but doesn't do anything
<ebroder> Both /var/lib/dpkg/info/$package.triggers and /var/lib/dpkg/triggers/$trigger have the correct information
<slomo> lool, seb128, doko_: i can take a look at any patches now... where are they? ;)
<seb128> doko_, lool, slomo: I don't intend to look at gstreamer changes either, we are on sync with debian and that would nice to stay this way
<lool> 13:00 < doko_> lool, seb128: plesae could you apply the two recent pulseaudio  patches seen here  (http://cvs.fedoraproject.org/viewvc/devel/gstreamer-plugins-good/)  afaiu these are taken from upstream.
<lool> slomo: ^
<pitti> asac: do you still think that jaunty-desktop-network-changing is something for jaunty? it's still in 'discussion' state
<slomo> doko_, seb128, lool: yeah, i'll include this two patches in the debian package... i had them already on my list but as another large gst-pulseaudio patch is pending for upstream inclusion (with many bugfixes and some new features) i wanted to wait until that patch is finished too
<seb128> slomo: ok thanks
<lool> slomo: Great
<asac> pitti: not sure. what i am doing is going through the list of apps, verifying their exact behaviour and report bugs/suggest fixes while testing.
<lool> Perhaps a stupid question but why is linux in hardy's NEW for a bunch of arches without actually any NEW package?
<slangasek> well, AFAICS they are new packages, they just aren't correctly labeled as such?
<lool> Oh ok; there's a red NEW aside of NEW packages in other sources
<lool> But not in the linux one
<slangasek> yes, I'm not sure what it is that sometimes confuses soyuz about this
<slangasek> but there aren't currently any lpia 2.6.24-23 packages in -proposed, for instance
<lool> slangasek: Hmm I think there are some
<lool> slangasek: Not quite sure what you mean actually
<lool> slangasek: Do you mean *only* in proposed?
<slangasek> yes
<lool> Ok; I'm fine with the -updates one actually since the latest lum-2.6.24 is still for -23
<slangasek> well, still needs to get processed. :)
<lool> slangasek: Oh since we're on that topic...   ;-)
 * slangasek tweaks the kernel-overrides script a bit more, so it can handle this case of new-but-not-new binaries
<Luke> asac: you around?
<Luke> asac: I have an issue I want to discuss with you before submitting it as a bug
<asac> Luke: go ahead
<Luke> asac: in /etc/hosts our local ip/hostname gets defined
<Luke> asac: this causes problems when on a corporate network where we are assigned our own ip
<Luke> asac: so some software at our company was using some java "get next available port" call which was returning the local IP "hardcoded" in /etc/hosts/ instead of grabbing the real one from ifconfig or whatever is appropriate
<Luke> asac: so i'm wondering what the benefit of the "hardcoded" ip and hostname are vs. just removing it and having it be automatic
<slangasek> Luke: the general solution is to assign your local hostname to 127.0.1.1
<Luke> still... that requires user intervention
<slangasek> instead of to an IP that's associated with a connection that may not always be up
<slangasek> why does it require user intervention?  That's the default in the installer.
<Luke> what's the default in the installer?
<slangasek> to attach your hostname to the 127.0.1.1 IP.
<Luke> right.. which is wrong
<slangasek> um, no
<Luke> ok that isnt helpful. i'll wait for alex
<slangasek> if your java app is assuming that it can *listen* for incoming connections by resolving the hostname and binding to that IP, that's a bug in your java program, frankly
<Luke> good point
<Luke> i'll relay that back
<cjwatson> ebroder: if you want an example of file triggers rather than explicitly-activated triggers, see man-db
<slangasek> i.e., is there a known reason why this app doesn't follow the conventional default behavior of listening on all addresses (by binding to 0.0.0.0)?
<cjwatson> Luke: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/8980/comments/30 describes the constraints we are satisfying right now
<ubottu> Launchpad bug 8980 in network-manager "hostname -f does not return a proper FQDN" [Medium,Confirmed]
<asac> Luke: i think the problem is in the java app as slangasek said.
<Luke> i'm talking to the guy now that wrote it
<Luke> this is why I came to IRC before filing a bug. I never claimed that ubuntu was wrong. I was simply looking for the pros and cons
<cjwatson> 15:44 <Luke> right.. which is wrong
<cjwatson> :-)
<Luke> the ip is wrong
<Luke> not the setup
<cjwatson> which IP?
<Luke> the local vs our network ip
<slangasek> perhaps it's not the IP your app wants, but that doesn't make it "wrong". :)
<Luke> i meant it's not the desired IP of they were looking for
<cjwatson> right
<Luke> exactly
<Luke> thus the overhead of IRC
<Luke> try to deal
<cjwatson> we're dealing fine :)
<slangasek> mathiaz: hi!  I assigned an open-iscsi SRU bug to you because you had done the upload that fixed it in jaunty; if you don't have time for this SRU, please let me know and I'll look for someone else to take it
<mathiaz> slangasek: ok - I'll look at the bug and let you know.
<dholbach> ember: do you know if the libbrasero-media package is used by anything already?
<Luke> cjwatson: thanks for that launchpad btw. that's a perfect description
<cjwatson> Thomas Hood is a good guy
<Luke> cjwatson: hows things going with dell?
<Luke> i think I worked with you when I was at dell
<calc> slangasek: rene just brought up something i hadn't realized
<cjwatson> no major problems I know of
<calc> slangasek: stlport is only enabled on i386 because it needs it to be able to use extensions, so when we disabled it we broke extensions (at least some unknown subset in any case)
<slangasek> calc: yes, I read that mail.  When was stlport disabled?  That doesn't ring a bell
<calc> slangasek: early in jaunty release cycle someone mentioned i forgot to disable it so i disabled it
<calc> slangasek: i believe it had been disabled for intrepid also due to space reasons but we didn't catch the problem with it at that time
<slangasek> ah
<calc> it was enabled in jaunty due to a reworking of the rules file and i didn't notice it was enabled, but now after seeing email from rene it seems it should be enabled for compat reasons
<calc> is stlport small enough to be made to fit somehow?
<ScottK> jcastro: When you moved wiki.ubuntu.com/ContributingToDebian to Debian/ForUbuntuDevelopers there was at least one sub-page that got missed: https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam
<ScottK> jcastro: It seems a bit out of place now, so I was wondering if you'd move that too.
<calc> it appears to only be ~ 200KB
<ScottK> JFTR, I'm not a fan of wiki reorgs and stuff like this is one reason why.
<jcastro> ScottK: sure, I'll do it now, thanks for the headsup
<primes2h> pitti: Do you know where jockey emblems come from in nautilus?
<pitti> primes2h: already fixed in trunk, will upload soon
<primes2h> pitti: Great, now I'm working on gnome-icon-theme to fix some emblems with the untranslatable problem as well, moreover I found out that installing gnome theme you have 32x32 emblems untranslatable as well (they appear in Properties->Emblems right clicking on a folder)
 * calc wonders why debian has a newer version of bzr than ubuntu
<slangasek> ehm... because someone forgot to ask for a post-DIF sync? :)
<calc> well its in experimental in debian but i thought we kept our version up to date
<calc> i guess we can sync to experimental also
<pitti> calc: yes, we can!
<pitti> (*ahem*)
<calc> lol
<DGMurdockIII> hi
<DGMurdockIII> how do i go about getting hardware supported
<DGMurdockIII> how good is bluetooth suport OTB
<calc> DGMurdockIII: best way is to write drivers if they don't exist :)
<calc> thats what i do :)
<DGMurdockIII> there is a linux driver for what i want supported
<DGMurdockIII> i just want it to be added
<calc> ah, probably should talk to the kernel ubuntu-kernel people then if it is part of the kernel anyway
<calc> if it isn't you would need someone to package it
<DGMurdockIII> http://www.bigfootnetworks.com/Support/index.php?_m=downloads&_a=viewdownload&downloaditemid=65&nav=0,2,8
<calc> DGMurdockIII: so find out if it is being added to the kernel since it is gpl or create a package for it if it is not packaged
<DGMurdockIII> the ubuntu kernel or linux kernal
<calc> DGMurdockIII: either
<DGMurdockIII> is there a channel for the linux kernnel
<calc> not public afaik
<calc> iirc linuxnet (or whatever its called) isn't public
<calc> its been a few years since i last logged on though
<calc> there is a linux kernel bugzilla
<DGMurdockIII> where the bugzilla
<cjwatson> DGMurdockIII: did you try googling for "linux kernel bugzilla"?
<DGMurdockIII> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/277749
<ubottu> Launchpad bug 277749 in linux "Killer nic network card not detected" [Undecided,Invalid]
<calc> DGMurdockIII: yes they closed the bug because you never answered their question
<seb128> tkamppeter, pitti: bug #320873 claims an intrepid cups update broke things
<ubottu> Launchpad bug 320873 in cups "CUPS update breaks Evince printing to SMB printer(s)" [Undecided,New] https://launchpad.net/bugs/320873
<pitti> seb128: marked as regression, thanks
<LordMetroid> So I decided to try to write a patch for the bug I previously reported
<LordMetroid> I can't fins the glib source through google... what am I to do?
<LordMetroid> ohh wait a minute, this link seems promising
<cjwatson> LordMetroid: if you really mean glib (a library of useful C routines used by GTK+ among others) then 'apt-get source glib2.0'. If you mean glibc (the GNU C library), then 'apt-get source glibc'.
<LordMetroid> thank you
<LordMetroid> The glib source is totally incomprehensible unless you are acquainted with it... Ohh, well. Maybe I'll get back to this bug patching when I feel more encouraged.
<LordMetroid> I had hoped I could fix the bug sooner rather than later though :(
<dg> any idea when a fix for this might get released: https://bugs.launchpad.net/ubuntu/+source/gitweb/+bug/317052 ?
<ubottu> Launchpad bug 317052 in gitweb "gitweb multiple remote command injections (CVE-2008-5516 CVE-2008-5517)" [Undecided,Confirmed]
<dg> i attached a patch and nominated it for release, not sure what more I'm supposed to do..
<Edico> hello
<Edico> why ubuntu doesn't have default aliases configured for the shell?
<Edico> is should have
<Edico> It's so odd for a linux distribution to came default with desktop effects and without a minimum aliases set!
<maxb> Edico: Desktop effects are a feature. Shell aliases are personal preferences. So no, I don't think it odd.
<directhex> Edico, i think ubuntu should have "sl" installed by default
<maxb> :-)
<Edico> maxb, it should have a default aliases set for user@host colors, when I give few commands with a more output it's hard to see from where becomes a command
<maxb> Edico: You are effectively saying that Ubuntu "should" conform to your personal preferences
<directhex> to be fair, uncommenting force_color_prompt=yes in bashrc is the first thing i do on a new ubuntu install
<Edico> no, I say that it should have set for a easyer output understanding
<maxb> Well, which is easier is a matter of subjective opinion
<Edico> I think the effects are a matter of prefference and aliases set for easier understanding of the output, because it takes much longer time fo find from where it begins the output and the mark is user@host , it should be colored at least the user@host
<LaserJock> I think colors can mess up some apps
<cjwatson> Edico: set it according to your own preferences. (My preferences are no colour in the prompt; it distracts from useful colour-coding in things like ls.)
<cjwatson> Edico: plus prompt colours tend to only work with one of white-on-black and black-on-white; there are many Ubuntu users preferring either one of those
<Edico> cjwatson, let you writed this # uncomment for a colored prompt, if the terminal has the capability; turned
<Edico> # off by default to not distract the user: the focus in a terminal window
<Edico> # should be on the output of commands, not on the prompt
<Edico> #force_color_prompt=yes
<Edico>  ?
<Edico> cjwatson, you should make a poll to see how many people are sharring your way of thinking
<Edico> you would be very surprise
<lfaraone> cjwatson: personally, I'm with EagleScreen
<lfaraone> cjwatson: * Edico
<EagleScreen> sorry, whay are yoy saying about me?
<EagleScreen> I just have entered :)
<maxb> EagleScreen: looks like just auto-completion of nickname gone wrong
<EagleScreen> okay
<cjwatson> Edico: I'm entirely happy with the status quo, and so am not motivated to start a poll about changing it :-)
<maxb> I notice linux-doc hasn't been upgraded when I went intrepid->jaunty, should I be directing my bug at linux-doc or update-manager ?
<maxb> (And has anyone ever managed to figure out exactly when apt will be willing to remove a package?)
<maxb> (as part of an upgrade, I mean)
<cjwatson> Edico: and no, it was not I who wrote the text you quote, although I agree with it. I cannot see the justification for several pages of IRC argument over deleting a single # character from a configuration file, particularly since if you're using a terminal that shouldn't be so big a deal
<cjwatson> desktop effects are a completely different kettle of fish, since we do not want to expect users to edit configuration files to configure their desktop
<cjwatson> but shell users are, on the whole, rather more flexible people
<directhex> i'm inflexible!
 * Spads touches his toes
<Edico> cjwatson, it more easy for an noob linux user to find preference > appearance > visual effects than to find how to configure his shell, and if that user wants to learn linux on ubuntu it would have a difficult task to read the output after some commands with lot of output
<cjwatson> Edico: sorry, I really don't buy that
<cjwatson> pressing enter a few times to space things out if you want to is hardly a big deal, and certainly easier than trying to see the command output when Exciting Colours in the prompt are competing for your attention
<YokoZar> Against what package would a bug in Gnome's save dialog go?
<directhex> gtk
<cjwatson> yeah, that's GtkFileChooserDialog, isn't it? the source package name is gtk+2.0 though
<YokoZar> cjwatson: Yeah...apparently the bug I found was also reported earlier but marked invalid.  https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/230618
<ubottu> Launchpad bug 230618 in gtk+2.0 "no focus on file name in save-as dialog" [Low,Invalid]
<Necrosan> Who maintains sparc64?
<cjwatson> Necrosan: the ubuntu-sparc64 team, in theory, although sparc is no longer a supported architecture and it's not especially active
<cjwatson> https://launchpad.net/~ubuntu-sparc64/+members
<Necrosan> cjwatson: The repos are messed up bad for Intrepid.
<Necrosan> I must be the only person attempting to use X11. :)
<Necrosan> Putting jaunty on to see if the problems are fixed..
<cjwatson> Necrosan: sparc is not all that heavily used. You say that the repositories are messed up, which sounds like there's some structural problem rather than just package bugs; what's the problem exactly?
<Necrosan> cjwatson: if you have a sparc64 system, try installing linux-sparc64-smp
<Necrosan> Unmatched deps like crazy. Also get problems with some Xorg stuff.
<Necrosan> Looks like on jaunty repos the problem doesn't exist.
<maxb> I am purely guessing here, but I suppose the problem is that there wasn't enough developer time among sparc porters to get it sorted in time for intrepid?
<cjwatson> Necrosan: I don't
<cjwatson> though that does not stop me looking at broken dependencies
<Necrosan> ah
<Necrosan> I dunno exactly what the problem is, but figured it would be worthwhile letting someone know.
<gQuigs> who would have to approve a feature? https://wiki.ubuntu.com/Specs/no-input-recovery
<gQuigs> looking for comments and suggestions as well
<Necrosan> cjwatson: xserver-xorg-video-sunffb is broken also
<Necrosan> All the problems seem to stem from virtual packages
<lfaraone> How hard is it to get a package blacklisted?
<cjwatson> blacklisted from what?
<cjwatson> Necrosan: the problem with linux-sparc64-smp is that linux-ubuntu-modules-2.6.25-2-sparc64-smp doesn't exist
<lfaraone> cjwatson: from debian automagic imports. I want a package dropped from the archive, and I think I have a good reason.
<Necrosan> cjwatson: Yep, figured that out.
<Necrosan> cjwatson: Try the sunffb one I referenced.
<cjwatson> and xserver-xorg-video-sunffb is built for the wrong X ABI
<Necrosan> yup.
<cjwatson> lfaraone: file a bug report on the package and subscribe the ubuntu-archive team
<Necrosan> I tried using -ignoreABI, no dice.
<cjwatson> won't help dependencies anyway
<cjwatson> does it work in jaunty?
<Necrosan> Updating now, I'll keep you posted.
<cjwatson> in principle I think we could consider a stable update to make stuff installable
<Necrosan> s/updating/upgrading
<cjwatson> Necrosan: checking it out quickly with chdist
<Necrosan> Awesome, thank you. :)
<Necrosan> It looks like -cgsix and friends are installing, didnt see -sunffb though.
<cjwatson> linux-sparc64-smp is still uninstallable; somebody should file a bug on linux-ports
<cjwatson> xserver-xorg-video-sunffb is still uninstallable
<Necrosan> :/
<Necrosan> What's the problemnow with sunffb? ABI crap still?
<Necrosan> And can I rebuild it manually without building all of X11?
<tjaalton> Necrosan: it needs some work to make it build
<Necrosan> tjaalton: have you done it?
<tjaalton> no
<cjwatson> Necrosan: still the same thing
<Necrosan> cjwatson: It hasn't been updated from the intrepid package?
<Necrosan> I notice -cgsix now will auto install.. wonder how -sunffb slipped through.
<Necrosan> (Does ubuntu even run on sun4ms?)
<cjwatson> Necrosan: the source has been updated, but it failed to build
<tjaalton> -sunffb 1.2.0 might compile
<cjwatson> it didn't last time, https://launchpad.net/ubuntu/+source/xserver-xorg-video-sunffb/1:1.2.0-0ubuntu2
<cjwatson> /bin/sh: ../configure: not found
<Necrosan> I sawsome patches that are ubuntu specific while browsing jaunty stuff
<Necrosan> Heh.
<cjwatson> rather blatantly, too ;-)
<Necrosan> yep, those are the diffs
<tjaalton> oh right
<cjwatson> that at least doesn't look tricky but I have no idea about whether anything else will break
<mathiaz> should file located in /etc/default/ only be used and relied upon by init script?
<cjwatson> Necrosan: it slipped through because it's not something we QA centrally (since it isn't supported)
<cjwatson> so it's dependent on people being motivated to fix it, and we won't delay releases due to it being broken
<Necrosan> cjwatson: Understandable
<mathiaz> or daemons in /usr/{s}bin could also use the content of /etc/default/service?
<cjwatson> mathiaz: I don't think we have a rule on it, but my intuition is that if you want to do the latter you should have the init script read /etc/default/whatever and pass things to the daemon
<cjwatson> if nothing else, that will probably be less code since you can just source the file in the init script rather than having to write configuration file parsing in C
<Necrosan> tjaalton: you're the maintainer for sunffb it looks like?
<tjaalton> Necrosan: not really, just tried to make it build..
<cjwatson> mathiaz: /etc/default/ was created specifically for the use of init scripts, so I'd be wary about using it outside that context
<cjwatson> (see policy 9.3.2)
<Necrosan> tjaalton: Forget to run autoconf? ;l)
<mathiaz> cjwatson: right - but using /etc/default/service_name as the only configuration file for the service is the recommended way of doing things?
<mathiaz> cjwatson: is *not* the recommended way
<mathiaz> cjwatson: ok - thanks for your input.
<tjaalton> Necrosan: don't remember anymore what problems there were, but hopefully debian will have it soon and then we can sync it
<cjwatson> well, look, if the daemon wasn't going to have any configuration file anyway, but is controlled entirely by its command-line options, then it's OK to have the behaviour of the init script in passing those options be controlled by a file in /etc/default/
<Necrosan> cjwatson: just an FYI, aptitude is smart enough to work around the linux-sparc64-smp problem
<Necrosan> tjaalton: ah. i think debian may have it already
<cjwatson> mathiaz: but it is usually not the best idea
<tjaalton> Necrosan: actually they don't
<cjwatson> Necrosan: how on earth can it "work around" an entirely uninstallable dependency?
<cjwatson> Necrosan: that sounds like a bug in aptitude, not a feature :)
<Necrosan> cjwatson: Hehe. It was smart enough to figure all it needed was the image..
<cjwatson> but it's installing a package without all its dependencies satisfied
<cjwatson> it has no right to work that out for itself
<Necrosan> Heh, it suggested I do that.. I did, it worked. :)
<cjwatson> unless it's really getting it from some other repository and you didn't notice
<mneptok> don't mistake "too stupid to relaize that ..." for "so smart it worked around it"  ;)
<cjwatson> Necrosan: well, it's in clear violation of policy
<cjwatson> I know it happens to be convenient in this case
<Necrosan> ah.
<Necrosan> I can see how that could cause problems.
<cjwatson> furthermore, dpkg would normally refuse to configure such a package, unless passed --force-depends, which is generally not a great idea
<Necrosan> IIRC, I just ran "sudo aptitude install linux-sparc64-smp"
<Necrosan> and it "figured" it all out
<Necrosan> apt-get wouldn't do it.
<cjwatson> are you sure that you don't have some other stuff in sources.list, other than the main archive?
<Necrosan> main, universe restricted and multiverse
<cjwatson> I didn't mean main in that sense. Nothing other than deb http://ports.ubuntu.com/ubuntu-ports intrepid main ...?
<Necrosan> backports, proposed and security
<Necrosan> and updates.
<cjwatson> none of which change linux-sparc64-smp or its dependencies
<Necrosan> yeah
<cjwatson> if you still have a transcript of what it did, please file a bug on aptitude
<Necrosan> I just put intrepid on it a fewhours ago.
<Necrosan> I will be re-running it again when jaunty finishes
<Necrosan> I'll post a bug then..
<mneptok> !info linux-sparc64-smp
<ubottu> Package linux-sparc64-smp does not exist in intrepid
<mneptok> ^^^^
<cjwatson> it might have worked here, but other packages would have broken later
<cjwatson> mneptok: the bot is buggy
<cjwatson> linux-sparc64-smp | 2.6.25.2.3 |      intrepid | sparc
<cjwatson> sayeth the master archive
<cjwatson> mneptok: perhaps the bot does not look at ports architectures
<mneptok> cjwatson: yeah, but in this case it backs up our claim, so i'll choose to believe it. :P
<cjwatson> the package is available, just uninstallable
<cjwatson> anyway, off ...
<kirkland> rtg: pgraner: fyi, guys, i uploaded an ecryptfs-utils to jaunty earlier today that adds the userspace support for filename encryption
<joe-mac> is it considered a bug if .sudo_as_admin_successful isn't rm'd by bash logout when you end a session?
<joe-mac> IMO the /etc/skel's bash log out should test -e for the file and rm it
<andersk> No, .sudo_as_admin_successful is supposed to stay there so you don't get the annoying message telling you how to use sudo every time you open a terminal.
<Necrosan> I love that message! :)
<soren> joe-mac: That would sort of defeat the purpose of having the file to begin with, wouldn't it?
<joe-mac> so andersk
<joe-mac> i log out out a system, but someone somehow gets access to my account, then they can sudo -i without a pass?
<joe-mac> a session's credentials should not stay if you log out, period
<joe-mac> i'll just add it to my skel, just wanted to make sure you guys didn't think it was a bug, thanks
<Necrosan> joe-mac: uh
<Necrosan> you don't know how sudo functions apparently..that file does NOT enable passwordless sudo
<andersk> Right.  .sudo_as_admin_successful does not have any effect on anything other than that message.
<kash> so this networkmanager + wpa-enterprise thing, what's the hold-up?
<kash> bug 263963
<ubottu> Launchpad bug 263963 in linux "[iwl*] intel drivers take overly long to associate to WPA for some hardware" [High,Confirmed] https://launchpad.net/bugs/263963
<joe-mac> Necrosan: then school me
<Necrosan> joe-mac: not sure how ubuntu does it, but on openbsd its a random interval of 5-10 minutes after the last use it will ask for a password.
<Necrosan> I'm sure it's configurable.
<Necrosan> Logging out SHOULD reset it by default
<joe-mac> Necrosan: yes and if i log out of a session, and go back in, the sudo as admin is still there, and i can sudo -i
<joe-mac> ok, and i agree, but it doesn't. it's not huge, but still a risk
<Necrosan> joe-mac: That file has nothing to do with sudo other than showing youamessage.
<Necrosan> joe-mac: The interval must stick after logout, probably as a feature.
<Necrosan> I think it even works like that on openbsd
<Necrosan> check out /var/run/sudo
<andersk> By default, your sudo credentials are tied to a particular username and tty with a 15 minute timeout.  You can explicitly invalidate them with `sudo -k`.  The .sudo_as_admin_successful file is irrelevant.
<Necrosan> there you go.
<andersk> If you want sudo to always prompt you, you can set timestamp_timeout=0 in /etc/sudoers (man sudoers).
<Necrosan> Or he could throw sudo -K/k in his profile
<joe-mac> ah ok, i figured that a pam module used that file or something, never looked into it, thanks
<joe-mac> it's not so much i want sudo to always prompt me, in fact that's super annoying, i just think it shouldn't persist after logging out, but i am not the supreme overlord or anything so
<Necrosan> joe-mac: add sudo -k to your profile, it will always prompt you then after a logout.
<joe-mac> yea, going to push it out to our skel folder, thanks Necrosan!
<soren> Necrosan: That's a horrible way to "fix" that.
<joe-mac> well it's not like a huge gaping hole
<joe-mac> someone would have to get back into the same tty
<Necrosan> soren: How would you do it,then?
<joe-mac> like if you walked away from your box after re logging in or something
<soren> Necrosan: I wouldn't.
<soren> Necrosan: Probably.
<Necrosan> soren: you talking about sudo or sparc crap?
<soren> Necrosan: If I would, I'd tie it to logging *out*, not *in.
<joe-mac> that's what he saidm, didn't he?
<Necrosan> soren: Either way will work..
<joe-mac> well, i assumed he meant bash_logout
<Necrosan> Logout would be better.
<soren> Necrosan: Erm.. No. Doing it on login only makes it more difficult for well-behaved logins.
<soren> Doing it on logout actually does something to increase security.
<soren> It makes sure that once you log out, the credentials tied to your login on the given tty are cleared.
<Necrosan> Yes, agreed.
<Necrosan> But putting it in .profile won't hurt anything, unless the shell getschanged to something that doesn't source the profile
<soren> Doing it on login only ensures that if they're still there when you log in properly, using your proper .bashrc, etc. etc., it's cleared.
<Necrosan> (which would req. root/sudo access anyway)
<soren> Or someone grabs a pty in some other way.
<Necrosan> I suppose.
<joe-mac> yea i can't immediately think of  an exact attack vector besides walking up to a tty that you walk away from after you've just logged back in, like "o crap i forgot something at my desk", but the risk however slight still remains
<soren> Or if the malicious user from another terminal just removes that bit from the .profile before he fires up terminals until he hits the same pty.
<Necrosan> soren: How is that possible without access to the file?
<soren> ...but in that case you're rather screwed anyway. (Malicious user with physical access to the machine)
<Necrosan> yeah
<soren> Necrosan: Why wouldn't he have access to the file?
<Necrosan> soren: I didn't think you were insinuating he left something with his username logged in on another tty.
<soren> Necrosan: It's apparantly given that said user can somehow log in as you, and thus gain your previously granted sudo-without-password privileges.
<soren> Necrosan: That's the presumed attack vector, correct?
<Necrosan> soren: You'd have to be pretty careless to get done like that.
<Necrosan> soren: Yes.
<soren> Necrosan: Good.
<kees> i tried to convince kernel upstream to put consoles into /sys so udev could wipe sudo tickets when a tty closed. didn't go so well
<joe-mac> no
<soren> If he can do something like that at will, why couldn't he just use the first couple of attempts to clear out these "sudo -k" things from .bash_* ?
<joe-mac> this is how it would go
<Necrosan> soren: I agree, in theory. But more than likely, if he's logging out he'll be sure to close all other ttys.
<Necrosan> Especially if he's concerned about sudo's default behavior.
<soren> Necrosan: Who says he's logging out?
<lamont> why do I hate it so much when an upstream makefile does >/dev/null 2>&1 ?
<Necrosan> soren: He did.
<Necrosan> To sum it up, I agree, it is much safer to put it in logout script
<joe-mac> you log in you're the admin in a server room, WAHHHH the loud fans everywhere make it so you don't hear the ninja-like attacker hanging out in the corner. you go to take a piss and you remember to log out before doing so, but curiously enough you leave your phone on the sink in teh bathroom but you don't realize til you log back in. you say crap and go away without logging out this time. the ninja emerges, has enough time to sudo -i o
<Necrosan> Them ninjas are shady.
<soren> If there's ninja's in your server room, you've got much bigger problems than stale sudo tickets.
<Necrosan> haha
<soren> Seriously.
<joe-mac> well, i specifically don't haev to worry abotu ninjas because i am a ninja-viking-pirate hybrid, but most admins aren't, so i worry about them.
<joe-mac> i can actually see a very similar situation happening in a data center i've been in where it really is obscenely loud, large, and the distance from the bathroom to the data center is pretty long
<soren> kees: Why didn't they like it?
<kees> felt it was too much overhead
 * kees thinks the world needs more ninja-viking-pirate hybrid sysadmins
<soren> kees: Hm... udev has rules for pty's? They never trigger, though, but they're there. That seems rather odd.
<kees> soren: yeah, dunno. i didn't have the intestinal fortitude to dig into it :P
<directhex> poke poke
<kash> superpoke
<directhex> i still need to hear a decision on dh7.1
<directhex> i suppose that means cjwatson
 * Laney pokes too
<directhex> with your pokes combined, i am captain pokings!
<directhex> captain pokings, he's our hero, gonna poke core-devs down to zero!
<directhex> he's our pokings, magnified
<Necrosan> heh
<directhex> and he's fighting on young meebey's side!
<directhex> and that's as much of THAT piece of my youth as i remember
<directhex> or care to admit to remembering
<Necrosan> I never liked the "heart" guy
<Necrosan> "heart" is not an element.
<directhex> there were only limited ways to fit all the token ethnicities
<kirkland> bryce: is the nvidia-glx graphics drivers known to work in jaunty?  i haven't managed much success to this point
<kirkland> s/is the/are the/
<bryce> kirkland: I believe they work if you use the IgnoreABI option
<bryce> we should be getting ABI-compliant versions of some/all the -nvidia drivers soonish (matter of weeks maybe)
<directhex> bryce, oh? this is from the horse's mouth?
<kirkland> bryce: where does that go?  what's the syntax?
<kirkland> bryce: i mean, what section of xorg.conf?
<TheMuso> doko_: no idea at this point, 0.9.14 was a bugfix release.
<bryce> kirkland, actually -ignoreABI is an X flag, not an xorg.conf option
<kirkland> bryce: ah, startx -- -ignoreABI ?
<johanbr> It also works if you stick it in the ServerFlags section in xorg.conf
<bryce> kirkland: yep, or in the appropriate gdm conf file
<bryce> johanbr: aha ok
<tseliot> yep, ServerFlags should be ok
<TheMuso> doko_: and unfortunately I haven't quite been able to work out the C function equivalents with the symbol references in that error.
<bryce>        Option "IgnoreABI" "boolean"
<bryce>               Allow  modules  built for a different, potentially incompatible version of the X server to load. Dis-
<bryce>               abled by default.
<bryce> yep you're right
<TheMuso> doko_: I think I've worked out one of them, but not the other.
<TheMuso> doko_: And there has been no change to that function from 13 to 14 releases of pulseaudio.
<Riddell> tkamppeter: there is code in system-config-printer's applet for authentication, how do I set the print server to need authentication?
<kirkland> bryce: hmm, still not having any success here
<bryce> tseliot: ideas?
<tkamppeter> Riddell, you have to edit cupsd.conf setting The AuthType of a resource (ex: <location /printers/myqueue>) to "Basic". See the documentation on localhost:631 about cupsd.conf.
<tseliot> kirkland: what driver did you install?
<tseliot> kirkland: 180? 177?
<kirkland> tseliot: i'm trying 180 now
<tseliot> kirkland: install 180 and reboot
<tseliot> I don't know why but sometimes IgnoreABI doesn't seem to work if I change driver unless I reboot
<tseliot> kirkland: let me know if you still have problems with the driver
<kirkland> tseliot: okay, so i need apt-get install --reinstall nvidia-glx-180 ?
<tseliot> apt-get install --reinstall nvidia-glx-180 nvidia-180-kernel-source
<tseliot> and reboot
<tseliot> kirkland: also make sure that DefaultDepth is set to 24 in your xorg.conf
<kirkland> tseliot: hmm, interesting, i don't have nvidia-180-kernel-source installed ... is that perhaps missing as a dependency?>
<kirkland> tseliot: i have the -96-kernel-source installed
<tseliot> kirkland: Depends: nvidia-180-kernel-source (>= 180.22)
<tseliot> remove -96
<kirkland> tseliot: removing nvidia-glx-96 is throwing dpkg-divert errors
<kirkland> tseliot: missing /usr/lib/xorg/modules/extensions/libGLcore.so
<tseliot> kirkland:  can you file a bug report about it, please?
<kirkland> tseliot: you bet, thanks.
<tseliot> good
<kirkland> tseliot: how can i easily just use the vesa driver in the mean time?
<tseliot> simply set the driver to "vesa" in the Device section of you xorg.conf
<kirkland> tseliot: right, even that's failing for me
<tseliot> kirkland: is xserver-xorg-core installed?
<kirkland> tseliot: hmm, no, it's been removed
<tseliot> kirkland: yes, because the other nvidia driver conflict with the new xorg abi
<kirkland> tseliot: not by me, consciously, i might add
<kirkland> tseliot: okay, so i need to remove some stuff?
<kirkland> tseliot: or has the nv driver gotten any better?
<kirkland> tseliot: can i just use that one?
<tseliot> simply install xserver-xorg-core
<tseliot> and you'll be able to use nvidia -180
<kirkland> k
<kirkland> oh
<tseliot> or nv or whatever you prefer
<kirkland> okay
<Necrosan> Yep, aptitude still doing the same thing in Jaunty/sparc64, cjwatson
<maxb> Anyone else seeing update-manager disinclined to install a lot of libx11 / libxcb updates?
<Turl> just found 2 broken packages,   libx11-6 and libxcb-xlib0-dev
<Turl> can you look into them?
 * ScottK is gonna guess that bryce already knows all about it.
<bryce> hadn't heard that
<bryce> link me?
<maxb> I don't think it's broken packages, per se. Just lacking whatever Replaces: magic is needed to convince apt that it's alright to remove the libxcb-xlib ones which have gone away
<Turl> libxcb-xlib0-dev: Depende: libxcb-xlib0 (= 1.1-1.1) pero no es instalable
<Turl>   libx11-6: Depende: libxcb-xlib0 pero no es instalable
<Turl> pero no es instalable=but it's not installable, depende=depends
<Turl> then, there are packages missing replaces magic, as maxb said
 * maxb wonders why a "Partial upgrade" thinks it should remove powermanagement-interface along with the two xcb-xlib packages
<Necrosan> looks like ports.* is down
<Necrosan> back
<Necrosan> What package do I need to compile X drivers? Getting the RANDR error, not sure what its called in jaunty.
<dtchen> Turl: why would it need a Replaces?
<Necrosan> ah, xorg-dev.
<dtchen> slangasek: thanks for clarifying the ia32-libs mess =)
<YokoZar> dtchen: so, are you gonna find me some magic multi-arch implementing developers?
<dtchen> YokoZar: in what context?
<dtchen> Turl: AFAICT, libxcb1 does the right thing in its Conflicts
<Turl> dtchen: because other packages depend on it? if you don't add the replaces, you should make the other packages depend on the new lib
<YokoZar> dtchen: so we can get rid of ia32-libs the proper way ;)  Reading the mailing list it seems at least 3 grad students have written papers about how wonderful and proper a good multi-arch implementation would be, but no one's actually written enough code we can use
<dtchen> Turl: the latter must happen regardless
<Turl> dtchen: then I'll have to wait I guess
<maxb> update-manager baffles me. It's computing a dist-upgrade that involves removing a random extra package for no sane reason, compared with 'apt-get dist-upgrade'
<ScottK> In general it should have reasons.
<ScottK> It has a lot of special cases.
<ScottK> It may be a reason you don't know about.
<dtchen> FWIW, i didn't experience any odd things with aptitude upgrade just a few moments ago using us.archive.u.c
<maxb> I experienced the oddity on only one machine of two, which have generally been upgraded in-sync :-/
<cjwatson> directhex: remind me tomorrow?
<StevenK> slangasek: If you're still around, can you review ubuntu-netbook-remix-default-settings in the source NEW queue?
<maxb> Oh, nifty. It was an update-manager quirk added in the small window between me jauntifying one machine and jauntifying the other, then taking effect at the next dist-upgrade that occurred.
<directhex> cjwatson, will do
 * directhex battles the last mono 2.0 transition app
<calc> shouldn't launchpad-integration binary spwan firefox and return to the command line?
<calc> if firefox isn't already running launchpad-integration does not return
<ScottK> calc: launchpad integration isn't just used by Firefox.
<alex-weej> i did some translations of nautilus' en_GB to use proper UTF-8 quotes
<alex-weej> how long does it take to review stuff like this?
<alex-weej> (did it like 2 weeks ago i think)
<alex-weej> and how does the work filter back upstream?
<Necrosan> ffb_driver.c:117: error: âPACKAGE_VERSION_MAJORâ undeclared here (not in a function)
<Necrosan> woohoo. Any ideas anyone?
<ScottK> alex-weej: AFAICT, it's "whenever reviewers get around to it" and "it doesn't".  I
<ScottK> I'm not an expert about translations, but that's my impression.
<Necrosan> got it. xutils-dev
<alex-weej> hm. damnit.
<alex-weej> it's so easy to translate with launchpad
<Necrosan> Maybe not. Crap.
<Necrosan> Any ideas, anyone?
<alex-weej> well actually i could have saved myself a lot of time by using find/replace in gedit
<alex-weej> but nm
<bryce> Necrosan: what are you having trouble with in X-land?
<Necrosan> bryce: sunffb
<bryce> hum sun
<Necrosan> apparently i can define the crap in file, but xutil-dev should include the macros to properly adjust it..
<Necrosan> hm
<Necrosan> got it,needed autogen re ran
<Riddell> kees: what happened to your quassel review?  bug 317892
<ubottu> Launchpad bug 317892 in quassel "Quassel main inclusion report" [Undecided,In progress] https://launchpad.net/bugs/317892
#ubuntu-devel 2009-01-27
<kees> Riddell: still pending
<kees> Riddell: I'm working on kernel and openjdk updates at the moment
<calc> ScottK: no i mean the fact that it launches a browser but does not return
<calc> ScottK: and since firefox when launched does not return it keeps launchpad-integration running iff firefox isn't running already
<ScottK> I see.
<calc> ScottK: i'm talking about the launchpad-integration binary not library interface
<ScottK> Yes.
<ScottK> Our KDE packages use it too.
<Necrosan> lessee if it works.
 * calc kicks ATT
<calc> too much packet loss for me to reach lp
 * calc sees if he can leech off someone else's wifi for a few min
<Necrosan> great,now X is crashing.
<bryce> Necrosan: progress ;-)
<StevenK> bryce: Are you around?
<bryce> StevenK: yes
<StevenK> bryce: So, do you know libx11-dev is broken? :-)
<bryce> nope; bug #?
<StevenK> bryce: libx11-dev Depends on libxcb-xlib0-dev, libx11-6 Depends on libxcb1, libxcb-xlib0-dev pulls in libxcb-xlib0 and libxcb1 and libxcb-xlib0 Conflict
<bryce> StevenK: hmm let me look
<slangasek> dtchen: sure - I would've had the bug fixed by now, too, if it weren't for the fact that ia32-libs is such a seeping horror that requires every single lib it builds against to be in sync before you can upload...
<Turl> can anyone help me? I installed realvnc but it doesn't include Xvnc, needed to run it
<Turl> sorry, wrong channel :p
<Turl> this should go in #gentoo
<bryce> hmm, according to the libx11 control file, libx11-dev depends on libxcb1-dev.  Where does libxcb-xlib0-dev come from?
<StevenK> bryce: apt-cache show in my jaunty chroot says libxcb-xlib0-dev
<slangasek> StevenK: mm, not sure that I'll have a chance to get to that today, we'll see
<StevenK> bryce: Double checking
<bryce> StevenK: ok this may be beyond my packaging-fu but it looks like the *old* libx11-dev depended on libxcb-xlib0-dev (up to libx11-1.1.5), but the new one does not have that dependency any longer
<bryce> presumably something should be added to clue apt in of the change?
<StevenK> bryce: Mmmm. I just updated against archive.u.c, so looks like libx11-6 and libx11-dev are out of sync on my mirror
 * StevenK kicks his mirror and tells it to update
<bryce> aha
<slangasek> right, libx11 was just uploaded today
<slangasek> it was dep-wait on libxcb which was dep-wait on xcb-proto; I fixed that so I could upload ia32-libs :P
<bryce> slangasek: ahaaa
<StevenK> Ahhh
<directhex> ahhhhhhhhh
<directhex> sorry, i felt left out
<slangasek> ahhhh the atmosphere
<slangasek> hah, there we go, after I kill the reference to libxcb-xlib0 in ia32-libs, it finally builds :P
<Necrosan> tjaalton: sunffb still crashes even with that patch applied.
<Necrosan> Oh boy.
<mib_zo2qpbqm> Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai
<mib_zo2qpbqm> Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai
<mib_zo2qpbqm> Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai
<mib_zo2qpbqm> Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai
<mib_zo2qpbqm> Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai
<slangasek> !ops mib_zo2qpbqm
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Hobbsee> sigh.
<directhex> yay for Hobbsee
<ajmitch> ah, mibbit
<Necrosan> http://pastebin.com/m638bda5d
<slangasek> hrm, is that not the right command?
<Necrosan> Any ideas on that crash?
 * directhex offers Hobbsee some cake
<Hobbsee> slangasek: you want !ops, or !ops | foo
<slangasek> ah
<Hobbsee> directhex: thanks!
<slangasek> thx
<Hobbsee> slangasek: if it's obvious, just go for !ops
<cody-somerville> How long does it take a build to publish?
<cody-somerville> (primary archive)
<cody-somerville> It finished building 38 minutes ago
<Keybuk> just past the top of the next hour
<Keybuk> plus ~1 hour for publishing
<Keybuk> if it finished 38 minutes ago, it will be in the next publishing run, so another hour and a bit to go at least
<cody-somerville> ...
 * Keybuk takes away cody-somerville's sugar
 * slangasek injects the sugar into his own eyeballs
<Keybuk> slangasek: oh?
<slangasek> wanna try?
<Keybuk> no, I don't think it would do them any good :p
<slangasek> oh, ok
<slangasek> dtchen: there we go, ia32-libs all fixored
<mathiaz> slangasek: about bug 321689 - it seems that some packages from -proposed have been included in 8.04.2 -server isos.
<ubottu> Launchpad bug 321689 in openldap "openldap (slapd) installation fails" [Undecided,Confirmed] https://launchpad.net/bugs/321689
<stdin> and the alternate ISOs
<ebroder> Can someone accept the Hardy backport of remctl 2.13-2?
<ebroder> (Intrepid would be cool as well, but I'm not using Intrepid right now, so I care less :-P)
<Hobbsee> ebroder: accepted.
<ebroder> Thanks
 * NCommander debates if he wants to just buy a time capsule or similar NAS, or roll my own ...
<TheMuso> 6/c
<TheMuso> NCommander: roll your own. :p
<NCommander> TheMuso, any recommands on how to do it?
<TheMuso> NCommander: nope :p
 * NCommander falls over
<ebroder> Time Capsules don't suck, for the record
<TheMuso> ebroder: They probably would if one couldn't access them with Linux.
<ebroder> TheMuso: That's fair. I still don't use Linux for desktop systems, though :)
 * TheMuso pats his file server. More extendable than any time capsuel, and can currently store 2.5 times more data than the biggest time capsuel without any additional HDs connected.
 * TheMuso is assuming that the biggest time capsuel is 1TB.
<ebroder> That's right
<TheMuso> Oh and no redundancy. I'm using Linux s/w raid here as well.
<ebroder> Yeah, yeah - I could spend a few hours making something more awesome, but I decided it was worth the convenience to never have to think about it again
 * TheMuso nods.
<YokoZar> Is there a discrete file that refers to the current user's home folder?  I'd like to symlink to it without using environment variables.
<StevenK> ~ will probably get expanded by the shell
<StevenK> YokoZar: But symlinks don't get resolved, it's a static link
<YokoZar> StevenK: Hmm, how do I make a link to "~" then without just making a link to whatever user is typing ln -s ~
<persia> YokoZar, From where are you symlinking?
<calc> did freenode just explode?
 * calc had thought it was just his crappy dsl until he saw how many joins there are
<Hobbsee> calc: clarke did, at least, yes.
<stdin> several times it seems
<calc> at&t is coming out tomorrow to fix my line, heh
<Hobbsee> hrm, now connecting from amsterdam.  OK then.
<dholbach> good morning
<slangasek> mathiaz: hrm, investigating
<slangasek> mathiaz: sigh, not good :(
<tjaalton> Necrosan: file a bug with the log attached
<ebroder> I just found a regression in a package I got backported. What's the right process here?
<ebroder> remctl-server 2.13-2 in depends on netbase >= 4.31, but Hardy only has 4.30ubuntu1
<ebroder> The change is significant - 4.31 added a new line to /etc/services
<Hobbsee> jdong: oh, crackporter....
<ScottK> ebroder: Didn't you say you'd tested this before it was approved?
 * ebroder sighs
<ebroder> I tested the client
<ebroder> ...and also the new python-remctl package, because I knew how to use that one
 * ScottK headdesk.
<ebroder> Yeah...I know
<dholbach> bug 308800
<ubottu> Launchpad bug 308800 in intrepid-backports "Please backport remctl 2.13-2 from Jaunty to Hardy and Intrepid" [Wishlist,Fix released] https://launchpad.net/bugs/308800
 * ScottK sighs.
<Zetto> Someone can include Bug #251173 in the milestone of jaunty-alpha-5 ?
<ubottu> Launchpad bug 251173 in netbeans-ide "Update NetBeans to 6.5" [Undecided,Confirmed] https://launchpad.net/bugs/251173
<ScottK> ebroder: The process is file a new bug against hardy backport explaining the problem (please subscribe me to it).
<Hobbsee> Zetto: no.  and it didn't need to go across 3 channels either, btw.
<ebroder> ScottK: Ok. I'll do so, and include the fix. I'm really sorry
<Zetto> Hobbsee, ok
<ScottK> ebroder: Then see if you can figure the best solution.
<ScottK> ebroder: OK.  That's good.
<ScottK> ebroder: I don't feel so bad about mistakes as long as you clean up after yourself.
<ScottK> In the meantime, it's nearly 2AM here, so I'm going to bed.
 * ScottK will consider what to do in the morning.
<ebroder> I'm pretty sure I can do the fix in 2 lines
<ScottK> Great.
<YokoZar> An Intrepid Ibex: http://img.waffleimages.com/b44642ef0d1f06ead5848f4a7a844773a369702c/00035152.jpg
<Amaranth> YokoZar: hahahaha
<Amaranth> funniest thing I've seen all day :)
<iulian> Heh
<pitti> Good morning
<StevenK> Morning pitti!
<Hobbsee> hey there pitti!
<RAOF> Howdie all!
 * pitti waves to Australia
<pitti> sorry, -EHEMISPHERE
 * pitti ÉÄ±×ÉÉ¹ÊsnÉ oÊ sÇÊÉÊ
 * RAOF wonders idly how that works.
<persia> The magic of unicode.
 * Hobbsee gets boxes, and is sad.
<RAOF> Why does unicode appear to have RTL, upside down, latin?
<slangasek> it appears to have it because it does in fact have it
<StevenK> Hm, works for me
<persia> Actually, some letters are supported poorly: it's just people looking through the available glyphs, and picking some that looked right.  Lots of them are math symbols, etc.
<RAOF> I mean: Why does unicode have RTL, upside down, latin?
<RAOF> Also, who'd like to make f-spot installable again in half an hour or so?
<StevenK> pitti: Could I monopolise some of your time to NEW two things today?
<StevenK> pitti: I uploaded both of them, so I can't do it. ubuntu-netbook-remix-default-settings, which is tiny, and desktop-switcher
<pitti> StevenK: ah, uploaded those yourself? sure
<pitti> StevenK: u-n-r-d -> main or universe?
<pitti> StevenK: u-n-r-d does not have a COPYING
<pitti> StevenK: please fix the short description of desktop-switcher
<soren> How long does it take for stuff to go through source NEW these days? I see there's a bit of a queue.
<slangasek> RAOF: "latin small letter turned r/t/a/e" are all used in phonetics
<pitti> StevenK: desktop-switcher needs to build a .pot during package build (intltool-update -p --verbose)
<soren> Ah, it seems the oldest stuff in there is from the 23rd, so not too long, I guess :)
<RAOF> slangasek: Oh, of course.
<pitti> StevenK: d-s accepted, u-n-r-d rejected due to missing COPYING
<dholbach> HAHAHAHAHA :-)
<dholbach> https://launchpad.net/~sorens-target-audience
<dholbach> https://launchpad.net/~we-love-pitti
<dholbach> https://launchpad.net/~dholbach-huggers
<dholbach> looks like we have a bunch of fanclubs already
<pitti> lol
<ion_> :-)
<pitti> what would we do without Launchpad?
<ion_> pitti: Thereâs a better rotated i: á´
<pitti> ion_: tell that to the guys at http://www.sevenwires.com/play/UpsideDownLetters.html :)
<StevenK> pitti: Right, I'll fix up desktop-switcher
<StevenK> pitti: u-n-r-d-s re-uploaded as 0.1
<StevenK> pitti: u-n-r-d-s is fine as universe
<mvo> u-n-r-d-s? that sounds like a long name :)
<StevenK> ubuntu-netbook-remix-default-settings
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, s-c-p needs a new Python library, see bug 321785, should I simply upload it (going into Universe NEW) or should I upload it into REVU?
<ubottu> Launchpad bug 321785 in ubuntu "pysmbc library needed for system-config-printer to support browsing for SMB printer shares" [Medium,In progress] https://launchpad.net/bugs/321785
<tkamppeter> pitti, it is a simple package like python-cups and it is also from Tim Waugh.
<StevenK> pitti: http://paste.ubuntu.com/110194/ for proposed changes to desktop-switcher
<pitti> tkamppeter: if it's lintian clean, and you are reasonably sure about the packaging, just upload it; if you have some doubts and would like to get feedback, use REVU
<pitti> StevenK: s/Allows the user to// IMHO, but the intltool stuff looks fine
<StevenK> pitti: Hmmm, yeah
<StevenK> "allows the user" is a little redudant :-)
<slangasek> tjaalton: do you have any further insights into bug #270259, given that it failed SRU verification?
<ubottu> Launchpad bug 270259 in acpid "Leaks file descriptors and eventually runs out" [Medium,Fix released] https://launchpad.net/bugs/270259
<tkamppeter> pitti, thanks. It is Lintian-clean (both source and binary) and it works (I can browse for SMB shares with s-c-p), so I will upload it.
<tjaalton> slangasek: no.. but it hasn't caused problems here anymore (running on ~300 desktops)
<tjaalton> so it definately fixed _something_
<slangasek> tjaalton: do you know what the python test program is that Paul refers to?
<slangasek> oh, probably the one in the bug description
<tjaalton> yes
<tjaalton> haven't tried it myself
<slangasek> I can reproduce the problem using that script, even on jaunty
<tkamppeter> pitti, package is uploaded now, its name is python-smbc.
<tjaalton> maybe the rate of leaks is now smaller, but still not fully fixed
<StevenK> slangasek: Also reproduced in Intrepid.
<StevenK> tjaalton: It doesn't seem to be smaller.
<StevenK> tjaalton: I just connected eight times and closed the socket, and acpid has another 8 FDs open
<tjaalton> StevenK: ok, but we haven't had any "/var full" incidents since the update (on our local repo)
<StevenK>  /var full is a side-effect, not the cause
<tjaalton> of course
<tjaalton> caused by the logfile bombing
<StevenK> So it's pointless to declare that since /var hasn't filled up, it's fixed the problem.
<tjaalton> well it's certainly better for us
<tjaalton> I would've seen that many times during these couple of months
<StevenK> slangasek: Should we slam that bug back to Confirmed and open a task for Intrepid?
<slangasek> AFAICS, the rate of leaks is still one socket per socket - so the leak doesn't look slower to me...
<slangasek> StevenK: I wouldn't bother with a separate intrepid task at this point, let's worry about jaunty and hardy first
<slangasek> ah - I see, the patch only causes acpid to notice the closed socket when it tries to write to it and gets an EPIPE
<slangasek> so if there are no ACPI events happening, the sockets stay open :)
 * slangasek generates an ACPI event and sees the socket close
<StevenK> How does one generate an ACPI event?
<slangasek> StevenK: I closed my laptop lid. <shrug> :)
<StevenK> Hmm. My desktop doesn't have a laptop lid :-)
<StevenK> Meh. It's not like 8-10 open FDs is going to kill anything
<pitti> seb128: ah, I found out why consolidating is so slow; there are tons of bugs which do not have the 'apport-retrace' tag any more
<seb128> pitti: how come?
<pitti> if only I'd know
 * pitti retags them
<pitti> seb128: I added logging for that case yesterday
<seb128> pitti: it seems the retracer just don't add this tag by looking at the recent emails I got
<pitti> seb128: the retracer isn't supposed to
<seb128> pitti: what is supposed to?
<pitti> seb128: when filing the bug it should already be there
<seb128> pitti: need-arch-retracing is there when filling the bug
<seb128> and apport-crash
<pitti> seb128: right, and the apport-crash tag is set with the very same call
<seb128> pitti: you said apport-retrace before though?
<pitti> many of those are very old bugs, though (1xxxxx)
<seb128> pitti: wasn't that supposed to be set on succeful retracing?
<pitti> maybe the triagers just removed the tag
<pitti> seb128: sorry, 'apport-crash' I mean
<seb128> I doubt of that
<seb128> do you have desktopish bug number?
<pitti> http://pastebin.com/f2806928a
<seb128> urg
<pitti> I'll fix them once for now
<pitti> and then observe when it happens again
<pitti> 1.500 bugs point towards a system problem, not to triagers removing it
<pitti> seb128: no wonder that it takes 2:40 hours with that long list..
<seb128> pitti: did you fix those already?
<pitti> seb128: it's currently running, from the top
<pitti> but tagging 1600 bugs will also take that long, I expect 2:30 hours
<seb128> pitti: weird, bug #315307 is tagged but at the bottom of our list
<ubottu> Launchpad bug 315307 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in gnome_rr_config_match() (dup-of: 314406)" [Medium,Invalid] https://launchpad.net/bugs/315307
<ubottu> Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Fix released] https://launchpad.net/bugs/314406
<seb128> pitti: that's a duplicate though
<pitti> oh, hang on
<seb128> pitti: do you handle duplicates incorrectly?
<seb128> our list -> your list
<pitti> seb128: right, I assume some/many of those are duplicates
<pitti> however, yesterday I found three bugs which weren't, but didn't have an apport-crash tag
<seb128> pitti: maybe those were manual untagging
<pitti> so it seems I need to clean up the dup db and throw out the bugs which were marked as dupe
<seb128> I though using duplicates was useful
<seb128> sometimes the duplicates have a different or better stacktrace and it's useful to have this one is the database
<pitti> yes, but not as master bug
<seb128> right
<pitti> right, but then I should update the master bug number
<seb128> right
<pitti> since the dupes won't appear on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-crash
<pitti> which is what I am using to find out all non-fixed bugs
<pitti> ok, gives me something to work on
<pitti> but first, sponsoring o'clock
<seb128> brb, restarting session
<StevenK> pitti: Oh, the other thing to please check for me is human-netbook-theme.
<slangasek> tjaalton: looking at the acpid source makes me sad :(
<tjaalton> slangasek: I can understand..
<slangasek> especially the part where they give each client an associated regexp of .* and then do regexp matching to decide whether to pass the event to the client
<tjaalton> uh :)
<slangasek> tjaalton: btw, do you know why libxcb1 declares a Conflicts: on libxcb-xlib0?  I don't see any filesystem-level overlapping
<slangasek> the Conflicts: without a Replaces: causes libx11-6 and libxcb1 to be held back on upgrades
<asac> ArneGoetje: 214519 ... is there anything in the pipeline for that dictionary or shall i just sponsor?
<tjaalton> slangasek: hmm, no I don't.. I'll ask jcristau
<ogra> Keybuk, !!
<ogra> Keybuk, http://launchpadlibrarian.net/21658731/buildlog_ubuntu-jaunty-armel.openjdk-6_6b14-0ubuntu10_FAILEDTOBUILD.txt.gz why does udev fail here ?
<ogra> cat: /sys/kernel/uevent_seqnum: No such file or directory
<ogra> invoke-rc.d: initscript udev, action "restart" failed.
<ogra> dpkg: error processing udev (--configure):
 * ogra saw that error in local image setups before, but it didnt fail back then ...
<ArneGoetje> asac: I don't have anything in the pipeline for that one... I just saw it in my bugmail.
<asac_> ArneGoetje: thx
<asac_> will proceed then
<ArneGoetje> asac_: ok, go ahead. Thanks :)
<slangasek> anyone here with broadcom wireless who could test out whether the jockey SRU in hardy-proposed makes it work?
<slangasek> (bug #289845)
<ubottu> Launchpad bug 289845 in jockey "WL and B44 Not Properly Configured" [Undecided,Fix committed] https://launchpad.net/bugs/289845
<seb128> hum
<davmor2> slangasek: any preference on architecture?
<seb128> did anybody get xorg speed issues on intel in jaunty since recents updates?
<seb128> ie opening new dialogs or switching workspace has several second lags
<slangasek> davmor2: no, just whether you have one of the wireless chips that didn't work previously
<Milosz> Is there a way to see download statistics for packages somewhere?
<davmor2> slangasek: I can't remember I have a feeling in hardy I had to use ndiswrapper
<directhex> Milosz, sort of
<directhex> Milosz, popcon.ubuntu.com - but that only counts users with the "popcon" package installed
<davmor2> slangasek: I'll fire it up and see anyway
<Milosz> Hmm ok I was there, and didn't find the package I was looking for
<Milosz> i'll check again
<Milosz> directhex, thanks
<seb128> tjaalton, tseliot: ^ did you read my xorg question? any known recent speed issue on jaunty intel?
<tseliot> seb128: I've noticed that too but I don't know what's causing the problem
<davmor2> slangasek: I have the same chipset as in the bug and on today iso it works fine from cd do you want it installing and testing?
<slangasek> davmor2: what do you mean by "today's iso"?  I'm looking for a test of the hardy SRU, and there are no hardy ISOs from today... :)
<davmor2> slangasek: iso is the one from the 21st I hit the sta driver in jockey and wireless networks appears I select the connection and the t'interweb works :)
<slangasek> 'sta' driver?
<slangasek> davmor2: sounds like a positive result, then - could you post that information to the bug, please?
<davmor2> slangasek: listed as Broadcom STA wireless driver in jockey
<slangasek> ah, so it is
 * apw wonders who has the best view of how the kernel/hal/Xorg/gnome-power-manager fit together, as we are seeing double and tripple suspends in response to a button led suspend
<slangasek> apw: https://wiki.ubuntu.com/Hotkeys/Architecture, https://wiki.ubuntu.com/Hotkeys/Troubleshooting for a starting point
<slangasek> davmor2: oh, this bug only affects machines that also have the b44 driver - is that the driver for your ethernet on this machine?
<davmor2> slangasek: http://www.davmor2.co.uk/hplappy.html seems to be the same chipset as the initial reporter
<cq> hm, any idea why ubuntu has a much larger /lib than a debian install?
<slangasek> well, the ethernet is listed as forcedeth there, so I guess it's not the same enough
<slangasek> davmor2: thanks for testing, but I guess the results are inconclusive except to show that there's not a regression
<tjaalton> seb128: yes, bug 320813
<ubottu> Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813
<seb128> tjaalton: thanks
<apw> oh its this fix to X to make the sleep button work
<seb128> tjaalton: any idea if that will be fixed quickly in jaunty or how to workaround?
<tjaalton> seb128: no proper workaround I'm afraid
<apw> now how can i find that
<tjaalton> seb128: well, don't suspend :)
<tjaalton> that's known to trigger it
<seb128> tjaalton: I didn't suspend, that's a fresh boot from today
<cjwatson> cq: all sorts of possible reasons (different kernel module sets, firmware, things like FUSE and NTFS moved into /lib to support using them in early boot, etc.). Why?
<tjaalton> seb128: ok, so it's triggered by something else then
<tjaalton> seb128: check dmesg if there's anything suspicious
<cq> cjwatson, i just moved my system to LVM (tmp, swap, usr, var, home) and have a too-small root partition for the Ubuntu lib
<cjwatson> cq: that's life, sorry
<cq> cjwatson: no kidding, I was just wondering if that was a design decision, and if so why.... supporting more at boot makes sense
<cjwatson> personally I have never recommended separate /usr and /var
<cjwatson> well, not separate /usr anyway
<cjwatson> I can understand separate /var for log files and so on
<cq> why not? meaning /usr on root, or together with var?
 * slangasek separates /usr to avoid overhead of encryption
<tjaalton> separate /usr is UNIX legacy :)
<cjwatson> cq: it's not a design decision in itself, but is the likely consequence of other design decisions
<cjwatson> separate /usr *should* be supported, I agree, but is an excellent way to ensure that you're first to run into a slew of bugs
<cjwatson> so if you like that sort of thing, great
<seb128> tjaalton: nothing special there from a quick glance
<slangasek> hrm, I can't remember the last time I ran into a bug because of it :)
<tjaalton> seb128: ok, and I bet nothing in the xorg log either
<seb128> no
<seb128> nor in syslog
<cjwatson> I remember in particular that hwclock behaved differently for a while if you had a separate /usr
<cjwatson> and of course encrypted filesystems were broken at some point (was it edgy? feisty?)
<cjwatson> the first release after we introduced vaguely working support for them post-usplash, anyway
<seb128> ok, restarting my box and having lunch too, bbl
<tjaalton> seb128: I'm pretty certain that it's the new drm patches that got in -5.15, since I had been running the same userland for a week without problems
<cq> before running gparted, is there a way to defragment the drive?
<apw> presumably you could just test by booting back to the -4 kernel wnhich should still be installed
<BUGabundo> cq ext doesnt fragment
<cq> ok, so I can just resize the partition to as small as the existing data permits?
<BUGabundo> although fsck does some file reording with -D
<cq> plus a safety margin...
<BUGabundo> yeah, u need a margin
<cq> it wants 15gb, i give it 30 :)
<BUGabundo> lol
<BUGabundo> what does df -h sayÂ»
<cq> nothing right nowm its still resizing down from 900GB :)
<BUGabundo> rofl
<apw> one or two cylinder groups to check
<cq> the weird part is, according to DF it should only have used 500MB
<apw> superm1, you did some changes to X to get XF86Battery key working on bug #281134 wanted to talk to you about the XKeySymDB update that that brought
<ubottu> Launchpad bug 281134 in xkeyboard-config "Intrepid regression: XF86Battery hotkey doesn't work" [Undecided,Fix released] https://launchpad.net/bugs/281134
<cjwatson> gah. of course it would be too easy if random packages didn't break the installer build :-/
<ogra> cjwatson, i see d-i still on the ftbfs list, i though the udebs were there and would fix it ?
<ogra> ah, your latest upload seems to attack that, i see
<cq> I have a kubuntu X server problem... maybe you guys have an idea
<cq> I boot the machine, get to the login screen, log in, and the resolution is set too low. Then I click on system settings -> display, and hte display goes dark and then adjusts to the correct resolution...
<StevenK> pitti: So, if I can tempt you to look at the archive again -- desktop-switcher has built everywhere so needs review for binary NEW. I've not uploaded -0ubuntu2 with the .pot fix, I was waiting for -0ubuntu1 to get out of NEW first. Then there's the new u-n-r-d-s and human-netbook-theme in source NEW. :-)
<cq> next boot, same story.
<pitti> StevenK: W: desktop-switcher: script-with-language-extension usr/bin/gconf-panel-saving.sh
<pitti>  :)
<StevenK> Meh, it's a warning :-P
<pitti> StevenK: h-n-t needs to grow .icon files for translated emblems, and needs to drop build/ from the orig.tar.gz (the latter is more relevant for NEW, since it ships binary files in the tar.gz)
<StevenK> There's a build directory!? How did I miss that?
<pitti> StevenK: cf. the recent changes to human-icon-theme from primes2h
<StevenK> pitti: I wonder if we can just have h-n-t depend on human-icon-theme
<pitti> StevenK: it does already?
<pitti> StevenK: (and please fix debian/rules clean to remove build)
<pitti> StevenK: d-s binary NEWed, u-n-r-d-s isn't in the queue (forgot to remove the .upload file?), rejected h-n-t for the binary stuff
 * StevenK kicks dput
<StevenK> pitti: I'll deal with d-s armel when it turns up since you've accepted the rest
<StevenK> pitti: u-n-r-d-s reuploaded.
<ogra> cant you generate longer abbreviations ? :P
<StevenK> ogra: I can expand it out if you want
<ogra> well, u-nerds sounds funny actually :)
<ogra> now that i read it aloud
<pitti> Keybuk: any idea what else in bug 283316 could call vol_id or scsi_id? what udevmonitor incantation would you recommend for debugging this?
<ubottu> Launchpad bug 283316 in udev "CD-ROM tray closes automatically after eject" [High,Confirmed] https://launchpad.net/bugs/283316
<StevenK> pitti: Er, what translatted emblems?
<StevenK> pitti: I'm not so clear on theme packages, so you can explain the first part with butchers paper and crayon?
<pitti> StevenK: bug172353
<pitti> bug 172353
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Fix released] https://launchpad.net/bugs/172353
<pitti> has the details
<StevenK> Ah, okay
<StevenK> pitti: Which bit of h-n-t has emblems?
<StevenK> pitti: Since maybe they can get stripped
<pitti> StevenK: ah, sorry; it doesn't ship its own icons, sorry; ignore me
<StevenK> pitti: Right, so the build directory is the only thing. Cool.
<StevenK> pitti: u-n-r-d-s? :-P
<tkamppeter> I have uploaded Ghostscript 8.64RC1 and it builds perfectly on PCs (i386 and x86_64) but fails on all non-PC architectures (sparc, powerpc, lpia, ia64, hppa) not being able to install its needed libraries due to inconsistencies in the repositories.
<Keybuk> pitti: hal?
<ddeath> Hi
<ddeath> What do you can tell me about dekstop sharing on Ubuntu?
<ddeath> I have new idea to do it.
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   freeglut3-dev: Depends: xlibmesa-gl-dev but it is not going to be installed or
<tkamppeter>                           mesag-dev or
<tkamppeter>                           libgl-dev
<tkamppeter>                  Depends: xlibmesa-glu-dev or
<tkamppeter>                           libglu-dev
<pitti> Keybuk: I mean, the udev rules still call vol_id if there are tracks, I just wonder how to check that in an udev debugging output log
<Keybuk> ogra: because it can't restart the running udev on the buildd I guess
<ddeath> Why I must share whole desktop, nor only certain application
<Keybuk> pitti: udevadm monitor --udev should tell you
<Keybuk> it'll show you the tracks in the env
<StevenK> Keybuk: I didn't think the buildds used udev ?
<ogra> Keybuk, hmm, any way to avoid that in the package ?
<ogra> Keybuk, i would exect the buildd env to be in a chroot, udevs shouldnt restart in a chroot
<ogra> *udevd
<ogra> *expect
 * ogra needs type training :(
<Keybuk> in this case, it looks like it's failing even before that because the chroot doesn't have /sys mounted
<Keybuk> or has an ancient kernel
<pitti> Keybuk: thanks, asked for that and test with hal stopped
<cjwatson> ogra: ignore d-i, I'm looking at it
<ogra> cjwatson, yeah, i saw that after asking :)
<ddeath> Hi everybody
<StevenK> pitti: *prod* h-n-t uploaded
<pitti> StevenK: both done
<StevenK> pitti: As in ACCEPTed?
<pitti> yes
<StevenK> pitti: Ahh, thanks :-)
<directhex> cjwatson, poke poke r.e. debhelper 7.1. 7.1 (in experimental) broke something that pkg-mono has been using for a few years to handle package versioning. since all current mono development is happening in experimental, this has forced the need for "mono" and "cli-common" to be altered with workarounds. net result: either jaunty needs dh7.1 too, or all jaunty mono from now on needs to be merged rather than synced, to revert those 7.
<directhex> 1 workarounds (and cli-common-dev absolutely NOT updated)
<StevenK> pitti: Both of them are in binary NEW
<StevenK> directhex: Are they using a compat level of 6 or below?
<directhex> StevenK, no. 7.0 is used extensively
<StevenK> directhex: The version has a little to do with the compat level
<StevenK> directhex: If you've been using the behaviour for a few years, you'd be stuck in compat 5 or so?
<directhex> StevenK, yes, it looks like mono and cli-common have a compat of 5.
<StevenK> directhex: If debhelper 7.1 has broken compat 5, then file a bug on debhelper
<seb128> tjaalton: the way to trigger the xorg slowness on my laptop is to restart the session
<directhex> <meebey> compat is used for extra features in existing debhelper files, which is not the case here
<cjwatson> has anyone asked joeyh about it?
<StevenK> It should not break backward compatibility
<cjwatson> meebey's description is inaccurate, TBH
<directhex> there's some new syntax in 7.1+1 afaik
<cjwatson> compat has been used in the past to cope with changes that required breaking backward compatibility
<StevenK> Since doing so could render large parts of the archive insta-FTBFS
<cjwatson> it is NOT just for new features
<tjaalton> seb128: ok..
<soren> seb128: Killing gnome-power-manager doesn't help?
<cjwatson> directhex: can you give me a precise reference - what change was required in mono?
<seb128> soren: I doubt of it, I'm on ac and I don't have any processus eating cpu
<soren> seb128: Doesn't matter.
<soren> seb128: It doesn't use much CPU, it just keeps Xorg *really* busy.
<soren> seb128: I'm on AC as well and had the same problem.
<seb128> I though that issue was trigerred by power management events, ie changing backlight or ac to battery
<seb128> and it was already there one week ago
<seb128> I just started having the issue with the upgrade I did yesterday
<soren> Ah.
<meebey> cjwatson: you think the init() change was a bug?
<StevenK> meebey: I think so too.
<meebey> thing is, debhelper never had a proper interface for non-debhelper parameters
<meebey> so cli-common-dev used parameters that are used by existing debhelper tools
<meebey> could call it "internal usage"
<meebey> non-debhelper in this context means dh-scripts not part of the debhelper source package
<meebey> now with dh7.1, joeyh added an API for it, init() takes an argument now
<tjaalton> seb128: disabling vblank again might fix it for now
<seb128> tjaalton: how do I do that?
<tjaalton> seb128: build mesa with the patch from the previous version
<seb128> tjaalton: ok, that could take a while, maybe I'll try later ;-)
<tjaalton> seb128: sure
<meebey> the change in dh7.1 was a backwards compatiblity breakage without doubt, but relying on parameters maybe handled by debhelper or not was not that nice either
<PecisDarbs> hi people, what does linux-image-virtual means and why it doesn't have all ata kernel drivers? It is on purpose?
<meebey> so cli-common-dev < 0.6 needs dh < 7.1
<StevenK> meebey: Or you needed to bump compat to 8 due to the change and still deal with the old behavior
<StevenK> meebey: Since breaking debhelper can make large parts of the archive insta-FTBFS
<tjaalton> seb128: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob_plain;f=debian/patches/102_dont_vblank.patch;h=99000f2f819dade994f3b221e48c456a3dfccff0;hb=4f2e014fcd7c6fa58172c768f843e678c1332ea0
<tjaalton> seb128: that's the actual patch
<meebey> StevenK: AFAIK compat was never used for internal changes, only for source package that use debhelper directly, which is not the case for cli-common-dev
<seb128> tjaalton: ok
<meebey> StevenK: cli-common-dev doesn't use debhelper, it extends debhelper
<lamont`> WTF piece of braindamage in network-mangler causes it to generate resolv.conf files with both 'domain' and 'search' directives?
<StevenK> meebey: Hmm. It provides a dh_ ?
<meebey> StevenK: yes
<meebey> StevenK: dh_makeclilibs which causes the pain now
<meebey> StevenK: -m is ignored means it generates no minimum version for clilibs
<tjaalton> seb128: I could build it myself later
<meebey> StevenK: I fixed that in cli-common-dev, that it registers the parameter it needs and that fixes it
<meebey> StevenK: didn't upload yet though
<seb128> tjaalton: do you get the bug to test that change?
<StevenK> Mmmmmm
<tjaalton> seb128: yep
<seb128> ok good, I will let you try then, I've enough other things to do today ;-)
<StevenK> Right, that is a completly different issue ...
<tjaalton> seb128: the kernel was ruled out, at least the recent changes didn't break it
<tjaalton> seb128: me too.. damn ITIL web course (using flash of course)
<junyer> hi
<meebey> StevenK: a bit odd is thought hat debhelper still registers some parameters for all tools :)
<junyer> who's the best person to hassle about the autofs{,5} packages?
<meebey> StevenK: a bit inconsistent :-P
<meebey> like -V IIRC
<mok0> We're seeing more and more packages coming from VCS repos and with no upstream tarball. I'm looking for suggestions on how to make the watch file work for those
<junyer> (specifically, with regard to autofs v4 EOL)
<directhex> wsvn!
<cjwatson> meebey: ah, so the problem is with debhelper extensions not ordinary debhelper use. hmm.
<cjwatson> meebey: it feels to me that there ought to be a way to make the new code in cli-common-dev backwards-compatible, even if we can't make debhelper backwards-compatible
<cjwatson> meebey: actually, surely it already is
<meebey> cjwatson: well I didn't change any parameter usage code
<cjwatson> meebey: if it's just a matter of passing an extra argument to init(), you can do that without breaking old debhelper
<meebey> cjwatson: I only registered the parameters, thats all
<cjwatson> since old debhelper's init() ignored @_
<meebey> cjwatson: so perl wouldn't cry?
<cjwatson> no
<cjwatson> init isn't prototyped so it won't check
<meebey> so cli-common-dev works with old debhelper then
<cjwatson> I haven't checked this, but my perl's pretty good
<meebey> didn't know perl was that hacky^Wrelaxed
<junyer> teeheehee
<cjwatson> meebey: depends whether you use prototypes or not; if you use prototypes it's stricter. joeyh is a bit old-school and often doesn't, though
<cjwatson> directhex: so it sounds as if this is not a major problem; we just take new cli-common-dev and don't worry
<directhex> cjwatson, well, i'll try a test build of mono 2.0.1-3 which would exhibit a problem
<directhex> if there were one to exhibit
<directhex> but first, i must buy some bubble wrap
<meebey> so I can lower the build-dep of mono on debhelper
<directhex> meebey, test build needed, to be 101% certain
<directhex> but first, bubble wrap!
<meebey> directhex: you can do that, just need to check any deps if they have versions or not
<lool> cjwatson: I had to repush xine-lib still for bug #290768 as a security update was just released
<ubottu> Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed] https://launchpad.net/bugs/290768
<lool> cjwatson: 1.1.15-0ubuntu3.1intrepid1 is in unapproved
<superm1> apw, yeah, what about it?
<apw> superm1, do you know if htat might have included the XF86Sleep symbol?
<mdeslaur> siretart: I noticed you were the one who merged xine-lib the last. There are security issues in xine-lib in Jaunty. Either I apply the security patches to it, or someone merges from unstable. What do you think would be best?
<superm1> apw, no it didn't. Here's the diff: http://launchpadlibrarian.net/20150384/libx11_2%3A1.1.5-2ubuntu1_2%3A1.1.5-2ubuntu1.1.diff.gz
<superm1> apw, i believe upstream renamed the keys between intrepid and jaunty however
<apw> ++XF86Suspend		:1008FFA7
<apw> ++XF86Hibernate		:1008FFA8
<apw> it did bring the one i meant (and missstated), thanks for the diff
<apw> i think that is the cause of strange bug i have with machines double suspending
<apw> (or even tripple)
<superm1> apw, do you mean hibernating or suspending?
<apw> i mean suspend in this case
<apw> you iht FN-f4 and my T30 suspends 3 times
<apw> ie suspends again twice after waking
<superm1> apw, on jaunty or intrepid?
<apw> and a number of other platforms report double suspend
<apw> on jaunty
<superm1> apw, well on jaunty that's a little more explainable i think.  hal sends those as dbus events and gnome power manager reacts to them
<superm1> apw, so are there multiple users logged in?
<ogra> apw, there is some discussion on the hal ML about having keys captured multiple times on IBM HW (not sure thats related)
<StevenK> pitti: *prod* please release h-n-t and u-n-r-d-s from binary NEW. And webfav is in source NEW. And that's the last one, I swear!
<apw> superm1, no not multiple users
<apw> what we see at gnome-power-manager is a hal key coming in and an XF86Suspend X event coming in and _both_ being executed
<seb128> StevenK: didn't you have ubuntu-archive powers?
<apw> for my T30 there is something even odder going on in that HAL produces two keys from different places
<superm1> apw, then what you'll want to do is put a dbus monitor on the bus and see how many times the event is being sent
<apw> but i suspect that is a separat bug
<apw> which event the suspend event?
<StevenK> seb128: I still do, I don't like pulling stuff I've uploaded out of binary or source NEW.
<StevenK> seb128: Second pair of eyes, etc, etc
<seb128> StevenK: binary new is usually no issue
<apw> they are real complete and separate suspend/resume cycles
<superm1> apw, gnome-power-manager shouldn't be reacting to the X event, only the dbus event
<apw> well it has code in it to react?
<seb128> StevenK: we usually don't NEW our source uploads but I consider binaries as being no issue
<apw> which now works as the keysymbol now exists :)
<StevenK> seb128, pitti: Okay, I'll deal with binary NEW.
<StevenK> seb128: Review webfav in source NEW? :-)
<superm1> apw, it has code to react that's commented out
<seb128> StevenK: not now I'm busy on some other things right now, will do tomorrow during my archive day if nobody else did before ;-)
<apw> superm1, will check, didn't look commented out, and produces mssages in my logs
<superm1> apw, hm, well XF86Battery is commented out in 2.24.0-0ubuntu13.  if the others aren't, then they should be
<apw> /              gpm_button_xevent_key (button, XF86XK_Suspend, GPM_BUTTON_SUSPEND);
<apw>                 gpm_button_xevent_key (button, XF86XK_Sleep, GPM_BUTTON_SUSPEND); /* should be configurable */
<apw> so ... Suspend is commented out but Sleep is not, and its Sleep that we see in the logs ... interesting
<apw> i wonder what that means
<apw> superm1, so is key handling moving frmo hal direct to X do you know?
<superm1> apw, so what changed here is that X no longer has an exclusive hold on the key.  that's why HAL can send the dbus event
<superm1> apw, i believe this is the model that is going to stick, but you might check with pitti on it if he knows where HAL is headed about this
<apw> so you think it is hal which is the new event here
<pitti> I'm not actually sure
<superm1> i'm sure it is. that's what preempted my dropping 79-enable-battery-hotkey.patch
<superm1> when I pressed XF86Battery, I saw two popups.  this was because I saw one dbus event from HAL and one grabbed keypress
<apw> superm1, so by that same theory we should be suppressing XF86Sleep in g-p-m as hal is doing the job now
<superm1> apw, so i think in the short term, if any of those keys are still grabbed by gnome-power-manager that also get dbus events, you should throw a patch together that comments out the keys that are also sent by HAL.
<superm1> apw, yeah
<apw> superm1, will give that a go as step one for these people, thanks
<apw> for me i still have an issue in that now hal is producing keys i get two, and they both look rea;
<apw> real ...
<apw> they pop out two different hal channels, not sure if thats a kernel issue or hal
<superm1> apw, so the weird thing though is that only a few machines are seeing this?  you should be able to reproduce it on any machine I would think
<apw> but one bit a a time
<apw> superm1, not convinced it isn't every machine yet
<apw> as its only showing up on jaunty
<apw> and it only hits you if you hit the key, and my key didn't work on intrepid
<superm1> apw, well it will only show up in jaunty, that's when the HAL change happend
<apw> so i never used it, it was only when people reported the double and i found it differeed
<apw> for menu driven suspend and key that i tried my key again
<apw> so i gained a working key at the saem time it broke
<apw> if you get me
<apw> anyhow superm1 you have been most helpful as always
<superm1> apw, no problem, i've somehow gotten more involved in this hotkey mess :)
<apw> its all those cute keys they keep adding to those dells that does it
<directhex> meebey, what's the telltale sign whether this works or not? how would i spot a "bad" build in this context? missing versions on arch-all package deps?
<apw> so i have just apt-get source gnome-power-manager and it tells me to use bzr, and spits out a bzr command to use which doesn't work
<apw> any idea how i find out where it really is in launchpad
<james_w> "doesn't work"? what was the command?
<siretart> mdeslaur: please merge unstable. there is little point in staying at 1.1.14
<apw> Please use:
<apw> bzr get bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging
<apw> was what it told me
<apw> apw@dm$ bzr get bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging
<apw> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging/".
<apw> and that is what it says when you try it
<mdeslaur> siretart: you wouldn't feel like doing it, would you? :)
<apw> james_w, i though that there was a short form now like lp://gnome-power/trunk
<james_w> apw: seems like you want https://code.edge.launchpad.net/~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24
<siretart> mdeslaur: I'll try to find time to merge it this evening, ok?
<apw> james_w, how on earth did you figure that out?
<james_w> "bzr branch lp:~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24" will get you that
<mdeslaur> siretart: that would be great! :)
<james_w> apw: https://code.launchpad.net/gnome-power
<james_w> apw: if you are changing something in the package would you update the URLs in debian/changelog then please?
<apw> james_w, sure thing
<cjwatson> (debian/control)
<james_w> tedg: could you confirm that lp:~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24 is the branch to use to make changes in jaunty?
<james_w> err, yeah, debian/control of course
<apw> there is also a real trunk
<seb128> james_w: control.in in desktop packages if you want to keep your changes after a clean target run ;-)
<james_w> lp:gnome-power is the upstream code
<james_w> seb128: ah, of course :-)
<tedg> james_w: Uhm, I believe it should be.  But I merged the Debian SVN into there accidentally -- so it got downgraded to 2.22 :(
<james_w> oops
<tedg> james_w: So, yes, but it's FU right now.
<seb128> brb, xrandr screwed the usuable screen region when switching and there seems to be no other way that a reboot
<apw> tedg, does that mean that we don't have the code we have in jaunty to modify?
<tedg> apw: Well, what is current in Jaunty is an older revision on that branch.
<tedg> apw: But there is a lot of other work on that branch that I don't want to loose.
<tedg> apw: For instance, merging in all the mactel's team work.
<apw> tedg, ok so if i want to make a change destined for jaunty, where should i base my branch
<apw> i presume i should base from whats in jaunty to provide maximum flexibilty for where it gets merged to
<apw> i presume we tag those branches when we cut releases?
<apw> (where releases means something for upload)
<tedg> apw: I don't usually tag.  There's not enough revisions that I've done that.  debcommit should though...
<tedg> apw: Anyway, r108 of that branch is what is in Jaunty.
<apw> so you would recommend branching from there
<apw> so say it was 100% important we could release from that branch etc
<apw> and if not it should merge just fine into your jaunty head
<tedg> Yeah, I would say that if you branched from there, then we should be able to merge everything in -- that's Bazaar's job, right? :)
<apw> yeah we should indeed.  all changes should be against the last version so they can be merged in any order, imo
<lool> Â§wo, 1
<lool> Ups
<pirroh> hi, could someone with ubuntu+1 paste me the output of cat /proc/sys/fs/epoll/max_user_instances ? thanks a lot
<pochu> pirroh: maybe try #ubuntu+1
<pirroh> pochu: thanks for the hint
<meebey> directhex: unversioned deps on limono*-cil packages
<directhex> meebey, doesn't matter. won't build. "Unknown option: internal-mono"
<meebey> directhex: which dh did you use?
<directhex> 7.0.foo. whatever's in jaunty
<directhex> 7.0.17ubuntu2
<meebey> thats just for mono
<meebey> special case
<meebey> as it passes --internal-mono
<meebey> so that requires dh7.1
<meebey> but non-mono would not
<directhex> :|
<meebey> cli-common-dev 0.6 would be backwards compatible with dh7.0
<meebey> but cli-common-dev 0.5 is not forward compatible with dh7.1
<meebey> and in the case of the mono source package, it's not backward compatible with dh7.0
<directhex> is there no way to make it backward compatible? i had hoped to avoid merging
<meebey> so the issue is that ubuntu has no dh7.1 so mono can be synced?
<cjwatson> well, debhelper 7.1 is only in experimental and so makes us nervous
<cjwatson> we *could* include it
<meebey> directhex: there is but that would need ugly conditional calls in mono's rules file
<meebey> to pass the internal-mono parameter differently depending on the used debhelper version
<meebey> :-P
<meebey> is there sane way to check the debhelper version within debian/rules?
<meebey> mono's source package is already full of hacks, so another hack wouldn't be too hurtful :-P
<Laney> meebey: dpkg-query -f "${Version}" -W debhelper
<meebey> Laney: with '' that looks good
<meebey> Laney: thanks
<meebey> wrapped with dpkg --compare-version I guess thats a decent way to check for dh >= 7.1
<tkamppeter> pitti, I have prepared an SRU for bug 277404 and bug 303691 (in the cups package). The previous SRU of CUPS is still in -proposed. Should I already upload the new SRU?
<ubottu> Launchpad bug 277404 in cups "hp laserjet postscript text print does not print some characters" [Undecided,Fix released] https://launchpad.net/bugs/277404
<ubottu> Launchpad bug 303691 in cups "Intrepid, print broken with Minolta PagePro 8L printer" [Medium,In progress] https://launchpad.net/bugs/303691
<pitti> tkamppeter: just commit it for now, the current one should go to -updates first; then we can pile up more fixes
<tkamppeter> What do you mean with "commit". The changes for Jaunty are already committed to the BZR. Now I mean the upload of the package 1.3.9-2ubuntu8.
<pitti> tkamppeter: to the intrepid barnch
<pitti> tkamppeter: lp:~ubuntu-core-dev/cups/intrepid/
<tkamppeter> pitti, there I do not have access (core-dev only). Can you take the debdiff from one of the bugs and commit? Thanks/\
<pitti> tkamppeter: you can read from it and put your changes to your own branch, then I just need to pull from that
<pitti> tkamppeter: i. e. "bzr get lp:~ubuntu-core-dev/cups/intrepid/", commit, "bzr push lp:~till-kamppeter/cups/intrepid"
<Necrosan> cjwatson: ping
<cjwatson> Necrosan: yes?
<pitti> tkamppeter: want to join the desktop team meeting? (#ubuntu-desktop)
<apw> tedg, looking at what is in bzr and what is in jaunty i don't think your bzr tree is up to date
<tedg> apw: :(  Someone must have updated it out of tree then.
<apw> your tree and the changed in the apt-get source seems to diverge at 2.24.0-0ubuntu8, the tip there is ubuntu12
<apw> so should i sync that first?
<apw> sadly there are a few commits there and as there is no real info it may be hard to split them into real commits
<tedg> apw: Sure, that'd be great.
<cjwatson> you could fetch the individual revisions of the source package along the way from https://launchpad.net/ubuntu/+source/gnome-power-manager
<cjwatson> those would probably be good enough as individual commits
<apw> ok will load the changed up into a branch off 0ubuntu8 ...
<cjwatson> (not perfect obviously)
<apw> cjwatson, ahh yes, better than trying to do it manually
<apw> thanks for that gem
<cjwatson> james_w also has a 'bzr import-dsc' tool that can automate the import from source packages
<cjwatson> though it requires slightly careful driving sometimes
<ScottK> mvo: Compiz is going to need a rebuild against kde 4.2.0 for libplasma changes.  I didn't do it with the others, because I thought it best to leave it to someone more focused  on the package.  The new kde4libs hasn't built yet on lpia, powerpc, ia64, or hppa due to uninstallable build-deps.  In other packages I just versioned the libplasma-dev build-dep to 4.2.0 so it wouldn't build against the old one accidentally.
<Riddell> compiz uses plasma?
<mvo> ScottK: thanks, I will update the bzr tree and upload it
<mvo> that is the kde side of compiz :) I have little clue about that
<ScottK> Riddell: Yeah.  Compiz-kde does.
<ScottK> mvo: I did about a dozen and a half packages last night and today and so far all but one were good as no change rebuilds.
<mvo> ScottK: excellent, thanks
<ScottK> cjwatson: I've been following your edits of the archive-reorg spec on the wiki.  Is this idea of essentially promoting all MOTU to core-dev something that there is a hard consensus around or do you think it's still up for discussion?
<cjwatson> it may not be clear from the spec as written, but the current consensus as I understand it is to have a transition process where many MOTU are given full archive access and many are moved into layer-specific teams
<cjwatson> ScottK: do you have an objection to it?
<ScottK> cjwatson: It sounded to me from reading the spec like it was all MOTU and automatic.
<ScottK> cjwatson: That I'd object too.
<cjwatson> ~[6~[6~that's an error
<ScottK> OK.
<cjwatson> (sorry for load-induced garbage)
<ScottK> No problem.
<ScottK> I guess i don't understand why we don't keep MOTU as a generalist entry point to deal with all unseeded packages.
<ScottK> That's essentially what MOTU covers now.
 * ogra collects the garbage for possible later use 
<cjwatson> oh, the spec does not call for the disbandment of MOTU
<ScottK> Well that's another misimpression I have then.
<cjwatson> it's still clearly useful as a mentoring organisation, particularly for generalists
<cjwatson> but I don't think it needs to have lower access control than current ubuntu-core-dev in order to achieve that
<ScottK> Hmmm.
<cjwatson> in other words, people who only want to work on packages not in any layer are entirely free to continue to do so, and I expect will
<ScottK> Right, but we generally have expected core-dev to understand more about integration and care for the whole distro.
<cjwatson> but I don't think that *has* to be the only identity of MOTU; even at the moment it seems to be more than that
<ScottK> It seems then that we are losing that disctinction then.
<cjwatson> well, I think that distinction has been blurred over time anyway
<cjwatson> MOTU's application process involves much more teaching than it used to
<cjwatson> and we already expect MOTU to exercise a degree of discretion, don't we?
<ScottK> A degree.
<cjwatson> I don't think that the boundary between main and universe is anywhere close to the line between "this stuff is fairly isolated" and "this stuff will break the world if you get it wrong" any more
<cjwatson> which makes it ... well, a bit artificial
<cjwatson> and maybe it isn't worth trying to enforce that in the same way any more
<ScottK> Perhaps.
<pitti> tkamppeter (CC: Keybuk, seb128): Do you see any chance of the printer applet being rewritten in C, or be spawned on demand? it imposes quite a high startup cost when you log into GNOME
<ScottK> I do think a half-step to general upload rights (i.e. unseeded) is a good idea.
<ScottK> I'm less concerned about what we call it.
<pitti> jockey does as well, I'll address that in jaunty
<ion_> pitti: If youâre going to rewrite jockey in C, you might find the code in hardware-connected useful.
<cjwatson> ScottK: my perception is that there are very few packages for which I would be concerned about granting access to most of today's MOTU, given the number of eyeballs on jaunty today and the opportunity for social approaches to mistakes
<pitti> ion_: no, not that, just don't start it by default each and every time
<cjwatson> ScottK: I don't think that necessarily means that everyone is obliged to work on everything, any more than today's MOTU necessarily work on everything to which they technically have access
<ion_> pitti: Ah
<cjwatson> and so it's a question of how much time we lose due to the distinction drawn four and a half years ago, when Ubuntu was a much simpler place
<ScottK> cjwatson: Right, well there's a transition issue to deal with.
<ScottK> If we conclude that someone is not ready for general acces, but doesn't have a particular focus interest, do they have no upload rights?
<cjwatson> I'm not sure, but that's a good question
<cjwatson> ScottK: I've made a FIXME note in the spec
<ScottK> When I think about the path in the future to core-dev, I can see a specialist working to branch out, but I don't know how a generalist could get limited upload rights to prove themselves in the current plan.
<ScottK> cjwatson: Thanks.
<ScottK> At least as I understand it anyway.
<cjwatson> the original notion of limited rights to universe while we figured out trust issues was based, I think, on the notion that most users would only install packages from main
<cjwatson> I'm not sure that that's true any more, and so I wonder whether this is actually a good proving groundd
<cjwatson> -d
<cjwatson> given that it does offer very direct access to users' systems
<cjwatson> and hence a level of trust that, in practice, is really not that far off core ...
<ScottK> I think a slight redefinition covers it then.
<ScottK> core is packages installed by default and not in packages installed on selected systems.
<ScottK> I do think we need a route in for generalists.
<ScottK> If we don't then we've traded one problem for the opposite.
<cjwatson> thing is, I don't actually think the opposite problem is a problem
<cjwatson> Debian does not have people wildly uploading rubbish, and to be honest, even though the Debian process is overly lengthy, there are plenty of Debian developers who are fairly amateur
<cjwatson> (and also of course lots of excellent ones!)
<ScottK> True.
<ScottK> But Debian has a tradition of people being focused on specific packages that they get to know well.
<ScottK> People understand there is a higher threshold for not messing up when you NMU someone elses package.
<ScottK> That same extra consideration doesn't exist in Ubuntu.
<cjwatson> "installed by default" is a far too movable feast in Ubuntu
<cjwatson> I don't think it's something we can base access control on, not to mention that many Ubuntu users have a hit-list of things they install anyway right after installation
<ScottK> OK.
<ScottK> I'll just take a step back and say we ought to have a clear path for generalists.
<cjwatson> so, route in for generalists: what aren't we solving by means of sponsorship, PPAs, branch reviews, and our existing mentoring facilities?
<ScottK> I guess if you view the entire notion of limited upload rights first as obsolete, nothing.
<cjwatson> well, I'm exploring
<cjwatson> not based on the conviction that limited upload rights *are* obsolete, but based on removing the conviction that they're necessary
<ScottK> OK.
<apw> tedg, how is one meant to use this bzr checkout of gnome-power ?  i had expected d/r patch to make me some source but it does not
<ScottK> Taking that one step further then, if you're willing to go straight from no upload rights to full (almost) upload rights for generalists and trust them not to mess where they don't know enough, why have teams and limits at all?
<ScottK> I'm not sure that the case doesn't apply equally well to specialists.
<cjwatson> I guess because the process for gaining access to those teams could potentially be simpler and shorter
<ScottK> just exploring ....
<tedg> apw: I copy the debian directory in to the source tree cp -a branch/debian gnome-power-manager-2.24.2/
<cjwatson> you only have to investigate their specialist abilities, and not so much their ability to cope when thrown something they don't understand
<ScottK> Perhaps.
<apw> tedg, hmmm ok
<apw> this bzr integration really isn't that smooth is it
<ScottK> OTOH, if I'm a server guy working on a server app not seeded, I don't need access to upload everything.
<cjwatson> apw: once we deploy bzr across the board, we will not be using this scheme where the branch doesn't come with all the source
<tedg> apw: Well, yes and no.  If you use the package-import.u.c stuff you get everything directly, but then there's no separation between upstream VCS, upstream tarball, and the ubuntu package.
<cjwatson> apw: we'll just be putting all the upstream source in the branch
<apw> i would have expected this branch to be a branch off your upstream branch, and as a result have the source
<apw> but no matter, if thats how it works, its how it works
<cjwatson> that's how the new world order will work
<apw> just not at allll obvious
<seb128> if you don't have very fast internet access bad luck for you
<cjwatson> the only downside is performance, but that's outweighed by avoiding all the setup problems
 * tedg is still resisting the new world order
<cjwatson> seb128: I'm on a 512KB link (at best, often much slower) *shrug*
<cjwatson> so don't talk to me about slow links :)
<cjwatson> err, I mean 512kilobits
<cjwatson> it was 100 kilobits for a while there
<seb128> cjwatson: which means getting a non trivial source is going to take a while compared to apt-get
<cjwatson> I'm not a fast-link fascist, I'm a make-the-tools-not-suck fascist
<cjwatson> seb128: I'd gladly trade that for the time spent helping people battle with the tools and being turned off Ubuntu development as a result
<ScottK> cjwatson: Thanks for the discussion.  I'll sit back and see how the spec evolves ....
<cjwatson> not to mention the time spent battling with the tools myself
<seb128> cjwatson: apt-get source, change, dput is not that much battle, for me it's using bzr which is the battle ... but let's see how it goes when we have an established workflow
<cjwatson> for non-trivial source packages, it's going to take a while to test-build anyway and after the initial pull everything is much faster thereafter; and I can always go and get a cup of coffee
<cjwatson> apt-get source, fiddle about to put debian/ into the right place, test-build, curse when I discover there are some files missing from the checkout, etc.
<cjwatson> I wouldn't say it was a battle if it weren't for me, every time I try to work with a package that isn't full-source
<seb128> I don't mean the debian directory in bzr, I mean what we have now when not using bzr ;-)
<cjwatson> ah
<seb128> I just find work harder to do every time I've to change a package in bzr
<cjwatson> personally I'd like to explore putting .bzr in the source package to resolve that problem, perhaps using dpkg-source v3
<seb128> that would be nice
<seb128> once of the issue right now is that we don't have standard locations
<cjwatson> James' work is solving that
<cjwatson> once we get the necessary LP facilities
<seb128> ie, you apt-get source, get a bzr get command to use, use it, ran bzr commit and bzr push and you get an error saying you need a location
<seb128> which is usually where I get stucked and ask mvo for help to figure what location to use ;-)
<cjwatson> we'll be able to run 'bzr checkout lp:ubuntu/+trunk/packagename' or similar
<cjwatson> same schema for everything
<ScottK> seb128: I recently learned about bzr push :parent.
<ScottK> That pushes it back where you got it from.
<cjwatson> 'bzr push' without arguments does that if you only just did 'bzr get'
<seb128> cjwatson: no it doesn't
<seb128> not when using get, maybe when using checkout or mirror or something else
<seb128> I know some are alias for others but I usually use get which is what apt-get source suggest and get stucked
<seb128> btw speaking about bzr
<cjwatson> hmm, ok, I thought it did
<cjwatson> I always use checkout if I possibly can
<seb128> why does running "bzr get lp:~mvo/+junk/compact-dpkg-status" wants me to enter my ssh passphrase and how do I tell it I just want an anonymous checkout?
<cjwatson> don't you run an ssh agent?
<seb128> I do
<seb128> but I would expect that to not use http to do the checkout
<seb128> -not
<cjwatson> lp always uses bzr+ssh or sftp; I think bzr+ssh is actually faster than http for checkout, although I could be wrong and haven't timed it recently
<seb128> hum, ok
<cjwatson> at any rate I'd expect it to be potentially faster since it's using a customised protocol
<cjwatson> obviously there are the extra round-trips for auth but that should be dominated by large branches
<cjwatson> seems pretty similar here for lp:~ubuntu-desktop/vte/ubuntu vs. http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu, though
<cjwatson> at any rate, it would be possible to add that feature but it would require modifying the bzr launchpad plugin
<seb128> that's not really an issue, I was just curious about why the ssh key was used I though http was used for checkouts
<seb128> ah
<seb128> apt-get source suggests "bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main"
<seb128> that might be why push doesn't work
<seb128> it's suggesting the http url
<cjwatson> that's entirely dependent on what's in debian/control
<cjwatson> you can use debcheckout -a <package>, which always gives you an authenticated checkout if it can
<cjwatson> which means you have the best of both worlds - a URL in debian/control that you can paste into a web browser, and an easy way to get an authenticated checkout if you want
<seb128> right
<seb128> I guess most of my issues using bzr is just that I'm not really used to this worklow and we don't really have one consistant way to do things
<cjwatson> I agree that the inconsistency is a pain
<cjwatson> from my POV, the things that are inconsistent from what I'm used to are a pain, of course, so I will express annoyance at different things
<cjwatson> e.g. I swear out loud pretty much every time I have to deal with anything called 90_autoreconf.patch :-)
<seb128> ;-)
<seb128> I'm pondering changing those to run autotools are build time
<seb128> but I'm not sure that would be better, that leads to another class of issues
<seb128> ie, things stop working when a new libtool gets uploaded and ftbfs
<seb128> hum, bzr is still slooow
<seb128> apt-get source update-manager -> 23 seconds
<seb128> bzr -> 6 minutes 22 seconds
<cjwatson> james_w: this all reminds me, should we make debuild -S run bzr bd -S if appropriate (.bzr-builddeb exists, plugin available)?
<cjwatson> that's one irregularity in my workflow at the moment
<apw> tedg, ok i have pulled in all of the changes that have been applied to gnome power via direct uploads, and pushed them as a branch and proposed it for merge: https://code.launchpad.net/~apw/gnome-power/incorporate-direct-uploads/+merge/3160
<seb128> ie, 16 times slower
<apw> tedg, i would note that you have rebased to a newer upstream since this branch was made so the merge will be hairy
<cjwatson> bzr is certainly never going to be even close to as fast as apt-get source for me, since I have a local mirror of the latter; but I don't usually find that it gets in my way that much, I can always go and triage a few more bugs or something
<seb128> well, I know I find the 7-8 minutes to get gtk to be a while already
<seb128> but it would take over an hour using bzr
<cjwatson> how many people bzr get gtk when they don't work on it regularly though?
<Keybuk> seb128: provided you've done the switch to libtool 2.2 you should be fine
<Keybuk> the whole reason I pushed hard to get to 2.2 was that libtool 1.5 was the last of the tools that didn't believe in upgradability
<seb128> Keybuk: I'm not, I still downgrade to libtool 1.5 to autoreconf gtk because otherwise it doesn't build
<Keybuk> autoconf 2.6x, automake 1.6+, libtool 2.2 and gettext all should upgrade gracefully
<cjwatson> seb128: re autoreconf.patch, I think the main thing that causes me problems is that often they aren't actually autoreconf, and don't describe the command you need to run to update them in the patch
<cjwatson> so I run autoreconf -iv and get an enormous diff from hell
<seb128> cjwatson: we often have autoconf changes which are just an autoconf run to update configure due to lpi changes
<cjwatson> (sometimes just because diff hunks are in a different order or something, but it's pretty hard to tell)
<cjwatson> seb128: right, but they usually don't say that in the patch so how am I supposed to know :(
<seb128> otherwise we used to run aclocal, autoconf, automake, etc in order but we learnt to use autoreconf recently and use that now ;-)
<Keybuk> seb128: you shouldn't _have_ to run autoreconf for those ;)
<Keybuk> just build-depend on autoconf
<seb128> cjwatson: yeah, we should document the patches
<seb128> the naming gives an hint, autoconf against autoreconf
<james_w> cjwatson: we could. I'm not sure it's worth the "wtf?" for those who don't really realise what's going on though.
<james_w> cjwatson: and the two tools aren't completely command-line compatible.
<seb128> Keybuk: well, what I said before, I'm considering changing that but I'm not convinced by running autotools at build time, that can lead to surprises
<james_w> cjwatson: is it just that you are used to typing "debuild -S", or something else?
<cjwatson> james_w: yes
<cjwatson> (the former)
<cjwatson> oh, also, I think that in general devscripts should be able to do the right thing across the board
<seb128> Keybuk: where autotools patches made with a known to work version are using not an issue ;-)
<Keybuk> seb128: if it leads to surprises, I promise to investigate and fix any autotools bugs I find
<cjwatson> which seems to suggest that if it sees a tree containing .bzr-builddeb it should build it appropriate
<cjwatson> ly
<james_w> cjwatson: I don't think we can guarantee that, so it's a tricky path to start down
<cjwatson> I like the idea of devscripts as unifying wrapper scripts, which by and large they are
<seb128> Keybuk: ok good to know, the issues are usually not autotools though bug configure doing stupids things which used to work but are not documented and stop working in some new version
<cjwatson> it could even refuse to build something containing .bzr-builddeb and tell you what to do, although that wouldn't be optimal
<seb128> bug configure -> but configures
<Keybuk> seb128: true, but I've found that most software is quite easy to fix
<cjwatson> the problem I have is finger macros that do debuild -S and then I find some cruft in the debdiff and have to rebuild
<Keybuk> admittedly, sometimes you have to repackage the tarball :-/
<seb128> Keybuk: the "m4_ifdef([LT_OUTPUT], [LT_OUTPUT])" trick you gave me the other time seems to be usually a good way to fix issues
 * Keybuk can't remember what that one was for ;)
<seb128> gtk has still something which it doesn't like in libtool2 though, I need to investigate, I might ping you back about it
<seb128> I still downgrade to libtool 1.5 to relibtoolize this one for now
<Keybuk> ohhh
<Keybuk> I remember
<Keybuk> that was extraordinarily cunning of me ;)
<cody-somerville> lol
<Keybuk> not only will that make libtool 2.2 generally work like 1.5 with its early libtool generation,
<Keybuk> but it will still work if someone uses libtool 1.5,
<Keybuk> *and* if someone has both, it'll make them use 2.2
<Keybuk> I deserve some kind of award for that one <g>
<liw> hmm. I'm renaming package foo to bar. foo has a state file I need to copy to the new location in bar. bar Conflicts and Replaces foo. shouldn't bar's prerm script be called by dpkg during the upgrade?
<cjwatson> why would bar's prerm script be called, rather than foo's?
<cjwatson> at no point in this procedure is bar removed ...
<cjwatson> (or even an old version of bar "removed" in order to unpack a new one)
<liw> that's what I thought Debian Policy 6.6, point 3, subpoint 3 says (http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html)
<cjwatson> are we looking at the same point?
<cjwatson> "Otherwise (i.e., the package was completely purged): "
<liw> "Conflictor's-prerm remove in-favour package new-version"
<cjwatson> do you mean point 2 subpoint 3?
<liw> er, point 2, subpoint 3
<cjwatson> ah. that's talking about the package being removed, not the package being installed. the term "conflictor" is a bit confusing.
<cjwatson> but the ambiguity is cleared up at the top of that point, I think ('If a "conflicting" package is being removed at the same time ...')
<liw> ok, so I don't need to (rather, can't) do anything in bar's prerm
<cjwatson> does foo remove its state file on remove, rather than on purge?
<liw> only on purge
<cjwatson> you can probably retrieve it in bar's preinst then
<ScottK> cjwatson: WRT bar and debuild, it seems to me that changinging what it's done into something different would be a suprise.  Wouldn't it be better to just have a different command for doing it the bzr way, that way the finger macros don't get tempted?
<cjwatson> I say "probably" because if the user told their package manager to purge foo at the same time, I don't think the ordering of foo purge vs. bar unpack is defined
<cjwatson> ScottK: well, at least in the (simple) cases I've encountered, the only effective difference is to exclude .bzr-builddeb from the source package
<cjwatson> ScottK: but debuild is *supposed* to be a clever wrapper that figures out what to do and does the right thing
<liw> cjwatson, in this case I'm happy enough with a best-case effort to save the file in question, so that's OK
<ScottK> OK.
<cjwatson> ScottK: the surprise, for me, is when it doesn't :-)
<cjwatson> if I wanted a stupid tool I'd just use dpkg-buildpackage
<ScottK> As long as we preserve the non-bzr case to work correctly, I'm happy.
<ScottK> Right. ;-)
 * pochu feels stupid - I use dpkg-buildpackage a lot ;)
<cody-somerville> ScottK, bzr merge makes doing merges from Debian super easy
<cody-somerville> ScottK, Have you tried it?
<ScottK> cody-somerville: I haven't.
<ScottK> I don't generally have a lot of trouble with the output of MoM/DaD.
<cjwatson> pochu: stupid tool doesn't imply stupid user/developer :-)
<cody-somerville> ScottK, its nice when there is no output of MoM or DaD
<cody-somerville> ScottK, ie. new upstream releases that are in Debian SVN but not uploaded because Debian is frozen
<[swb]> hey guys, wondered if anyone would be interested in trying to reproduce a bug in gnome panel behaviour for me
<[swb]> its pretty annoying
<ScottK> [swb]: #ubuntu-bugs is probably a better channel for that.
<[swb]> ahh ok
<iulian> [swb]: You might want to file a bug as well.
<Necrosan> cjwatson: doh,still around?
<cjwatson> Necrosan: yes?
<Necrosan> ill paste log of aptitude
<didrocks> cjwatson: thanks for the sponsorship :)
<Roby> save the pervs! http://www.ihateyounatalie.com/?id=1175538
<iulian> Eh?
<cjwatson> coo, I didn't know the XFS lots-of-NULs bug had been fixed
<cjwatson> http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F
<cjwatson> good news for anyone trying to use apt on it, I guess ;-)
<ion_> Oh, neat.
<directhex> hmph, mere mortals aren't meant to get neat features from XFS. that's what SGI support contracts are for!
<slangasek> cjwatson: wow, they're just getting rid of all of XFS's distinguishing features these days, aren't they? :)
<lfaraone> Hi, are we going to have gnome 2.26 in jaunty?
<cjwatson> I would assume so since Ubuntu releases always come with the newest version of GNOME
<lfaraone> cjwatson: ok, so when will .26 prerel packages start shipping in Jaunty? (before FF I hope, I have packages which depend on bindings there)
<pochu> lfaraone: they are already in the archive
<pochu> 2.25.5 mostly
<lfaraone> pochu: the spesific package I'm eyeing is http://packages.ubuntu.com/jaunty/python-gnome2-desktop
<lfaraone> pochu: "Package: python-gnome2-desktop (2.24.1-0ubuntu1) "
<seb128> lfaraone: what is the question exactly? I just joined the channel
<lfaraone> seb128: When is the python-gnome2-desktop containing the sugar evince bindings (which are shipping in 2.26, or so upstream sugar tells me) going to land in Jaunty? (well before FF I hope)
<seb128> lfaraone: when upstream roll a tarball which has the code changes
<lfaraone> seb128: ok, arn't .25 tarballs already out for tyhat package?
<seb128> lfaraone: there is a 2.25.1 which has no interesting changes (ie a waf build system update, a small fix and a configure option bugfix)
<lfaraone> seb128: kk, understood.
<Chipzz> waf - because auto* doesn't work
<Chipzz> </sarcasm>
 * Chipzz sighs
<Amaranth> cmake - because auto* is slow :)
<Chipzz> Amaranth: nuke libtool if you don't want slow
<Chipzz> or annoying and pointless .la files
<Amaranth> Chipzz: If I could figure out how
<Amaranth> I've given up on understanding that system, I just copy/paste from other people :P
<Chipzz> I was not saying auto* was easy :)
<Chipzz> it does, however, get a lot of stuff right that I doubt other systems do
<Chipzz> I wonder how many of the alternatives to auto* can do out-of-tree building
<Amaranth> Chipzz: That's all cmake can do
<superm1> slangasek, i've cleaned up most of hotkey-setup and moved things into hal-info (in Ubuntu and submitted upstream).  I forget what the contingency plan was for thinkpad stuff though, so i'll leave that bit to you thinkpad owners okay?
<slangasek> superm1: hrm, I was still working on getting a bzr repo set up so that we'd have fine-grained regression tracking
<slangasek> superm1: I don't suppose you did something like that while cleaning it up? :)
<superm1> slangasek, no... can't say I did.  I hand checked each of the lines to make sure they were in an FDI file
<slangasek> ok
<slangasek> so what's left in the new hotkey-setup package - ibm.hk and thinkpad-keys.c?
<slangasek> and lenovo.hk
<superm1> slangasek, that and a call to set DOS on Intel or AMD /proc/acpid/video/VID* to 7 (enable keys)
 * lfaraone pokes GNOME with a sharp stick.
<slangasek> superm1: alrighty
<lfaraone> seb128: any chance I could get you to include some SVN'd patches that arn't yet tarballed? :P
<superm1> slangasek, i'm not sure why that needs to be done in an init script though about enabling hotkeys for video switching.  would probably make more sense to just set the kernel to default to them enabled
<slangasek> superm1: probably; but twiddling in an init script is a lot more lightweight than getting a kernel patch accepted upstream, so I guess it was meant to be a stopgap and was never followed up
<superm1> slangasek, yeah probably in that case
<seb128> lfaraone: that can always be done but that doesn't seem to be anything really useful in an unstable distribution where nothing uses the new code yet
<seb128> lfaraone: next tarballs are due monday I would rather wait for them to roll a tarball
<lfaraone> seb128: well, we _would_ be using it if we could upload the package.
<seb128> lfaraone: we being?
<lfaraone> seb128: but we can't do that until evince is up to date.
<lfaraone> seb128: ubuntu-sugarteam.
<seb128> lfaraone: you are welcome to work on the change and request sponsoring
<slangasek> bryce: huh, does bug #217908 really affect 8 different source packages?
<ubottu> Launchpad bug 217908 in xserver-xorg-video-openchrome "Images in Firefox and Opera are extremely pixeled when zoomed" [Undecided,Confirmed] https://launchpad.net/bugs/217908
<seb128> lfaraone: the ubuntu desktop team is already overworked so we will not take on extra work only to backport something a few days before a new tarball
<bryce> slangasek: yuck
<lfaraone> seb128: ok, sorry.
<mathiaz> slangasek: are aware of bug 321689 - which is a result of having -proposed packages in 8.04.2 -server isos?
<ubottu> Launchpad bug 321689 in openldap2.3 "openldap (slapd) installation fails" [Undecided,Confirmed] https://launchpad.net/bugs/321689
<slangasek> mathiaz: yes, the openldap2.3 SRU has just been pushed in response
<seb128> lfaraone: nothing to be sorry about I'm just telling you I'm not interested to work on the change now but I'm happy to review work if you want to work on it an request sponsoring
<seb128> lfaraone: otherwise wait a week or so for the update
<mathiaz> slangasek: ok. that should fix the problem for openldap.
<mathiaz> slangasek: are we respinning the isos?
<slangasek> mathiaz: no, we're trying to get all the SRUs that crept on from -proposed validated and pushed out instead
<mathiaz> slangasek: ok.
<bryce> slangasek: yeah someone went package crazy there
<slangasek> since that's something that needs to happen anyway, and rolling new ISOs won't roll back the installs that are already in the wild
<slangasek> bryce: yes, yes they did :-)
<bryce> slangasek: guessing they suspected it to be an X problem but didn't figure out which package, so just shotgunned a bunch of X packages
<slangasek> bryce: and then someone marked the bug 'confirmed' on half of them? :)
<bryce> can I blame my scripts?  ;-)
<slangasek> sure :)
<bryce> slangasek: wow this is an interesting bug
<bryce> slangasek: okaaay, I think I got it
<bryce> slangasek: in this case it probably is alright for this to be open against all these drivers
<bryce> the issue is that there needs to be a repeat mode implemented in each of the video drivers to display images correctly
<bryce> currently they say they support it, but they don't do so properly, which confuses higher level things like cairo
<slangasek> bryce: ah - so should the bug against cairo and xulrunner be closed...?
<bryce> anyway, it looks like Thomas Jaeger has this bug pretty well under control, I don't think we need to tweak it
<bryce> slangasek: I think we can leave it as is; those will also need to be touched once the drivers are fixed up
<slangasek> bryce: darn. :)  ok, what should I do with the jaunty nomination - is this a realistic target for jaunty?
<bryce> it makes for a messy bug, but it's a messy problem, and it seems people are making the best of it
<bryce> I think it is realistic; already Tom posted one patch, it sounds like he plans to get patches done for each driver, and then we can switch cairo
<bryce> hmm
<bryce> it probably doesn't really matter to have jaunty nominations for all of this
<bryce> and the hardy nominations are probably right out...  this doesn't feel like a viable sru thing; it requires twiddling too many different packages
<slangasek> well, I'd like to either approve or decline the nomination, and that applies to all packages with an open task - we can 'wontfix' any that aren't jaunty targets afterwards if necessary
<bryce> slangasek: I'd say decline them all.
<bryce> progress can just be tracked with the regular non-targeted tasks
<bryce> most of these are obscure drivers anyway, who cares about -i128 :-)
<bryce> s/most/several/
<slangasek> bryce: done, thanks
<bryce> I'll update the description too
<slangasek> did jaunty change something wrt touchpad handling?
<slangasek> my laptop's left mouse button has gone batshit suddenly; not sure if it's hardware or software
<slangasek> only the one on the touchpad is affected, the nipple-complementing one works fine
<bryce> lots of fixes have gone into input stuff, and we did just put in a new xserver recently, so I'd guess it's software more likely
<slangasek> doh
<bryce> heh, you'd be more happy if it were hardware, eh?  ;-)
<slangasek> not really, but at least then it would just be me :)
<bryce> booting an intrepid livecd and seeing if it can be reproduced would probably help rule in or out the recent changes (assuming you can reproduce it reliably boot-to-boot currently)
<slangasek> I haven't yet rebooted since noticing the problem; part of my ongoing love for gnome session saving
<ebroder> ScottK: have you had a chance to look at #321763 yet?
<slangasek> seb128: sent a follow-up to bug #267018; I'm wondering why you thought it was fixed in jaunty, maybe it would help to talk through this in realtime?
<ubottu> Launchpad bug 267018 in gnome-settings-daemon "regression: g-s-d no longer handles Fn+F7 as xrandr --auto" [Low,Confirmed] https://launchpad.net/bugs/267018
<seb128> slangasek: because the gnome-settings-daemon 2.25.3 NEWS lists an add support for fn-f7 keys in the list of changes
<slangasek> hmm
<slangasek> seb128: I don't know what that refers to, but the default keybinding for the xrandr plugin is still wrong
<slangasek> AFAICS it should be 'XF86Display', not 0xdc or whatever
<seb128> slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon?view=revision&revision=622
<slangasek> seb128: well, I think that's unrelated to this bug, though maybe it's related to the bug I'm about to file regarding a regression in the behavior of the xrandr plugin
<seb128> wh
<seb128> which one?
<seb128> slangasek: try desactiving the xrandr keybinding, that's an ubuntu patch and it might be hijacking the new upstream option
<seb128> ups
<seb128> slangasek: wait
<seb128> slangasek: http://bugzilla.gnome.org/show_bug.cgi?id=568713
<slangasek> seb128: now when I press XF86Display in jaunty, video comes up on the external monitor, with the same resolution as the LCD instead of with the preferred resolution as shown by xrandr
<ubottu> Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=568713)
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=568713
<ubottu> Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=568713)
<seb128> stupid bugzilla is being slow again apparently
<seb128> slangasek: ok so the keybinding does something?
<slangasek> seb128: if I set the keybinding to XF86Display, it does something that's wrong and a regression from intrepid
<slangasek> if I delete the override of the keybinding, it does nothing
<slangasek> I think I've /also/ seen 568713, but that's a separate bug
<seb128> slangasek: the patch makes the keybinding call xrandr --auto
<slangasek> that's a patch that's in the Ubuntu package?
<seb128> slangasek: apt-get source gnome-settings-daemon and look to 19_extra_keybindings.patch
<seb128> yes
<slangasek> the behavior of g-s-d does *not* match the behavior of xrandr --auto
<seb128> what upstream does seems to be activating the clone mode when using the keybinding
<ion_> What key is XF86Display?
<slangasek> ion_: whichever key the input layer says it is
<slangasek> on thinkpads, Fn+F7
<ion_> I mean typically. Ah, that one.
<slangasek> seb128: strange; the behavior of g-s-d definitely doesn't match the behavior of xrandr --auto
<seb128> slangasek: maybe the upstream code triggers first but that's weird that disabling the keybinding would stop the action then
<slangasek> how is the upstream code triggered?
<slgce> where do i find su source code? til now i just found sudo ones
<seb128> slangasek: I'm looking to that, I would say that gnome-settings-daemon listen for key events
<slangasek> slgce: su is part of the 'login' package.
<slangasek> seb128: bug #322111 filed for this
<ubottu> Launchpad bug 322111 in gnome-settings-daemon "gnome-settings-daemon xrandr plugin gets wrong resolution on external monitor" [Undecided,New] https://launchpad.net/bugs/322111
<slgce> slangasek, thank you, I'll take a look right now
<seb128> slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/xrandr/gsd-xrandr-manager.c?view=markup&pathrev=622
<seb128> gsd_xrandr_manager_init ()
<seb128>  guint keyval = gdk_keyval_from_name (VIDEO_KEYSYM);
<seb128> where
<seb128> #define VIDEO_KEYSYM "XF86Display"
<slangasek> seb128: hmm, ok
<seb128> slangasek: doing fn-f7 on my laptop crashes g-s-d which seems to indicate that I run into the bug indicated before
<slangasek> yeah, I can trigger that bug too by pressing Fn+F7 repeatedly :)
<seb128> ok, which means the upstream code get called
<slangasek> sure
<slangasek> but, if I disable the gconf keybinding, whatever that upstream code does has no effect here
<seb128> that's because it crashes ;-)
<seb128> ah, if you disable it
<seb128> that's weird
<seb128> why would that impact on the upstream code
<slangasek> no, I know when g-s-d crashes or not, I can tell by the color of my window borders. :)
<slangasek> perhaps what's happening is that xrandr --auto is being called first, and *then* the upstream code runs and screws up the resolution of the external monitor?
<slangasek> but the upstream code by itself fails to ever do anything to bring up the external monitor?
<seb128> that could be
<seb128> I'll upload a version which drops the ubuntu change and include the svn fix tomorrow
<seb128> so we will have a better idea of what the upstream code do
<slangasek> seb128: well, in a quick reading of the upstream code, it says that it's meant to cycle through "profiles" - so where would I define these profiles?
<slangasek> that's something new, that doesn't seem to be connected to the existing configuration tools
<seb128> slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/xrandr/gsd-xrandr-manager.c?view=markup&pathrev=622 look to generate_fn_f7_configs (GsdXrandrManager *mgr)
<seb128> slangasek: it does xinerama, clone, etc configs there
<slangasek> hmm
<slangasek> so maybe it's just crashing before it gets to the profile that does what I want
<seb128> right
<seb128> there is no hurry and I was about to go to bed but I will look at it tomorrow
<seb128> feel free to backport the svn fix and drop the patch and upload if you want to do that now
<slangasek> yes, don't let me keep you - good night!
<seb128> otherwise wait for the update tomorrow
<slangasek> ok, I'll test that here if I get a chance
<seb128> thanks and good evening to you ;-)
<ScottK> ebroder: Not yet.  On my list for tonight.
<ebroder> Great. Let me know if you need anything
<junyer> hi
<junyer> i'm looking for anyone who might deal with the autofs and autofs5 packages
<junyer> (mostly concerning the autofs v4 EOL)
#ubuntu-devel 2009-01-28
<Necrosan> Just an FYI, after building sunffb on jaunty, xorg is crashier than ever.
<Necrosan> Will not run.
<Necrosan> Not sure if it's sunffb or xorg itself.
<slangasek> where's the best place to assign bugs in langpacks?  (bug #286065)
<ubottu> Launchpad bug 286065 in apt "Swedish translation typo: opeation -> operation" [Undecided,New] https://launchpad.net/bugs/286065
<slangasek> if I assign it to the actual langpack that's at fault, will it get looked at?
<cjwatson> I generally subscribe the relevant translation team and hope they'll pay attention
<cjwatson> I'm not convinced bugs against individual language packs get looked at remotely promptly
<cjwatson> though they probably ought to
<slangasek> oh - n/m, this bug was present in the intrepid source and is fixed in the jaunty source, so I guess not a langpack bug in this case
<slangasek> but noted for the future, thanks
<cjwatson> wow, how did partman-crypto ever work
<cjwatson> it's attempting to find UUIDs by looking at the encrypted block device
 * slangasek squints
<cjwatson> "<shuffle> <shuffle> I guess this looks a bit like a UUID, I'll use that"
<cjwatson> this bug appears to have existed since gutsy ...
<cjwatson> bug 321732
<ubottu> Launchpad bug 321732 in partman-crypto "Alternate and Server CD installer fails to create encrypted swap parition" [Undecided,Incomplete] https://launchpad.net/bugs/321732
<Necrosan> cj
<Necrosan> ill pastie now, had some car problems.
<Necrosan> http://pastebin.com/m7c3de64
<cjwatson> though even then I'm confused - this code seems to be supplying a UUID where the encrypted block device was desired. Surely that doesn't work?
<cjwatson> Necrosan: OK, you described the problem incorrectly earlier :-)
<Necrosan> cjwatson: Eh? how'd you interpret it? =P
<cjwatson> Necrosan: aptitude hasn't installed linux-image-sparc64-smp, so there's no bug of the form "installs package without dependency satisfied" here
<cjwatson> Necrosan: instead, what it's done is attempted to install as many of the dependencies of that package as it can
<Necrosan> Oh, a miscommunication.
<slangasek> I'm wondering if that wasn't an unused code path before now; I'm pretty sure I went through partman-crypto to set up my crypted LVM in earlier iterations
<Necrosan> cjwatson: Alright. Good to know.
<cjwatson> which is perfectly legitimate although (to me) surprising
<cjwatson> i.e. the result is still a sound dependency graph
<Necrosan> cjwatson: an FYI, x11 is all messed up on sparc64..
<cjwatson> I'm glad my initial diagnosis was wrong
<Necrosan> Bad...
<cjwatson> Necrosan: noted but I'm not the person to do anything about it :-)
<Necrosan> C'mon, take one for the team ;)
<cjwatson> I'm directly involved with neither X nor sparc
<Necrosan> Is there anyone actively working on the 9.04 build?
<Necrosan> IE, someone to fix the problems before release?
<cjwatson> you've already spoken to the main X developers in Ubuntu
<Necrosan> Ah..
<cjwatson> bryce and tjaalton
<Necrosan> Do either of them  own sparc machines? or do they cross compile?
<bryce> no
<Necrosan> which one, bryce?
<cjwatson> neither is particularly required, since we have sparc build daemons in our datacentre for building binary packages
<slangasek> compiling is done by the central buildds
<cjwatson> Ubuntu developers do not themselves build the binaries you install on your system
<Necrosan> I see. I'm a little unfamiliar with all ofthat.
<cjwatson> we upload source packages which are built centrally
<cjwatson> therefore as long as the source doesn't break, a port can in theory be kept going with very little manual attention
<bryce> I always build packages against at least amd64 before uploading, sometimes i386 as well, but not really anything beyond that
<Necrosan> Pretty slick
<bryce> s/build/test build/
<Necrosan> bryce: The stuff builds fine.. just segfaults.
<slangasek> bryce: presumably not the sunfb package, though. ;)
<bryce> if I were to modify it and upload it, yeah I'd definitely try building it first ;-)
<Necrosan> I had to manually go grab libdrm though, as the package is broken horribly on sparc64..
<cjwatson> slangasek: it seems to give me some kind of UUID when used in encrypted LVM mode, although I have no idea what it represents
<slangasek> hmm, I got nothin'
<cjwatson> maybe the LUKS header
<cjwatson> ah yes
<cjwatson> so it'll work as long as you're using the passphrase key type
<slangasek> asac: hrm; libnss3-1d is using dpkg-symbols, but all of the symbols have been revved to version 3.12.2~rc1?
<slangasek> asac: that's quite a bit of overhead for the same result as a .shlibs file :)
<asac> slangasek: thats a one time thing ... because we flipped SONAME
<slangasek> oh?
<asac> tthe win of this move was that we get back to upstream binary compatibility in both directions
<slangasek> from what I can see, libnss3-1d in hardy already provided /usr/lib/libnss3.so, so there really isn't a need to bump the minver so high in practice
<asac> slangasek: yes, versions for a bunch of symbols were even below the addition of that symlink
<asac> so i hit the reset button.
<slangasek> I don't think I understand
<asac> hmm ... right. sorry misread. i didnt research carefully enough. we probably added the symlink during hardy dev cycle then.
<slangasek> appears so
<asac> but is not really a big issue from what i can tell
<slangasek> anyway, minor issue - I was really looking at bug #272314 and ended up down a rabbit hole :)
<ubottu> Launchpad bug 272314 in update-manager "update-manager disabled multiverse on 8.04 -> 8.10 upgrade (Was: NSPlugin Viewer ERROR: libnss3.so)" [Undecided,Invalid] https://launchpad.net/bugs/272314
 * asac looks with tired eyes ;)
<slangasek> don't worry about it :)
<asac> thats not related ;) ...
<asac> but the min version would still be good to have i think
<slangasek> heh, it's related in that I was looking for a shlibs file to parse mentally. :-)
<TheMuso> asac: Re bug 318985, have you had a chance to try my suggestions?
<ubottu> Launchpad bug 318985 in linux "line-in doesnt work for my HDA NVIDIA device" [Undecided,Confirmed] https://launchpad.net/bugs/318985
<RAOF> Anyone feel like applying a 3.7 MiB debdiff to f-spot for me? :/
<RAOF> Buildsystem changes suck.
 * ScottK steps away.
<TheMuso> RAOF: What build system changes?
<RAOF> TheMuso: Well, there's autoreconf-ing to make it support passing in CSC, for the mono 2.0 transition.  Then, I need to patch it again to make it pick up Mono.Cairo (libmono-cairo2.0-cil doesn't ship mono-cairo.pc).  Then, there were buildsystem changes (accidentally) rolled up in the .diff.gz for -0ubuntu5, which I rolled into 98_autoreconf.
<ajmitch> minor things, only 3.7MB
<RAOF> If it wasn't CDBS I'd have just switched it to running autoreconf during build.
<RAOF> Actually, that still would've been a 3MB debdiff, but at least the next buildsystem change we needed to make wouldn't be so big.
<TheMuso> Right.
 * TheMuso is not sure he wants to take that on atm.
<RAOF> Eh.  Someone will, eventually.  Someone will want both f-spot and banshee to be simultaneously installable.
<ScottK> That takes me off the hook for sure.
<RAOF> Now that some part of it actually works, KDE4 appears to be kinda neat, yes.
<ScottK> Based on some of the ranting I've seen here recently I get the impression that KDE decided on purpose to take a hit and redo a bunch of stuff in order to get to a better future and is now starting to come out of it while this is happening to Gnome bit by bit and it's always something new.
<ScottK> Of course I may just be listening to channel trolls too much.
<ScottK> Since I don't know much about Gnome it's hard for me to tell.
<RAOF> ScottK: Yeah, that's about right.  GNOME's breaking stuff just about slowly enough that not too much stuff is broken at any one time, it seems.
<calc> slangasek: ping
<slangasek> calc: yo
<calc> slangasek: what did we decide about the help support wrt search/cd
<calc> slangasek: dropping help for english off the cd?
<calc> iirc there was the issue of how the user would get it installed
<calc> versus help being broken without lucene
 * calc checks what happens when he removes lucene to see how bad the issue is
<calc> well it appears that 'Find' in Help just does nothing at all if its not there
<calc> no error, no nothing
<slangasek> calc: right, it's not resolved how we would get the help package in later; I think embedding a copy of lucene might be simplest?
<calc> hmm yes, i'll see what that entails, brb
<slangasek> that solves the problem of not being able to recommend: lucene without pulling in the whole java stack; leaving only the "java is missing so things don't work" problem common to the rest of OOo
<calc> slangasek: yea that looks doable, i'll just have to verify it still works after a build
<calc> i don't think it will work for jaunty+1 but i can deal with that later, heh
 * slangasek nods
<calc> ok, well off to start the build and then to bed :)
 * calc wonders why his laptop goes into automatic sleep mode when he unplugs the power cord
<calc> seems like some sort of ubuntu bug to me
<Necrosan> or a feature
<calc> Necrosan: hah
<Necrosan> =P
<RAOF> calc: What does gnome-power-manager think your battery life is like?
<calc> well i am running Gnome so perhaps they do consider it a feature
<slangasek> presumably it's built-in troll detection. :)
<calc> RAOF: 99%
<calc> RAOF: i had to pull the power then bring it back from sleep again to see
<RAOF> So, I guess it's not getting freaked out about low power, then.
<calc> apparently its just braindead
<TheMuso> calc: something to get debugged at the sprint next week.
<calc> TheMuso: yea :)
<calc> hopefully its not a heisenbug, i've seen it happen several times already though
<slangasek> run gnome-power-manager --no-daemon --verbose, capture the output when it does it, and dump it to a bug?
<calc> slangasek: would that actually work since it shoves it immediately into sleep mode?
<slangasek> it'll still be running when you resume
<ajmitch> maybe it thinks your battery is at 1% or so
<calc> ok
<calc> heh heisenbug
<calc> i killed g-p-m then ran it from command line and pulled the power and it was fine
<slangasek> heh
 * ScottK is currently chasing a bug that goes away when you install debug packages.
<calc> i'll have to look at it again later when i reboot
<calc> ScottK: those are fun
<calc> ScottK: OOo has one of those with accessibility
<calc> ScottK: forwarded it to upstream they saw it happened but when building it in debug mode its fixed :\
<ScottK> Right, well OOo is just chock full of insanity.
<dholbach> good morning
 * slangasek waves
<calc> slangasek: hey are you able to sync packages from debian? :)
<slangasek> calc: yes
<calc> slangasek: can you sync suitesparse and lp-solve from experimental for me? :)
<slangasek> what are the chances I'll regret it if I do? :)
<calc> slangasek: hopefully none :) its the new version OOo 3.0.1 depends on
<calc> slangasek: i will be working on breaking up suitesparse later after it syncs (probably at the sprint)
<calc> calc needs lp-solve but only libcolamd from suitesparse
<slangasek> calc: ah; will you continue to leave the lp-solve dep out of OOo for alpha-4, then?
<slangasek> (since alpha-4 comes out during the sprint)
<calc> i can get it broken out early in the week, the issue is calc actually really links to it, so anyone trying to use the solver has a good chance of it blowing up on them currently
<calc> actually i can try to get it done before i leave for the sprint (maybe tomorrow)
<slangasek> wgrant: I've gone and subscribed you to bug #303587, since this bug seems to be fixed by merging from Debian unstable and you appear to have TIL :)
<ubottu> Launchpad bug 303587 in maxima "Error in CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER [or a callee]: Caught fatal error [memory may be damaged] " [Undecided,Confirmed] https://launchpad.net/bugs/303587
<calc> slangasek: does that sound ok?
<slangasek> calc: that seems to imply OOo uploads next week during the sprint so probably not
<slangasek> anyway, suitesparse and lp-solve synced
<calc> ok
<calc> hmm i'll break suitesparse up before uploading tomorrow then
<calc> so it will only need one OOo upload (assuming OOo doesn't show up any other issues) ;-)
<slangasek> that would do nicely
<calc> i'll try to get it done tomorrow morning
<pitti> Good morning
<siretart> mdeslaur: okay, I've now merged the xine package, but I still need to have a look at the tons of dpatches lool added to it. I currently think that all of them have been merged upstream (at least the package builds fine in jaunty), but I need to double check it
<lool> siretart: Cool, thanks
<siretart> lool: what's the status about the broken translation dpatch?
<siretart> lool: I've applied it inline now, but I remember you were talking with darren about it?
<lool> siretart: So basically Darren didn't want to protect strings in xine-lib in this way
<lool> siretart: It's basically assuming that all translations are perfect and you can trust all translators or you review each translation file in full when you merge it
<lool> siretart: So feel free to remove the dpatch for these two strings after the next langpack update in jaunty
<siretart> I don't find that too unreasonable, TBH.
<siretart> ok, I've applied it inline for now, I'll add a note in debian/changelog about that
<lool> I think it's the case of many upstreams so not worth fighting
<siretart> ok
<lool> Concerning the patches to port to new APIs, these should be all upstream I guess
<lool> Finally there's the imagemagick build-deps mess
<lool> I think I changed them in a way which will work in both jaunty and backports, but in the mean time I've readded the imagemagick compatibility packages
<lool> I didn't recheck, but I don't think these should have any bad influence
<siretart> I've dropped them for now, because the package builds just fine in jaunty
<siretart> TBH, the hole merge was terribly painful
<siretart> could you perhaps double check my merge before I upload?
<lool> siretart: Hmm ok
<siretart> (or upload yourself if you are OK? - need to run to work now)
<siretart> hg clone http://hg.debian.org/hg/xine-lib/pkg/xine-lib-deb-ubuntu
<siretart> thanks
<siretart> lool: btw, I've committed your debian/rules cleanup to the debian packaging branchj
<lool> siretart: Thanks
 * lool shivers on mercurial
<LaserJock> lool: not a fan?
<lool> I'm not yet confortable with it
<lool> So it's a pain each time I need to use it
<tkamppeter> pitti, I tried "bzr get lp:~ubuntu-core-dev/cups/intrepid/", commit, "bzr push lp:~till-kamppeter/cups/intrepid" to create a BZR repo of the newest CUPS SRU for you, but the bzr push falls into an infinite loop.
<pitti> tkamppeter: oh? how does that look?
<pitti> tkamppeter: maybe name the branch "intrepid-till"?
<pitti> (it should work with "intrepid", too, but maybe not)
<tkamppeter> pitti, when I look on Launchpad, an empty lp:~till-kamppeter/cups/intrepid is created, telling that there was never pushed anything into it yet.
<pitti> tkamppeter: okay, then that should work; maybe you just didn't wait long enough or so? (should take some 3 minutes)
<pitti> tkamppeter: the branch is visible as soon as it gets created, but the push needs to finish until lp can browse it
<tkamppeter> I have deleted the branch now and I am retrying.
<pitti> tkamppeter: recursive loop> did you get some output, or did it just get stuck?
<pitti> (it usually looks like the latter)
<tkamppeter> pitti, I have also another problem: I have uploaded GS 8.64RC1 yesterday and RC2 today. In both cases they build only on i386 and x86_64, on powerpc, ia64, lpia, ... they do not build.
<pitti> tkamppeter: hm, and it's a non trivial build failure?
<tkamppeter> The error message is the following:
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   freeglut3-dev: Depends: xlibmesa-gl-dev but it is not going to be installed or
<tkamppeter>                           mesag-dev or
<tkamppeter>                           libgl-dev
<tkamppeter>                  Depends: xlibmesa-glu-dev or
<tkamppeter>                           libglu-dev
<pitti> oh, then that needs to be fixed, and the build can be attempted again
<tkamppeter> I uploaded a development snapshot of GS 8.64 last week and it installed without problems.
<pitti> tkamppeter: (don't upload a new version just for a rebuild, that can be done in the web ui)
<tkamppeter> pitti, I know, todays upload was RC2, it was not an attempt to force rebuilding.
<pitti> tkamppeter: right, I know; just mentioning
<tkamppeter> I have posted about this problem here yesterday, too, but no one showed any reaction.
<apw> TheMuso, don't suppose you are about still?
<pitti> tkamppeter: right, it's because mesa failed to build on all those
<pitti> tkamppeter: so don't worry about it for now (mesa should be fixed at least for lpia, though)
<pitti> ^ tjaalton
<pitti> bryce: ^ too
<bryce> pitti: thanks
<tkamppeter> pitti, now my bzr push is transferring, so the repo should arrive before Christmas.
<pitti> *chuckle*
<tjaalton> pitti: yes, lpia has switched to 2.6.28 so it should now build on it
<pitti> tjaalton: oh, shall I give-back?
<tjaalton> pitti: a retry should do
<tjaalton> if that's the same :)
<tkamppeter> pitti, now the bzr push finished, the progress bar was at around 49 %, disappeared, and it said "Created new branch.".
<pitti> yes, sorry
<pitti> tkamppeter: ok, thanks; please just commit to that one then, and prod me to pull from it once you have updates to be uploaded
<tkamppeter> pitti, I have already given back lpia.
<pitti> tkamppeter: won't work, mesa needs to build first
<pitti> tjaalton: kicked
<Mirv> ArneGoetje/mvo: noticed that desktop team would (still) not have time for language-selector. anyway, I'd hope someone could review and import my bzr branch to fix the bug #311228
<ubottu> Launchpad bug 311228 in language-selector "[jaunty] Extra Translations and Writing Aids not installed for the default language" [Undecided,New] https://launchpad.net/bugs/311228
<tkamppeter> I have already committed before pushing, so the changes should already be inside.
<Mirv> it's the last bug people encounter in the flow "install non-English Ubuntu from a CD without a network connection and boot to it (and get language support installed)"
<tjaalton> pitti: thanks
<mvo> Mirv: I have a look
<mvo> Mirv: patch looks fine, thanks a lot
<Mirv> mvo: great that it looks proper, I tried a few more ugly approaches before finding that one
<mvo> Mirv: just to confirm, the old way was that it would have prompted the user about missing translation packs and after the next re-open of the language-selector it would have noticed the missing support packages? this now makes it one go (which is much better)
<tjaalton> pitti: still failed.. I need to relax the dependency on linux-libc-dev for lpia, and maybe other archs too
<Mirv> mvo: (just tested it again). no, it never suggested support packages. ie. after suggesting the basic support to be installed, no matter how many times l-s is opened, it will not offer support packages to be installed for the default languages (ie. there is no cross mark for the default language, only the "half mark" (color, no check)
<pitti> superm1: great work wrt. moving hotkeys out of hotkey-setup! I'm committing everything upstream now
<siretart> lool: regarding hg, if you are happy with my merge, just upload it to the ubuntu archive, I'll import the upload to the hg branch
<siretart> lool: if you have changes and want them committed to the branch, just tell me the url, I'll fetch & push them. otherwise just upload, I'll import them
<lool> siretart: I'm uploading as we speak
<lool> siretart: I resisted doing a trivial change: moving from XS-Vcs-* to Vcs-*
<lool> siretart: I built the source with debuild -i'\.hg|\.hgtags' -S -sa; hope that's fine
<siretart> lool: yes, that's fine. I'm building it with hg-buildpackage -S, but haven't noticed a difference yet
<siretart> just make sure that you grab the orig.tar.gz from debian
<siretart> ah, I'll commit that change in debian, so we'll get that on the next merge
<siretart> pushed
<tkamppeter> pitti, the CUPS SRU is successfully committed. I have checked on Launchpad. I have also proposed to merge it into your branch. So you have probably some click button to merge it in now.
<pitti> bryce, tjaalton: hm, (for bug 311895), it seems that Xorg.0.log doesn't report pipe underruns any more? I still get them, though
<ubottu> Launchpad bug 311895 in xserver-xorg-video-intel "[i945] spontaneous black screen (major pipe-A underrun)" [High,Triaged] https://launchpad.net/bugs/311895
<bryce> heya pitti
<tjaalton> pitti: that's with the current driver?
<pitti> tjaalton: jaunty du jour, yes
<bryce> I think eric may have suppressed some error/warning messages
<pitti> okay; it was useful for counting, but I still see the flickering, so I can still test it
<pitti> I'm currently trying the "FramebufferCompression" "off" suggestion
<ogra> cjwatson, http://www.nslu2-linux.org/wiki/Debian/TroubleShooting ... acording to martin michlmayr the -r and -k options dont work for slugimage or do i read that wrong ? (you use them both in latest d-i)
<cjwatson> ogra: *I* don't use anything
<cjwatson> ogra: that code is straight from Debian, just with numbers tweaked
<ogra> well, the d-i buid does
<ogra> *build
<cjwatson> ogra: I am not going to get involved in debugging this; somebody needs to work out what's wrong and send a patch
<cjwatson> I have already spent far too much time trying to get d-i going on armel
<ogra> i'm not sure i'm reading it right though ... "Don't be fooled by the documentation -- the -r and -k options don't work for Debian-on-slug, because of the APEX bootloader "
<ogra> ok, thats fine (you said yesterday to leave you alone with it ... )
<pitti> Riddell: any idea what to do with the KDE 4.1.4 in intrepid-proposed? only two packges have a bug mentioned in the changelog, so we have no written feedback for them whatsoever
<Riddell> pitti: ScottK was keeping track of them, I believe there is a bug open
<Riddell> although can't seem to find it
<Riddell> mm, no, can't find it, we'll need to wait for ScottK-desktop to wake up
<dholbach> seb128: you were quicker than I was on pochu's vinagre upload :)
<dholbach> mid-air collision :)
<Kaloz> hey. libasound2_1.0.18-1ubuntu3_i386.deb breaks audio on intel hda for me
<Kaloz> reverting to libasound2_1.0.18-1ubuntu2_i386.deb and restarting pulseaudio fixes it
<seb128> dholbach: sorry about the race upload ;-)
<dholbach> no worries
<dholbach> I'll go and do something else now :)
<seb128> dholbach: I'm trying to be responsive on desktop requests when I'm not too busy ;-)
<pochu> dholbach: that explains the reject mail - diff.gz already in the archive ;-)
<dholbach> pochu: yeah
<fabbione> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<fabbione> Connection failed, aborting. Check your network (111, 'Connection refused')
<fabbione> known issue?
<pitti> fabbione: yes, cocoplum is down ATM
<fabbione> pitti: ok thanks..
<fabbione> pitti: do you have an ETA?
<pitti> fabbione: might take a while, thanks to my stupidity we need to recover some files
<fabbione> it's nothing urgent anyway.. just wanna flush the queue :)
<pitti> fabbione: an hour or two perhaps
<fabbione> pitti: no worries man.. i doubt it was your stupidity.. rather your fingers didn't obbey the master :P
<pitti> either way :)
<lool> infinity: Hmm I think we need manual intervention to fix the lpia and probably other chroots to install a newer linux-libc-dev
<lool> infinity: This affects e.g. mesa which has a libdrm-dev bdep which has a versionned dep on linux-libc-dev; mesa failing to build affects a bunch of packages
<DexterF> hi
<DexterF> 8.10 in vmware workstation 6.5.0, linux host: no X driver from vmware tools, won't compile. options?
<superm1> pitti, great thanks
 * ogra pokes pitti in the ribs 
<pitti> ogra: eek
<ogra> heh
<ogra> pitti, i have some touchscreen issues with the latest hal
<ogra> apparently the "touchkit touch" on the Q1 forcefully gets capabilities input.touch*pad* set so hal uses synaptics (which doesnt work)
<ogra> it should either be evdev or evtouch, where does the synaptics suddently come from ?
<ogra> *suddenly
<DexterF> 8.10 in vmware workstation 6.5.0, linux host: no X driver from vmware tools, won't compile. options?
<ScottK> pitti: On 4.1.4 we have two issues we're investigating.  It's working quite well for me and others, but I don't want to say verification is done until we get the issues sorted.
<ScottK> So I think we'll get them verified, but it may take several days.
<ScottK> Riddell: ^^
<ogra> pitti, aha, removing /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi fixes it
<tjaalton> ogra: lshal should show the capability of input.tablet
<ogra> tablet
<ogra> that would be wrong as well
<tjaalton> why?
<ogra> since touchscreen != tablet
<tjaalton> well that's what it's called in hal anyway
<ogra> touchscreen us definately closer to touchpad
<ogra> but it needs to use the right driver
<tjaalton> now it matches 10-x11-input.fdi
<tjaalton> if you remove the synaptics one
<ogra> no, it matches evdev
<ogra> err
<ogra> evtouch
<ogra> let me remove that as well and see if evdev recognizes the taps
<ogra> grrr, if only ctrl alt BS would work now to kill the calibration X server
<tjaalton> well, I don't know what evtouch does to it, but it shouldn't list input.touchpad as a capability
<ogra> well, touchpad isnt to wrong here
<ogra> just synaptics is
<cody-somerville> slangasek, Ugh... the new kernel update prevents Xubuntu users from logging in??!
<cody-somerville> :S
<ScottK> bryce: I was wondering what your thoughts on a SRU for Bug #254468 are?  I can guarantee you lots of testers, starting with me.
<ubottu> Launchpad bug 254468 in xorg-server "MASTER: momentary video garbage upon drawing new objects (particularly in KDE)" [High,Confirmed] https://launchpad.net/bugs/254468
<ScottK> cody-somerville: Should cut down on bug reports then.
<cody-somerville> : P
<tjaalton> ogra: but because it lists input.touchpad (because of some evtouch trickery?) it'll use synaptics
<cody-somerville> charlie-tca, Can you fill me in on what you know?
<charlie-tca> I ran the updates to 7.10 yesterday, about 83 of them installed. When I restarted, I got the GDM login screen.
<charlie-tca> It went into a continuous loop using automatic login, just trying to login
<tjaalton> ScottK: probably not going to happen
<ogra> tjaalton, evtouch doesnt touch any capability settings, it matches only vendor and device names
<ScottK> tjaalton: Why not?  It's a pretty major bug.
<tjaalton> ogra: then the kernel gets it wrong
<ogra> tjaalton, removing it *and* the synaptics fdi doesnt make it use evdev though
<tjaalton> ScottK: I think the performance regression would be greater
<ogra> there is no x11 driver in lshal at all now
<charlie-tca> I logged in through tty, changed to not auto login, and every time I tried to login it just keeps asking for a name and password, never leaving the gdm screen
<ScottK> tjaalton: Apparently we already decided to take that hit for Jaunty.
<charlie-tca> When I start the -15 kernel, it works
<tjaalton> ScottK: yes
<tjaalton> well, for now anyway
<ScottK> tjaalton: So it's been decided the performance hit is acceptable.
<tjaalton> ScottK: I can't see it with current intel stack. maybe radeon is safe too since we are using EXA now
<charlie-tca> Something in the 2-6.22-15-generic kernel is blocking me from logging in through the GUI
<ScottK> tjaalton: Can't see the performance hit or can't see the screen corruption?
<tjaalton> ScottK: neither
<charlie-tca> No, 2.6.22-16-generic kernel is blocking me
<tjaalton> ScottK: it was dropped during feisty, but got added back almost immediately
<tjaalton> I think the legacy nvidia* would be hit the most
<tjaalton> maybe the problem is more evident in KDE.. it never bothered me much
<ScottK> tjaalton: It really has an attrocious affect on KDE.  In addition to looking horrible, it causes hangs.
<Amaranth> Wait, you dropped the "make X go fast but break KDE" patch?
<Amaranth> Put it back, put it back
<ScottK> yep
<tjaalton> Amaranth: why?
<Amaranth> I wondered why I could watch windows redraw again
<tjaalton> Amaranth: on intel? it's not that
<Amaranth> KDE is only broken because they're not doing something correctly I thought anyway
<ogra> tjaalton, creating an fdi file to make it use evdev doesnt make evdev recognize any input events
<ScottK> tjaalton: And if we got to upstream and say "We've patched X to make it suck on KDE, please help us work around it" I don't think we'll get a lot of support.
<ScottK> Amaranth: Tell us what so we can get it fixed.
<Amaranth> ScottK: Did fedora drop the patch as well then?
<ScottK> Currently KDE is fine with an unmangled X.
<tjaalton> ScottK: fedora still has it
<ScottK> Amaranth: I have no idea.
<Amaranth> scottK: the upstream bug report says what to do
<ScottK> Get upstream to accept the patch and then I'll accept it's a KDE problem.
<Amaranth> scottK: Upstream wrote the patch
<Amaranth> Well, ajax did anyway
<ScottK> What's the upstream bug report?
<Amaranth> There is something wrong with the spec I think that causes the problem
<Amaranth> scottK: I dunno, I'd have to find the launchpad one first
 * Amaranth woke up about 30 minutes ago, brain not firing right yet
<tjaalton> Amaranth: so, are you on intel or what?-)
<Amaranth> tjaalton: Yep
<tjaalton> Amaranth: ok, bug 320813
<ubottu> Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813
<tjaalton> caused by vblank
<Amaranth> tjaalton: X3100, vsync disabled in compiz, using UXA
<tjaalton> Amaranth: ah :)
<tjaalton> I don't have problems with UXA, other than X crashes on resume
<tjaalton> oh and the alpha corruption
<Amaranth> tjaalton: Well for me gutsy was the last one to work right
<Amaranth> Most people wish we'd go back to hardy graphics, that was the worst one for me
<tjaalton> intel is in flux..
<Amaranth> Until recently performance in jaunty was pretty good, now it's pretty slow on the desktop yet 3D is nice and speedy
<Amaranth> So it's either UXA is really slow or put it back, put it back (the patch) :P
<tjaalton> Amaranth: please verify that it would help ;)
<ogra> tjaalton, so any suggestions ?
<Amaranth> bleh, the bug report in KDE is on my OtherOS partition
<Amaranth> What is the launchpad bug report for KDE being broken?
<ScottK> Amaranth and tjaalton: We currently have a KDE SRU pending for Intrepid, so if there's a bug that says what needs to change in KDE to work around this patch, please point me at it and I'll see if I can get someone to look into it.
<Amaranth> The one where people are screaming for blood to get the patch dropped :P
<ogra> tjaalton, i see it being configured properly in Xorg.0.log as mouse device now ... but apparently no events are getting through at all
<ogra> (by forcing evdev
<ogra> )
<tjaalton> ogra: sorry, not really.. file a bug with the log and output from evtest
<tjaalton> ogra: might be a kernel bug then
<Amaranth> scottK: There is a KDE bug report where ajax tells them what the patch does, why, and what to do to KDE to work with it
<tjaalton> http://bugs.kde.org/show_bug.cgi?id=170462
<ogra> tjaalton, well, they get through with using the evtouch driver
<Amaranth> scottK: But I have no idea how to find it
<ubottu> KDE bug 170462 in compositing "Video garbage when drawing new object (Comment #54)" [Normal,Resolved: downstream]
<ScottK> OK
<ogra> tjaalton, so i'm pretty sure its in the X layer
<Amaranth> ScottK: You up for adding a major chunk of plumbing to Qt? I hear they accept community contributions now :/
<tjaalton> ogra: then try evtest to be sure
<ScottK> Nope.
<ogra> tjaalton, hrm, why is that in the joystick ackage
<tjaalton> ogra: no idea..
<Amaranth> Qt needs to support _NET_WM_SYNC_REQUEST on initial drawing, not just resizing
<ogra> weird
<Amaranth> Until they KDE is broken on lots of X servers when you use a compositor
<Amaranth> s/they/then/
<ScottK> As the bug says, this patch violates the current design, which is why it isn't accepted upstream.
<ogra> tjaalton, hmm, funny, i see events in evtest
<ogra> and even with the proper coordinates
<ScottK> Now that I've read that, I'm more convinced than ever dropping the patch as a bad hack is the right answer.
<Amaranth> ScottK: It breaks what applications _expect_ the server to do, I don't think it violates the spec
<Amaranth> ScottK: I dunno if SuSE carries this patch but Fedora still does, what do they do to Qt/KDE to not have this problem?
<ScottK> Last I heard they had the problem.
<ogra> tjaalton, so am i right to assume the kernel side is fine if it passes evtest ?
<tjaalton> ogra: probably. file a bug against evdev with all the findings
<ogra> will do ...
 * ogra wonders if the joystick driver would work ... *g*
<ScottK> Amaranth: In the bug report, I find, "<ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast".  That sounds to me like "we don't like the spec so we'll just ignore it."
<ScottK> So the right way is to change the spec.
<ScottK> Not just hack around it and not care what users get screwed in the meantime.
<ScottK> But I guess I'm done.
<bbs> hi -- i'm a programmer -- this is the first time i've used ubuntu on my own system coming from gentoo type system
<bbs> where can i find the vim / emacs/ gedit syntax files
<bbs> so i can program with highlighting
<Amaranth> ScottK: I'd still rather not destroy the performance of everything else
<ScottK> I understand KDE isn't a priority.
<Amaranth> ScottK: There is a clear thing Qt can do here that will fix the problem _and_ make Qt look better on unpatched servers too
<hyperair> where can i get access to ia64 debs?
<Amaranth> ScottK: That is pretty much what I am saying, yes.
<jpds> hyperair: ports.ubuntu.com
<hyperair> jpds: ah thanks. i'll take a look
<Tm_T> Amaranth: without knowing better, doing something that break Qt-related stuff and just point them is not helpful IMO
<jpds> bbs: /etc/vim/vimrc
<Tm_T> Amaranth: point/point at
<Amaranth> Tm_T: Ok then, let's just permanently disable compositing for everyone that way they don't run into the problem the patch is trying to fix.
<bbs> jpds: everything is installed by default?
<bbs> the syntax files
<Tm_T> Amaranth: that's not the solution either (:
<jpds> bbs: You might want to intall vim-full for that.
<ScottK> Amaranth: Fix the design first.
<Amaranth> Tm_T: Or just disable compositing for kwin since that seems to be where the problems are
<Amaranth> ScottK: We can rewrite the core X protocol now?
 * Amaranth goes to do something else
<ScottK> Amaranth: That or carry an out of tree hack forever
<Amaranth> Which one sounds more likely?
<Tm_T> Amaranth: anyway, for this particular case, I don't comment on details until I know what is this all about
<ScottK> Which upstream will never support and we're continually screwed.
<Tm_T> Amaranth: but, just breaking and waiting others to fix is not nice, it can be done more collaborative way too
<Amaranth> ScottK: One of the main upstream developers wrote the patch and maintains it in Fedora
<ScottK> And KDE is still borked there too.
<ScottK> Just because he's an upstream dev doesn't make it less of a hack on the protocol.  He even says as much in that bug.
<Tm_T> ScottK: this is the buffer thing?
<ScottK> Yeah.
<Tm_T> ...no point breaking stuff because of that, until it's properly fixed IMO
<Amaranth> ScottK: It does mean as long as he cares about the performance in Fedora the patch will be maintained by someone else
<ScottK> It's not the maintenance of that patch that worries me.
<tjaalton> Tm_T: we've had the patch for 2,5 years.. now who's breaking what again?-)
<ScottK> It's the knock on effects and getting upstreams to accept change to work around it.
<ScottK> We didn't have KDE4 for that long.
<Tm_T> tjaalton: exactly, its broken at begin with (:
<ScottK> Obviously we aren't going to solve this.
<tjaalton> true
<Amaranth> I consider Qt broken
<Tm_T> Amaranth: I consider too
<Amaranth> So then fix Qt or wait for someone to fix Qt
<Tm_T> tjaalton: anyway, IMO this is the kind of issue that must be taken cautiously, it's not helping anyone to just break things for some people to help performance elsewhere, unless it really is greater benegit
<Tm_T> tjaalton: this in short term, in long term it must be fixed everywhere properly
<Mirv> (tjaalton: nice to know X is crashing for you, too, on resume)
<Amaranth> Tm_T: At this point dropping the patch would be a large regression in performance
<JontheEchidna> then compiz should be fixed!
<Tm_T> Amaranth: how large?
<tjaalton> Tm_T: no-one has been breaking anything, it's been there for a long time
<Tm_T> tjaalton: I know
<JontheEchidna> kwin works just fine without the patch, compiz must be broken
<Tm_T> JontheEchidna: heh
<Amaranth> JontheEchidna: The bug was reported against kwin's compositor?
<JontheEchidna> I'm saying, kwin has no slowdown after removing the patch. If compiz does it must be broken
<tjaalton> JontheEchidna: maybe not with your driver
<Tm_T> tjaalton: Amaranth: JontheEchidna: but anyway, really, thinking compiz or kwin is more important than other is not a solution, we don't like to divide community, do we?
<Amaranth> Tm_T: I'm absolutely only thinking about GNOME/Compiz users
<Tm_T> Amaranth: I know that
<Amaranth> Tm_T: The rest of them either don't have the problem or have always had the problem
<Tm_T> Amaranth: I'm not, because I have to answer to every user, not only those
<Amaranth> Tm_T: If you change the patch we have a regression
<Tm_T> Amaranth: and Qt breaking isn't regression then?
<Amaranth> I think we've had the patch longer then we've had Qt4
<Tm_T> perhaps
<Tm_T> perhaps not
 * Tm_T remembers doing Qt4 stuff for over 3 years now
<Amaranth> I know we've had it longer than KDE 4
<Tm_T> Amaranth: I dealt with KDE4 3 years ago first time
<Amaranth> tjaalton would be able to tell you for sure but I thought we added that patch for dapper
<Tm_T> well -2 month but anyway
<Amaranth> Tm_T: When was it in the archive?
<Tm_T> Amaranth: I have no idea, I do a lot with upstream
<tjaalton> Amaranth: nope, for edgy (Mon,  7 Aug 2006)
<Amaranth> Tm_T: My point is the patch is older then our having KDE4 or possibly even Qt4 in the archive so from an ubuntu point of view KDE4 has always been broken and changing the patch is a regression for others
<Tm_T> Amaranth: could be
<Tm_T> Amaranth: that doesn't mean we as a whole, not you alone, should ignore qt
<JontheEchidna> Qt4 has been in the archives since 2005
<Amaranth> So fix Qt, doubt it'd take more then a week
<Tm_T> Amaranth: anyway, are you willing to wait until qt4 side is fixed?
<JontheEchidna> https://launchpad.net/ubuntu/+source/qt4-x11
<Tm_T> JontheEchidna: thanks
<Amaranth> It'd be a nice test for community involvement in Qt Software
<Riddell> I've filed a task with Qt upstream
<tjaalton> Tm_T: the patch is disabled in jaunty (for now anyway)
<Tm_T> Riddell: thanks sir, bug number?
<Amaranth> Fixing this would make KDE look better on unpatched X as well so it's a win-win
<Riddell> Tm_T: no number until it's public
<Tm_T> Riddell: roger
<Tm_T> Amaranth: true
<Tm_T> Amaranth: that's what I meant by collaborating
<Tm_T> Amaranth: one side soloing isn't helpful (:
<Tm_T> tjaalton: I see, thanks for info, so, are we now evaluating situation or what?
 * Amaranth tries to free up HD space to build X with the patch again
<Tm_T> Riddell: have any our friend trolls been poken about it?
<tjaalton> Tm_T: yes.. nvidia updated their legacy drivers to support the new xserver video ABI, so once tseliot has updated the packages we should know how they are affected
<Tm_T> tjaalton: appreciate all info in the future too, son (:
<tseliot> I'll do it soon
<Riddell> Tm_T: 15:29 < Riddell> I've filed a task with Qt upstream
<tjaalton> tseliot: now! :)
<Tm_T> Riddell: ah, with! thanks
<Tm_T> tjaalton: these issues are messy, I notice
<tseliot> tjaalton: I'll go back in time and since "now" has just passed
<tseliot> s/and//
<tkamppeter> pitti, I have added also the fix for bug 309314 to the CUPS SRU. Can you merge it into the Intrepid CUPS repo? Thanks.
<ubottu> Launchpad bug 309314 in cups "Documents silently fail to print" [Undecided,Fix committed] https://launchpad.net/bugs/309314
<pitti> tkamppeter: did you see my merge request reply? did you pull before?
<ScottK> pitti and tkamppeter: Can we arrange it so all core-dev don't have to get emailed about those?
<pitti> ScottK: I don't know how... I get annoyed by those, too (getting merge requests for firefox etc.), but ATM there's nothing in LP to change that :(
<ScottK> I think there have been some recent changes.
 * ScottK looks....
<pitti> tkamppeter: ah, apparently you did; looks fine, pulled
<ScottK> pitti: https://code.launchpad.net/~ubuntu-core-dev/cups/intrepid/+subscription/ubuntu-core-dev - Unsubscribing the team will, I think, do it.
<pitti> ScottK: I set it to "no email"
<ScottK> pitti: Excellent.
<tkamppeter> pitti, thanks for taking that one in.
<pitti> ScottK: thanks, didn't know about that
<ScottK> pitti: It's a recent development.  A few weeks ago and went and bitched about it in #launchpad and they pointed me at the feature.
<slangasek> charlie-tca: was '7.10' a typo?
<dholbach> slangasek: so... sponsoring :)
<slangasek> dholbach: it was actually less a comment on the sponsoring queue per se, than a repeat of my kvetch from UDS about there being packages in main with authoritative repos that core-dev don't have commit rights to
<dholbach> slangasek: ah, I see - sounds like something we should discuss on the mailing list
<dholbach> slangasek: I don't think that "make ubuntu-core-dev join a bunch of other teams" will help
<cjwatson> the main reason I haven't just added ubuntu-core-dev to the ubuntu-installer team is that I think it would generate a lot of mail
<dholbach> *nod*
<cjwatson> in principle, I think it would be correct enough, actually
<Keybuk> the way this was always envisioned as working was that you had a lp bzr branch that ubuntu-core-dev can commit to, that matches what's in the archive
<cjwatson> perhaps somebody could write up a primer on LP mail handling as it affects team memberships
<Keybuk> and you have a second team branch
<cjwatson> I actually do that for ubiquity
<Keybuk> which the entire mozilla team can commit to
<slangasek> dholbach: I don't think there are "a bunch" of other teams; I know of 4
<dholbach> in an archivereorg + bzr-for-everything world it will be different, I don't know what the best way to do it now
<Keybuk> and when you do releases, you merge from the team branch into the core-dev branch
<slangasek> mozilla, OOo, network-manager, and (apparently) installer
<cjwatson> but I often forget to push to the core-dev branch (I certainly don't want to merge if I don't have to)
<dholbach> slangasek: artwork stuff too
<cjwatson> (I'd rather revision numbers stayed the same)
<dholbach> docs too
<slangasek> dholbach: oh, those don't count because I don't ever commit to them. ;)
<slangasek> though, I think g-p-m is also in this state, now that I think of it
<cjwatson> desktop
<Keybuk> what broke when we set the core-dev mailing address, can anyone remember?
<cjwatson> ~ubuntu-desktop/vte/ubuntu was one I ran into recently
<slangasek> dholbach: anyway - I agree it should go via mailing list; I'm not volunteering to drive this discussion just at the moment.  Was just kvetching. :)
<cjwatson> Keybuk: I think the "matches what's in the archive" constraint is weird, because it doesn't hold if a core-dev not in the team commits something but doesn't think it needs to be uploaded right away
<dholbach> slangasek: kvetching... is that something like czechnology?
<slangasek> if czechnology is Yiddish, then yes
<Keybuk> cjwatson: right
<dholbach> slangasek: no, not really :)
<cjwatson> Keybuk: so the effect of that policy is that the branch is up-to-date for anything core-devs commit, but not for anything that the team most qualified to work on the package is concerned, which seems precisely backwards
<Keybuk> cjwatson: I agree with you there
<cjwatson> Keybuk: which is why I just push ubiquity to the ubuntu-core-dev branch when I feel like it ;-)
<cjwatson> really, though, I'd rather that the branch be "ubuntu-core-dev + ubuntu-installer"
<seb128> slangasek: hello, so the g-s-d changes fix your issue, good ;-)
<Keybuk> branch permissions?
<cjwatson> once they exist ...
<Keybuk> I don't think they are even planned
<cjwatson> if ubuntu-core-dev can have a mailing address set, I can just make it a member of ubuntu-installer and not care
<cjwatson> Keybuk: they are, as part of the distro branch namespace work
<Keybuk> cjwatson: we tried setting a mailing address for it
<Keybuk> it broke some things
<james_w> cjwatson: you would like the branch permissions to be different to the upload permissions?
<cjwatson> Keybuk: i.e. eventually it'll just be ubuntu/+trunk/ubiquity or whatever, and anyone who can upload ubiquity can commit to it
<slangasek> seb128: yep - like magic!
<Keybuk> oh, interesting
<Keybuk> that would certainly fix the problem
<cjwatson> james_w: perhaps, but that isn't required for this; we could just say that some extra people can upload ubiquity
<geser> mvo: about bug 243550: I've just tested your patch, but it doesn't work (for me). gdebi still lists all recommends if I enable recommends again in my host system (I've checked, it's still disabled in the pbuilder)
<ubottu> Launchpad bug 243550 in python-apt "gdebi --root doesn't use the apt config from the chroot but the one from the "host"" [Medium,Triaged] https://launchpad.net/bugs/243550
<cjwatson> we originally moved it to ubuntu-installer because evand wasn't in core-dev but needed to work on ubiquity, and I was fed up merging his stuff on autopilot
<james_w> cjwatson: I think that makes more sense at this point.
<mvo> geser: yeah, thanks for testing it
<mvo> geser: sorry that its not quite there yet, I'm investigating
<cjwatson> I *would* like extended branch permissions at some point, but we could get by without
<geser> mvo: does it matter that I'm still on intrepid?
<james_w> (p.s. lp namespace and branch permissions based on upload permissions are well on the way)
<dholbach> slangasek: here's where I first stumbled over the word: http://jimmac.musichall.cz/log/?cat=31
<mvo> geser: the patch I did initially had some bad side effects,  I need to redo it I think
<geser> should I add my test results to the bug?
<mvo> geser: feel free, but I hope to get a new version up soonish :)
<charlie-tca> slangasek: Sorry, No, 7.10 was not a typo.
<slangasek> charlie-tca: ah.  so cody-somerville was hitting the panic button about a bug in gutsy then?
<charlie-tca> I'm running a fresh install now, to see if it happens again
<charlie-tca> Gutsy is 7.10. We do still support it, right?
<slangasek> there's security support for it.  You're not going to get much support for other bugfixes.
<charlie-tca> So if the kernel won't boot, what?
<charlie-tca> We just tell the user "too bad, it is not a security issue"?
<slangasek> charlie-tca: direct them to the forums for a workaround that will let them upgrade to a version of Ubuntu whose kernel *is* actively maintained?
<charlie-tca> But the update to the new kernel was just this month!
<slangasek> oh?
<charlie-tca> The kernel was upgraded from 2.6.22-15 to -16 and that is what broke
<slangasek> sorry, I thought you were saying that you had just recently upgraded your system to 7.10 from an older release
<slangasek> if it's a regression *in* a security update, yes, that should be tracked down and fixed
<charlie-tca> The -15 kernel will start, the -16 kernel will loop the GUI login screen
<charlie-tca> Once it upgrades the kernel, you can not log in at the GUI
<slangasek> charlie-tca: is there a bug report open for this issue?
<charlie-tca> No, not that I can find. I can file it, though
<slangasek> charlie-tca: please do, and give me the bug number so I can escalate
<charlie-tca> Okay, I will.
<slangasek> also, can you capture an strace of what gdm is doing when it's supposed to instead be logging you in?
<charlie-tca> I can try, but so far none of the logs are showing anything.
<slangasek> I wouldn't expect them to; hence, 'strace'
<charlie-tca> I'll do that
<pitti> Riddell: FYI, bug 297152 is the boost transition thing, and immediate uploads just for this aren't really required (but thanks for your kdepim upload)
<ubottu> Launchpad bug 297152 in linux-ports "boost -> boost1.35 transition / demote gcc-4.1 and gcc-4.2 to universe" [High,In progress] https://launchpad.net/bugs/297152
<Riddell> pitti: yep, found that out
<kees> charlie-tca: that sounds like video driver version mismatch.  did all the other kernel-related packages get updated too?
<charlie-tca> yes, to the best of my knowledge
<Kano> hi, could syslinux upgraded to 3.72 to use hybrid iso mode of isolinux?
<Kano> or newer... like in experimental
<Kano> 3.73
<kees> charlie-tca: when you've got a bug #, let me know, and I can poke around at it.
<Kano> then you could call isohybrid on the created iso image
<soren> Kano: What would that do?
<Kano> well you can cp the iso image 1:1 onto hd or usb stick
<Kano> and it is bootable
<Kano> like that moblin iso, which is created that way
<soren> I'm almost certain we can already do that.
<Kano> you have got a pretty bad installer for usb stick
<soren> I've done some testing of extboot in kvm that suggests that that is the case, anyway.
<soren> Kano: Perhaps I'm not fully understanding what you're saying.
<cjwatson> simply changing the way the image is written to the USB stick would not change the other problems with running from a USB stick in any way, and those are more urgent.
<cjwatson> generally speaking upgrading syslinux is a complete pain to do because we have to upgrade the gfxboot patch as well
<Kano> soren: cp image.iso /dev/stick
<Kano> is what you do, then you can boot it
<cjwatson> so I try to avoid it whenever possible. If you want it faster, send a fully-tested patch that preserves all of the things we use
<soren> Kano: I'm 99% sure that works now.
<Kano> cjwatson: why dont you use the standard routines?
<cjwatson> Kano: because people screamed at us until we did gfxboot
<cjwatson> and it's a pain to change now
<Kano> syslinux has nice gfx support
<cjwatson> soren: no, you have to use usb-creator
<soren> Kano: But I appear to be wrong.
<cjwatson> Kano: it's different, and would require substantial porting. I will not be harangued by you about it, I'm afraid
<cjwatson> and it didn't have any of that support when we first added gfxboot
<Kano> vesamenu
<cjwatson> would require substantial porting work
<cjwatson> read my lips
<cjwatson> it's not just as simple as saying that the facilities exist
<cjwatson> I would get shouted at if I made it look less pretty
<soren> cjwatson: Hm... That is interesting, actually. I had a libvirt bug once where Fedora CD's failed to boot. The conclusion was that due to some misunderstandings between libvirt and kvm, we were booting the CD's as though they were hard drives, and for some reason, Ubuntu and Debian CD's worked fine, but Fedora ones didn't.
<cjwatson> which I think is pretty shallow, but that's not my problem
<cjwatson> soren: they might use some different bootloader on their CDs, e.g. grub
<calc> i have a question i am modifying suitesparse to break a library out and it uses cdbs, how do i make it link automatically to the other package (being produced at the same time) or should it know how to do that already and something possibly broken?
<cjwatson> right now, we depend very extensively on the customisations that have been applied to gfxboot
<Kano> which are not working with pxelinux btw.
<calc> iirc dh_shlibdeps (or something like that) is supposed to do it, but i thought cdbs does this automatically?
<soren> cjwatson: I think they also used syslinux, but ICBW. Anyhow, this sheds new light on the issue.
<cjwatson> Kano: yes, I am aware that gfxboot doesn't currently work with pxelinux; there is a bug about it
<cjwatson> nobody has sent a patch yet AFAIK and I haven't had time to dust off my assembler and figure it out
<Kano> could you put that into a module?
<cjwatson> put what into a module?
<Kano> your gfxboot hack
<cjwatson> it's not my gfxboot hack, it's SuSE's
<cjwatson> ask them, I'm not interested in that level of work on it
<Kano> i know that gfxboot is from suse
<cjwatson> nor do I think I would do a good job on it
<TheMuso> 8/c
 * ogra really wonders how "cp image.iso /dev/stick" would work though ... 
 * calc thinks he found the issue
<ogra> are you sure you didnt mean dd ?
<Kano> ogra: you can use dd, cat or write your own app, all would work
<cjwatson> our gfxboot customisations are in gfxboot-theme-ubuntu, which is written in gfxboot's own interpreted language. They would not make a lot of sense as a standalone syslinux module
<ogra> but not cp ... thats what confused me
<Kano> cp too
<Kano> no diff
<cjwatson> cp image.iso /dev/stick => replace the /dev/stick device node with a regular file
<Kano> just dont forget sysnc
<Kano> sync
<cjwatson> hmm, that's interesting, cp foo devicenode does actually appear to write to devicenode
<ogra> hmm, i always thought you had to pipe a binary stream to it ...
<calc> yep got it working
<ogra> which is what cat and dd would do
<cjwatson> I take it back
<ion_> cjwatson: echo foo >foo >bar; strace cp foo bar: cp just open()s bar for writing and write()s to it.
<cjwatson> yes I already did
<slangasek> calc: should already do it automatically; is it not working?
<slangasek> calc: oh, scrolling down, n/m
<slangasek> :)
<Kano> btw. when you use: default vesamenu.c32
<Kano> then you see at least the logo and have got a menu
<Kano> of course you have to put that module on the iso
<calc> slangasek: i found the problem it uses a .symbols file i forgot to update
<calc> slangasek: so it was claiming the symbols were in the wrong file
<slangasek> aha
<slangasek> :)
 * calc notes he isn't sure how good a feature that is ;-)
<slangasek> dpkg-gensymbols has an option to make it complain if there's a mismatch
<slangasek> hmm, except the levels are wrong, warning if libraries have disappeared should be a lower level than warning if symbols have been added
<slangasek> doh
<slangasek> charlie-tca: have a bug number yet for us? :)
<DexterF> does ubuntu 8.04 support the GeForce 8x00 chipsets out of the box or is there a backported kernel that does?
<directhex> DexterF, are you talking plug-in gpus, or motherboard chipsets?
<DexterF> directhex: chipsets
<directhex> DexterF, you be wantin' Envy.
<directhex> envyng-gtk package
<DexterF> uh... no, *not* gpus - chipsets. sATA ports, usb and such.
<calc> the nvidia geforce 8300 chipset came out after 8.04 so probably not supported i would imagine
<DexterF> there goes that plan
<DexterF> any backported kernels available?
<calc> afaict it wasn't even reviewed by sites until ~ July 2008
<calc> DexterF: 8.10 might support it
<DexterF> not an option
<directhex> sata ports should be AHCI these days shouldn't they?
<directhex> USB hasn't changed for about a decade
<calc> the newest kernel in hardy is 2.6.24-23.46
<DexterF> all irrelevant if the chipset is unsupported
<calc> DexterF: you could try booting a live cd and see if it works
<directhex> i don't think you know exactly what "the chipset is supported" means though
<DexterF> system is in planning stage right now
<DexterF> directhex: in order to talk to the board components the chipset has to be supported by the kernel. it's quite obvious I'd say
<calc> but yea in general its not a good idea to buy a chipset newer than the version of linux you want to run on it ;-)
<DexterF> dang I need a board with nvidia based onboard video...
<directhex> you'd be wrong, though. the chipset's individual components, as reportsed to given busses, is what matters
<DexterF> the old 7050 work fine I know but I need a *tad* more punch
<calc> directhex: i don't know if its as problematic as it used to be but generally linux has had to add quirks, etc for new chipsets
<directhex> so whilst sata_nv might be too old, as an example, EHCI is EHCI and usb2 will just work regardless of vintage
<calc> DexterF: so why is it you have to run 8.04? :)
<directhex> version matching for mythtv at a guess
<calc> DexterF: even if there was a backported kernel you would have to somehow get the machine bootstrapped probably on another machine before upgrading the kernel
<DexterF> friend's machine, 8.10 means kde4 which I can't support because I don't use it. kde4 quite frankly and imo sucks wet farts from dead pidgeons
<calc> DexterF: you could try installing just the kernel from intrepid or jaunty i suppose
<directhex> calc, nah, too much changed
<DexterF> hmm, manually backport, eh?
<calc> directhex: oh? need new userland for them?
<directhex> and building ubuntu kernels manually sucks
 * calc is running jaunty kernel on intrepid, but hasn't run hardy in a long time
<directhex> calc, lots of things changed around, so you'd lose the entire support structure for, say, nvidia graphics drivers
<calc> directhex: ah ok
<DexterF> i see where this is going
 * calc avoids nvidia due to their stance on floss ;-)
<DexterF> if that fglrx drivers wasnt that crappy I'd go for a 780G board...
<directhex> in the end, ubuntu has a particularly bad mechanism for supporting new hardware in old LTS releases
<calc> well thats not completely true i run nvidia card with the nv driver because ati at the time had no fanless dual dvi cards i could find
<calc> DexterF: intel ftw :)
<DexterF> calc: $$$-issue. not applicable. that is.. wait. hm. the X3100 series packs a punch in terms of integrated video, right?
<directhex> depends. what do you want it to be able to do?
<directhex> games are right out
<calc> intel cpu can be really cheap eg the c2q 8300
<calc> and are much faster than amd
<calc> but yea no gaming on them, probably not too good gaming on any integrated chipset really
<calc> some can run games only 5 years old instead of 10 ;-)
<calc> DexterF: the one good point about amd is that there are open drivers in active development with specs so you are less likely to get bitten by ugly nvidia bugs
<charlie-tca> slangasek: no, not yet. I'm trying to verify it on another system first.
<calc> like not being able to see text on menus in applications
<slangasek> charlie-tca: well, even if it's only reproducible on a single system, regressions in security updates are a critical issue
<ogra> pfft, menus are overrated anyway
<directhex> i wonder whether intrepid will install on my new pc, once i get the broken motherboard issue solved
<directhex> i was surprised enough that it worked on this laptop
<calc> DexterF: but no fglrx is not the open driver :)
<calc> i'm waiting to buy a new computer until ~ dec/jan at the end of the year
<DexterF> calc: I fell for ATi PR chatter for five f?!*ing years, I hardly have adequate words for how through I am with their video cards
<slangasek> so is libxcb upgrading ok for folks now on jaunty, as opposed to being held back in update-manager?
<slangasek> (I already forced the upgrade on my system, so don't have a convenient test case anymore)
<calc> DexterF: phoronix has articles about the work, it has taken a few years to get them running (aiui)
<calc> DexterF: and nvidia still has no real open source drivers at all after claiming they would help floss over 10 years ago now, so ymmv ;-)
<directhex> DexterF, i benchmarked it about 5 years ago. ut2004 performance, Â£100 geforce ti4200 versus Â£300 ati 9800 xt... guess which was 3x faster than t'other :)
<superm1> calc, was it ever discerned if that was a driver bug, or did it only happen with compiz running (and is possibly a compiz implementation bug?)
<superm1> i remember hearing about it a long time ago, but never followed it
<calc> i was in a discussion with nvidia (iirc on irc) back around 1998
<calc> superm1: aiui it only happens on nvidia so it is almost certainly their bug
<DexterF> I've been monitoring the open drivers dervelopment lately and from what I saw/heard full featured stable drivers are *way* in the future, 2010 perhaps when everything current is more outdated than socket A boards and don't get me started on moronix' fanboi drivel
<calc> superm1: but i don't know the current status
<directhex> DexterF, phoronix mean well, they just don't really understand how to benchmark things properly
<DexterF> they are fanbois
<superm1> calc, well it only happens with them doesn't mean it's "their" bug, it still could just be that their driver emphasizes a bug with a lower layer.  i know that was happening with gnome screensaver a release or two ago
<DexterF> each time I glimpsed in it was "NEW!! ATi free drivers now *even better!!"
<superm1> in this case turned out to be a compiz bug
<DexterF> yeah, like: it doesn't crash now when changing resolution or such
<directhex> DexterF, you don't think that counts as "even better"? :)
<calc> DexterF: well if you do go with nvidia do realize your hardware is going to become unsupported in the not too distant future, just look at the list of drivers for nvidia in ubuntu, we have to maintain 5 sets of drivers because nvidia dropped support for older cards at various times
<DexterF> I switched to nv finally and while I'm aware of the perf issues I can't describe how happy I am with that evil closed src driver
<calc> DexterF: we have 71, 96, 173, 177, 180
<DexterF> speaking of which: I _don't_ habe 180 in 8.04. any way to get it? I'd like the perf extra plus...
<calc> back when i used nvidia it would always crash when i tried to switch to console
<directhex> DexterF, sure. don't be 8.04
<DexterF> kde4 still = teh suck
<directhex> calc, anyway, i have similarly bad glitching on intel
<Riddell> DexterF: can you stop flaming please
<calc> DexterF: xubuntu? :-)
<DexterF> Riddell: k
<directhex> calc, if i allow usplash to use its default resolution, i can't switch to a console after x starts
<calc> directhex: ah ok
<directhex> calc, and sadly usplash doesn't correctly work with widescreen
<calc> directhex: luckily we'll be rid of usplash with 9.10
<ogra> directhex, until them patches are hapily accepted ;)
<ogra> *then
<directhex> ogra, i had a look at the code, and ran screaming
<directhex> ogra, both at the code and at the idea of telling mjg59 that something sucks
<ogra> directhex, just call it a challenge ;)
<DexterF> calc: I'd like nv to port over the old stuff, too, yes, just pointing out everything works with those. 3D, Xv... with ATi couldn't get even decent Xv.
<directhex> DexterF, ati sorta kinda got xv support in driver 8.5 or so
<calc> DexterF: nv can't since nvidia refuses to give out any documentation at all
<calc> DexterF: the ati drivers are better because amd released nearly full docs
<DexterF> directhex: fglrx had Xv ever since, only problem was serious artifact issues over month they didn't solve. last time I checked was... mmh... 8.3 or 8.4.
<calc> DexterF: they won't even release documents for the nv01
<DexterF> calc: yeah, sad story. thing is they dont really need to.
<directhex> calc, zomg trade secrets!!!
<calc> DexterF: yea what with intel having more market share than them ;-)
<DexterF> ?
<calc> DexterF: nvidia isn't in a market dominant position so probably should be releasing documents
<calc> their stock price is less than 1/4 what it was a year ago
<calc> they had product recalls that nearly killed them as well
<DexterF> didn't know about the stock thing. well, I guess their main interst is windows gamers. I came to think ATi made the open src move because they were desperate before the 48x0 series rolled in real cash
<calc> iirc intel has the vast majority in the market for video chipsets with ati and nvidia trailing fairly far behind
<directhex> the real cash is in OEM sales
<calc> DexterF: not really before the amd buyout even finished they had already announced they were going to release the documents
<DexterF> calc: intel? Oo
<calc> directhex: yea and that is where nvidia has been having trouble, esp with all the bad parts
<calc> DexterF: in the past there have been graphs published showing the breakdown of the market between the vendors
<calc> slangasek: i think the new suitesparse i uploaded might be stuck in new
<calc> slangasek: i haven't received an email about it yet though, it has a new binary package
<slangasek> did you get confirmation of the source upload?
<slangasek> yeah, I see the binaries in new; processing
<calc> slangasek: not yet
<TheMuso> Keybuk: Afaik you are working on initramfs-tools. Are you likely going to upload soon, or is it safe for me to do an upload today?
<calc> slangasek: thanks :)
<slangasek> calc: oh, the binaries I see are from 3.2.0-1, which is the one we synced - if there's another upload, I don't see it
<calc> yea a 3.2.0-1ubuntu1 upload
<Keybuk> TheMuso: I'm not doing any work on initramfs-tools right now
<calc> slangasek: hmm maybe i should try uploading again
<TheMuso> Keybuk: Ok thanks.
<slangasek> calc: doesn't show up on https://launchpad.net/ubuntu/+source/suitesparse, so if it's been more than 15 minutes, yeah probably
<calc> slangasek: ok
<calc> slangasek: should it show up there even if it is new? btw i just uploaded again
<slangasek> calc: yes, the source should show up there.
<calc> ok
<calc> once i see it finished building i'll let you know for the new processing bit
<superm1> tseliot, tedg should we be pulling in http://svn.gnome.org/viewvc/gnome-power-manager?view=revision&revision=3167 to fix the high CPU usage bug on gnome power manager? does jaunty have RR1.3 yet so we could do that?
<superm1> (bug 307306 for reference)
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306
<maxb> superm1: I'm running with that patch locally - it works, and helps, but doesn't completely fix things (as per my later comments in the bug)
<superm1> maxb, considering it's upstream, perhaps we should pull it in then to at least get the behavior improved until a final resolution is found.
<maxb> It would undoubtably be appreciated by people testing Jaunty on problem setups who haven't done local builds.
<superm1> maxb, have you explored at all, do you have any idea why there are so many randr calls happening in the first place?
<Amaranth> You mean X will stop chewing 50% CPU for 3 minutes after gnome-power-manager starts soon? :)
<maxb> Unfortunately my X-fu is insufficient
<Amaranth> superm1: The call they are making used to return a cached result, now it probes
<maxb> I'm hoping the log I posted will mean something to someone
<Amaranth> And apparently GDK sends the "monitors-changed" signal when you change the brightness which is broken
<superm1> Amaranth, so who is really to blame then and should be fixed? GPM to cache the result and/or make it less frequently?
<Amaranth> superm1: There is another function they can use to get the cached result in randr 1.3
<superm1> Amaranth, is that the call that was added in the patch i posted above, or you are meaning a different one yet?
<Amaranth> superm1: probably that one
<superm1> Amaranth, "XRRGetScreenResourcesCurrent" ?
<Amaranth> yep, that one
<Amaranth> gnome-settings-daemon needed patched as well, iirc
<superm1> okay well i'll get this into an upload to GPM then, it's upstream already, and way annoying.
<Amaranth> oh, the gsd one was actually in gnome-desktop which we have already
<calc> slangasek: i uploaded suitesparse again 30m ago and i still haven't received an email and its not showing up on LP, any ideas?
<slangasek> calc: see other channel where you've been highlighted. :)
<slangasek> there are some delays right now with package accepts
<tseliot> superm1: my patch for g-p-m is ok but we still need other two patches for gnome-control-center. And yes we have randr 1.3
<calc> slangasek: thanks :)
<tseliot> superm1: we're discussing with upstream on the patches for gnome-control-center here: http://bugzilla.gnome.org/show_bug.cgi?id=568160
<ubottu> Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Resolved: fixed]
<mohbana> am i the only one who is experiencing a really slow file browser (the gnome one)
<mohbana> yet the  kde file explorer - dolphin - is very fast
<mohbana> it's very noticeable
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 23:00 UTC for a code update | Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/Helpi
<thinkgnu> which one is better for my system (dual core2  , 1GB ram) ?  kubuntu32 but or kubuntu64 bit ?
<Riddell> thinkgnu: user questions in #kubuntu
<thinkgnu> :D
 * directhex smiles sweetly at tseliot and superm1, asks gently about nvidia 180.22 in intrepid
<tseliot> directhex: I'll work on it tomorrow
 * directhex offers tseliot a muffin
<tseliot> directhex: keep an eye on https://bugs.launchpad.net/bugs/322416
<ubottu> Launchpad bug 322416 in nvidia-graphics-drivers-180 "update request: nVidia ver 180.25, stable" [Medium,In progress]
<directhex> can't find 180.25 on nvidia.com :/
<directhex> at any rate, wanna be sure my new pc works, when i eventually get a fixed motherboard ;)
<superm1> tseliot, okay i pushed the GPM patch in, so that should be some improvement at least.  thanks for writing it :)
<tseliot> superm1: great, thanks
<calc> slangasek: can you process suitesparse now, or does it have to be built on all archs (for the new processing bit)
<calc> its still working on armel/hppa
<charlie-tca> slangasek: bug 322497
<ubottu> Launchpad bug 322497 in linux-source-2.6.22 "gutsy 7.10 will not login after updating to kernel linux-source-2.6.22.16 *regression*" [Undecided,New] https://launchpad.net/bugs/322497
<charlie-tca> could not reproduce on two different systems with fresh installs
<ScottK> charlie-tca: I'm having similar symptoms on 8.10 right now.
<ScottK> charlie-tca: If you do a console login does df -k say there's no space left?
<charlie-tca> I'll go look
<charlie-tca> This just started on 7.10 after the latest kernel update
<charlie-tca> ScottK: no, mine shows lots of space left; over 40% unused
<ScottK> charlie-tca: And it shows block in the available column?
<charlie-tca> yes
<ScottK> OK.  Then I've got a different problem.
<charlie-tca> yeah, quick glance shows it about right, too
<ScottK> Mine is basically no user level ability to write to disk because it thinks it's full.
<ScottK> I can write as root and delete as user, but writes as user fail.
<charlie-tca> I see. This is different.
<ScottK> If anyone has thoughts on that, I'm all ears.
<slangasek> calc: if I make it before the LP maintenance it can be, sure
<calc> slangasek: ok
<slangasek> kees: ^^ seen bug #322497?
<ubottu> Launchpad bug 322497 in linux-source-2.6.22 "gutsy 7.10 will not login after updating to kernel linux-source-2.6.22.16 *regression*" [Undecided,New] https://launchpad.net/bugs/322497
<slangasek> charlie-tca: thanks, fixed up the bug state
<calc> "Launchpad will be going offline for maintenance very very soon." lol
<kees> slangasek: I'll check in a moment... doing kernel updates.  ;)
<slangasek> sure
<charlie-tca> You're welcome. I hope there is enough there to count
<kees> slangasek: will you be around after LP is back to do some pocket-copies for me?  (kernel updates from -security to -updates)
<slangasek> calc: should libsuitesparse-dev have a dep on libcolamd-3.2.0, given that it ships the .so for it?
<slangasek> (it currently depends indirectly)
<slangasek> calc: anyway, LP maintenance window hit before I got a chance to accept it; will try again in an hour
<calc> slangasek: ok np
<calc> slangasek: not sure wrt your question, i saw it was getting pulled in by libsuitesparse-3.2.0 already so just left it at that
<calc> slangasek: apparently this will probably be fixed in debian soon as well, so we hopefully will be able to go back to syncing in the near future
 * slangasek nods
<cody-somerville> slangasek, Hows that Xubuntu killing bug going?
<slangasek> cody-somerville: it's been filed and the security team is in the loop
<kees> slangasek: you've meaning 322497?
<slangasek> yes
<slangasek> charlie-tca: why are all of these vboxsf mounts happening at login time?
<slangasek> charlie-tca: and I bet you don't have a virtualbox-ose modules package to match your kernel, because vbox isn't in main so didn't get updated with the kernel security release
<slangasek> charlie-tca: also, please check for gdm output in /var/log/auth.log; the strace shows some of it being written, but it's truncated because I didn't ask you to use -s :)
<charlie-tca> The virtualbox came direct, I ran /etc/init.d/vboxdrv setup to update it.
<slangasek> ok
<slangasek> [pid  4995] 07:36:56.235593 writev(2, [{"gdm[4995]: PAM adding faulty mod"..., 71}, {"\n", 1}], 2) = 72
<charlie-tca> I don't know why all the mounts happen at login
<slangasek> that looks promising; pam_gnome_keyring.so is referenced but absent
<charlie-tca> you're right about /var/log/auth.log
<charlie-tca> let me get a copy out
<charlie-tca> slangasek: added the auth.log to the bug report
<slangasek> thanks
<charlie-tca> Thank YOU. I know you are very busy
<calc> how often do packages get put in the archive (eg ACCEPTED -> DONE)?
<slangasek> charlie-tca: could you please confirm that 'grep pam_gnome_keyring /etc/pam.d/*' returns only 'optional' lines?
<charlie-tca> how?
<slangasek> charlie-tca: well, regressions in security updates are kind of a priority
<slangasek> charlie-tca: run the command 'grep pam_gnome_keyring /etc/pam.d*', and tell me if there are any lines that don't say "optional"
* mthaddon changed the topic of #ubuntu-devel to: Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | this week: https://wiki.ubuntu.com/UbuntuDeveloperWeek
<charlie-tca> slangasek: no lines at all
<charlie-tca> nothing comes up
<slangasek> er, oops, wrong command
<slangasek> charlie-tca: grep pam_gnome_keyring /etc/pam.d/*
<charlie-tca> slangasek: two lines, both with 'optional'
<slangasek> ok
<slangasek> so it doesn't appear to be an authentication failure
<slangasek> charlie-tca: I notice that the PIDs from the logfile and from the strace don't match; I guess they're from two different tests?  (it probably doesn't matter, just want to be sure)
<charlie-tca> yes
<cjwatson> calc: hourly
<charlie-tca> I been in there so many times I got confused
<slangasek> charlie-tca: the problem is in /etc/gdm/PostLogin/\:0 - could you send a copy of that file to the bug?
<charlie-tca> slangasek: sure, let me get it.
<slangasek> this is the script that's trying to do all of the vboxsf mounts; it's the only thing run between the 'session opened' and 'session closed' lines, and there are a lot of failures, with the script eventually exiting non-zero
<slangasek> so this still points back to a vbox problem, ultimately
<charlie-tca> slangasek: Oh, no. Do I just pull that and try to login, then?
<charlie-tca> Oh, sent the :0 file to the bug report
<slangasek> charlie-tca: you could try that, yes
<slangasek> charlie-tca: alternately, you could change the 'exit' at the end of the script to an 'exit 0'...
<calc> cjwatson: ok
<charlie-tca> slangasek: I renamed the file, it did not allow the primary user to log in, but did allow another one.
<charlie-tca> Is this all my fault, then?
<cjwatson> calc: (this is aside from all the problems there've been specifically today of course)
<slangasek> charlie-tca: well, as far as I can tell the login failures were the result of your local PostLogin script; but the reason for that script to start failing may still point to a regression that should be addressed
<charlie-tca> I lied. wrong system
<calc> cjwatson: ok, i see it got marked as done, i guess it takes a while after that for it to show up on archive.u.c?
<slangasek> yes, it's marked as 'done' at the very beginning of the publisher run
<cjwatson> calc: yes - the bug is closed at the ACCEPTED->DONE transition, but that's actually at the ... what slangasek said
<calc> slangasek: ah i see :)
<slangasek> and the publisher run lasts ~1h
<charlie-tca> slangasek: I haven't changed that script in a very long time.
<calc> well sometime tonight i should have new OOo in after its deps get finished anyway ;-)
<slangasek> charlie-tca: sure.  I think your virtualbox-ose setup is broken following the kernel ABI change, which may be an Ubuntu issue
<slangasek> charlie-tca: did I understand you to say that you weren't using the virtualbox-ose packages from the archive...?
<charlie-tca> slangasek: Okay, it does allow login with out the script.
 * slangasek nods
<TheMuso> superm1: Re bug 32250, do you think that could have anything to do with the missing kernel hid quirk modules from the initramfs? I uploaded an initramfs-tools earlier to add the hid quirk modules.
<ubottu> Launchpad bug 32250 in gnome-power-manager "g-p-m critical power warning states "will power-off" which is misleading" [Medium,Fix released] https://launchpad.net/bugs/32250
<TheMuso> sorry sorry bug 322506
<ubottu> Launchpad bug 322506 in busybox "Caps lock doesn't work in initramfs environment" [Undecided,New] https://launchpad.net/bugs/322506
<TheMuso> superm1: ^^
<cjwatson> caps lock has occasionally been a source of console-setup-related glitches
<slangasek> charlie-tca: it should also allow login if you put the script back, but edit the last line to say 'exit 0' instead of 'exit'; that can be a permanent change to make the script more robust, then we can focus on debugging your vbox problem
<cjwatson> is this consistent across keyboard layouts?
<cjwatson> superm1: attaching /etc/default/console-setup would probably be a good thing, as well as confirming that that file is also present in the initramfs
<charlie-tca> slangasek: I am running virtual peul. It is not virtualbox-ose
<charlie-tca> virtualbox peul
<charlie-tca> I installed it before virtualbox-ose was in the repositories, and the system has been upgraded to 8.04
<TheMuso> cjwatson: ah ok.
<Hobbsee> hrm.  Preseeding packages won't get their recommends, will it?
<slangasek> charlie-tca: ok.  what does 'lsmod | grep vbox' give you?
<cjwatson> bug 281940
<ubottu> Launchpad bug 281940 in tasksel "Debian-installer can't be (and isn't) told not to install recommends by default." [Wishlist,Confirmed] https://launchpad.net/bugs/281940
<cjwatson> err, no, maybe not that one
<charlie-tca> slangasek: nothing
<slangasek> charlie-tca: output of find /lib/modules -name 'vbox*.ko', please
<cjwatson> I'm sure there was a bug about allowing pkgsel/include to install recommends
<cjwatson> oh, I can't find it because Timo fixed it :) bug 315363
<ubottu> Launchpad bug 315363 in pkgsel "add an option to install "Recommended" packages too" [Wishlist,Fix released] https://launchpad.net/bugs/315363
<cjwatson> Hobbsee: on jaunty, pkgsel/install-recommends=true tweaks it; on earlier releases, no
<charlie-tca> slangasek: 2 lines, '/lib/modules/2.6.22-15-generic/misc/vboxvfs.ko'
<slangasek> charlie-tca: the other line?
<charlie-tca> '/lib/modules/2.6.22.14-generic/misc/vboxvfs.ko'
<Hobbsee> cjwatson: ah, excellent, thanks.
<charlie-tca> '/lib/modules/2.6.22-15-generic/misc/vboxvfs.ko'
<slangasek> charlie-tca: yep.  So, you need to rebuild your peul kernel module for the new kernel
<charlie-tca> same line with -14
<slangasek> charlie-tca: presumably you had to do this before for the -14 -> -15 update
<charlie-tca> I sure don't remember it, but you are most likely correct.
<slangasek> charlie-tca: so it's not actually a regression in the linux security update, but the vbox folks should provide an updated virtualbox-ose-modules package for gutsy as well; I've fixed up the bug to reflect that
<charlie-tca> Thank You. I'll go rebuild it then.
 * Hobbsee invalidates a bug, claims it for 5-a-day
 * directhex opens 5 bugs for Hobbsee to close
<Hobbsee> directhex: darn you ;)
<RAOF> Hobbsee: Like to add making f-spot installable with monodevelop, banshee, et al your next bug?
<Hobbsee> RAOF: not overly, but nice try ;)
<pwnguin> how 'bout eclipse 3.4? ;)
<Hobbsee> not that crazy...
<RAOF> All it needs is for you to apply a debdiff.  Nice and simple :)
<pwnguin> RAOF: speaking of closing bugs, what should we do about bugs against nv?
<pwnguin> ask them to retest on nouveau?
<RAOF> nv is still maintained by a guy at nVidia.
<RAOF> Feel free to ask them to check on nouveau; that'd probably be useful/nice.
<RAOF> But we're not replacing nv with nouveau for Jaunty.
<pwnguin> does nv support anything nouveau doesn't? obviously it might be buggy, but that "guy at nVidia" seems to dislike features
<pwnguin> so long term i'd imagine a replacement is going to happen. (certainly not for jaunty)
<RAOF> "That guy at nvidia" really doesn't like features, no.
<RAOF> nv probably supports some newer cards than nouveau does; nouveau apparently doesn't support nv9x chips at the moment.
<slangasek> who can blame him, no good has ever come of features
<slangasek> ;)
<pwnguin> RAOF: if you have a nv9x chip, it's probably connected to a display that nv wont drive properly
 * RAOF rather likes the fact that nouveau actually dithers for his laptop's 18bit LCD properly.
<pwnguin> but there's not really a point to debating this
<pwnguin> im not arguing for the removal of nv
<RAOF> Debating?  Feel free to suggest people test nouveau.
<RAOF> If it drives their card, it'll almost certainly be better than nv.
<pwnguin> RAOF: what if a bug comes in against nv, is confirmed broken, the tester tries nouveau and drops nv entirely?
<pwnguin> do we leave the bug open?
<RAOF> I'd say yes.  It's still a bug in nv, and nv is still our default nvidia driver.
<pwnguin> i kinda wonder how often nv is used in practice
<RAOF> Everytime someone with nvidia hardware loads a livecd, certainly.
<pwnguin> good point
<pwnguin> RAOF: perhaps an invitation to test should be published, so people know it's available?
<RAOF> That sounds like a job for ReleaseNotesâ¢
#ubuntu-devel 2009-01-29
<directhex> yes, because everyone reads the manual
<directhex> :p
<RAOF> directhex: Go formulate an ubuntu-devel-discuss message, then :)
<directhex> "digg this if users suck"
<slangasek> who here can test a powerpc-specific SRU? (bug #220890)
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [Undecided,In progress] https://launchpad.net/bugs/220890
<maxb> The langpacks in intrepid currently have a higher version than in jaunty, is that an issue, or a normal state of affairs at this point in the cycle?
<cjwatson> I wouldn't get too worried, but obviously it needs to be fixed before release
<TheMuso> slangasek: When I do powerpc related work this afternoon (i.e after work/canonical work), I'll take a peak
<cjwatson> ArneGoetje: ^- plans for a jaunty langpack update?
<cjwatson> we could copy the intrepid-updates ones to jaunty, in principle, but I don't want to do that because there's a Soyuz bug that means architecture-independent packages copied that way end up not showing up for armel
<cjwatson> though that's 299448 which is fix-committed so it's possible it was fixed in the recent rollout
<cjwatson> looks like it ought to be; I can give it a try tomorrow
<cjwatson> but we'll need jaunty langpacks anyway so it'll just be to stop people being surprised :)
<slangasek> seriously, what kind of boolean pervert came up with the idea of calling these things "killswitches" that turn your antenna off when they're on and on when they're off?
<pwnguin> the same guy that named the xserver option "DontZap"
<slangasek> nah, pretty sure that guy died of old age already
<pwnguin> slangasek: just use the phrase "killswitch engage". its 23 percent more brutal
<sakrasemangat> halloo..
<slangasek> hello
<cjwatson> my killswitch is labelled 0 for wireless-off and 1 for wireless-on
<cjwatson> so +1 for Dell's sanity, I guess
<slangasek> physically labelled?
<sakrasemangat> i'm newbie from indonesia and i need the study kernel compilation process on ubuntu please guide me...
<cjwatson> slangasek: yes
<cjwatson> sakrasemangat: this isn't really the right channel for advising new developers; you might start by reading the kernel team's wiki, http://wiki.ubuntu.com/KernelTeam
<cjwatson> sakrasemangat: also reading the various links from http://wiki.ubuntu.com/UbuntuDevelopment, since many of those general principles apply to the particular case of the kernel
<sakrasemangat> cjwatson, ok thank's...
<sakrasemangat> :)
<junyer> hi
<junyer> trying a third time :P
<junyer> does anyone here work on the autofs/autofs5 packages?
<ScottK> junyer: Just ask your question.
<slangasek> the answer to the initial question is "no", no one from Ubuntu works on the autofs5 package, it's synced unmodified from Debian
<slangasek> (which is not to say that this is the wrong place to ask if you're wanting to discuss development issues in the package)
<junyer> well, autofs v4 is essentially dead as far as upstream is concerned
<andersk> The current Intrepid/Jaunty autofs package has an Ubuntu patch that was added in bug 111612.
<ubottu> Launchpad bug 111612 in autofs "The auto.net script that comes with autofs is broken" [Undecided,Fix released] https://launchpad.net/bugs/111612
<junyer> so i'm wondering if/when support (in the form of a maintained autofs package) will cease
<slangasek> support for the autofs package will probably cease when the Debian maintainer gets rid of it, or when an Ubuntu developer notices that it's bit-rotted to the point that we should prefer the autofs5 package instead
<ScottK> slangasek: I've got an odd problem here that I've no idea how to troubleshoot well enough to even file a useful bug.  On intrepid I've got a hard drive that when I try to write to it as a user, I'm told the disk is full, but it's not.  df -k shows more blocks existing that used, but 0 available.  I can write to the disk as root and I can delete stuff as a user, but not write new stuff.  Suggestions?
<junyer> hmm
<slangasek> ScottK: ext3 reserved blocks?
<junyer> okay, so i should probably ping the debian maintainer then
<junyer> thanks
<slangasek> junyer: he's the one at the wheel on those packages, yes. :)
<junyer> (although he didn't respond to my mail yet, so i might have to hunt him down on irc)
<ScottK> slangasek: How would I know?  When I delete files the number 'used' goes down, but Available stays consistently 0.
<slangasek> ScottK: tune2fs /dev
<andersk> See the tune2fs manpage, -m option.
<ScottK> Lookinmg
<ScottK> Looking even
<StevenK> ScottK: Deleting files but available staying at 0 certainly points to you being over the reserved blocks percentage
 * slangasek nods
<ScottK> OK.
 * ScottK wonders how he got there.
<slangasek> the default reserved blocks are ridiculously large on today's large disks, it really ought to be logarithmic
<slangasek> ScottK: you wrote a bunch of stuff as a user, then root pushed you over the limit :)
<ScottK> Right
<StevenK> For things like /home and /srv and such, I will run tune2fs -m 0 after mkfs'ing them
<StevenK> Actually, for things where I'm the only user, or I can trust everyone with an account.
<ScottK> Well let me go find something big to delete ...
<slangasek> StevenK: well, for /home there's not much reason for root to have reserved space, neh?
<slangasek> ScottK: reducing the reserved count is easier :)
<ScottK> Reduced it to 1 and it still says 0 available
<StevenK> slangasek: Not usually. :-)
<slangasek> (though if it's not obvious how root pushed you over the limit, maybe there are leaky logs)
<slangasek> ScottK: mm, if tune2fs -l confirms, then /that/ might be a sign of fs corruption...
<slangasek> assuming that when you deleted stuff, the used count went down and stayed down
<ScottK> I'm guessing "Couldn't find valid filesystem superblock" is bad.
<slangasek> yes
<ScottK> I'm also guessing I'm into it's not worth the trouble, just start over territory.
<ScottK> Is there anything useful for a bug I can do first?
<slangasek> if you're not going to cry over the data, yes, that's start-over territory
<slangasek> if you have kernel logs that show it getting corrupted somehow
<StevenK> Actually, it's recoverable
<StevenK> You can run mkfs with -n, which will tell you where the backup superblocks are stored
<ScottK> StevenK: I'm open to suggestions ...
<StevenK> And then point tune2fs at one of the backup superblocks
<slangasek> could've been a hardware failure, a kernel bug, someone trying to dial out on the hard drive by mistake, ...
<StevenK> And fsck *really* soon
<slangasek> so unless you know how it got corrupted, hard to get a useful bug report out of it
<StevenK> And it may not be a software bug
<ScottK> Well I can try to get the kernel logs off.
<ScottK> Now I guess I really need to find the CD drive for this laptop.
<StevenK> ScottK: One large partition, and it's /, I'm guessing?
<slangasek> ... does strace work for anyone in jaunty?
<ScottK> Of course
<ScottK> StevenK: ^^^
<StevenK> ScottK: Bleh, this is the situation that having one large partition on / is bad :-)
<ScottK> Fortunately there's nothing critical on it.
<ScottK> There's a few things it'd be nice to save.
 * LaserJock makes some backups just in case it's contagious
<ScottK> I have it up on the network now, so I'm going to see if I can sftp to it....
<StevenK> I would sftp *from* it
<StevenK> Since that wouldn't try and write anything
<ScottK> Trying that.
 * ScottK gets to practice his rusty command line sftp skills.
<charlie-tca> slangasek: apparently, that was a bad thing to try
<slangasek> charlie-tca: hmm?
<charlie-tca> I ran strace on a 64-bit jaunty. It locked everything up and I had to go to a tty and kill it
<slangasek> heh
<Bsims> Can anyone point me to a tutorial to build multi binary debs... I want to package and host kde 3.5x built against Ubuntu Current...
<slangasek> it hasn't been crashing anything for me, except for itself
<Bsims> I am not entirely ignorant of dpkg but need help and the Debian New maintaners guide doesn't go into multi package debs
<maxb> Bsims: #ubuntu-motu is more appropriate for learning-how-to-package questions
 * Bsims smiles thanks maxb 
<ArneGoetje> cjwatson: after all remaining buggy translations have been fixed by jtv (will happen these days), we will generate a full export for jaunty and updates for hardy and intrepid. I hope those to be ready on Monday, then I will do the updates on the sprint.
<StevenK> ScottK: How goes the recovery?
<ScottK> StevenK: sftp'ing my heart out.
<StevenK> cd /chest_cavity
<StevenK> scp heart donor:
<ScottK> Found some un-backed up photos I'd forgotten about ...
<ScottK> But they're transferring just fine, so no it's just a matter of doing it.
<StevenK> ScottK: Mmmm. Avoid writing to the disk, if you can
<ScottK> Just doing a lot of sftp put.
<ScottK> Going in the order of how much I care too.
<StevenK> Heh
<TheMuso> slangasek: https://launchpad.net/bugs/220890 verified.
<ubottu> Launchpad bug 220890 in python-apt "[hardy] software-properties-gtk doesn't recognize (nor know about) ports.ubuntu.com" [Undecided,In progress]
<slangasek> TheMuso: thanks!  You used the test case from the bug description?
<TheMuso> slangasek: Yes.
<slangasek> great
<slangasek> bryce: I've confirmed that my touchpad issue is software (gpm works fine on console); where should I file the bug report?
<calc> maybe i can blow up the nightly cd later tonight >:-)
 * calc is doing a rebuild with fresh chroot to make sure everything is working properly
<ScottK> slangasek and StevenK: Thanks for the help.  I got everything I need.  Now if I can find the CD drive ...
<StevenK> ScottK: We won't come over to help you look ...
<slangasek> ScottK: glad to hear :)
<LaserJock> StevenK: that could be a long trip
<StevenK> True
<bryce> slangasek: most likely it's a bug in the xinput stuff so should be against xorg-server
<bryce> slangasek: subscribe me to the bug and I'll try to follow up on it
<slangasek> ok
<StevenK> bryce: I noticed that synaptics thought my touchscreen on my Q1 was touchpad, is that known?
<StevenK> was a touchpad
<ScottK> This will be my first Intrepid fresh install....
<LaserJock> ScottK: really? I think I've done about 5-6 so far
<ScottK> It's all been upgrades from Hardy until now.
<LaserJock> I generally reinstall about every 2-3 months
<LaserJock> I think I've done 3 Jaunty reinstalls so far
 * ScottK still has one Dapper desktop that was installed before Dapper's release.
<LaserJock> that's why I don't like UUID too much
<LaserJock> I gott fix things after each install
<maxb> LaserJock: but why? I've gone dapper-edgy-feisty-gutsy-hardy-intrepid without a reinstall
<LaserJock> I should just not UUIDs but I hate going against the grain
<LaserJock> maxb: because stuff usually starts breaking
<LaserJock> or I want to try something different
<maxb> Would be all the way to jaunty, but I needed to change i386->amd64
<LaserJock> I should probably try to slow down though, I'm afraid of wearing out the hard drive in my laptop
<LaserJock> it can't be good to keep installing and reinstalling on the same 6GB
<LaserJock> bugger, I never can seem to get reportbug to send stuff
<LaserJock> isn't it supposed to use a Debian SMTP host?
<StevenK> If you configure it too
<LaserJock> well, it keeps timing out
<LaserJock> I have: smtphost bugs.debian.org in .reportbugrc
<LaserJock> maybe rather than worrying about reportbug I should make up a BTS cheat sheet and manually do the emails
<LaserJock> I end up copy-n-pasting anyway
<ScottK> LaserJock: When you normally send mail, what mail server do you submit to?
<LaserJock> ScottK: I just use gmail
<LaserJock> I don't have any local client that I use
<LaserJock> I guess I could dig up the Gmail SMTP server
<ScottK> You can probably convince reportbug to do that too or set up a local postfix to do it (there are decent how-tos)
<LaserJock> I think I have exim4 install because of stupid sbuild
<LaserJock> *installed
<LaserJock> but I don't do anything with it I don't think
<LaserJock> I really dislike having a MTA on my machine
<ScottK> 243 updates are available ...
<mrooney> kirkland: ping!
<bbs> hello
<bbs> i do kernel work
<bbs> is there a spot that the ubuntu kernel is discussed?
<greg-g> bbs: #ubuntu-kernel , appropriately enough
<bbs> greg-g: figured it out
<bbs> asked stupid question
<bbs> sorry
<hyperair> asac: could bug #248705 be considered for SRU? it seems that 2.24.3-0ubuntu1 was uploaded to intrepid-updates, but not 2.24.3-0ubuntu2, and the changes between the two versions are only that which fixed the said bug.
<ubottu> Launchpad bug 248705 in evolution-data-server "Evolution Exchange does not authenticate to Exchange servers with a relative path in the form action, e.g. "owaauth.dll"" [Undecided,Fix released] https://launchpad.net/bugs/248705
<hyperair> asac: in addition, you were the one who uploaded 2.24.3-0ubuntu2
<mrooney> anyone know how to switch to a virtual terminal in a virtualbox instance?
<mrooney> Using ctrl+alt+# switches the host even if the guest is grabbing keys
<hyperair> mrooney: ssh
<smoser> mrooney, http://forums.virtualbox.org/viewtopic.php?t=9615&sid=c79dce75d9b09436397acb59992a316f
<smoser> "should be" right control F1
<smoser> that is if you actually meant ctrl-alt-F# , maybe you didn't though
<hyperair> http://www.virtualbox.org/ticket/41 this says it too
<mrooney> smoser: yeah, did :)
<mrooney> thanks!
<superm1> TheMuso, this was verified with an intrepid disk, so unless they were missing in intrepid too N/A.  I'll reverify with a jaunty daily tomorrow.  I was going to add more stuff to the bug, but launchpad went into maintenance mode 5 or so minutes after I filed it. cjwatson i'll get that added from the jaunty daily as it will be more useful
<dholbach> good morning
<bryce> heya dholbach
<dholbach> hiya bryce
<dholbach> hi thekorn, ara, Koon! :)
<Koon> o/
<ara> hey dholbach, morning :-)
<bryce> StevenK: not sure, I've not been following synaptics too closely; check the bug tracker to see if it's known.  If it is, probably needs forwarding to bugzilla.freedesktop.org next.
<thekorn> morning dholbach
<pitti> Good morning
<dholbach> hi pitti
<pitti> superm1, slangasek: so after those recent hal-info commits, what's actually left in hotkey-setup? just the module option for the thinkpad? (which should become a modprobe.d script)
<pitti> hey dholbach *hug*
 * dholbach hugs pitti back
<slangasek> pitti: the options that can't currently be set with modprobe..?
<pitti> oh?
<slangasek> it twiddles bits in /sys
<pitti> right, but modprobe install scripts can do that
<slangasek> hmm
<pitti> well, either way, I was just curious whether there's anything else left
<slangasek> would still have to be a separate script because of the complexity, so I don't know that it's really advantageous to move it to modprobe
<pitti> so far I'm just aware of that thinkpad module flipping
<slangasek> there's also the thinkpad daemon that's run on some hardware, yes
<slangasek> /usr/sbin/thinkpad-keys
<pitti> slangasek: well, I'd like it to be moved to a modprobe.d script, because then we don't need to penalize every non-thinkpad-laptop user with a no-op init script
<pitti> that can still be in the hotkey-setup package, if the rest gets stripped out
<pitti> e. g. if all hotkey mappings are migrated now, we should throw them out
<slangasek> "throw them out" - I think superm1 already did that?
<pitti> oh, so he did!
<pitti> (didn't follow -changes in the week I was on holiday)
<slangasek> :-)
 * pitti hugs superm1
<slangasek> I actually started from the other end, so I have a diff here that reduces the ibm.hk to only the essentials, which we can then also get moved over to hal-info sometime soon
<slangasek> that leaves the /sys twiddling, the thinkpad_keys daemon (which as a daemon, I think should be managed by an init script...) and one last thing for /proc/acpi/video/*/DOS
<pitti> slangasek: daemon init script> *nod*
<pitti> slangasek: Keybuk might have a better idea about how to start the thinkpad daemon on thinkpad laptops only (i. e. module load triggered), though
<slangasek> pitti: we could not ship a start link for the init script, by default only calling it via modprobe?
<pitti> slangasek: right
<pitti> (or just put the start-stop-daemon call into the modprobe.d script itself)
<slangasek> yeah, I'd rather not do that because it means there's no good way to manage the process
<slangasek> invoke-rc.d on upgrades, etc
<pitti> right
<pitti> kees: was the hardy-security linux -23.48 based on -23.47 in hardy-proposed? or against -23.46 in hardy-updates?
<slangasek> doko_: bug #315770> hmm, but why is libio-socket-ssl-perl needed in main?  checkrdepends shows nothing
<ubottu> Launchpad bug 315770 in libtree-dagnode-perl "MIR for libnet-ssleay-perl and dependencies" [Undecided,New] https://launchpad.net/bugs/315770
<pitti> kees: if the former, it wasn't verified yet, if the latter, it needs to be merged and reuploaded into -proposed
<pitti> jdstrand: ^ or maybe you know
 * slangasek wanders bedwards - night, folks
<pitti> slangasek: sleep well!
<soren> I wish Launchpad would show which archive-admin ACCEPTed stuff, so that I could distribute hugs accordingly.
<pitti> soren: if you are talking about NEW, look at the archive day mapping on wiki/ArchiveAdministration
<soren> pitti: Hm... Yes, I suppose that's a reasonable approximation. The fact that it seems to have happened in the middle of the night suggests that it's someone with different hemispherocity than myself.
<soren> ...so...
 * soren hugs StevenK 
<pitti> soren: he deserves a hug either way :)
<soren> Quite so :)
<Necrosan> soren: I am the official hug accepter here.
<Necrosan> Dole them out as you see fit.
<pitti> lool: rejecing your xine-lib intrepid-proposed upload; it's a merge without merged changelogs (forgot -v), and was perhaps aimed at jaunty?
<pitti> lool: ah, perhaps not at jaunty; either way, changelog needs to explain the changes and link to LP bug #s
<kirkland> mrooney: pong
<evand> Can someone else with access to ubuntu-devel process the mailman queue?  My login information is stored in a still-packed computer that's lacking a keyboard at the moment.
<BUGabundo> evand: lol
<BUGabundo> evand: you can always retrive it, no?
<BUGabundo> although mailman admin/mod login, aint that easy to get
<evand> I'd have to ask one of the other individuals with access for the password, or bug IS.
<lool> pitti: Uh?
<pitti> lool: http://launchpadlibrarian.net/21679435/xine-lib_1.1.15-0ubuntu3.1intrepid1_source.changes
<lool> pitti: I merged the security update with the current -proposed upload
<lool> pitti: Ok; so you want a clean .changes?
<pitti> lool: ah, can you then please reupload with using -v?
<lool> pitti: Should I include the original -proposed upload as well?
<pitti> lool: yes, please do
<lool> Actually I'm not sure I have it anymore
<lool> pitti: Hold on before you reject please
<lool> Too late
<pitti> lool: I rejected it already, but I can fish it out of the rejected queue
<lool> pitti: If it's not too long, that would be good
<pitti> lool: https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=4&queue_text=xine-lib
<lool> pitti: Will you also process hardy's unapproved today?
<pitti> lool: yes, I'm at it
<lool> Great
<pitti> lool: can you access that page?
<pitti> I'm not sure whether it's restricted to ~ubuntu-archive
<pitti> if so, I'll fish it out for you
<lool> pitti: Pushing xine-lib_1.1.15-0ubuntu3.1intrepid1.changes again with the initial -proposed upload, the security merge, and the new -proposed upload in the changes
<lool> pitti: it's fine I can access it alright
<lool> Just finished the new upload
<Keybuk> pitti: why do we have yet another daemon for it at all?
<pitti> Keybuk: I don't know at all what this is doing; but launching it through a modprobe.d script isntead of rc2.d seems like a good move
<Keybuk> why does it exist?
<Keybuk> it sounds like the kind of thing that should be a hal add-on
<lool> pitti: Thanks for approving xine-lib already
<pitti> lool: thanks for doing it
<doko_> slangasek: spamassassin libwww-perl libnet-server-perl libnet-ldap-perl suggest it, but maybe these are more recent changes
<slangasek> doko_: only suggest?
<slangasek> we don't have a closure over suggests in main
<slangasek> nor do we want one
<doko_> slangasek: but it doesn't show up in component mismatches
<slangasek> doko_: OTOH, it also doesn't show up in germinate output AFAICS
<slangasek> doko_: so either that's a bug in component-mismatches, or the package is only needed on lpia or something?
<slangasek> doko_: nope, not needed on any arch - so I think that's a bug in component-mismatches.  Shall I demote it and see?
<slangasek> doko_: oh!  found it - libnet-ldap-perl has a Build-Depends-Indep on it, that didn't get reported by checkrdepends
<doko_> slangasek: yes, the demotion sound sounds nicer :)
<slangasek> but maybe we can fix libnet-ldap-perl to not need it...
<pitti> slangasek: I fixed checkrdepends a while ago to also display B-D-I, weird
<slangasek> pitti: checkrdepends gave me a bunch of errors, e.g., grep-dctrl: /tmp/tmp.ZcOkhX1927/jaunty_restricted_Sources: No such file or directory
<slangasek> and I was used to getting errors from it the past few times I've used it, so I didn't dig deep enough
<pitti> hm, indeed
<pitti> will look at that later
<slangasek> anyway, libnet-ldap-perl b-d-i seems like a silly reason to pull all those packages into main
<pitti> /tmp is probably from gunzip -c
<slangasek> well, libio-socket-ssl-perl has been in main since dapper or earlier; but why does it suddenly need all this other junk
<pitti> slangasek: seems that there's a newline after 'jaunty', so the command gets split; weird
<slangasek> huh, ok
<slangasek> doko_, pitti: libnet-ldap-perl only uses libio-socket-ssl-perl for an optional part of its test suite; what do you think about dropping the b-d-i and kicking it (and its deps) to universe?
<pitti> slangasek: if that pulls in a whole lot of further libs, fine for me; if it's just that one, I'd rather promote it
<doko_> fine for me
<slangasek> pitti: there's an MIR right now for the four other perl libs it pulls in
<pitti> slangasek: hm, $T/*_Sources expands to jaunty
<pitti> _main_Sources
<pitti> WTF?
<pitti> aaah, found it
<pitti> slangasek: apparently a cut&paste error from yesterday's rescue operation
<pitti> fixed
<alkisg> pitti: Me and some other people are looking for a better user management tool. We saw your evaluation of system-config-users: http://www.mail-archive.com/ubuntu-desktop@lists.ubuntu.com/msg01544.html
<slangasek> pitti: cheers
<pitti> have to run out for two or three hours
<apw> TheMuso, about?
<pitti> alkisg: need to run now, please mail pitti@ubuntu.com
<alkisg> pitti: ok, ty
<slangasek> pitti, doko_: interestingly, the only reason libnet-ldap-perl is in main either is because it's explicitly seeded in supported-development ?
<doko_> hmm, maybe ask the server team?
<dholbach> hum... where's http://people.ubuntu.com/~ubuntu-archive/removals.txt ?
<slangasek> dholbach: bdmurray was asking after it the other day; I don't know whether he found an answer, but I don't know where that's supposed to come from
<TheMuso> apw: Yes.
<dholbach> slangasek: it always was there :)
<apw> TheMuso, i won't ask what time it is there
<dholbach> it's even linked from https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages :)
<slangasek> dholbach: right, but something has to create it. :)
<TheMuso> apw: 21:43.
<slangasek> and I don't know what that something is
<apw> TheMuso, you sync'd alsa-drivers recently with debian
<dholbach> slangasek: https://wiki.ubuntu.com/ArchiveAdministration#Removals maybe?
<TheMuso> apw: Yes but they have a newer revision I need to get to.
<slangasek> dholbach: no
<apw> TheMuso, that brought a change to /etc/modprobe.d/alsa-base, which commented out the load of oss
<apw> and that is breaking espeak
<slangasek> dholbach: we weren't populating it manually - it must have been created by some script, but I don't know what script
<TheMuso> apw: Oh right, will fix that when I do the merge. Thanks.
<apw> its already uploaded?
<TheMuso> apw: No, I need to prepare a merge of 1.0.17a with debian
<apw> affecting the jaunty releases, bug #319505
<ubottu> Launchpad bug 319505 in linux "In Jaunty Alpha3 release 32 bit and 64 bit versions the sound is not work." [Medium,In progress] https://launchpad.net/bugs/319505
<TheMuso> so I'll fix it in that.
<TheMuso> apw: and I am following that bug.
<TheMuso> apw: thanks for the heads up.
<slangasek> doko_: well, we can check with the server team, but they didn't add it; it traces back to the original bzr import of the seeds, so there's no specific rationale :)
<apw> TheMuso, the change occured cuase of a threat (literally) from the debian kernel team about alsa sharing not working if they were loaded, so i need to work out if that is also true fo rus
<TheMuso> apw: ok
<TheMuso> anyway I'm off for the evenin.
<TheMuso> evening
<TheMuso> apw: You got me just in time. :p
<apw> TheMuso, have a good one, will update the bug with my findings
<slangasek> cjwatson: you don't remember a rationale for the set of perl packages listed in supported-development, do you? :)
<cjwatson> ArneGoetje: cool, thanks
<cjwatson> dholbach: removals.txt is no longer relevant because all its data was migrated into Launchpad
<cjwatson> slangasek: ^-
<slangasek> ok
<cjwatson> dholbach: so if you look at https://launchpad.net/ubuntu/+source/<src> and follow links, you should see the removal reason etc.
<cjwatson> dholbach: we have a backup copy in case somebody does need the old file, but it shouldn't be necessary any more
<dholbach> cjwatson: THANKS muchly
<dholbach> cjwatson: I'll update the docs referring to it
<__doc__> hi, anybody of you has got a device from 3dconnexion (space ball, navigator etc.?)
<cjwatson> dholbach: thanks
<ogra> cjwatson, fyi, versatile netboot installer seems to work well in qemu
<cjwatson> ogra: superb
<ogra> though ports seems down
<ogra> ah, not anymore
<cjwatson> ogra: http://cdimage.ubuntu.com/ports/daily/current/jaunty-alternate-armel.iso managed to spit something out at least
<cjwatson> no kernel or initrd on that though
<ogra> yep, i'm just trying that with the netboot installer
<ogra> though i wanted to try a normal netinstall first
<cjwatson> base-installer might not get kernel selection right
<cjwatson> yeah, doesn't look like it uses the metapackages
<ogra> but it should offer me to go on without kernel, no ?
<cjwatson> maybe
<ogra> first i have a different prob though, seems qemu cant resolve
<ogra> hmm, or route ... weird, i can ping the gateway but it doesnt get forwarded
 * apw has a blank moment, what was the command which let you edit the src directly and made a patch out of it when you exit'd
<cjwatson> ogra: it would be useful if you could send me /proc/cpuinfo from that emulated machine
<Mithrandir> dpatch-edit?
<cjwatson> apw: run what-patch first to find out which patch system the package already uses
<ogra> cjwatson, well, it works with my homebrewed kernel usually, i guess its a kernel issue ... i'll try the netinstaller with that one
<cjwatson> apw: you generally need to run a command appropriate to the package
<cjwatson> ogra: no, I want /proc/cpuinfo because base-installer's kernel test suite needs a copy of it :P
<apw> quilt
<ogra> cjwatson, ah, k, you'll get it :)
<cjwatson> apw: 'export QUILT_PATCHES=debian/patches' and then use quilt normally
<cjwatson> apw: that package won't be suitable for the tools that produce a complete copy of the source for you to edit
<apw> ahhh, now that is why people moved to quilt
<apw> if one is modifying the debian part of a package sync'd from debian (a file in debian which is copied in wholesale) should you be adding that as a patch in the patches directory or just modifying it directly?
<cjwatson> just modify it directly
<apw> makes life easy :)
<ogra> cjwatson, http://paste.ubuntu.com/111192/
<cjwatson> ogra: thanks, pastebin tends to mash tabs though. Could you put it on people?
<ogra> sure
<slangasek> Keybuk: udevadm trigger --action=change isn't documented in the --help output, and only --action=add is documented in the manpage...
<ogra> cjwatson, http://people.ubuntu.com/~ogra/arm/qemu/cpuinfo
<cjwatson> ogra: thanks, grabbed
<ogra> cjwatson, any idea why i cant get over the NAT gw from the VM ?
<ogra> works if i just bootstrap a system ...
<cjwatson> err, no idea
<ogra> so it seems to be an issue with d-i
<cjwatson> my approach to qemu networking is to hope it works
<ogra> ARGH !
 * ogra slaps forehead intil it turns red
<ogra> *until
 * ogra makes note to next time read carefully what d-i asks him :P
<highvoltage> don't stress, ogra
<apw> though it is fun to watch
<ogra> http:// is not really liked by the mirror input
<hyperair> is there a way to get qemu to work with ia64 archs?
<hyperair> i'm looking for an ia64 buildd
<ogra> its so long ago that i actually used d-i with all these questions :P
<hyperair> qemubuilder looks promising, but no ia64 support from qemu
<asac> TheMuso: http://launchpadlibrarian.net/20109106/at-spi_1.25.1-0ubuntu2_1.25.2-0ubuntu1.diff.gz
<asac> TheMuso: you a) dropped my changelog entry
<asac> TheMuso: and b) dropped the patch i added
<asac> TheMuso: without a comment ... has this been applied upstream?
<asac> TheMuso: i doubt it has been.
<ogra> bah, partman takes ages in qemu
<asac> TheMuso: debian/patches/05_lp278095_no_environ_access_shutdown.patch
<asac> TheMuso: can you readd that? i receive crash reports on firefox again :)
<asac> TheMuso: also please readd my changelog entry ... so i dont have to hunt that info on launchpad :=)
<asac> TheMuso: alternatively let me know and i can do this ;)
<seb128> mvo: could you look to bug #321919?
<ubottu> Launchpad bug 321919 in evolution-exchange "package evolution-exchange 2.24.2-0ubuntu1 failed to install/upgrade: Package is in a very bad inconsistent state - you should" [Undecided,New] https://launchpad.net/bugs/321919
<ogra> cjwatson, base install in qemu is almost done, would be helpful to have ports.ubuntu.com in the preseed file somehow (and indeed the ubuntu-ports dir)
<cjwatson> ogra: it should detect it automatically. Which bit didn't detect it?
<cjwatson> (the design is that this does not require preseeding)
<ogra> oops, console setup just trashed the d-i frames
<cjwatson> hmm, new base-installer defaults armel to MODULES=dep
<cjwatson> I guess that's reasonable
<ogra> cjwatson, well, it asks for a mirror
<ogra> and only offers manual input there
<ogra> nothing preselected
<cjwatson> so the mirror selection component. ok
<ogra> and the dir is set to /ubuntu/ instead of /ubuntu-ports/
<cjwatson> I can fix that easily
<ogra> great
<cjwatson> heh, that was never fixed for lpia either
<persia> mpt, regarding your comment that ichthux and ubuntume provide filtering controls: are those general solution that are but an apt-get away for other sorts of installs?
<ogra> ah, and it seems to let me properly go on without kernel
<persia> For lpia we just preseeded it away in the MID image, because there was only the MID image that worked.
<ogra> oh, fun now the trashed d-i UI frames changed back to look proper
<ogra> oh, wow, i havent seen the automatic updates question yet
<asac> TheMuso: ok. false alert i think. the code looks ok now
<cjwatson> ogra: fixed for the next d-i build
<ogra> cool !
<cjwatson> Keybuk: so, empirically, the first obvious effect of removing udevadm trigger from the installer is that it stops being able to detect the network card
<cjwatson> Keybuk: and it refuses to do so until I run udevadm trigger; settle
<cjwatson> (as in, /sys/class/net contains only lo; upon running udevadm trigger eth0 it appears immediately)
<cjwatson> s/it //
<elmo> so, err, someone (keybuk) I think, once told me 'udevadm trigger' was how to get the system to see a hot-added RAID array
<elmo> what is it in the new world order?
<cjwatson> now I know that class devices aren't guaranteed to show up especially immediately but still ...
<cjwatson> elmo: my understanding is that trigger is not necessary (any more?) because anything that trigger does should already be in udevd's queue
<cjwatson> so ISTM that it's a bug if trigger is needed
<elmo> ah, ok
<Keybuk> cjwatson: we'll look at the sprint
<Keybuk> I'd guess that the network card modules weren't there when udev's installer-startup script ran udevtrigger
<Keybuk> and they were installed later
<mpt> persia, no idea, all I know is that their Web sites advertise them.
<persia> mpt, OK.  I'll chase up with AnAnt or txwikinger at some point then.  Thanks.
<cjwatson> Keybuk: that's common practice in d-i
<Keybuk> but you don't try and modprobe them?
<cjwatson> probably at some point
<cjwatson> oh, not like individual network card drivers no
<rickspencer3> asac: ping
<asac> rickspencer3: hi
<rickspencer3> I saw your policy page. Do you want me to type it into pros?
<rickspencer3> It looks quite complete, btw
<asac> rickspencer3: i think its ok to use the form currently used. I think what we need is some intro text explaining a bit the rational and the spirit of this
<asac> and cleaning up the things in brackets et al.
<rickspencer3> So you want me to do some wiki gnomiing? Just clean it up here and there?
<evand> Anyone have experience with libglade and custom widgets?  The documentation tells me to use the custom widget container, but glade says that it's deprecated.
<rickspencer3> asac: Is there an example of a complete policy somewhere on the wiki that would make a good example?
<seb128> evand: that doesn't reply to your question but you should try using gtkui nowadays
<asac> rickspencer3: Maybe MainInclusionProcess
<seb128> evand: otherwise mvo might know about glade specifics
<rickspencer3> asac: thnaks
<asac> rickspencer3: but well :) ... thats not really more
<asac> rickspencer3: i think its really just cleaning up; fix wording and do some intro text
<rickspencer3> asac: sure. Whatever I can do to help. n/p
<evand> seb128: ok, thanks.  I'm not familiar with gtkui and a google search just lists a bunch of modules for various projects that use a similar name.  Do you have a link to some documentation?
<seb128> evand: http://library.gnome.org/devel/gtk/stable/GtkBuilder.html
<evand> ah, indeed
<evand> thanks!
<seb128> you're welcome
<seb128> that's the gtk equivalent of libglade
<seb128> evand: you have scripts to convert .glade to .ui
<seb128> evand: gtk-builder-convert
<evand> neat
<cjwatson> yeah, that postdates ubiquity's original use of glade and we never converted
<asac> rickspencer3: also there is StableReleaseUpdates
<evand> cjwatson: any objection to converting to gtkbuilder format at some point over the course of Jaunty development (before FF)?
<rickspencer3> asac: tx
<calc> anyone know why kdelibs4-dev is not installable on most architectures?
<calc> kdelibs4-dev is for kde 3 btw
<ScottK> Probably libdrm-dev not installable
<calc> ScottK: is that going to be fixed soon?
 * ScottK looks at bryce
<calc> its breaking OOo so hopefully so ;-)
<ScottK> calc: When I looked at it, it seemed that libdrm-dev had a versioned depends on a particular kernel version that wasn't satisfied on any ports arch except armel.
<calc> well whatever is making kdelibs4-dev on all non amd64 arch is anyway ;-)
<ScottK> If it's catching i386, then it may well be another problem too.
 * ScottK looks into it.
<calc> well not sure about i386 its been held by stlport atm
<Riddell> calc: actually we were going to ask you about dropping kdelibs4c2a from ooo
<Riddell> calc: can you make ooo just use the Qt stuff but not the KDE native dialogue stuff?
<calc> Riddell: hmm maybe, i'm not certain
<calc> if some kde hacker wants to fix kde4 support in OOo that would be great too :)
<Riddell> calc: yes that would be the best option of course
<cjwatson> evand: not at all, as long as it can work with something like the separated glade file format we have
<evand> cjwatson: ok, I'll look into it
<calc> Riddell: so the libdrm thing is why its not installable anywhere for right now?
<ScottK> That's at least why KDE 4.2 FTBFS on everything except i386, amd64, and armel.
 * calc notes his connection may drop soon due to at&t working on the line, its not that he just decided to leave, heh
<Riddell> calc: dunno, let me look
<calc> Riddell: ok
<Riddell> calc: apt is installing it here on my system and in a chroot
<calc> Riddell: yea according to scottk it should be failing on most arch due to libdrm being uninstallable
<Riddell> libdrm-dev installs for me
<Riddell> on i386
<ScottK> Yeah, on i386 that's fine.
<ScottK> It's the non-armel ports archs
<calc> ScottK: is bryce already aware of the issue, i didn't see a bug about it in LP
<ScottK> No idea.
<ScottK> It's been on my list to ask.
<calc> i'll file a bug with some of this log in it
<ScottK> You can toss in some kde4libs build logs too if you want.  It failed on all the same archs (which is why I know)
<cjwatson> oh, presumably due to kernel desync then
<cjwatson> linux-ports desperately needs to be brought into sync
<calc> bryce: ping
<ScottK> Prior to this we had KDE bulding very nicely on all the ports archs except hppa (and that due to a soyuz bug).
<cjwatson> Soyuz bug as in missing architecture: all packages, or something else/
<cjwatson> ?
<ScottK> cjwatson: Yes.  It's the "If p-a-s says skip any binaries, let's just skip the build for the whole source package" bug.
<cjwatson> so you mean "no" :-)
<cjwatson> (that's not the bug I was thinking of)
<ScottK> Now that I've read what you wrote again, yes.  I meant no.
<ScottK> ;-)
<johanbr> I'll just restart X. Brb...
<mdeslaur> siretart: thanks for the xine-lib merge!
<slytherin> Keybuk: Since you are the last uploader of mouseemu, I was wondering if you have any idea why having mouseemu installed is causing problem with permission for /dev/null, /dev/console.
<slytherin> Keybuk: directhex suggested it because of presence of udevadm in the init script.
<cjwatson> slytherin: I tried to tell you at the time but you'd left: mouseemu only calls udevadm settle, not udevadm trigger
<slytherin> cjwatson: Then what could be the problem.
<DexterF> hi
<cjwatson> slytherin: no idea
<slytherin> ok.
<cjwatson> but don't pick on it just for using a udevadm command that isn't the one Keybuk identified as breaking stuff ...
<tjaalton> ScottK: why would libdrm-dev block the installation of kdelibs4-dev?
<slytherin> hmm. so I will have to digg deeper. I will take a look at it when I go home.
<ScottK> tjaalton: When I looked at it, that's where the dependency chain stopped.  It's blocking X -dev installs (I forget exactly which package).
<tjaalton> ScottK: ok
<tjaalton> I've no idea if the ports kernels are going to be updated to 2.6.28 anytime soon, so maybe it needs something else
<ScottK> I didn't actually check it for kdelibs4-dev (KDE3), but I did for kde4libs FTBFS.  I'm pretty sure it's the same issue.
<slytherin> is anyone working on fixing FTBFS of xorg-server on non i386/amd64 arch? Looks like issue is due to old linux-headers
<tjaalton> slytherin: exactly the same issue as above
<slytherin> tjaalton: ahh, just saw your message
<tjaalton> drm headers moved to the kernel since 2.6.28-4
<tjaalton> and I don't understand why the lpia kernel didn't use the same ABI, so libdrm needs to be fixed to match .28-1 for lpia..
<ScottK> I don't suppose there's some way libsrm-dev could continue to provide them for the older kernels?
<tjaalton> ScottK: different packages for different archs?
<tjaalton> somehow I don't like the idea ;)
<ScottK> Some arch specific ifdef magic?  Dunno, just know that change totally broke ports.
<tjaalton> ScottK: one possible short-term fix would be to not depend on linux-libc-dev on the ports, until they provide the kernel
<tjaalton> that would only break some X driver builds
 * calc found out at&t is going to be digging around in his yard soon
<ogra> sigh, d-i in qemu is really taking its time ...
<ScottK> tjaalton: I don't know enough to have an opinion on how best to proceed.
<cjwatson> pgraner: ^- see above discussion about linux-ports
<cjwatson> pgraner: the desynchronisation is causing userspace problems
<tjaalton> pgraner: indeed..
<slytherin> how about getting ports kernels updated. :-) But AFAIK, TheMuso is already working on that.
<pitti> geser: o_O "$ pkcon resolve hal" -> Fehler: package-not-found : Package name pkcon could not be resolved
<pitti> geser: I noticed that my jockey test suite fails, and it seems that pkcon mixes up the package name nwo?
<tjaalton> well, adding this band-aid solution would at least allow the non-X parts to build
<pitti> geser: sorry, that should have been "glatzor"
<Baby> does anyone know how to activate GLX in Xephyr?
<Tm_T> ok, should I scream it here if xine packages breaks with dpkg ?
<cjwatson> you should file a bug
<Tm_T> hrrr, have to try to find working browser then
<Baby> you're free to scream if you want too, anyway ;)
 * ogra points Tm_T to man ubuntu-bug 
<Tm_T> ogra: aaah, that's new to me
<Tm_T> anyway, got Konq to work, so, http://paste.ubuntu.com:80/111264/
<Tm_T> so something weird happens that causes dpkg: ../../src/packages.c:221: process_queue: Assertion ependtry <= 4' failed.
<cjwatson> Tm_T: should be fixed in jaunty
<Tm_T> cjwatson: I'm in intrepid, hmmm, so this wasn't my doings then
<jcastro> mvo: iirc update-manager disables PPA addresses on upgrade right?
<Tm_T> cjwatson: thanks, have to look about this, I got interested
<james_w> jcastro: it does. It has a whitelist though, not sure if any PPAs are in that
<jcastro> james_w: I was just thinking that it might be a good idea to do a rename on the urls for the new PPAs on the next upgrade
<james_w> jcastro: it could probably do that as it disables them.
<james_w> jcastro: the worth of it depends on how long the old URLs work I imagine
<jcastro> or at least leave a note in a comment
<james_w> if they get turned off soon then most people will have had to deal with it before upgrade
<mvo> jcastro: yes
<mvo> jcastro: the trouble is that external repos (including ppa) quite frequently screw the upgrade calculation
<mvo> this is why the external repositories are dissabled during upgrades, there is now a config option to override that
<jcastro> mvo: how about a note in the comments when you disable it with a link to the new URL or something?
<jcastro> mvo: informing people that the url has changed would be easier than trying to do it for them I think
<mvo> jcastro: sure, I could do that, disable and update in one go so that its easier for them to re-enable it
<mvo> jcastro: that is a good idea
<jcastro> mvo: yeah, they have to reenable it by hand anyway, so if there's a comment there that will cover people who miss the announcements.
<mvo> jcastro: thanks, I add that
<jcastro> <3
<ScottK> mvo: Do you think there's still time for you to work on the backports improvement spec if it were approved?
<ScottK> No point in pushing for someone to approve it if not.
<mvo> ScottK: what is the url for that?
 * ScottK should have anticipated you'd ask that.  Just a moment.
<mvo> ScottK: was that the idea to have backports show up unticked in update-manager?
<mvo> ScottK: or to use "NotAutomatic: yes" in the release file?
<ScottK> It was the NotAutomatic: yes one.
<ScottK> https://blueprints.launchpad.net/intrepid-backports/+spec/selective-backport-support
<ScottK> mvo: ^^
<mvo> ScottK: I sitll like the idea, let me check how much effort it would be
<evand> mvo: I noticed you're using the Custom object in libglade.  I need to make use of this, but noticed that it's deprecated in glade.  Any idea what's intended to replace its functionality?
<ScottK> mvo: Thank you.
<mvo> evand: no, sorry. my guess is gtkuibuilder, but I have not worked that much with it yet, I don't like the addtional glade->ui file step (not a biggie of course :)
<evand> mvo: ok, no worries
<evand> and thanks
<mvo> cheers (also there is not a lot to thank for unfortuantely :/)
<superm1> evand, so is the thought to just use '.ui' files instead of glade files then, or '.ui' files specifically where you need the custom widgets?
<mvo> jcastro: commited
<evand> superm1: to evaluate GtkBuilder and move to that if it's not too much of a headache (that is, we don't have to merge all the glade files back together)
<cjwatson> I don't think we'd want a *mix* of .ui and .glade
<evand> indeed
<superm1> besides the custom widget support, what other benefits does GtkBuilder bring to the table?
<jcastro> mvo: um, wow, that was fast, thanks!
<evand> I haven't discovered custom widget support in it yet, but I've found this helpful in explaining the differences between the two: http://www.micahcarrick.com/05-30-2008/gtk-builder-libglade-faq.html#3
<mvo> ScottK: my current (hopefully not too naive) feeling is that it can done reasonable painless with update-manager so I would say we should write the spec and make update-manager the first target for the implementation
<ScottK> mvo: OK.  If you could scribble on https://wiki.ubuntu.com/Backports/SelectiveInstallation a bit with some idea, I can work on fleshing it out.
<ScottK> mvo: Thanks for looking into it.
<superm1> evand, if worst comes to worst, and gtkbuilder doesn't support using multiple .ui files and/or doesn't support custom widgets, you could always just leave a container in the glade file and add the widgets in the python source i'd think.
 * ScottK points NCommander at the discussion above ...
<mvo> ScottK: I think we should go with notautomatic instead of pinning, that should make it easier
<mvo> ScottK: I'm testing some ideas right now, hopefuly I should have a better opinion by tonight :)
<ScottK> mvo: OK.  I'm more interested in the result than the design.  I think backports will become immeasuably more usable if people can enable it and leave it on without fear of unwanted upgrades.  Thanks.
<ScottK> Pinning was NCommander's idea anyway ....
<mvo> ScottK: agreed!
<mvo> ScottK: thanks for the reminder about it, its one of the things that should really be done :)
<NCommander> er, what?
 * ScottK slaps NCommander around a bit, just to keep him dazed and confused.
<tseliot> sabdfl1: you've got mail ;)
<evand> superm1: indeed, though I'd ideally like to avoid that :)  Someone on #gtk+ helped me with custom GTK widgets, so I may have that sorted shortly.
<davmor2> the new pulseaudio update seems to remove my intel hda audio device from output on Sound Preferences and I get no audio after the login music
 * robbiew  fights with broadband...using windows right now...rebooting back to linux and crossing fingers
<calc> at&t is running a new wire to my house :)
<DexterF> will open vm tools provide me a working Xserver for kub8.10 running in vmware workstation 6.5.0?
<directhex> seems my new graphics card definitely doesn;t work on intrepid, with nv or nvidia
<calc> i got at&t to upgrade my line the day after i get back from germany :)
<calc> going from 3.0/0.5 to 10.0/1.5 :)
<calc> still not as good as FIOS but not too shabby
 * ScottK hugs his FIOS.
<calc> i bet at&t will roll out better stuff once comcast here rolls out their 50/10 this summer
<redvamp128> quick question-- where can I find the changelog for kernel updates?
<RAOF> aptitude changelog linux
<redvamp128> last night I downloaded it and clicked on the update description and it was unavailible
<redvamp128> Though one thing to note-- this one seems to make the hard drive a little more quiet
<redvamp128> 2.6.24-23
<redvamp128> RAOF:  thanks that worked--
<ogra> cjwatson, fyi my netinstall finished properly
<redvamp128> I know this is a room for ubuntu development-- but I have an interesting issue with using LXDE window manager-- lack of volume control -- has anyone heard of this issue?
<redvamp128> Gnome-openbox or Gnome does not have this issue or the XFCE (XUBUNTU-desktop)
<kees> doko_: in openjdk-6's Makefile.in, there is this line:
<kees> 	  $(TAR) xf $(OPENJDK_SRC_ZIP) -C openjdk; \
<kees> since OPENJDK_SRC_ZIP in a tar.gz, tar execs gzip.  but the Makefile.in has exported the "GZIP" environment variable.
<kees> gzip will think this is a cmdline argument and die.
<kees> later in the Makefile, you can see work-around for this:
<kees> GZIP=$(GZIP_ENV) gunzip -c $(distdir).tar.gz ....
<kees> doko_: so, mostly, I can't understand how the buildds don't explode when my local builds do.
<mneptok> kees: i blame usplash-mnepolo
<kees> mneptok: haha, it was pwning my eyes, so I uninstalled it.  :)
<cjwatson> ogra: woo
<doko_> kees: it's not used, the ALTERNATE_something is used
<kees> doko_: something weird is going on with it, but I've worked around it
<doko_> works without problems for me
<kees> yeah, I think "make" is doing something funny because I have GZIP in my environment
<cjwatson> kees: make re-exports variables if they're already present when it starts
<cjwatson> kees: more precisely, it leaves their export status alone
<kees> cjwatson: ah-ha.  that would do it.
<kees> i have an exported GZIP, and when the Makefile sets it to /bin/gzip, the build explodes.  wheee
 * kees swore sbuild cleared the environment
<cjwatson> kees: you may need either 'export GZIP' or 'unexport GZIP' depending on the direction of the problem
<slangasek> sounds like 'unexport GZIP'''
<kees> yeah
<kees> ah... it's just debuild that had the preserved list...
<TheMuso> aw/
<kees> doko_: how do you avoid dpkg-source -b screaming about your @lists.launchpad.net Maintainer field?
<doko_> kees, oh didn't see it. maybe I should patch it in when generating the control file
<cjwatson> my usual solution is DEBEMAIL=cjwatson@debian.org dpkg-whatever
<cjwatson> then it's just a warning
<cjwatson> we should probably extend dpkg to recognise @lists.launchpad.net as valid for Ubuntu
<TheMuso> 8/c
<kees> cjwatson: I was pondering that, and I'm not sure it makes sense since upstreams (not in Ubuntu) can use that address too
<cjwatson> hmm
<DexterF> can't find a package containing /usr/share/kde4/services/desktopthemedetails.desktop
<kees> cjwatson: i.e. if I set my DEBEMAIL to something non-ubuntu, it will warn?
<DexterF> pointers where I might find that? wanna change the plasma looks on kde4
<cjwatson> kees: rather than error, yes
<ScottK> DexterF: http://packages.ubuntu.com/search?searchon=contents&keywords=desktopthemedetails.desktop&mode=exactfilename&suite=jaunty&arch=any
<DexterF> ScottK: plain weird. I installe kdebase-workspace, shouldn't that have pulled it as a dep?
<ScottK> DexterF: I'd have thought so.  Do you have kdebase-workspace-data installed?
<DexterF> ScottK: actually, yes. but the file isn't on disk. dpkg -L doesn't list it as well.
<ScottK> DexterF: --> #kubuntu-devel
<ScottK> Let's discuss there.
<blueyed> redvamp128: "aptitude changelog linux"?
<slangasek> aw man, why does aptitude keep adding features that lure people into using it
<blueyed> (sry, backlog has not scrolled - and I've typed the nick by name, without realizing) ;D
<elmo> slangasek: they should be using dselect instead?
<slangasek> elmo: synaptic/update-manager > apt-get > dselect > aptitude :P
<azeem> where's package-kit in there?
<directhex> slangasek, you missed the "ar, gzip, tar, & vi" method of debian package management
<blueyed> The question really is, why does apt not support "changelog"? or is there some other tool which allows fetching changelogs?
<slangasek> azeem: between dselect and aptitude, maybe
<directhex> dselectitude. there's a summer project
<azeem> aptitussy
<slangasek> blueyed: because apt-get was always intended to be a back-end tool, except that aptitude as a front-end sucks because its author screws around with the dependency resolver
<blueyed> ..which combines apt-get install and less /usr/share/doc/../changelog.gz
<cjwatson> slangasek: we're likely to be using aptitude for manual package selection in the installer once I get the relevant plumbing working again
<blueyed> slangasek: I've never used the aptitude frontend
<cjwatson> I think the server team would lynch me if I made them use dselect
<cjwatson> ... maybe that should be a hidden preferene
<cjwatson> c
<slangasek> cjwatson: can we arrange to never display the fact that it's 'aptitude'? :)
<slangasek> using aptitude interactively is fine
<slangasek> letting it resolve things on its own is suicide
<cjwatson> the tasksel UI would just say "Manual package selection"
<cjwatson> I don't know whether it says it's aptitude in its UI; I assume it does
<slangasek> yeah
<slangasek> time to patch the .po files ;)
<TheMuso> susudo adduser account-name
<TheMuso> woops wrong window
 * Mez wonders why 1280x960 is no longer a valid screen resolution
<YokoZar> Would anything break if we changed the useragent string in Firefox to identify us as "Ubuntu" rather than as "Linux" ?  Over time, that would allow us to count Ubuntu users much more accurately.
<james_w> Ubuntu is already in the user-agent
<savvas> Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5
<YokoZar> james_w: so how come all the websites publishing browser statistics just say "Linux" ?
<savvas> correct
<james_w> YokoZar: well, there's a difference between OS and vendor
<james_w> presumably they are just recording OS
<savvas> Because we're not that big yet :P And we're a strong community hehe
<YokoZar> Basically I want to count Ubuntu users using this sort of metric: number of people on web times percentage on linux times percentage of linux on ubuntu -- those last two steps could be much more accurate if they just used that data
<YokoZar> admittedly we probably have a disproportionate (compared to other OSes) number of users not on the web, so this would undercount Ubuntu a bit
<ajmitch> why do you think there's a disproportionate number not on the web?
<savvas> YokoZar: so how do you know which company's web site to count?
<savvas> google.com or msn.com search? what if microsoft or google forge numbers to favour something else?
#ubuntu-devel 2009-01-30
<YokoZar> savvas: That's obviously a hard problem, as different websites will have different demographics and some will have incentives to lie.  It's a similar problem to television ratings.  That said, there are groups out there that do try and get wide, representative statistics by polling a whole bunch of different "representative" websites to some extent.  Not surprisingly, their estimates of Linux usage vary, but generally not by mor
<YokoZar> ajmitch: I imagine Ubuntu is more popular in regions of the world where internet access is really awful.  I could be wrong about that though.
<savvas> YokoZar: then the only way is to get out there and ask :)
<YokoZar> savvas: pretty sure polling websites that have millions of visitors is a bit easier than asking millions of people ;)
<ajmitch> I would have thought that at least in countries with more developed infrastructure that ubuntu is more popular amongst the technically literate
<mathiaz> is invoke-rc.d supposed to be run by sysadmin or its usage is mainly reserved for maintainer scripts?
<ajmitch> whether they balance out, I don't know :)
<YokoZar> ajmitch: yeah, it's a good point.  It's not clear at all which way it'll go
<ajmitch> mathiaz: I believe it's to be used by the sysadmin instead of calling the initscript directly
<ajmitch> at least I regularly use it :)
<james_w> mathiaz: it's there so that the admin can enforce policy via. policy-rc.d I believe, so an admin probably knows their policy and doesn't need to use it
<james_w> mathiaz: I don't think there would be an issue with them using it though
<james_w> mathiaz: does kirkland use it for the service command?
<mathiaz> james_w: good question I was looking into that as well
<james_w> mathiaz: nope, he uses calls invoke-rc.d
<ajmitch> the manpage doesn't say anything either way about it, but there is bash completion for invoke-rc.d which indicates that at least a few people use it directly
<mathiaz> james_w: ajmitch: ok - thanks for your input :)
<jelmer> slangasek, I think I've got that grub branch working
<slangasek> oooooh
<jelmer> slangasek, I'll put my copy of the svn repository up somewhere - any chance you can double-check?
<slangasek> jelmer: sure; what am I double-checking?
<jelmer> slangasek, basically the way bzr-svn does the operations on history
<jelmer> http://samba.org/~jelmer/tmp/pkg-grub-svn-log
<slangasek> jelmer: I guess that looks sensible to me; why does it look all svn-y, though?  That would seem to be the opposite of anything I would ever be doing with it
<jelmer> slangasek, this is the svn log
<jelmer> slangasek, not the bzr log
<slangasek> well, yes, I can see that it's an svn log, I just have no idea what that should signify :)
<jelmer> the bzr log just looks like the bzr branch you provided to me
<jelmer> slangasek: these operations match what's being done in bzr
<jelmer> slangasek, If it looks ok, I'll push these changes
<slangasek> jelmer: ok, then I think it looks right from what I can see
<cjwatson> we aren't going to lose the committer information, are we? (noting that all the committers are "jelmer" there)
<slangasek> Keybuk: I like that you uploaded nut to fix the udev rule paths, but didn't notice it was calling udevtrigger :-)
<jelmer> cjwatson: The committer information from bzr will still be there, in revision properties (that bzr-svn will read back)
<jelmer> cjwatson, the person pushing the bzr revisions into svn will be marked as author of those revisions in svn though
<slangasek> jelmer: we never push any of this into svn
<slangasek> not sure if you missed that point?
<slangasek> (or if it matters to what you're doing)
<jelmer> slangasek, it's never been pushed in the past, but you intend to push it into svn now though, right?
<slangasek> no
<slangasek> I don't have write access to the svn repo
<slangasek> and am not seeking it
<slangasek> my concern is being able to /pull/ from svn
<jelmer> ahhh
<jelmer> I misunderstood then, sorry
<slangasek> does that change the scope of the problem?
<jelmer> yeah, I was fixed pushing the current bzr branch back into svn (which is also a nice feature :-)
<slangasek> right :)
<jelmer> s/was//
<jelmer> slangasek: So what is it exactly you'd like to get working?
<jelmer> basically "bzr merge <svn-url>" ?
<slangasek> jelmer: yes
<jelmer> so there are two things I can do
<jelmer> either merge in the existing revisions that were merged in previously. that'll duplicate the revisions in the log (once merged by you, once merged by me)
<jelmer> or I can fix up the revisions that were merged earlier, but that'll change the revision ids of the branch
<jelmer> the latter would require everybody who is using the branch to drop their old copies and refetch the bzr branch
<jelmer> is there either you'd prefer?
<jelmer> slangasek, ^
<slangasek> jelmer: I'm checking whether there are any other branches published on LP that #2 would disrupt
<slangasek> kirkland: do you care if jelmer makes a change that breaks your existing branches on LP?
<slangasek> lool: do you have any outstanding changes based on the LP grub package branch?
<slangasek> jelmer: we might have to wait 18h or so to get those answers :)  I'd prefer option 2 myself, is it ok to wait until we hear back from lool and kirkland before going ahead with this?
<jelmer> slangasek, yeah, no problemo
<TheMuso> Is it just me, or is sudo broken on the latest amd64 alternate CD? I just did a fresh install on a box, to find that /etc/sudoers didn't have the admin group added. Could be either sudo or user-setup.
<slangasek> it shouldn't be user-setup; surely sudoers should ship right out-of-the-box in the sudo package?
<TheMuso> well it appears that the admin group wasn't in sudoers, and I am not in the admin group.
<slangasek> oh
<slangasek> user-setup, then :-)
 * TheMuso enters recovery mode to fix things.
<slangasek> not sure why we don't patch the sudoers generation in sudo itself, though
<pwnguin> fun tip: migrating from ext3 to ext4 changes the partition's uuid
<[reed]> hmm, three kernels just today?
<[reed]> (intrepid)
<dholbach> good morning
<highvoltage> and so it is
<superm1> pitti, i was wondering if i could pick your brain for other ideas you had (but just hadn't implemented) for jockey's package installation method.  since switching to dbus, you lost package the progressive package install status (and support for a vte widget etc).  is that stuff not passable over dbus at all easily?
<superm1> pitti, i'm looking at needing something similar for a rewrite of another application that i've been working on and would like to policykitify it move the installation routines to a dbus spawned service
<superm1> pitti, what i was thinking (but hadn't looked into much yet) was passing the DISPLAY and necessary X auth information over dbus to the service.  if the service could then gain access to the display, it could spawn it's own methods for displaying status, and then when it finishes, send another dbus message telling the client to come back to life
<kirkland> slangasek: hmm, i'm curious what branches in LP would be affected
<kirkland> slangasek: i'll try to read some more back scroll
<kirkland> slangasek: i'm sort of on vacation today in Germany/Austria
<kirkland> james_w: mathiaz is right, i only use invoke-rc.d in /usr/bin/service
<kirkland> jelmer: slangasek: oh, if this would only affect my grub branches, go right ahead...  i don't think i have anything un-merged in there
<pwnguin> what's this about grub?
<kirkland> well, i do have an ubuntu logo'd grub splash screen, that hasn't been merged :-)
<kirkland> but that's fine
<pwnguin> im having a great time with grub and ext4 right now. im assuming currently im doing it wrong
<dholbach> kirkland: where are you hanging out atm?
<kirkland> dholbach: munich atm, heading to innsbruck in a few minutes
<dholbach> enjoy :)
<kirkland> dholbach: cheers, see you in berlin ;-)
<dholbach> take care :)
<pitti> Good morning
<pitti> superm1: I have partial progress report, but it isn't very accurate (just what apt gives me)
<pitti> superm1: no, unfortunately the backend doesn't have any connection to the frontend at all, same problem as with packagekit
<pitti> superm1: passing $DISPLAY and cookie would certainly work, but it's really quite hackish and not really intended to be used that way
<pitti> superm1: what happens in jockey is that the backend sends progress signals to the frontend, and the frontend listens to those and updates the UI accordingly
<pitti> superm1: thus the lack of good progress information is really a packagekit/python-apt problem, not an intrinsic one of d-bus backends
<tkamppeter_> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> piiti, why did you reject bug 321164 for Intrepid? It is exactly this bug which caused the regression in the original SRU. The second SRU fixes exactly this bug.
<ubottu> Launchpad bug 321164 in foomatic-filters "Ubuntu 9.04 has a problem with Laser Printer HL-1435" [High,Fix released] https://launchpad.net/bugs/321164
<pitti> tkamppeter: right, but there was another bug for this regression already, which was reported against jaunty
<tkamppeter> Bug 318614 was originally reported about another segfault which the first SRU perhaps already fixed, but the original poster never answered. Later someone discovered the other problem in 4.0.0 final and hijacked this bug. I told him where "his" bug is to continue discussion there.
<ubottu> Launchpad bug 318614 in foomatic-filters "foomatic-rip crashed with SIGSEGV" [Undecided,Fix committed] https://launchpad.net/bugs/318614
<tkamppeter> What confused you was probably that both bugs are segfaults..
<tkamppeter> The segfault which caused me to fix the SRU was a bug which was perhaps already in the BZR rev 177 which came with Intrepid, but to trigger it one needs a driver which puts at least seven lines of PJL into its output or a PPD with at least seven PJL options. This is rather rare and by accident this was a user who downloaded the first SRU of foomatic-filters. It was not in the code which I added between 177 and 195 (final) but perhaps m
<tkamppeter> y code additions raised the probability to hit it.
<pitti> tkamppeter: the changelog made it sound like it was the same bug
<pitti> tkamppeter: okay, asking for testing on 321164 then
<tkamppeter> pitti, I have already asked for testing there, simply open the Intrepid task and add the tags.
<tkamppeter> pitti, thanks.
<lool> slangasek: I actually have one grub patch in my mailbox, but I don't think it should block any grub upload if that's the reason you're asking
<slangasek> lool: it's not about grub uploads, it's about rebasing the ~ubuntu-core-dev grub branch to fix some bzr-svn brokenness and invalidate any branches based on it
<doko_> slangasek, lool: 299847: only builds because test suite results are ignored. how do you want to track this?
<slangasek> doko_: oh.  Ok, do we have any idea what the root cause is?  Is it really related to this package..?
<doko_> slangasek: no, I didn't check
<slangasek> ok
<slangasek> then reopen it, I guess :/
<lool> slangasek: That's fine, I have the file as a patch
<slangasek> I thought it was a build failure earlier, though, and the version number has only incremented by 1x build?
<lool> Not a branch
<slangasek> lool: ok, thanks
<lool> slangasek: thanks for checking
<slangasek> jelmer: please go ahead with fixing up the repo using method #2
<doko_> retitled and reopened
<seb128> slangasek: hi
<slangasek> seb128: heya
<seb128> slangasek: about your gnome-screensaver issue do you set some im method setting? there is a recent gtk+2.0 similar to your gnome-screensaver one where user state they have issues only when changing im settings
<seb128> I didn't investigate yet though
<slangasek> seb128: heh
<RAOF> So!  Who wants to make f-spot and banshee simultaneously installable?
<slangasek> $ env|grep IM
<slangasek> GTK_IM_MODULE=xim
<slangasek> seb128: ^^
<seb128> slangasek: ok, you can dup the gtk+2.0 bug of yours which was opened before and reassign to gtk+2.0 then ;-)
<seb128> slangasek: check before that you don't get the issue if you unset that
<slangasek> seb128: because the default GTK IM reinvents the wheel on compose sequences - I'd love to not have to set that :P
<slangasek> yep, testing now
<RAOF> bug #314516 has a nice big debdiff for it.
<ubottu> Launchpad bug 314516 in tomboy "gnome-sharp2 transition" [Medium,Confirmed] https://launchpad.net/bugs/314516
<slangasek> dup which bug?
<seb128> slangasek: the newest gtk+2.0 bug in the list if you ignore the installation bugs listed there iirc, let me check
<seb128> just reassign yours to gtk+ if you want
<seb128> I will do cleaning
<slangasek> ok, will test first
<slangasek> seb128: yep, works now :(
<seb128> slangasek: ;-)
<slangasek> hmm, it's possible that I don't need GTK_IM_MODULE set anymore for my env, the compose settings seem to have caught up with iso8859-2
<slangasek> but that's still a pretty big bug for CJK, I guess
<Keybuk> slangasek: I wasn't looking for that at the time ;)
<lool> doko_, slangasek: libipc-sharelite-perl on my armel babbage: All tests successful.
<doko_> lool: maybe it is fixed. re-upload and see if it testsuite results are ok on the buildds?
<lool> pushed
<slangasek> seb128: ok - which direction will you dupe them? I want to make sure the release-manager-y tags are all set right afterwards :)
<seb128> slangasek: I will keep yours open which already has a jaunty task
<slangasek> ok
 * slangasek heads off to bed to get a few hours of shut-eye before the release meeting
<seb128> 'night slangasek
<slangasek> 'night!
<tkamppeter> pitti, what about the CUPS SRU? Can we already put ...ubuntu7 into -updates and let ...ubuntu8 into -proposed?
<pitti> tkamppeter: no, the bug wasn't verified yet
<pitti> cjwatson, Riddell: (preparing release team meeting) -- question about bug 310575, is it in the pipe, or blocked by something?
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575
<pitti> cjwatson, Riddell: sorry, bug 309482
<ubottu> Launchpad bug 309482 in oem-config "jaunty: Kubuntu OEM enduser setup fails" [Undecided,New] https://launchpad.net/bugs/309482
<Riddell> pitti: I've not seen that bug, but I can try and look into it
<tkamppeter> pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify?
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575
<cjwatson> pitti: I'd been planning to today, but of course it would probably be quicker if somebody who knows KDE did so
<lool> doko_, slangasek: Failed on the buildd; it could be a SHM conflict, but this would fail *all* tests, so it might be some missing underlying SHM support; this might be board specific
<lool> I'm trying on my evm
<pitti> Riddell: was there a decision about IRC client in the recent Kubuntu meeting? (for https://blueprints.edge.launchpad.net/ubuntu/+spec/kubuntu-jaunty-kde-packaging)
<lool> doko_: So it passed on my evm as well; I think this kind of renders the bug slightly less important, but it's blocked until we can have a look at the failure in the buildd's environment
<tkamppeter> pitti, it is bug 310575, the one who reported the bug was not available thios week, he will be back only next week. Should we give the next week only to him to verify and release the other fixes for verification only the week after or should we release the other fixes now (superceding the current -proposed package) so that all four bug reporters can verify?
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575
<Riddell> pitti: we want to go for Quassel
<pitti> Riddell: ah, cool; can you please update the spec accordingly? I'll review it immediately, so that we have this off the table
<Riddell> yep
<pitti> Riddell: cheers
<Riddell> pitti: done
<pitti> Riddell: and approved
<tkamppeter> pitti, what about my question concerning the CUPS SRU?
<pitti> tkamppeter: getting to it, still finishing the release report
<lool> asac: FYI ogra tested firefox on armel and it worked fine in his experience (but it was a little while ago)
<ogra> asac, you can test yourself next week :)
<pitti> tkamppeter: yes, I prefer to not stack multiple updates on top of each other; by now, really none of intrepid's bugs are high-urgency
<pitti> tkamppeter: if you want, you can upload ubuntu8 as ubuntu8~till1 into your intrepid PPA and ask reporters to test that (if you are unsure whether the patches really help)
<asac> lool: ogra: thanks.
<tkamppeter> pitti, I think this is not needed. So let us leave this week for getting an answer on bug 310575 and depending on whether we get the answer you advance the CUPS SRU queue on one of your next scheduled SRU day. In the time being I will simply commit SRU fixes as they come to the BZR.
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Undecided,Fix committed] https://launchpad.net/bugs/310575
<pitti> tkamppeter: right; but please keep in mind that we really must slow down SRUs for intrepid; only truly major fixes
<tkamppeter> I hope there are no more SRU fixes needed, though. I think now all issues are covered.
<lool> mvo, seb128: the trigger upgrade issues with libxine segfaulting seem awfully similar to the xine-lib crash we had in intrepid-proposed: under some locales, xine will crash
<seb128> lool: is there any xine code run during the install?
<lool> seb128: There's a trigger related to xine I think
<lool> seb128: There was a security update of xine, it would well have cause the problematic code to be run under a non-C locale
<seb128> lool: ok, I see
<jelmer> slangasek, ok
<kwwii> asac: stupid question, but where does nm-applet keeps it's icons?
<asac> kwwii: http://pastebin.com/fe73ebf2
<kwwii> asac: sweet, thanks
<mdeslaur> lool, seb128: Is there something wrong with the xine-lib security update?
<lool> mdeslaur: The upload I did to -proposed was addressing a crash when xine scans for plugins under some locales; I suspect your security update triggers this bug
<mdeslaur> lool: oh, and you now pushed another to -proposed to fix it again?
<lool> mdeslaur: Yes, but it will take ~10 days
<lool> Since we need to retest
<lool> mdeslaur: Actually we pushed two fixes for this issue, either suffices
<lool> mdeslaur: https://bugs.launchpad.net/bugs/290768
<ubottu> Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed]
<lool> Oh you know about it already
<lool> Since you sent the debdiff there
<mdeslaur> lool: yeah, that's what our procedure is...release a security update without what's in -proposed
<lool> cjwatson, slangasek, pitti: I uploaded langpacks 10 days ago
<mdeslaur> sorry about that
<lool> cjwatson, slangasek, pitti: Might be worth promoting the langpacks to -updates now
<lool> Context: 290768 might have been triggered in a new way via a -security update
<lool> mdeslaur: Not your fault; it's unfortunate but it's a race between fixing the crash and fixing the security holes
<mdeslaur> hehe
<cjwatson> lool: main problem is that there seems to be no independent verification that the new language packs alone fix this
<lool> cjwatson: I sent an update to the TB thread
<lool> cjwatson: I find it weird that the installed xine version is the old -proposed one and the locales don't seem to be either german or italian
<lool> cjwatson: But it's really suspicious
<ogra> asac, hmm, shouldnt FF offer me some gnash or swfdec love if i go to youtube (on armel)
<ogra> all i get is the link to adobe that only offers x86 versions indeed
 * ogra tries video.google.com instead
<ogra> aha, there i get the proper thing
 * ogra wonders if it will ever find something ... still checking for available plugins
<asac> ogra: no
<asac> ogra: yeah. video google works
<asac> ogra: unlikely
<asac> ogra: is armel on archive.ubuntu.com yet?
<asac> or ports?
<ogra> asac, ports
<ogra> and it will stay there
<asac> yeah. we currently dont index those
<asac> hmm
<ogra> oh, we need to
<ogra> lets talk about that next week then
<ogra> there is also a flash for arm (maemo uses it) but not publically downloadable afaik
<asac> ogra: yes. needs a fix of the database updater.
<asac> lpia is also on ports afaik
<ogra> right
<lool> cjwatson: I tried to reproduce the original xine-lib issue in a vm with the it langpack, the it locale generated, and running "xine-list-1.1 --all" under LANG=it_IT.UTF-8 to no luck (I even installed libxine1-all-plugins)
<lool> cjwatson: I suspect it might be ~/.xine/config or similar pointing at additional plugins to load
<lool> I couldn't find a way to trigger more verbose behavior
<lool> cjwatson: So I can't check whether the gxine issue relates
<__Ali__> how can i access the source directory name in debian/rules?
<lool> __Ali__: $(CURDIR)
<__Ali__> lool: $(CURDIR) doesnt work? dpkg-buildpackage extracts the source into a temp dir
<ScottK> james_w: Do you have a moment to discuss your latest changes to your DD/DebianImport spec?
<james_w> ScottK: I have a moment, but little more right now I'm afraid
<james_w> I'm happy to start discussing it, but we may have to take it to email if it's a longer discussion
<ScottK> Sounds good.
<ScottK> james_w: OK.  The concern I have is social, not technical.  I think that while you make a good technical argument for basing the Debian branches off the Ubuntu ones, I think it is likely to be perceived unfortunately in Debian.
<ScottK> If the DistributedDevelopment model is successful, it will be with us for a very long time.
<lool> __Ali__: I'm afraid I don't see what you're talking about then
 * broonie seconds ScottK - that's going to play rather poorly with a lot of people.
<ScottK> And so it seems to me like your proposal, while technically sound, trades short term expediency for a long term source of friction with our major upstream.
<james_w> ScottK: but these branches won't be. Whenever we rewrite, which has to be done at some point, it will end up the right way round
<ScottK> So this is a temporary, experimental set of branches?
<james_w> not so much experimental
<james_w> but it trades short-term expediency for possible medium-term friction
<ScottK> I think the friction will be immediate and ongoing.
<ScottK> You just got some.
<__Ali__> lool: i followed this instruction: http://www.debian.org/doc/manuals/maint-guide/ , it should be valid for ubuntu as well?
<ScottK> james_w: So that's my concern.  Please consider it and we can discuss via email.
<cjwatson> __Ali__: no, dpkg-buildpackage doesn't extract the source into a temporary directory. Some debian/rules implementations do that.
<cjwatson> ScottK: heh, I was just making a fairly similar point to James by /msg :-)
<ScottK> ;-)
<lool> __Ali__: Perhaps you can be more specific in the error you see, which package, what you're trying to do etc.
<ScottK> cjwatson: I've got a thought for you on archive reorg too that I'd like to discuss when you have a moment.
<cjwatson> ScottK: sure
<ScottK> IIRC, the discussion to date on sub-teams has been around seeds.
<ScottK> But in many cases I don't know that will be the best model.
<cjwatson> ScottK: Mark feels quite strongly that we should also have the ability to have layers formed from hand-maintained lists of packages; I don't see that we lose anything by having that flexibility and so the spec does mention that possibility
<ScottK> As an example, currently clamav is in Main and only seeded on Server.  I do most of the maintenance work on that and it's rdepends.
<__Ali__> cjwatson and lool: after running debhelper, I get mylib/debian dir, then i cd to mylib dir and run dpkg-buildpackage, obviously there is no source file in mylib dir which is $(CURDIR)
<ScottK> If I were not a core-dev, but only interested in server, with the current proposal, I'd lose access to upload all the non-server rdepends.
<cjwatson> although there is also no reason we couldn't have extra miniature seed collections that correspond to things like clamav-and-friends
<ScottK> Alternatively, for the Kubuntu team, if someone is good enough to have upload rights to the KDE stuff we ship on CD, it makes no sense they can't upload the stuff that's not seeded.
<cjwatson> __Ali__: your statement is very confusing on a number of levels. The debian/ subdirectory is typically a child of the top-level directory where the upstream package is extracted.
<ScottK> The more I think about what I think are the likely areas of interest, the less I think they are really likely to correspond well with seeds.
<cjwatson> __Ali__: so if upstream ships foo_1.0.orig.tar.gz extracting into foo-1.0/, then you'd have foo-1.0/debian/
<cjwatson> there are plenty of cases that do, and plenty that don't
<ScottK> OK.
<cjwatson> also, you're looking at the current set of seeds which are very very broad
<cjwatson> if we were actually using them for access control, we'd have finer-grained sets, I think
<ScottK> OK.
<__Ali__> cjwatson: foo-1.0/ has only debian, nothing else, do i have to extract the source manually to foo-1.0/?
<cjwatson> __Ali__: normally you would extract the upstream source *before* running dh_make or whatever
<cjwatson> if you've just created a blank directory and run dh_make in that, you're doing it wrong
<__Ali__> cjwatson: i fed the tarball to debhelper, it wasnt extracted initially
<cjwatson> you "fed the tarball to debhelper"? using what command?
<cjwatson> ScottK: I think where the spec says "seeds", my intent was that people think of abstract seeds (i.e. list of top-level packages, dependency-expanded) rather than the ones we have now
<__Ali__> cjwatson: dh_make  -f ../foo-1.0.tar.g
<cjwatson> ScottK: maybe I was underestimating people's mental link with the current model
<ScottK> cjwatson: OK.  That makes sense.
<ScottK> Mine in any case ....
<ScottK> cjwatson: Also I think one should also be able to do reverse dependency expansion.
<ScottK> That would cover most of the cases I was considering.
<cjwatson> __Ali__: the manual page says that it extracts it; but if it doesn't, then extract it yourself
<__Ali__> cjwatson: thanks
<ScottK> cjwatson: For example for the Kubuntu/KDE team, I think it'd be reasonable to describe it's area of interest of the depends of the KDE library packages and all the things that in turn depend on them.
<cjwatson> hmm
<cjwatson> that's interesting, although I would say that it might have unexpected results
<ScottK> It might.
<cjwatson> particularly when you consider source packages that build both GNOME and KDE variants
<cjwatson> I think it's likely to suck in much of the archive
<ScottK> True, but if you think of a team that 'knows how to package KDE stuff', that's what their interest would cover.
<cjwatson> my inclination would be to give the Kubuntu/KDE team the ability to nominate stuff they're interested in, and for the archive admins to be very liberal about acknowledging basically anything with a k at the front :)
<ScottK> Now the ones that support both, then fall into the the multi-seeded set.
<ScottK> I'm using that as an example, but I think it's a general case.
<cjwatson> it's also worth noting that germinate has absolutely no idea how to do this - it would be a complicated development project
<ScottK> It might be that in the overlap case you'd have to look at which way to push it.
<cjwatson> and I'm already aware that this is a complicated project as it is and am striving for simplification
<ScottK> Understand.
<ScottK> Maybe this is a future capability then and we do manual adjustments as needed in the meantime.
<ScottK> cjwatson: So that's my thought.  Up to you what of it you find worth taking up.
<pitti> tseliot, bryce: do you know if there's anything like an ETA for nvidia/fglrx drivers which work with our X.org?
<pitti> tseliot, bryce: i. e. do we have a contact to them?
<tseliot> pitti: I'm working on the nvidia right now
<pitti> tseliot: oh, it's in the open source bits?
<pitti> or upstream has a new release?
<tseliot> new upstream releases
<tseliot> pitti: but I want to make sure that other fixes are included in the new packages before an upload
<pitti> tseliot: rock, thanks (just needed a quick status update for release meeting)
 * pitti hugs tseliot
<tseliot> np
<Amaranth> tseliot: catalyst 9.1 doesn't support the new ABI?
<tseliot> Amaranth: I don't know. You should ask superm1 since he's the maintainer.
<tkamppeter> pitti, can you have a look at bug 323224?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/323224/+text)
<pitti> tkamppeter: in meeting, please subscribe me and ask your question there
<slangasek> mvo: ping
<mvo> slangasek: pong
<slangasek> mvo: hi, did you happen to see my followup to bug #318442?  Do you think my proposal is the right solution?
<ubottu> Launchpad bug 318442 in command-not-found "openjdk-6-jdk should be the default/priority for javac" [Undecided,Confirmed] https://launchpad.net/bugs/318442
<mvo> slangasek: I looked at your changes in bzr
<mvo> slangasek: I agree with your reasoning
<slangasek> ok
<mvo> slangasek: adding it to the database should be fine
<slangasek> cool; I'll try to come up with some code for that in my copious free time then :-)
<superm1> Amaranth, as far as i'm aware it doesn't still.
<mvo> slangasek: nice, thanks. we can do a bit of work on this on the sprint if you want
<slangasek> sounds good
<pitti> slangasek: fix for bug 314263 uploaded, FYI (the "apport opens file:///" one)
<ubottu> Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Triaged] https://launchpad.net/bugs/314263
<slangasek> pitti: sweet \o/
<dholbach> superm1: coolbhavi has updated firmware-tools to 2.1.5 in bug 321866 for jaunty - is that alright?
<ubottu> Launchpad bug 321866 in firmware-tools "Please update firmware-tools to the latest version 2.1.5" [Undecided,Confirmed] https://launchpad.net/bugs/321866
<superm1> dholbach, yeah should be fine
<dholbach> rock on
<dholbach> I'll sponsor it in a bit then
<superm1> dholbach, that reminds me i need to double check on libsmbios to see if debian pulled in the new version too
<superm1> thanks dholbach
<__Ali__> isn't dpkg-source supposed to create the .dsc file?
<__Ali__> it does not generate it for me
<tseliot> __Ali__: debuild -S will do it
<__Ali__> tseliot: debuild?
<tseliot> __Ali__: yes, install the "devscripts" package, then enter the directory with the source and type debuild -S
<tseliot> __Ali__: for further information: https://wiki.ubuntu.com/PackagingGuide/Complete
<__Ali__> tseliot: does debuild call dpkg-source or do i have to call debuild after dpkg-source?
<__Ali__> ok thanks
<tseliot> __Ali__: just use debuild
<__Ali__> tseliot: i dont want to build the package, i just want to create orig.tar.gz and diff.tar.gz and .dsc to upload them to opensuse build service
<__Ali__> i just need to package the source and create the required files, not actually compiling
<cjwatson> debuild -S does what you ask
<cjwatson> as tseliot already told you
<__Ali__> cjwatson: so it doesnt actually build?
<ogra> alternatively dpkg-buildpackage
<cjwatson> no. read the documentation
<tseliot> __Ali__: if you read where it says "Building the Source Package" in that guide you will see why I suggested to use debuild -S
<cjwatson> ogra: just one option I think, to avoid confusion
<__Ali__> ok ok
<fta2> is there a known problem with sasldb2? it makes sendmail-mta crash so no SMTP AUTH is possible (jaunty)
<fta2> hm, sasldblistusers crashes too
<bluefoxicy>   PID USER      PR  NI  VIRT  RES  SHR S PU %MEM    TIME+  COMMAND
<bluefoxicy> 30779 root      20   0 2296m 2.2g 4756 R   98 59.5   7:12.21 rsvg-convert
<bluefoxicy> as soon as I get logged in, I hit 100% usage OF 4 GIGS OF RAM
<bluefoxicy> oh, my fault.  It's boot chart throwing a fit.
<maxb> Hrm. screen-profiles has tweaked my .screenrc without informing me what it was doing. I find that a little intrusive
<bluefoxicy> how long is this supposed to take?  bootchart is still eating several gigs of RAM generating a chart of boot o_O
<bluefoxicy> wait, it just flatlined at only 1 gig of RAM and 100% CPU,ok.
<bluefoxicy> <_< finished in almost 13 minutes of full-utilization CPU time
<kees> pitti: what is dhcp3 upstream's position on interface-mtu?
<pitti> kees: oh, hang on; I just checked again, and it seems that upstream's default is actually to not request it
<pitti> kees: it was done in debian bug 372689
<pitti> bdmurray: ^
<pitti> kees: seems I don't quite remember any more then
<ubottu> Debian bug 372689 in dhcp3-client "default dhclient.conf does not request interface-mtu" [Wishlist,Closed] http://bugs.debian.org/372689
<bdmurray> I found some discussion about it - https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024845.html
<kees> okay, so we'll follow suit and stop requesting it?
<pitti> kees: as I said, fine for me
<kees> cool
<cjwatson> err. on my network I *have* to use interface-mtu or things randomly break.
<cjwatson> why are we dropping it?
<cjwatson> I can't be the only one, I'm sure
<pitti> hah
<cjwatson> I know that there are some silly MTUs advertised (as I mentioned in that post), but surely we could just tweak the "insane" range
<pitti> that's what I meant with "damned if you do, damned if you don't" :(
<pitti> cjwatson: that's the problem, 576 isn't "insane" at all
<pitti> (I think)
<pitti> the lowest legal one is 68
<cjwatson> no - although it is the absolute minimum allowed
<cjwatson> is it?
<pitti> which of course is unrealistic for today's systems
<pitti> cjwatson: just parroting the manpage (dhclient.conf)
<pitti> dhcp-options, I mean
<cjwatson> from the point of view of somebody who actually needs an MTU of 576, there is no difference between us not requesting the MTU at all and ignoring MTUs less than (randomly) 1000
<pitti> cjwatson: which one do you need for your system?
<cjwatson> 1380
<cjwatson> err, I think
<kees> it seems there are a large number of people for which requesting interface-mtu breaks their network.  given this, I'd advocate following upstream, which also matches what Ubuntu has always done (excepting intrepid)
<Lure> any X developer around? I raised priority of bug 322155 as it is nasty regression...
<ubottu> Launchpad bug 322155 in xserver-xorg-input-synaptics "laptop touchpad button shows unreliable behaviour after package upgrade in Jaunty" [High,Confirmed] https://launchpad.net/bugs/322155
<cjwatson> kees: what MTUs are these people getting?
<kees> 576.
<bdmurray> cjwatson: I've gotten 576
<kees> on comcast
<cjwatson> kees: honestly, I think there are plenty in the other direction too, who obviously aren't speaking up right now because their network works
<cjwatson> kees: is that consistent? if so, s/576/577/ in dhcp3 and people will be happy
<RainCT> mvo: hey
<kees> cjwatson: i.e. ignore 576 as a response?
<cjwatson> kees: I would rather that we tried harder to find a working compromise, than flip-flopped between breaking different people's networks from release to release
<cjwatson> kees: yes
<cjwatson> we already ignore <576, it's only a one-byte leap :)
<kees> cjwatson: hm, well it seems it would certainly unbreak comcast
<pitti> cjwatson: (s/68/577/, but all the same)
<pitti> well, not quite
<pitti> we don't want to lock out people who do need < 576
<kees> seems like a config option is best?
<cjwatson> $ grep 575 debian/dhclient-script.linux
<cjwatson> if [ -n "$new_interface_mtu" ] && [ $new_interface_mtu -ge 575 ]; then
<cjwatson> pitti: ^-
<cjwatson> pitti: are such people shouting about the problem right now?
<RainCT> mvo: adding PPAs requires quite some clicks now (get to the key, copy it to a file, import it..), so what do you think about adding an option to apturl to enable an additional repostitory (also adding its key)?
<cjwatson> because they should be - we're already locking them out
 * ScottK has seen 1 second dhcp cycling sometime on Verizon FIOS too.
<kees> (i've seen some reference to 576 being a dialup setting hm)
<cjwatson> we could be cleverer yet - allow 576, but only if it's a PPP interface
<cjwatson> oh, no, that doesn't help DSL
<cjwatson> still, I do think we should be trying harder here rather than alternately giving up in one direction or the other!
<cjwatson> perhaps we could make it work for NM-managed interfaces
<cjwatson> given that NM should know more about the connection type
<kees> hm, sounds like "dial" really means "19200 or lower serial and X.25"
<kees> and for serial, it sounds like it's just a patch for latency issues
<cjwatson> well, the effect of having a higher MTU than you ought to is (in practice) that web pages sometimes work and sometimes randomly stall
<kees> cjwatson: I think we're safe with the 577 or higher
<cjwatson> particularly if it's only slightly higher, as in my case
<kees> from the looks of it, people wanting 576 have already configured their interfaces to 576, so ignoring the interface-mtu sent of "576" is fine, since they'll already be at 576.
<cjwatson> do dialup tools know to force the MTU to 576?
<kees> it appears to be strictly a latency preference; there's no protocol reason I've seen yet to drop it to 576.
<kees> cjwatson: e.g. http://www.tldp.org/HOWTO/text/Leased-Line
<cjwatson> except for UDP, as mentioned there, since it can't be fragmented
<cjwatson> so for UDP you do want to have a reasonably accurate MTU, although I suppose that also depends on the application
<kees> right, the discussion on mtu focuses around interactivity not protocol reasons.  in fact, they recommend trying to use 1500 because of the UDP issues.
<kees> i.e. I think we're safe requiring higher than 576.
<kees> (in dhclient)
 * cjwatson nods
<cjwatson> cool
<kees> shall I patch dhcp3 or does someone else have an update in progress?
<maxb> Where do I report paste.ubuntu.com breakage?
<jpds> maxb: rt AT ubuntu.com
<Keybuk> bryce: I have an interesting bug on jaunty
<Keybuk> well, actually, I'd go as far as to describe jaunty as a collection of interesting bugs, _but_ ...
<Keybuk> this one is with the X server
<ogra> like ctrl-alt-bkspc stopped working ?
<ogra> :)
<Keybuk> no, thanks to Mark talking to Aberto and managing to cc everyone in core-dev, I knew about that ;)
<Keybuk> this one is that the X server uses 50-100% of the CPU continuously
<ogra> yeah, its quite annoying to use the branch notification for it
<Keybuk> fortunately it's logging things to Xorg.0.log
<Keybuk> what is says is
<Keybuk> "Oh, a monitor"
<Keybuk> "Oh, a monitor"
<Keybuk> "Oh, a monitor"
<Keybuk> (I'm paraphrasing here)
<bryce> Keybuk: sounds like you've got some app polling the xserver with XRandR queries
<bryce> Keybuk: https://wiki.ubuntu.com/X/Troubleshooting/HighCPU
<pitti> Keybuk: happens when you pull the power plug and run on battery, for example?
<Keybuk> I am on battery, yes
<pitti> Keybuk: that's been reported and argued since last UDS, when it happened the first time
<pitti> Keybuk: bug 307306
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306
<Keybuk> pitti: yes, killing gnome-power-manager does help ;)
<Keybuk> that just made everything funny
<maxb> Keybuk: There's a workaround patch that you can apply to gnome-desktop which changes from eating all of one core continuously to eating too much CPU for about 2-3 minutes whilst g-p-m initializes
<Keybuk> that doesn't sound like a fix
<maxb> No, but it helps you actually manage to use Jaunty to do other work
<Keybuk> I just killed gnome-power-manager
<Keybuk> which turns out to make suspend work again
<LaserJock> any dutch (or whatever NL is) speakers around?
<cjwatson> nl is Dutch, yes
<BUGabundo> apw: ping
<BUGabundo> apw bug 319505
<ubottu> Launchpad bug 319505 in linux "In Jaunty Alpha3 release 32 bit and 64 bit versions the sound is not work." [Medium,Invalid] https://launchpad.net/bugs/319505
<LaserJock> nvm, google did it for me
<BUGabundo> apw its looking like a regression
<BUGabundo> the change mess my system
<pitti> calc: wrt. bug 305790, do we actually still need jaxme and xom? apparently current OO.o builds fine without them?
<ubottu> Launchpad bug 305790 in suitesparse "MIR - move to main for openoffice.org 3 build-depends" [Undecided,Fix released] https://launchpad.net/bugs/305790
<pitti> calc: oh, nevermind, they were temporarily promoted to get it to build, but they still need to be fixed
<pitti> bryce, tjaalton: how come that xserver-xorg-input-vmmouse wants to go to universe?
<Keybuk> hmm, now compiz is dog-slow :-/
<pwnguin> heh
 * Keybuk likes how everything breaks just before the sprint
<Keybuk> (or any other travel, for that matter)
<pwnguin> presumably it has to do with what scottK mentioned
<ScottK> That's been for a while now.
<Keybuk> what did ScottK mention?
<pwnguin> http://www.kitterman.org/ScottK/2009/01/bug_254468_momentary_video_gar.html
<ScottK> The Fedora xorg-server patch that was dropped (finally) in Jaunty.  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468
<ubottu> Launchpad bug 254468 in xorg-server "MASTER: momentary video garbage upon drawing new objects (particularly in KDE)" [High,Confirmed]
<tjaalton> pitti: looks like -input-all no longer depends on it.. I'll investigate
<Keybuk> I'm not sure I'd describe this as lower performance
<Keybuk> taking eight seconds to switch a workspace at the moment
 * cody-somerville is still running hardy.
<isaac> yeah, i have had to disable compiz completely
<isaac> with an up-to-date jaunty
<maxb> huh, what video hardware, I have it working fine on an nvidia, an ATI (with radeonhd), and an intel
<Keybuk> intel
<isaac> intel here too, 945GM
<isaac> but well, in alpha-3 it made my computer hang completely
<isaac> so it's getting better :P
<maxb> egads, it's a lot worse on my intel than I remember it being a few days ago
<tjaalton> Keybuk: it's a bug in drm, you can work around it by disabling vblank, see bug 320813
<ubottu> Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813
<isaac> tjaalton: awesome
<tjaalton> I've got a patch for the kernel which fixes it for me, but upstream is still fighting if it's the correct fix
<syldeb35> Une partie de messagerie musicale a Ã©tÃ© demandÃ©e. Veuillez cliquer sur l'icÃ´ne MM pour l'accepter.
<Keybuk> tjaalton: random Q - we're not using GEM yet, are we?
<tjaalton> Keybuk: sure are
<Keybuk> ahh, but KMS comes in the next release with .29+ ?
<tjaalton> yes
<Keybuk> hmm, I need to restart X after the .drirc ?
<tjaalton> GEM came with .28, enables DRI2 (but only if using UXA, not EXA which is the default)
<tjaalton> .drirc doesn't work, you need to put it as /etc/drirc
<Keybuk> do I need to change the driver="i965" to driver="i945"
<tjaalton> debian will release mesa 7.3 in a moment, so we might just disable vblank again until the patch is in the kernel
<grndslm> Could anybody help me figure out how to set Ubiquity's first three variables (English, Chicago, USA) and not have the program ask for them??
<tjaalton> Keybuk: actually, the dri driver is i915
<tjaalton> for you
<Keybuk> ah, that works
<Keybuk> thanks
<grndslm> I'm assuming to accomplish my goal, I'll need to download the source for ubiquity??
<grndslm> i tried looking at /usr/bin/ubiquity & ubiquity-dm ... but they didn't look like what i was really after
<Keybuk> grndslm: you can use debconf seeding for that, I believe
<grndslm> Keybuk: care to explain?
<grndslm> never heard of that
<Keybuk> https://wiki.ubuntu.com/Ubiquity/Automation
<grndslm> Keybuk:  thanks!!
<Keybuk> and try google "ubuntu preseed"
<Keybuk> basically any question asked, you can pre-supply the answer
<Keybuk> including questions that you didn't realise were asked, because ubiquity was already giving the answer
<grndslm> Keybuk: most of this preseeding stuff has to do with debian-installer... are you sure it works with ubiquity?
<ogra> ubiquity is a frontend to debian-installer
<cjwatson> https://wiki.ubuntu.com/Ubiquity/Automation is specifically about ubiquity ...
<cjwatson> actually, I think there's better documentation than that
<grndslm> hmm... never realized that... thought d-i actually unpacked/installed packages, whereas ubiquity just copied the filesystem
<grndslm> that wiki doesn't get too much into instructions, tho
<ogra> heh, the spec is still pending approval :)
<cjwatson> hah
<cjwatson> https://wiki.ubuntu.com/UbiquityAutomation
<cjwatson> a single character makes a big difference
<grndslm> cjwatson:  thanks a bunch!
<cjwatson> grndslm: yes, that part of d-i and ubiquity is of course entirely different; but much of the configuration code is shared
<grndslm> sweet... learn somethin' new everyday
<cjwatson> you do need to run with the automatic-ubiquity flag, otherwise all you'll achieve is setting different defaults but still having the questions asked :)
 * ogra ponders how to fit all the HW in his trunk
<ogra> .oO( and i thought working with mobile makes everything become smaller )
<ScottK> bryce: alt-sysrq-k isn't new is it?  It doesn't do anything on my Intrepid latop.
<mvo> lool: do oyu have any idea about the crash in gxine (bug #323316)?
<ubottu> Launchpad bug 323316 in gtk+2.0 "package libgtk2.0-dev 2.14.4-0ubuntu2 failed to install/upgrade: package libgtk2.0-dev is already installed and configured" [Undecided,Incomplete] https://launchpad.net/bugs/323316
<tjaalton> ScottK: what about altgr?
<tjaalton> ScottK: and do you use dvorak?
<bryce> ScottK: alt-sysrq-k has been around quite a while
<bryce> heya ogasawara
<ogasawara_> bryce: hiya
<ScottK> tjaalton: No, regular qwerty.
<ScottK> Not sure what key altgr would be?
<ScottK> bryce: IIRC I saw at least one other reference to it not working in the discussion.  I think maybe we ought to understand more about how widespread it's working is before we declare victory
<pochu> ScottK: the one next to the space, on the right
<pochu> probably not on US keyboards I think
<davertron> hi, can anyone help me out with a postfix install on intrepid?
<redvamp128> davertron:  I sent you here and since these guys develop here-- they should know how to debug-- kernel panics
<redvamp128> I am actually curious myself
<davertron> it looks like the issue is i'm not using postfix or something
<davertron> that's what the guys in #postfix said anyway :)
<davertron> must be even after installing postfix with apt-get, the MTA is different or something
<redvamp128> though I have only had one thus far on ubuntu -- but only with 8.10 though
<davertron> i'm still trying to keep up with all of the mail acronyms...
<rbrunhuber> davertron: Did you already write a bugreport about this?
<davertron> kernel panics?
<davertron> am i the right person?
<davertron> ha
<davertron> was the error i reported a kernel panic?
<ScottK> #ubuntu-server is a much better place for this discussion.
<redvamp128> however though for me-- I just booted to the prior one and deleted the link to the current one- then the next update it didn't
<redvamp128> Though since then I have went back to 8.04 which is now 8.04.2 and stable as can be
<lamont> davertron: this would be the channel to discuss your patch for fixing whatever you found, #ubuntu-server would be a better place for getting help with an unknown issue
<JacobBrown> Hi.  I'm making an ubuntu package for the software I'm working on, and I'm wondering how ubuntu has the mysql server setup so that my post install script can install the user/database/schema for my application
<Amaranth> hrm
<Amaranth> someone said my name, it fell off my scrollback
<maxb> JacobBrown: request-tracker3.6 is a package which does this. You may be able to use it as a guide.
<maxb> 16:23 < superm1> Amaranth, as far as i'm aware it doesn't still.
<maxb> (That's UTC)
<Amaranth> yeah, I got it already, thanks though
 * maxb hugs irssi /sb search
<Amaranth> I have a funny feeling we're going to end up with a 'private' beta of fglrx again
<TheMuso> /c/c
<maxb> The lack of the regular monthly releases for the last two months doesn't seem to bode well, does it :-/
<Laney> Anyone seen unupgradability with latest vim from -security? http://pastebin.ubuntu.com/111877/
<jdstrand> Laney: please file a bug
<Laney> jdstrand: Sure, I'm just doing it. I just wanted to smoke test
<jdstrand> though I have not seen that problem myself
<Laney> jdstrand: bug 296324 is similar
<ubottu> Launchpad bug 296324 in vim "dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed" [High,Fix released] https://launchpad.net/bugs/296324
<Laney> can probably steal the fix from there
<Laney> jdstrand: bug #323381
<ubottu> Launchpad bug 323381 in vim "[intrepid] Cannot upgrade between vim-{tiny,runtime} 1:7.1.314-3ubuntu3 to 1:7.1.314-3ubuntu3.1" [Undecided,New] https://launchpad.net/bugs/323381
<jdstrand> Laney: thanks!
<Laney> I'll knock up a debdiff for the conflicts if you think that's correct?
<jdstrand> Laney: feel free to post it in the bug with your findings. It sounds like it existed before the security fix, so it'll likely be an SRU
<tjaalton> ScottK: so none of the sysrq shortcuts work for you? is it a mac?-)
<LaserJock> tjaalton: what's the one to kill X
<ScottK> tjaalton: It's a Dell Latitude D430.
<LaserJock> I thought I tried it an it almost crashed my machine by taking ~50 screenshots
<tjaalton> LaserJock: alt+sysrq+k
<tjaalton> it'll kill every process on the current VT
<LaserJock> tjaalton: ok, then it doesn't work for me either
<tjaalton> tough :)
<LaserJock> heh
<bryce> do we have kernel bug reports open yet on these sysrq-no-workee issues?
<tjaalton> LaserJock: one combo should print the help screen.. you could try it on a VT
<tjaalton> a sec
<tjaalton> to see if it works on the console but not X
<LaserJock> hmm, I see if I can get a VT, most often I can't
<LaserJock> that's the other problem
<tjaalton> KMS ftw
<LaserJock> I rely on the 3-finger-salute because most often I cant get a VT
<LaserJock> tjaalton: ok, from a VT it changes the log level
<tjaalton> hmm
<LaserJock> on my machine sysrq is acting like prtscrn
<LaserJock> so I hit alt-sysrq and it takes a screenshot
<andersk> Go to console 1 (Ctrl+Alt+F1) and try again.
<tjaalton> I need to use altgr
<tjaalton> on my laptop
<LaserJock> andersk: what do you mean? that's what I did and it changes the log level
<LaserJock> or are  you saying I need to do it twice?
<LaserJock> part of the problem may be that sysrq on my laptop is a function key
<ScottK> tjaalton: I think if it's one of several possibilities it's not a reasonable substitute for ctrl-alt-backspace,
<LaserJock> so I actually press Alt-Fcn-Del-k
<ScottK> LaserJock: It's a function key on mine too.
<ScottK> Mine is Fn-F11-Alt-k
<ScottK> Fn/Fcn
<LaserJock> argg, that's awful, stupid screenshots :-)
<ScottK> bryce: No.  I didn't file bugs.  This discussion I didn't even know about the 'feature'.
<LaserJock> ScottK: same here
<hyperair> mine's fn+screenshot so multiple windows of gnome-screenshot open when i try to use it
<dtchen> LaserJock: keep in mind that on some hardware you need both r and k sysrq
<hyperair> i mean fn+printscreen
<LaserJock> I didn't know I had a sysrq key
<dtchen> LaserJock: (and in such cases, bug reports are much appreciated; those are kernel issues)
<ScottK> dtchen: All the more reason this isn't a user appropriate alternative.
<LaserJock> hyperair: mine is the same but they're different keys
<LaserJock> dtchen: what does that mean? Alt-sysrq-k-r ?
<dtchen> ScottK: fixing bugs in the stack(s) are going to cause regressions, but they need to be fixed. if dontzap is a step toward it, then we'll have to suffer.
<dtchen> (oh do i know the pain in the audio realm)
<Laney> cjwatson: You might be interested to know that the conflicts mentioned in the changelog to bug 296324 don't seem to have made their way in (http://git.debian.org/?p=pkg-vim/vim.git;a=commitdiff;h=f0116b4ca5a40a2147c6ccc01abd0e013fea0295)
<ubottu> Launchpad bug 296324 in vim "dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed" [High,Fix released] https://launchpad.net/bugs/296324
<dtchen> LaserJock: alt+sysrq+r then alt+sysrq+k
<tjaalton> ScottK: well, alt works now. no need to use fn even though the key might suggest that
<slangasek> ScottK: well, I knew about Alt+SysRq+k, but I didn't know until now that it only killed things on the current VT
<dtchen> LaserJock: (and, as tjaalton alluded to, you probably need to use altgr)
<LaserJock> dtchen: what's altgr?
<tjaalton> dtchen: not anymore
<slangasek> but anyway, SysRq+K as a method of killing X toasts my VTs, so that's not nice
<tjaalton> slangasek: on intel? sometimes yes, not always
<ion_> That probably should not happen anymore after kernel mode setting has been implemented everywhere.
<LaserJock> at this point I can't imagine that recommending alt-sysrq+k is a good option
<ScottK> It really doesn't seem suitable, but I need to go get ready for the KDE 4.2 release party.
<LaserJock> dontzap sound like the best
<slangasek> tjaalton: that it does it at all appears to make it an inferior choice in comparison with Ctrl+Alt+BkSp
<slangasek> ion_: which isn't happening this cycle, at least
<ion_> Yep
<tjaalton> slangasek: well, it's still there. who needs VT's anyway :)
<slangasek> tjaalton: the very people who are trying to debug the X problems that cause them to need to kill the X server?
<tjaalton> slangasek: are you sure zapping doesn't mess the VT's?
<tjaalton> maybe I'll do some testing.. bbl
<LaserJock> does anybody know what xorg upstream's rationale was for removing zapping?
<LaserJock> was it that alt-sysrq-k was available, or that X never needs killing, or ...
<slangasek> tjaalton: when I had occasion to use it in intrepid, it didn't break my VTs
<LaserJock> it seems like it must have been more drastic than "people accidentally zapp X"
<slangasek> you're saying "people accidentally pressing a key combo that loses their current session and not knowing why" is insufficient reason to be dissatisfied with the status quo?
<LaserJock> no
<LaserJock> I mean, that's a keybinding issue, not a feature issue, it would seem
<LaserJock> so I can totally understand "dang, this is too easy to hit"
<LaserJock> but "yeah, nobody needs to kill X anyway" is a bit different
<LaserJock> seems like fixing the wrong problem
<slangasek> it is fixing the wrong problem
<slangasek> that doesn't imply upstream had a more cohesive rationale for the change...
<LaserJock> most people I've talked to accidently hit it because they us Ctrl-Alt a lot
<LaserJock> I just wondered
<tjaalton> slangasek: so, it seems like a bug in the intel drm driver then
<tjaalton> the suse patch was proposed to upstream, and they rejected it
<tjaalton> this was discussed Sep-Oct '08
<tjaalton> LaserJock: and it wasn't removed, the default was changed
<__Ali__> why is dh_install commented out in debian/rules?
<tjaalton> some still believe it was removed completely..
<__Ali__> is dh_install necessary for the actual binaries to be included in deb?
<LaserJock> tjaalton: I thought it was removed and we patched it back in
<bryce> tjaalton: yep.  And I notice many are misperceiving that xorg upstream removed it, and it was Ubuntu that patched it back in
<LaserJock> __Ali__: try #ubuntu-motu
<__Ali__> ok
<bryce> LaserJock: nope.  What we're carrying currently is 100% what upstream provides, no patches.
<LaserJock> bryce: that's what was floating around at UDS
 * LaserJock notes if people would publish UDS results a bit better things might be clearer
<tjaalton> hm, an unfortunate misconception
<fta> pitti, is apport broken? I wanted to report a crash, i got an url like: file:///ubuntu/+source/cyrus-sasl2/+filebug/PBwouks3QeVaVpymxUTDGODffC while it should be launchpad or something
<dtchen> slangasek: before i propose bug 107687 for hardy, what are your thoughts? should i push a patch to BTS and into jaunty, first? (the reason i haven't done so is because none of the supported Debian versions have the older xfonts-scalable that hardy does.)
<ubottu> Launchpad bug 107687 in xfonts-scalable "missing versioned dependency of xfonts-utils aborts distribution upgrade from dapper/edgy at xfonts-scalable" [High,Fix committed] https://launchpad.net/bugs/107687
<slangasek> dtchen: bugs should certainly be fixed in jaunty before being proposed for SRUs
<slangasek> or if there's a reason not to fix it in jaunty (the upgrade issue may no longer be applicable for instance), then 'wontfix' it for jaunty and explain why in the SRU request
<dtchen> slangasek: ok, i'll use the wontfix, then. thanks.
<andersk> fta: bug 314263?
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/314263/+text)
<fta> d'oh
<fta> andersk, thanks, i'll have a look
<dtchen> slangasek: my main concern is the versioning; 1:1.0.0-6 is in gutsy, hardy, intrepid, and jaunty, which makes that approach hairy
<comradekingu> My tracks are listed multiple times in the new rhythmbox
<slangasek> dtchen: ah; in that case we could upload to hardy-proposed, and when it's validated we can down-copy to the later releases
<dtchen> slangasek: ok, great
<comradekingu> Rhytmbox 0.11.6svn20081008-0ubuntu4.3 (intrepid-proposed)
<fta> anyone using sasl2 here?
<fta> bug 323409
<ubottu> Launchpad bug 323409 in cyrus-sasl2 "sasl2-bin broken, segfaulting during install" [Undecided,New] https://launchpad.net/bugs/323409
#ubuntu-devel 2009-01-31
<Bsims> Ran into an error upgrading I am not sure what package caused it but I got a segfault and then this upon recomended fix"dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed."
<Devin_M> can someone here help me?
<Bsims> Anyone have any clue
<Bsims> whats up Devin_M
<Devin_M> do you know of a good programming language easy to learn and good support in ubuntu?
<Bsims> Devin_M: perl or python
<Devin_M> do you know of any good tools for ubuntu? compilers and such
<Bsims> Devin_M: apt-get install build essential
<Bsims> and get used to installing package-devel
<Bsims> er -dev
<Devin_M> okay, so just install build-essential, but wht do you mean by "get used to installing package-devel"
<Bsims> Well the headers used to build a package from source are packaged seperate from the deb
<Bsims> for example gnomelibs don't contain the headers needed to complile a gnome program
<Devin_M> still not following, sorry, new to linux
<directhex> Devin_M, what do you use to program currently?
<Devin_M> uh, I just want to learn, my only realy experience is with vb in windows
<Devin_M> and a little c/c++
<directhex> vb6 or vb.net?
<Devin_M> 6
<Devin_M> I think
<Devin_M> I'm pretty sure
<Devin_M> but just school stuff
<Devin_M> nothing big
<Bsims> Devin_M: try bash to start out with, then perl
<Devin_M> bash?
<directhex> this isn't really the place for the question
<Devin_M> I thought that stood for born again shell?
<directhex> and it's a "which is better, cat or dog" question too
<Devin_M> yeah, I know, but I just wanted to start somewhere
<directhex> ubuntu has environments for loads of programming languages. easily tens, if not a hundred. what you want to use depends on the task at hand, and personal preference
<Devin_M> I thought here was convenient
<directhex> i'd advocate c#. people might disagree
<savvas> Devin_M: here's a forum post with various tutorials: http://www.ubuntucy.org/forum/viewtopic.php?f=22&t=708#p3569
<savvas> see which one seems better/easier for you
<Devin_M> okay, thanks a lot, I really appreciate it
<savvas> and since you're new, don't forget the ubuntu guide book: http://www.ubuntupocketguide.com/
<savvas> thankfully the author provides a free pdf :)
<Devin_M> yeah, I was just about to look at it, but I don't think I have and pdf viewers installed other that ooo
<savvas> in ubuntu?
<savvas> you have pre-installed pdf viewers
<directhex> evince.
<Devin_M> oh, oka
<Devin_M> okay*
<Devin_M> good to know
<Devin_M> is bash the same as the terms and commands used in the terminal?
<kolby> is there a REVU channel?
<kolby> #revu didn't work
<mrooney> kolby: I think you want #ubuntu-motu
<kolby> thanks
 * lamont pounds his head on the desk
<lamont> so... how do I convince d-i that the install of the base system succeeded, now that I've finished doing its job for it?
 * lamont pokes slangasek 
<slangasek> um
<lamont> seems that 8.04.2 lacks linux-restricted-modules$mumble-hppa32, so the install FAILS
<slangasek> hotwiring the postinst of whatever script was supposed to do it?
<lamont> yeah. it's the "whatever script" that's the question
<slangasek> base-setup, maybe?
<lamont> outside the /target, yes?
<slangasek> yes
<lamont> bootstrap-base
<lamont> run_waypoints base-installer/progress/installing-base
<lamont> ^^ now how do I get it to forget that a step failed, I wonder
<lamont> Installation complete
 * lamont checks for LYING
<lamont> [17179577.264000] VFS: Cannot open root device "md0" or unknown-block(2,0)
<lamont> hrmpf
<lamont> clearly I'll need to get my duct tape out in a bit
<tag> I don't know what fix exactly it was that you pushed out in the last 48 hours, but it stopped this constant problem I've been having for the last year with my system running incredibly hot.  So, thanks!
<Hobbsee> (you're welcome)
<Mithrandir> hi Hobbsee
<Hobbsee> hey there Mithrandir!
<cjwatson> Laney: I believe that the conflicts were superseded by a different solution (maintainer script hacking)
<cjwatson> Laney: but if you notice that the conflicts are present in the *current* Debian package but not in Ubuntu, by all means file a bug ...
<ebroder> Hmm...so hardy-backports has Xen 3.3, but ubuntu-xen-server in hardy explicitly depends on Xen 3.2 components. Who gets the bug? Backports? The xvm-meta package?
<Hobbsee> ebroder: backports
 * Hobbsee mumbles about crackports, and how stuff's obviously not getting tested properly before going through?
<Hobbsee> ebroder: basically, if it's not a problem with the latest release (usually the release it was backported from), it's a bug for backports.
<ebroder> Ok. And...if I'm going to propose a fix, what should I use for a version number? Hardy has 0.0.1-2ubuntu8, and Intrepid has 0.0.1-2ubuntu9, so 0.0.1-2ubuntu8hardy1 or something?
<ebroder> (Also, why on earth isn't this a Debian-native package?)
<Hobbsee> ebroder: 0.0.1-2ubuntu9~hardy1 is the usual convention, as far as i know
<Hobbsee> (no idea on why it isn't native, i don't deal in xen)
<ebroder> Ok
<mnabil_work> guys , is there an application or a framework for building ubuntu from source ?
<ion_> For what purpose?
<mnabil_work> as i wanna to trim down package dependencies
<mnabil_work> ion_, development and customization purposes
<mnabil_work> ion_, any idea ?
<daan> hey, i need some help
<jelmer> are bzr looms a valid patching system ?
<emgent> someone saw google ?
<G__81> i installed Ubuntu 8.10 for the first time and i am really impressed. Great Work Guys. I see a big difference between this and Fedora as i ve been a long time fedora user
<G__81> Keep up the Great work
<ziroday> Hi, does anyone know what might have happened to the welcome slideshow that was supposadly targeted for jaunty according to http://brainstorm.ubuntu.com/idea/136/ or who I might want to talk to?
<superm1> ziroday, as far as i'm aware, it's still targeted for jaunty.  you'll want to check with evand sometime during the week (UK work hours)
<ziroday> superm1: awesome, thanks!
<DktrKranz> cjwatson, re bug 323413, it seems it hasn't been synced correctly, I still see old version in LP.
<ubottu> Launchpad bug 323413 in missingpy "Please sync missingpy 0.10.0.2 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/323413
<ScottK> jelmer: I wouldn't think so.
<ScottK> jelmer: Although if you wrote sufficient documentation in README.Source, it might.
<jelmer> ScottK: Ok, so no particular reason other than the fact that it's not listed atm?
<ScottK> jelmer: It's not really a patch system.
<sharperguy> anyone here know if/when we might see python3-tk in jaunty? (sorry if this is the wrong place to ask)
<jelmer> ScottK: Looms? They're pretty similar to quilt, just more integrated with the VCS
<ScottK> I don't really know about them as I'm a pretty basic bzr user.
<ScottK> One can use a lot of different tools, but using relatively obscure ways to solve common problems is not, IMO, generally good.
<ScottK> It makes it harder for whoever comes along next to touch the package.
<jelmer> ScottK: Well, Ubuntu seems to be moving in this particular direction
<ScottK> We have future plans, but I don't recall looms being mentioned in the specs.
<jelmer> NoMoreSourcePackages mentions  it
<ScottK> OK.   I missed that then.
<ScottK> Today, stuff like that will narrow the range of people who will/can work on the package.
<ScottK> The future is likely to be different.
<cjwatson> DktrKranz: I forgot to flush that batch into the queue. In progress now.
 * DktrKranz hugs cjwatson, sorry for bothering you during weekend
<cjwatson> jelmer,ScottK: I would say that since it's perfectly valid to use no patch system at all, it's also valid to use looms, *provided* that you take responsibility for merging in changes made by people who don't know how to drive it.
<cjwatson> (i.e. people might upload changes not represented in the loom)
<ScottK> cjwatson: Sounds reasonable to me.
<cjwatson> there are probably people today who have packages in a revision control system which isn't publicly usable, which is sort of equivalent (I certainly do for some of my Debian packages, although I'm trying to move them all to bzr)
<ScottK> Certainly, but I think the Debian situation is a bit different because there uploads by someone other than a dedicated maintainer are an exception and when there is a team, the team has generally agreed on a common toolset.
<lool> I'm about to push ubuntu-meta to update the dep on hwtest-gtk to checkbox-gtk; hope that's ok
<lool> (WRT A4)
<pochu> hi lool :)
<lool> Hey
<lool> pochu: how is it going?
<pochu> lool: quite good. almost finished my exams
<lool> Oh nice
<pochu> and I'm starting to learn C :)
<lool> Eh, is certainly useful around what you package :)
<pochu> yeah :)
<pochu> the bad news are that my AM seems to have gone MIA ;)
<lool> Ah; hopefully not for too long or you'll get a new one
<lool> Hmm how useful
<lool>     raise RuntimeError('Unable to retrieve package list from debootstrap: %s' % debootstrap_stdout)
<lool> RuntimeError: Unable to retrieve package list from debootstrap:
<lool> But then I'm not up-to-date due to checkbox/hwcheck; vicious circle
<ogra> lool, did you deliberately wait until slangasek stepped on the train to do that meta update ? :)
<ogra> err
<ogra> plane indeed
<sharperguy> Right I'm trying to add the "Replaces:" line to the package python3.0 (which I think might be why idle-python3 isn't installable) but everytime I run "debuild -S" it undoes the changes...
<lool> ogra: I think it breaks upgrades; didn't you get that issue when upgrading to checkbox?
<lool> I'd rather unbreak them before A4
<ogra> lool, i shamefully admit that my lappie still runs intrepid
<lool> wow
<sistpoty> sharperguy: maybe control is generated from e.g. control.in?
<sharperguy> sistpoty, yeah that might make sense (I'm new to packaging)
<ogra> lool, i'll do my upgrade from the local mirror in berlin
<sistpoty> sharperguy: maybe #ubuntu-motu might be a better place to ask that questions ;)
<sharperguy> ah ok ty
<sistpoty> you're welcome, sharperguy:
<bluefoxicy> so when this thing says "restart session"
<bluefoxicy> as in, you go to share a folder, it installs samba, and says "You need to restart your session in order to enable sharing"
<bluefoxicy> what does it mean, "Session"?
<bluefoxicy> ... log-in session?
<lool> Hmm even after upgrading, ./update files
<lool> *fails
 * lool runs germinate manually
<lool> Hmm worked; weird
<lool> No special changes in debootstrap and germinate
<lool> Uhoh, my install is seriously hosed
<pochu> lool: that's why ogra still runs Intrepid :)
<ogra> lool, perfect for a day before the sprint :P
<lool> I was fearing all my python modules were broken, but actually I just hit two bugs
<lool> It seems I can't ./update because debootstrap returns an error code, but doesn't output anything
<lool> Weird, it runs: ['debootstrap', '--arch', 'amd64', '--print-debs', 'jaunty', 'debootstrap-dir', 'http://archive.ubuntu.com/ubuntu/']
<lool> And that works fine here
<ogra> hmm
 * lool tries agian withing python
<lool> Printing stderr this time
<lool> Oh I wonder whether it's just archive.u.c failing from time to time
<lool> I get many errors recently
<ogra> yep
<lool> Yeah, it passed amd64 fine; so it must be transient issues with archive.u.c  :-/
<ogra> i noticed that too
<ogra> apparently loaded ... though i wonder what causes the load
<elmo> ogra: the kernel security updates
<ogra> probably 8.04.2
<elmo> no
<ogra> ah
<slangasek> ogra, lool: heh
<slangasek> what broke, exactly?  Anything I can help with?
<slangasek> (The Portland Mafia have a 5-hour layover here in JFK)
<ogra> something about the change from hwtest-gtk to checkbox-gtk
<lool> slangasek: Mailed you
<slangasek> ok - wasn't sure if that mail was from before or after something being broken :)
<lool> slangasek: The actual problem I had on IRC earlier seemed to be due to archive.u.c slowness
<slangasek> ah
<lool> slangasek: hwcheck was fragile and hwcheck -> checkbox made this obvious; I'm hoping that making the move to checkbox easier will help
<lool> Which is why I was trying to push an ubuntu-meta if it's still not too late
<slangasek> yeah, not too late at all; merging ubuntu-meta is a normal part of the milestone process anyway :)
<slangasek> lool: was the libwmf addition yours, or just something pulled in when you ./update-d?
<sistpoty> tjaalton: libdrm, I just saw http://launchpadlibrarian.net/21861310/buildlog_ubuntu-jaunty-powerpc.mesa_7.3-1ubuntu1_FAILEDTOBUILD.txt.gz... will the new version fix that and I only need to click on rebuild for mesa?
<slangasek> ah, Riddell's addition
<slangasek> Riddell: why did you add libwmf0.2-7-gtk to the desktop seed, exactly?  Your bzr changelog includes no rationale
<slangasek> Riddell: libraries should normally be pulled in by the packages that need them instead of being directly seeded, surely?
<sistpoty> tjaalton: ah, obviously not... I'll add the depends back on any for linux-libc-dev... ok? (or bryce)?
<lool> slangasek: No, Riddell split libwmf because of the gtk dep it has, but I mailed him that it should probably be seeded if we want to keep the same functionality
<lool> slangasek: libwmf0.2-7-gtk is a gtk module to load wmf files
<slangasek> right
<slangasek> ok, all makes sense now :)
<lool> libwmf0.2-7 is pulled anyway, so for a marginal size we get support in gtk for them in gtk seeds
<lool> Such as thumbnails etc
<lool> Or eog
<sistpoty> crap, I'm still at -0ubuntu2... damn mirror lag *g*
<sistpoty> (drm)
<lool> slangasek: (pushed ubuntu-meta)
<slangasek> cheers
<lool> mailed cjwatson
<sistpoty> ScottK (or bryce): second opinion about libdrm... I dropped the arch specific linux-libc-dev and have it require on all arches, so that mesa should build... however I can't say I know what I'm doing right now definitely, so I'd like to hear a second opinion
<ScottK> sistpoty: It was versioned before it was dropped.
<lool> sistpoty: We need the versionned dep where possible
<sistpoty> ScottK, lool: good point, thanks!
<lool> sistpoty: I'm not sure what you mean, did you see libdrm 2.4.4-0ubuntu3?
<sistpoty> lool: yep
<lool> Is there anything to fix after it?
<slangasek> who here has a panasonic, sony, toshiba, asus, or IBM (not Lenovo) laptop running jaunty?
<ScottK> lool: But then when I rebuilt mesa on the ports archs it couldn't find drm.h
<slangasek> (with hotkeys)
<lool> ScottK: Right, the problem is that it's in the kernel
<lool> now
<sistpoty> lool: but the dependency on linux-libc-dev was dropped for anything not amd64 armel i386
<lool> So we would have to install drm.h from libdrm on the other arches
<sistpoty> lool: which I guess is what makes mesa FTBFS on other arches
<ScottK> So how does dropping the build-dep help us then.
<lool> But the best fix is really to uploda linux-libc-dev on these arches instead
<lool> The problem is that linux-libc-dev is lagging on all other arches
<slangasek> lagging, or stuck in NEW?
<slangasek> oh, you're talking -ports
<sistpoty> lool: ah, so if it were built, it could make libdrm built on the other arches and then mesa would build fine?
<sistpoty> slangasek: yep
<lool> sistpoty: yes
<lool> slangasek: Right ports kernel lagging
<sistpoty> lool: do you see any problem with requiring linux-libc-dev now? (as libdrm-dev  3 is already built?)
<sistpoty> -3 even
<slangasek> no panasonic toshiba sony asus IBM? :)
<lool> sistpoty: ?
<ScottK> I see an lpia kernel in New but that's it.
<slangasek> everyone here is Dell and Lenovo then? :)
<lool> sistpoty: I think linux-libc-dev is still too old on the other arches
<slangasek> c'mon, people, help me kill off acpi-support
<sistpoty> lool: well, libdrm would sort this via its version...
<sistpoty> lool: (>= 2.6.28-5.15)
<lool> sistpoty: It's going to cause other problems downstream
<sistpoty> lool: as in?
<lool> sistpoty: Let's not spend any effort in a hackish solution; the solution is clear
<sistpoty> lool: but what is the solution?
<lool> sistpoty: Solution is to update the ports kernel
<lool> which will update the headers and you can restore the drm bdep
<sistpoty> lool: oh, and that didn't happen yet?
<lool> err dep
<lool> sistpoty: I don't see it
<sistpoty> lool: ah, thanks for your insight!
<ScottK> lool: Who's updating the ports kernels?
<sistpoty> ScottK: so: you know what to do, but I don't touch a kernel, sorry :P
 * ScottK doesn't get how the 'solution' of dropping the build-dep was any kind of solution at all.
<lool> ScottK: I have no idea; I think I saw a mention recently
<lool> It seems smb might do it
<lool> see thread alpine.OSF.1.99.0901292328210.384018@replicant.hut.fi
<lool> http://article.gmane.org/gmane.linux.ubuntu.devel.kernel.general/3536
<ScottK> lool: On what list?
<ScottK> Ah.
<ScottK> Thanks.
<sistpoty> lool: but out of interest, would it break anything if the arch dependency was dropped from libdrm? Imo it just wouldn't build due to the versioned build-dep... right?
<lool> sistpoty: What do you propose exactly, sorry I'm not sure I understand
<lool> sistpoty: We need the dependency, it was removed for some arches to make libdrm-dev installable
<sistpoty> lool: currently there's:  linux-libc-dev (>= 2.6.28-5.15) [i386 amd64 (maybe others)]
<sistpoty> lool: so I propose to get rid of the arch requirement
<sistpoty> (in build-deps)
<lool> Yes, it should be linux-libc-dev (>= 2.6.28-5.15) in an ideal world, but until linux-ports is uploaded it's best to keep it like that
<lool> sistpoty: It was without the arch specification
<lool> These were addedd
<sistpoty> lool: yes... but still, I don't see where it would break anything... it just would be in dep-wait for other arches, right?
<ScottK> It seems like adding the arch specification just traded not installable for not actually useful.
<lool> Anyway current situation is broken, what you propose was the previous situation which was also broken without linux-libc-dev on the other arches
<lool> ScottK: Exactly
<lool> So let's not trade back and forth, just need a linux-ports upload
<ScottK> So color me a little frustrated at this response to the discussion at the release team meeting.
<lool> ?
<ScottK> It may be coindence, but we discussed this problem at the release team meeting yesterday.
<lool> I didn't pay attention to that part I'm afraid
<ScottK> I assume that upload less than a day later is related.
 * sistpoty won't do kernel ports, for sure :P
<ScottK> I could be wrong.
 * ScottK neither.
<lool> ScottK: You mean the libdrm upload?
<ScottK> Yeah
<ScottK> That added the per-arch specification on the build-dep
<lool> tjaalton wasn't in that meeeting
<ScottK> Maybe coincidence then.
<ScottK> Does the lpia kernel in New solve it for LPIA?
<lool> Also, I'm not sure why "bdep" gets mentionned, as far as I know it's a dep
<lool> ScottK: Quite certainly
<lool> Hmm actually it depends whether the packaging was really merged
<ScottK> Right,  Dep, not build-dep.
 * lool checks
<ScottK> slangasek: Any chance you could use some of your layover to get the lpia kernel out of New.  That'd give us at least one more arch to try and get working.
<ScottK> Ah.
 * ScottK waits.
<lool> ScottK: What was uploaded is a linux-lpia-meta right?  It wont help the linux-libc-headers
<ScottK> Yes.  That's what is it.
<ScottK> slangasek: Never mind ...
<ScottK> is it/it is
 * lool grabs linux-libc-dev_2.6.28-1.2_lpia.deb
<lool> It has drm
<lool> So it should be fine to also let libdrm-dev dep on linux-libc-dev (>= foo) on lpia
<lool> Probably tjaalton didn't know about the special lpia tree
<sistpoty> lool: sorry to bother you again, but what would be wrong with uploading a librm, which drops the arch-specific b-d on linux-libc-dev? wouldn't it just wait in dep-wait for the arches that don't have a fitting kernel yet? (as the version on the b-d would still be there)?
<lool> sistpoty: Build-depends?
<sistpoty> lool: yep
<lool> I see no such build-depend
<lool> Build-Depends: debhelper (>= 5.0.0), libx11-dev, dpkg-dev (>= 1.13.19), quilt (>= 0.40), automake, libtool, pkg-config, libpthread-stubs0-dev
<ScottK> I think going back to that would be better as the arch specific change didn't actually help.
<sistpoty> lool: erm, sorry, depends
<ScottK> My fault.
<lool> ScottK: They help installability
<sistpoty> lool: but that wouldn't help ports, would it?
<ScottK> In that case we'll need to upload and change the archs as they are done.
<lool> sistpoty: it might for builds which pull libdrm-dev and don't use it
<ScottK> Anything the does that is buggy anyway.
<sistpoty> lool: ah, good pointer... though I think that would be a bug in itself?
<lool> I'm sorry but what are you trying to solve?  The only proposal which makes all packages build again is to upload linux-ports
<lool> ScottK: It's not, libdrm-dev might be pulled but might not be required in all cases
<ScottK> I guess.
<lool> When I say pull, it might be directly or indirectly
<sistpoty> lool: that's for sure... I'm trying more or less to find out why that change was done
<ScottK> Right.   Forgot about indirect.
<lool> having libdrm-dev might impact a lot of other packages
<lool> Actually probably not
<lool> It has no rdep
<lool> So nevermind
<sistpoty> lool: and I certainly appreciate your insight :)
<lool> Ok, I'm just going to push libdrm-dev with the same change for lpia
<ScottK> That'll be progess.
<ScottK> I guess I do want slangasek to get lpia out of New then ...
<lool> sistpoty, ScottK: documented in the new libdrm upload I just pushed
<ScottK> Great.
<sistpoty> lool: thanks a lot!
<lool> Well that wont help you much I'm afraid :)
<sistpoty> hehe
 * lool &
<sistpoty> lool: but I still fail to understand, why you didn't remove all of the architectures in depends? wouldn't that help r-build-depends to fail unless a new ports-kernel was uploaded? (so that these builds could simply be clicked on retry?)? am I missing s.th.?
 * sistpoty is pretty confused right now, admitted
<lool> sistpoty: We really need the version; the package is always installed anyway
<sistpoty> lool: yes, but the version is either satisfied, or would cause the package to dep-wait?
<lool> sistpoty: it's a dep of libc6-dev
<lool> sistpoty: No idea what's best here except pushing a new linux-ports :)
<lool> I don't think we should waste too much thinking in this situation
<sistpoty> lool: ok, just wanted to figure out lp myself ;)
<sistpoty> lool: so let's not waste any more time to it ;)
<DBO> bryce, are you here?
<DBO> I am playing 7 degrees of ubuntu developers and you ended up being my next stop =)  I am looking for someone knowledgeable in the x dnd protocol so that I might make a window that is transparent to it
<sladen> DBO: IIRC, just don't listen for DnD messages
<DBO> does that work...
<DBO> i can try
<sladen> to make DnD work, you have to actively do something
<DBO> no i want DND to go to something behind it
<DBO> my window is transparent
<sladen> (again, IIRC, E&OE, I haven't written an DnD app for a while)
<DBO> yeah i just confirmed, it still "eats" the drag and drop event
<DBO> so the window below does not get the event
<DBO> it just goes into oblivion
<sladen> DBO: so, if you're not transparent, but you are preventing to be, you need to proxy and pass through all the events that you're [pretending] to be transparent to (DnDrops too)
<sladen> DBO: what is the application that you're trying to write?
<sladen> DBO: XdndProxy  may, or may not be helpful
<slangasek> ScottK: we seem to only have linux-lpia-meta in NEW currently?
<DBO> sladen, Docky
<DBO> sladen, I am the primary author of Docky if you have any idea what that is
<sladen> DBO: I'm clearly behind the times.  From Googling it appears to be a Mac OS X work-alike.  Is that correct?
<DBO> sladen, i prefer not to think of it like that
<DBO> but yeah, its like that
<DBO> but its also part of GNOME Do and a full out frontend for it
<DBO> but you can see where the problem comes in
<sladen> DBO: so, (guessing again and pulling straws from the sky), all the crap stuck to the edges of the desktop is preventing the users getting at their real work underneath?
<DBO> no, really its just dnd thats failing
<DBO> input masking is working fine
<DBO> if you drag something around on your desktop
<DBO> and you try to drop it onto your desktop under an invisible part of the window
<DBO> docky eats the event (bad)
<sladen> DBO: http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#id2447278
#ubuntu-devel 2009-02-01
<sladen> DBO: a slightly different, but related case
<DBO> =/
<DBO> pretty...
<DBO> i guess I'll just make Docky embed everything, mwahahahaha.... wait
<sladen> https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/docs/dnd_internals.txt  grep for "we actually have to figure out which window
<DBO> sladen, how did you find that?
<sladen> DBO: I'm not sure what search phrase; possibly "window manager ignore xdnd" or "xdnd masking input masking"
<sladen> DBO: I actually have a related case for a transparent keyboard so I'm quite interested in find the answer
<DBO> sladen, your google-fu is strong
<DBO> well if it makes any difference to you, I am doing this all in Mono
<DBO> so we will see if I get it working =)
<Roey> mako:  greetings
<Roey> mako:  hmm, wrong maco :)
<Roey> but hello nonetheless!
<sladen> DBO: there's going to be interesting situation when the target window, docky window and icon window overlap, if two out of the three are trying to proxy to the "correct" bottom window
<sladen> DBO: but as long as you (in Docky) manage not to proxy it to the clipped mouse icon window, it should work
<DBO> yeah
<DBO> i am really curious how I am supposed to figure out how to proxy to the right window
<DBO> lets say there are 4 or 5 windows in a stack
<DBO> which one do I figure out is on top?
<sladen> testing the x,y against the rectangle of the topmost, then the second most, then the third most ... until you get a hit
<DBO> sladen, i am not sure I follow you here
<DBO> you must excuse me, I have been programming for far less time than I should have by now
<DBO> I can get a ref to the root window
<DBO> are all other windows one of its children?
<DBO> or rather, how do I find the topmost window?
<sladen> DBO: take a bunch of pieces of paper and spread them (overlaping) on the table.  Close you eyes and put your finger down;  which piece of paper did you hit?
<KDesk> hi
<DBO> sladen, i know how to do that logically
<DBO> just not in code...
<sladen> DBO: hopefully you can check that you hit this piece of paper as you're inside it's four edges/four corners
<DBO> i can check and see if I am in bounds
<sladen> DBO: yup, you can get a list of all of the TOPLEVEL windows that are a a child of the ROOT window
<DBO> right but what if two of those toplevel windows are overlapping?
<sladen> then, if you're doing thwat Gtk is doing for efficiency you can subscribe to changes and keep you're internal list up to date
<sladen> or if you're lazy, you can just query for the full list each time a DnD comes in
<KDesk> For which architecture are the deb packages in Ubuntu optimized for i386, 686 or what?
<sladen> KDesk: they're optimised for recent chips, but will run on i486 IIRC
<DBO> i will be lazy
<sladen> DBO: if you put all the windows in order from top to bottom, and start at the top and work downwards, you'll check the topmost one first
<DBO> yes i know that, but how does one put them in order
<DBO> that is the question I have been trying to ask
<KDesk> sladen: ah, I thought there where not optimized, or only for 386, is possible to know this info from a binary package?
<ebroder> Is there anyone from backporters who could take a look at LP bug #323546?
<ubottu> Launchpad bug 323546 in hardy-backports "xen-meta only depends on Xen 3.2 packages" [Undecided,New] https://launchpad.net/bugs/323546
<sladen> for w in sorted(get_root_window()->children) { if w.bounds.text(event->mouse.position) proxy_dnd_to(w); }
<DBO> sladen, sorted?
<DBO> I am not trying to be difficult
<sladen> DBO: psuedo-code
<DBO> i know
<DBO> but thats the thing I am saying
<DBO> I see nothing in gdk's api that lets you determine which window is "topmost"
<sladen> in Python (a fabulous language, btw), it would return a copy of the array, sorted by calling __cmp__() on each object
<sladen> which window is topmost, depends on where you are looking on the screen
<Roey> sorted(collectionOfObjects), sladen?
<Roey> sladen:  doesn't sorted() call __cmp__ on every element in the list passed to it?
<sladen> KDesk: don't think so, but you can check the build-log that built that binary package.   If you were running a supercomputercluster you'd probably be worried about optimisation;  however the default configuration options are probably about as good as you can get for Desktop yse
<KDesk> sladen: ah, ok, thanks a lot! A last question, where can I find the build log, in launchpad?
<sladen> Roey: so you might do  sorted(window_list, cmp=lambda a,b: x.height < y.height)
<Roey> ahhhh ok
<Roey> I had thought that sorted() calls __cmp__
<Roey> but, you're right, I've used sorted() in the way you described to sort IP address stringts
<Roey> strings
<Roey> so yeah
<sladen> KDesk: probably easier if you say which package you're after.  eg. https://launchpad.net/ubuntu/+source/xbill/2.1-7/+build/593853
<KDesk> sladen: oh, thanks! I was only curious about the optimization. :)
<cjwatson> ScottK: yes, yes - maybe I shouldn't have mentioned Debian. The point is that there's nothing wrong with having a package in a private revision control system and just uploading the tar/diff that results from it, as long as it's then your responsibility to maintain it.
<ScottK> cjwatson: Certainly.
<DBO> sladen, it works!
 * DBO dances the dance of joy
<jelmer> slangasek, hi
<sladen> DBO: rock!
<DBO> sladen, how can I thank you in the source, real name, sladen, email?
<bettercoder> Hey guys! I think I am cool enough to be a mainstream dev! I made a program that prints hello world! pretty sweet, eh??!!!!?!??!?!?!??!?!?!?!??
<bettercoder> also, is ubuntu vulnerable to the y2k bug/
<bettercoder> hello???????????????!!!!!!!!!!!!!!!!!!????????????????????!!!!!!!!!!!!!!?????????????
<bettercoder> WWWWWWWWWWWWHHHHHHHHHHHYYYYYYYYY WOOOON"TTT ANNNYYONNNE ANNNNSSSSSSWEEEEEEEEERRRR????????????
<patxbot> stfuckup
<patxbot> jeese
<bettercoder> whats does stfuckup mean?
<patxbot> it means be quiet
<bettercoder> ok, thats a good idea
<patxbot> stop spamming
<bettercoder> So
<bettercoder> hw do i b a dev?
<patxbot> ty
<bettercoder> huh??huh??
<patxbot> you develop brains *first* cos i do not have any of them...
<jsmidt> Is there anyone here who understands PPAs well?
<jsmidt> I am trying to build Python 3.0 for hardy.
<jsmidt> https://launchpad.net/~python-ubuntu/+archive/ppa
<jsmidt> It build depends on python-sphinx
<jsmidt> I have successfully build this in the PPA for Hardy
<jsmidt> Yet Python 3.0 still complians the build dependency isn't met
<jsmidt> How do you get a package in the PPA to "see" the other packages?
<jsmidt> https://launchpad.net/%7Epython-ubuntu/+archive/ppa/+build/854896/+files/buildlog_ubuntu-hardy-i386.python3.0_3.0-0~ppa7~hardy_FAILEDTOBUILD.txt.gz
<jsmidt> Thanks in advance.
<ScottK> jsmidt: PPAs have nothing to do with Ubuntu.  They use Ubuntu, but are done by Launchpad.  Try PPA questions in #launchpad.
<jsmidt> ScottK, thanks
<jsmidt> (Though I'm sure you are technically right, very few people would say PPAs have nothing to do with Ubuntu.  Much in Ubuntu is done through using PPAs)
<ScottK> People use PPAs for testing, but "Ubuntu" the distro does not come from PPAs.
<jsmidt> ScottK, yes I know, I know.
<jsmidt> ScottK, I wasn't trying to argue.
<ScottK> OK.  I think it's an important point.  I am tired of dealing with bugs filed against Ubuntu packages that are really from some random PPA.
<jsmidt> ScottK, I'm sure that is very frustrating.  And so now that I think about it, my issue is probably annoying for the same reason.  :)
<slangasek> pitti: please consider those Hotkey pages locked by me currently, for spec drafting :)
<slangasek> pitti: but thanks for the information - bryce and I were struggling with exactly this question on the plane; I'll review what you've added to see if it makes sense out of what I see with thinkpad_acpi
<slangasek> jelmer: hi, thanks for the fixed branch - what's the right way for me to replace the current ~ubuntu-core-dev branch with yours?
<ogra> slangasek, hey, arrived safely ?
<slangasek> ogra: yep, all 16 of us
<ogra> great :)
<slangasek> pitti: btw, hal-info isn't currently in bzr?  Should I push an ~ubuntu-core-dev branch based off of the jaunty package-import?  (I have a patch for it to fix a ThinkPad hotkey)
<ion_> http://golf.naurunappula.com/nn/0/151/007/336376.jpg
<ion_> Sorry, wrong channel. :-(
<tjaalton> lool: libdrm is maintained in git, so probably the "Rename Vcs-*" bit is wrong? (thanks for adding lpia, I didn't know -1.2 was out)
<hyperair> could someone look at bug #268141 please? debdiff's attached for both intrepid and jaunty.
<ubottu> Launchpad bug 268141 in gnome-keyring "no ssh-agent after resume from hibernate" [Unknown,Confirmed] https://launchpad.net/bugs/268141
<directhex> erm... is requestsync being insane again?
<lool> tjaalton: Oh sorry, I checked the git tree and didn't see the ubuntu branch
<lool> tjaalton: Which branch is it?
<lool> tjaalton: Uh I'm blind
<Rocket2DMn> TheMuso, i'm looking at bug 308539 which states that the problem is that libft-perl is uninstallable - https://launchpad.net/ubuntu/intrepid/+source/defoma/0.11.10-0.2ubuntu1
<lool> tjaalton: I checked it out extra yesterday evening to check
<ubottu> Launchpad bug 308539 in defoma "/usr/bin/defoma-hints broken due to deleted dependency" [Undecided,Confirmed] https://launchpad.net/bugs/308539
<lool> tjaalton: But I missed the branch
<lool> tjaalton: Sorry about that
<lool> tjaalton: Yeah, not only is the rename wrong but I should have committed there
<Rocket2DMn> TheMuso, can you tell me how to proceed with the triage on that bug?  Can we somehow link it to that page
<Rocket2DMn> TheMuso, please ignore my previous comments, sorry
<tjaalton> lool: no problem :)
<TheMuso> Rocket2DMn: uh... ok. :)
<Rocket2DMn> heh, sorry man
<TheMuso> np
<lool> tjaalton: Pushed 2.4.4-0ubuntu4 and a revert of the XS-Original-Vcs-* change to git
<TheMuso> c
<pitti> fta: that was a bug in gvfs, hopefully worked around in the latest version
<fta> pitti, eh.. what for?
<pitti> slangasek: locked pages> oh, sorry; but I only really added information, so I guess it's ok
<pitti> slangasek: hal-info isn't in bzr; I commit stuff directly into git upstream; but if it helps you, feel free to bzrize it
<pitti> fta: you pinged me earlier about getting file:// urls when reporting apport crashes
<fta> pitti, oh, ok. thanks
<fta> pitti, i ended up filling bug 323409
<ubottu> Launchpad bug 323409 in cyrus-sasl2 "sasl2-bin broken, segfaulting during install" [Undecided,Confirmed] https://launchpad.net/bugs/323409
<pitti> fta: FYI, bug 314263 is the breakage you mention
<ubottu> Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Fix released] https://launchpad.net/bugs/314263
<fta> pitti, yes, sure. i encountered 314263 while fighting against 323409.
<fta> now waiting for Keybuk to have a look at 323409
<slangasek> pitti: ah, well, if it doesn't help you, I probably won't bother bzring hal-info since LP needs to be taught about the project first
<slangasek> pitti: anyway, should I upload my ThinkVantage change, or email it to you?
<allquixotic> Hi, I found a bug in Jaunty (a regression from 8.10) which causes hald to crash during input hotplugging when I have a Logitech ChillStream video game controller plugged in to USB. The controller worked, and hald didn't crash, under 8.10. What sort of priority should I file a bug with? What details should I include?
<calc> hello
<bluefoxicy> okay this has been bugging me forever
<bluefoxicy> can somebody please extend fakeroot to debian package INSTALLATION?
<ion_> Why?
<bluefoxicy> I should not be able to make a .deb that gets run, asks a question, gets a "no" and aborts installation
<bluefoxicy> and leaves a rootkit behind on my system
<bluefoxicy> current method of package installation:  glorified tarball.  Unpack, run pre-install.sh, does whatever it wants to your system AS ROOT
<ion_> Itâs okay if it leaves behind a keylogger on your user account?
<bluefoxicy> installing a non-root service that runs as a restricted user and can't affect your system (say...wesnoth's dedicated server?)?  It can still gain root access
<ion_> Itâs not a problem of the package manager if a user installs a malicious package.
<bluefoxicy> ion_:  I have had to re-install before (later, modify the deb) because of a bug in the java deb
<bluefoxicy> if you don't check "I Agree" on the license question, it makes a permanent change to your system and aborts installation
<bluefoxicy> pre-rm and post-rm don't undo it
<elmo> bluefoxicy: it's not a permanent change
<elmo> it's a debconf question
<bluefoxicy> elmo:  yes, and if you say no, and then attempt installation again, it doesn't ask;it just says, "oh, no, you didn't want to agree to the license, so screw you"
<elmo> bluefoxicy: ok, but that doesn't make it permanent
<elmo> the debconf DB is entirely under your control
<bluefoxicy> elmo:  nothing's technically "permanent."
<ion_> 0) That can be fixed in the packaging, 1) how is fakeroot relevant here?
<bluefoxicy> it could replace /bin/sh with malware, and I could technically replace the malware with a proper /bin/sh
<bluefoxicy> ion_:  0) It's a package bug; 1) I don't believe the system should be changed, at all, until the package is finished installing.
<bluefoxicy> in Gentoo, when a package is built, emerge has a sandbox environment that forbids real writes outside the build and image directory
<bluefoxicy> post-installation file access pulls the files into the image directory, and i.e. updates to samba.conf or /etc/passwd get written to copies in the image directory
<soren> I don't think fakeroot is the right tool for something like htat.
<bluefoxicy> the final step is to "merge" that to /
<bluefoxicy> at any point before then, your system has been completely unchanged
<bluefoxicy> soren:  yeah that's whyI said extend... fakeroot doesn't do anything nearly useful for that
<bluefoxicy> at one point I almost wrote a completely different package manager because i don't like things playing around with full root access running arbitrary code just to install
<soren> I don't think fakeroot is the right application to extend to achieve something like that.
<bluefoxicy> I don't have to audit the final installed files, config changes, etc; I have to audit the entire logic of the installation system
<bluefoxicy> soren:  maybe so.
<elmo> how do you audit the final installed files?
<elmo> JOOI
<bluefoxicy> elmo:  make all changes to an isolated image that gets  copied over / to finalize installation; then stop it at that point, and examine that tree?
<Notch-1> hi, i'm trying to boot intrepid from a loop device, using root=/dev/loop0 (or root=700) boot parameter, and a little initrd script that mount the device containing the image, and then "losetup /dev/loop0 /path-to-the-image"... but it still can't find init... can anybody help me?
<bluefoxicy> SUID binaries, strange changes to /etc/passwd, debconf settings, strange binaries that shouldn't exist, funny scripts generated by obfuscated logic in the pre-install scripts of the package...
<bluefoxicy> all lain out clear
<bluefoxicy> anyway
<bluefoxicy> endrant
<tjaalton> lool: excellent, thanks
<Notch-1> please guys, anybody familiar with booting loop images?
<ScottK> Notch-1: User support in #ubuntu
<Notch-1> ScottK: thank you
#ubuntu-devel 2010-02-01
<fullTummy> j
<word2007adobefla> The Devil (Greek: diabolos = 'slanderer' or 'accuser'[1]) is believed in certain religions and cultures to be a powerful, supernatural entity that is the personification of evil and the enemy of God and humankind. The Devil is commonly associated with heretics, infidels, and other unbelievers. The Abrahamic religions have variously regarded the Devil as a rebellious fallen angel or demon...
<word2007adobefla> ...that tempts humans to sin or commit evil deeds. Others regard the Devil as an allegory that represents a crisis of faith, individualism, free will, wisdom and enlightenment.
<word2007adobefla> In mainstream Christianity, God and the Devil are usually portrayed as fighting over the souls of humans, with the Devil seeking to lure people away from God and into Hell. The Devil commands a force of evil angels, commonly known as demons.[2] The Hebrew Bible (or Old Testament) describes the Adversary (Ha-satan) as an angel who instigates tests upon humankind.[3][4] Many other religions...
<word2007adobefla> ...have a trickster or tempter figure that is similar to the Devil. Modern conceptions of the Devil include the concept that it symbolizes humans' own lower nature or sinfulness.
<directhex> o_o
<xnox> nhandler: ping - UbuntuClassroom lesson pitch? leoquant's recruit
<tripzero> anyone know what touches the /etc/sudoers file after the install
<hyperair> visudo?
<LucidFox> Is Thunderbird 3 going to be in Lucid?
<mdke> if anyone could take a quick look at ubuntu-docs 8.10.3 in the queue for intrepid-proposed, that would be appreciated
<mdke> or rather someone in ~ubuntu-sru
<twp> hi - i have a question about debuild, versions and maintainers. is this the right channel to ask it? if not please tell me where i should ask. thanks
<BlackZ> twp, ask in #ubuntu-motu
<twp> BlackZ: thanks!
<bdrung> sebner: can you have a look at bug #285417?
<ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
<bdrung> sebner: sorry. this question targets seb128, not you.
<chrisccoulson> bdrung - seb128 isn't online yet
<chrisccoulson> he's in portland
<bdrung> chrisccoulson: i noticed it too, after the wrong tab completion
<sebner> bdrung: np
<mdeslaur> chrisccoulson: could you take a look at the debugging screen locking wiki page I've started: https://wiki.ubuntu.com/DebuggingScreenLocking
<mdeslaur> chrisccoulson: and this: https://wiki.ubuntu.com/DebuggingScreenLocking/HowScreenLockingWorks
<chrisccoulson> mdeslaur - yeah, i can take a look at those
<mdeslaur> chrisccoulson: I would like to know what you think, and if you have any other ideas for them
<TheMuso> cjwatson: I have someone from the a11y community asking me about the font size in lucid compared to karmic. Is this something that console-setup is responsible for?
<cjwatson> TheMuso: I hope not
<cjwatson> TheMuso: unless you mean font size on the console - but even then I don't think anything's changed
<TheMuso> cjwatson: Yes I mean font size on the console.
<TheMuso> cjwatson: Ok I'll let them know that.
<slangasek> TheMuso: well, kms is now supported on more hardware in lucid, so affected users will now see a different console resolution by default due to use of fbcon
<cjwatson> TheMuso: yeah, what slangasek said - it's also possible that there's been the odd language-specific change
<cjwatson> pitti: where's the code that generates pending-sru.html?
<pitti> cjwatson: it's "sru-report" in ubuntu-archive-tools
<cjwatson> oh, yes, just found it
<cjwatson> thanks
<slangasek> pitti: how do you identify the list of language packs that need to be pocket-copied, given that they're not output in pending-sru?  Is there a tool?
<pitti> slangasek: yes, indeed there is
<pitti> slangasek: there's a langpack-o-matic checkout on cocoplum
<slangasek> aha
<pitti> slangasek: ./copy-packages karmic proposed updates
<pitti> slangasek: or copy-packages hardy ppa proposed
<pitti> that will generate a list of copy-package.py commands to stdout
<pitti> slangasek: it checks the Packages.gz files which versions are newer
<seb128> directhex, Laney: hey, do you know if anybody is working on packaging moonlight2 for debian or lucid?
<Laney> seb128: directhex has done work on this. As far as I know it's... not ideal for packaging (bundled copy of mono)
<Laney> (ftpmaster says no, but I think AA has OKed it)
<seb128> Laney, ok thanks
<Laney> seb128: can you NEW the waiting cil-dev stuff?
<seb128> Laney, sure, let me have a look to those
<Laney> thanks
<AnAnt> Hello, I tried to build mailutils 2.1 (from lucid) on my PPA, but it failed: http://launchpadlibrarian.net/38633096/buildlog_ubuntu-lucid-i386.mailutils_1%3A2.1%2Bdfsg1-4%7E1_FAILEDTOBUILD.txt.gz , why is that ?
<directhex> seb128, yes, Laney reports status correctly. currently i have a working build system (you can imagine the chaos involved in the "bundled mono" thing), and am producing binaries for documentation and for desktop (gtk library) packages only. the sdk is only a few more lines to add, the big pending item is support for firefox >3.5
<seb128> directhex, ok, great, so you think you will get that done for lucid right?
<directhex> seb128, i'm partly waiting on upstream to get the plugin working on lucid's browser. i hope to get it into lucid, although it may require some massaging of freeze dates by a local friendly core-dev
<directhex> upstream are currently preparing a point release for 2.0, which will fix the browser support, and also brings in some licensing fixes i requested
<seb128> directhex, ok thanks, I don't think the archive admin side should be an issue but let's see when it gets ready...
<seb128> directhex, thanks for working on it
<directhex> seb128, well, i wish the build system were a little more sane so it were debianable, but the assurances i got regarding ubuntu acceptability reignited my desire to work on it
<seb128> great! :-)
<mok0_> What's the status on format 3.0 (quilt) ?
<mok0_> ah n/m, found it
<pitti> 3~
<cjwatson> mok0_: .orig.tar.(!gz) is broken, that's the main outstanding issue (bug 225151)
<ubottu> Launchpad bug 225151 in soyuz "Please add support for .orig.tar.bz2" [Medium,Triaged] https://launchpad.net/bugs/225151
<seb128> cjwatson, it's broken for syncs you mean or...?
<StevenK> seb128: It would be broken for everything, syncs and uploads
<seb128> StevenK, weird, I did upload pidgin with an orig.tar.bz2 some weeks ago and it worked
<seb128> it's in lucid
 * StevenK looks
<StevenK> cjwatson: ^
<ccheney> yep its there
<ccheney> http://archive.ubuntu.com/ubuntu/pool/main/p/pidgin/pidgin_2.6.5.orig.tar.bz2
<cjwatson> seb128: it may only be in some cases, but the bug does seem to suggest that database support is nonexistent
<cjwatson> so maybe it does work, I can't say how well
<StevenK> So perhaps it's just "we'd rather you didn't"
<StevenK> Rather than "it's completly broken, and won't work"
<slangasek> but is -2ubuntu1 the only Ubuntu revision we've had of pidgin 2.6.5?
<ccheney> hmm pidgin has the whole new format it seems
<ccheney> including eg pidgin_2.6.5-2ubuntu1.debian.tar.gz
<cjwatson> ccheney: you can't do .orig.tar.bz2 in format 1
<cjwatson> so that's not surprising
<slangasek> (the sync-source problems, certainly, are specific to trying to upload a *second* version that references the same .orig.tar.bz2)
<ccheney> cjwatson: ah ok
<seb128> slangasek, yes it is
<seb128> (only revision of the version)
 * slangasek nods
<cjwatson> it's possible that a subsequent upload would be unable to realise that there's already a .orig there
<cjwatson> I'm not entirely sure
<cjwatson> (but I think we should fix this for lucid rather than panicking about stuff already in the archive ...)
<slangasek> we certainly should :)
<StevenK> Oooh, that's a good point.
<StevenK> Shall we upload a no-change pidgin to see if it goes bang?
<mok0_> Is there still no intelligent way to specify build-depends for a source package?
<StevenK> mok0_: What do you mean?
<mok0_> StevenK: That occasionally you can't build a source package because certain packages are needed, for example in the clean target
<TheMuso> Right, thanks.
<StevenK> mok0_: And they should be in the Build-Depends, and is a bug. And?
<persia> Um, no they shouldn't.
<slangasek> mok0_: they're specified, and you should be installing them as specified?
<mok0_> slangasek: right
<persia> Policy doesn't require that the packages required to maintain a package are specified anywhere.
<slangasek> persia: "in the clean target"
<slangasek> that's specified in policy
<cjwatson> seb128: looking through soyuz, I think it might just be syncs
<mok0_> OK, in this case, the package _was_ specified in Build-Depends
<persia> Ah, right.  Sorry, got confused with my dream of Source-Depends.
<mok0_> but it's still a hunt to track it down
<mok0_> persia: That's a nice dream :-)
<cjwatson> I don't *see* any hardcoded references to .orig.tar.gz elsewhere
<StevenK> Is there something in Debian we can try and sync to try it? :-)
<cjwatson> we *know* .orig.tar.bz2 syncs failed
<cjwatson> sync-blacklist is full of failures
<cjwatson> s/failed/fail/
<StevenK> Ahh
<cjwatson> the question is whether non-origful uploads fail
<bryce2> apw, btw I have a box here in the desktop room with your l-b-m kernel bits on it
<bryce2> apw, it's up right now with nouveau+kms.
<bryce2> compiz crashes on it, and vt switching doesn't work
<bryce2> haven't tested it too deeply
<directhex> seb128, still about?
<seb128> directhex, hey
<directhex> seb128, i wonder if you can help me find some packages which have gone walkabout... the new -dev packages for gnome-desktop-sharp2 are showing on launchpad, but i can't see them on packages.ubuntu.com
<seb128> directhex, I newed those just before lunch so maybe yet another publisher run
<directhex> seb128, ah, i see
<directhex> seb128, wondered why i was missing build-deps for building moon2 against lucid rather than sid ;)
<ccheney> doko: new OOo (rc4) uploaded with your new patch
 * ccheney now gets to work updating all the surrounding bits for OOo
<lifeless> jcastro: what bzr package did you have?
<lifeless> jcastro: also can you do 'which bzr' just to be sure the system one ran
<lifeless> jcastro: in fact, where are you ?
<StevenK> cjwatson: d-i uploaded for new kernel ABIs. Twice. :-/
<cjwatson> StevenK: thanks
#ubuntu-devel 2010-02-02
<mdz> persia, I read the transcript of your Open Week talk on stack traces; interesting topic
<mdz> persia, I find it more convenient to browse the source from within gdb rather than opening up a separate editor, when walking through the stack frames
<mdz> cjwatson, I enjoyed your merging session as well
<mdz> dholbach, developer week seems to have gone very well, nicely done
<dholbach> thanks mdz
<seb128> directhex, they are published now btw
<directhex> oh, neato
<directhex> i'll look tomorrow after it hits my mirror
<cjwatson> mdz: oh good
<persia> mdz: When one runs gdb directly, I'd agree it's more convenient.  That said, I often find that using the apport stacktraces with the source is good enough, without needing to fully replicate.
<persia> Is there a good way to use the info the retracer leaves in a bug (after the coredump is stripped) to initialise gdb?
<persia> In many cases, I find the crashes are data- or environment-dependent, and replication can be tricky.
<cjwatson> persia: as it turned out it wasn't directly germane to your talk since one can't use it with apport stacktraces, but do you know about gdb 7's record-and-replay support?
<persia> cjwatson: I don't.
<cjwatson> persia: it rocks.
 * persia reads http://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay.html#Process-Record-and-Replay
 * cjwatson does an entire test install to test installing GRUB's boot sector + core image to an LVM, only to realise that this makes no sense
<cjwatson> persia: reverse execution is the sexy bit, of course
<persia> Indeed.  I didn't get any farther than that on the page before redirecting to chapter 6 :)
<ogra> Keybuk, http://people.canonical.com/~ogra/osiris-lucid-20100202-2.png :)
<ogra> (with FRAMEBUFFER=y btw
<ogra> )
 * StevenK through and NBSes 3 kernels with happy abandon
<Keybuk> what did you change?
<StevenK> Sigh. Missing word fail
<Keybuk> ogra: I want to see that without ubuntuone-syncd ;)
<ogra> Keybuk, nothing ... i switched FARMEBUFFER to n and then back to y, regenerated the initrd both times
<ogra> i guess if you move on like that we need some new solution for bootchart to keep the charts readable :)
<Keybuk> move on?
<ogra> well, to 2sec boots or so :)
<ogra> ok, ubuntuone removed ...
<Keybuk> we'd have to use perf or something
 * ogra reboots 
<ogra> :)
<ogra> Keybuk, hmm, so the modprobe of death comes back randomly it seems
<ogra> Keybuk, but if its not there i get something like http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :D
<ogra> i guess thats something to show off with :)
<Keybuk> niiiiice
<pitti> 8s? sweeeet
<ogra> pitti, without ubuntuone and without plymouth though
<LaserJock> does anybody know if there's a good overview of what's happening for UNR/UNE for Lucid?
<persia> LaserJock: bzr log of the seeds probably says the most up to now.  Can't give you a pointer for the future.
<LaserJock> is it continuing to be actively developed or is it sort of in maintanence mode?
<LaserJock> my only machine is now a netbook and so I've noticed a few things that could maybe be improved
<LaserJock> but it didn't seem like much was going on with core code (netbook-launcher, etc.)
<persia> Have you checked upstream activity?  I haven't followed in a bit, but I remember hearing a bit of talk at UDS.
<LaserJock> well, that's sort of what I'm trying to find
<LaserJock> I don't know where upstream is
<StevenK> In Launchpad
<LaserJock> the last commit to netbook-launcher was 14 weeks ago
<LaserJock> I'm wondering what that means, "we think we're at a stable point" or "we're not really interested and are moving on"
<persia> Is there nifty bits that are not yet released upstream that we'd want?
<persia> s/Is/Are/?
<LaserJock> honestly I don't know what's upstream and what's not
<persia> Well, it's like anything else :)  But if you're looking at the specific packages, that's probably an upstream thing.  If it's not, then it's probably seeds or other random bits :)
<LaserJock> well, I'm wondering about code, not seeds
<persia> That's probably upstream then.
<LaserJock> so upstream I guess, which is sort of the same as downstream, but yeah
<persia> How is it the same?  We're downstream.
<LaserJock> well, netbook-launcher is done by UNR and UNR is part of Ubuntu
<LaserJock> hence, kinda the same
<persia> Yeah.  The names are annoying.  I was involved in a discussion about nomenclature back in the very beginning of karmic, with the following conclusions:
<persia> 1) There exists some set of code (the core applications) that is a separate project, which is on LP.
<persia> 2) There exists an implementation that has been adopted by Ubuntu, which was UNR, and is now becoming UNE.
<persia> 3) There exist some other implementations further downstream which are UNR.
<persia> Dunno how much that's still true, but theoretically there's supposed to be distinction.
<LaserJock> geeze, that's kinda confusing
<LaserJock> but the "separate project" is run by "UNR Developers" which makes it sound not-so-separate
<persia> Yeah well :)  There was a session on naming at UDS Jaunty, but that was the conclusion :)
<persia> I know, but "UNR Developers" != Ubuntu Developers.
<LaserJock> I'm seeing that
<ajmitch> so much confusion there
<LaserJock> it's mostly DX and OEM Solutions
<LaserJock> so a bit more like CNR
<LaserJock> in fact every single member of "UNR Developers" is Canonical
<LaserJock> hmm, weird
<persia> Well, still, contacting upstream is the best way to get guidance :)
<persia> Otherwise it's just the stuff in the specs.
<LaserJock> persia: right, I guess I can file a bug, I just hate doing that if it's likely to come of nothing
<persia> LaserJock: I guess.  My point is mostly that I'm not convinced that this channel is the best place to answer that question.  I don't happen to know the best way to contact upstream, but I do expect they're in a better position to answer questions of general direction.
<LaserJock> persia: right, I just didn't really know where
<LaserJock> probably a bug will get to the right people though if Canonical's still running it
<persia> Probably, if it's against the right project :)
<LaserJock> heh
<fullTummy> ubuntu is good
<fullTummy> for testing formatting
<fullTummy> kapetan sam od careva grada,
<fullTummy> u njem vladam od trista godinah;
<fullTummy> Äed mi ga je na sablju dobio
<fullTummy> Äe su carstvo sablje dijelile,
<fullTummy> te mu tragu osta za gospodstvo."
<fullTummy> Raspali se MiÄunoviÄ VuÄe,
<fullTummy> pa se Hamzi poprimaÄe blizu:
<fullTummy> "Kakvo VlaÅ¡e, krmska poturice!
<fullTummy> Äe izdajnik bolji od viteza?
<fullTummy> Kakvu sablju kaÅ¾eÅ¡ i Kosovo?
<fullTummy> Da l' na njemu zajedno ne bjesmo,
<fullTummy> pa ja rva i tada i sada?
<fullTummy> Ti izdao prijed i poslijed,
<fullTummy> obrljao obraz pred svijetom,
<fullTummy> pohulio vjeru praÄedovsku,
<fullTummy> zarobio sebe u tuÄina!
<fullTummy> Å to se hvaliÅ¡ gradom i gospodstvom -
<fullTummy> svi gradovi Å¡to su do nas turski,
<fullTummy> jesam li ih opsuo mramorjem,
<fullTummy> te nijesu za ljude gradovi
<fullTummy> no tavnice za nevoljne suÅ¾nje?
<fullTummy> BiÄ sam boÅ¾ji ja spleten za tebe,
<fullTummy> da se stavljaÅ¡ Å¡to si uradio!"
<ogra> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<David-T> no floodbot here?
<breinera> on what channel should I ask about packaging a personal project
<ScottK> If you plan to try to get it into Ubuntu, #ubuntu-motu.  If you're going to put it in a PPA, #launchpad.
<ccheney> hmm an upload i did today shows binaries still not published
<ccheney> is there some kind of block on OOo, or myself? ;-)
<ccheney> ah nm it apparently is new for some reason
<ccheney> didn't mention that until i clicked through to the actual build
<Damascene> Hello, http://www.ubuntu.com/testing/lucid/alpha2 says that UNR is KDE base now. is that right?
<Riddell> Damascene: no it doesn't
<Damascene> why it is on kubuntu page?
<Riddell> why is what?
<Damascene> http://cdimage.ubuntu.com/kubuntu/releases/lucid/alpha-2/ (Kubuntu Desktop and Netbook Remix)
<Damascene> that is what the page says
<Riddell> "Kubuntu Desktop and Netbook Remix" means Kubuntu Desktop images and Kubuntu Netbook Remix images
<Riddell> Ubuntu Netbook is not the same as Kubuntu Netbook.  UNE is hidden at the bottom of http://cdimage.ubuntu.com/releases/lucid/alpha-2/
<StevenK> And UNE is the new name for UNR
<Damascene> Ok :) , I understand now. the site should be clearer
<Damascene> thank you
<mdz> persia: ah, of course, you were talking about analyzing stack traces in bugs. it would be way cool if Launchpad would cross-reference to the source package branches so you could just click through to the source
<nigel_nb> Hobbsee, I now have the source from packages.ubuntu.com and I'm wondering what to do next
<nigel_nb> (I should do this more often :( )
<Hobbsee> nigel_nb: you're looking for the ubuntu packaging guides and similar, i presume
<nigel_nb> Hobbsee, yep... i have the one from motu... works?
<Hobbsee> nigel_nb: yep.  What you want should be listed in some section of https://wiki.ubuntu.com/MOTU/Contributing
<nigel_nb> Hobbsee, reading through :)
<nigel_nb> Hobbsee, what is the patch system in gnome? git?
<Hobbsee> nigel_nb: i don't actually know, tbh.  i'm going to tentatively guess dpatch - is there a 00list in debian/patches?
<Hobbsee> you can always try building the package / looking at the build depends to see, though
<nigel_nb> oh yes
<nigel_nb> so its dpatch
<nigel_nb> Hobbsee, uh, wait.. cdbs is listed as build depends
<Hobbsee> nigel_nb: then that's what it'll be.
<nigel_nb> Hobbsee, ah
<Hobbsee> 00list is used in multiple patch systems, but does help in tracking it down
<nigel_nb> okay.. so I have to add another number to the 00 list?
<Hobbsee> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#CDBS with Simple Patchsys
<Hobbsee> nigel_nb: gives a fairly good overview of how to use it
<nigel_nb> Hobbsee, hehe, I'm already there
<Hobbsee> cdbs-edit-patch will automatically add it for you
<geser> what-patch (from ubuntu-dev-tools) can also give a hint what patch system is used
<nigel_nb> yep, just installed what-patch now
<nigel_nb> I'll explain where I'm lost
<nigel_nb> I have this diff from upstream (the actual patch).  Am I supposed to do a cdbs-edit-patch and run that patch?
<nigel_nb> or pass that patch in to edbs-edit-patch
<geser> what patch system is exactly used? what does "what-patch" tell?
<nigel_nb> geser, cdbs
<geser> then create with "cdbs-edit-patch my_new_patch" a new patch and apply the upstream patch inside the working copy, when you are done all your changes are get saved in my_new_patch
<geser> check the new patch name wisely as the patches are applied in lexicographic order
<nigel_nb> geser, so I'm supposed to simply create a blank file called my_new_patch?
<geser> cdbs-edit-patch will do it for you (and my_new_patch is a placeholder for a better name)
<geser> a good name should describe what the patch solves without needing to look inside
<nigel_nb> something like "cdbs-edit-patch 07_fix_GvcChannelMap_leak" ?
<geser> yes
<nigel_nb> I get an error like "dh_testdir: cannot read debian/control: No such file or directory"
<nigel_nb> what am I missing?
<geser> are you inside the (unpacked) package directory?
<Hobbsee> you need to do it in the source package root
<Hobbsee> ie, the one that has a debian folder
<nigel_nb> I was inside the patches directory.. ah
<nigel_nb> oh, I have to satisfy all depends when working on a package?
<geser> not necessarily, just the ones needed to run the "clean" target
<geser> in this case probably "cdbs" and some other packages
<nigel_nb> I'm not running gnome.. which means ......lots of them
<nigel_nb> now its a good idea to switch back
<nigel_nb> okay, now I'm in the subshell of cdbs-edit patch :)
<nigel_nb> geser, so I just paste the diff inside the subshell?
<geser> yes, apply it with patch
<nigel_nb> um, with patch?
<geser> every change you do inside this subshell will be put into the patch later
<nigel_nb> so inside the subshell, I'm supposed to go to the particular file and make the modification?
<geser> yes, apply the changes you need, e.g. by editing a file with an editor or applying a ready patch
<geser> yes
<nigel_nb> I have this file withe me http://bugzilla-attachments.gnome.org/attachment.cgi?id=152824
<geser> save it somewhere (e.g. /tmp) and then "patch -p2 --dry-run < /tmp/the_saved_patch". if this works without an error, remove the "--dry-run"
<geser> (alternatively you could also open that file (src/gvc-mixer-stream.c) in an editor and do the changes there, but that's only feasible for small patches)
<nigel_nb> since its a very small patch I opened the file and did it :)
<nigel_nb> and the patch command gave me an error and I didn't have enough patching $foo to fix that one
<nigel_nb> now the patch is in the folder but its not applied
<nigel_nb> shouldn't the patch be applied and not just listed there?
<geser> patches are applied before building and un-applied during clean
<nigel_nb> ah, so I can just go on to building this now?
<geser> when you build the binary package you can check the build output to see if your patch got applied or not
<geser> yes
<nigel_nb> geser, the patch needs to be tagged rite?
<geser> I don't know the current policy but it's a good idea to do it
<nigel_nb> I've used this http://dep.debian.net/deps/dep3/
<nigel_nb> to the extend that I know how its done
<juliank> Shouldn't libslab be included in main and gnome-control-center build-depend on it, like it is done in Debian?
<juliank> libslab is currently in universe.
<ScottK> Since most/all of the Canonical developers are at a sprint this week, the odds of an authoritative answer via IRC are particularly low at the moment.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 => somebody has time to check this patch ? :) didn't make it in Karmic, would be nice to have it into Lucid :)
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<juliank> ScottK: I will then report a bug against control-center, once triaged =>MIR for libslab => Change gnome-control-center => Fix released. Should be a good way to do this.
<ScottK> juliank: I don't have an opinion on the best way to proceed.  I don't even use Gnome.  I was just suggesting IRC isn't it.
<dupondje> nobody to review my patch :) its in sponsor queue for some time now
<Ng> I guess whoever would process NEW packages this week is in Portland doing far more interesting things :)
<dupondje> Alot of packages in the queue it seems :)
<bigon> could someone have a look at my merge request plz https://bugs.edge.launchpad.net/ubuntu/+source/virtinst/+bug/509800 ?
<ubottu> Ubuntu bug 509800 in virtinst "Please merge virtinst (0.500.1-2) from debian main" [Wishlist,New]
<LucidFox> "Lucid changes to Firefox default provider"
<LucidFox> I saw Lucid and Firefox in one sentence and did a double take.
<Ng> LucidFox: we're sending all search requests to you. I hope you've got plenty of coffee
<LucidFox> Er, I don't drink coffee.
<ScottK> You will
<LucidFox> Eek
<Laibsch> ArneGoetje: I have a question if I may.  It seems to me that among scim and now ibus, uim was never seriously considered.  Can you briefly explain the reason?
<persia> Laibsch: We used uim back in Breezy, and switched to scim.  I'm not sure switching back was ever considered, but uim was once the preferred choice :)
<Laibsch> I see
<Laibsch> I'm not very familiar with the options, really
<Laibsch> But I learned today that at least in Japan uim is the default
<Laibsch> and the numbers in popcon support that
<Laibsch> actually, maybe not
<Laibsch> I was looking at the wrong package
<Laibsch> scim-anthy and uim-anthy seem to be equal at around 1.500 installations
<Laibsch> ibus-anthy is still way behind at only ~30 (one of which is mine ;-))
<persia> anthy is preferred.  How we get to anthy is less important :)
<tkamppeter> pitti, hi
<pitti> tkamppeter: hello
<persia> The old docs all referenced uim, but scim has started to work well enough that it's the default in the Japanese Remixes.
<tkamppeter> I have prepared an SRU for foomatic-filters, bug 463059
<ubottu> Launchpad bug 463059 in foomatic-filters "Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM" [Medium,Fix committed] https://launchpad.net/bugs/463059
<sebner> pitti: ~o~, everything fine in Portland? :)
<pitti> sebner: yes, it is; had Karaoke last night :)
<pitti> tkamppeter: I saw your mail, will followup later on
<tkamppeter> pitti, can you accept the foomatioc-filter to get into -proposed, so that the reporter can start testing and does not need to wait for the Sprint to finish?
<tkamppeter> Sprint is in Portland?
<sebner> pitti: hahaha! I hope you won! you have to defend the german honor :P
<pitti> sebner: it wasn't actually a competition :)
<pitti> tkamppeter: I'll do it later today, don't worry :)
<tkamppeter> OK, it is early in the morning for you, I was used to Sprints being in Europe.
<sebner> pitti: then your are doing something wrong, Who is the most funniest, the most drunk, the most embaressing one ... all essential questions :P
<pitti> sebner: slangasek wanted to hear 99 Luftballons, but they only had the English version :/
<pitti> (which I refused to sing..)
<sebner> hahaha
<pitti> tkamppeter: right, I just got up early for the DMB meeting
<lamont> asac: mono given back
<tkamppeter> pitti, thanks for passing through the SRU, it perhaps fixes also bug 513690 and bug 422949.
<ubottu> Launchpad bug 513690 in foomatic-filters "Xerox WorkCentre 7245 (7228) prints only first page" [Medium,Incomplete] https://launchpad.net/bugs/513690
<ubottu> Launchpad bug 422949 in cups "Document Viewer 2.26.1 not printing" [Undecided,Incomplete] https://launchpad.net/bugs/422949
<sbalneav> I'm having trouble trying to get something working for evolution for teachers as part of #edubuntu.  I'm trying to get the evoldap backend working for gconf, and it works for setting mail accounts, but I can't seem to set addressbook and calendar defaults.  Anyone know off the top of their head where evolution picks up it's defaults for addressbook and cal?  It sure seems to find the ubuntuOne stuff.
<ArneGoetje> Laibsch: ever tried to install and configure uim? Ever compared the user interface between uim and scim/ibus? IMHO scim/ibus are more advanced and user friendly than uim.
<Laibsch> OK
<Laibsch> Just curious
<asac> lamont: rock
<slangasek> ion: fyi, I've uploaded the plymouth upstart job changes now following discussion with Keybuk; he helped identify one reason that would account for the splash screen starting so late, but we haven't pinned your race condition yet - the upstart jobs themselves seem to be exactly what he was expecting, and we probably have to debug the race condition as a plymouth bug
<ion> slangasek: Alright
<slangasek> ion: you were running on intel, right? you mentioned kms
<ion> slangasek: Radeon
<slangasek> ion: ok; will try to sniff out some radeon hardware here at the company sprint to reproduce the problem :)
<Jumanji> What is the cause of this ? -> WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported!  This is an application bug!
<Jumanji> Thats compiz
<Jumanji> X.Org X Server 1.7.4.901 (1.7.5 RC 1)
<Jumanji> Release Date: 2010-01-23
<Jumanji> X Protocol Version 11, Revision 0
<Jumanji> Build Operating System: Linux 2.6.32.3 i686
<Jumanji> xf86-video-intel-2.10.0
<Jumanji> (nice driver btw)
<sheldon> hi, i'm trying to upload a source package on my ppa but i recevie this error pkg-kde-tools_0.6.0~ppa1.dsc: format '3.0 (native)' is not permitted in karmic. How can i solve?
<Riddell> sheldon: convert it to format 1.0 by removing debian/source/ directory
<sheldon> thanks Riddell
<ccheney> slangasek: ping
<sbalneav> seb128: Got a half a sec?
<seb128> sbalneav, yes
<sbalneav> As part of Edubuntu, I'm trying to get the gconf backend evoldap going.  Evolution picks up the account settingdgs from ldap, but seems to be ignoring the addressbook and calendar settings...
<sbalneav> do you know off the top of your head where evolution's grabbing the default gconf keys for /apps/evolution/calendar/sources and .../addrssbook/sources?
<sbalneav> it seems to be ignoring the ones evoldap gives it.
<seb128> no I don't
<sbalneav> ok, fair enough.  I'll keep digging.
<pitti> Keybuk, sabdfl: FYI: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1-nobg.png  and http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1-tiledbg.png
<pitti> Keybuk, sabdfl: in short, tiled bg is cheap
<Keybuk> oh, cool
 * Keybuk was wrong
<micahg> anyone know the debian policy for reopening won't fix bugs if time passes and there's new info?
<highvoltage> the universe has a strange sense of humour. just a few weeks ago I laughed at a Windows 7 bug that caused login to take 30s longer if you don't have a wallpaper and just a plain background
<seb128> micahg, don't?
<highvoltage> and now this :)
<micahg> seb128: does that mean file a new bug?
<pitti> Keybuk: it does use some CPU, but much less apparently than all the huge .jpg decoding and scaling
<seb128> micahg, no that mean if the maintainer says the change will not be made it will probably not
<pitti> Keybuk: (it's jpg these days, it just pretends to be a .png for backwards compat issues)
<pitti> Keybuk: doing a chart now with new plymouth
<micahg> seb128: k, thanks
<seb128> micahg, you can argue on the bug but don't play close, reopen game, it will just annoy the maintainer and not lead anywhere usually
<micahg> seb128: ok, so it's ok to comment on a won't fix then if there's new information??
<seb128> yes
<seb128> but those bugs usually don't wait on new comments
<micahg> seb128: thanks
<seb128> bugs which lack informations are incomplete
<seb128> or invalid
 * micahg has to actually see if there's an update on the issue
<micahg> but wanted to know general policy
<ccheney> doko: OOo failed on arm due to what appears to be broken krb5
<pitti> right, that caused FTBFSes all over the place (not just on arm)
<StevenK> pitti: Which are now fixed?
<pitti> I dunno
<doko> ccheney, pitti: fixed and requeued
<pitti> sweet, thanks
<ccheney> doko: thanks
<pitti> slangasek, Keybuk: did old vs. new plymouth, nice job!
<pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-1.png
<pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100202-2.png
<pitti> (it works around the usb_id bug again by parallelization, and is also quite fast)
<Keybuk> cool
<Keybuk> looking in good shape there
<Keybuk> I suspect the usb_id thing is actually holding stuff up still
<ion> keybuk: The ureadahead-with-HDD â udev â framebuffer â plymouth sequence causes quite a long period of confusing-black-screen-for-user here. I wonder if thereâs a compromise that can be done so that plymouth doesnât need to wait for the entire readahead thing?
<Keybuk> ion: possibly
<ogra> pitti, woah, slooow boot there
<ogra> :P
<pitti> ogra: sheeeesh
<pitti> ogra: well, it's an Abacus^WAtom
<ogra> heh
<TheMuso> lol
<Keybuk> ion: got any ideas?
<ion> keybuk: Perhaps using similar IO priority queueing as mountallâs doing with fscks and launching ureadahead and udev in parallel with ureadahead having the priority. Then making ureadahead read the files needed for framebuffer first and the rest later. But then, udev probably blocks on IO unrelated to framebuffer, which causes this entire hack to fail.
<Keybuk> ion: exactly
<Keybuk> and if you do multiple readahead passes, you fail
<Keybuk> (on HDD more than SSD)
<ion> Yeah
<sabdfl> pitti: that latter one is very nicely compacted
<pitti> sabdfl: indeed; it'll look even better with the kernel bug fixed
<ion> keybuk: Would building the framebuffer stuff into the kernel work? Perhaps make plymouth not wait for a udev event if it can just show the splash?
<Keybuk> ion: can't do that
<Keybuk> would mean we couldn't update graphics drivers through backports
<ion> Right
<slangasek> ccheney: pong
<ccheney> slangasek: nm i found out it was riddell's day to process new :)
<slangasek> ccheney: ah :)  sorry for not getting to it right away, the server team AET MAI BRAIN
<ion> keybuk: When udev finds a framebuffer, log the corresponding kernel module and on the next startup try modprobing that stuff and starting plymouth in parallel with ureadahead? If the hardware has changed and the modprobe fails, udev will bring up the correct framebuffer later in the startup and log the new framebuffer module for the next boots. One would need to measure whether those things happening in parallel with ureadahead have too great an impact on HDDs.
<ccheney> slangasek: heh ok :)
<ion> keybuk: Perhaps do the modprobe attempt just before ureadahead if the framebuffer module has been logged previously.
<Keybuk> ion: no.
<ion> keybuk: Hack udev to queue all non-whitelisted kernel events for later and only act on framebuffer-related events? Process the entire queue and continue as normal as soon as a signal is received. Start udev early along with ureadahead and signal udev when ureadahead is ready.
<Keybuk> ion: again, brittle
<Keybuk> udev can't start before mountall
<Keybuk> because udev needs /proc, /sys, etc.
<Keybuk> but ureadahead has to start before mountall
<Keybuk> this is pretty much the fundamental issue
<mpt> tremolux, I've added some specifics of how software items without a source should be presented. https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=316&rev1=314
<tremolux> mpt: ah great, thanks!
<mpt> tremolux, actually, I made a confusing mistake there. Fixed in https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=317&rev1=314
<tremolux> mpt: ok, thx
<directhex> seb128, can you sync gtk-sharp2 from sid? 2.12.9-4 is needed to fix the tasque compile error
<seb128> directhex, ok
<directhex> thanks
<pitti> seb128, slangasek, Riddell, james_w, jdstrand: oops, I wanted to sync a package, which started to sync the entire load of packages currently being in syncs/; I ^Ced it
<kklimonda> are we going to upload django 1.2 to lucid? it's supposed to be released at 9th march
<sebner> pitti: why don't let it run through? =)
<Riddell> pitti: hmm, those syncs aren't from me
<Riddell> someone is doing my archive day for me!
<slangasek> sebner: the sync will run with the wrong options in that case
<sebner> slangasek: ah, I wasn't aware of that
<slangasek> sebner: we pass a flag when doing mass syncs to tell it not to spam $dist-changes
<sebner> slangasek: and I suppose he forgot this special flag?
<slangasek> I would expect so :)
<ccheney> how often does the conference mirror get the new crack?
<pitti> yes, this caused -changes spam, sorry
<TheMuso> ccheney: Once a day afaik.
<slangasek> ccheney: quadridiurnally
<slangasek> oops, no, my bad
<slangasek> ccheney: octodiurnally
<ccheney> slangasek: 8 times a day or is that every 8 hours?
<sebner> pitti: I think you have to pay a round of beer at the next karaoke party :P
<slangasek> ccheney: 8 times a day
<ccheney> slangasek: ok
<pitti> slangasek: ok, we identified why the full OO.o gets pulled in; the oo.o-hyphenation-en-us package gets built by the hyphen source now (instead of oo.o-dictionaries), and thus is missing the | l-support-en dep
<pitti> slangasek: ccheney is on it
<slangasek> okie
<bdrung_> james_w: look at bug #514491
<ubottu> Launchpad bug 514491 in liblo "Sync liblo 0.26~repack-1 (universe) from Debian experimental (main)" [Undecided,Confirmed] https://launchpad.net/bugs/514491
<james_w> I'll do it in a moment
<bdrung_> something weird is going on. audacity 1.3.11-1 was now synced three times (first time it works; the last two time failed, because the version is already in the archive)
<james_w> yep, we had a bit of a collision, as long as it was accepted once we're ok now
<james_w> sorry about the noise
<bdrung_> james_w: no problem. i just wanted to make sure, that you are aware of it and that a script do not run amok.
<ccheney> pitti, slangasek: fixed
<pitti> ccheney: sweet, thanks
<Lex79> james_w: about kernel-package sync, the sources.changes is rejected
<Lex79> Rejected:None: unable to parse .changes file: ",
<james_w> Lex79: paste the mail in the bug please
<Lex79> ok
<Lex79> james_w: bug 512000
<ubottu> Launchpad bug 512000 in kernel-package "Please sync kernel-package 12.032 with Debian Testing" [Undecided,Fix released] https://launchpad.net/bugs/512000
<directhex> hm
<directhex> fta, is there no xulrunner 1.9.2 package?
<fta> didrocks, yes there is one. just not in the archive yet
<james_w> Lex79: please file a bug on soyuz
<Lex79> ok
<fta> oops, directhex ^^
<directhex> fta, will it be parallel-installable with 1.9.1?
<fta> directhex, if it stays like it is today, yes
<fta> directhex, but you should ask asac. even if i packaged it and maintained it myself, i kind of dropped the ball
<geser> james_w, Lex79: interesting bug, it breaks because of an embedded ^M in the changelog
<james_w> it breaks because it's munging the encoding as far as I can see
<micahg> directhex: I hope to finish the package tonight
<geser> I've opened the .orig.tar.gz and look inside the changelog: âBug fix: "make-kpkg should use update-initramfs when
<geser> ", thanks toâ
<micahg> directhex: we'll be porting everything to 1.9,2
<geser> argh, there is a ^M before the closing "
<directhex> micahg, 1.9.1 will be removed from the archive?
<micahg> directhex: yes, (hopefully)
<directhex> i see
<micahg> directhex: and xulrunner is dropping to universe
<directhex> micahg, what should i build-depend on for a plugin?
<micahg> directhex: xulrunner-dev should be fine
<micahg> I"ll be adding that to xulrunner-1.9.2
<ion> geser: English text using German quotation marks to quote English text that uses ASCII quotation marks is a pretty sight. :-D
<james_w> geser: it's not the ^M in the changelog from what I see
<james_w> geser: oh, it is, sorry
<wgrant> james_w, geser: Is this really a bug, then?
<james_w> yes
<james_w> IMO
<james_w> ^M isn't a newline in a .changes file, soyuz shouldn't open it in a way that causes it to be interpreted as such
<geser> the ^M (carriage return) should be in the changelog in the first place
<wgrant> The policy manual doesn't seem to actually state what a newline is.
<geser> s/should/shouldn't/
<cjwatson> Policy doesn't specify, although I do tend to agree with James
<geser> isn't the bug in the part that generates the .changes file for the sync?
<james_w> soyuz?
<james_w> :-)
<Keybuk> pitti: bIlujDI' yIchegh()Qo'; yIHegh()!
<james_w> yes, it could strip, but we could always do both
<pitti> Keybuk: sorry, my Klingon is not that good, I'm afraid
<BlackZ> hi geser ;)
<geser> does python differentiate between "\n" and "\r" for newlines?
<ogra> pitti, it is better to die() than to return() in failure
<pitti> lol
<pitti> the Perl mantra?
<Lex79> james_w: reject again
<Keybuk> exactly
<Keybuk> idly thinking we should resurrect the idea of a Klingon translation again
<james_w> geser: yes, but you can decide whether it does or not on Windows
<Keybuk> because translating Ubuntu into a language that *cannot* express the meaning of the word Ubuntu appeals to me
<Lex79> james_w: ah no, sorry :)
<ion> keybuk: Hah
<StevenK> Keybuk: \o/
<james_w> Lex79: I haven't flushed yet :-)
<Lex79> ok :)
<Keybuk> njpatel_: are we there yet?
<ogra> hrm, who broke indicator-session ? i cant lock my screen anymore with it
<sebner> mighty Keybuk, what do you think about http://img534.imageshack.us/img534/418/ubuntulucid201002021.png ?
<Keybuk> I think it's a fantastic example of early-cubist work
<Keybuk> with a distinctly impressionist approach to colours
<Keybuk> the linearity has some reflection in the work of modernist painters
<Keybuk> but without the bold use of colour
<directhex> micahg, is /usr/lib/xulrunner-addons no longer searched by firefox in lucid?
<micahg> directhex: is this for a firefox-addon?
#ubuntu-devel 2010-02-03
 * micahg doesn't know offhand
<directhex> micahg, yes, it's for a firefor addon
<micahg> but thanks to bdrung_we have an installer for addons now
<RAOF> directhex: Did you see the xul packgaing team mail on debian-devel@ recently?
<directhex> RAOF, no. link?
<sebner> Keybuk: haha, I agree but the lines are too long imho, won't you agree? :P
<micahg> http://wiki.debian.org/mozilla-devscripts
<sebner> hi directhex :)
<directhex> evening seb128
<directhex> sebner,
<RAOF> http://lists.debian.org/debian-devel/2010/02/msg00011.html
<mneptok> Keybuk: You're in a desert, walking along in the sand, when all of a sudden you look down. You look down and see a tortoise, Scott. It's crawling toward you. You reach down and you flip the tortoise over on its back. The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can't. Not without your help. But you're not helping. I mean ... you're not helping, Scott! Why is that?
 * directhex retires mneptok 
 * sebner is scared
<Keybuk> mneptok: because I crave tortoise soup
<Keybuk> sebner: "the lines" ?
<directhex> micahg, blurgh, xpi-ifying what i have is added work
<ion> mneptok: Have you stopped beating your wife?
<Keybuk> sebner: I really don't know what about the graph you're asking me to comment on
<Keybuk> it looks like a bootchart to me
<micahg> directhex: an xpi is a zip file
<Keybuk> of a hard-drive based machine
<Keybuk> where on the first boot you took longer to log in than ureadahead bothered to wait
<mneptok> ion: Sushi. That's what my ex-wife called me - cold fish.
<micahg> directhex: there's an example of building from source in the wiki page
<directhex> actually, maybe it's not so bad...
<directhex> bleh, not sure
<sebner> Keybuk: 38 seconds are bothering me :P
<pitti> sebner: http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100122-2.png ..
<micahg> directhex: the ever shrinking rules file
<directhex> micahg, for simple cases perhaps
<sebner> pitti: on my bootcharts from february 1st too but I thought we are decreasing boot time instead of increasing it :P
<bdrung_> when will be the next autosync run?
<directhex> micahg, so delete all the ubufox Npp stuff?
<micahg> directhex: I'm not sure what that is...which package?
<bdrung_> directhex: i read xpi. do you work on xul extensions?
<directhex> micahg, moon
<bdrung_> ok, moon is not a xul extension - so not my field
<directhex> bdrung_, so we're drawing a line between plugins & extensions? these rules are for extensions only?
<micahg> yeah, this is for extensions, not plugins
<bdrung_> directhex: yes.
 * directhex has been wasting his time, then
<bdrung_> directhex: did you read debian-devel ML?
<directhex> so where should *plugins* be shoving themselves?
 * micahg is looking directhex
<micahg> directhex: /usr/lib/firefox-addons/plugins seems to be the place
<directhex> micahg, firefox on karmic will load a plugin from /usr/lib/xulrunner-addons/plugins. on lucid it won't. hence the question
<micahg> see above
<Keybuk> sebner: well, part of your problem is that it's not auto-login
<Keybuk> sebner: make it auto-login
<Keybuk> wipe the ureadahead pack
<Keybuk> then do two reboots
<Keybuk> giving it about 30s to a minute after the first to settle and make the pack
<jdong> is there a secure way (reasonably) to auto-login and lock the screensaver?
<micahg> directhex: firefox on lucid doesn't use xulrunner
<jdong> I'd love to boot and walk away and come back to a ready desktop
<directhex> i see
<micahg> in fact, the xulrunner-addons is explicitely denied in the apparmor profile
<sebner> Keybuk: I'll give it a try. Btw, what's the goal now. 15-20 seconds right?
<Keybuk> sebner: along those lines
<micahg> oops
<micahg> ignore my last statement
 * micahg read it wrong
<jdstrand_> micahg: that is actually unrelated-- it is denied to prevent logging-- DAC wouldn
<jdstrand_> 't allow it anyway
<directhex> and in debian, is /usr/lib/firefox-addons/plugins appropriate?
<micahg> jdstrand_: yeah, I misread it
<micahg> bdrung_: ^^
<lifeless> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/xdg-user-dirs/+bug/516344 for your depressed edification
<ubottu> Ubuntu bug 516344 in xdg-user-dirs "prompt to rename homedir to subdir of homedir" [Undecided,New]
<lifeless> pitti: where to language pack bugs go? [scott was asking about a klingon desktop but there isn't a klingon (-tlh) langpack]
<ion> jdong: Iâd like that, too. It would also be nice if the unlocking of the screensaver unlocked the Gnome keyring in the same session as well.
<bdrung_> micahg: yes
<directhex> /usr/lib/firefox-addons/plugins/ for both distros, then? right, that simplifies matters.
<directhex> and what's an appropriate Depends: line to use, without the commonality of xulrunner? firefox|iceweasel|abrowser|somethingelse ?
<pitti> lifeless: there needs to be a locale first; once there is, and some translations on LP, they'll be created automagically
<bdrung_> directhex: i think we should provide tools for plugins, too.
<dpm> lifeless, https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
<micahg> directhex: you still need to build on xulrunner
<StevenK> Apparently, the colour of Klingon should be a deep purple
<micahg> so technically, it still depends on xulrunner, but enhances firefox in Ubuntu
<directhex> bdrung_, that could well be useful. although plugins can be somewhat unwieldy beasts, so don't go overboard in how much hand-holding you do. i'd settle for a variable signifying the system plugin dir plus a substvar for the odd thing here & there
<micahg> that reminds me, I should talk to asac about that...
<directhex> but ff on lucid doesn't use xulr... frankly, i'm totally lost now
<micahg> bdrung_: maybe an install-plugin similar to install-xpi
<ccheney> isn't xulrunner being killed off for all releases?
<micahg> ccheney: not entirely, just for firefox
<directhex> ccheney, did i mention i was lost? ;)
<ccheney> micahg: ok
<bdrung_> micahg: and dh_xul-ext needs to be adjusted on cloned to dh_xul-plugin (or something like this)
<ccheney> directhex: heh
<micahg> ccheney: we're migrating what we can away from it
<ccheney> micahg: ah ok, i thought it was migrate what we can and kill everything else :)
<ccheney> but i am probably wrong
<bdrung_> micahg: you are welcome tho write install-plugin
<bdrung_> :)
<micahg> bdrung_: is that an invitation for me to work on it ;)
<micahg> you beat me to it bdrung_...
<micahg> bdrung_: where should I file the bug?
<bdrung_> micahg: it should go into mozilla-devscripts
<directhex> i really really don't care about the specifics. i just want a symlink to usr/lib/moonlight/plugin/libmoonloader.so to be shoved in whatever location is used by mozilla-flavoured browsers, whatever they may be. that's all i want. with or without Xb-Npp-MimeType or other such nonsense, that's all i need. one symlink in the correct place.
<directhex> and dependencies of some variety to make it actually work
<directhex> meaning moonlight-plugin-core plus whatever else tastes good, like shlibs:depends and misc:depends and a browser of some variety
<bdrung_> directhex: for the second part you want a equivalent to dh_xul-ext
<directhex> yes, that'd be fine & dandy
<ccheney> pitti: do we have code to ask a user to install a particular package when an app runs, similar to how the codec stuff works?
<ccheney> pitti: i need to ask users to install java when they run OOo if they don't already have it
<lifeless> pitti: oh thats interesting; I'm making the locale for scott now.
<directhex> ccheney, i don't know of a generic framework for that
<micahg> bdrung_: it's on my list, but I don't know when I'll get to it
<micahg> oops
<micahg> bdrung_: bug 516350
<ubottu> Launchpad bug 516350 in mozilla-devscripts "provide install-plugin similar to install-xpi" [Wishlist,Triaged] https://launchpad.net/bugs/516350
<bdrung_> micahg: you may want to write a equivalent to dh_xul-ext
<micahg> bdrung_: should I rename it to that
<micahg> bdrung_: is it not 2 pieces of the same thing?
<bdrung_> micahg: no. install-xpi installs the xpi file (extract + symlinks). dh_xul-ext evaluates ${xpi:*}
<bdrung_> micahg: 2 scripts for the same thing
<micahg> bdrung_: I think I'll call the bug provide plugin install assistance and explain the in description
<bdrung_> sound good
<micahg> done
<lifeless> pitti: langpack-locales - does that control what langpacks are made?
<pitti> lifeless: indirectly
<pitti> /usr/share/i18n/SUPPORTED has the list of available locales
<lifeless> right
<pitti> langpack-locales ships that file, and the locales
<lifeless> ah
<pitti> and langpack-o-matic builds packages for locales which are in SUPPORTED
<lifeless> pitti: thats not quite right
<pitti> why not?
<lifeless> pitti: la_AU.UTF-8 is in my SUPPORTED file, and not in the package
<pitti> /usr/share/i18n/locales/la_AU
<pitti> lifeless: ^ it was you who contributed that :)
<lifeless> I know
<lifeless> but I've just done apt-get source langpack-locales
<lifeless> and it doesn't have la_AU in the source package so I'm checking my facts
<pitti> lifeless: it's in debian/patches
<pitti> (it's still not accepted upstream)
<lifeless> yeah
<pitti> or should I rather say "refused"
<pitti> so we keep it as a patch
<lifeless> ok, well I'll add klingon the same way
<lifeless> I wish I had time to do a proper orthogonal language separate from location system
<pitti> Qapla'
<StevenK> pitti: Won't Klingon hit the "Enough isn't translated, so no langpacks for joo"
<pitti> StevenK: no, we have plenty of scarcely translated langpacks
<lifeless> also klingon folk are insane
<directhex> lifeless, they're just overly exuberant
<lifeless> dpm: so why did you link that wiki page to me?
<dpm> lifeless, I was complementing pitti's answer to your question on Klingon translations. You need to create an Ubuntu Klingon team following that process to be able to translate Klingon in Launchpad
<directhex> dpm, klingon needs more vocab first though, surely? i mean, eskimos have 50 words for snow, klingons have 50 words for "disembowel"
<directhex> and whilst "disembowel" might work as a replacement for "cut", i'm not sure where else it fits
<sebner> directhex: but they don't have a word for fridge! :P
<lifeless> dpm: I have no interest in translating it ;)
<lifeless> dpm: I'm doing a favour for Keybuk
<dpm> np, just trying to be helpful :)
<lifeless> kk:)
<Keybuk> directhex: you could translate fridge pretty easily
<Keybuk> "be cold box"
<Keybuk> tep bImeHwI or something
<directhex> o_o
<Keybuk> "box for the purposes of being cold" :p
<directhex> nerd!
<Keybuk> heh
<Keybuk> Klingon has a sufficiently large vocab that entire books have been translated into it, and a fairly flexible one that it allows word creation by description
<lifeless> hmm, I've forgotten how to turn a locale on
<StevenK> Keybuk: And words invented due to cultural references
<pitti> lifeless: sudo locale-gen xx_YY.UTF-8
<pitti> lifeless: and then export LANG=xx_YY.UTF-8
<zul> cjwatson: im in the middle of writing an apport hook for openssh-server do you want to review it after can i just upload it when Im done writing it?
<directhex> shame unicode doesn't formally include klingon
<lifeless> pitti: actuall  I needed to edit /var/lib/locales/supported.d/local
<lifeless> pitti: so that it stays up to date when the locales package is refreshed
<lifeless> anyhow
<lifeless>   tlh_GB.UTF-8... done
<lifeless> Keybuk: ^
<StevenK> lifeless: Where GB is effectively, well, Earth?
<lifeless> StevenK: its for Keybuk, so I've used GB layout
<StevenK> lifeless: Does it work, though? :-)
<lifeless> StevenK: 'meh'
<directhex> barring the confusing rules regarding plugin packaging in lucid, the lack of adequate support for firefox 3.6, the lack of a debian/copyright file, and a debian/rules which doesn't work twice in a row, i have a preliminary package for moonlight 2.0. i feel i should sleep now
<directhex> seb128, ^^
<seb128> directhex, waouh, good work ;-)
<lifeless> pitti: https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/langpack-locales/bug-516359/+merge/18496
<directhex> seb128, upstream have promised me a new release within a couple of weeks which will resolve at least one of those issues. as well as the current need to +dfsg some of the tarballs which i've been ignoring
<seb128> lamont, is that normal that amd64 has only 2 buildds?
<lamont> seb128: some days
<lamont> and yes
<lamont> i386 is the workhorse that does all, so it has more
<seb128> hum, ok
<seb128> I guess those changes will be for tomorrow then
<seb128> it's annoying to have things blocked for over 10 hours as soon as gcc or openoffice get uploaded
<seb128> lamont, thanks
<lamont> seb128: yes, it is.
<lamont> I know where we can find our favorite german.....
<seb128> lamont, yeah, me too
<lamont> seb128: yeah - but I can actually throw  things at him...
<seb128> oh, please do ;-)
<StevenK> seb128: Yes, I'm blocked for an armel CD build for 28 hours because of OO.o
<seb128> StevenK, that's a different issue
<seb128> StevenK, you have 7 buildds, which means it at least doesn't block everything else
<StevenK> seb128: Sure, but while we're complaining about OO.o and gcc :-P
<seb128> ;-)
<Riddell> geser: do you have a magic script for these move to universe bugs or are you doing it all manually?
<cjwatson> zulI'd like to review it
<lifeless> pitti: ping
<pitti> lifeless: pong
<lifeless> hey, klingon all gtg :) - pushing the second patch in a second
<lifeless> been interrupted ;>
<lifeless> https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/langpack-locales/bug-516359/+merge/18496 is the langpack one
<pitti> lifeless: ++territory "Great Britain"
<pitti> shouldn't that be "Kronos"? :=)
<lifeless> pitti: no :P
<lifeless> pitti: its GB phone # layout etc
<pitti> lifeless: no translated weekdays? :)
<lifeless> patches accepted :)
<lifeless> how many weekdays does klingon have?
<pitti> no idea
<pitti> anyway, uploading now :)
<lifeless> pitti: lp:~lifeless/ubuntu/lucid/libx11/bug-516359 is the second
<lifeless> pushed
<pitti> lifeless: nice, it's already in langpack-o-matic's maps/languages
<StevenK> pitti: It's also already in Rosetta
<pitti> lifeless: uploaded
<Riddell> DktrKranz: do you have an opinion on bug 508013 ?
<ubottu> Launchpad bug 508013 in gpsd "Sync gpsd 2.90.1~svn6819-1 (universe) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/508013
<lifeless> pitti: weet, thanks
 * Dante_J greets the room
<Dante_J> Under Lucid Alpha 2 with Firefox 3.6, noscript in the repo is not compatible with Firefox, and noscript supplied via Mozilla locks everything - caps light won't even toggle.
<Dante_J> This is on a T30 Laptop with a radeon graphics card.
<gnomefreak> IIRC noscript is waiting for xul* naming update
<Linux-CLI> hi
<Linux-CLI> I'm trying to install a .deb package, however it told me that I already had a package in use (because I pressed Ctrl+C on "sudo apt-get install patch"). So I gave up & just rebooted. Still getting the error when trying to install the .deb package, any ideas?
<sbalneav> Linux-CLI: Can you give the exact error message?
<Linux-CLI> I'm trying to install a .deb package, however it told me that I already had a package in use (because I pressed Ctrl+C on "sudo apt-get install patch"). So I gave up & just rebooted. Still getting the error when trying to install the .deb package, any ideas?
<Linux-CLI> Do we use the Debian maintainers guide to create .deb packages for Ubuntu?
<RAOF> Yes.
<Linux-CLI> Thanks
<RAOF> The answer to your first question is likely to be âget dpkg to configure the partially-installed package by calling 'sudo dpkg --configure -a'â
<Linux-CLI> Yeah it was, sorry
<Linux-CLI> lol
<Linux-CLI> It took me 5 minutes to download fakeroot before
<Mad_Gouki> what sort of kernel development happens specifically for Ubuntu?
<crimsun> Mad_Gouki: the async population, hardware enablement (OEM), among others
<crimsun> async rootfs *
<Mad_Gouki> interesting
<Mad_Gouki> do most distros have kernel developers, and do the changes get folded back into the main kernel from time to time?
<maco> the corporate sponsored ones do tend to have them, yes
<maco> and at least of ubuntu, red hat, and suse.... yeah, those get submitted upstream
<Mad_Gouki> very cool
<crimsun> the merge policies tend to be governed by each team, but the general approach is to work directly in upstream as much as possible
<superm1> any archive admins about?  I was wondering if someone could clear ubiquity from binary new so that it can be included on the live cds for tomorrow in time?
<sabdfl> hi folks, why are redland-utils and raptor-utils in the default install?
<cjwatson> sabdfl: openoffice.org-core Depends: librdf0 Depends: redland-utils; librdf0 Depends: libraptor1 Depends: raptor-utils
<cjwatson> sorry, Recommends: for the last step in each of those chains, not Depends:
<cjwatson> superm1: done
<superm1> thanks
<sabdfl> cjwatson: i have oo.o-core 1:3.2.0~rc4-1ubuntu1, which appears not to
 * cjwatson peers
<cjwatson> sabdfl: ah, in that case the answer is that it is no longer in the default installation :-) I've confirmed this from the current override files
<sabdfl> doh
<sabdfl> so much changes so quickly round here :-)
<cjwatson> (I hadn't updated since this afternoon ...)
<cjwatson> it may or may not fall out automatically due to apt-get autoremove; I'm not sure exactly how sensitive that is
<cjwatson> it looks like it will stay in main for some time due to KDE bits and pieces
<cjwatson> specifically (at least) soprano-daemon)
<geser> Riddell: I checked them manually
<superm1> dang, appears to have missed the publisher cycle in time, still got the old ubiquity in the livefs :(
<slytherin> Hi. I would like to know if anyone is working on updating evolution-data-server in lucid. I want to upload latest version of evolution-mapi which depends on e-d-s 2.29.x.
<strycore> slytherin, if I recall correctly, Lucid sticks with Evolution 2.28
<slytherin> strycore: Where was this discussed? And what is the reason?
<strycore> slytherin, sorry I can't find where it has been discussed but I remember seeing that on IRC
<slytherin> hmm, I trust a discussion on mailing list than IRC discussion about such a bug decision.
<strycore> http://irclogs.ubuntu.com/2010/01/20/%23ubuntu-desktop.txt
<strycore> at 20:07
<slytherin> hmm, I wonder when and why was this decided.
<hexa-> hey, can anybody take a quick look into bug #514299 please?
<ubottu> Launchpad bug 514299 in ia32-libs "ia32-libs don't ship 32-bit libdrm_radeon" [Undecided,New] https://launchpad.net/bugs/514299
<jelmer> slangasek: Hi
<jelmer> slangasek: Are you aware of any source packages in Debian that have component orig tarballs at the moment, or are bz2 tarballs the main issue when syncing ?
<Laney> aiui the sync script is hardcoded to expect orig.tar.gz at the minute
<Laney> jelmer: wgrant was looking at it AFAIK
<jelmer> Laney: I'm working on the v3 support for the sync script at the moment, but the bug mainly talks about bz2 support.
<smoser> james_w, it looks to me like 'bzr branch lp:ubuntu/python-boto' is out of sync with the archive, could you kick it ?
<lifeless> pitti: https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/libx11/bug-516359/+merge/18538
<lifeless> bryceh: ^ may interest you too
<superm1> lifeless, "   * Add klingon language definition." is that a patch pulled from upstream I hope?
<jdong> hahaha
<StevenK> superm1: You tell funny jokes ...
<jdong> sounds SRU-worthy!
<slangasek> jelmer: bz2 tarballs are the only issue I can recall running into
<superm1> slangasek, could you re-roll daily-live from today?  tried to get the new ubiquity in in time, but the publisher was a little late
<slangasek> superm1: "daily-live" - mythbuntu or ubuntu?
<superm1> slangasek, ubuntu
<slangasek> superm1: ok, running
<superm1> slangasek, thanks
<lifeless> pitti: https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/libx11/bug-516359/+merge/18538 is the new patch
<mdeslaur> slangasek: do you own nvidia hardware? Would you like to see what plymouth looks like on my nvidia laptop (including freeze every second boot)?
<TheMuso> mdeslaur: *raises hand, I get that too.
<TheMuso> mdeslaur: Although mine is a little worse than that. Atm I can't boot the -12 kernel at all, either with plymouth or without/recovery mode.
<charlie-tca> Most of us have to use the Alt+SysRq+k to get a gdm screen in the -12 kernel
 * TheMuso can never remember what sysrk is... Please remind me. :) as in what key it is.
<charlie-tca> printscreen
<TheMuso> ah ok thanks.
<doctormo_> I have a question about this bug:
<doctormo_> https://bugs.launchpad.net/groundcontrol/+bug/516651
<ubottu> Ubuntu bug 516651 in groundcontrol "necessary to translate debug output ?" [Low,Confirmed]
<doctormo_> I want to know what the best thing to do about translating debug messages
<StevenK> cjwatson: Should we remove the lpia kernel section in the platform.lucid installer seed?
<cjwatson> StevenK: feel free
<ccheney> is lock screen broken for anyone else today?
<persia> ccheney: I've heard a couple reports.  `gnome-screensaver -l` seems to be the workaround.  Go chase dbus.
<chrisccoulson> somebody mentioned gnome-screensaver?
<StevenK> kees: Just curious, is the fortification stuff in our toolchain upstream?
<chrisccoulson> heh, i bet the new autostart delay causes it to race with the indicator-session applet
<chrisccoulson> ccheney - can you not lock the screen from there?
<persia> chrisccoulson: Seems to be a bug in how the notification applet calls it right now.  g-s itself seems fine.
<kees> StevenK: the glibc goo that responds to setting -D_FORTIFY_SOURCE=2 is in upstream glibc, yes.
<chrisccoulson> persia - right, i've noticed this before. if the indicator starts before gnome-screensaver, then it doesn't work
<kees> StevenK: our compiler sets -D_FORTIFY_SOURCE=2 by default.  that is not in the upstream compiler.
<chrisccoulson> and we just changed gnome-screensaver to not start for 5 seconds
<chrisccoulson> so, that's an indicator bug
<ccheney> ah ok
<ccheney> i tried locking by the power button in the top right of the screen in lucid
<ccheney> it does nothing though :-\
<ccheney> chrisccoulson: so i think that is the applet you are talking about?
<chrisccoulson> ccheney - yeah, it's broken because of my change to gnome-screensaver to delay starting it
<chrisccoulson> yeah, thats the applet i'm talking about
 * ccheney larts chrisccoulson for breaking stuff ;-)
<chrisccoulson> heh, yeah, that's my fault :P
<dholbach> kenvandine: did you guys see a bug about the indicators that rhythmbox is not shown although it's running (up-to-date lucid)?
<kenvandine> dholbach, i haven't seen that
<dholbach> kenvandine: which source package should I report a bug on and what kind of info do you need?
<kenvandine> rhythmbox
<kenvandine> the patch is to a plugin that is included
<slangasek> charlie-tca: sorry, who's "most of us"?  The two folks who have laptops I've looked at haven't needed to Alt+SysRq+K anything
<Sarvatt> Heyo, anyone around that works with plymouth? Got a patch for it to work with the linux-backports-modules-nouveau kernel module that is being worked on now and is not really upstream material -- http://sarvatt.com/downloads/patches/0001-src-plugins-renderers-drm-plugin.c-Add-check-for-lbm.patch
<charlie-tca> Sorry, I had two or three in #ubuntu+1 with this issue
<charlie-tca> It seems to be the way around the garbled gdm screen that appears after update to the -12 kernel in lucid
<dholbach> kenvandine: awesome, will do
<kenvandine> dholbach, thx
<dholbach> kenvandine: bug 516685
<ubottu> Launchpad bug 516685 in rhythmbox "rhythmbox is running, but no indicator is shown" [Undecided,New] https://launchpad.net/bugs/516685
<Keybuk> james_w: around?
<StevenK> cjwatson: I'm going to try a sync of a package that is quilt 3.0 and orig.tar.bz2, I'll let you know if it goes bang
<StevenK> cjwatson: Looks fine ...
<kenvandine> dholbach, thx
<dholbach> no worries
<lifeless> pitti: ping :P
<pitti> lifeless: hi; will get to the merge, still debugging pm-utils
<lifeless> kk
<lifeless> I can get someone else to do it if you like
<pitti> sure, go ahead
<seb128> DktrKranz, hi
<seb128> DktrKranz, do you think you could get the change from bug #495326 in debian?
<ubottu> Launchpad bug 495326 in lazr.restfulclient "AttributeError: 'NoneType' object has no attribute 'self_link'" [High,Fix committed] https://launchpad.net/bugs/495326
<seb128> DktrKranz, we need it in lucid and since the package is in sync right now...
<StevenK> seb128: That looks like the wrong number ...
<seb128> StevenK, why?
<StevenK> seb128: There's no Debian task, and I didn't think lazr.restfulclient was in Debian
<seb128> StevenK, well the fix is upstream now so there is no real reason to add a debian task there
<seb128> and it is in debian and in sync right now
<cjwatson> StevenK: oh, did somebody fix soyuz?
<StevenK> cjwatson: It seems so, it got synced correctly, and went through source and binary NEW easily
<StevenK> But let's see if the publisher goes BANG
<DktrKranz> seb128: hi! I think I can easily cherrypick and upload it. I don't have main upload privileges, may I ping you so you can eventually sync it?
<seb128> DktrKranz, yes, I was going to upload to lucid but I figured it would be better to get it in debian
<seb128> DktrKranz, thanks
<seb128> DktrKranz, I will sync when it's uploaded to debian
<DktrKranz> seb128: I don't think I beat dinstall, so you have to sync from incoming. Is that still possible?
<seb128> DktrKranz, yes
<seb128> thanks
<DktrKranz> ok then
<zul> cjwatson: ping
<pitti> kees: http://cgit.freedesktop.org/pm-utils/tree/src/import-fdi-quirkdb.in#n75
<cjwatson> zul: yes?  (please include content with pings :-) )
<tkamppeter> pitti, can you help Stew Ellis on bug 447961? He has problems installing CUPS from -proposed.
<ubottu> Launchpad bug 447961 in ttf-freefont "Printer autoconfigured, but LPR prints with to wide font/cpi setting" [High,Confirmed] https://launchpad.net/bugs/447961
<zul> cjwatson: sorry im going to adding an apport hook to openssh do you want to review it first or should I just upload it
<cjwatson> zul: I answered yesterday - I'd like to review it, please
<zul> cjwatson: ah ok i didnt see it yesterday ;)
<StevenK> slangasek: Is yada still trying to enter main? I have this feeling I got 70% through a yada-repackage
<cjwatson> zul: feel free to commit it to lp:~ubuntu-core-dev/ubuntu/lucid/openssh/lucid though
<cjwatson> zul: is there some urgent need for it? :-)  openssh doesn't get many crash reports
<zul> cjwatson: no urgency its just apart of the server-lucid-apport-hooks spec
<cjwatson> zul: ah, ok
<cjwatson> the spec is missing /etc/ssh/ssh_config, which is useful for client bugs
<cjwatson> I imagine the hook should be binary-package-specific if possible
<zul> cjwatson: will do
<slangasek> StevenK: see components-mismatches?  I don't know if it's still trying to get back
<geser> zul: Hi, in case you didn't notice: your php5 upload depwaits on libmcrypt-dev, looks like it slipped though in the merge
<zul> geser: thanks ill take a look
<StevenK> slangasek: No yada, so I guess we are safe :-)
<slangasek> Riddell: what's happening with koffice-l10n?  It's removed in Debian, and ISTR hearing that was specific to old koffice and should also eventually be removed for us - or should it be sync-blacklisted instead?
<Riddell> slangasek: we probably want to sync it from debian experimental
<Riddell> our koffice update is blocked on MIRs currently
<slangasek> hmm, when is koffice-l10n going to re-enter unstable then?
<Riddell> I don't know I'm afraid
<slangasek> doh
<StevenK> Riddell: How many MIRs?
<ScottK> Piles
<Riddell> StevenK: 6
<StevenK> 6 is not piles
 * ScottK thought he'd take longer to answer so the phear would build.
 * StevenK has submitted and argued for a large number of MIRs
<Riddell> it's enough to stop it progressing anyway
<Riddell> we could really do with more main inclusion reviewers
<ScottK> StevenK: I know the feeling.  IIRC I had to do 22 or some similar number to get spamassassin in Main.
<Riddell> asac, lool: got any MIR time schedule in the near future for those koffices ones you have assigned?
<lifeless> pitti: james_w is uploading it
<dpm> ccheney, doko, would you have a few minutes after lunch to discuss OO.o translations?
<ion> keybuk: Please see my last comment in LP #506727.
<ubottu> Launchpad bug 506727 in mountall "upstart fails to start system into multiuser mode" [Undecided,Confirmed] https://launchpad.net/bugs/506727
<Keybuk> ion: I'm not reading bugs at the moment
<doko> dpm: is there anything to add after the uds discussion?
<didrocks> currently Quickly use python-mkdebian from python-distutilsextra which needs debchange and so, devscripts. devscripts recommends bsd-mailx | mailx | mailutils and by and large, postfix is installed with the awful debconf question. What do you think about putting the recommends as only a suggests and patch the scripts using mail to tell something like "you need blablabla package"?
<dpm> doko, I'd simply like to know what the current status is. Translations in LP are scheduled to be open tomorrow, and if the infrastructure for importing and exporting translations is not working, I think we should disable them from Launchpad.
<dpm> (disable does not mean deleting, just hiding the templates in the UI in order not to create false expectations on translators that their translations will be included in Ubuntu)
<doko> dpm: afaik ccheney did commit to updating the import/export for lucid and have the translations from lp included in the -l10n package
<dpm> doko, yes, that was in UDS, I just want to have a quick chat to know about the current status, if this is still doable, and whether there is something else to do on the LP side (e.g. enabling or disabling translations)
<lamont> didrocks: what "awful debconf question"
<lamont> didrocks: what "awful debconf question"
<lamont> ?
<LaserJock> lamont: the questions about how to set up postfix
<LaserJock> like satelite, host only, no config, smart server, or something along those lines
<didrocks> LaserJock: the relayhost one, yes
<didrocks> lamont: ^
<LaserJock> didrocks: I would love to see such a patch to debscripts
<LaserJock> that issue has annoyed me for the last few years but I not enough to write one myself
<didrocks> LaserJock: should be pretty easy to fix, but I prefer to have some feedback on it first :)
<lamont> well, that's what you get for recommending an MTA
<didrocks> lamont: that's why I think we can just suggests it and tweak the scripts to help the user/dev
<ccheney> dpm: have not had time to even look at it since i have been focused on firefox related issues
<slangasek> doko: you uploaded sagemath for python 2.6, but left a build-dependency on libboost-python1.38-dev...
<ccheney> dpm: i got OOo 3.2 uploaded but only to make sure it got in under the FF deadline in a working state
<dpm> ccheney, no worries, I just wanted to know the status. I think for now the best would be to disable them in LP until you've had the time to have a look at them
<ccheney> dpm: yea
<dpm> ccheney, ok, but still, I think it'd be good to have a quick chat about it, would you have a few mins later on?
<ccheney> dpm: ok
<doko> slangasek: ok, will have a look, was just a no change upload
<persia> kees: armel schroots are now buildable: after fixing another little bobble.  It's still in bzr though.
<ccheney> anyone able to upload to ubuntu?
<ccheney> its hanging for me atm
<dpm> thanks ccheney :)
<persia> ccheney: The last-1Kbyte hang, or a different one?
<ccheney> well with dput it just hangs directly after checking signatures
<ccheney> last 1k byte hang usually is a local router issue
 * ccheney will try copying to chinstrap then uploading from there
<ccheney> worked fine from there, very strange
<ccheney> and the scp to chinstrap worked fine also
 * ccheney bbl lunch time
<kees> persia: \o/
<persia> kees: http://paste.ubuntu.com/368455/
<Keybuk> kees: when you get a moment, could you come down to the Foundations room
<DktrKranz> seb128: lazr.restfulclient uploaded and available on incoming, all yours :)
 * ccheney still can't upload directly from home, this is annoying :(
<ccheney> actually i'm not uploading from home, i'm uploading from my laptop, hnmm
<ogra> slangasek, did you upload the plymouth fix that should make it work on imx51 already ?
<slangasek> ogra: yes
<ogra> hmm
<slangasek> did it build on arm yet?
<ogra> we dont have a splash on the current live image
<ogra> oh, didnt check yet
 * ogra goes to look
<ccheney> ah passive mode :)
<slangasek> yah, it's built on arm
<ogra> right
<slangasek> does the current live image have 0.8.0~-8 on it?
<ogra> i'll check soon, cant access it atm
<seb128> DktrKranz, thanks
<ogra> slangasek, manifest says it has 0.8.0~-8
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100203/lucid-netbook-armel+imx51.manifest
<slangasek> hmm
<lifeless> james_w: so we're happy that the debhelper bug is fixed?
<slangasek> ogra: please give me the value of readlink /lib/plymouth/themes/default.plymouth; it's possible this is a separate bug
<slangasek> (I don't see any mistakes in my code)
<ogra> will do
<ogra> i'm just downloading it, i cant access the one booted instance atm
 * slangasek nods
<ogra> slangasek,
<ogra> ubuntu@ubuntu:~$ readlink /lib/plymouth/themes/default.plymouth
<ogra> ubuntu-logo/ubuntu-logo.plymouth
<ogra> looks ok to me
<slangasek> ogra: yep - so it's a different bug :)
<ogra> ubuntu@ubuntu:~$ plymouth-set-default-theme
<ogra> ubuntu-logo
<slangasek> what's your framebuffer?  (cat /proc/fb)
<ogra> seems ok
<ogra> 0 DISP3 BG
<ogra> 1 DISP3 BG - DI1
<ogra> 2 DISP3 FG
<slangasek> ooookay... what are those? :)
<ogra> heh, mxcfb devices
<ogra> plymouth worked on my former install so i know the framebuffer does actually work
<ogra> i havent seen it since the theme was updated though
<slangasek> is other fb output working?
<ogra> sure, X is on the framebuffer
<ogra> (we have no free driver for the GPU so it defaults to xfbdev)
<slangasek> right
<slangasek> ogra: can I come get a console on this?
<ogra> console is no prob, we're a bit out od monitors atm
<ogra> *of
<ogra> but you can have a serail console
<ogra> *serial
<pitti> slangasek, Keybuk, tseliot: if you get complaints about plymouth breaking X.org and boot, hold on with debugging
<pitti> I just found out that gdm's "force first server to vt7" patch does not work any more for some reason
<pitti> I'm debugging that now
<pitti> aah
<pitti> the patch is just fine, but debian/patches/28_plymouth_transition.patch breaks it
<pitti> it implements its own startup logic
<Keybuk> pitti: yes, there is different startup logic if plymouth is running
<Keybuk> since you want to re-use plymouth's vt, and not cause a vt switch
<Keybuk> there's possibly an issue there if you're not on vt7 ;)
<Keybuk> ie. if plymouth wasn't showing the splash
<pitti> right, jdstrand booted without "splash"
<Keybuk> yeah, that should still have switched vt
<Keybuk> but it doesn't
<pitti> for jdstrand, X.org always starts on vt1
<pitti> which wreaks a lot of havoc
<pitti> (you get the password and other input to vt1, control-C kills the server, etc.
<pitti> Keybuk: would you recommend that 28_plymouth_transition.patch gets fixed to run X on vt7 again, or should we just stop having a getty on vt1?
<Keybuk> pitti: no
<Keybuk> neither
<Keybuk> I would recommend that plymouth is fixed to switch to vt7 in the text/details case
<Keybuk> it's a plymouth bug
<Keybuk> it's actually outputting to vt7
<Keybuk> it just forgot to switch
<pitti> ok
<Keybuk> if it had, then X would have inherited it
<pitti> Keybuk: so I guess we still need to fix the patch to start X on vt7 the first time if we boot with "nosplash"?
<Keybuk> no
<Keybuk> no
<Keybuk> no
<Keybuk> we need to fix *plymouth*
<pitti> "nosplash" -> no plymouth?
<Keybuk> no
 * pitti confused now
<Keybuk> nosplash -> plymouth using a text output plugin, rather than a graphical one
<pitti> ah
<Keybuk> you still need plymouth to arbitrate who's asking for input, etc.
<pitti> ok, got it
<Keybuk> when you have no splash, it means plymouth uses text.so or details.so instead of drm.so or fb.so
<Keybuk> the code to do the vt switch is missing in the text/details case
<pitti> Keybuk: that actually means that we can drop this hideous 05_initial_server_on_vt7.patch patch
<Keybuk> (it assumes drm/fb did it already)
<Keybuk> pitti: in theory
<Keybuk> pitti: I left that there so when people do "start gdm", it does flip to vt7
<pitti> *nod*
<pitti> ok, thanks for the heads up!
<Keybuk> (from single user mode, etc.)
<pitti> Keybuk: interestingly enough, when adding a sleep to the gdm upstart job it works just fine
<Keybuk> sure
<pitti> presumably because the getty is faster, or so
<Keybuk> yeah
<Keybuk> red car wins the race, despite stuffing its face, etc.
<cjwatson> sigh, I broke grub.  again.
<cjwatson> (not in the archive)
<lamont> cjwatson: that's because you rock
<cjwatson> "grub-probe: error: unknown filesystem."  not what you want to see w.r.t. /
<lifeless> Keybuk: https://translations.edge.launchpad.net/ubuntu/karmic/+source/launchpad-integration/+pots/launchpad-integration/tlh/+translate - fully translated. a rgh.
<Keybuk> I like the translation of Launchpad - taghwI'
<Keybuk> "Thing the begins a process/initiates proceedings" - ie. launches
<crimsun> hmm, bzr merge-package is (perhaps correctly) picky with the trailing / ("bzr: ERROR: Invalid source branch URL?")
<ion> keybuk: The message i wanted you to see was about it seeming like mountall blocks while waiting for the user to either skip a mount or have mountall exit to shell when boredom_timer is triggered on a mount. IMO the prompt should be done asynchronously. If the device appears and the user hasnât done anything by then, just hide the prompt and continue with the mount. The guy who reported the bug has the boot hang consistently to that prompt just because the ...
<ion> ... device doesnât happen to appear quickly enough.
<Keybuk> ion: if you can work that out, do it ;)
<ion> keybuk: Iâll try to get that done.
 * Keybuk decides that Debian clearly needs to be translated to ghobchuq loDnI'pu'
<Keybuk> lit. "The Brothers Fight One Another"
<ion> Hah
<cjwatson> ah, I didn't break grub, upstream did
 * ogra files another plymouth bug so Keybuk doesnt get bored ...
<StevenK> ogra: He's not bored, he's translating
<ogra> StevenK, splash screens to klingon ?
<StevenK> Keybuk: Idea from plars about Ubuntu in Klingon: "I have what I have because I killed you for it"
<plars> StevenK: might require some small modifications to the CoC
<StevenK> plars: I welcome a translation of the CoC into Klingon
<Keybuk> StevenK: I was going with something like "My honour is mine because of the enemies of I have killed"
<Keybuk> StevenK: Heghlu'meH QaQ jajvam
<crimsun> StevenK: do you have plans to merge ekiga from squeeze soon?
#ubuntu-devel 2010-02-04
<StevenK> crimsun: I can do so, if you wish
<crimsun> StevenK: up to you; mostly merged locally
<StevenK> crimsun: Go ahead and finish, tis cool
<crimsun> StevenK: cheers
<Keybuk> cjwatson: a good translation for "Canonical" might be: malughwI'qu'
<Keybuk> lit. "we are ALWAYS right"
<ogra> ev_, cjwatson, is it not possible anymore to install oem-config without getting the whole of ubiquity ?
<ev_> ogra: oem-config is ubiquity
<ev_> they were merged
<ogra> (i really dont want ubiquity on installed systems)
<ogra> hrm
<ev_> in recent versions of oem-config, it removes itself once completed successfully
<ogra> right, thats what i want
<ogra> but i dont want the use to be able to muck about with partitions etc
<ogra> *user
<ev_> sure, understandable
<lifeless> Riddell: you can also use 'bzr branch git://...'
<ogra> ev_, so if they were merged, is there still the old whiptail/debconf interface for commandline systems or is that gone with the merge ?
<ev_> ogra: there's a debconf_ui frontend
<ogra> ok
<TheMuso> Anybody got any idea why kvm in lucid is causing my capslock key to be held down?
<ev_> ogra: you'll see it if you do an oem server install
<ogra> is that autoselected if there is no X up or do i need to set anything specific ?
<superm1> ev_, i dont think the automatic removal stuff is working right.  perhaps  http://pastebin.com/f15cf97a3  might address it though
<slangasek> smoser: the "uec-specific hack to redirect console output" - that's gone now in lucid, yes?
<ev_> ogra: if no other frontends are installed, it will just use the debconf_ui frontend.  You can explicitly use the debconf_ui by running `oem-config debconf_ui`
<ogra> ah, nice
<ev_> superm1: why is that necessary?
<ogra> and if i understand the upstart script right i only need to touch /var/lib/oem-config/run to make it do its firstboot magic ?
<TheMuso> Hrm things are ok if I don't run the kvm command in the background.
<superm1> ev_, well i'm not seeing any templates on the installed system, so either copy_debconf was failing or they didn't get populated during postisnt into the debconf cache
<superm1> (or both)
<smoser> slangasek, yes. i use console output now and it works fine. well, and it doesn't run in sysv anymore, but a upstart script.
<slangasek> smoser: "it"?
<slangasek> you mean you still have a hack in place?
<smoser> well, that used to run via ec2-init init script, which ran from sysvinit
<smoser> but it now runs in upstart job, and writes to console using 'console output'
<smoser> so, no, dont need hack
 * ccheney uploaded 13 packages today :)
<bryce2> jdstrand, agd57
<bryce2> jdstrand, on #radeon
<lifeless> james_w: is there a plan to import experimental as well ?
<james_w> it is done already
<lifeless> james_w: \o/
<james_w> lifeless: debhelper is safe to delete
<lifeless> james_w: cleaned
<james_w> lifeless: thanks
<lifeless> james_w: https://bugs.edge.launchpad.net/udd/+bugs?field.searchtext=collision+zsh looks the same to me
<lifeless> james_w: I'm trying to learn the pattern to look for, so feedback appreciated
<james_w> lifeless: repeated collisions in debian over a short period of time some months ago or earlier
<james_w> that does indeed look the same
<james_w> anything with the longer bug description is probably something difference
<ccheney> mvo: bug 516727, any idea?
<ubottu> Launchpad bug 516727 in openoffice.org "could not do system upgrade error message E: Couldn\'t configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Undecided,New] https://launchpad.net/bugs/516727
<mvo> ccheney: I have a look in a bit
<slangasek> ccheney: why is there a pre-depends?
<lifeless> bryce2: so, why is mesa 7.7 in experimental ?
<slangasek> ccheney: oh, ignore me; I read the message backwards, I know what the pre-dep is
<ccheney> ok
<Sarvatt> is it intended (or known) that nothing plymouth related is getting put in the initrd right now?
<persia> Sarvatt: Might be a local issue: some people are reporting the opposite.
<slangasek> no, it's quite deliberate
<slangasek> it's *not* supposed to be in the initramfs
 * persia is happily corrected
<slangasek> putting it in the initramfs means putting the framebuffer in the initramfs, means everything else is delayed until that's done when it could have been started in parallel
<slangasek> (also, you might prefer an initramfs that doesn't have, oh, pango)
<ogra> why ?
<ogra> :)
<ccheney> i have enough ram just put all of ubuntu into initramfs :)
<Sarvatt> why have a splash at all if it's only going to be shown for ~1 second then?
<persia> Um, how long does that take to load when booting?
<slangasek> because splash is not the purpose of plymouth, it's just a side-effect :)
<slangasek> plymouth gives us serialization of boot-time interaction
<ccheney> persia: ~ 2GB linear read, hmm yea more than 10s :)
<Sarvatt> it doesnt show the splash until ~9-16 seconds in on my 4 machines, then goes away a second later when X starts
<slangasek> and it works on things other than a graphics-capable framebuffer
<slangasek> Sarvatt: the job dependency chain there is mountall (virtual-filesystems) -> udev -> udevtrigger -> plymouth-splash; there may be some optimization that needs to be done yet at the mountall stage
<slangasek> oh right - ureadahead inserts itself before mountall
<Sarvatt> why are the initramfs-tools hooks/scripts still shipped if they don't do anything? its not even possible to put it in the initrd with plymouth-set-default-theme --rebuild-initrd anymore for people who would like to see a splash like in the previous version
<slangasek> they do things for certain cases where questions need to be asked in the initramfs
<slangasek> (e.g., cryptsetup)
<slangasek> you could set the FRAMEBUFFER=y option in /usr/share/initramfs-tools/conf-hooks.d/ to force it
<Raydiation> hm im just packaging a package vor lucid and im in the control file where it says Depends ${shlibs:Depends}, ${misc:Depends}
<Raydiation> i need these dependencies: python-lxml python-django python-mutagen apache2 sqlite3 libapache2-mod-wsgi python-pysqlite
<Raydiation> how do i add them?
<Hobbsee> Raydiation: usually, by adding their corresponding -dev packages to the build depends
<Raydiation> Hobbsee: ty
<Hobbsee> yw
<StevenK> cjwatson: You fixed the grub-pc error that just made -netbook blow up in a screaming heap?
<Laibsch> lool: I'd like to talk to you about kasumi if you have a minute
<ccheney> why is qemu-arm-static now a recommends of ubuntu-dev-tools?
<ccheney> persia: i'm looking at you :-P
<ScottK> Reccomends sounds pretty heavy.
<ccheney> ScottK: yea sounds a bit odd
<ScottK> (even if it's spelled right)
<ScottK> I'd say go ahead and drop it to suggests.
<ccheney> registration just opened for Debconf 10 :)
<micahg> was language-support-translations replaced with language-pack?
<Laibsch1> Ubuntu is not present at FOSDEM?
<persia> ccheney, ScottK: feel free to make it Suggests: if you think that's better.
<micahg> can someone please tell me which package to depend on in place of language-support-translations-XX
<dupondje> pitti: nice quick fix for xorg :)
<KevinK> I don't suppose anyone knows where I can find a java irc channel do they? #java seems to be invite only. (Thats what IRC is telling me unless im smoking something :)
<jussi01> KevinK /msg alis help list
<jussi01> KevinK: you can search the channels with alis :)
<KevinK> ahh. thanks
<lool> Riddell: Not really; sorry; perhaps reassign if these are urgent
<Laibsch> lool: Are you coming to FOSDEM?  I'd also like to talk with you about kasumi if you have the time.
<lool> Laibsch: I originally intended to but cancelled
<Laibsch> unfortunate
<lool> Laibsch: I saw your ping earlier, but you weren't online; I'm afraid you pinged me at 3 or 4 am my time
<Laibsch> Ubuntu is not present there?
<lool> At least one person is going
<lool> Probably two
<Laibsch> Hehe, me?
<lool> (sorry, from Canonical; there are more Ubuntu people coming)
<Laibsch> Well
<Laibsch> Can we talk briefly about kasumi?
<lool> e.g. pkg-multimedia people are coming
<lool> Laibsch: Sure
<Laibsch> cool
<Laibsch> thanks
<lool> Laibsch: How did the patches get received upstream?
<Laibsch> Ikuya-san, the maintainer of kasumi said they should be in the next release
<lool> Laibsch: That's nice, when is it slated for?
<Laibsch> but I have seen no activity to that effect in CVS/SVN or whatever they use :-(
<Laibsch> not a set date
<Laibsch> I previously thought they had a fixed six-months schedule
<Laibsch> but that would have been about ten days ago ;-)
<lool> Laibsch: Did they give you the impression they understood the changes and the value of the changes?
<Laibsch> to be honest
<Laibsch> I'm quite sure they don't
<Laibsch> At least not Ikuya-San
<Laibsch> And I have not had any reaction from anybody else
<lool> That's a pity
<Laibsch> They will likely apply them nonetheless ;-)
<Laibsch> I'll keep pushing the topic from time to time
<Laibsch> Anyways
<Laibsch> Finding a sponsor has been more difficult than I thought.  So far I've talked to four Japanese DD and they all are generally helpful and well-meaning.
<Laibsch> But none of them seem to (knowingly) use the package (not a surprise, it's fairly minimal and could be mistaken to be part of another package)
<Laibsch> kasumi is just the front-end to manipulate a dictionary with entries for conversion from Kana characters to Kanji
<lool> persia: Do you use kasumi?  ^
<Laibsch> lucid DebianImportFreeze is looming and I'm starting to be afraid none of them may act on the thing in time
<lool> persia: Context: trying to find people who can review the package
<Laibsch> the package is easy enough
<lool> Laibsch: Don't worry about DebianImportFreeze, but do try hard to get it in ASAP
<Laibsch> it has a fully English interface
<Laibsch> Well, I also want to improve scim-anthy which isn't in the best of shapes, either
<Laibsch> so, clearing kasumi would help me do that
<Laibsch> lool: I think you would be in a position to test the app
<Laibsch> it's really VERY simple
<Laibsch> if you have the time, I'd appreciate if you considered sponsoring it into Debian
<lool> Laibsch: If you tell me upstream will eventually merge the fixes, I'm ok with taking an intermediate package which only has the packaging updates
<Laibsch> I have also pinged broonie about it, but the last time I talked to him he said he would be busy for a while.
<lool> Laibsch: Could you find one third party to test it in Debian?
<lool> I can do the sourceful review and the upload parts, but would prefer if we'd test these
<Laibsch> what do you mean intermediate package?
<lool> A package with all the fixes we exchanged about, except the autotools ones
<Laibsch> what kind of test would you be looking for? start the program, click a few buttons and make sure it doesn't bomb?
<Laibsch> intermediate meaning *just* those fixes and nothing else?
<lool> Laibsch: Oh more fixes are fine  :)
<Laibsch> OK
<Laibsch> I was afraid I'd have to pull out other stuff
<lool> Laibsch: I just don't think it's maintainable to add the autotools fixes downstream
<Laibsch> I wouldn't have had the time
<Laibsch> agreed
<Laibsch> all the fixes are in the mentors package: http://mentors.debian.net/debian/pool/main/k/kasumi/kasumi_2.5-1.dsc
<Laibsch> lool: what kind of test would you be looking for? start the program, click a few buttons and make sure it doesn't bomb?
<Laibsch> has to be done by a DD?  or just a Debian user?
<sebnerr> AH, whats with that Bug that mouse and keyboard is not working when gdm starts
<lool> Laibsch: Sorry, got distracted by phone
<lool> Laibsch: Some trustworthy user or preferably developer would be great
<Laibsch> OK
<lool> Laibsch: Yeah, just that there are no major regressions basically
<Laibsch> I think you could easily verify yourself
<Laibsch> The program has what, like 3 buttons?
<Laibsch> it *really* is very simple
<debfx> why isn't virtualbox-guest-additions synced from debian testing? it doesn't have ubuntu specific changes
<Laibsch> ArneGoetje: maybe you'd be available to test the kasumi package as well? (see discussion above with lool)
<micahg> hi, can someone please tell me which package to depend on in place of language-support-translations-XX
<micahg> pitti: for thunderbird-locales should I depend on language-pack-xx now instead of language-support-translations-XX
<lifeless> ls /win 82
 * jpds hands lifeless Â£82.
<Keybuk> pitti: hai
<Keybuk> pitti: __abort_msg
<persia> lool: I don't use it, but you're the second person to ask for it to be reviewed.  I'll take a look.
<lifeless> cr3: where art thou?
<cr3> lifeless: you found me, and I added you to my calendar just in case I forget... or get distracted by a shiny object
<pitti> micahg: I wonder whether we need it at all; these days, language selector installs the necessary packages
<pitti> Keybuk: hi
<pitti> Keybuk: __abort_msg ?
<micahg> pitti: k, but not for thunderbird yet
<pitti> oh -- that should be fixed then
<Keybuk> pitti: yeah, was just reading the glib bug
<Keybuk> are you happy for libnih to just keep on using __abort_msg ?
<micahg> yes, but maybe not for Lucid
<pitti> Keybuk: sure; I don't have a problem with it, I just reverted it in glib because other distros have apparently
<Keybuk> pitti: I made it a weak symbol in libnih
<Keybuk> so if glibc doesn't have it, it's not used
<lifeless> pitti: yo. package branches... we should talk
<pitti> lifeless: o/ (sorry, currently busy with sth. else)
<lifeless> pitti: think we can make time before 6pm tomorrow ? :)
<pitti> sure
<pitti> lifeless: I'll find you after my current task
<lifeless> heh, I'm slated with cr3 shortly.
<cr3> lifeless: I might be ready earlier, so I'll ping you when ready
<lifeless> cr3: I'm still prepping a test package
<lifeless> cr3: so no rush
<Mad_Gouki> Will Firefox 3.6 be put in the repositories soon or will it be updated when lucid comes out?
<micahg> Mad_Gouki: Firefox 3.6 is in Lucid
<Mad_Gouki> yes but what about karmic?
<hwilde> anybody know if talk and talkd are discontinued or whatnot?
<micahg> Mad_Gouki: hmm...at some point...not sure exact;y when yet, you can get from the mozilla team's PPa
<micahg> ppa:mozillateam/firefox-stable
<Mad_Gouki> ah, thank you micahg
<sebner> pitti: /me thinks gdm start up too early so keyboard and mouse are not working. I think we had that bug in the past already
<alkisg> Today's (or yesterday's, depending on the timezone) updates made my amd64 installation crash after 1-2 minutes of usage. This also happens for me with the i386 daily live.
<alkisg> Is there any way to mass-downgrade the following list, to verify which one of them is causing the problem? http://alkisg.pastebin.com/d556fecc
<pitti> sebner: weird; it does wait on udev to finish
<sebner> pitti: I can't use my mouse or keyboard so I have to do a hard reset. My workaround for now is starting in recovery mode and starting gdm there
<mdeslaur> sebner: you get a freeze at the gdm login screen?
<sebner> mdeslaur: I'm not sure, I think it's a freeze sometimes and sometimes just not taking input
<mdeslaur> sebner: is that with nvidia?
<sebner> mdeslaur: aye
<sebner> mdeslaur: since yesterday
<sebner> mdeslaur: before the last nvidia update(yesterday) though
<ion> mdeslaur, sebner: I have that issue due to a race between X and plymouth since a recent plymouth upload. It helps to keep hitting ctrl-alt-F1 immediately when X appears, and to only return to X after getting to the virtual console first.
<sebner> hmm
<mdeslaur> sebner: I have the same...happens about 1 out of 2 boots. Curiously, this morning when I booted I was frozen at the gdm screen, but when typing I could see graphical corruption near the top of the screen.
<sebner> I'll try that
<sebner> but I have the feeling that it gdm works normally in 1 out of 10 cases
<sebner> mdeslaur: I saw that too a few minutes ago but for the first time
<lifeless> james_w: could you send another mail about 'hey here is the udd list and its good' to u-d ?
<james_w> lifeless: yes
<lifeless> james_w: pitti and seb amongst others were like 'huh' when I asked if they were on the list ;)
<lifeless> james_w: cool, thanks
<Q-FUNK> hi! is there any instruction on how to convert an init script to an upstart job?
<Q-FUNK> I'd like to convert the init scripts of cups and pulseaudio.
<lifeless> bryce2: there are other patches I've put in upstream bugzilla but they are cosmetic so I don't really care :)
<bryce2> lifeless, well I can pull them in too if you'd like
<bryce2> lifeless, btw turned out the patches just needed -p0 instead of -p1
<lifeless> ah
<lifeless> https://bugs.freedesktop.org/show_bug.cgi?id=26389
<bryce2> lifeless, uploading now
<ubottu> Freedesktop bug 26389 in Server/general "small randr code cleanup" [Normal,New]
<bryce2> lifeless, it's been my experience that the xorg-server bug tracker bug reports largely get ignored; upstream pays attention mostly just to the drivers
<bryce2> so the trick I usually use for xorg-server bugs is to "accidentally" file them against a driver
<bryce2> however in this case since it's an xrandr feature against xvfb, can't use that trick
<bdmurray> stgraber: should bug 516403 be invalid then?
<ubottu> Launchpad bug 516403 in ltspfs "Please merge ltspfs (0.5.14-1) from Debian Testing" [Undecided,New] https://launchpad.net/bugs/516403
<bryce2> lifeless, an alternate approach is to give the patches to debian (jcristau @ #debian-x or #ubuntu-x) and he can also push into upstream X git if appropriate
<lifeless> https://bugs.freedesktop.org/show_bug.cgi?id=26376
<ubottu> Freedesktop bug 26376 in DDX/vfb "Typo in Xvfb help." [Normal,New]
<pitti> mdeslaur: would you mind to add upstream bug links to the g-p-m patches?
<pitti> mdeslaur: thanks in advance!
<cr3> lifeless: ready, where are you?
<lifeless> bryce2: those are the other two bugs anyhow
<lifeless> cr3: in my chair :). One sec...
<bryce2> lifeless, ok in my gtg todo list, I'll take a look within the next few days.
<ari-tczew> pitti: could you sponsor merges for main?
<lifeless> bryce2: thanks!
<mdeslaur> pitti: I haven't submitted them yet...they're to go with gnome-screensaver being a dbus service
<lifeless> bryce2: like I say though, they don't really matter - just little things I noticed in the code as I explored the RANDR interface
<pitti> ari-tczew: I'm a core-dev, yes
<ari-tczew> pitti: have time now?
<ari-tczew> I'm waiting too long
<pitti> ari-tczew: please just subscribe ubuntu-main-sponsors
<pitti> no need to block on a single person
<ari-tczew> Subscribed.
<lifeless> cr3: ok, I'm waiting for a PPA build
<pitti> thanks
<lifeless> cr3: so that I have something approximating test code to work with with you
<cr3> lifeless: no problem, I have plenty to work on in the meanwhile
<lifeless> k I'll  get back to you
<ari-tczew> pitti: my debdiffs are there: bug 503136 ; bug 499671
<ubottu> Launchpad bug 503136 in dmraid "Merge dmraid 1.0.0.rc16-2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/503136
<ubottu> Launchpad bug 499671 in texinfo "Merge 4.13a.dfsg.1-5 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/499671
<pitti> ari-tczew: I won't touch the dmraid stuff, I don't understand this at all; I can take a look at texinfo
<ari-tczew> ok
<TheMuso> ari-tczew: I'l take care of dmraid.
<ari-tczew> TheMuso: great!
<TheMuso> ari-tczew: `There is a newer version in Debian, you may want to merge again with that.
<ari-tczew> TheMuso: could you wait for me? give me a 10 minutes
<TheMuso> ari-tczew: Sure, take your time.
<bdmurray> james_w: does https://code.edge.launchpad.net/~hmontoliu/ubuntu/lucid/denyhosts/fix-516160/+merge/18467 have the right reviewer?
<bryce2> apw, good news, -nouveau suspends
<bryce2> apw, now resume on the other hand...
<persia> heh
<ari-tczew> TheMuso: go ahead
<TheMuso> ari-tczew: Thanks.
<apw> bryce2, ahhh welll, about the same as before then
<pitti> ArneGoetje: bug 407649
<ubottu> Launchpad bug 407649 in scim-anthy "Sync scim-anthy 1.2.7-1 (main) from Debian unstable (main)." [Undecided,Incomplete] https://launchpad.net/bugs/407649
<TheMuso> ari-tczew: Looks good, uploading. I added the launchpad bug to the changelog entry, so it will be closed on upload. Please ensure you add the launchpad bug number to changelog entries in future, so your sponsor request bug gets closed.
<bryce2> apw, resume from hibernate also does not work
<apw> bah, what is with nvidia h/w, they just love to make it hard .... <- bryce2
<ari-tczew> TheMuso, thanks!
<TheMuso> ari-tczew: You're welcome.
<Flimm> Hello, I'm trying to submit a proposal to freedesktop's mailing lists, but
<Flimm> I keep getting "not member" messages whenever I send an email
<Flimm> Is there a freedesktop membership?
<bryce2> Flimm, yeah gotta join first
<Flimm> bryce2: how?
<Flimm> I've already subscribed to the mailing list
<jdstrand_> dpm: https://bugs.launchpad.net/ubuntu/+source/gui-ufw/+bug/459554
<ubottu> Ubuntu bug 459554 in gui-ufw "gufw wont detect the enabled state of ufw in karmic" [High,Fix released]
<dpm> ah, thanks jdstrand, looking...
<jdstrand_> dpm: thank you! :)
<Flimm> I suppose I should join #freedesktop, what was I thinking?
<ari-tczew> TheMuso: could you sponsor one simple fakesync by bdrung? bug 511448
<ubottu> Launchpad bug 511448 in libxml-security-java "Fakesync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Triaged] https://launchpad.net/bugs/511448
<TheMuso> james_w: How often does the importer get run? It seems alsa-tools hasn't been updated from debian. Is this a known problem package?
<TheMuso> ari-tczew: I'll take a look when I get back in a little while.
<alkisg> How can I see if the daily-live 20100202 has xserver-xorg-core 2:1.7.3.902-1ubuntu9   or -10? I think that's what's causing my crashes...
<fale> hi
<pitti> alkisg: check the .manifest file on cdimage (same place as the .iso)
<alkisg> Ah, sorry, found it at the manifest. It has -ubuntu9, so I bet it'll work fine for me. Downloading..
<alkisg> Thank you pitti
<ari-tczew> pitti: and what about merge texinfo?
<pitti> we'll get to it
<peppino87> hi
<ari-tczew> hello
<james_w> TheMuso: it's not know problematic, I asked it to ensure that alsa-tools is up to date
<fale> hi peppino87
<peppino87> how do you create the official live-cds?
<cjwatson> the livecd-rootfs package builds the live filesystems
<cjwatson> https://code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline (and the stuff in configs/devel there) deals with ISO assembly
<peppino87> cjwatson: thank you
<ari-tczew> pitti, TheMuso: could you sponsor too small fakesync? bug 512430
<ubottu> Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430
<peppino87> cjwatson: do you have any how-to or similar to create an ISO?
 * fale is also interested in peppino87's question... anyone knows?
<TheMuso> james_w: Thanks.
<james_w> TheMuso: should be up to date now
<TheMuso> cheers
<crimsun> would an archve admin please accept ptlib so that I can test opal?
<maxb> james_w: Hi - do you know when you might be able to have a look at bug 516464?  Wondering whether I should consider doing a non-UDD merge, in absence of a working import.
<ubottu> Launchpad bug 516464 in udd "Debian import branches are missing for 'subversion'" [Undecided,New] https://launchpad.net/bugs/516464
<james_w> maxb: looking
<bryce2> apw, I plugged a GeForce 7600 in, and it does resume, but freezes with a white screen :-/
<bryce2> apw, however it does not have the crash-on-invert-screen issue that the G8x cards did
<ari-tczew> james_w: could you sponsor 3 small fakesyncs for main?
<slangasek> why do you need to fakesync?
<slangasek> orig.tar.gz skew?
<ari-tczew> cleaning repositories
<ari-tczew> this is a problem?
<apw> bryce2, some good some bad
<directhex> it looks like i'm not the only one totally confused about the correct place to put browser plugins these days
<slangasek> ari-tczew: I'm asking why a fakesync is needed; I guess james_w knows since he's the one who said it was needed :)
<james_w> yeah orig.tar.gz mismatch
<ari-tczew> for autosync in future
<directhex> /usr/share/ubufox/plugins/libgnashplugin.so - okay, that's a new record for messed-up-ness
<directhex> wait, sofiles in /usr/share? sigh
<bryce2> apw, I'm pretty much done for now if you'd like to poke on the box.  otherwise tseliot's going to test some jockey stuff
<ari-tczew> bug 511448 ; bug 517297 ; bug 512430
<ubottu> Launchpad bug 511448 in libxml-security-java "Fake sync libxml-security-java 1.4.3-2 (main) from Debian testing (main)" [Undecided,Triaged] https://launchpad.net/bugs/511448
<ubottu> Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297
<ubottu> Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430
<james_w> ari-tczew: I don't have time right now I'm afraid, my stack is a bit deep
<ari-tczew> so maybe someone else can do it ?
<bdrung> when was the last auto sync? tabmixplus is in testing since over an week, but it is still not synced.
<cjwatson> bdrung: about four hours ago
<cjwatson> but it didn't include new packages, which tabmixplus is
<bdrung> cjohnston: it would be nice if the new package were included. i know at least three of them.
<cjwatson> I've synced tabmixplus since you asked nicely; a full new-source run will have to wait a bit
<cjwatson> and I'm cjwatson not cjohnston ;-)
<bdrung> cjwatson: sorry, that's due to tab completion ;)
<bdrung> cjwatson: will a new-source sync be run before feature freeze?
<cjwatson> yes
<bdrung> good
<bdrung> cjwatson: thanks for the answers and the sync
 * micahg won't ask for a sync of dojo then :)
<cjwatson> micahg: individual syncs aren't a problem, I'm just too deep in something else to deal with the fiddly bits of a full new-source sync ... done dojo
<ari-tczew> TheMuse: ping
 * persia suspects a need for s/e:/o:/
<mneptok> ari-tczew: tab-complete is your friend.
 * mneptok and persia seem to be mind-melded
<ari-tczew> mneptok: nobody is perfect
<mneptok> ari-tczew: if you look up that axiom in The Great Compedium, you'll see my photo
<mneptok> +n
<micahg> cjwatson: thanks..it wasn't urgent, just wanted it in Lucid :)
<ari-tczew> TheMuso: ping
<ari-tczew> mneptok: why I need see your photo? ; o
<cr3> pitti: are you familiar with the dbus error: Connection ":1.44" is not allowed to own the service "com..." due to security policies in the configuration file?
<cr3> pitti: the dbus system configuration says something like <policy user="root"><allow own="com.." /></policy>
<pitti> cr3: it usually means that you are lacking a /etc/dbus-1/system.d/packagename.conf with an "allow own" stanza
<cr3> pitti: I have /etc/dbus-1/system.d/com.ubuntu.checkbox.conf
<pitti> cr3: do you actually run the process as root?
<cr3> pitti: yes
<cr3> pitti: oh wait, on the client side, I run the process as the user but it is the backend called through dbus which should be started as root
<TheMuso> ari-tczew: pong
<pitti> cr3: your .service file has User=root ?
<cr3> pitti: for the user, I believe this is the corresponding policy: <policy context="default"><allow send_destination="com.ubuntu.checkbox" send_interface="com.ubuntu.checkbox" /></policy>
<ari-tczew> TheMuso: have time for sponsor fake syncs?
<TheMuso> ari-tczew: no
<pitti> cr3: right, but that's for receiving messages, not owning
<ari-tczew> pitti: got time?
<pitti> please; we'll get to it, but we are at a sprint this week
<bdrung> ari-tczew: btw, you should fill your motu application with real data
<ari-tczew> bdrung: huh? current I'm not applicating to MOTU
<cr3> pitti: /usr/share/dbus-1/system-services/com.ubuntu.checkbox.service indeed contains User=root
<bdrung> ari-tczew: i found https://wiki.ubuntu.com/ArturRona/MOTUApplication
<pitti> cr3: if you run the daemon manually with sudo, do you get the same error?
<cr3> pitti: works when running the client as root
<persia> Just having a template page doesn't constitute an application :)  Lots of people spend time preparing them.
<pitti> cr3: no, the server
<cr3> pitti: the server, defined in the .service file, runs fine as root. actually, it logs to /var/log/checkbox.log by default and the log was empty when attempting to run the client, as if dbus never started the server
<pitti> cr3: ok, sounds like you don't give the client enough privileges then?
<bdrung> doko: can you have a look at bug #517288?
<ubottu> Launchpad bug 517288 in python3-defaults "Sync python3-defaults 3.1.1-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/517288
<cr3> pitti: I purged and reinstalled the package, then everything works again. so this might be an upgrade problem, I'll have a closer look
<mpt> mvo, tremolux: https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=327&rev1=326
<lifeless> anyone know where jkakar is?
<elmo> lifeless: on a plane
<elmo> or at least heading to the airport
<lifeless> ah
<lifeless> thanks
<lifeless> cjwatson: bug 516344 is the xdg uesr dirs one, if you care.
<ubottu> Launchpad bug 516344 in xdg-user-dirs "prompt to rename homedir to subdir of homedir" [Undecided,New] https://launchpad.net/bugs/516344
#ubuntu-devel 2010-02-05
<breinera> how would I got about making my program automatically add itself to Gnome's Main Menu
<directhex> a dh_ command of some kind or another
<persia> Um, no.
<directhex> or maybe just putting a .desktop in the right place
<persia> Install an XDG-compliant .desktop file.
<persia> Yes :)
<directhex> yeah, dh_desktop is a noop. when did that happen?
<directhex> i'm getting too old for this stuff
<persia> When triggers became available.
<seb128> directhex, when it moved to a trigger
<persia> dh_desktop used to regenerate the MIME db, so never actually affected the menu.
<breinera> is there a website that talks about how to create XDG-compliant files
<directhex> seb128, do you know how one would obtain a native pbuilder? moonlight 2 packaging is pretty much functional (if not yet uploadable), but i expect build failures might happen on unconventional arches like arm
 * persia digs up the URL
<TheMuso> c
<TheMuso> whoops
<persia> breinera: http://standards.freedesktop.org/menu-spec/latest/apc.html is probably the best place to start.
<breinera> thanks persia
<seb128> directhex, no
<directhex> hm
<jdong> hmm tjaalton: Regarding bug 430532, I've got a vmware fusion with a lucid guest and no vmmouse working... Would be happy to guinea-pig udev rules for you, etc
<ubottu> Launchpad bug 430532 in xserver-xorg-input-vmmouse "should depend on -vmmouse?" [Medium,Triaged] https://launchpad.net/bugs/430532
<jdong> (commented on bug report as well)
<breinera> I looked at the link and some example files, but how would I tell it to go into Accessories or Internet or Something else
<persia> breinera: Categories.
<cjwatson> breinera: the way it works is that you specify Categories that make sense, and then the OS menu implementation decides which specific menus those map to
<persia> http://standards.freedesktop.org/menu-spec/latest/apa.html
<cjwatson> you don't say which specific menu your app goes in, because the list of available menus isn't necessarily the same from desktop to desktop
<breinera> thanks
<breinera> and it makes more sense now
<Sarvatt> is grub2 whats forcing efifb to be used and killing the console for alot of people?
<cjwatson> Sarvatt: not knowingly ...
<Sarvatt> its happening in debian too, started yesterday here and I'm getting it on all my machines. nouveau can kick out the efifb ([    3.335681] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver) but intel can't and I get no display until X (and no consoles still after)
<Sarvatt> grub2 just seemed like the most likely culprit looking at the changes in the past 24 hours since it started loading efifb and considering its happening in debian unstable also
<cjwatson> Sarvatt: I suppose it could be http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/revision/1855.8.190
<cjwatson> I don't know for sure, and somebody should report it to grub-devel if it does turn out to be that
<cjwatson> or a few other loader changes a bit before that
<Sarvatt> looks like http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/revision/1920/util/grub.d/10_linux.in ?
<cjwatson> Sarvatt: ah (and ew)
<cjwatson> Sarvatt: is there a bug for this, explaining why efifb is badbad?
<Sarvatt> i just noticed this about an hour ago, haven't looked into it too much yet but googling gfxpayload=keep seems to bring up a ton of bugs, lets see
<cjwatson> no, don't bother with that line of inquiry
<cjwatson> gfxpayload=keep is not intrinsically related to efifb
<cjwatson> is this on non-EFI hardware?
<Sarvatt> yep non-efi, its loading efifb for everyone now because we have that kernel config option it looks like
<Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245
<ubottu> Debian bug 567245 in grub-pc "gfxpayload=keep broken" [Normal,Open]
<Sarvatt> I guess it's just KMS fb's that can't handle it
<cjwatson> Sarvatt: well, I'm happy to nuke that option for Ubuntu for the time being
<cjwatson> Sarvatt: (fwiw I have kms and it works for me, but hmeh)
<cjwatson> *meh
<Sarvatt> ati?
<cjwatson> intel
<cjwatson> grub2 1.98~20100128-1ubuntu3 reverts that check
<bryce2> which option is this?
<cjwatson> gfxpayload=keep in grub2
<cjwatson> which is frankly a bit of a crackful option anyway so I don't mind disabling it
<Sarvatt> thats for that cjwatson
<cjwatson> and mind even less stopping forcing it on :)
<pitti> james_w: what does it take to bless lp:~ubuntu-branches/ubuntu/lucid/ido/lucid (just uploaded/NEWed) into "the" lp:ubuntu/ido branch?
<aburch> What is the prefered way to bug people to merge new releases from Debian?
<kapdia> hmm
<kapdia> how can i join the ubuntu development?
<ScottK> !development
<ubottu> Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<ScottK> kapdia: ^^^
<kapdia> thanks ScottK
<kapdia> hmm i read through it, but I still don't know where to begin
<kapdia> ah ok
<kapdia> motu
<ccheney> i need a few packages synced from debian unstable but for some reason requestsync is failing to find them
<ccheney> ispell-fi 0.7-17.3, bgoffice 3.0-10, medicalterms 20100204-1
<fabrice_sp> ccheney, it's working here using -d option (as by default, requestsync looks at testing) ?
<fabrice_sp> oh: 404 error on getting the changelog
<ScottK> There's some latency is debian/changelogs being available, so either make the sync request bug by hand or wait and try again tomorrow.
<ccheney> ScottK: ok
<nigel_nb> Hobbsee, are you around? got a doubt...
<nigel_nb> Hobbsee, I working on a patch for gnome-media recently, but now there are around 8 new patches for various bugs.  So is there a point in doing the exercise of patching only one bug?
<nigel_nb> bah... "I was working"
<fale> is there an how-to/doc about how to create an ISO?
<akheron> is there a way to run upstart jobs as another user than root?
<akheron> I found an old blueprint that sounds promising: https://blueprints.launchpad.net/ubuntu/+spec/upstart-user-jobs
<akheron> but the man page for upstart 0.6.3 doesn't mention support
<jdong> mmmhmm I put that on my christmas wishlist :)
<jdong> it still hasn't arrived yet
<akheron> ah ok
<jdong> I mean, surely you can do some su hacks
<akheron> so all I can do is to su -c command user ?
<jdong> right
<akheron> bla :)
<akheron> well, thanks anyway
<jdong> sure thing :)
<jdong> wish I had a more elegant answer :)
<nigel_nb> jdong, can you take a look at my query above?
<tjaalton> jdong: re vmmouse; run ubuntu-bug $id on the vmware instance to collect relevant information for the bug. there should be a way to recognize the device and use vmmouse instead
<tjaalton> vbox is screwed though, since their mouse driver doesn't have a input device set by the kernel
<tjaalton> but uses the information from the vbox pci device
<jdong> interesting
<jdong> ok tomorrow morning I'll do so
<tjaalton> ok
<jdong> yeah definitely I know in jaunty/karmic we did a great job of autodetecting the device
<mneptok> jdong: thanks for being the first person on the Internet in 2010 i have seen spell "definitely" correctly.
<mneptok> </ranty_pet_peeve>
<jdong> hahah
<chrisccoulson> would somebody mind sponsoring a vte upload if they get the chance? (bug 516770)
<ubottu> Launchpad bug 516770 in vte "Update to 0.23.5" [Undecided,Confirmed] https://launchpad.net/bugs/516770
<chrisccoulson> there is a gnome-terminal update waiting, but it needs the latest vte, and I can't upload that myself
<aburch> How often are new package imported from Debian? (ie. packages that haven't been in Ubuntu before, not just a new version)
<persia> aburch: Prior to DebianImportFreeze, there is a sync during most weekdays, depending on how busy the archive admin of the day happens to be that day.  After Debian Import Freeze, new packages are only imported by developer request through FeatureFreeze.  After FeatureFreeze, new packages are only imported if there is both a developer request and an approved freeze exception.
<aburch> Hmm, so if a package has been in testing for more than one week it should already be imported to universe?  Well, I'll probably wait a few more days before asking further.
<persia> aburch: Well, check the set of packages in testing and not in universe, which is likely more interesting.  If that set is large, then it's worth saying something.  If not, then just wait a bit more unless we're tight against DebianImportFreeze.
<Laney> aburch: http://qa.ubuntuwire.com/multidistrotools/all.html#notinB should give you an idea, but take it with a pinch of salt
<jdong> tjaalton: errr see bug 517642; it doesn't seem like ubuntu-bug attached any of the useful debugging information. What should I manually do to provide you with useful information?
<ubottu> Launchpad bug 517642 in xserver-xorg-input-vmmouse "In lucid, vmmouse position glitches on grab/ungrab" [Undecided,New] https://launchpad.net/bugs/517642
<tjaalton> jdong: check the xorg apport script what it runs for the other packages. can't check it myself now
<jdong> tjaalton: ok thanks, added the hook. New bug 517659, closed old one
<ubottu> Launchpad bug 517659 in xserver-xorg-input-vmmouse "vmmouse glitchy position tracking in Lucid" [Undecided,New] https://launchpad.net/bugs/517659
<tjaalton> jdong: please file a bug against xorg to add the hook there, thanks :)
<jdong> hehe ok :)
<ccheney> if i am reading the weather forecast correctly there is expected to be ~ 3 ft of snow in DC by tomorrow
<ScottK> ccheney: More like 1.5 to 2 feet, but still a lot.
<ScottK> It's snowing now.
<ccheney> well the site i saw claimed 5" this afternoon, another 15" tonight, then 8" more tomorrow
<ccheney> but maybe i misread what they meant
<jdong> eh it's a weather forecast :)
<ccheney> in any case no one will be flying there most likely
<fabrice_sp> Woauh: Xorg is using 1gb of memory (in Karmic)! How can I see what part of XOrg is using that amount of memory?!
<ScottK> Not tomorrow.  Sunday should be OKish.
<TheMuso> ivanka1: Could you please download http://www.alsa-project.org/alsa-info.sh, and run it in a terminal like so: bash alsa-info.sh  Then give me the URL that it gives you. I need some information about your hardware, and this script will get that for me.
<ivanka1> TheMuso: doing it now
<TheMuso> ivanka1: Thanks.
<ivanka1> TheMuso: You got mail :-)
<TheMuso> ivanka1: thanks muchly.
<TheMuso> ivanka1: I forgot that the behavior had changed t o not uploading the details, but making a text file. Well done in figuring that out, and thanks again.
<ivanka1> thanks TheMuso - I now know more instructions for terminal than I did when I got up this morning :-)
<TheMuso> ivanka1: you learn something new every day. :)
<ivanka1> TheMuso: yes!
<TheMuso> ivanka1: So everything works, i.e microphone, headphones, but the only problem is that the internal speakers don't mute correct?
<ivanka1> themuso: correct
<TheMuso> ivanka1: ok great, that helps a lot.
<TheMuso> ivanka1: There is a bug already filed about this issue. If could please subscribe to https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/477226 I can talk you and the bug reporter through a suggestion I will be giving soon, once I am sure it may help. I'[ll be assigning it to the audio team, so I'll be subscribed as well, to track progress.
<ubottu> Ubuntu bug 477226 in linux "Sound simultaneously on headphones and speakers - Lenovo IdeaPad u350" [Undecided,New]
<slangasek> tjaalton: how exactly were you adding kinit to /etc/init/gssd.conf?
<slangasek> (OOI)
<TheMuso> ivanka1: Does your ideapad support a docking station, i.e does it allow you to connect a docking station to it? I think such stations usually connect to the bottom of the notebook.
<TheMuso> ivanka1: Knowing this helps narrow down whether my suggestion will work.
<ivanka1> TheMuso: No. It doesn't support a docking station.
<TheMuso> ivanka1: Right, that helps a lot, thanks.
<TheMuso> ivanka1: I posted something to try to the above mentioned bug. Please give it a try if you get a chance, and if you ahve any questions, feel free to ping me.
<ivanka1> TheMuso: thanks :-) Will try and do this in a bit
<TheMuso> ok np
<dholbach> pedro_, seb128_: is there a bug about rhythmbox-metadata using 100% cpu?
<seb128_> not that I know about at least
<didrocks> dholbach: I have this bug with Upnp enabled
<dholbach> didrocks: let me check
<dholbach> didrocks: nope, disabled
<didrocks> sorry then :)
<ari-tczew> dholbach: ping
<dholbach> ari-tczew: pong
<ari-tczew> dholbach: could you tell me what is wrong with debdiff on bug 517297
<ubottu> Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297
<dholbach> ari-tczew: as I can't upload the Debian tarball, I need the diff against the Ubuntu package
<persia> ari-tczew: It's best practice not to ask the same question in two channels.  it's also best practice to ask questions generally, rather than poking specific people (especially two *different* specific people in two *different* channels)
<ari-tczew> dholbach: so I need to make debdiff based on tarball which already exist in Ubuntu?
<dholbach> yes
<ari-tczew> ok
<dholbach> because we can only upload the package for the ubuntu release
<chrisccoulson> hey dholbach
<chrisccoulson> you having a good week?
<dholbach> heya chrisccoulson
<ari-tczew> understand
<dholbach> yeah, we got lots of stuff done :)
<chrisccoulson> excellent!
<chrisccoulson> it's strange having everybody around on IRC in the evenings ;)
<dholbach> how about you? how's life over there?
<chrisccoulson> yeah, it's ok here. i'm just winding down for the weekend now ;)
<ari-tczew> dholbach: do I need to get back DebianMaintainerField  from Debian?
<dholbach> yeah, just run update-maintainer
<ari-tczew> dholbach: update-maintainer is giving a correct DebianMaintainerField for Ubuntu, current exist DebianMaintainerField from Debian as I looked (without XSBC-Original-Maintainer)
<ari-tczew> so do I need to change it?
<dholbach> if we change something in Ubuntu, we update the maintainer field
<dholbach> https://wiki.ubuntu.com/DebianMaintainerField
<ari-tczew> dholbach: theoretically, we have next development cycle, Debian has got new upstream release, autosync will get package from Debian?
<ari-tczew> after this fakesync
<dholbach> ari-tczew: I think this is one of the packages that don't get many upstream updates any more
<ari-tczew> dholbach: understand, but I'm asking theoretically, generally for other packages too
<smoser> slangasek, you have  minute. https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/499520
<ubottu> Ubuntu bug 499520 in vm-builder "default uec-image requires at least 300 M of RAM to run - m1.small and c1.medium not needed by default" [High,Confirmed]
<ari-tczew> dholbach: updated. bug 517297
<ubottu> Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297
<dholbach> ari-tczew: I'm working on a few other things now
<slangasek> smoser: what's the concern there?  I thought that bug was already triaged to ureadahead, no?
<TheMuso> crimsun: Question about quirk stuff for connextant chips. I have access to hardware that works perfectly with no edxisting quirk, except for headphones not muting. Is it possible to do a quirk that only needs to set the correct bits for the nid in question, or will I have to write a totally new quirk table for this machine?
<TheMuso> crimsun: In sort, to fix only the headphone muting/unmuting, do I have to write init verbs for every input/output of the hda driver?
<lifeless> Keybuk: you should setup a 'translation group
<ScottK> pitti: Thanks for following up on the dkms/wl bug (506816).  I was afriad I was going to have to reinstall karmic and upgrade again.
<pitti> ScottK: it seems to be pretty common indeed
<pitti> and I don't believe it's specific to bcmwl; would just hit nvidia as well
<ScottK> It's also an example of why I really dislike the "Oh, you can't give us the needed info -> Invalid" triage policy
<ScottK> It gets perfectly fine bugs marked invalid when they should stay incomplete.
<pitti> well, it's fine; you can always reopen the bug if you have more data
<pitti> I was going to report a new one, and LP proposed this one
<ScottK> Right, but it discourages other people from adding data.
<cjwatson> ScottK: yes!
<ScottK> Well that's good.
 * cjwatson waves the "I agree" flag frantically
<cjwatson> although I do think we shouldn't be encouraging other people to add data to other people's bugs
<cjwatson> as a general rule
<pitti> I usually leave them in incomplete and let them time out after a month or two
<ScottK> I think that's better.
<pitti> it's the compromise that works well enough for me, and avoids overzealous closing
<cjwatson> though I'm inclined to think that if you don't want to see incomplete bugs, filter them out
<lamont> 2010-02-05 20:20:39+0000 [-] Build log: dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)
<lamont> wth???
<soren> lamont: Which package?
<lamont> indicator-applet-0.3.2+r342+201002050500 <-- I think it's actually in a private ppa, to be fair
<lamont> just wondering if it's the buildd or the package.  didn't seem like something the package would be involved with
<lamont> yeah - p3a
<soren> lamont: I've seen a package create its control directory "by hand".
<lamont> ah, ok
<cjwatson> REPLACES, people
<soren> lamont: I mean.. One that didn't even use debhelper. I doubt anything as new fangled as indicator-applet will be debhelper-less.
<StevenK> crimsun: Why did you just upload opal right over the top of my changes?
<StevenK> crimsun: And where is the ekiga merge that you said was mostly finished?
<lamont> https://edge.launchpad.net/ubuntu/+source/xf86-video-displaylink/0.3-0ubuntu1/+build/1486433 <-- soren: thoughts?
<persia> That one definitely isn't debhelperless :)
<lamont> where is umask hidden in /proc/NNN/?
<soren> lamont: pass
<lamont> heh
<StevenK> lamont: environ?
<lamont> no, not so much
<StevenK> Yeah, that was a guess
<cjwatson> ICBW but it's not obvious to me that it's there at all
<lamont> cjwatson: kinda where I was landing too...
<lamont> that's the only explanation I can find for why a build would be so, um, strange as to create control mode 700 instead of 755.
<lamont> only underlying difference is that it's running karmic for the base OS, instead of, um, dapper
<StevenK> Google is failing me for trying to figure out if umask is under /proc, too
<lifeless> cr3: after lunch ok for you?
<lifeless> I have the goods
<MacSlow> seb128_, there you go https://edge.launchpad.net/notify-osd/trunk/ubuntu-9.10-sru
<seb128_> MacSlow, thanks
<cr3> lifeless: unfortunately, I have two hours of meetings scheduled after lunch
<lifeless> cr3: meep
<lifeless> cr3: 4pm then ?
<fabrice_sp> seb128_, any opinion on bug 285417 ?
<ubottu> Launchpad bug 285417 in ubuntulooks "[intrepid] gtk2-engines-ubuntulooks can't be installed" [Undecided,Confirmed] https://launchpad.net/bugs/285417
<seb128_> intrepid?
<seb128_> fabrice_sp, no
<fabrice_sp> the bug report comes from Intrepid, but they are willing to patch the package to be compatible with lucid's theme (and I proposed removal)
<seb128_> I'm busy right now, will read those 10 pages comments next week
<seb128_> I'm not sure I understand the issue
<fabrice_sp> ok. Thanks for looking at it
<seb128_> the theme is ubuntulooks not Human
<seb128_> just rename any conflicting file
<fabrice_sp> but does i make sense to still ahve a theme that is not used anymore in Ubuntu?
<fabrice_sp> anyway, if you are busy, I don't want to disturb you
<seb128_> it's rather than I don't really have an opinion about that
<seb128_> if some people still use the theme I don't see the issue with a renaming
<fabrice_sp> ok
<seb128_> I don't really care either way to be honest
<seb128_> do whatever you think works better for users
<fabrice_sp> fair enough :-)
<Caesar> kees: can you independently confirm for me that fuse-utils 2.7.2-1ubuntu2.1 contains an /etc/fuse.conf whereas fuse-utils 2.7.2-1ubuntu2 did not?
<crimsun> StevenK: "just"?
<crimsun> StevenK: I did it piece-wise; I don't tend to upload if the build-deps aren't satisfiable in a schroot and pbuilder
<crimsun> StevenK: please note that -4 dropped the celt build-dep; it made more sense at the time that I used bzr merge-package (from sid) to just use that.
<crimsun> TheMuso: generally don't need an entirely new quirk for that
<crimsun> TheMuso: e.g., you could switch(foo) case blah in the appropriate patch_cxt..()
<kees> Caesar: checking, one sec
<kees> Caesar: when I install fuse-utils 2.7.2-1ubuntu2 on hardy, I have /etc/fuse.conf
<Caesar> Oh doh
<Caesar> I see what's going on
<Caesar> Sorry
<Caesar> We have an internal package that provides /etc/fuse.conf and Replaces: fuse-utils
<Caesar> So it looked to me like the currently installed 2.7.2-1ubuntu2 fuse-utils didn't provide /etc/fuse.conf
<Caesar> Sorry to waste your time
<crimsun> StevenK: ah, I see what you're referring to. Sorry about that; I had the merge prepared but had been waiting for ptlib to be NEWed.
<statik> hi pitti, i proposed some changes to python-mkdebian. if you think they are crazy, just reject them I won't mind :) https://code.edge.launchpad.net/~statik/python-distutils-extra/modernize/+merge/18726
<TheMuso> crimsun: by patch-cxt do you mean the various codec .c files, or a function/structure within one of those files?
<jbebel> Asbas2h.
<JFo> bryceh, I have asked to join Greasemonkeying-of-Launchpad Developers :-)
<statik> thanks pitti, fixed and pushed
<crimsun> TheMuso: the functions inside sound/pci/hda/patch_conexant.c, e.g., patch_cxt5045()
<TheMuso> crimsun: ahhh thanks a million, will dig deeper into that later.
<crimsun> TheMuso: yw
<pitti> statik: hi! looks good now, will merge
<statik> sweet! maybe i will have some luck adding this functionality to debhelper
<lifeless> Keybuk: dpm: time to create that translation group, I found the last spot needed to enable new translations again.
<pitti> lifeless: jIH HoHta' gdm
<lifeless> pitti is uploading now
<lifeless> pitti: thanks :)
<Keybuk> lifeless: ubuntu-l10n-tlh
<lifeless> pitti: you should join https://edge.launchpad.net/~ubuntu-l10n-tlh
<lifeless> Keybuk: https://translations.edge.launchpad.net/ubuntu/lucid/+lang/tlh still claims it is unmanaged
<lifeless> dpm: ^
<dpm> lifeless, there needs to be a team managing the translations: https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
<lifeless> dpm: isn't that the team keybuk made?
<lifeless> dpm: 10:08 < Keybuk> lifeless: ubuntu-l10n-tlh
<dpm> lifeless, I can assign the new team to ubuntu-translators, but please take a few mins to read that page. It's a very simple process, and we ask all Ubuntu translation teams to follow that - I'm not trying to make it difficult, I just don't want to be unfair to other new teams
<pitti> Keybuk: mind to fix the "langauge" typo? :-)
<TheMuso> mvo: Thanks for the possible webkit fix. I'll install the latest synced webkit and see if the problem goes away. If not, I'll try your fix. Thanks again.
<pitti> lifeless: Scott] ghajtaH Daq ghurmoH jIH DaH
<mvo> TheMuso: I'm bulding the fix currently, if you have i386 I can give you the deb once its finished building :)
<pitti> lifeless: (Scott has to approve me now)
<TheMuso> mvo: I'm on amd64.
<TheMuso> mvo: Happy to wait to grab the source from somewhere.
<mvo> ok, thanks TheMuso
<TheMuso> np
<lifeless> Keybuk: will you do as dpm asks? makes the translations come through langpacks so much better
<Keybuk> lifeless: I gave it a brief read, but haven't worked out what step(s) we've missed yet
<plars> bdmurray: I see bughugger package available in lucid now, but I seem to get a backtrace when running it.  I seem to be missing a module named quickly.widgets.async_task_progressbox.  Have you seen this?
<didrocks> plars: oh really? you should install quickly-widgets so
<didrocks> I'm adding the missing dependency
<plars> didrocks: will try that, thanks
<StevenK> \o/
<didrocks> plars: y/w :)
<didrocks> I first try to figure out why python-distutilsextra didn't add it itself
<lifeless> mvo: why is it add-apt-repository, not apt-add-repository?
<lifeless> didrocks: rename it! ;)
<didrocks> lifeless: I know, it's on my todo for next week ;)
<ojwb> hi folks - should a new package get automatically pulled into lucid when it appears in debian testing?
<kirkland> slangasek: http://paste.ubuntu.com/369848/
<tjaalton> slangasek:  re kinit; putting it in the pre-script failesd with some preauth error. the real fix would be to make rpc.gssd work with the machine upn
<slangasek> tjaalton: mmk :)
<slangasek> kirkland: pretty
<tjaalton> slangasek: but that's a part of my thesis, so it'll get resolved one way or another..
<lifeless> ojwb: I think so
<slangasek> tjaalton: whoo :-)
<kirkland> slangasek: http://paste.ubuntu.com/369850/
<ojwb> lifeless: i guess there must be a lag as it hit testing on feb 1st: http://packages.qa.debian.org/n/notmuch.html
<lifeless> ojwb: archive admins have to +1 it
#ubuntu-devel 2010-02-06
<lifeless> or run a script or some such.
<lifeless> StevenK: ^
<ojwb> lifeless: ah, ok.  i guess i'll keep an eye on it, and prod if it hasn't appeared in a few more days
<lifeless> pitti: lp-project-upload should be in lptools or something like that - ubuntu-dev-tools is way opaque for non-ubuntu devs using lp
<mvo> lifeless: add-apt-repository> history mistake, apt-add-repository makes more sense
<cjwatson> ojwb: yes, there's a bit of a lag, but it'll happen before feature freeze
<jbebel> cjwatson: Is there a new preseed required to get grub to install automatically?  I'm getting the message that "You chose not to install GRUB to any devices."
<ari-tczew> ttx: ping
<jbebel> But if you tell it to continue without installing GRUB, it proceeds to install GRUB.
<ttx> ari-tczew: pong
<cjwatson> jbebel: fixed yesterday
<ari-tczew> ttx: could you review this, please? bug 512430
<ubottu> Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430
<cjwatson> jbebel: (grub-installer 1.49ubuntu4)
<jbebel> cjwatson: thanks.  I'll update our mirror and try again.
<ttx> ari-tczew: looking
<ttx> ari-tczew: will sponsor it... not today though
<ari-tczew> ok
<lifeless> mvo: perhaps a symlink and then removal ?
<tjaalton> lifeless: hey, about the klingon change.. you like maintaining libx11 from now on?-)
<mvo> lifeless: yeah
<lifeless> tjaalton: actually I want to patch it to not need these noddy patches
<lifeless> there is no excuse for it.
<lifeless> but, I haven't had time yet.
<lifeless> tjaalton: ^
<tjaalton> lifeless: another patch for libx11?
<tjaalton> lifeless: I was just concerned about patches that will (likely) never be accepted upstream.
<tjaalton> ..
<ojwb> cjwatson: thanks
<slangasek> tjaalton: btw, one possible reason for a preauth failure is that kinit is racing the network :)
<lifeless> tjaalton: well, things that aren't ISO codes I could understand ;)
<slangasek> (gssd -> portmap only waits for localhost)
<tjaalton> slangasek: yeah it's probably doable, but didn't get to it yet :)
<tjaalton> lifeless: if klingon is supported by libc, then yeah :)
<tjaalton> lifeless: but la isn't, and we talked about that one before :)
<lifeless> tjaalton: anyhow, many of the UTF8 locales are copy n paste - much better to just recognise them all
<lifeless> tjaalton: it is supported by libc
<tjaalton> lifeless: ok, care to file a bug upstream about it?
<lifeless> tjaalton: mmm, not really, if they didn't take latin they won't take klingon :)
<tjaalton> lifeless: but the reasoning against latin was that libc didn't have it, right?
<lifeless> tjaalton: or do you mean about getting rid of all the duplicate data and understanding that UTF-8 is UTF-8 ?
<lifeless> tjaalton: I don't remember.
<lifeless> locale -a
<lifeless> la_AU.utf8
<lifeless> POSIX
<lifeless> tlh_GB.utf8
<lifeless> brb testing X again
<tjaalton> I don't know anymore.. :)
<persia> Why tlh_GB.utf8 rather than tlh_AU.utf8 ?
<lifeless> pitti: its for Keybuk
<lifeless> bah
<lifeless> persia: ^
<pitti> ?
<pitti> ah
<pitti> it should be tlk_KR
<pitti> tlh_KR, even
<persia> That seems even more appropriate.
<StevenK> But I doubt it recognizes _KR
<ari-tczew> pitti: ping for my merge :)
<Keybuk> ITYM tlk_Qo
<Keybuk> (the Klingon homeworld is called Qo'noS)
<StevenK> tlk_Qo sounds good
<cjwatson> pitti: do you know why jockey has started popping up on live CD boot?
<cjwatson> to say nothing except "No proprietary drivers are in use on this system"
<pitti> uh, that sounds wrong
<pitti> I don't know off-hand, I'm afraid
<pitti> but I think I get it on the mini (where it advertises broadcom)
<ogra> oh, its not an armel prob ?
<ogra> good to know
<pitti> cjwatson: do you have a machine which reproduces this?
<pitti> cjwatson: can I come over to take a look?
<cjwatson> pitti: kvm.  certainly, I'm in the foundations room
<pitti> oh, in kvm?
<pitti> that'd be sweet
<pitti> waaah
<pitti> cjwatson: I get it, too
<pitti> cjwatson: it's not just the indicator, it's literally popping up the window
<pitti> cjwatson: I have a suspicion indeed
<pitti> cjwatson: recent app-indicator broke the D-Bus API by changing the bus name
<pitti> I suspect it's stumbling over that
<pitti> cjwatson: now if only I could actually build jockey.. (it's FTBFSing due to python-kde4 being uninstallable)
<pitti> cjwatson: I'll get that fixed, thanks for pointing out
<Caesar> cjwatson: you around?
<RAOF> How long does it generally take for Ubuntu uploads to get merged into the package branches?
<fale> hi
<pecisk> hi people, it is true that netbook edition will have Google Docs instead of OO.o?
<pbn> morning
<pecisk> morning ;)
<pbn> It's perhaps not the right channel to ask that kind of think pecisk :) better ask on #ubuntu or on your local language ubuntu channel...
<pbn> :s/think/thing/
<pecisk> pbn, well, it is about Lucid, and it is about blueprint for Ubuntu Netbook edition
<pecisk> so I think it is appropriate to ask it here
<pbn> ah sorry pecisk , that I didn't know :)
<Chipzz> pecisk: I don't think it is
<Chipzz> you can check the status of a blueprint
<pecisk> Chipzz, I already confirmed that it is just a blueprint with better intentions than Slashdot submitter wrote
<pecisk> it is for ARM only
<pecisk> as OO.o for ARM is slow
<Chipzz> and from that status you could derive the answer to your question
<pecisk> Slashdot is going down to the toilet
<Chipzz> you just have to take slashdot with the appropriate grains of salt
<pecisk> Chipzz, I do, but lot of people don't - and thus false rumors are spread
<elpargo> hello, I was wondering if there is an automatic way of adding lines to /etc/apt/sources.list
<elpargo> I assume I could do some shell-foo to append to it but perhaps there is a better way.
<Chipzz> http://wp.colliertech.org/cj/?p=728
<elpargo> nice! thanks Chipzz
<elpargo> ah :( it's not smart enough to not add it if it's already there.
<elpargo> oh well, good enough. Thanks agan.
<elpargo> again*
<qense> Ridell: Should Kubuntu bugs also be accepted for hundredpapercuts?
<qense> ahem, Riddell ^^
<nigel_nb> qense, doesn't KDE have its own papercuts (there was a UDW session on it)
<qense> nigel_nb: I wouldn't know, actually.
<jml> RAOF, sorry, I don't know.
<qense> Riddell: nevermind, nigel_nb gave me the answer
<jml> hello
<jml> I've managed to screw up my system in a fascinating way
<jml> every time I try to do something like apt-get upgrade, I get this:
<jml> (Reading database ... 30%dpkg: unrecoverable fatal error, aborting:
<jml>  files list file for package `com.d0lph1nk1ng.h.cowtasks' contains empty filename
<nigel_nb> jml, lol, I did something to that extent some time back
<nigel_nb> I had to reinstall OS
<BSD-CLI> Do control files for package development have an extension?
<geser> interesting package name
<nigel_nb> BSD-CLI, you mean debian/control ?
<nigel_nb> geser, hehe
<nigel_nb> cowtasks, wonder who gave that name
<BSD-CLI> nigel_nb: Yes
<nigel_nb> BSD-CLI, no extension
<BSD-CLI> kk
<BSD-CLI> Also, is it bad form to install a shortcut on the desktop?
<BSD-CLI> (ln -s)
<geser> jml: is this package name real? do you have files in /var/lib/dpkg/info matching that package name?
<geser> BSD-CLI: whose desktop?
<nigel_nb> BSD-CLI, I believe so.  I think its official rule, but I dont remember
<BSD-CLI> Could you find out if it's an official rule please?
<nigel_nb> you can look through debian maintainer guide
<jml> geser, it's an palm webos package that I accidentally ran dpkg --unpack on
<Laney> you can't write to users' home directories
<jml> geser, I do have a file in /var/lib/dpkg/info matching that
<BSD-CLI> There's nothing akin to NSIS/MSI/InnoSetup's installer for Debian, is there?
<BSD-CLI> (Next, Next, Checkbox to install shortcut etc.)
<geser> jml: do you have also a file /var/lib/dpkg/info/com.d0lph1nk1ng.h.cowtasks.list? and does it perhaps contain empty lines?
<nigel_nb> BSD-CLI, I doubt if Linux as such as anything like that
<jml> geser, I have such a file, but it contains no empty lines that I can see.
<BSD-CLI> nigel_nb: Damn!
<nigel_nb> linux desktops tend to have a clean desktop
<BSD-CLI> I like shortcuts
<BSD-CLI> :P
<nigel_nb> put it in your menu.  when developing software you have to think about end-users and not everyone likes desktop shortcuts
<BSD-CLI> Wait, so are you telling me that not everyone thinks exactly as I do?
<BSD-CLI> :P
<nigel_nb> yeah
<geser> jml: can you pastebin that .list file?
<jml> geser, http://pastebin.ubuntu.com/370204/
<geser> jml: like I assumed after consulting the source: change line 1 from "/" to "/.". That should make dpkg happy again
<jml> geser, thanks. I'll try that.
<BSD-CLI> nigel_nb: Awwww!
<BSD-CLI> hehe
<nigel_nb> geser, its that simple?
<Chipzz> BSD-CLI: no, there are no such installers, and I'm quite sure that they are not *wanted* either
<Chipzz> why would you want such a thing when apt-get install foo saves you the trouble of finding software, downloading it and clicking through such an installer
<nigel_nb> +1
<Chipzz> and as Laney pointed out, you are not allowed to write to users homedirs
<Chipzz> for one because it is really bad form
<Chipzz> but also because there's the question which users' homedir you would write to
<Chipzz> and what would happen if you did that (write to all users' homedirs) and afterwards a new user were created
<Chipzz> that being said, those questions are not appropriate here; pls continue this discussion on #ubuntu-motu
<Chipzz> and please DO read the topic before asking questions
 * BSD-CLI just made his first unique .deb installer (created the 'hello-world' program once when following the official guide, now I've just got a custom control file).
<jml> geser, that worked. cheers.
<BSD-CLI> Does anyone have a control file I can look at, I think I need more content in mine, do we specify the files within the control file?
<mr_pouit> meh, xulrunner-1.9 can't cleanly be removed by update-manager when upgrading from hardy to lucid, and apport refuses to report the bug because xulrunner-1.9 isn't in lucidâ¦
<Adri2000> hi
<Adri2000> who is at fosdem right now?
<Chipzz> I am :P
<jdong> holy crap radeonhd works well these days!
<jdong> just after I say that radeonhd gpu-locks while  the installer is going :)
<jdong> *turns off Compiz*
<TheMuso> c
<TheMuso> o/c
<cjohnston> mbudde: when you have a few minutes I would like to run something by you
<mbudde> cjohnston: sure!
<cjohnston> It's in reference to Lernid.. Do you want to do it in here or in PM
<mbudde> we can do it here
<cjohnston> Okie..
<cjohnston> The fix you attached to bug #511535
<ubottu> Launchpad bug 511535 in lernid "Limit the links Lernid opens automatically" [High,Fix committed] https://launchpad.net/bugs/511535
<cjohnston> I posted a comment that pretty much says what I wanted to say about that...
<cjohnston> My other thing was.. And I wanterd to talk to you before putting in a feature request...
<cjohnston> If the -classroom channel is not +m, (which it isnt for many classes) allow users the ability to speak in -classroom... If it is +m, that ability may as well be removed, since saying something wont be said anyway
<Tm_T> cjohnston: hmm, irc channelsare (mostly) managed in -ops
<cjohnston> Tm_T: I don't know what relevance that has to the discussion?
<mbudde> I see your point but do you have any suggestions? I'm not quite sure I like the idea about parsing the topic...
<cjohnston> mbudde: my opinion is +v/o can paste links/slides
<mbudde> But how's that different from how it is now?
<cjohnston> anyone who is an ubuntu member has the ability to voice/op themselves.. and if they arent and teaching a class.. myself or another member of the classroom managemnt can do it.. or even another ubuntu member
<cjohnston> right now the room has to be +m if I understand your commit right..
<cjohnston> alot of instructors dont make the room +m
<cjohnston> so if they just +v themselves, the room remains -m, but they can paste links and run slides
<cjohnston> I agree with not parsing the topic
<mbudde> Oh ok.. I thought everyone was +v when the channel wasn't moderated
<cjohnston> Nope..
<cjohnston> Right now when the classroom is not in use, its -m.. When someone puts on a class, they have the ability to make the room +m if they so desire..
<cjohnston> if not.. then they cant use the features of lernid, as it stands right now with your commit
<mbudde> The problem is that can't seem to find a way to get the voice status of channel member with telepathy.. I'm not even sure it is possible :/
<cjohnston> eww
<cjohnston> ok..
<cjohnston> well.. that would provide an issue then
<cjohnston> if it is possile... would that be a reasonable fix for you?
<mbudde> Yeah, that would be the optimal solution.
<cjohnston> :-)
<cjohnston> What about my other request... about typing in -classroom when the channel is -m? is that something dooable that I could file a feature request for?
<mbudde> Hmm.. what would the use case for that be? Isn't that what the classroom are for?
<cjohnston> Unless it has changed.. if you are running lernid you cant talk in #ubuntu-classroom
<cjohnston> for the instructors who leave ubuntu-classroom -m, they want questions in -classroom and not in -classroom-chat
<cjohnston> so users running lernid need the ability to type into -classroom when the room is -m
<cjohnston> And then prolly a faq somewhere to say if you cant type in -classroom, its because -classroom is +m, please use -classroom-chat
<mbudde> Yeah, that could be somewhat confusing.. What about a [QUESTIONS-IN-CLASSROOM] command instead?
<cjohnston> what would that do?
<cjohnston> I'm confused
<mbudde> That would make it possible to send messages to the classroom
<cjohnston> that would be fine too
<cjohnston> but then, for instructors who arent familiar with lernid, they would have to run that
<cjohnston> i think +/-m would be better
<cjohnston> imo
<mbudde> You have a point..
<cjohnston> making an instructor run a command to allow lernid users to speak seems like a bad idea.. but allow the default that a user can speak, and only cant speek if the channel is +m would be much better
<cjohnston> I am going to print this screen and show my wife
<cjohnston> she never thinks i have a point
<cjohnston> lol
<mbudde> :P
<mbudde> Are you going to file a bug?
<cjohnston> Yup..
<mbudde> Great
<cjohnston> I just wanted to talk it out with you first so we were on the same page
<cjohnston> mbudde: bug 518222  --  I hope that is clear enough
<ubottu> Launchpad bug 518222 in lernid "Allow a user to type in #ubuntu-classroom when the room is unmoderated" [Undecided,New] https://launchpad.net/bugs/518222
<mbudde> cjohnston: Yep, that's fine :)
<cjohnston> Great.. Thanks!
<cjohnston> Let me know if I can be of help..
<cjohnston> And I'll keep thinking about some sort of fix for the other issue
<cjohnston> Actually.
<cjohnston> Could it parse from the ics or the config file somehow?
<cjohnston> hmm
<cjohnston> That wouldn't allow improptu classes that use lernid features.. but it may be a fix
<mbudde> I don't think getting that info from the ical is a good idea..
<cjohnston> What about the config file...? again still doesnt allow for improptu classes..
<cjohnston> I had another request too.. I spoke with sopmoene about it.. dont remember who
<cjohnston> In this situation: I'm an instructor.. I'm teaching a class on bug triaging for example.. I may post 5 links in quick succession for reference.. I don't want those 5 links opening up..
<cjohnston> I just want the user to have them
<cjohnston> maybe require a link be [http://mbudde.com] to load?
<mbudde> if you post the links in the same line only the first one will be loaded and the rest will just be added to the combo box
<cjohnston> https://wiki.ubuntu.com/UserDays/01232010/Introduction  <-- if you would.. scroll down a little more than half way to 12:26
<cjohnston> Something to fix that
<cjohnston> cause listing them all on one line would not look good
<cjohnston> but listing them that way made them all open
<cjohnston> which wasnt the intent
<cjohnston> or even [http://www.thislinkdoesntopen.com] but http://thislinkopens.com
<cjohnston> a way to "turn a link on or off"
<mbudde> Yeah, ok.. but then I'd rather make it opt-out instead of opt-in, so [http://foo.com] would make Lernid ignore the url
<cjohnston> that would be fine by me
<cjohnston> Any other thoughts on that subject
<cjohnston> ?
<mbudde> Should they be completely ignored or just not loaded in the browser but added to the combo box?
<cjohnston> combo box?
<mbudde> in the browser
<cjohnston> you mean the drop down?
<cjohnston> with the addresses?
<mbudde> yeah, that's it
<cjohnston> I dont have an opinion
<cjohnston> hard to believe, i know
<cjohnston> but.. its true
<cjohnston> lol
<cjohnston> hmm.. did you fix the issue where the channels werent visible at startup?
<cjohnston> or is that not fixed yet?
<mbudde> I'd guess adding it to the list would make most sense
<cjohnston> thats fine
<mbudde> cjohnston: I disabled saving of the vertical panel position.. so the symptom is gone but I'd like to fix the underlying issue, if you know what I mean :)
<cjohnston> i just had it
<mbudde> hmm.. are you running from source?
<cjohnston> i dont know if im on the most up to date code or not.. but its the most recient in the ppa im using
<cjohnston> help reports 0.5
<cjohnston> mbudde: ill file a wishlist about turning off links too
<cjohnston> mbamford:  bug 518229
<ubottu> Launchpad bug 518229 in lernid "Add the ability for an instructor to "opt-out" links from being loaded by the Lernid browser" [Undecided,New] https://launchpad.net/bugs/518229
<cjohnston> sorry mbamford, mbudde
<mbudde> cjohnston: did you answer my previous question? I got disconnected so I might have missed it...
<cjohnston> i dont know if im on the most up to date code or not.. but its the most recient in the ppa im using
<cjohnston> help reports 0.5
<mbudde> oh, perhaps my message didn't go through
<mbudde> Are you using the release or daily ppa?
<cjohnston> i guess its releases
<cjohnston> ill go get daily
#ubuntu-devel 2010-02-07
<obx> this is the 3rd time an update to the Linux kernel messed up either Xorg or my video card driver. I filed a bug report for both of the first bugs and it took several months to fix it, although many people reported the same bug. and now, after the recent update, I had to reinstall the graphic card drivers and xorg is eating up CPU again. serious question: is it so hard to get it right before officially releasing an update and not beta test it on
<obx>  the user base?
<ravenxbishop1> hello
<ravenxbishop1> any chance anyone in here can point me in a direction for help in porting drivers?
<ravenxbishop1> maybe to someone who is amaising at it
<ravenxbishop1> or maybe just a great developer
<ravenxbishop1> i promise there IS no port of this driver, im not just over looking something thats allready done
<jmarsden> ravenxbishop1: The Kernel Driver Project.  See http://www.linuxdriverproject.org/foswiki/bin/view
<ravenxbishop1> thanks i'll check it out
<Keybuk> I'm not sure you can really "port" a driver though
<ravenxbishop1> oh that wont work tho
<ravenxbishop1> because theres no specs
<ravenxbishop1> and no way to get them
<Keybuk> if you don't have the specs, how do you know how to write a driver?
<ravenxbishop1> well, its called reverse engineering
<Keybuk> so do that
<Keybuk> then write the spec as a result
<Keybuk> then write the driver
<ravenxbishop1> nod i need someone who is good at it
<ravenxbishop1> i didnt say I WAS
<ion> What does *he* need *you* for? :-P
<ravenxbishop1> depends, he doesnt actually, but it could be something we both want to do for any number of reasons
<ravenxbishop1> why so much animosity?
<Keybuk> there's no animosity
<ravenxbishop1> well ion sounded... uhm
<ravenxbishop1> mean
<ravenxbishop1> i just want some help, so i can use linux
<Keybuk> sure, but writing a driver is *hard*
<ravenxbishop1> and i dont really know where to start
<ravenxbishop1> sure it is
<Keybuk> the people who can do it are already hard at work writing drivers
<Keybuk> and it's still hard even if you've got the full specs
<ravenxbishop1> oh, so im out of luck?
<ravenxbishop1> and i cant get any help
<ravenxbishop1> and i should just give up?
<Keybuk> what's the device?
<ion> Itâs easy to interpret tones incorrectly on IRC. I wasnât being hostile.
<ravenxbishop1> its a sound card
<ravenxbishop1> a professional sound card
<Keybuk> and there's no extant driver for the sound card?
<Keybuk> your best bet is to find someone in the ALSA project
<Keybuk> bribing them by sending them the sound card and letting them keep it often works
<ravenxbishop1> i see no indication that there is any way to get it working in linux
<Keybuk> especially if it's a good one
<ravenxbishop1> well then i wouldnt have it :)
<Keybuk> if you gave us the model name/number/etc. I could actually look it up for you
<ravenxbishop1> AArdvark q10
<Keybuk> ravenxbishop1: they can't write drivers blind ;)
<ravenxbishop1> of course not
<ravenxbishop1> i didnt think they could
<Keybuk> that's what ion meant
<Keybuk> unless there's something in it for them (e.g. getting a neat sound card) a developer is unlikely to be interested
<Keybuk> since they're probably doing linux in their spare time
<ravenxbishop1> but that cant be negotiated with you
<ravenxbishop1> becuase you cant do the job
<ravenxbishop1> i didnt ask anyone here, to do it
<ravenxbishop1> i asked to be directed to someone who might be able to
<ravenxbishop1> and instead
<Keybuk> sure, and we've told you the two groups ;)
<Keybuk> Linux Driver Project and the ALSA Project
<ravenxbishop1> i saw one
<ravenxbishop1> ah
<ravenxbishop1> alsa
<ravenxbishop1> so they work without specs?
<Keybuk> no
<ravenxbishop1> because the first says "dont bother asking"
<Keybuk> they *might* work without specs and with the card
<Keybuk> (ALSA might)
<Keybuk> but you're basically asking for a year or two's work
<ravenxbishop1> well, maybe
<ravenxbishop1> typically speaking, if i can get in touch with the right person
<ravenxbishop1> i can make things happen
<Keybuk> another good bet is to speak to the manufacturer and try and persuade them that it's in their interests to assist in writing a linux driver
<Keybuk> e.g. by giving the LDP the specs
<ravenxbishop1> thats impos
<Keybuk> why?
<ravenxbishop1> because it isnt something that can be done
<Keybuk> we've got specs out of *NVIDIA*, anything is possible
<Keybuk> of course it is
<ravenxbishop1> well, no, its not
<ravenxbishop1> i can get specs from nvidia
<ravenxbishop1> but i cant get them from aardvark
<Keybuk> if everyone returned their Q10 cards, because they didn't have linux drivers, and nobody bought them, then they'd pony up the specs pretty quick :p
<ravenxbishop1> well
<ion> If you can get in touch with the right person with Aardvark, you can make things happen. :-P
<ravenxbishop1> there would be no where to return them to
<Keybuk> so the company who makes the device has gone bust?
<jmarsden> I think the Q10 is already a discontinued product... ?
<ravenxbishop1> sort of went bust
<Keybuk> being realistic, I suspect your chances of getting a driver are basically zero
<Keybuk> especially if it's not a production device anymore
<ravenxbishop1> the company is closed.
<ravenxbishop1> theres NO one to contact
<ravenxbishop1> and no place to contact them
<ravenxbishop1> they didnt fail they were forced out by competition
<ravenxbishop1> through an unrelated legal issue with a board member
<Keybuk> the competition probably had Linux drivers ;)
<ravenxbishop1> no, you dont understand
<ravenxbishop1> its alot of irrelivant things to explain
<ravenxbishop1> before you would
<ravenxbishop1> but something unrelated to the product, closed the company
<jmarsden> Bottom line: They aren't likely to sell many more Q10 cards... so the work to create a Linux driver is out of all proportion to the benefit.  Buy a new card.
<ravenxbishop1> there IS no new card
<ravenxbishop1> it does things other things CANT do
<jmarsden> From a different company.
<ravenxbishop1> if i spent $10,000 i could get something similer, using more space that still wasnt as good
<Keybuk> would you pay someone $10,000 to write a driver for your card?
<ravenxbishop1> hrm.
<ravenxbishop1> hard to say
<Keybuk> though, honestly, I suspect the rate would be more like $100,000
<jmarsden> Old ads for it do not seem to proclaim that it does things only $10K cards can do... makes me wonder what these things are and where they are documented...
<ravenxbishop1> it was a $1k card
<ravenxbishop1> it contains a word clock thats ALSO worth $1k
<ravenxbishop1> but it is a clearer card than 10k cards
<ravenxbishop1> first try to find a 10 in 10 out card with 8 preamps in BOTH 1/4 inch and xlr.
<ravenxbishop1> once you do.
<ravenxbishop1> find one that has midi too
<ravenxbishop1> and a word clock generator
<ravenxbishop1> not just having word clock
<ravenxbishop1> but having a generator for it
<ravenxbishop1> you still wont have as GOOD of a word clock generator because there ISNT a better one
<ravenxbishop1> its EXTREMELY low latency
<ravenxbishop1> i get 1ms
<Keybuk> sounds like it's missing a key feature though - a driver
<ravenxbishop1> it has drivers.
<ravenxbishop1> just not one for linux
<ravenxbishop1> has osx and windows
<jmarsden> Does it have one for FreeBSD?  or OpenSolaris?
<ravenxbishop1> shake, osx and windows
<ravenxbishop1> and only 32 bit windows
<ion> Other professional audio interface manufacturers just donât bother to use good enough components?
<ravenxbishop1> correct
<ravenxbishop1> the guy that invented it, is a nasa guy, who is just better than everyone else
<ravenxbishop1> igor levin
<ravenxbishop1> and so far i'm yet to get any contact with him
<ravenxbishop1> tho i've had ... really important people try
<ravenxbishop1> people just dont FIND him
<ravenxbishop1> for instance... we've called "antalope audio" quite a bit, no one ever answers the phone the website stays up, but i cant imagine they do much business when they never pick up
<ravenxbishop1> if i had one of the cards sooner i probably would have GOTTEN the source when they closed down
<ravenxbishop1> i have a tendancy to do things like that
<ion> I guess the fact i demand less from my gear makes my life easier. :-)
<ravenxbishop1> it seems like walking me through a clean room reverse engineering process wouldnt take too much time or resources. but i'd have to know the right linux developer. it doesnt seem like THAT person hangs out in here
<ravenxbishop1> thats probably true
<ravenxbishop1> maudio has linux drivers but their cards are shit
<Keybuk> ravenxbishop1: usually the approach is debug the windows driver
<Keybuk> send commands, intercept the pci stream, then figure out what it's actually doing
<Keybuk> replicating it in your own driver
<ravenxbishop1> nod keybuk... but do you have experience?
<Keybuk> I've done it before, not for a sound card though
<Keybuk> (and I'm not interested, btw :p)
<ravenxbishop1> because you arent really the guy for the job.
<ravenxbishop1> but someone is
<ravenxbishop1> my guess from years of practical experiance is... that you probably havent REALLY done it, that you've done parts of the actual process and feel you know the theory. i could be wrong. but someone around has done it a few times and would probably help
<ravenxbishop1> infact the guys that do it alot, do it for fun
<ravenxbishop1> usually the people asking for money or saying how hard it is... arent really the guys that know how
<ravenxbishop1> like the friend of a friend of mine that just cracked the ps3.
<ravenxbishop1> he doesnt charge :)
<ravenxbishop1> he's the one for the job, when you start bringing up anything to do with it, you cant even shut him up
<ravenxbishop1> not that i expect anything for free.
<m4t> are there any official ubuntu sparc tftp images?
<Liquid-Silence> hi all
<Liquid-Silence> I am new to ubuntu but I want to contribute as a developer
<hyperair> Liquid-Silence: hello. did you need something?
<Liquid-Silence> nope
<Liquid-Silence> just looking @ contributing to ubuntu as a developer
<tomeu> Liquid-Silence: have you seen this already? http://www.ubuntu.com/community/participate
<Liquid-Silence> yup
<Liquid-Silence> going through that and some other things atm
<tomeu> ah, cool
<Liquid-Silence> got launchpad etc..
<Liquid-Silence> but more interested in what development tools I require etc...
<tomeu> Liquid-Silence: that will depend on the package you want to hack on
<Liquid-Silence> Well in general I am not going to focus on one package
<Liquid-Silence> I want to contribute in many ways
<jussi01> Liquid-Silence: Id say join #ubuntu-motu they have some help for people to get started
<tomeu> Liquid-Silence: I would just start with one and learn from there
<jussi01> !motu
<ubottu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<Liquid-Silence> I am in that channel
<Liquid-Silence> :)
<jussi01> ahh, so you are. best to start on the basics, I can assure you that there is more than enough work to go around.
<Liquid-Silence> jussi01: yip
<qense> chrisccoulson: The version of Transmission I pushed last night does work. I'm now working on creating a patch for the latest version.
<chrisccoulson> qense - thanks. i will try and set aside some time later to look at it
<qense> chrisccoulson: thank you
<chrisccoulson> i don't know why people keep changing the status and assignee on bug 452208
<ubottu> Launchpad bug 452208 in devicekit-disks "devkit-disks-daemon crashed with SIGSEGV in dbus_g_method_return_error()" [High,Fix released] https://launchpad.net/bugs/452208
<chrisccoulson> it's getting ridiculous now
<chrisccoulson> when you look through the history of it, it's just people having to constantly revert unnecessary changes
<chrisccoulson> qense - which branch did you base your work on?
<qense> chrisccoulson: lp:ubuntu/lucid/transmission
<qense> and that still uses 1.80~b1
<chrisccoulson> ah, yes
<qense> whereas the repos have got 1.83
<chrisccoulson> the packaging branch we use is lp:~ubuntu-desktop/transmission/ubuntu
<chrisccoulson> that one is always up-to-date
<qense> ok
<chrisccoulson> it should be listed in debian/control
<qense> I'll merge with that branch
<chrisccoulson> (if it's not, then i need to add that)
<qense> I'll have a look at it
<chrisccoulson> cool, thanks :)
<qense> chrisccoulson: I can just merge that autoreconf patch into this branch, it just contains the directory. That's correct?
<qense> btw, yes, it contains the Vcs-bzr entry
<chrisccoulson> qense - thats right. our packaging branches only contain the debian/ folder
<chrisccoulson> but once you have the branch, you can type "bzr bd-do", and get the full source directory
<qense> ah
<qense> that's a nice feature I had never heard of
<chrisccoulson> it's actually a bit of a pain, but it does save on bandwidth ;)
<geser> qense: the lp:ubuntu/transmission packaging branch might stay outdating for some time as the package importer failed over the .orig.tar.bz2 from Debian (and this might have stopped imports of Ubuntu uploads too)
<qense> geser: yeah, I saw that. A lot of imports failed recently.
<czajkowski> aloha
<geser> Hi
<czajkowski> at fosdem great turn out, interesting talks, one talk this morning, ubuntu and debian was soo full they stopped allowing folks in
<czajkowski> tweet came in afterwards
<czajkowski> RT @rdicosmo: Debian and Ubuntu .... After the talk in H1309 at Fosdem, I think Debian really needs to push Ubuntu to behave as a proper dowstream!!!!!
<Tm_T> er?
<hyperair> ho?
<geser> I can imagine that, I was at FOSDEM already twice (the last time last year) and the Debian dev room was always full
<hyperair> debian needs to push ubuntu to behave as a proper downstream? what's up with that?
<hyperair> have we not been a proper downstream?
<geser> I guess the opinion depends on who you ask
<hyperair> or are those rogue debian developers getting ahead of themselves claiming that ubuntu never contributes to debian again?
<czajkowski> hyperair: it was one comment that just caught my eye on the #fosdem search on twitter
<hyperair> czajkowski: i see.
 * hyperair sighs. i thought that whole war was behind us
<Tm_T> you should just drag the original poster in middle of Ubuntu crew there (;
<hyperair> i agree
<czajkowski> Tm_T: there are more debian here
<czajkowski> 18 ubuntu folks went for dinner last night
<Tm_T> czajkowski: doesn't matter (:
<czajkowski> http://fosdem.org/2010/schedule/events/dist_debian_ubuntu  was the speaker
<geser> Debian is to inhomogeneous to come just to *one* opinion on anything
<Tm_T> czajkowski: no material available? ):
<czajkowski> Tm_T: pardon?
<hyperair> i'm curious to see the actual speech
<Tm_T> czajkowski: nothing, I cannot build reasonable sentences currently (:
<Tm_T> hyperair: me too
<czajkowski> it was wedged, looked interesting but it was just too warm to stay
 * hyperair wants to see a video or hear a recording =\
<czajkowski> aye before commenting
<czajkowski> i was just curious tbh, i'd have prefered to see a more larger presence from ubuntu tbh.
<geser> I guess you talk to lucas also when he is here again
<czajkowski> his first slide was why he's qualified to give this talk, and said jokely it was being recorede so didnt want to offent anyone or something like that
<geser> lucas did the recent archive rebuilds for us (and is also a MOTU)
<czajkowski> i dont think there was anyting wrong wiht his talk, the perception on stream just got me wondering
<kitallis> does Ubuntu plan to apply as an Org for GSoC'10?
<hyperair> what would you work on under gsoc for ubuntu?
<kitallis> there's the whole Atayana thing, and notify-osd needs a lot of revamping.
<kitallis> Ayatana*
<hyperair> notify-osd eh..
<hyperair> i'd think that'd be under notify-osd instead of ubuntu.
<kitallis> notify-osd won't make much of an organisation...
<czajkowski> hyperair: Debian's conclusion about Ubuntu at FOSDEM - http://short.ie/fh36jd
 * hyperair clicks
<hyperair> czajkowski: that sounds fine to me.
 * Daviey expected a rick roll
<hyperair> czajkowski: but how did that come to "ubuntu needs to be a good downstream"?
<hyperair> Daviey: that was the first thing that crossed my mind as well =p
<czajkowski> hyperair: that was whats someone took from the talk.. i really need the recordings
<hyperair> =\
<czajkowski> Daviey: i'm not going near rickroll that song does my noggin in
<Daviey> :)
<czajkowski> hyperair: talk should be up next week once proceessed
<hyperair> czajkowski: cool
<alkisg> For LTSP development, I want to disallow upstart daemons from running while maintaining the chroot. Does upstart support some kind of "flag" to disallow daemon starting, like policy-rc.d does for invoke-rc.d ?
<alkisg> Hmmm ok I found this: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224
<ubottu> Ubuntu bug 430224 in upstart "misc: packages cannot be upgraded in a chroot" [Medium,Confirmed]
<alkisg> I'll try to make a wrapper for initctl, that either runs initctl or runs true, depending on if we're on a live system or in the chroot...
<Liquid-Silence> arg
<Liquid-Silence> need to go sit and watch movies with the wife
<mdeslaur> lamont: is there a specific reason why we don't ship /usr/lib/libuuid.la in uuid-dev anymore?
<ScottK> mdeslaur: There's a general push in Debian not to ship .la files.  I think it should be the other way around, don't ship it unless there's a reason to.
<mdeslaur> ScottK: do you know of any webpages with info on transitioning packages to use the .pc file?
<ScottK> mdeslaur: No.  Sorry.  I haven't had to deal with it yet, I've just read about the goal to remove them on debian-devel.
<mdeslaur> ScottK: ok, thanks
<lamont> mdeslaur: because .la files are evil and should die
<mdeslaur> lamont: so, if I get a FTBFS on another package because of it, what's the proper thing to do?
<mdeslaur> bbl
<akgraner> slangasek, are you around I have a quick question for ya?
<lamont> fix the other package to not need the .la file - a large part of the push to get rid of the .la files was that they introduced amusing(tm) build-deps that were 4 and 5 deep and totally undeclared
<lamont> gnome in hoary was _such_ fun
<slangasek> akgraner: hi
<akgraner> hey
 * ScottK thought maybe slangasek was still on his trip home from the sprint.
<ScottK> ;-)
<slangasek> it's a tiring journey
<ogra> heh
<nick19691> hello, how does ubuntu handle virtualbox? Any specific kernel settings or videodrivers? I see ubuntu doesn't use guest additions etc.
<persia> nick19691: If nobody gets back to you in a while, you might try #ubuntu-virt
<nick19691> thanks persia
<gord> nick19691, there are two versions of virtualbox. the open source edition thats included in ubuntu and the closed source edition that you can download from the virtualbox website, that has guest additions and such, but is closed source
<micahg> gord: guest additions is in ubuntu
<gord> micahg, i think there is a few that are kept out or something, i'm not 100% on the details
<micahg> gord: USB support
<nigel_nb> gord: and shared folder support
<Liquid-Silence> uhm
<Liquid-Silence> the one you can install via apt has folder support
<Liquid-Silence> and 3d
<Liquid-Silence> and the guest additions
<Liquid-Silence> I am running it atm
<nick19691> gord: I was mostly talking about ubuntu as a guest as it doesn't freeze as eg debian does
<lamont> ScottK: postfix 2.7.0~rc1-1~1 bits at deb http://ppa.launchpad.net/lamont/ppa/ubuntu lucid main
<lamont> or will be once the publisher runs
<lamont> ScottK: feedback welcome
<ScottK> lamont: THanks.
<ScottK> lamont: Unfortunately I supposed to leave town for a week tomorrow, so tossing experimental Postfix packages on even my test server (which I do use for some actual stuff) is probably not prudent.
<ScottK> I'll have a look when I get back (although it's no doubt going to be OBE by then)
<lamont> it's running on my primary mail server, but then, I'm _in_ town this week
<azeem> 00:36  * bremner learns from an Ubuntu user that he is the maintainer of syncevolution in Ubuntu.
<azeem> and indeed, he's mentioned as "Maintainer" if you input syncevolution in launchpad.net/ubuntu's search box and click the result
#ubuntu-devel 2011-01-31
<RAOF> Hm.  How can I take a bug off the QA sponsoring list?  Bug #644644 has had it's gstreamer task sponsored, but there's still a valid pulseaudio task up, and that doesn't have a sponsoring candidate.
<ubottu> Launchpad bug 644644 in pulseaudio (Ubuntu Natty) "Frequent PA crashes during playback - pa_stream_cork() failed: Connection terminated and pa_stream_writable_size(): Connection failed" [High,Triaged] https://launchpad.net/bugs/644644
<broder> RAOF: just unsubscribe -sponsors
<broder> (if you're not in the group, i can do it, but you should ping persia and ask him to add you)
<RAOF> broder: Ta.
 * persia isn't the *only* admin of -sponsors, but is always happy to add folk
<ari-tczew> +1 ^^
<ari-tczew> IIRC dholbach and kees as well
<RAOF> Piloting will me a more rewarding experience in core-dev :/
<s0ullight> when will support for the newer elan smartpad be added?
<ari-tczew> RAOF: is that wrong?
<lifeless> RAOF: l2english?
<RAOF> lifeless, ari-tczew: Like you can't mentally translate a bistaken 'm' :)
<lifeless> RAOF: haha
<ari-tczew> RAOF: I guess while reading s/me/be
<persia> RAOF, For those you can't sponsor, if they look generally useful, consider helping them get upstream, which may be almost as satisfying if they land.
<RAOF> Yeah, when that's appropriate.
<RAOF> If a core-dev would like to sponsor http://cooperteam.net/Packages/mtdev_1.1.0-0ubuntu1_source.changes I'd appreciate it :)
<lifeless> Hobbsee: don't suppose you're on irc atm ?
<RAOF> And I'm sure the ubuntu-touch team would appreciate it, too :)
<RAOF> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<jdong> have I heard correctly that Keybuk is (already? going to be?) in Mountain View?
<psusi> Mountain View?
<micahg> psusi: MOuntain View is Google HQ
<psusi> ahh
<RAOF> jdong: Yes; already.
<jdong> RAOF: ah cool. I'
<jdong> ll have to look him up for a beer or something :)
<broder> jdong: wait, are you still out here?
<jdong> broder: out here? where's here?
<broder> bay area
<jdong> yeah, moved out here for good (for now) :)
<jdong> accepted a job at evil fruity world ;-)
<broder> sweet. i think i thought you were grad schooling or something
<jdong> you're still in the bay area too?
<broder> we should totally catch up for a beer at some point
<broder> yeah
<jdong> neat!
<jdong> yeah, definitely
<jdong> yeah, I still plan on grad school in the near future. But for now a job is a refreshing change
 * broder knows the feeling
<jussi> cripes, its a jdong!
 * jussi waves
<jdong> hey :)
<jussi> not seen you around for a while - do fruity companies block irc? :D
<jdong> no they don't, actually
<jdong> just my busy nature has inhibited IRC :)
<jussi> Ahh, fair enough.
<jussi> good to see you are still kicking though :)
<jdong> haha thanks :)
<jdong> still adjusting to this silly time zone though
<jdong> getting ready to go to bed at 11:30!
<jussi> lol
<jussi> anyway, its like 9.30 am here, and I should really go do work...
<dholbach> good morning
<pitti> Good morning
<RAOF> Oh, oh!  It's pitti!
<RAOF> Good morning pitti  :)
<pitti> kees: are you sure that the gdm uid patch is still required? the logic which users to filter out should be much better now; but if you have a ported patch for the current gdm, please go ahead and commit it
<pitti> hey RAOF, how are you?
<RAOF> pitti: I'm ok.
<RAOF> I'm discovering some stupidity in thinking that builds == works, though :/
<RAOF> On the plus side, this is in the pre-upload testing, so no-one need know!
<micahg> hi pitti, I wanted to ask about Thunderbird for natty alpha 2, would it be better to have it be updated to 3.1.8 on arm, but w/out Breakpad enabled (submit crashes to Mozilla) (not parity with i386/amd64) or leave it at 3.1.7?  There might be the other option of actually fixing breakpad, but idk if that can happen before alpha 2
<pitti> micahg: my gut feeling is to update without breakpad, but ogra_'s or persia's opinion here is more important
<micahg> pitti: I"ll check with chrisccoulson as well either before I go to sleep or when I wake up (and might find it mysteriously fixed :))
<didrocks> good morning
<JackyAlcine> Morning, didrocks.
<didrocks> hey JackyAlcine
<pitti> bonjour didrocks
<didrocks> Guten Morgen pitti :)
<DktrKranz> mvo: hi! during weekend I spent some time doing gdebi bug triage, and noticed you were working on gio support (lp:~mvo/gdebi/gio). Do you think it's functional enough to be merged, or does it need polishing?
<mvo> DktrKranz: thanks for the triage :) there was/were issues with gio, but I don't remember the details, let me look at the code again (its been a while)
<janimo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: janimo
 * micahg waves to janimo
<mvo> DktrKranz: one problem was that gio will not support remove downloads as root. that should be fine most of the time (as we run as user by default) though
<DktrKranz> ah, yeah
<janimo> micahg, hi
<micahg> janimo: hi, we've got another failure on thunderbird on ARM, I was looking for the ARM xulrunner tree to see if anyone fixed it, but it seems to no longer exist
<janimo> micahg, those fixes are easy, I saw that too, I'll provide a patch today - not debidff though
<janimo> I wonder though why mozilla keep adding asm code :)
<micahg> janimo: awesome, thanks
<micahg> janimo: we enabled a new module (breakpad)
<janimo> ah, makes sense
<mvo> DktrKranz: nice work on trunk btw, many thanks :)
<DktrKranz> mvo: thanks, I plan to commit a couple of things, then upload and sync in natty
<mvo> DktrKranz: sounds good to me,  I play a little bit with the gio stuff in the meantime
<DktrKranz> mvo: cool, thanks!
<mvo> DktrKranz: could you merge the gio branch to trunk and play a bit with it? it should be good now
<ogra_> mvo, any chance that we get a working update-manager soon so we can build non x86 images again ?
<ogra_> (why is it depending on fglrx-modaliases ?)
<janimo> micahg, so mozilla will  not report via apport? How do apport and breakpad get along?
<micahg> janimo: apport should be blacklisted if breakpad is enabled
<janimo> ok
<micahg> janimo: you should still be able to use ubuntu-bug though to report non-crashes
<janimo> micahg, does the mozilla team upstream patches (I am thinking of the arm ones in particular)?
<micahg> janimo: we should be :)
<janimo> micahg, ok. There's no easy way I know of - short of looking at he buglist and upstream resources - what the status of various packages is wrt upstreaming
<micahg> janimo: generally I think we do, occasionally one slips through the cracks
<mvo> ogra_: yes, on my list for today :) its a quirk handler because fglrx used to drop support for older cards so we like to tell users (and transition them)
<ogra_> ah
<ogra_> great, thanks
<cjwatson> broder: thanks for pushing the libpipeline backport :-)
<\sh> guys, who is responsible for upstart in ubuntu right now?
<micahg> \sh: I think jhunt is working on it
<\sh> micahg: thx...I'll get in touch with him...looks like we still have problems with upstart + virtual nic interfaces
<micahg> \sh: bug 678425?
<ubottu> Launchpad bug 678425 in upstart (Ubuntu) "virtual network interfaces sometimes dont start on startup" [Undecided,New] https://launchpad.net/bugs/678425
<\sh> micahg: nope, this looks just like the reporter is not following the exmaple of ifenslave for new upstart behaviour
<\sh> micahg: it's more : bond0 -> slaves eth0 eth1 -> mode 4 / bond1 -> slaves eth2 eth3 -> mode 4 <- those are available, and now you device a bond2 -> slaves bond0 bond1 and bond2 doesn't work
<micahg> \sh: way too late at night for me to follow that :)
<\sh> micahg: hehe...I can imagine that...
<DktrKranz> mvo: sure, I'll have a go this eve
<\sh> micahg: I commented on bug #678425
<ubottu> Launchpad bug 678425 in upstart (Ubuntu) "virtual network interfaces sometimes dont start on startup" [Undecided,New] https://launchpad.net/bugs/678425
<cjwatson> smb,sconklin-gone: we need an urgent upload for bug 709694, IMO, because now lucid-updates has regressed for people with the backports modules installed
<ubottu> Launchpad bug 709694 in linux-backports-modules-2.6.32 (Ubuntu Lucid) "Lucid package linux-backports-modules-wireless-lucid-generic broken" [Critical,Triaged] https://launchpad.net/bugs/709694
<\sh> cjwatson: don't know if you are the right man for initramfs-tools, but the correct fix for bug #415353 is now in initramfs-tools 0.98.8 in unstable...we should take a look at it and eventually push that to natty
<ubottu> Launchpad bug 415353 in linux (Ubuntu Lucid) "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,Incomplete] https://launchpad.net/bugs/415353
<cjwatson> \sh: yes I'm going to do that this week
<cjwatson> maks already asked me about it
<cjwatson> pitti: given that you removed the fglrx-modaliases package, do you have an idea for how to make update-manager not dep-wait on it in natty?
<\sh> cjwatson: cool...thx :)
<pitti> cjwatson: oh, I'll look into it and discuss with mvo
<pitti> sounds like an obsolete workaround anyway
<ogra_> cjwatson, see above, mvo said he'd work on it today
<cjwatson>   * DistUpgrade/DistUpgradeQuirks.py:
<cjwatson>     - add detection for cards no longer supported via fglrx
<cjwatson>       and ensure transition to "ati" (LP: #284408)
<cjwatson> ogra_: ah, thanks
<cjwatson> I missed that
<pitti> mvo: do we still need that? would it help if I send you a snippet of code which determines the vendor/product IDs in the new "package header" world?
 * ogra_ grumbles at freenode
<Tm_T> ogra_: that's not freenode's fault (:
<ogra_> Tm_T, that my nick gets cked for 2h if i nistype my PW ?
<ogra_> *mis
<Tm_T> ogra_: I believe you have turned on nick-guard
<ogra_> *locked ...
<ogra_> i havent turned on anything
<ogra_> i'm using IRc like i do since 8 years
<Tm_T> hmm, interesting, it shouldn't force nick-change without the nick protection
<ogra_> if i mistype my pw and am not fast enough to retype in time i get a Guest account
<ogra_> after that my nick is locked for about 2h
<Tm_T> haven't heard of locks before
<ogra_> * ogra :Nick/channel is temporarily unavailable
<ogra_> thats what nickserv replies
<Tm_T> ogra_: you can still identify
<ogra_> i cant change my nick, so no
<Tm_T> ogra_: /msg nickserv identify <account> <password>
<ogra_> yes, that works, but i cant change my nick
<Tm_T> as identified?
<ogra_> yes
<ogra_> same message as above
<Tm_T> what happens if you try to ghost that nick?
<ogra_> -NickServ- ogra is not online.
<ogra_> :P
<Tm_T> interesting
<Tm_T> -NickServ(NickServ@services.)- ogra has enabled nick protection
<ogra_> well, i'll live with the tail for 2h
<Tm_T> ogra_: you might like to group that tailed nick to your account too (:
<ogra_> to have that locked as well ?
<ogra_> no, thanks :)
<Tm_T> ogra_: well, now someone else can register it
<ogra_> nobody has in the last years ... and i still own the toplevel
<Tm_T> true
 * cjwatson looks sideways at http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
<ogra_> i like to have a working fallback
<cjwatson> we're producing an alpha this week, right? :-(
<ogra_> cjwatson, armel looks worse than it is for images
<ogra_> we only miss u-m currently afaik
<cjwatson> ogra_: I was actually mostly looking at x86
<ogra_> ah
<geser> cjwatson: a binary promotion of "libsmokebase3" should resolve the "libsmoke*" ones (kdebindings)
<cjwatson> geser: thanks, will poke at component-mismatches
<cjwatson> there's a qscintilla2 rebuild needed too
<JackyAlcine> Is NAS (Network Audio System) is shipped with Ubuntu?
<JackyAlcine> Qt seems to rely on it.
<cjwatson> Riddell: I've uploaded qscintilla2 to fix its sip-api-* dependency - hopefully it still works
<jibel> ev: Hi, can you look at bug 710582, looks like a webkit bug rather than ubiquity.
<cjwatson> Riddell: is somebody working on the kdebindings FTBFS on armel?
<ubottu> Launchpad bug 710582 in ubiquity (Ubuntu Natty) "ubiquity crashes after step 'Who are you' : segfault in libwebkitgtk-1.0.so.0.5.2 on AMD64" [Critical,Triaged] https://launchpad.net/bugs/710582
<ev> jibel: ugh, it seems like we get these once a cycle.  Sure, will do.
<jibel> ev: thanks
<Riddell> cjwatson: I can't work out the problem (it's failing to typecast double as qreal). I've pinged upstreams who havn't so far helped
<ev> jibel: I've followed up on the bug
<cjwatson> Riddell: maybe I should work my way through the problems I'm more likely to be able to solve then ;-)
<JackyAlcine> When will Ubuntu replace X for Wayland?
<cjwatson> RAOF: I just uploaded xserver-xorg-input-evdev to fix a udeb dependency problem which was showing up in component-mismatches.  I don't suppose you could sync that upload into wherever x-s-i-e is maintained?
<RAOF> cjwatson: Yeah, ok.
<cjwatson> Riddell: qtmobility 1.1.0-0ubuntu3 removed libqtmessaging1, I think, but qtmobility-dbg still seems to depend on it?
<cjwatson> RAOF: thanks
<cjwatson> ... and I think that should be the last of the x86 uninstallables
<cjwatson> JackyAlcine: http://www.markshuttleworth.com/archives/551 is the most authoritative answer to that I know of
<bdrung> cjwatson: re libkibi: it wasn't as easy as i assumed. https://bugzilla.gnome.org/show_bug.cgi?id=640432
<Riddell> cjwatson: ok I'll look at that along with the arm build failures of qtmobility today
<cjwatson> Riddell: thanks
<cjwatson> bdrung: well, I'm not hugely surprised, but we can't leave the c-m status the way it is forever
<bdrung> cjwatson: c-m?
<cjwatson> bdrung: we could demote it and bump the MIR bug back to Fix Committed pending app changes?
<cjwatson> bdrung: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<JackyAlcine> Fantastic, cjwatson.
<bdrung> cjwatson: i'll can start to port non-glib C programs.
<RAOF> cjwatson: Ah, I guess -evdev hasn't been published yet?  I'll leave that for Bryce then.  Time for me to hit the sack :)
<mvo> pitti: I'm working on that now, it should be fine
 * pitti hugs mvo, danke
<cjwatson> RAOF: not quite.  https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.6.0-1ubuntu3
<om26er> hey janimo
<janimo> om26er, hello
<om26er> janimo, could you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/totem/totem-fix-647607/+merge/47903
<jibel> ev: I'll submit the bt after lunch. In the mean time I caught another blocker but this time on Kubuntu bug 710612 . Looks like a problem with debconf.
<ubottu> Launchpad bug 710612 in ubiquity (Ubuntu Natty) "Kubuntu Desktop AMD64 - ubiquity kde_ui crash with File "/usr/lib/python2.7/dist-packages/debconf.py", line 70, in command self.write.flush() IOError: [Errno 32] Broken pipe" [Undecided,New] https://launchpad.net/bugs/710612
<janimo> om26er, looking
<janimo> om26er, have you built this and it works?
<om26er> janimo, I have not build since it seemed like a one line fix, should I now, will take a few minutes if you say
<janimo> om26er, ok, just to make sure, please do, thanks
<janimo> since you know the best how to test if it indeed fixes the bug
<mvo> pitti: what does a line with multiple seperators in modaliases looks like? i.e. what is the seperator? Modaliases: fglrx(..), fglrx2(..) ?
<mvo> pitti: in the Packages header
<pitti> mvo: right, modulename(alias, alias, ...), modulename(alias, ...), ...
<mvo> ok, thanks
<cjwatson> jibel: it's rare for such things to be a problem with debconf, just as compiler errors are rarely a problem with gcc
<pitti> mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/view/head:/jockey/oslib.py#L716 is what jockey uses
<cjwatson> FYI
<mvo> thanks pitti
<bdrung> mvo: bug #710618 - that's the try to comply to ubuntu's units policy
<ubottu> Launchpad bug 710618 in apt (Ubuntu) "Please support libkibi" [Wishlist,New] https://launchpad.net/bugs/710618
<bdrung> mvo: libkibi is in NEW in Debian
<mvo> bdrung: thanks, I have a look. also I tend to be very reluctant to add dependencies to libapt
<bdrung> mvo: libkibi is very small for that reason
<mvo> pitti: hm, the old modalias files had a "xorgdriver" as part of their data, that got dropped now?
<mvo> pitti: it should not affect u-m much though, just curious
<pitti> mvo: where was that?
<hyperair> cjwatson: ping
<juliank> bdrung: I share mvo's opinion with dependencies, and APT seems compliant already
<hyperair> cjwatson: is there a possibility of enabling busybox's httpd?
<cjwatson> hyperair: why?
<cjwatson> and in which build?
<hyperair> cjwatson: any one of them -- i think it would be useful for testing of stuff that should run on embedded environments.
<mvo> pitti: e.g. http://paste.ubuntu.com/560591/
<mvo> pitti: alas, it looks like its the module, not the xorg driver
<cjwatson> hyperair: well, we certainly can't do it in the udeb, for instance, it would clash confusingly with save-logs
<hyperair> cjwatson: save-logs?
<cjwatson> hyperair: a d-i component
<hyperair> cjwatson: how about busybox-static? or busybox?
<pitti> mvo: right, first is the module name (before the () now), second the package name (Package: field)
<cjwatson> hyperair: httpd is already enabled in those.
<cjwatson> debian/config/pkg/static:722:CONFIG_HTTPD=y
<cjwatson> debian/config/pkg/deb:721:CONFIG_HTTPD=y
<hyperair> eh wait a sec..
<hyperair> oh sorry
<hyperair> i meant... busybox cgi support
<cjwatson> feel free to file a bug for that
<cjwatson> seems reasonable enough
<hyperair> +CONFIG_FEATURE_HTTPD_CGI=y
<hyperair> +CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
<hyperair> +CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV=y
<hyperair> okay
<hyperair> cjwatson: by the way, is there a special use case for busybox-static?
<cjwatson> no idea, it predates me
<cjwatson> I imagine it's recovery shells and the like
<hyperair> ah okay
<om26er> janimo, builds fine on 32bit install. youtube video does not play for me at the moment due to other reasons
<cjwatson> certainly that's why it's in ubuntu-standard
<hyperair> cjwatson: wasn't that the job of busybox-initramfs?
<cjwatson> hyperair: no
<hyperair> ah
<cjwatson> its purpose is to be /bin/sh and tools in the initramfs, not in the main system
<janimo> om26er, ok
<apw> pitti, when you copy out kernels for lucid SRUs (from the canonical-kernel-team PPA) do you include the LBM packages?  i assume you are copying out those packages you are asked to
<pitti> apw: sconklin-gone sends me a list to copy, as there is often old/other stuff
<apw> pitti, ok so the disconnect is at his end, seems he did not include LBM in the lucid update last time, as that is uninstallable rgith now.  there seems to be a valid build in the PPA however
<pitti> apw: ok, so I'll copy that then
<apw> pitti, it looks to be the right version to my eye and matching the git repo, so that seems appropriate
<apw> cjwatson, ^^
<cjwatson> pitti: thanks
<apw> cjwatson, pitti i will close the loop with the stable team to make sure the process hole here is closed
<cjwatson> pitti: this is a regression in -updates right now - do you think we can waive the waiting period to some extent?
<pitti> so it seems neither cert nor qa even test these
<pitti> cjwatson: yes, absolutely
<pitti> cjwatson: I thought we push it to -proposed now, and perhaps to -updates tonight?
<cjwatson> right, once somebody has test-installed it and confirmed it doesn't explode
<apw> pitti, my understanding always has been that they are 'backports' and therefore more like the backports pocket from a process point of view
<pitti> oh, it's not just a no-change rebuild
<apw> pitti, indeed, seems to be some updates from upstream there too ...
<pitti> http://launchpadlibrarian.net/62531555/linux-backports-modules-2.6.32_2.6.32-27.26_2.6.32-28.27.diff.gz is quite nontrivial, so it should be tested at least
<apw> pitti, if you get it into -proposed, i'll get some people in my team to 'feel the pain' testing it
 * apw looks grumpy
<pitti> apw: that'd be great; copied now, and updated bug 606278 (which should get the testing results)
<ubottu> Launchpad bug 606278 in linux-backports-modules-2.6.32 (Ubuntu Lucid) "Add linux-backports-modules-input" [Undecided,Fix committed] https://launchpad.net/bugs/606278
<pitti> sorry for the process fail
<apw> pitti, i don't see you have any fault in the matter
<pitti> forgot about lbm
<apw> pitti, i am sure you reviewed what you are asked to release ...
<apw> pitti, i don't think you should be having to remember
<juliank> bdrung: Why did you create a type filesize_t (that falls into a POSIX-reserved space), instead of using the off(64)_t type which is a standardized type for file sizes?
<hyperair> say... is rmadison going mad? it says busybox is in universe
<hyperair>    busybox | 1:1.17.1-8ubuntu1 |         natty | source
<hyperair>    busybox | 1:1.17.1-8ubuntu1 | natty/universe | amd64, i386
<hyperair> cjwatson: ^^
<hyperair> but launchpad.net/ubuntu/+source/busybox says it's in main.
<hyperair> as does apt-get source
<hyperair> er apt-get show(src)
<juliank> hyperair: source is in main, binary in universe
<hyperair> O_o
<hyperair> oh i see.
<hyperair> juliank: thanks
<cjwatson> juliank: C99-reserved, too
<juliank> cjwatson: Can't find it in C99, at least not in "7.1.3 Reserved identifiers"
<juliank> 7.26.8 defines types matching u?int.*_t as possible future additions
<cjwatson> juliank: hm, looks like you're right, sorry
<ari-tczew> then rebuild
<ScottK> lamont: Is Postfix 2.8 high enough on your list that you're likely to get it done before feature freeze?
<lamont> when is feature freeze?
 * ScottK looks
<lamont> feb24
<lamont> I expect so
<lamont> there's also a new util-linux, which I think would be nice to get in, too.
<lamont> and nmap
<lamont> and prolly bind9 (rc bits are out now)
<ScottK> Debian should be unfrozen this time next week.
<lamont> that's what I've been stalling on
<ari-tczew> ScottK: I heard about 5/6 feb.
<janimo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<ScottK> ari-tczew: Yes.
<lamont> ari-tczew: that'd be "by next week"
 * lamont makes a note to prep and take his laptop to the thing this weekend, since he'll prolly be a bit bored at least part of the time
<bdrung> juliank: off64_t doesn't seems to be portable. maybe i should only use uint64_t from stdint.h
 * dholbach hugs janimo
<juliank> bdrung: Well, the important part would be to not use a name ending in _t, so kibi_filesize would be better
 * janimo hugs dholbach
<janimo> dholbach, piloting was a bit hectic for the first time. I am not too familiar with UDD
<jelmer> hi janimo
<janimo> the diversity of branches and who owns what confuses me still
<janimo> jelmer, hi
<dholbach> janimo, did you take "notes"? :)
<jelmer> janimo: just getting more familiar with it, or are there things you think we can improve?
 * janimo will be back after 1-on-1 call with manager
<janimo> jelmer, need to get more familiar that;s for sure, but there are probably things to be improved
<dholbach> might be good to send a short followup mail to ubuntu-devel@ so we can talk about
<dholbach> I'm sure you're not the only one
<janimo> for instance merging would be easier done only from the web UI wihtith the need to get locally then merge then push
<janimo> dholbach, yes, I'll write one up. It will definitely be short, as there's not much to tell :)
<jelmer> janimo: Yeah, agreed
 * dholbach hugs janimo
<dholbach> thanks
<janimo> dholbach, np
<janimo> jelmer, but I guess there are things which are not technical - such as making sure I am not stepping on other devs toes. From the ~46 sponsoring requets I was not sure which other sponsor has their eyes on
<janimo> the last commented field helps
<Laney> you can always shoot them a quick ping to check :)
<janimo> but with recent bugs (as it actually happened with a U1-sso) upload I think teammate usually help eachother and there's no need for othewr sponsors
<jelmer> janimo: how do you do it for non-UDD sponsoring ?
<janimo> jelmer, the reason it was a bit slow for me is that I did not really do much sponsoring before
<janimo> however I am more familiar with 'here's a debdiff for agains the latest source' approach
<jelmer> janimo: you should be able to use the "Claim Review" link on the merge proposal to indicate you're processing it
<janimo> with bzr seems I need to merge and push to bzr (making sure I push to the right branch i.e ubuntu/totem vs desktop-team/totem)
<jelmer> perhaps we should mention that on the UDD pages
<janimo> then I need to do the same change in the package
<janimo> espeically if the request comes only as a bzr request and orig tgz needs to be found and fetched separately
<ogra> janimo, you can do it the other way round, upload, wait until it shows up in the package branch and then merge back
<janimo> jelmer, I found and used that actually
<jelmer> janimo: Thanks for the feedback :)
<Laney> bzr bd usually manages to find the orig
<janimo> I am sure large part of my troubles was not having read the UDD docs thoroughly and not had peeked over anyone else's shoulder doing sponsoring work
<smb> pitti, apw sconklin Did a quick install test for lbm-lucid. AFAICT all packages are installable from proposed now
<sconklin> smb: thanks
<barry> does anybody know what "System program problem detected" means?  i see this popup on login after today's updates, but it does not appear to be hooked into apport because "report problem..." does nothing
<barry> i do see an indicator-applet file in /var/crash and one from network manager, but those are the only files from today
<seb128> barry, it's what update-notifier displays when there is a crash from another uid that yours
<seb128> barry, it's to avoid locking the screen asking for a gksudo password to report those
<seb128> it should call apport, maybe check .xsession-errors
<barry> seb128: okay, thanks.  note that when i click on "report problem" nothing happens
<seb128> does apport work?
<barry> seb128: unsure.  the other crash was from indicator-applet, and no apport opup came up for that one either
<seb128> barry, try running ubuntu-bug /var/crash/...
<barry> seb128: that worked for the indicator applet crash.  the network-manager crash file from earlier today though "problem cannot be reported".  also looks up u-b tracebacks ;)
<pitti> smb: ah, thanks; so I'll move them to -updates, and then to -security
<barry> seb128: i'll report what i can, thanks
<mterry> dholbach, heyo, can you put me in the patch pilot calendar for tomorrow (as a one-time thing?  i forgot to do it on Friday)
<seb128> barry, yw
<dholbach> sure
<dholbach> mterry, I'll give you access to the calendar too - unfortunately I can't do it "automatically for everyone" :(
<dholbach> anyone else while I'm at it?
<dholbach> mterry, done
<mterry> dholbach, thanks
<Kano> cjwatson: why are u images still not hybrid?
<Kano> cjwatson: https://bugs.launchpad.net/ubuntu-cdimage/+bug/524803
<ubottu> Ubuntu bug 524803 in Ubuntu CD Images "isolinux hybrid mode should be used - all other major distributions do so since last year" [Undecided,New]
<Kano> no response too...
<Kano> cjwatson: btw. i have got a patch for os-prober to fix gentoo detection, and you upload to d too?
<cjwatson> Kano: don't expect me to respond to questions in that tone
<cjwatson> if you have an os-prober patch, it's probably best to file a Debian bug for it and I/we can pick it up there
<Kano> well i told the one i wrote the patch for to do that
<cjwatson> if you'd asked politely about isohybrid, I would have given a detailed status update
<Kano> just update the bug?
<cjwatson> but not now
<cjwatson> no, you were rude in the bug
<cjwatson> I don't reward people who are rude with details
<cjwatson> sorry
<Kano> well every other distro uses hybrid mode, even live-build creates binary-hybrid.iso
<cjwatson> we will be moving to hybrid mode; if you'd been polite I would have given details of the plan
<cjwatson> as it is I'm afraid you'll have to wait
<Kano> well i can execute isohybird on the iso, but do others know that?
<Kano> ntfs-3g seems to be a bit old too
<Kano> 2 stable releases after 8.8. already
<Kano> would be interesting too for u, as it does not need any patch most likely
<Kano> New: implemented the âsyncâ mount option.
<Kano> http://www.tuxera.com/community/release-history/
<kirkland> slangasek: howdy, around?  wanted to chat with you (again) about bug #313812
<ubottu> Launchpad bug 313812 in eCryptfs "umount of ecryptfs does not automatically clear the keyring (can be mounted by root later)" [Medium,Triaged] https://launchpad.net/bugs/313812
<elif> Hi, as vim user I would like to know when 7.3 will arrive at ubuntu ?
<davmor2> apw: Hey dude Latest natty upgrade seems to kill my wireless and drop me into flight mode no nm
<apw> davmor2, did you use to be using linux-backports-modules-wireless ?
<cjwatson> elif: natty already has it; earlier releases will remain at their current versions
<davmor2> apw: If it wasn't in the standard install nope,  I've just checked on a fresh cd from this morning same issue.
<davmor2> apw: is it best to ubuntu-bug the kernel and point you at the bug?
<apw> davmor2, definatly want a bug yes please
<davmor2> no probs one minute
<bdrung> cjwatson: do it
 * apw wonders if we have a firmware name change or something
<cjwatson> bdrung: do which?
<bdrung> cjwatson: demote libkibi and bump the MIR bug back to Fix Committed
<cjwatson> ok
<cjwatson> done
<davmor2> apw: bug #710738
<ubottu> Launchpad bug 710738 in linux (Ubuntu) "Regression latest kernel breaks my Atheros AR5001 wifi" [Undecided,New] https://launchpad.net/bugs/710738
<apw> davmor2, and you are ok if you boot back to the .37 kernel ?
<davmor2> apw: I'll check if it's still listed
<davmor2> apw: 2.6.37-12-generic is fine I have wireless
<elif> cjwatson: I saw something strange, I know I'm using 10.10 (maverick), but system->About Ubuntu is saying I'm using 11.04 (Natty), It's just curious thing.
<apw> davmor2, could you get a dmesg from that too please, and add it to the bug
<micahg> cjwatson: or pitti can I get one of you to reject thunderbird-locales from maverick-proposed, I forgot one change
<pitti> micahg: sure
<pitti> micahg: but why remove? you can just upload a followup and use -v<version_in_updates> to include the previous changelog(s)
<cjwatson> elif: please file a bug, I can't take all your bug reports personally :-)
<micahg> pitti: it's included in that changelog :(
<micahg> pitti: it hasn't been accepted yet
<pitti> micahg: aah
<pitti> micahg: I thought you meant "the version which is already in proposed"
<micahg> sorry, I should have specified the upload queue
<cjwatson> elif: (anyway, I think that's already known)
<davmor2> apw: added dmesg.txt
<apw> davmor2, ta
<elif> cjwatson: ok. just thks, I'll check there. and try to file bug if not.
<pitti> micahg: done
<micahg> pitti: thanks, I'll reupload shortly
<cjwatson> elif: bug 690248
<ubottu> Launchpad bug 690248 in ubuntu-docs (Ubuntu Maverick) "In Maverick 'About Ubuntu' displays Natty info" [High,Triaged] https://launchpad.net/bugs/690248
<elif> cjwatson: that's unfair you're too fast. anyway I have to get used with launchpad yet.
<davmor2> apw: anything else you need?
<apw> davmor2, not that i can think of right now, thanks
<davmor2> apw: if you think of anything feel free to ping
<mr_pouit> pitti: your halsectomy page is only for rdepends, right? Because hal is still pulled somehow on the latest xubuntu daily, so I suppose there are still a few spurious (r)recommends ;p
<pitti> mr_pouit: the page isn't a complete rdepends list in Ubuntu, just projects which we run into
<mr_pouit> ah, okay
<pitti> mr_pouit: exaile still pulls it in, for example
<mr_pouit> yeah, I just saw that, it's in recommends
<pitti> mr_pouit: http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.natty/rdepends/hal/hal
<pitti> mr_pouit: so, pretty much just that
<pitti> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.natty/rdepends/hal/libhal1
<pitti> mr_pouit: libthunar-vfs-1-2
<pitti> stil needs libhal1
<pitti> or is that library obsolete as well?
<mr_pouit> yeah, and I managed to drop it from the default install
<hallyn> so if i dont' have the hw to reproduce a bug, and am waiting for someoen to confirm a fix for the bug - what's the proper state?  leave it as 'in progress'?
<cjwatson> sounds reasonable to me
<hallyn> ok
<apw> davmor2, are you in armenia ?
<apw> it seems your networking went into country AM configuration
<davmor2> apw: no wolverhampton not much difference
<mvo> DktrKranz: if the gdebi gio branch looks good to you then feel free to just merge to trunk and upload, should be good from my POV
<apw> davmor2, whats channel is your access point on ?
<davmor2> apw: 11bgn mixed, http://ubuntuone.com/p/b4y/
<apw> davmor2, and the iwconfig output from the linux side would be good
<davmor2> apw: for which kernel new or old?
<apw> the working one :)
<apw> as your routerconfig just says "any i feel like"
<davmor2> apw: added to bug
<apw> davmor2, ta
<slangasek> kirkland: hi there
<kirkland> slangasek: howdy
<kirkland> slangasek: so, this bug is gaining heat, once again
<kirkland> slangasek: my tested/working solution involves the small patch to pam, here: http://launchpadlibrarian.net/39308219/pam.diff
<kirkland> slangasek: which i think you've nacked in the past
<kirkland> slangasek: i guess i'm wondering if that nack still holds :-)
<slangasek> kirkland: yeah, it does.
<kirkland> slangasek: okay
<kirkland> hallyn: ^
<SpamapS> So, does anyone else have the situation where gdm starts, and the screen is black.. then ctrl-alt-f1, login, restart gdm, fixes it?
<SpamapS> I changed gdm.conf to start on stopped rc RUNLEVEL=2 .. and that seems to have fixed the problem.. but made login available a few seconds later in boot.
<DktrKranz> mvo: ok, I'll give it a go later
<DktrKranz> mvo: should we bump to 0.7.0, changes and fixes introduced will be quite important
<Riddell> slomo: gst-plugins-base0.10 no longer compiles because /usr/include/linux/videodev.h no longer exists
<cjwatson> w
<cjwatson> w
<cjwatson> (sorry)
<slomo> Riddell: that's sad, why? was v4l(1) dropped?
<ari-tczew> ogra: ping
<Riddell> slomo: there seems to be a /usr/include/linux/videodev2.h now
<slomo> Riddell: yes, that's for v4l2... ok, i guess old v4l is finally gone then, that's good news. for ubuntu you only have to drop the v4l plugin then, in debian i'll still keep it until after squeeze release
<Riddell> slomo: ok thanks, I'll upload with that change
<udienz> did all ftbfs packages must be fixed before natty?
<micahg> udienz: would be nice, but there are usually some failures left, the ones in main will usually be addressed before release though'
<udienz> micahg: if a fixed package release after natty, the packages will be uploaded to natty or O-release?
<Laney> FTBFS can be fixed via SRU
<micahg> udienz: well, fixes should land in the devel release first, if there are no binaries, FTBFS fix usually qualifies for SRU, if there are binaries, then usually the fix is saved until another fix goes in unless it's something we know will need to be rebuilt (i.e. lots of security updates in the past)
<udienz> ok, thanks
<mvo> DktrKranz: yeah, sounds good to me
<hyperair> cjwatson: thanks for the upload =)
<cjwatson> no problem
<cjwatson> thanks for the patch :)
<scott-work> cjwatson: do you have a minute to talk about an error in tasksel for ubuntu studio installs from image?
<cjwatson> scott-work: it's the end of my day so I'm only intermittently around; it would be best if you described the problem such that I can reply asynchronously
<SpamapS> cjwatson: re the openssh-server init.d script being more upstart aware.. I'll take a look and see if I can whip something up. :)
<cjwatson> great, thanks :)
<bdrung> geser: DMB meeting now!
<kees> rickspencer3: re LP: #710796 -- the _kernel_ had hibernate removed. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commitdiff;h=2e5f0ea801534914c6747e953ed277fa16081602
<rickspencer3> oh
<rickspencer3> kees, ok, so I was a bit out of touch there
<rickspencer3> I thought they were just hiding the UI where "they" was the desktop team
<rickspencer3> removing it from the kernel is bold, indeed
<kees> rickspencer3: right, that's mostly okay -- that's just a configurable. but to be _unable_ is a big deal, IMO.
<rickspencer3> kees, well, I dropped a note to @u-devel and @u-desktop
<rickspencer3> I think a proper discussion would be good
<cjwatson> it seems bad form to remove it from the kernel; I said as much to kernel folks at the rally ...
<rickspencer3> kees, would you mind correcting my mistake on that thread?
<kees> rickspencer3: cool, thanks.
<kees> cjwatson: and that desktop told us that it wouldn't be removed from the kernel. :P
<kees> rickspencer3: yup, already added a note.
<kees> rickspencer3: or do you mean the u-d thread?
<rickspencer3> hmm
<rickspencer3> the disconnect was probably due to me not connecting dots sufficiently
<rickspencer3> in any case, it seems like a good thing to propose and explore, but warrants some discussion before a final decision is taken
<cjwatson> I can see the news articles already :-/
<cjwatson> (FWIW I don't care whether the UI is there or not!)
<maco> hibernate as in dont-use-power-(if-it-works) ?
<rickspencer3> maco, correct
<maco> O_o
<ScottK> Sigh.  I use that every time I get on an airplane.
<rickspencer3> most of the time for me, as in, wait a long to shutdown, then not start up properly
<ScottK> rickspencer3: Where is this discussion?
<rickspencer3> ScottK @ubuntu-devel and @ubuntu-desktop
<rickspencer3> I just started a thread ..  Shall we hide the GUI for Hibernate in Natty?
<ScottK> rickspencer3: If it's not in the kernel, that's an easy one to answer.
<rickspencer3> well, tbh, I didn't realize it was removed from the kernel
<rickspencer3> a bit changes the tone l)
<rickspencer3> *;)
<ScottK> Right.
<rickspencer3> anyway, the discussion needs to take place
<broder> it would be nice if we could make some reasonable runtime guesses as to whether or not it would work on a given piece of hardware
<rickspencer3> there are pros and cons and options
<ScottK> Brings up the "If I have to compile my own kernel anyway, why am I using *buntu" question.
<rickspencer3> broder, I was thinking of a white list combined with a checkbox to turn it on if you're not on the white list
<ScottK> My only problem with it recently is sometimes I don't have enough swap available (which I can fix), so it's not necessarily a fixed list of what works and what doesn't.
<broder> yeah, sure, though maintaining that list is obviously difficult, especially with release-to-release regressions
<rickspencer3> but, it's not really my decisions, I'm just trying to make sure that it gets discussed, and doesn't end up happening a bit by default
<broder> ScottK: available swap is easy to test for
<ScottK> broder: Agreed.  It does that now and then doesn't shut down.
<ScottK> rickspencer3: I didn't see anything on ubuntu-devel.  Is it just on -desktop so far?
<rickspencer3> ScottK, could be
<rickspencer3> I sent it to both lists
<kees> rickspencer3: you only sent to u-desktop? not -devel?
<broder> no, it was to devel as well. i bet it's stuck in moderation or something
<rickspencer3> kees, ubuntu-devel@lists.ubuntu.com
 * kees waits on https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/date.html
<broder> rickspencer3: the e-mail came from your @canonical address. for future reference, my recollection is that anything from an @ubuntu.com address (or maybe from the ubuntu.com smtp server?) is automatically accepted
<rickspencer3> broder, thanks for the info
<sconklin> pitti, StevenK: is there an actual archive on launchpad (accessible through the API) which corresponds with http://archive.ubuntu.com/ubuntu/pool/main/ ??
<broder> actually, what makes hibernate unreliable? because it doesn't seem like it should be hardware dependent - it seems more like it's an issue with not enough swap, or unfavorable disk layouts that the initrd can't dig into correctly, etc
<apw> rickspencer3, well we can reinstate it, but its a kernel respin, so if we need to do that for A2 we'll need to cope with the kernel bumping
<ScottK> apw: Why did it get disabled?
<apw> ScottK, that as i understood it was the decision, it seems a misscommunication if 'get rid of it' doesn't mean that
<ScottK> apw: Who's decision?  We certainly support it in Kubuntu.
<apw> i don't think i was there fore the discussion, only the final messge it was to go
<rickspencer3> i don't think we should worry about turning it back on for A2
<rickspencer3> it's not worth a respin and revalidating
<rickspencer3> imo
<ScottK> rickspencer3: But we are going to turn it back on in the kernel, right?
<rickspencer3> I would think so, but I think we should wait and see how the discussion progresses
<ScottK> rickspencer3: So far we're only discussing disabling the U/I on one flavor of Ubuntu.  It would seem odd to me that might drive the decision about a kernel change.
<rickspencer3> ScottK, you make a good point, I asked someone to add to the thread that it's actually turned off in the kernel right now
<ScottK> rickspencer3: That's been done.
<rickspencer3> I wasn't aware that that particularly step had been taken
<ScottK> But I think the discussion should be on ubuntu-devel.  At this point we aren't just talking Ubuntu Desktop.
<rickspencer3> oh?
<rickspencer3> I send the email to both
<pgraner> rickspencer3, we had discussions at the sprint and the take aways was that is was to get tuned off to see what the impact was
<rickspencer3> pgraner, ack
<pgraner> rickspencer3, so we turned it off in the kernel
<rickspencer3> probably my fault for not connecting all the dots properly
<rickspencer3> however, there is plenty of time to discuss and turn it back on, etc...
<ScottK> At this point you've ripped it out from under all the other flavors with no discussion.  You need to decide if that as appropriate or not.
<ScottK> If it's not, please have it turned back on.
<ScottK> Not sure what else there is to discuss.
<rickspencer3> let me log a bug to get it turned back on
<rickspencer3> I don't think anyone is particularly married to the idea of it being off in the kernel
<pgraner> rickspencer3, nope we can turn it back on post A2
<rickspencer3> ok
<rickspencer3> let me start a new bug for turning it back on the kernel, and sorry for the confusion
<smagoun> rickspencer3: thanks for doing that. Would you post the bug # here when you're done?
<rickspencer3> yes
<rickspencer3> smagoun, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/710877
<ubottu> Ubuntu bug 710877 in linux (Ubuntu Natty) "re-enable hibernate in the Natty Kernel" [Undecided,New]
<kees> rickspencer3: the bug was already open (the original report was against the kernel...)
<rickspencer3> kees, yeah, but I want to keep that one "should we hide it"
<rickspencer3> ?
<rickspencer3> versus the discrete task of turning it back
 * kees doesn't care. the wording of 710796 was "it's broken in the kernel". *shrug*
<rickspencer3> kees, just give me a few minutes to get these fixed up
<smagoun> thanks
<rickspencer3> kees, the user for bug #710796 is clearly saying "I want hibernate to work"
<ubottu> Launchpad bug 710796 in linux (Ubuntu Natty) "[regression] hibernate no longer works on natty" [Undecided,In progress] https://launchpad.net/bugs/710796
<rickspencer3> or, "I want the feature there"
<kees> rickspencer3: they said "option was removed and pm-hibernate doesn't work". the latter is the kernel issue
<rickspencer3> which is different than bug #710877 which is to just turn it back on
<ubottu> Launchpad bug 710877 in linux (Ubuntu Natty) "re-enable hibernate in the Natty Kernel" [Undecided,In progress] https://launchpad.net/bugs/710877
<rickspencer3> kees, right, so there's 2 issues, so should be 2 bug reports, imo
<kees> rickspencer3: sounds good!
<rickspencer3> in any case, I think the first bug should be moved to polkit
<kees> rickspencer3: my point was that 710796 was already open against the kernel, etc.
<kees> but yeah, whatever makes sense. as long as it's coming back in the kernel, I'm happy :)
<hallyn> bdmurray: /win 10
<hallyn> huh
<hallyn> bdmurray: what is the 'proper' place to get your greasmonkey lp extensions?
<micahg> hallyn: https://launchpad.net/~gm-dev-launchpad/+archive/ppa
<bdmurray> hallyn: firefox-lp-improvements ppa is the best
<hallyn> thanks
<DktrKranz> mvo: gio branch merged!
<cjwatson> broder: no, the auto-accept is based on membership of ~ubuntu-dev
<broder> oh really? that's actually rather clever. so i assume that means it also incorporates any e-mail address a member of ~ubuntu-dev has registered on their lp account?
<cjwatson> (though I don't see Rick's mail in the moderation queue - of course there is an extra whitelist)
<cjwatson> broder: it's supposed to
<cjwatson> that part is not directly visible to me though, but that's what I'm told
<ScottK> lamont: Has fiordland been "improved" or does "stuff" just happen: http://paste.ubuntu.com/560732/
<cjwatson> ok, I have no idea where rickspencer3's mail to ubuntu-devel went
<cjwatson> it's neither in the queue nor in the archive
<rickspencer3> weird
<rickspencer3> cjwatson, I'll resend, and yeah, weird
<cjwatson> the queue's been suspiciously empty all day (some longer-term things in there but nothing new)
<cjwatson> and nijaba was asking me about some problem earlier ...
<cjwatson> rickspencer3: I suggest chasing it up with IS, quoting the message-id of the message you sent
<cjwatson> I'm not sure resending will help - it will probably just confuse things
<rickspencer3> ok
<cjwatson> it's almost as if anyone not on the whitelist is getting binned
<lamont> ScottK: good question. I'm a bit out-of-loop on that, maybe an RT with the output on it would be in order
<ScottK> lamont: OK rt .at. ubuntu.com?
<elmo> sigh
<elmo> the problem is the tool that hardcoded fiordland
<elmo> rather than using the MX
<elmo> fiordland is no longer the mx for launchpad.net
<ScottK> I see.
<ScottK> bdrung: ^^^^
<ScottK> elmo: Thanks.  That we can fix.
<cjwatson> oh, wow, that's nasty code
<ScottK> tumbleweed: ^^^
<lamont> ew
<ScottK> Yep.  Updating to the current MX works.
<ScottK> elmo: Thanks.
<elmo> ScottK: np
<cjwatson> updating to code that doesn't just hardcode a new MX, I hope :)
<lamont> hopefully doing a lookup of mx for launchpad.net and using that???
<broder> ugh, smtplib doesn't have a mode where it will do that itself? that's kind of lame
<ScottK> broder: It's smtplib, not DNS.
<broder> yeah, but "send this message to whoever is the mx for the recipient" seems like a pretty common thing to do
<StevenK> Uh, doing a lookup of an MX inside Python is not expensive?
<geser> that's also means SRU's are needed
<cjwatson> StevenK: how do you do it then?  I was just googling ...
<StevenK> Damn it, I knew some one was going to ask that.
<cjwatson> so far, only found a stackoverflow comment saying that doing MX lookups in python requires a third-party module
<ScottK> It's not that hard.
<ScottK> I'm the Debian maintainer for python-dns.
<ScottK> One could also use dns-python.  That's a bit overkill for this.
<cjwatson> though dnspython is at least in main
<cjwatson> (but I agree, it's a big hammer)
<StevenK> Bah, seems I'm mis-remembering. Doing DNS lookups in Python can be done with 'socket', but things like MX or NS lookups need a 3rd party module.
<broder> yeah, that was what i thought
<ScottK> cjwatson: Since I'm maintaining python-dns, I don't think it matters much which is in Main.
<cjwatson> ScottK: heh, fair enough
<cjwatson> StevenK: right, socket.getaddrinfo is fine for A lookups
<scott-work> cjwatson: if i were to fix the seeds and push it back to bzr would you be able to help me get the meta packages rebuilt?
<scott-work> cjwatson: i would really like to get the tasksel fixed before alpha2 and my usual contact hasn't responded back yet
<geser> ScottK: are you going to file a bug about it for u-d-t? or should I do it?
<cjwatson> scott-work: doesn't need metapackage rebuilds, just needs a tasksel rebuild.  yes I can do that.
<ScottK> geser: No.  I'm going to fix it.
<geser> ok and thanks
<scott-work> cjwatson: i will update the seeds in approximately six hours time from now
<scott-work> cjwatson: and thank you again!
<geser> ScottK: don't we need a bug for the SRU? as maverick and lucid are affected too
<ScottK> Good point.
<ScottK> Please file it.
<cjwatson> scott-work: is it possible to do it before I go to bed?
<cjwatson> scott-work: if you do it six hours from now, I won't update tasksel until I get up in the morning, and we'll miss the cron job that should be building the alpha-2 images
<scott-work> cjwatson: unfortunately i'm at work and will not leave for another 1.5 hours, plus need to pick kids up on the way home
<cjwatson> scott-work: you can just tell me what change to make
<cjwatson> what the new Description should be
<scott-work> cjwatson: i can do that:
<scott-work> cjwatson: in audio-plugins replace "Task-Description: LADSPA, LV2, and DSSI audio plugins" with "Task-Description: LADSPA/LV2/DSSI audio plugins"
<cjwatson> scott-work: committed, thanks
<scott-work> cjwatson: awesome, thank you very much :)
<cjwatson> I'll upload tasksel once the local update finishes here
<geser> ScottK: bug 710925
<ubottu> Launchpad bug 710925 in ubuntu-dev-tools (Ubuntu) "[requestsync] fiordland.ubuntu.com is not a MX for launchpad.net anymore" [High,Triaged] https://launchpad.net/bugs/710925
<SpamapS> cjwatson: so the most reliable way that I can find to determine whether or not to use upstart is to drop a fake randomly named job in /etc/init and ask upstart what its status is.. if it doesn't know about the job, then I assume we're in a chroot.
<StevenK> geser: That's so not the bug.
<broder> SpamapS: oww
<StevenK> "Talks directly to a machine, assuming it's the MX for launchpad.net"
<cjwatson> SpamapS: look at /proc/1/exe?
<SpamapS> cjwatson: its a symlink. :-/
<SpamapS> as is /proc/root and /proc/cwd
<SpamapS> no help at all :P
<geser> StevenK: fixed the bug description (taken yours)
<cjwatson> I've definitely seen code along those lines that worked
<broder> cjwatson: i know you can see if something is in a chroot under you looking at /proc/pid/root
<broder> i don't think it works the other way around
<cjwatson> initramfs-tools.preinst
<cjwatson> tested, works fine
<cjwatson> of course on the feature test principle it would be better to test whether upstart knows about the job, so that things work once upstart gains chroot support, but that may be too complex to live
<broder> oh right, you have to look at the inode number. i remember seeing that now
<SpamapS> The inode number of what exactly?
<SpamapS> ?
<cjwatson> see initramfs-tools.preinst
<broder> your / vs. /proc/1/root
<cjwatson> there's a chrooted() function there which works
<SpamapS> right, that is reasonaly accurate, but fails if you chroot into a dedicated mount point
<cjwatson> "dedicated mount point"?
<broder> SpamapS: sorry, combination of the inode and the device number that contains / :)
<SpamapS> mkdfs file ; mount -o loop file /mnt/mychroot ; copy stuff to /mnt/mychroot ; chroot /mnt/mychroot /bin/bash
<SpamapS> dev number yes that works
<cjwatson> please try the code I referred to
<SpamapS> yes I was waiting for bzr branch ;)
<cjwatson> cat /var/lib/dpkg/info/initramfs-tools.preinst
<SpamapS> oh that would have been clever wouldn't it have?
<SpamapS>     # borrowed from udev's postinst
<cjwatson> it was in Debian udev's postinst, I think, not Ubuntu's
 * SpamapS is wary of spreading the evil of copy/paste :-P
<cjwatson> yes, still is
<cjwatson> meh
<cjwatson> I mean I kind of agree but this is code we already know we intend to throw away
<SpamapS> That branch of Scott's looked reasonably mature.. did you get any feeling as to how likely it was to make it into natty?
<broder> the upstart spec still has it scheduled for natty, right?
<cjwatson> fairly, I think, he and James just need to agree on maintenance practices
<cjwatson> (not that there's a fundamental disagreement AFAIK, it just needs to get nailed down)
<SpamapS> Cool. So this really is just likely to be something for lucid and maverick only.
<cjwatson> I'm not going to worry about that until closer to feature freeze
<jcastro> ogra: did you get the mail from the banshee upstream guy (gabriel) wrt. ARM?
<SpamapS> so.. the question in my mind is how do we know to throw this code in openssh-server away when upstart gets the new capability...
<cjwatson> if you come up with something, let me know :)
<bdrung> ScottK: feel free to commit a fix to lp:ubuntu-dev-tools
<ScottK> bdrung: It's been "improved" in natty, so I'm not sure I'll be able to fix it.
<ScottK> bdrung: Where does mailserver_host get set now?
<bdrung> ScottK: ask tumbleweed
<ScottK> tumbleweed: ^^^
<bdrung> ScottK: requestsync line 99: default='fiordland.ubuntu.com'
<ScottK> Thanks.
<bdrung> ScottK: don't forget to update the man page too
<ScottK> bdrung: Found it.
<bdrung> poolie: i checked bzr with lintian and found that: http://paste.ubuntu.com/560748/
<tumbleweed> bdrung, ScottK: back. shall I commit a fix?
<ScottK> tumbleweed: I'll do it for Natty and then you can backport, OK?  I'm already working on it.
<bdrung> tumbleweed: yes unless ScottK is working on a fix too
<tumbleweed> ScottK: great. I suppose you'll have to pull in an extra dependancy for DNS support :/
<ScottK> yes
<poolie> bdrung, thanks
<SpamapS> slangasek: so I think we can write the -wait job generically
<SpamapS> slangasek: meaning one could reasonably do    start wait-for WAIT_FOR=ssh
<slangasek> SpamapS: instance $WAITER$WAITSFOR ?
<ScottK> bdrung and tumbleweed: Pushed.
<bdrung> ScottK: where?
<ScottK> bdrung: My bad.  Comitted.  Didn't push.  Just a moment.
<ScottK> bdrung: Pushed to trunk.
<tumbleweed> ScottK: the second config.get_value doesn't do anything useful
<tumbleweed> it will also not abort if it can't do the DNS lookup, but presumably crash later when it tries to connect to ''
<geser> ScottK: there is a typo in the ImportError message: "Launchapd" â "Launchpad"
<tumbleweed> and you can test it on staging :P
 * tumbleweed heads to bed
<SpamapS> slangasek: something like that, still monkeying with it
<hggdh> slangasek, can you please look at bug 708579? This is either a new issue, or bug 603934 is not completely fixed
<ubottu> Launchpad bug 708579 in runit (Ubuntu) "package runit 2.1.1-6.2ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurÃ¼ck" [High,Triaged] https://launchpad.net/bugs/708579
<ubottu> Launchpad bug 603934 in upstart (Ubuntu Natty) "upstart-job returns SysV-incompatible value for 'start' when job is already running" [Critical,Fix released] https://launchpad.net/bugs/603934
<SpamapS> slangasek: yes, that works..
#ubuntu-devel 2011-02-01
<slangasek> hggdh: it boggles the mind that runit has been upstartified; looking
<SpamapS> upstart runs runit runs daemontools runs home and cries to djb ;)
<slangasek> hggdh: this package is calling stop/start directly - that's a bug
<slangasek> hggdh: the only interface policy says packages are supposed to use in their maintainer scripts is invoke-rc.d
<hggdh> slangasek, ah, I feel better now :-)
<SpamapS> slangasek: I'm going to send the idea to upstart-devel ... I think this may be the right thing to ship and recommend people use until we have 'while'
<slangasek> SpamapS: ok, cool
<slangasek> hggdh: so yeah, it's a bug in runit, which is definitely not a package I'm spending any effort fixing right now :)
<hggdh> slangasek, NP. I understand all that is needed is change the postinst to call invoke-rc.d instead of /sbin/start. If this is it, I can do it mesself. Correct?
<slangasek> hggdh: well, the *sensible* thing to do is to make the package use debhelper, which automatically spits out the correct maintainer script snippets... but yeah, I don't think you want to maintain that :) so just replacing with invoke-rc.d is the way to go
<SpamapS> hggdh: the real question is why isn't it using dh_installinit
<SpamapS> err.. what he said
<slangasek> SpamapS: I don't think that's a question, really
<slangasek> I mean, it's runit
<slangasek> did you expect the packaging to not also be idiosyncratic? ;)
<hggdh> SpamapS, slangasek: adding debhelper will be a bigger change ;-)
 * hggdh would rather start with small changes
<slangasek> hggdh: yeah, I generally wouldn't be in favor of debhelperifying a package in Ubuntu only unless it's something we plan to maintain
<hggdh> deal
<ScottK> geser, tumbleweed, etc.  Feel free to fix.  I need to run.
<jderose> Does anyone know if Python3.1 will remain in Natty, or will it be dropped, leaving just Python3.2?
<persia> jderose, I can't speak authoritatively, but I doubt anyone is going to try really hard to drop python3.1.
<persia> I suspect the default python3 interpreter will be python3.2
<persia> Python2.6 will likely also be available in parallel.
<jderose> persia: yeah, 3.2 already seems to be default.  i'm working on a python3 package and was just curious if i should fully QA for running under 3.1 also, or just 3.2
<jderose> persia: thanks for the insight!
<persia> I'd recommend focusing on 3.2: it will be a rare case that someone would be using 3.1 unless they asked for it especially.
<persia> And in the longer term, 3.1 will go away: I'm just not sure that the actual final removal is on someone's natty agenda.
<jderose> persia: okay, thanks :)
<RAOF> Any archive admins available to push through the -vmmouse sync in bug #709134?  It's the last of the pieces required to transition to Xserver 1.10.
<ubottu> Launchpad bug 709134 in xserver-xorg-input-vmmouse (Ubuntu) "Sync xserver-xorg-input-vmmouse 1:12.6.99.901-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/709134
<pitti> Good morning
<SpamapS> pitti: ahoi! :)
<RAOF> pitti: Good morning!
<RAOF> pitti: Are you archive admininging today? The sync in bug #709134 will finish the Xserver 1.10 transition.
<ubottu> Launchpad bug 709134 in xserver-xorg-input-vmmouse (Ubuntu) "Sync xserver-xorg-input-vmmouse 1:12.6.99.901-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/709134
<pitti> RAOF: I'm not, but I can do the sync
<pitti> RAOF: is that the reason why dist-upgrade currently croaks?
<pitti> The following packages have unmet dependencies:
<pitti>  xserver-xorg-core : Breaks: xserver-xorg-video-8
<pitti> hm, hardly, that's -input
<pitti> oops, seems the new pygobject breaks a lot
<RAOF> It will be breaking dist-upgrade, once the rest of the uploads are built and published.
<pitti> will fix
<pitti> synced
<RAOF> Hm.  That's ususually long.  -ati finished building 3 hours ago, doesn't seem to have made it to archive.ubuntu.com yet.
<micahg> O
<micahg> I'm wondering, if a few packages build-dep on a package only on archs that we don't have, can the build-dep be dropped from Ubuntu (gcc-4.3)
<pitti> micahg: yes; we should drop it if it reduces delta from Debian, and keep it if that b-dep is in Debian (IMHO)
<micahg> pitti: the build-dep is gcc-4.3 and it's only on archs we don't have
<pitti> micahg: right, I understand
<pitti> micahg: as it's basically a no-op for us, we should keep it if the Debian package has it as well (to avoid an unnecessary delta), and drop it if not
<micahg> pitti: I'm wondering about dropping gcc-4.3 :)
<pitti> ah
<pitti> sorry, misunderstood
 * micahg probably isn't too clear at this hour :)
<pitti> there's still a couple of rdepends, though
<micahg> I'm looking now for ones that aren't no-ops
<pitti> e. g. chromium-browser
<pitti> Build-Depends: g++-4.3 | g++-4.2
<micahg> pitti: is there a germinate output for it?
 * micahg is wondering if there's an easy way to check for remaining deps
<pitti> micahg: http://paste.ubuntu.com/560844/
<micahg> pitti: is that a special tool?
<pitti> micahg: a lot of that is self-referential and there might also be alternative dependencies for those
<pitti> micahg: it's checkrdepends from lp:ubuntu-archive-tools
<micahg> ah
<pitti> checkrdepends gcc-4.3 natty
 * micahg needs to remember that
<micahg> pitti: thanks, will look into this
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<\sh> moins
<didrocks> good morning
<dholbach> Who wants to give a session at UDW? Please sign up at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable - thanks :)
<apw> didrocks, anyone reporting 'focus' issues with yesterdays unity... i am seeing the wrong cursor and lack of sensitivity on some elements ... actiling like one of the semi-transparent places boxes is on the screen; though there is nothing visible
<didrocks> apw: hey, there are some bug report in compiz, all new info like xwininfo + click on the "invisible" window can be great
<didrocks> apw: bug #709461
<ubottu> Launchpad bug 709461 in compiz (Ubuntu Natty) "semi-random invisible window with x geometry on top layer possible, all viewport only (one ws though)" [High,Triaged] https://launchpad.net/bugs/709461
<apw> didrocks, will see what i can gleen
<cjwatson> pitti: 'checkrdepends gcc-4.3 natty' isn't the right invocation any more :-)  probably works by accident ...
<cjwatson> bryceh,RAOF,Sarvatt: is there going to be an upload of -video-mach64 for the new X?
<cjwatson> bryceh,RAOF,Sarvatt: actually, there seem to be several video drivers missing, per http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
<RAOF> cjwatson: Meep, that's a big list of armel.
<cjwatson> I'm guessing that's just due to no (input|video) drivers being installable yet, so xserver-xorg's uninstallable, so xserver-xorg-core's uninstallable
<RAOF> Yeah, looks like it.
<RAOF> *All* the drivers built against the wrong server?!  Bah.
* cjwatson changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<RAOF> Ok.  I'll bump the X server dependencies and get those rebulit.
<cjwatson> OK, thanks
<cjwatson> RAOF: does that go for the ones that are still uninstallable on x86 too?
<RAOF> Yeah.
<RAOF> I see the rebuild-the-world script is going to need to be a bit smarter next time :/
<cjwatson> OK, I'll leave that with you then, thanks.  Do you need upload assistance?
<RAOF> I will, yes please.
<cjwatson> Point me at something moderately digestible then ...
<RAOF> I'll get everything batched up, then ping you once?
<cjwatson> yep
<RAOF> Is *_source.changes suitably digestible, or would you like debdiffs as well?
<cjwatson> just source packages should be fine
<pitti> cjwatson: oh?
<cjwatson> pitti: 'checkrdepends -s natty gcc-4.3' or just 'checkrdepends gcc-4.3' (plus -b if you want binary)
<cjwatson> pitti: I sent a mail about this at the time, I think - I had to change the syntax to make the interface sane for looking up multiple packages at once
<pitti> cjwatson: ah, so I suppose it additionally checked for rdepends of the "natty" pacakge
<cjwatson> yeah
<pitti> cjwatson: right, forgot about that apparently; thanks!
<ogra> The following packages have unmet dependencies:
<ogra>  unity : Depends: unity-common (= 3.2.16-0ubuntu1) but it is not going to be installed
<ogra> E: Broken packages
<ogra> GRRR !
<didrocks> ogra: on armel?
<ogra> didrocks, yeah, i suspect only arch any vs arch all out of syncness
<didrocks> ogra: right
<didrocks> ogra: unity FTBFS yesterday on armel IIRC
<ogra> but it gets annoying, we dont have images for weeks due to that skew
<didrocks> let me recheck
<didrocks> the FTBFS was due to something not being able to install
<cjwatson> I retried it earlier this morning
<ogra> cjwatson, you had some ideas how to solve that properly, i want to have a spec/BOF at next UDS about that
<didrocks> I asked for a rebuild a little bit later without any success
<didrocks> yeah, it's built now, thanks cjwatson
<ogra> it has gotten really bad this release
<cjwatson> ogra: the theory isn't difficult, but it requires soyuz implementation time
<directhex> should i mention here that canonical's gcc madness causes mono to fail more than three times as many test cases on natty as on sid, on the same arm hardware?
<cjwatson> it doesn't need a bof, it needs to get done
<ogra> cjwatson, right, i'll take care that we have soyuz people around for that
<cjwatson> directhex: given that our gcc maintainer is on holiday, I'm not sure what you would be achieving
<ogra> i think with a new non x86 arch it will get bad for others too
<cjwatson> ogra: around> it still doesn't need a bof
<ogra> cjwatson, well, then a spec with the right people assigned
<cjwatson> the solution is to keep multiple versions of packages in the Packages and Sources files, with appropriate refcounting
<ogra> ok
<cjwatson> so you have as many versions of architecture: all packages in the db as are required to match published builds of each architecture
<ogra> well, wouldnt it be easier to just block the new ones from showing up until the set is complete ?
<ogra> i know there will be a slight out of sync-ness across the arches due to that, but thats still better than completely uninstallable sets and seems easier to implement
<ogra> at least in my imagination (not knowing the code at all)
<cjwatson> that would cause different problems
<ogra> ah, k
<cjwatson> my solution is not theoretical
<cjwatson> http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
<cjwatson> (nor is it "my solution", come to that, but anyway)
<ogra> geez 2009 !
<ogra> i'll talk to davidm that he organizes resources for implementing that in O
<cjwatson> also http://twerner.blogspot.com/2009/11/dak-dominate-will-dodadoda-debian.html
<ogra> we have literally lost weeks this cycle due to it
<cjwatson> so this is implemented in practice and the various client-side things that had problems have generally already been fixed now; there is certainly no need to design something afresh, and it would probably be actively undesirable to do so
<ogra> well, i think linaro designed something different from scratch
<cjwatson> linaro probably didn't know about this
<ogra> they us an archive snapshot afaik
<cjwatson> this should be purely a catchup project
<ogra> *use
<ogra> but that adds the difficulty to know when the achive is in sync at all
<ogra> right, i'll do some writeup for david and hand it to him to make sure we have resources assigned for an implementation
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: pitti
<RAOF> ogra: Does your crazy AC100 still need -input-kbd?  I'll include that in the rebuild frenzy.
<ogra> RAOF, yep, it does, thanks !
 * dholbach hugs pitti
 * pitti hugs dholback
<RawChid> I just installed Wireshark in lucid, but for certain functionality it needs to be started as root. In previous versions it installed 2 menu option (1 to start with root privs.). Is this a bug? Anyone know if I should report this issue?
<RawChid> The issues is I manually had to make a second menu item for starting with root privs.
<cjwatson> RAOF: how's it going?
<jelmer> pitti: Thanks for merging that evolution-mapi patch :)
<RAOF> cjwatson: I'm just running a test-build of everything.
<pitti> jelmer: at your service :)
<RAOF> cjwatson: If you'd prefer, tjaalton has offered to sponsor the packages, too. :)
<cjwatson> don't mind
<cjwatson> I just want to get going on alpha-2 builds ASAP
 * didrocks sneaks two small fixes for unity places meanwhile :)
<RAOF> cjwatson: Yeah, sorry.
<ari-tczew> pitti: free?
<pitti> ari-tczew: what's up?
<ari-tczew> pitti: could you look on gedit merge?
<cjwatson> ari-tczew: you know main is (soft-)frozen?
<pitti> ari-tczew: will look, if it's safe for a2
<ari-tczew> cjwatson: oh! nope. but Robert Ancell has sponsored bluez for me 11 hours ago.
<cjwatson> ari-tczew: that was before the soft freeze started.
<ari-tczew> pitti: translations update
<pitti> ari-tczew: looks safe enough, yes
<cjwatson> pitti: please don't
<cjwatson> gedit has an arch any/all split; build skew will render it uninstallable
<pitti> ok
<ari-tczew> :(
<ogra> ari-tczew, pong btw :)
<cjwatson> well, maybe not since the dependencies aren't actually all that strict
<pitti> it doesn't have a strict dependency, though
<cjwatson> but surely it can wait for after alpha-2?  we have a lot of stuff still to build, like most of X
<ari-tczew> ogra: hi, do you will have time for my 2 bugs? (we talked PM last time)
<pitti> so I'll just review then
<cjwatson> so I would rather not have main uploads that will have to be scored down
<ari-tczew> cjwatson: ok but how long it needs to wait?
<cjwatson> alpha-2 is due on Thursday, although it will depend on QA cycles
<cjwatson> you can see this from the release schedule
<ogra> ari-tczew, yes, working on defoma atm but wont upload until friday (due to softfreeze)
<pitti> it doesn't change anythign visible anyway, so it's not urgent in any way
<ogra> (defomas build-deps are hilarious)
<pitti> for now I just reviewed/approved the MP
<ari-tczew> ogra: yep
<RAOF> cjwatson: I think everything in http://cooperteam.net/Packages/ is good to go.
<cjwatson> RAOF: OK, great, thanks - I'll start pushing
<cjwatson> modulo wet-string internet
<pitti> want me to take half of them?
<pitti> cjwatson: ^
<cjwatson> nah, it's ok
<Kano> hi cjwatson , there is the bugreport for os-prober: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611670
<RAOF> Ok.  Midnight says hello, time to go to bed.
<jfer> dholbach, i had the pleasure of meeting Kate LCA2011 she informed me that packages are still being accepted for natty. I was wondering if acire will be packaged for natty?
<dholbach> jfer, I have no idea
<RAOF> ogra: Argh, urgh.  Despite my first test-build somehow suggesting otherwise -kbd doesn't build against 1.10; I'll look at that tomorrow morning.  Sorry.
<ogra> RAOF, no hurry
<ogra> RAOF, i cant use natty on the ac100 yet until the new QT is uploaded
<ogra> (since i need to use unity-2d and QT without NEON)
<jfer> is it possible to be included in natty?
<dholbach> jfer, can you talk to Jono about that? I really don't want to be assumed to be the "maintainer" for it
<jfer> ok thanks.
<ogra> dholbach, sissy
<dholbach> jfer, I did one upload to the PPA to backport it and could see if it's possible to upload a natty version to the PPA
<dholbach> ogra, you do it!
<ogra> nah
<ogra> :)
<dholbach> there you go
<jfer> i am keen to get involved in packaging. is the mentoring program still happening?
<dholbach> jfer, unfortunately not, but I suggest you still check out https://wiki.ubuntu.com/MOTU/GettingStarted and just ask your questions in #ubuntu-devel or #ubuntu-motu
<dholbach> there's no dedicated 1-on-1 mentoring that I know of
<dholbach> but there's still a lot of very helpful people
<tumbleweed> #ubuntu-packaging is a good spot for packaging questions. Its very quiet, though...
<jfer> ok. i have watched a few of your videocasts and they are most helpful but i am keen to get working on some real examples
<dholbach> excellent
<ari-tczew> dholbach: hello. when we can except first conclusions from surveymonkey?
<dholbach> ari-tczew, in a few weeks
<ari-tczew> aha
<dholbach> lunch time :)
<cjwatson> RAOF: all done now, thanks!
<cjwatson> oh, damn, except it would have helped to use dupload -t ubuntu :-/
 * cjwatson expects a giant pile of reject mails
<cjwatson> RAOF,bryceh,Sarvatt: the new xserver-xorg-input-mouse fails to build - do you know what's going on there?
<pitti> cjwatson: FYI, I uploaded the pywebkitgtk fix, as it's quite important, but lowered its build score
<pitti> so it doesn't get into the way
<cjwatson> pitti: is that the one that fixes a crash in ubiquity?
<cjwatson> oh, no
<pitti> it previously shipped a broken .pyc file
<cjwatson> ok, that's fine, thanks
<tseliot> cjwatson: can I see the build log of xserver-xorg-input-mouse, please?
<tjaalton> http://launchpadlibrarian.net/63296363/buildlog_ubuntu-natty-i386.xserver-xorg-input-mouse_1%3A1.6.0-1ubuntu1_FAILEDTOBUILD.txt.gz
<tseliot> ah, thanks
<tjaalton> it probably needs an update to build against the new headers
<tjaalton> right, there hasn't been a release for 1.10
<tseliot> yes, I agree
<cjwatson> raof just bumped the build-dep
<tjaalton> hmm
<tjaalton> yeah that's not quite enough :)
<tjaalton> the warnings aren't critical, but looks like at least two commits from master should be needed for input abi 12
<pitti> I guess with nvidia/fglrx being broken right now, I better disable those in Jockey for now
<tjaalton> there could probably be a check for the video abi, and not offer those if the current package doensn't provide the current abi?
<pitti> right, that'd be a more permanent solution
<tseliot> pitti: yes, that would be a good idea, until I fix the dependecies as discussed in the ubuntu-x mailing list
<tjaalton> there's been some talk about how to handle the abi's on ubuntu-x@
<pitti> tjaalton, tseliot: so if I get the -video-abi from xserver-xorg-core, and check it against the driver package's Provides: line, would that be correct?
<pitti> (why is it provides: and not depends:?)
<tseliot> pitti: yes, I think so
<pitti> tseliot: fglrx doesn't seem to have a video-abi provides at all?
<tjaalton> I haven't read the thread with thought, yet, so can't comment in detail :)
<pitti> tjaalton: that's how it currently seems to work, anyway
<tjaalton> pitti: well, it doesn't really work currently
<tseliot> pitti: RAOF pointed me to ${xviddriver:Depends} which is what I should use instead of provides
<pitti> hm, so perhaps I just generally disable them for now, and postpone the ABI matching when this got settled
<tjaalton> yeah
<tseliot> pitti: I thought I added that in fglrx but I'll definitely fix it in the next upload
<tseliot> +1
<tjaalton> tseliot: I'll check -mouse and upload whatever builds against the new abi
<tseliot> tjaalton: ok, good. Let me know if you need a hand
<ari-tczew> tseliot: when we can except the fix for nvidia?
 * cjwatson cleans up the xserver-xorg-video-s3virge reject
<tseliot> ari-tczew: if you mean "expect", I'm still thinking about it
<tseliot> I noticed the thread in ubuntu-x only last night
<tjaalton> tseliot: grah, those abi patches don't apply on 1.6.0, probably best to pull master (1.6.99)
<tjaalton> not that it's hugely different in functionality..
<tseliot> tjaalton: they are going to release something stable together with X, aren't they? So it shouldn't be a problem
<tjaalton> tseliot: right, it was recently bumped to 1.6.99
<tseliot> yes, I see that in git
<tjaalton> actually, that happened two months ago, but there's only one commit after that :)
<cjwatson> are one of you two able to do the upload?
<tjaalton> cjwatson: yeah, I'll pull git master and wrap it up
<cjwatson> cool, thank you
<zul> can anyone tell me why mcollective got rejected?
<cjwatson> zul: you didn't get an e-mail?
<cjwatson> zul: Riddell was doing some source rejections earlier ...
<ev> a bit of historical curiosity: perhaps it's a false memory, but wasn't the plan a while back to use the desktop wallpaper for the plymouth theme so that the visual transition was minimal?
<zul> cjwatson: no i might have missed it or maybe dustin got it
<Riddell> zul: https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039057.html
<zul> Riddell: ok thanks
<Riddell> which also went to uploader kirkland
<ogra> ev, quite a *while* back ;)
<ev> any idea why it didn't come to fruition?
 * ogra hanst heard anything of that plan after dublin
<ogra> *hasn't
<ev> hm
<ogra> i guess because it was still usplash back then
<ogra> and likely nobody thought about it later when we got plymouth
<tjaalton> cjwatson: well, the new -mouse doesn't build on pbuilder because the headers are not available (yet). but it should be good for the archive builder, I guess
<cjwatson> tjaalton: go ahead if you think it's good, I don't think it can get significantly worse
<tjaalton> heh, right.. let's see how it goes
<tjaalton> there
<smoser> cjwatson, have you or know of a 2.6.38 kernel with grub 0.97 ? asking due to bug 710754.
<ubottu> Launchpad bug 710754 in linux (Ubuntu) "natty kernel does not boot on t1.micro in arch i386" [Medium,In progress] https://launchpad.net/bugs/710754
<smoser> smb has a workaround for -virtual kernel on ec2, but I was curious if it affected all grub 0.97.
<smb> For completeness, the bug seems to be in pv-grub which is based on the old grub. It may or may not have the same potential in there.
<cjwatson> smoser: I don't know, sorry
<cjwatson> pvgrub makes my head hurt
<smb> Heh, it surely did that to me even without looking at its code
<cjwatson> let me check grub's changelog briefly
<cjwatson> but I seriously doubt there've been any recent fixes in grub; last upstream commit in our package was 2005
<cjwatson> don't see any relevant changes post 0.97, on a quick glance
<smb> cjwatson, Probably just something to keep in the back of our memories should there be somone approaching us with strange boot failures with grub0.97 and Natty or later i386 kernels.
<smb> Not this should be expected to happen...
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<tjaalton> cjwatson: -mouse built, whee
<pitti> kees, jdstrand: postgresql just announced new security/bug fix release, I'm preparing them
<pitti> kees, jdstrand: are we actually still concerned about this buffer/int overflow in a security sense? http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=7ccb6dc2d3e266a551827bb99179708580f72431
<pitti> kees, jdstrand: or do we merely handle that as a DOS now?
<pitti> i. e. do you want -security or SRU?
<pitti> well, I guess at least teh dapper backport should go to -security
<jdstrand> pitti: a DoS in a server we consider medium priority
<pitti> jdstrand: ok, so still -security?
<jdstrand> pitti: so -security would be great
<pitti> jdstrand: ok; I'll open a tracker bug for it, and put the updated source packages somewhere
<pitti> jdstrand: 8.1 went out of support, so for that I'll backport the fix
 * pitti hopes there won't be too many security vulns in 8.1 any more until June
<jdstrand> pitti: thank you. not sure who will process it, it could be sbeattie or mdeslaur (or me or kees)
 * jdstrand nods
<jdstrand> pitti: but if you subscribe us to the bug (and ping as you helpfully do :), we'll sort that out. thanks for preparing them :)
<pitti> jdstrand: yup, as usual; thanks!
<geser> has marking a function (a constructor) as "inline" (or not marking anymore) any influence on the API or ABI of a library?
<pitti> in some cases at least
<pitti> I painfully remember that with apt
<pitti> inline constructors in C++ really really suck, and should be avoided
<geser> I'm looking at http://launchpadlibrarian.net/58061583/buildlog_ubuntu-natty-i386.gecode_3.4.0-1_FAILEDTOBUILD.txt.gz
<pitti> as you can't change them without breaking ABI
<pitti> (in a behavioural way, not in a compile sense)
<geser> as the .so version got bumped would that be a good chance to drop the "forceinline" from that contructor (or even all constructors)?
<juliank> Inline functions should be avoid in general, unless you can prove that there is a large advantage in a performance-critical path
<juliank> s/avoid/avoided/
<pitti> geser: sounds good; but that should probably happen upstream?
<geser> pitti: upstream "fixed" it by not providing a constructor with a va_arg list anymore. I'll wait on the DD to package it (upstream released it today)
<pitti> geser: but still inline?
<geser> yes, even "forceinline" :(
<pitti> geser: that's still broken, as with that you can't change the implementation of the ctor at all without breaking abi
<ogra> /var/lib/dpkg/tmp.ci/config: 127: cannot create /dev/null: Permission denied
 * ogra scratches head
<cjwatson> something's removed your /dev/null
<ogra> i'm in a chroot
<hallyn> make a new one
<ogra> and am root
<cjwatson> unfortunately it's extremely hard to retrospectively find out what
<ogra> and /dev isnt bind mounted or anything
<hallyn> oh
<ogra> so i should be able to just write to it as a file
<hallyn> ogra: cat /proc/self/status | grep Cap
<ogra> proc isnt mounted either
<hallyn> biab
<geser> nodev mount option?
<ogra> oh !
<ogra> indeed !!!
 * ogra higs geser 
<ogra> err
<ogra> *hugs
<SpamapS> is there a quick tool that I can use to check two revisions against the debian version sort algorithm?
<cjwatson> dpkg --compare-versions
<SpamapS> I knew it had to be simple. :)
<Amaranth> RAOF, bryceh: You broke my unity :/
<didrocks> kenvandine: you have the same issue on intel as well, isn't it? ^^
<didrocks> Amaranth is suggesting an FBO issue
<Amaranth> compiz itself works but if you enable the unityshell plugin and start compiz it segfaults, getting a backtrace now
<ScottK> tumbleweed: Thanks for fixing up requestsync.  Sorry I had to run off (due to $WORK stuff).
<Amaranth> #5  0x00007fce31d361c5 in nux::IOpenGLFrameBufferObject::Deactivate() () from /usr/lib/libnux-graphics-0.9.so.0
<Amaranth> So yeah, FBO :/
<Amaranth> I think it fails to setup the FBO and crashes trying to clean up
<bryceh> Amaranth, your welcome
<bryceh> Amaranth, actually, I booted unity successfully yesterday with the new stack and it seemed to be working fine for me
<kenvandine> didrocks, what's the issue?
<kenvandine> didrocks, yes mine is on intel
<didrocks> kenvandine: look ^^
<seb128> what are you debugging?
<kenvandine> didrocks, i didn't try disabling unity
<kenvandine> let me do that
<seb128> I just restart after some upgrades and my session was empty
<seb128> no compiz, no nautilus, no gnome-panel running
<seb128> it's weird
<didrocks> seb128: maybe you have the same issue than Amaranth is describing
<SpamapS> Amaranth, isn't that a grain used by the aztecs?
<Amaranth> bug 711396
<ubottu> Launchpad bug 711396 in xserver-xorg-video-intel (Ubuntu) "segfault in nux::IOpenGLFrameBufferObject::Deactivate" [Undecided,New] https://launchpad.net/bugs/711396
<Amaranth> I'm thinking we have a gnome-session issue here as well
<Amaranth> Apparently this case has never been tested
<didrocks> Amaranth: what issue in gnome-session?
<Amaranth> didrocks: It doesn't do any kind of fallback
<Amaranth> or even start nautilus...
<didrocks> Amaranth: not, nautius and gnome-panel is starting
<didrocks> Amaranth: look bug #711378
<ubottu> Launchpad bug 711378 in compiz (Ubuntu) "after compiz crashed, gnome-panel isn't mapped again" [High,Triaged] https://launchpad.net/bugs/711378
<kenvandine> didrocks, yes compiz works fine with the unity plugin disabled
<Amaranth> after compiz crashed compiz has no say in gnome-panel being mapped ;)
<kenvandine> Amaranth, right... that is the bug i filed earlier
<didrocks> Amaranth: right, but gnome-panel is running if you look at a tty
<didrocks> Amaranth: so as I have no input there, we filed the bug report
<Amaranth> didrocks: In this case I'm pretty sure nothing is running
<didrocks> Amaranth: did you try on a tty?
<Amaranth> I know nautilus isn't, at least
<didrocks> geser: kenvandine and I tried
<Amaranth> Yeah, I looked with pgrep, didn't look for gnome-panel though, just nautilus
<didrocks> and confirm it's running in that case
<Amaranth> But when I got a terminal running and ran unity --reset it was complaining about dbus and such not running so it seems I got no session
<Amaranth> s/terminal/gnome-terminal/
<didrocks> Amaranth: try with that, you should have gnome-session and othersâ¦ it has been confirmed
<didrocks> just that's it's not mapped
<geser> Amaranth: my gnome-panel is running as I send a SIGHUP to the gnome-panel to make it "reappear"
<Amaranth> I just hope VBOs still work so I can get back to work :)
<didrocks> Amaranth: So I just tried again
<didrocks> Amaranth: gnome-panel is running, nautilus is running and gnome-session as well
<didrocks> so gnome-session has no issue handling the fallback
<Amaranth> except for not starting metacity?
<didrocks> Amaranth: it's compiz which does it
<geser> for me metacity gets started but no visible gnome-panel
<didrocks> Amaranth: as the fallback session is gnomewm + gnome-panel
<didrocks> Amaranth: but as it's segfaultingâ¦
<Amaranth> didrocks: That's not very bright :)
<Amaranth> didrocks: Perhaps it should hardcode metacity
<didrocks> Amaranth: well, you can have compiz running but not unity
<didrocks> Amaranth: hence the helper test unity and compiz capability
<didrocks> Amaranth: so no, sorry, "maybe not bright" but finer grained
<didrocks> compiz should just triggers the fallback
<didrocks> Amaranth: do you still see no nautilus process starting from the session?
<didrocks> as it seems you are the only one to see this bug
<Amaranth> didrocks: I don't want to kill my session and start over right now
<SpamapS> 30757 clint     20   0 2920m 119m  43m S    4  3.0   2:12.84 banshee-1
<SpamapS> whoa..
 * ogra imagines thats LOUD music ;)
<debfx> bryceh: does the xserver-xorg-video-intel apport hook really need python-dev?
<bryceh> debfx, I've got a fix queued for that
<tumbleweed> ScottK: np
<SpamapS> slangasek: the portmap/sysvinit saga continues .. bug #711425
<ubottu> Launchpad bug 711425 in portmap (Ubuntu) "portmap does not stop during shutdown, causing possible root fs corruption" [Undecided,New] https://launchpad.net/bugs/711425
<slangasek> SpamapS: I am skeptical; portmap should only have read-only fds on the root fs
<SpamapS> slangasek: deleted libs are a special case
<slangasek> ah
<slangasek> SpamapS: why are we not restarting portmap at the time of the libc6 upgrade?
<slangasek> oh right
<SpamapS> slangasek: :)
<slangasek> because we don't do that period, we only do that for services that use nss
<slangasek> so yeah, I guess we should solve the nfs shutdown problem
<slangasek> SpamapS: please take into consideration what should happen here in the nfsroot case
<slangasek> (I'm not sure what *should* happen, but it's possible portmap+statd need to be kept running until the very end)
<kees> pitti: still here?
<pitti> hey kees
<kees> pitti: hi! I just sent email. the meta packages haven't been copied, and linux-ec2 is still unpromoted...
<pitti> huh?
<pitti> copy-package.py -ybs maverick-updates --to-suite maverick-security linux linux-backports-modules-2.6.35 linux-ec2 linux-meta linux-ports-meta linux-meta-ec2
<pitti> that's even in the bash history still
<kees> https://launchpad.net/ubuntu/+source/linux-meta
<kees> btw, there is no linux-ec2 in maverick
<pitti> hm, seems that went wrong somehow
<pitti> let me try again
<kees> I assume copy-package.py doesn't take multiple args
<pitti> linux-ec2 | 2.6.32-305.9 |      maverick | source
<pitti> sure there is
<kees> nope, that's been deleted.
<SpamapS> slangasek: with the init.d script.. portmap is stopped after umountnfs .. so maybe nfs root requires modification of the shutdown anyway?
<kees> linux-ec2 in maverick is provided by the "linux" source package. https://launchpad.net/ubuntu/+source/linux-ec2
<pitti> hm, so the source wasn't deleted in time for the release then?
<kees> correct
<pitti>  linux-ec2 | 2.6.32-305.9 |      maverick | source
<pitti>  linux-ec2 | 2.6.32.305.6 |      maverick | amd64, i386
<pitti> it's even the very same binary version
<pitti> very confusing
<slangasek> SpamapS: fair enough
<pitti> ok, I'll skip that then
<kees> yup, but that's not important. linux-ec2 is provided by "linux" in maverick and later, so no one will get the old bins
<slangasek> SpamapS: also I see nfs-common being stopped *before* umountnfs... that's not right
<SpamapS> there's an nfs-common ?
 * SpamapS reads
<SpamapS> right looks like that is what used to stop statd
<pitti> kees: all copied now; sorry about that!
<kees> pitti: cool, thanks!
<kees> pitti: what was the origin of the problem?
<pitti> kees: PEBCAK + copy-packages.py fail
<kees> heh
<kees> I always work from https://wiki.ubuntu.com/Kernel/Dev/ABIPackages to make sure I don't miss anything
<kees> and have scripted the post-unembargo package validations
<pitti> I have scripts for SRU accepting and release as well
<pitti> but not for -updates->-security
<pitti> (... yet)
<kees> hehe
<WikiUser65> BOO!
<WikiUser65> ka pow!
<pitti> the first shot wasn't enough? :-)
<Keybuk> first shot?
<maco> Keybuk: i think he means the boo
<kees> Keybuk: why both ban and unban?
<Keybuk> kees: ban stops auto-rejoin, but no point keeping it around for ages unless he comes back and continues to be silly
<kees> fair enough
<barry> hi folks.  can someone upload a no change rebuild for libvigraimpex?  i think that's all we need to rebuild (and fix) python-vigra for natty
<dupondje> somebody wants to check https://bugs.launchpad.net/ubuntu/+source/vinagre/+bug/711442 ?
<ubottu> Ubuntu bug 711442 in vinagre (Ubuntu) "vinagre crashed with SIGSEGV in g_socket_send()" [Medium,New]
<dupondje> added patch, tested, and it works :) so ...
<cjwatson> Amaranth: could you/somebody update #ubuntu-release once unity/X is fixed (whichever needs to change)?
<cjwatson> (don't update me, I'm finishing for the day)
 * skaet plans to pay attention...
<Amaranth> cjwatson: If RAOF or bryceh don't, yeah
<cjwatson> thanks
<cjwatson> we're treating it as blocking alpha-2 builds, which I trust is reasonable
<Amaranth> I dunno, if nux got fixed it would at least launch metacity instead
<Amaranth> Although apparently you don't get a visible gnome-panel in that case...
<cjwatson> "it"> *something* needs to change ...
<cjwatson> I'm not sure releasing alpha-2 with 2d only would be popular?
<Amaranth> I guess not
<bryceh> Amaranth, does it still crash if you downgrade to glew 1.5.2?
<kees> skaet: btw, we've got security updates coming for openoffice.org and openjdk-6. I'm not sure if we're in the point-release freeze yet, but just wanted to give you a heads-up.
<skaet> kees: thanks for the head's up,  we're in point-release freeze now.   Probably need to discuss with pitti after we get A2 out the door later this wee, what's possible/not for 10.04.2.
<kees> skaet: I saw the SRU freeze, but wasn't sure if it was hard freeze yet
<pitti> no objections from my side; depends if ara/QA are fine with that, as they might test an older version for certification
<skaet> images are going through cert testing now, so fairly solid freeze.  depends on if it will affect hardware or not - mostly.
<pitti> oo.o shouldn't, and for a security update openjdk sounds hw independent as well
<pitti> kees: so +1 from me, but please confirm with ara and victorp as well
<stgraber> hmm, maverick seems broken on netinstall because of an sru ...
<stgraber> new upstart depending on new libc6 but new libc6 is still in -proposed when new upstart is in -updates
<stgraber> ends up red screening d-i as it can't resolve the dependencies
<stgraber> I guess both should have been copied at the same time to avoid the breakage ...
<pitti> did libc6 change ABI?!?
<pitti> ah, the breaks
<stgraber> yep
<pitti> doesn't apt-get upgrade just hold that back for now?
<stgraber> apt-get upgrade will, my issue is netinstall ;)
<apw> anyone else seeing unity core dumping on  login with whats in the archive right now?
<stgraber> I've got VMs automatically installing and they all fail at the moment because of that
<bryceh> skaet, I've repro'd 711396 on same hw as used for testing X stack yesterday
<victorp> skaet, pitti - what? :)
<pitti> victorp: <kees> btw, we've got security updates coming for openoffice.org and openjdk-6. I'm not sure if we're in the point-release freeze yet, but just wanted to give you a heads-up.
<skaet> bryceh,  thanks.
<victorp> pitti -ok, shouldnt really impact cert testing, right?
<pitti> victorp: I don't think so, it's not hw specific
<skaet> victorp,  yeah, that's the assumption.
<pitti> victorp: but still wanted you to ack this
<victorp> pitti, thanks for that. It is fine with me.I will let ara know
<pitti> sounds better than asking folks to download a huge OO.o update right after installing a fresh CD..
<pitti> stgraber: so seems we urgently need to test and publish maverick's eglibc then
<SpamapS> slangasek: so what I'm seeing is that it is considered poor practice to mount multiple machines with the same nfsroot rw... so nfsroot would suggest either nolock or ro .. both of which preclude needing statd and portmap. I don't know about the nfsv4 stuff though.
<SpamapS> slangasek: it makes sense.. whats the point of having a bunch of machines sharing one root fs that they all modify? :-P
<slangasek> SpamapS: for nfsv4 there's a nontrivial bootstrapping problem where the support daemons are concerned; I don't know if anyone is doing nfs4root
<slangasek> yes, you're not allowed to share the same root fs rw :)
<SpamapS> in that case, the point is moot
<SpamapS> we can safely stop portmap and, ergo, statd, after umountnfs
<bryceh> skaet, alright I think we've narrowed bug 711396 to glew.  It happened to get sync'd just recently.
<ubottu> Launchpad bug 711396 in xserver-xorg-video-intel (Ubuntu Natty) "segfault in nux::IOpenGLFrameBufferObject::Deactivate" [High,Confirmed] https://launchpad.net/bugs/711396
<tormod> bryceh, like 7 hours ago :)
<bryceh> tormod, btw was there a particular need for going to the new version, aside from just being in sync?
<tormod> bryceh, nothing in particular other than piglit, and that the last version was > 1 year old
<tormod> bryceh, about time it got wetted, just badly timed at a2 freeze...
<bryceh> yeah we can try again after a2
<tormod> bryceh, maybe unity/etc needs to be rebuilt against libglew-dev?
<bryceh> this look like a sane enough version number for it?  glew (1.5.7.is.1.5.2-1ubuntu1)
<pitti> bryceh: that looks like the standard downgrading versioning approach, yes
<bryceh> ../glew-1.5.7.is.1.5.2
<bryceh> dch warning: no orig tarball found for the new version.
<bryceh> pitti, do I need to re-upload the orig tarball with this?
<pitti> bryceh: yes, as you have a new upstream version
<bryceh> guessing I do, and it needs named accordingly?
<pitti> right
<pitti> glew_1.5.7.is.1.5.2.orig.tar.gz
<bryceh> alright, building it again for one final test locally
<bryceh> lookin' good
<bryceh> uploaded
<bryceh> skaet, blocker bug sorted, reports should close momentarily
<pitti> now if we actually want to update to 1.5.7, it'll look even better
<pitti> 1.5.7.is.1.5.2.no.really.really.1.5.7.this.time
<skaet> bryceh, thanks.
<bryceh> pitti, erf
<bryceh> pitti, hopefully they'll be a 1.5.8 by then...  :-/
<chrisccoulson> pitti - imagine if we update back to 1.5.7 and then decide to downgrade again ;)
<chrisccoulson> what's the limit on version number length? :-D
<pitti> let's test stack overflows in dpkg :)
<chrisccoulson> lol
<apw> pitti, doesn't 1.5.7a work as well ?
<chrisccoulson> 1.5.7.is.1.5.2.no.really.really.1.5.7.this.time.oh.no.back.to.1.5.2.yet.again
<apw> ie 1.5.7.is. < 1.5.7a
<pitti> apw: sure, if upstream won't use that
<bryceh> apw, I like that better
<bryceh> ok back to broken X's
<bryceh> pitti, any ideas on http://paste.ubuntu.com/561141/ ?
<pitti> it's even worse for me
<pitti> Calculating upgrade... Failed
<pitti> The following packages have unmet dependencies:
<pitti>  xserver-xorg-core : Breaks: xserver-xorg-video-8
<pitti> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
<pitti> Depends: xserver-xorg-core (>= 2:1.9.99.901+git20110131.be3be758) but 2:1.9.0.902-1ubuntu4 is installed
<pitti> bryceh: ^ hang on, perhaps same problem that I have?
<pitti> I used the xorg-edgers PPA before
<pitti> bryceh: I suppose the git version was only in -edgers, and is newer than what's in natty?
<apw> cirtianly i have none of that on a machine here
<bryceh> pitti, yeah I ran into the same problems upgrading a box with xorg-edgers enabled
<bryceh> natty has 1.9.99
<pitti> apw: ok, I blame sidegrading fromo -edgers then
<bryceh> so yeah, best to completely remove xorg-edgers before doing this update
<pitti> bryceh: at least http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html seems happy again
<pitti> RAOF: ^ well done
<pitti> so on i386/amd64 the only uninstallable is the libreoffice metapackage
<pitti> nice
<RoAkSoAx> pitti: howdy!! I was wondering if after manually using pm-suspend, when waking up, pm-utils execs any of the /usr/lib/pm-utils/power.d/ scripts?
<RoAkSoAx> pitti: specially because of bug #711517, cause someone pointed me out that waking up after someone suspended using powernap, the user defined settings for his WoL nick changed!
<ubottu> Launchpad bug 711517 in pm-utils (Ubuntu) "pm-suspend doesn't respect wol settings of network interface" [Undecided,New] https://launchpad.net/bugs/711517
<pitti> RoAkSoAx: if you change the power state in between, it's likely, yes
<pitti> RoAkSoAx: it also might not remember the previous power state, so upower might just always run the power.d scripts after resuming
<pitti> ("just in case")
<RoAkSoAx> pitti: probably that's the case cause a user changes the WoL config for the network card, but when resuming from a suspend, the changes are not kept. but Powernap doesn't touch anything rather than making sure WoL is enable in the network card (in the upstart job)
<hdon> hello devs :) does ubuntu-bug depend on there being a crash report?
<RAOF> No - it'll collect information for non-crash bugs, too.
<hdon> RAOF, ok, well it's crashing on a KeyError in, i assume, settings['databases'][name] when i ubuntu-bug firefox. it worked, though, when i did "ubuntu-bug apport" (i tried ubuntu-bug ubuntu-bug, but learned that wasn't the package name for the command)
<hdon> i'm filing a bug report now..
<hdon> anyhow i only asked because firefox hadn't crashed, i just wanted to report an issue (that had been closed before Karmic!) that is present in Lucid
<hdon> the bug in firefox though should be reported upstream to Mozilla, but it needs to be in the Ubuntu tracker because it's a very important issue
<RAOF> Yeah.  There would seem to be a bug in the apport script for firefox, then.
<hdon> RAOF, it looks as though it DOES depend on a crash report. here is the stack: http://pastebin.mozilla.org/1011729
<hdon> ohhhh, hmmm!
<hdon> actually it looks like it must be a different bug
<broder> hdon: that looks like you have firefox installed out of a ppa, not the archive
<hdon> broder, ohhhhhh... hmm! well it probably shouldn't crash... when run from the "run application" dialog, it fails silently after a box pops up with a throbber/progressbar
<broder> hdon: i don't think running command-line things from "run application" has ever been remotely supported. but you're right that it probably shouldn't prompt
<hdon> broder, is it not meant to support ppas? it would be nice i think for ppa maintainers to be able to utilize the bug reporting and issue tracking infrastructure that ubuntu has created. ppas are an important part of the ubuntu community
<hdon> broder, ah, well launchpad.net directed me to a wiki which instructs the user to use Run Application
<maco> hdon: ppa's dont have bug trackers attached to them
<hdon> maco, :( they should!
<maco> hdon: bug trackers are for projects
<maco> though i think itd be amusing if you could file a bug on a person or team to mean that they screwed up packaging :P
<broder> err, s/prompt/crash/
<hdon> that's a place i often think Microsoft and Apple fall extremely short -- unless things have changed since i last checked years ago -- application developers have to package their own tools to help users report errors and give diagnostic information to developers
<hdon> maco, i think that would be awesome!
<broder> based on the very little i know about apport, i think it might be possible for a ppa package to include a file that tells apport where bugs should be filed
<maco> in that case, i dont think it'd be "ubuntu-bug" though
<RAOF> maco, hdon: Bug reporting against PPAs (and a wider variety of objects in general) is on the launchpad TODO list.
<hdon> maco, yes but the ubunut-bug tool does important work like gathering diagnostic information
<maco> would be neat if apport checked apt-cache policy to figure out which ppa to report it against
<broder> maco: i think it does
<hdon> RAOF, yay :)
<maco> hdon: thats just the apport hooks in the packages themselves
<maco> hdon: if you know the package, apport would do the same. ubuntu-bug's specialness is the symptom stuff
<hdon> i see
<maco> (at least, i think... cuz you used to report bugs with the apport command iirc...)
<broder> maco: ubuntu-bug just dispatches between apport-cli, apport-gtk, and apport-kde
<maco> oh
<maco> so apport on its own knows how to do -s audio too then?
<broder> i think so
<maco> nifty
<hdon> what is -s audio?
<maco> -s = symptom
<hdon> ah
<maco> audio = what symptom is problematic
<hdon> and these are apport-cli arguments?
<maco> so if your sound is being faily, you do "ubuntu-bug -s audio" and it asks what sort of fail the audio device is exhibiting
<hdon> oh i see
<asdfqwer> could someone recommend a good torrent client for cli use?
<asdfqwer> for ubuntu server meerkat
#ubuntu-devel 2011-02-02
<cousteau> there seems to be a problem with an update of the package "upstart" (you're probably already aware, but just in case)
<cousteau> seems to be due to a dependency problem; the version of libc6 required doesn't match the one available on maverick
<TheMuso> Gah was about to reply, and then he logged off...
<SpamapS> I hate when people do that :-/
<psusi> cjwatson, I just found breakage from the dropping of the no 'p' partition separator patch.. the installer is still not using the 'p'.  any idea where that code would be?
<cjwatson> psusi: depends which bit of the installer.  most of it should just come from parted.  it would be easier to diagnose given a bug with syslog and partman
<cjwatson> psusi: (we're in incompatible timezones, debugging by IRC probably won't be hugely useful - about to go to bed)
<psusi> hrm... k... I'll take a look at partman and I'm pretty sure we dropped the patch from parted too, but I'll check
<cjwatson> we dropped the parted patch, yes
<cjwatson> there are various bits and pieces where it could be - it would be easier to debug from a log than to try to enumerate them all, I suspect :)
<psusi> k... I'll take a look at the logs and file a bug
<psusi> I had a dog and his name was bingo
<sladen> cjwatson: just got that keyboard question x4 again on upgrade
<cjwatson> sladen: bug with logs please, can't debug it by irc
<cjwatson> I'll see a bug if you file it
<cjwatson> don't suppose you happened to be running with DEBCONF_DEBUG=developer
<kees> SpamapS: argh, how did upstart 0.6.6-4 get promoted from -proposed but eglibc 2.12.1-0ubuntu10.2  did not? now the archive is broken.
<cjwatson> if somebody validates bug 504198 on maverick then it'll be easy to promote
<ubottu> Launchpad bug 504198 in eglibc (Ubuntu Maverick) "locale support broken on upgrade to latest eglibc" [Undecided,Fix committed] https://launchpad.net/bugs/504198
<cjwatson> (and yes, this shouldn't have happened)
<psusi> cjwatson, found the problem and fixed it.  Hopefully you can upload it in the morning in time for alpha 2: bug #711616
<ubottu> Launchpad bug 711616 in parted (Ubuntu) "[PATCH] Fix dmraid install regression" [High,Triaged] https://launchpad.net/bugs/711616
<Laibsch> I am the Debian maintainer of the pastebinit package.  I'm preparing a new upstream release.  Some file were moved from /etc/ to /usr/ (see https://bugs.launchpad.net/ubuntu/+bug/621923).  I compiled and test-installed the package locally, but unfortunately, the files in /etc are not removed. http://paste.debian.net/106271/ What do I need to do to achieve the removal of these files?
<ubottu> Ubuntu bug 621923 in pastebinit (Ubuntu) "configuration folder does not respect FHS" [Low,Fix committed]
<RAOF> Laibsch: Have you performed the requisite supplications in preinst/postinst?
<Laibsch> nope
<Laibsch> Can you tell me more?
<Laibsch> or give an example package I can go by?
<RAOF> http://wiki.debian.org/DpkgConffileHandling
<Laibsch> thanks
<RAOF> And, obviously, use the dpkg-maintscript-helper stuff.
<Laibsch> My machines are lucid
<Laibsch> dpkg seems to be too old on them
<RAOF> Correct, unless we patched that in :(
<achiang> if i'm hacking on a source package and modify debian/control so as not to build a specific binary package, can i simply comment out all the lines in the binary-package.install file, or do i need to remove the .install file completely?
<broder> achiang: if the package is no longer listed in debian/control, i don't think you have to do anything to the .install file
<RAOF> You may have to do something to the rules file, if it explicitly references the package you've commented out.
<achiang> broder: RAOF: both make sense, thank you. :)
<achiang> RAOF: hm, indeed, there is a reference in the rules file to the udeb
<Laibsch1> I've read a bit about the conf file issue.  I'm starting to wonder whether the pastebin definitions are config files or not.
<Laibsch1> pastebinit has one for per supported pastebin where information is stored how to send text to that pastebin
<Laibsch1> these files used to reside in /etc/pastebin.d/ but we're in the process of moving them to /usr/share/pastebin
<Laibsch1> are these config files or not?
<RAOF> If you've installed them under /etc/ then they've been considered dpkg conffiles, and you'll need to do the magic dance.
<Laibsch1> I understand that
<Laibsch1> But I'm starting to wonder if they are config files (and should stay where they are) or whether they are not config file
<Laibsch1> s
<Laibsch1> they somehow configure the program
<RAOF> It depends on how complex you want the program to be.
<Laibsch1> hm, what do you mean?
<Laibsch1> from the next release, the program will read from both /etc and /usr
<RAOF> It seems to me that a totally acceptable solution would be to ship the default providers in /usr/share/hello-I'm-a-provider, and allow the user to define new ones in /etc/pastebin.d
<Laibsch1> I'm starting to have doubts that this is really the right thing
<Laibsch1> OK
<broder> rich set of defaults + user overrideability is a great model
<Laibsch1> RAOF, what you describe is what will ship in the next release
<achiang> RAOF: http://pastebin.ubuntu.com/561246/ -- what do those two lines mean? in the sense that the first line specifies -plibx11-6, but the second line seems to negate it?
<achiang> RAOF: my confusion stems from the fact that i think the first line should call dh_makeshlibs on the libx11-6 package *and* make it depend on the udeb
<Laibsch1> broder: actually, the program reads from three locations /usr/, /etc and dotfile in $HOME
<broder> Laibsch1: even better in my book :)
<RAOF> broder: Oh, yes.  Xserver configuration is much much nicer now that we can throw snippets into /usr/share/X11/xorg.conf.d, and have users put stuff in /etc/X11/xorg.conf.d to override.
<Laibsch1> OK, thanks.  So, I will keep this
<Laibsch1> now need to figure out the magic dance in a way that is supported in lucid (my main system for all machines) and acceptable for experimental
<RAOF> achiang: The first says ârun makeshlibs on the libx11-6 packageâ, the second says ârun makeshlibs on everything *but* the libx11-6 packageâ.
 * Laibsch1 goes back to read the wiki
<broder> Laibsch: if you can test in a pbuilder or schroot and use dpkg-maintscript-helper, that's probably better
<Laibsch> I still need to have lucid support
<achiang> RAOF: i see. so if i'm no longer building the udeb, i can just remove the --add-udeb= arg from that line, but still need to keep both lines to run makeshlibs both on the package and *not* on the package?
<Laibsch> or I will upload a package that I cannot use myself.  Now where would the point be in that? ;-)
<RAOF> achiang: You could also just remove the first line and the â-Nlibx11-6â from the second line.
<achiang> RAOF: duh. that makes much more sense. thank you
<achiang> does anyone know if we use libgtk2.0-0-udeb in our installer? or is that just a graphical d-i thing?
<broder> achiang: to the best of my knowledge, it would be a d-i thing. ubiquity feeds code from udebs into some of its backend stuff, but the runtime environment is all "normal" packages
<achiang> broder: ok, thank you. i am backporting maverick's libgtk2.0 to lucid, and there are versioned B-D on a bunch of libraries, but they *all* look related to udeb / installer-type things
<micahg> kees: BTW, new upstart wouldn't install w/out eglibc
<didrocks> good morning
<sk-ruby> Hi, getting errors while connecting remote MS SQL server from my Ubuntu 10.10...check http://pastie.org/1520778
<sk-ruby> any help would be appreciated
<micahg> sk-ruby: you might want to try #ubuntu-server or #ubuntu as this channel is for development
<kees> micahg: i know, which is why i was crying :( the archive is broken until eglibc gets promoted :(
<micahg> kees: why is that broke?  Isn't apt DTRT?
<kees> well, not broken. just that upstart is suddenly uninstallable
<kees> i am up too late :)
<micahg> kees: me too :)
<micahg> kees: I also forget most people don't use aptitude which does nice things like tell you not to break your system
<mvo> well, apt and update-manager should do the same
<sk-ruby> micahg: thank you
<mvo> kees: *ick*
<micahg> mvo: sorry, that came out wrong (2AM here :))
<mvo> micahg: no offense taken, no worries ;)
<micahg> mvo: are there any plans for "suggestions" in update-manager like aptitude?
<pitti> Good morning
<micahg> good morning pitti
<mvo> micahg: suggestions for alternative solution?
<micahg> pitti: I've looked for that checkrdepends tool and I cannot find it
<micahg> mvo: like how to resolve conflicts if packages cannot be installed
<pitti> micahg: ah, I thought it was in lp:ubuntu-archive-tools, but apparently it's only on cocoplum
<mvo> micahg: not in the near future, while useful its not easy to find a good UI for this so that its useful for non-powerusers I think
<micahg> pitti: ah, ok :), is there anything proprietary about it, maybe it could go in one of the tools branches?
<pitti> micahg: http://people.canonical.com/~pitti/scripts/checkrdepends
<mvo> micahg: but there are some plans to improve the apt resolver :)
<micahg> mvo: yeah, I was just thinking about that as well
<pitti> micahg: no, nothing proprietary, but it is currently written to require a local mirror
<pitti> micahg: shouldn't be too hard to change it to use urllib.open() instead, though
<micahg> pitti: ooh, sounds like a nice mini-python project for me to learn on
<micahg> pitti: thanks
<micahg> pitti: oh, should I file a metabug to resolve the gcc-4.3 rdepends?
<pitti> if we want to get rid of it, sure
<pitti> easier for tracking
<micahg> pitti: ok, I'll do that then, thanks, BTW, would you be able to accept thunderbird-locales in maverick-proposed?
<pitti> micahg: yes, I'll try to have another SRU run today
<micahg> pitti: ok, thanks, I can try to ask for testing at the Xubuntu meeting on Thursday then
<dholbach> good morning
<pitti> bryceh, RAOF: is bug 696957 fixed in natty already?
<ubottu> Launchpad bug 696957 in xserver-xorg-video-intel (Ubuntu Natty) "[SRU] Large non-antialiased text causes xserver to abort" [High,Triaged] https://launchpad.net/bugs/696957
<pitti> ah, description says so, nevermind; closing natty task
<\sh> is there a "non recommended way" to re-enable closed source nvidia drivers for natty, for the newest xorg, somehow...
<cjwatson> achiang: only graphical d-i; currently, we build it but don't use it
<cjwatson> achiang: (though I'd like to use it at some point)
<tjaalton> we could revisit it for 11.10? the X stack should at least be ready for it
<cjwatson> AFAIK the images work, but (a) they haven't had any significant branding effort (b) they're a fair bit bigger and this presents CD size issues :-/
<cjwatson> might put them on the DVD or something
<tjaalton> right
<achiang> cjwatson: thanks
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mterry
<corecode> hi
<corecode> how am i supposed to build packages from bzr that have a quilt patch queue?
<corecode> debuild tells me:
<corecode> ah, nm.
<corecode> it was for the src package
<barry> cjwatson: any chance you can sponsor this: https://code.launchpad.net/~barry/ubuntu/natty/libvigraimpex/bug-711468/+merge/48237
<cjwatson> barry: I can, it needs to be after alpha-2 though I think
<barry> cjwatson: ah, right, thanks
<barry> it's the last main package w/python depends that fails to install afaict
<cjwatson> barry: I think I actually demoted it :)
<cjwatson> python-vigra | 1.7.0+dfsg-7ubuntu4 | natty/universe | amd64, armel, i386, powerpc
<cjwatson> it wasn't actually directly needed - it was pulled in by an arcane quirk of germinate
<barry> cjwatson: even better! :)  it'll still be good to fix (and a rebuild alone should do it), but less critical
<cjwatson> right, I'll leave this in my browser until Thu/Fri and merge it then
<barry> thanks!
<JontheEchidna> mvo: ping
<mvo> JontheEchidna: in a meeting, but otherwise hello :)
<JontheEchidna> mvo: oh, ok. :) I was just wondering if there was currently a way to use the Icon: field of packages in extras.ubuntu.com
<JontheEchidna> to actually get the icon
<JontheEchidna> the thumbnail-url and screenshot-url fields seem pretty straightforward
<mvo> JontheEchidna: there is support for icon-url
<mvo> JontheEchidna: then it will fetch it dynamically, that should even be documented somewere, tremolux, do you have a link?
<JontheEchidna> otherwise it was pretty easy to add support for extras.ubuntu.com apps: http://i.imgur.com/VNQO1.png
<tremolux> JontheEchidna, mvo: hiya, info here: https://wiki.ubuntu.com/PostReleaseApps/Metadata
<JontheEchidna> yeah, I saw that page, but looking at the suspendend-sentence package the Icon: field doesn't give a url
<barry> skaet: for natty alpha 2 release notes, you may want to mention that all main packages should now be built for and installable with python 2.7 (at least afaik).  please request bug reports for any incompatibilities folks find
<skaet> barry, okie, adding now.
<skaet> thanks!
<barry> skaet: i've looked at build failures and installation failures, but there's no way to know if a package is actually run-time compatible unless people actually use them
<barry> skaet: thanks.  please ask folks to add the 'python27' tag to any bug reports
<skaet> barry,  will do.
<stgraber> mvo, JontheEchidna: If that's about suspended-sentence, I saw that we have a typo in the icon name field (after uploading the package obviously ...) so that might be why it's not showing up
<JontheEchidna> suspended-stentence? I saw that too. I'm just wondering where my app should grab the icon from
<tremolux> JontheEchidna: so, in the current scheme, the icons are published by LP to the following directory: http://extras.ubuntu.com/meta/
<JontheEchidna> ok, that's exactly what I needed. Thanks :)
<tremolux> JontheEchidna: you're welcome!  yeah, it's pretty well-hidden (tho not on purpose)  :)
<tremolux> JontheEchidna: I just added that info to the wiki page  :)
<JontheEchidna> thanks :)
<mvo> thanks tremolux!
<tremolux> mvo: sure thing  :)
<\sh> micahg: ZF 1.11.3 is coming
<micahg> \sh: thanks
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: barry, mterry
<ev> kees: regarding bug 710582, can you elaborate on why its bad use of assert macros?
<ubottu> Launchpad bug 710582 in ubiquity (Ubuntu Natty) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults)" [Critical,Confirmed] https://launchpad.net/bugs/710582
<\sh> micahg: zf 1.11.3 just reached natty...your turn ;)
<kees> ev: assert() is fine. webkit's insane way to die isn't helpful for debugging. if it actually used "assert" the reason would be capture, the backtrace would be sensible, etc.
<kees> *captured
<ev> kees: ah, that's what I thought, just wanted to clarify
 * kees nods
<kees> it's not security-bad, it's just terribly ugly and unhelpful. :)
<kees> also, libraries should avoid assert() at all costs
<ev> indeed
<barry> mtaylor: hi.  are you still piloting today too?  can you tell me what you're looking at so we don't step on each other's toes?
<barry> mterry: ^^
<mterry> barry, I was about to pilot off
<mterry> in fact...
<mterry> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: barry
<barry> mterry: cool, np.  i'll take over from here
<mvo> cjwatson: hints on what I can do about bug #712029 are appreciated, not urgend, I will read scrollback (hints how to get grub going and what might cause the issue, I suspect its the subvolume @ that causes the issue)
<ubottu> Launchpad bug 712029 in ubiquity (Ubuntu) "ubiquity btrfs install fails to boot (grub rescue> prompt)" [Undecided,New] https://launchpad.net/bugs/712029
<ari-tczew> is currently filled a bug against nvidia -> latest xserver ?
<TheMuso> ari-tczew: Its known that the current AMD and NVIDIA drivers in the archive do not work with the new X server. It requires NVIDIA/AMD to release new drivers.
<ari-tczew> TheMuso: OK, thanks for info.
<RoAkSoAx> ari-tczew: you have a broken X or a bad resolution that you can't change?
<ari-tczew> RoAkSoAx: I can't boot natty on 2.6.38 kernel, so I removed it and now I'm running 2.6.37-12 kernel on default driver. I can change resolution and now it's native for my monitor 1440x900.
<RoAkSoAx> ari-tczew: I couldn't boot either with latest kernel and nvidia drivers. So I dropped to root prompt (recovery mode), installed xserver-xorg, which deleted the nvidia driver, and it booted. but the resolution was not right. Had to do sopme tricks to get it fixed
<ari-tczew> RoAkSoAx: What's your
<ari-tczew> uname -r right now?
<RoAkSoAx> ari-tczew: 2.6.38-1-generic
<ari-tczew> RoAkSoAx: Use 2.6.37-12
<ari-tczew> You can change then resolution and even dualview.
<RoAkSoAx> ari-tczew: with nvidia drivers?
<ari-tczew> note: without nvidia, default driver (vesa?)
<RoAkSoAx> ari-tczew: oh ok!! nah I'm fine with 2.6.38 now! fixed the resolution problem already I just have an ISO with HDMI... but since it is nvidia.. it was expected
<ari-tczew> RoAkSoAx: Do you know how can I check which driver is natty running ATM?
<kklimonda> ari-tczew: check /var/log/Xorg.0.log
<ari-tczew> kklimonda: Thanks. If I'm correct, it says nv with NOVEAU. Odd.
<ari-tczew> barry: around?
<barry> ari-tczew: i am
<ari-tczew> barry: could you look on bug 712136
<ubottu> Launchpad bug 712136 in pymca (Ubuntu) "Please merge pymca 4.4.1p1-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/712136
<barry> ari-tczew: sure
<kklimonda> any idea if the new queue for debian is being processed at this time?
<barry> kklimonda: do you mean syncs from debian?  not for natty right now since we're frozen for alpha2, but iirc, even after that it's by request only for the rest of the cycle
<ari-tczew> I guess kklimonda is thinking about flow of packages in Debian, not natty.
 * micahg is guessing he means this: http://ftp-master.debian.org/new/
<kklimonda> barry: no, I'm talking about the NEW queue for debian - I'm interested in few packages that are still in their NEW queue and I can see they haven't yet been processed by ftp masters.
<barry> ah
<micahg> DktrKranz: ^^^
<kklimonda> so I'm wondering if the reason for that is the close proximity to the squeeze release, or are they always being slow :)
<micahg> kklimonda: before it was said the NEW processing would be slower during the freeze
<cjwatson> I would expect ftpmasters to have better things to do right now
<kklimonda> micahg: any idea if I can download packages from the new queue?
<cjwatson> but it's not long until the release
<cjwatson> packages in NEW haven't been vetted for redistributability, so I believe Debian would consider it a legal problem to allow you to download things from it
<ari-tczew> barry: any ideas for my question?
<barry>  
<barry> ERC> ari-tczew: do you mean "timeout: 255 seconds
<barry> ERC> ari-tczew: do you mean "
 * barry curses cut-n-paste
<barry> ari-tczew: do you mean "Please get in touch with someone expierence with python to add support for python 2.7." ?
<ari-tczew> barry: nope, support for python 2.7 in bug 712136
<ubottu> Launchpad bug 712136 in pymca (Ubuntu) "Please merge pymca 4.4.1p1-1 (universe) from debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/712136
<ari-tczew> yes
<barry> ari-tczew: yep, i'm looking at that right now
<micahg> barry: are we dropping python 2.6 or keeping it until the next LTS (or no decision yet)?
<barry> micahg: no decision yet.  i did post a message on ubuntu-devel looking for feedback and got radio silence ;)
<micahg> barry: I remember the Launchpad people were big advocates of keeping it around until the LTS
<barry> they are :)
<kklimonda> by until do you mean removing 2.6 in the next LTS, or after LTS?
<barry> micahg: if you have any thoughts, a follow up on the mlist would be great
 * kklimonda has some thoughts actually..
<kklimonda> lets see if I can dig the message out of archive :)
<micahg> barry: unfortunately, I know very little about the python stack, so all I have to contribute is hearsay
<kklimonda> bah, can't find the email when I need it ;)
<kklimonda> barry: do you remember the subject of the email about whether to keep python 2.6 or not for the next lts?
<micahg> barry: I don't see it, was it moderated?
<kklimonda> I do remember reading it
<kklimonda> but I can't find it now :)
<barry> kklimonda: yeah, i can't either!  maybe it didn't make it to the list
<barry> the subject is "Analysis of packages and their Python support"
<micahg> didn't see it
<barry> dated 2011-01-24
<barry> i don't see it on gmane either.  i guess that explains why i haven't gotten any responses :(
<barry> how very odd.  i'm going afk for dinner but i guess i'll resend when i get back
<kklimonda> hmm.. nothing, but I do remember this topic being brought somewhere and that LP people were advocating keeping python 2.6 around.. maybe it was discussed here?
<barry> kklimonda: could have been
<micahg> kklimonda: probably was discussed at UDS as well
<kklimonda> *nods* also possible
#ubuntu-devel 2011-02-03
<bryceh> skaet, you around?
<skaet> bryceh, yup
 * skaet is going to be around all night documenting bugs... :(
<bryceh> skaet, we have a bug preventing people from filing compiz bugs with apport, that I have a fix for
<skaet> sweet
<bryceh> skaet, I wanted to doublecheck with you for uploading the fix before doing so
<bryceh> skaet, it involves an upload of the 'xorg' package, which doesn't require much time from the buildds
<bryceh> but since we're deep in freeze just wanted to be sure it's allowable?
<skaet> thanks for asking.
<bryceh> the bug is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/710630
<ubottu> Ubuntu bug 710630 in xorg (Ubuntu) "fglrx apport hook AssertionError in __setitem__" [High,Triaged]
<skaet> we're likely to go with the images we have, but if we do end up with a spin, this would be a good one to include.
<skaet> buildd's aren't too busy.
<skaet> bryceh,  go ahead.
<skaet> (and thank you! - this is a good one to get fixed)
<bryceh> skaet, alright thanks
<bryceh> skaet, bdmurray gets the kudos for figuring out the fix :-)
<skaet> thanks bdmurray.  :)
<bdmurray> no problem
<chrisccoulson> skaet, if you're documenting bugs, firefox isn't translated at all in alpha 2 ;)
<chrisccoulson> not sure if that's worth documenting
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<hallyn> well, my last update said it couldn't install xserver-xorg-core bc it'd break applications.  that does NOT bode well for chances of my being online in the morning :)
<RAOF> hallyn:  Got any more details?  That *should* now all be fixed (barring nvidia/fglrx)
<hallyn> RAOF: no, i haven't dared reboot or log out yet, but /var/log/apt/term.log says
<hallyn>  xserver-xorg-core breaks xserver-xorg-video-8
<barry> micahg, kklimonda i just resent my messages.  i'm eod, but i'll check the scrollback.  let me know if you do or don't get the messages.
<hallyn> followed by
<hallyn>  installing xserver-xorg-core would break existing software
<micahg> barry: cool, thanks
<skaet> chrisccoulson, bug number?  (yeah, its worth documenting)
<kklimonda> micahg: barry: hmm, I didn't get it, maybe it's in moderation?
<RAOF> hallyn: Do you have the nvidia binary driver installed, or some obscure driver?
<barry> kklimonda: i'm seeing some odd errors in my mail.log.  ubuntu.com is 550'ing the message for some reason, though clearly other messages of mine are getting through.  will investigate tomorrow
<lifeless> barry: stop spamming :P
<barry> lifeless: that's like telling aussies not to say "krikee" :)
<hallyn> RAOF: i mean to have the intel i915 driver
<hallyn> RAOF: but i see nouveau installed
<hallyn> xserver-xorg-video-nouveau
<hallyn> haha, i see, they're all installed
<hallyn> all right, i'd better risk the reboot now so i know what to expect tomorrow
<bogner> I'm wondering about how to package 32 bit versions of libs. Is there documentation about how to make lib32* packages somewhere?
<RAOF> bogner: Not that I know of, but it's not terribly difficult.  You _may_ not want to bother; proper dpkg multiarch support is (apparently) being actively worked upon.
<bogner> RAOF: well, I need a 32 bit libvlc for something I'm working on, and it's easier to deal with things if I package them up
<RAOF> If you need something quick and dirty I'd just cargo-cult from one of the existing lib32* packages; I've touched lib32asound in the past, and it wasn't terrible.
<bogner> Yeah, based on lib32ncurses and lib32asound it doesn't look like it's too hard to deal with
<RAOF> Basically, throw up a new bulid dir, passing -m32, and you're golden.
<hyperair> hmm, what's this "soft freeze"?
<kklimonda> hyperair: it's a freeze that is not enforced by LP
<hyperair> ah, i see.
<bryceh> hyperair, don't upload stuff unless it's a critical bug fix\
<hyperair> kklimonda, bryceh: thanks
<hyperair> i suppose archive will be unfrozen after alpha 2
<kklimonda> yeah
<micahg> hyperair: you can upload stuff if it's not in any of the images
<micahg> or any build-deps of the images
<DktrKranz> kklimonda: packages are processed at a lower pace during freeze, expect more activity when squeeze is released (i.e. after this weekend). And no, you can't download packages from NEW.
<pitti> Good morning
<didrocks> good morning
<dholbach> good morning
<dholbach> janimo, thanks for the patch pilot post!
<dholbach> diwic, is https://wiki.ubuntu.com/DistributedDevelopment/Documentation also lacking information about bd-do?
<dholbach> I think that'd be the best place where we can put it
<dholbach> and it should go into the new packaging guide project that was just announced
<diwic> dholbach, *reading*
<diwic> dholbach, so that might be it, if there was a link from the packaging guide I just didn't make the connection from "Distributed Development" to bzr build-deb
<tumbleweed> not sure how useful (does it even work?) bd-do is for non-merge-mode branches
<dholbach> diwic, I added a comment to https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/702002
<ubottu> Ubuntu bug 702002 in Ubuntu Packaging Guide "Add article about Ubuntu Distributed Development" [Undecided,New]
<persia> bzr bd-do is the thing that pulls a remote tarball based on watch files or get-orig-source, right?
<diwic> persia, and executes a command/shell upon the result
<tumbleweed> persia: it's like svn-do, puts you into a temporary directory with upstream source + debian dir
<persia> Does it pull the upstream source that matches the source used for the packaging, or the latest upstream source?
<tumbleweed> persia: used for packaging :)
<tumbleweed> there's an open bug on that not being the policy-compliant way to use get-orig-source. We need to take it up with debian-policy
<persia> How does it do that?  get-orig-source is semantically required to get latest upstream, and watch files typically get latest upstream (especially for upstreams that don't store old tarballs around)
<persia> I actually agree with the current reading of debian-policy.
<persia> Seems easier to grab the version-matched tarball from our mirror network, no?
<tumbleweed> persia: well obviously it tries that first
<persia> (plus we then happen to have a trusted artifact, rather than a constructed artifact)
<tumbleweed> then get-orig-source, then uscan
<dholbach> janimo, I just added another comment to the CodeReviews page - thanks for the feedback
<persia> Ah, then that makes more sense (but wasn't obvious)
<tumbleweed> a fair number of pcakgase (including my own) use get-orig-source like that, because its more useful than getting the latest upstream
<persia> I'd prefer if there were two operations: one to get current source, and one to get new upstream, but that's a matter of preference.
<janimo> dholbach, you're welcome, I'll cjheck the page
<tumbleweed> persia: yeah, that's why it needs to be discussed in debian-policy...
<diwic> dholbach, so https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem <- is this documentation for merge-mode branches or not?
<persia> tumbleweed, please don't: it would be much prefeable to use another target (lots of folk seem to get get-current-source: )
<janimo> dholbach, nice :)
<persia> tumbleweed, It was, at length, and the semantics were changed from what you describe to what is currently in policy.
<tumbleweed> persia: right, yes, the correct way out of it is probably a new target with these semantics
<persia> tumbleweed, There's no policy against adding extra targets, and if enough people add them, it makes sense to add to policy :)
<dholbach> diwic, what do you mean by "merge-mode" branches? to me it seems the way to deal with source package branches of packages that have a patch system on top of it
<tumbleweed> persia: hah. in this case some coordination between svn, bzr, and any other VCS that needs this, would be great
<persia> dholbach, I believe it's ones that don't use pristine-tar, and just have debian/
<diwic> dholbach, well, I didn't know of that name either until yesterday, but that's when you have the debian/ in the bzr only, and the upstream source somewhere else
<persia> tumbleweed, I tend to focus on the devscripts implementations first, and then expect foo-buildpackage to conform to those semantics.
<tumbleweed> re modes: http://jameswestby.net/bzr/builddeb/user_manual/
<dholbach> aha
<dholbach> barry, james_w and jelmer probably know better about this - I'm afraid I haven't dealt with "merge-mode branches" a lot yet
<diwic> tumbleweed, aha, yet another useful link, thanks
<diwic> so maybe there is some documentation and I just didn't find it.
<dholbach> that sounds like something we can fix :)
<diwic> dholbach, maybe links to "Distributed Development" should say "Packaging with bazaar" instead, or both
<dholbach> diwic, gotcha - I added all the links to the bug report I mentioned above
<persia> diwic, The key to "Distributed Developement" is that it's more than just packaging with bzr: there's lots more components that are intended to make things scale better.  bzr is just a piece of it (although perhaps the most visible piece at the current stage)
<dholbach> micahg, do you know what's going on with bug 709216? :)
<ubottu> Launchpad bug 709216 in thunderbird (Ubuntu) "clicking on a link dont open the page " [Undecided,New] https://launchpad.net/bugs/709216
<lag> dholbach: Hey Daniel
<dholbach> hi lag
<lag> dholbach: Long time no see, how you been?
<dholbach> good good - how 'bout you?
<lag> Yeah not bad thanks
<lag> Do you know which channel would be best for libgpod questions?
<lag> Does anyone work on it @Canonical for instance?
<dholbach> lag, I guess #ubuntu-desktop
<dholbach> but I'm only guessing :)
<lag> I'll try them
<EtienneG_> kees, regarding the OO.org USN this morning, have there been reports of exploits in the wild?
<kees> EtienneG_: no, nothing. heap exploits are virtually unheard of due to glibc's defenses against it, but because of how they work, it's hard to really claim that they're all safe. in practice, I've only seen 1 heap overflow attack in the wild in the last 8 years.
* pitti changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<EtienneG_> kees, thanks for the info, and glad to hear that!  :)
<jdstrand> kenvandine: hey-- it looks like you sponsored the folks upload. is that to fix something for alpha2 images?
<micahg> jdstrand: archive was opened
<jdstrand> oh, I see that now
<kenvandine> jdstrand, no
<kenvandine>  :)
<jdstrand> micahg: thanks
<jdstrand> kenvandine: yes, nm :)
<marjo> ping apw
<kirkland_> apw: howdy;  i'm getting a kernel panic coming out of suspend *every time*;  this is new for natty, within the last 2-3 days
<apw> marjo, hi
<apw> kirkland_, lovely ... get a bug filed please... whats the ooops line
<apw> EIP specifically ?
<kirkland_> apw: shall i shoot a picture of the screen when it occurs?
<apw> kirkland_, definatly and add tyhat to the bug
<apw> and subscribe me, and post me the number too :
<apw> here :)
<kirkland_> apw: submitting bug now
<kirkland_> apw: will kill my machine again momentarily
<kirkland_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712625
<ubottu> Ubuntu bug 712625 in linux (Ubuntu) "panic on resume from suspend, everytime, thinkpad x201" [Undecided,New]
<kirkland_> apw: brb, killing my machine now
<kirkland_> apw: image uploading over crappy conference uplink...
<kirkland_> apw: standby;
<kirkland_> apw: done
<kirkland_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/712625/+attachment/1827461/+files/IMG_0867.JPG
<ubottu> Ubuntu bug 712625 in linux (Ubuntu) "panic on resume from suspend, everytime, thinkpad x201" [Undecided,New]
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bdmurray
<soren> qlist
<soren> whoops :)
<jelmer> hey soren, bitlbee user ? :)
<soren> jelmer: Busted :)
<soren> jelmer: Funny. I was wondering if you'd notice :)
<GunnarHj> cjwatson: Hi Colin,
<GunnarHj> cjwatson: Considering your comments at https://launchpad.net/bugs/666565, it would be great if you could spare a minute or two to act on the comment I posted earlier today.
<ubottu> Ubuntu bug 666565 in Ubuntu Translations ""utf8" charmap in locale name is wrong" [High,Triaged]
<jjardon> tkamppeter, Hello I was reading about https://www.linuxfoundation.org/collaborate/workgroups/openprinting/plan-completion-common-printing-dialog and I wonder if there is a bug open in GTK+ bugzilla about this
<slangasek> barry: ping
<broder> cjwatson: ping? i have a quick question about the automagical ntp stuff if you're still around
<ignarps> automagical ntp ?
<broder> i'm mostly trying to figure out how our /etc/network/if-up.d/ntpdate script will interact with a network that has a captive portal
<barry> slangasek: hi, sorry i was on a different desktop.  what's up?
<slangasek> barry: hi, just wondering if you know what the status is of documentation for dh_python2
<slangasek> I find "dh_python2 howto" doesn't work well as a google search term :/
<barry> slangasek: probably fairly poor ;).  i am planning on spending time on dh_python2 perhaps next week; i'd like to improve the docs
<slangasek> ok, cool
<kklimonda> barry: did you found out what's wrong with your emai? :)
<barry> kklimonda: i have not ;)  i'm going to investigate again later today
<slangasek> I ran into this when reviewing some packages of meego components; the original packaging was using python-central, I wanted to suggest dh_python2 instead and couldn't find references
<barry> slangasek: for simple packages, it's almost comical how simple it is
 * barry looks for an example
<slangasek> barry: right - I'm just left with the niggling doubt that I've overlooked something ;)
<barry> slangasek: with a good setup.py, a 3 line d/rules is all you need, though you can add a few extra lines for tests or such (i need to fix dh for those)
<barry> slangasek: http://bazaar.launchpad.net/~barry/flufl.i18n/i18n.deb/view/head:/debian/rules
<barry> slangasek: all you really need are lines 1, 6 and 7
<barry> slangasek: and even there, you don't strictly need --buildsystem python_distutils
<barry> slangasek: so line 7 can be: "dh $@ --with python2" and you're done
<barry> slangasek: (the --buildsystem python_distutils is needed if you have a Makefile though because dh isn't smart enough -- yet -- to recognize setup.py over Makefile)
<slangasek> barry: hmm, --buildsystem won't work in this case, the python bindings are a subset of the upstream source which uses autotools.  Will dh_python2 do anything sensible in this case?
<barry> slangasek: does "python setup.py install" DTRT?
<barry> slangasek: say, in a virtualenv?
<slangasek> ENOSETUP.PY
<barry> slangasek: ah, then i don't actually know ;).  give it a try and let me know, and i'm happy to help
<broder> dh_pysupport would basically go and hunt down any python modules installed anywhere. does dh_python2 not do the same?
<barry> broder: i haven't tried it with !setup.py
<slangasek> barry: tried it, get a package with /usr/share/pyshared/ContextKit/, /usr/lib/python2.7/dist-packages/ContextKit/, /usr/lib/python2.6/dist-packages/ContextKit/; a Python-Version: 2.6, 2.7 binary control field; a strange dependency on python (>= 2.7.1-0ubuntu2) (!?); and what look to be suitable pycompile invocations in maintainer scripts
<slangasek> pycompile+pyclean
<slangasek> why does dh_python2 guard its prerm check with 'if which pyclean'?
<barry> dunno.  fwiw, i have a branch that adds tests, cleans things up, and adds comments to explain things.  kind of languishing due to lack of time.  however, if you find problems/issues with dh_python2, you can file bugs and subscribe/assign me
<slangasek> ok, cheers :)
<slangasek> so the minimum python version is annotated in /usr/share/python/debpython/depends.py as "minimum version required for pycompile/pyclean"
<slangasek> which means the prerm check for pyclean should be dropped
<slangasek> and it should be run unconditionally, because depends aren't supposed to get removed before their rev-deps
 * slangasek will file bug
<JFo> Anyone know who owns the Bug Watch Updater?
<JFo> It seems to be going klepto on fixed bugs
<bdmurray> JFo: Launchpad does
<JFo> hmmm
<JFo> ok, thanks bdmurray
<slangasek> JFo: it should only be updating upstream tasks
<slangasek> to match the state of the remote bug tracker
<JFo> slangasek, bug 185025 is an example
<ubottu> Launchpad bug 185025 in linux-source-2.6.15 (Ubuntu) "Coolermaster Xcraft 360 USB drive fails" [Low,Fix released] https://launchpad.net/bugs/185025
<slangasek> JFo: yes; if you follow the link to the upstream bug tracker, is this not the same state?
<slangasek> maybe it just figured out how to import bug importances from the Linux tracker
<slangasek> or decided how to map them
<JFo> hmm
<JFo> I think the odd thing is that it has been fixed for 3 years
<JFo> and now the importance is being changed
<slangasek> yeah - it's no longer unknown, so the updater must've gotten smarter :)
<bdmurray> smarter is good
<JFo> indeed :)
<bryceh> no, a few weeks ago the updater went through and marked a ton of the freedesktop bugs as importance unknown from what it had been
<JFo> hmmm
<bryceh> my guess is they figured out and fixed whatever caused that, so the importances are getting re-added now
<bryceh> you might check if the bugs in question were upstreamed to freedesktop, or to some other tracker
<JFo> well, as long as it Does No Harm(tm) I can live with it :)
<bryceh> my mail box has been slammed all morning with the updates
<JFo> interesting
<JFo> I'll keep looking at it
<bryceh> yeah, been a simple matter of holding down the 'd' key longer than usual ;-)
<JFo> lol
<JFo> I am told it is because they fixed this bug https://bugs.launchpad.net/launchpad/+bug/707478
<ubottu> Ubuntu bug 707478 in Launchpad itself "Freedesktop bug watches are (incorrectly) updated with "importance unknown"" [Critical,Fix released]
<JFo> but that wouldn't explain the previous change
<bryceh> bingo
<JFo> or actually it would rather
<bryceh> yeah comment #9
<bryceh> JFo, thanks for digging that out, I was curious :-)
 * JFo spoke before reading
<JFo> so yeah, I think we may be good now
<JFo> :)
<JFo> no problem Tim was curious as well
<JFo> :)
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<barry> kklimonda: sending an edited summary now, while watching my postfix logs
<barry> kklimonda: 250 OK - should hit the list soon
<micahg> barry: got it :)
<barry> micahg: \o/
<lamont> there will be a brief, rolling blackout in the land of ppa builders.  just fyi
<ari-tczew> ogra: archive open, could you again have a look on merges?
<ogra> ari-tczew, tomorrow, its nearly 11pm here
<ogra> i didnt forget about you ;)
<ari-tczew> ogra: okok
<kirkland> apw: i backed down to the 2.6.37-11-generic kernel and i can suspend/resume again
<kirkland> apw: -12 is b0rked
<ari-tczew> barry: any news on pymca?
<barry> ari-tczew: yep. https://bugs.launchpad.net/ubuntu/+source/pymca/+bug/712136
<ubottu> Ubuntu bug 712136 in pymca (Ubuntu) "Please merge pymca 4.4.1p1-1 (universe) from debian unstable (main)" [Wishlist,New]
<barry> see comment #6
<ari-tczew> barry: many thanks!
<barry> ari-tczew: sure thing! how about giving me a nice endorsement here: https://wiki.ubuntu.com/BarryWarsaw/MyApplication
<barry> :)
<ari-tczew> barry: I'd like to more sponsor for you to give strong endorsement.
<barry> ari-tczew: you'll get sick of me prompting you about it eventually :)
<bj0> 4
<ari-tczew> barry: ATM I could say only that I've sponsored for you vala transition where were some issues and since these sponsors I have nothing else sponsored and I can't confirm that you don't make the same troubles.
<poolie> can anyone comment on https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/712812
<ubottu> Ubuntu bug 712812 in software-properties (Ubuntu) "gpg doesn't see the mandatory http proxy" [Undecided,New]
<poolie> ah, basically just the same as bug 443404
<ubottu> Launchpad bug 443404 in software-properties (Ubuntu) "gpg doesn't get the right proxy configuration" [Undecided,New] https://launchpad.net/bugs/443404
<hallyn> silly question - for natty cycle, can i request merges without a lp bug, or is an lp bug always required?
<hallyn> well, i guess i'll need a lp bug anyway for sru
#ubuntu-devel 2011-02-04
<bryceh> hallyn, it's not required to have a bug for merges
<bryceh> hallyn, generally you'd file a bug for a merge if you're seeking sponsorship
<Keybuk> ok, can anyone remember how ssh-agent/gnome-keyring/seahorse is supposed to work in Lucid? :-/
<maco> automagically?
<maco> seahorse-agent should cover both ssh & gpg -agent stuff iirc
<maco> (but seahorse-agent isnt api compatible with them so kmail falls over if its running instead of gpg-agent, but anyway...)
<Keybuk> maco: well, so I have seahorse agent
<Keybuk> but seahorse agent is only exporting GPG agent environment
<Keybuk> not SSH agent
<maco> that miiight be right... i dont have a .... hang on i might have a vm
<maco> i have a maverick vm
<Keybuk> so where does the ssh agent come from?
<maco> on my maverick it is running
<maco> but...wow maverick's confusing when you havent used gnome since hardy...
<maco> seahorse isnt in the menu anymore
<maco> ok i think seahorse just covers gpg
<maco> but it should offer to remember your ssh key passphrase for the rest of the session
<Keybuk> hmm
<Keybuk> right
<maco> gnome-search-tool? when did this replace beagle or tracker or whatever...  wah this is like when i tried to use windows after years of not using it!
<achiang> kubuntu user?
<maco> yep
<maco> i think i need to play with this vm a bit so next time i get a support call from my brother i know what's on his screen beyond "there's a menu at the top instead of bottom"
<achiang> you mean, "launcher on the side with big buttons" ;)
<maco> nah he sticks to lts
<maco> i dont have to worry about unity for another year with him. and then it can be "so they totally changed the UI around on you. wanna switch to the one i know how to use since you have to relearn anyway?!"
<achiang> ooh, sneaky
 * Keybuk blames Caesar
<maco> i found seahorse btw. its in system -> preferences now
<maco> Keybuk: who?
<maco> or was that metaphorical?
<Keybuk> maco: no, it was directed ;-)
<maco> discovery: the first thing that happens when i click on ubuntu software center is that i get a crash notification. shiny
<maco> (the computer with the vm has no network access, so no i'll not be sending a crash report)
<maco> (for all i know its fixed in an update anyway)
<maco> alpha 4...yeah probably fixed by now
<kklimonda> that's some old vm :)
<kklimonda> great, I've been wondering why I can't use keyboard to change the volume.. apparently PA died on me, and I can't revive it. Probably an indication I should restart my computer ;)
<lifeless> jcastro: ping
<achiang> let's say i've got a package whose control file was very simple: source package, binary package. now, i want to use the same source package to generate two binary packages, so i create an entry for foo and an entry for bar
<achiang> previously, i have files like dirs, install, postrm, postinst, prerm, etc.
<kklimonda> achiang: you rename them to (binary package name).dirs etc.
<achiang> must i create foo.dirs, bar.dirs ; foo.install, bar.install?
<achiang> what if there is some commonality?
<achiang> say dirs remains the same, but install should be different
<ari-tczew> barry: I suggest you for merge package nipy from Debian @universe. I could have a look on it then.
<achiang> can i just keep dirs, but then create foo.install and bar.install?
<kklimonda> achiang: no idea, but you can try doing that ans seeing what happens
<achiang> heh
<achiang> the less obvious files to me are compat, copyright, and this odd one named gconf-defaults
<achiang> i think those can remain as-is, right?
<achiang> i think compat and copyright should be fine, but gconf-defaults should be named foo.gconf-defaults
<kklimonda> gconf-defauls should be renamed so it's used for the binary package that ships gconf files, compat and copyright are not related to binary packages, so you don't have to rename them.
<achiang> kklimonda: thank you
<achiang> going back to previous conversation about splitting an existing source package into several binary packages... i've read through: http://wiki.debian.org/PkgSplit
<achiang> new question is, must i create a target in debian/rules for each binary i want to create and copy/paste all the dh_* commands for each target?
<achiang> seems rather anti-DRY
<ion> Iâd suggest using dh 7 and not copying a plethora of dh_* commands anywhere.
<micahg> achiang: no, dh7 should take care of that unless you need to override
<achiang> ah, i will go read about dh7, thank you ion and micahg
<persia> achiang, The conventional DRY way is to use rules.tiny and only vary from the defaults when using debhelper support files.
<ion> List binary packages in debian/control and for each package create debian/$PACKAGE.install to describe which files go into it.
<achiang> ion: right, that is what i did; maybe one complication is that say i have a config file that i want each binary package to install; after building the debs, i only see the config file present in the first binary package described in debian/control
<achiang> even though the config file is present in both foo.install and bar.install
<achiang> s/present/listed/
<persia> You want the same file to be produced by multiple packages, or the same content to be stored in multiple files in multiple packages?
<achiang> say the source package has "file.conf" ; debian/control has 2 binary package targets foo.deb and bar.deb ; i want file.conf to be installed into /etc/ when either foo.deb or bar.deb is installed
<achiang> (in my case, i know for sure that foo.deb and bar.deb are mutually exclusive; they'll *never* appear in the system together)
<persia> They'll have to Conflict:
<achiang> so i have been trying: echo file.conf /etc > foo.install ; echo file.conf / etc > bar.install
<persia> And that file exists at the root of the packaging directory?
<achiang> but after building, i see that only foo.deb delivers file.conf ; bar.deb is more or less empty (foo was the first target in debian/control)
<achiang> well, for this example, yes. i mean, in reality, i specify the full path to file.conf in [foo|bar].install
<persia> Full path?  It ought only take a relative path (but I'll presume that is what you meant)
<persia> Is the configuration file created by the build system, or just pulled from the source?
<achiang> just pulled from source (and yes, sorry, relative path)
<achiang> hm, changing debian/compat to say 7 (from 5) didn't really help
<persia> Ah, yes, seems that dh_install assumes that you don't want to install the same thing twice.  You can work around this by copying the configuration so that you have two relative paths, but that may be annoying.
<achiang> persia: which configuration?
<persia> Whatever configuration you want in both packages.
<persia> override_dh_auto_install:\n\tdh_auto_install\n\tinstall -m 644 -d ${DEST} ${FILE}
<achiang> hm, that is rather annoying. sorry i didn't say this earlier, but the entire point of this package is to install config files in various spots, and there are many of them; between foo.deb and bar.deb they are 95% similar, so that is a lot of repetition.
<persia> Commonly that's done with a -common package containing all the shared stuff.
<achiang> persia: ah! i could just create a third package in debian/control that contains the actual common stuff, then split out foo and bar appropriately
<persia> Indeed.  Then have the differing packages conflict, and both depend on the -common package.  That's how it's usually done.  If it's just one file, it seems heavyweight, but if it's 95% of the files, it's the better thing to do.
<achiang> persia: yes, thank you for the guidance. and i'll use #ubuntu-packaging for questions like this in the future. :)
<persia> Heh, that's why it's there :)
<chrisccoulson> slangasek, was you aware that yesterdays sqlite upload broke ABI?
<chrisccoulson> sqlite3_unlock_notify has gone
<slangasek> chrisccoulson: the 3.7.4-2ubuntu1 upload?
<chrisccoulson> slangasek, yeah, i just updated it now
<slangasek> chrisccoulson: updated as in uploaded?
<chrisccoulson> slangasek, sorry, i meant i just updated to the version you uploaded yesterday
<slangasek> ah
<chrisccoulson> slangasek, i only noticed because of this: http://launchpadlibrarian.net/63523237/buildlog_ubuntu-natty-i386.globalmenu-extension_0.3-0ubuntu1~pre1_FAILEDTOBUILD.txt.gz
<slangasek> it wasn't yesterday, though, it was only 2 hours ago
<chrisccoulson> so i just checked it locally too
<chrisccoulson> oh, yeah. it was yesterday my time ;)
 * chrisccoulson should get some sleep
<slangasek> heh :)
<slangasek> ok, looking to see what's going on here, because nothing in that should've been an ABI-changer
<chrisccoulson> thanks
<slangasek> I wonder if this is a cdbs behavior change
<slangasek> the bits that went missing are controlled by a define passed in DEB_OPT_FLAG
<chrisccoulson> slangasek, yeah, that's what i'm thinking. i just compared the 2 build logs and noticed that -DSQLITE_ENABLE_UNLOCK_NOTIFY is missing
<chrisccoulson> slangasek, oh, DEB_OPT_FLAGS doesn't seem to be used anywhere by cdbs :/
<slangasek>   * Deprecate DEB_OPT_FLAG (if ever used it should be done differently).
<slangasek> cdbs 0.4.90
<slangasek> works fine with previous cdbs, yay
<slangasek> chrisccoulson: thanks for letting me know; fixed sqlite3 uploaded
<chrisccoulson> slangasek, excellent, thanks for fixing it quickly too :)
<psusi> has anyone done any testing yet with uefi?  I finally got a new system that can do it but I can't figure out where to get a uefi shell and maybe other uefi applications and set them up
<charlie-tca> bug 712898 just filed for removing a group of packages with todays natty updates
<ubottu> Launchpad bug 712898 in update-manager "Updates removed many applications" [Undecided,New] https://launchpad.net/bugs/712898
<charlie-tca> seems to have taken over 20 applications
<persia> I'm not convinced that's an update-manager bug: I suspect it's a bug in the applications, or in one of the libraries upon which they depend.
<persia> If they all complain about python-gtk2, it's probably a problem with python-gtk2
<charlie-tca> how about python-gtk2
<charlie-tca> I just went by the debugging page for updates
<micahg> last update was weeks ago
<charlie-tca> it's not neccessarily python-gtk2, but it is python related
<persia> Finding the actual problem is a matter of running down the chain of "but it is not going to be installed" until you end up with some sensible reason why you can't install something.
<persia> I suspect there's some library that had an incomplete transition, and some conflicts that cannot be resolved currently.
<JanC> charlie-tca / persia : I _thought_ it was related to python-gobject (saw it too an hour ago or so)
<persia> Could well be
 * persia is trying to sort out git trees, and hasn't looked into this at all
<micahg> ah, in that case, I think there might be a bug already
<micahg> bug 712734
<ubottu> Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734
<micahg> err, maybe not
<charlie-tca> nope
<charlie-tca> that is just something with python2.6 installing
<charlie-tca> I hope it was okay to post that here. Normally I will not do that, but the weekend is coming fast...
<persia> -bugs would have gotten a similar response, I think :)
<kklimonda> I get an even weirder error on apt-get upgrade: abrowser : Depends: abrowser-branding (= 4.0~b10+build1+nobinonly-0ubuntu2)
<micahg> kklimonda: that's not so weird
<kklimonda> micahg: I don't really remember installing it
<micahg> kklimonda: if firefox was removed like charlie-tca had, it might have tried to install abrowser to fix deps
<kklimonda> micahg: ah.. that makes sense
<charlie-tca> I can't another bug, but now I am wondering how many will get filed for each application when someone finds it missing
<kklimonda> charlie-tca: there is still a whole day to fix it :)
<charlie-tca> yup
<kklimonda> it does seem to be related to bug 712734
<ubottu> Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734
<kklimonda> just as micahg was saying
<charlie-tca> but I got another person in #ubuntu+1 with the same thing already
<wildfire> I'm uploading to a ppa (lp.net/~wildfire/+archive/yate) - and the first email I had back indicated an error (I uploaded a binary rather than source) but my subsequent uploads have not resulted in any email back at all. Any hints on what to do next?
<jfer> jono, i sent you an email about acire. will it be included in natty?
<persia> wildfire, You might ask the team in #launchpad
<TheMuso> Yeah I just went to update and saw heeps of packages wanting to be removed. I just ran a regular upgrade, and am willing to have packages held back, whic were only a handfull, python-gobject* being one of them.
<TheMuso> Ok, python-gtk2 depends on python2.6-gobject, which doesn't exist.
<TheMuso> So I and there might be more packages in the same position.
<didrocks> good morning
<pitti> Good morning
 * bryceh waves
<micahg> pitti: a few people were running into bug 712734 last night
<ubottu> Launchpad bug 712734 in pygobject (Ubuntu) "Natty-alfa2 pygobject has incorrect dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/712734
<pitti> just saw it
<micahg> pitti: have a good day :)
<pitti> seems this kind of forces us to bring back python2.6 on the CDs, unless we drop 2.6 support completely
<micahg> pitti: discussion on ubuntu-devel about dropping it completely
<pitti> I'll re-add py26 support for now to fix the archive, and then investigate more closely
<persia> pitti, Is it not possible to just ensure that nothing actually on the CD requires python-2.6, and let it be pulled by updates if (and only if) required?
<pitti> persia: not with the way we currently package python apps
<pitti> python-foo has the extensions for all supported versions
<persia> Oh, right.
<pitti> and recently pygobject just started to use functions from libpython
<pitti> there isn't much that I can do about it
<pitti> I'll check it more closely later on, but I suppose it's necessary
<persia> Indeed.  I seem to recall having separate versioned python packages at one point, but in some ways it is good that this is no longer the case.
<broder> yeah, an early version of the python policy involved doing that
<pitti> persia: rebuilds for all pacakges are still required, but it avoids tons of binary NEWing/removing old packages
<persia> Right.
<rigved> hi everyone...i'm interested in kernel programming...can anyone guide as to where should i start
<dholbach> good morning
<diwic> rigved, for general helping out JFo might help you out in #ubuntu-kernel (once he's awake), for actual development reading the "Linux Device Drivers" book (available online, I believe) can be a good start. Or; find something that needs fixing and try to fix it.
<diwic> rigved, http://lwn.net/Kernel/LDD3/
<rigved> diwic: hmmm...ok...thanks for your help
<\sh> hmm..are there any archives of isoimages from non supported releases somewhere? I need a jaunty iso ;)
<\sh> jaunty server to be more precise
<\sh> ah got them
<persia> old-releases?
<Tm_T> http://old-releases.ubuntu.com/releases/
<\sh> persia: Tm_T: yepp found it
<Tm_T> goodie
<\sh> grmpf..debugging regressions is time consuming
<persia> Some stuff gets lost though: it's tricky to find a feisty Ubuntu Desktop/powerpc CD these days
<\sh> do we also have old-archive.ubuntu.com? ,-)
<Tm_T> we do
<persia> http://old-releases.ubuntu.com/ubuntu/
<\sh> very good
<soren> persia: I think Kees' CD collection is pretty complete, if you actually need it.
<persia> soren, I don't believe anything that is not available on old-releases.ubuntu.com/releases was ever formally pressed in a way that would qualify for that collection.
<soren> persia: Oh, ok :(
<soren> :), I mean.
<soren> Darned keymap.
<chrisccoulson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson
<cjwatson> janimo: could you check bug 712859, please?  It looks unclear to me - the Debian side drops -march=armv4t -mno-thumb-interwork, but I don't know whether the compiler defaults are then sufficient
<ubottu> Launchpad bug 712859 in libv8 (Ubuntu) "Sync libv8 2.5.9.9-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/712859
<janimo> cjwatson, I'll look
<cjwatson> thanks
<c2tarun> chrisccoulson: ping
<chrisccoulson> hi c2tarun
<c2tarun> hi chrisccoulson
<c2tarun> you looking at that bug?
<chrisccoulson> c2tarun, yeah
<c2tarun> chrisccoulson: thanks :) i am right here, just tell me about any error, i'll try to remove it.
<chrisccoulson> thanks
<janimo> cjwatson, looks safe, they removed the two flags that were not ok for us. In the case there is a new error I can fix it after sync
<cjwatson> janimo: ok
<cjwatson> thanks
<chrisccoulson> c2tarun, i see you dropped debian/patches/01-sigc_namespace.patch from bibshelf, saying that it has been merged upstream, but are you sure that's the case?
<chrisccoulson> c2tarun, your new source package contains debian/patches/debian-changes-1.6.0-0ubuntu1, which has the same contents as the patch you dropped
<chrisccoulson> and the changes aren't in the upstream source
<chrisccoulson> it looks like you deleted the original patch whilst it was applied, thinking that the changes existed in the upstream source ;)
<Laney> 3.0 (quilt) yay!
<pitti> I actually find it more disturbing that they are applied by default, in the lp:ubuntu/pkg branches
<persia> I thought applied-by-default was the preferred presentation format these days, after heaps of complaints about confusion related to unpacked source not matching built source.
<pitti> well, but having that in bzr completely breaks e. g. merge-upstream
<pitti> you need to unapply before m-u, but then you can't do m-u because you have uncommitted changes
<tumbleweed> I think it makes sense for bigger more complex packages, but less so for simple ones
<pitti> so you need to unapply, commit, m-u, update patches, re-apply, commit again
<tumbleweed> what's also confiusing (to newbies) is that src format 1.0 quilt packages don't have them applied but 3.0 (quilt) do
<c2tarun> chrisccoulson: ping
<chrisccoulson> hi c2tarun
<cjwatson> pitti: you ought to be able to use m-u --force
<cjwatson> if that doesn't work, I'd say it's a bug in m-u; it works with plain merge
<c2tarun> hi chrisccoulson, I actually copied the debian folder from the older version, how can it be not possible that patches are not applied?
<cjwatson>   --force               Merge even if the destination tree has uncommitted
<cjwatson>                         changes.
<persia> pitti, I'm not sure that's not a tool issue: a merge ought merge smoothly, and then a rebuild ought rebase the patches reported so they go away.
<ricotz> cjwatson,  hi, could you restart this build? https://launchpad.net/ubuntu/+source/totem-pl-parser/2.32.2-1 -- it builds fine in natty pbuilder now
<bigon> http://launchpadlibrarian.net/63538845/buildlog_ubuntu-natty-amd64.empathy_2.91.6.1-1~ppa11.04%2B1_FAILEDTOBUILD.txt.gz << why doesn't it find the dep, the dep is available in the gnome3 ppa and this ppa is linked with
<pitti> persia: well, in the end it is
<chrisccoulson> c2tarun, i'm not entirely sure what you did. i'm just pointing out that the patch you dropped hasn't yet been merged upstream ;)
<pitti> persia: conceptually it's really wrong to have debian/patches/* files when everything else is in revision control
<c2tarun> chrisccoulson: can I PM you ?
<pitti> persia: i. e. what we really need is loom, or "pipelines" as they seem to be called today
<cjwatson> ricotz: no, it's not going to work, libquvi is in universe and totem-pl-parser is in main.  needs an MIR
<persia> pitti, Well, if one is going to use bzr for everything, one ought put things in 3.0 (bzr).
<chrisccoulson> c2tarun, sure
<cjwatson> persia: I wrote 3.0 (bzr) and even I don't really advocate it :)
<cjwatson> it was an experiment, mostly for parity with 3.0 (git)
<pitti> cjwatson: i. e. unapply, mu, and rebase patches all in one commit? I guess that's what it comes down to then
<ricotz> cjwatson, ok, i see
<persia> cjwatson, The feedback I received from some bzr folk last month was that it ought be reimplemented if it was to be adopted.  I don't consider this reflection on your work, but rather emerging understanding of methods of representation.
<cjwatson> sure, I wrote it eons ago :)
<pitti> cjwatson: (and then hoping that you don't screw up while rebasing the patches and have to start over :) )
<cjwatson> pitti: that's what I do, albeit with merge
<cjwatson> I agree it could use better tooling
<cjwatson> persia: we talked about it at debconf - I think the consensus there was that it was an interesting experiment but basically an upside-down model.  (I forget the details of that argument though.)
<persia> I suspect it's worthy of future discussion, but I think it's not worth it until parallel import is implemented in bzr: otherwise it's too hard to sensibly reconcile data from tarballs.
<cjwatson> also shallow history would make a big difference to how sane it is
<jcastro> lifeless: pong
<ari-tczew> chrisccoulson: around?
<chrisccoulson> ari-tczew, yes
<ari-tczew> chrisccoulson: could you upload this one? bug 708401
<ubottu> Launchpad bug 708401 in gedit (Ubuntu) "Merge gedit 2.30.4-2 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/708401
<chrisccoulson> ari-tczew, in a bit, i'm looking at something else right now
<ari-tczew> chrisccoulson: Understood.
<hallyn> all right my archive seems pretty messed up.  I can't get past warnings about xorg packages.  it wants me to apt-get update -f, but that doesn't work either.  so i'm quite stuck.  how do i tell it to go bugger off and just install new packages?
<cjwatson> hallyn: it'd be easier if we could see literal error messages
<cjwatson> I don't believe that it means 'apt-get update -f'.  Perhaps 'apt-get dist-upgrade -f'
<hallyn> done that, bunch of times.  i'll pb
<hallyn> cjwatson: actually maybe i'tll go better this time.  yesterday it would break.  this morning it kept downloading google-chrome .deb over and over (as file 1, file 2, file 3, etc ) now it's actually downloading files.  i nuked my apt-cache-ng archive, so it's in desparation, so it's going to go slow.
<hallyn> https://pastebin.canonical.com/42878/
<cjwatson> I suspect those drivers need to be rebuilt against the current server ABI
<cjwatson> they probably didn't get picked up by the mega rebuild we did earlier, since they've been demoted to universe
<cjwatson> hm, no, that isn't so
<cjwatson> RAOF: might be worth going through 'grep-aptavail -FDepends xorg-video-abi-8.0' for more stuff to rebuild?
<cjwatson> not sure that's hallyn's problem though.
<cjwatson> hallyn: so what does 'apt-get -f install' say?
<cjwatson> (no other args)
<dobey> hey all, anyone around to discuss a probable automake bug? i'd like to discuss to determine if it's a bug to be fixed in automake, or just some annoying behavior i have to figure out an insane workaround for
<mdeslaur> pitti: any idea what could cause bug #713115? I don't know where to start looking...
<ubottu> Launchpad bug 713115 in virt-manager (Ubuntu) "[natty] virt-manager no longer starts with recent updates" [Undecided,New] https://launchpad.net/bugs/713115
<mdeslaur> pitti: something changed with the recent pygobject
<pitti> looking
<pitti> mdeslaur: doesn't ring a bell right now, I'll try to reproduce
<pitti> mdeslaur: does this happen right at program start?
<mdeslaur> pitti: yes
<mdeslaur> pitti: launch virt-manager with --debug
<pitti> ah, can reproduce
<pitti> mdeslaur: still busy with something else, but I'll have a look later on then
<mdeslaur> pitti: thanks a bunch :)
<hallyn> cjwatson: it's possible that corrupt apt-cacher cache was my problem.  i nuked that, and nuked /var/cache/apt/archive as well, and apt-get -f install looked better.  However, as I'm on 3G right now, and am trying to also get work done, I had to cancel the upgrade for now.  I don't know if it'll succeed after d/l everything, but it's looking better than it was before
<sconklin-gone> pitti: when it's convenient for you, could you please copy the mvl-dove kernel and meta packages from our PPA to -proposed?
<cjwatson> hallyn: *nod*
<pitti> sconklin-gone: for maverick, lucid, or both?
<pitti> sconklin-gone: I think wrt. lucid -proposed is by and large unfrozen again, just not -updates
<sconklin> pitti: for both please
<pitti> sconklin: are there any -dove specific patches in there? (before I start trawling through all the bugs which were just merged from linux)
<dobey> eh, found a workaround that doesn't involve patching automake or vala, but is a bit nasty. :-/
<dobey> nevermind then
<sconklin> pitti: tgardner prepped those, I don't know
<pitti> sconklin: ok, I'll check then
<sconklin> sorry
 * jdstrand finds it curious that he has a defunct metacity process when he is using compiz...
<sconklin> pitti: if lucid -proposed is unfrozen, then those packages from our ppa can go as well
<sconklin> beware that there is one higher version of a meta package sitting in there I think
<pitti> sconklin: https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=lucid -> all of those?
<sconklin> pitti: ack
<ari-tczew> chrisccoulson: when you have done gedit would be nice to have a look on bug 420387 as well
<ubottu> Launchpad bug 420387 in bittornado (Ubuntu) "[PATCH] DeprecationWarning: the sha module is deprecated; use the hashlib module instead" [Undecided,Confirmed] https://launchpad.net/bugs/420387
<pitti> sconklin: The -meta packages don't actually build depend on the kernel API, right? what keeps me wondering is how a diff like http://launchpadlibrarian.net/63502545/linux-meta-mvl-dove_2.6.32.410.2_2.6.32.414.4.diff.gz (i. e. no changes) can ever actually bump the dependencies to the current ABI if it gets uploaded at the same time as the actual kernel
<pitti> sconklin: does *-meta take the ABI from the version number in debian/changelog?
<sconklin> if you mean does the meta package take the ABI from the kernel package, no. The version is manually changed in the meta package changelog by someone when required by an ABI bump in the kernel package
<pitti> sconklin: ah, so it does parse the changelog
<pitti> linux-meta-mvl-dove (2.6.32.414.4)
<sconklin> yes
<pitti> sconklin: i. e. it strips off the .4, and turns that into 2.6.32-414?
<pitti> sconklin: ah, thanks; I was always wondering whether I need to wait with accepting -meta until the actual kernel has built
<sconklin> pitti: I assume so based on the fact that the only place we change a version is in the changelog
<pitti> that would have brought a lot of speedup for the old-style "accept from -proposed" workflow
<persia> The worry is that if there is a publisher run, the -meta update is uninstallable until the kernel binaries are published.
<sconklin> I have never had to dig into the meta package makefiles, so I'm not very familiar with them
<pitti> sconklin: hm, the current -29.57 upload changelog refers to bug 705565
<ubottu> Launchpad bug 705565 in linux (Ubuntu) "linux: 2.6.32-28.56 -proposed tracker" [Undecided,Incomplete] https://launchpad.net/bugs/705565
<pitti>  that's a bit confusing
<sconklin> looking
<pitti> ah, it's built with -v and two changelogs
<pitti> so it's kind of obsolete
<pitti> bug updated
<pitti> sconklin: I think Jeremy should update his overzealous "please confirm with upstream kernel" auto bug replies to not cover trackign bugs :)
<sconklin> pitti: we've discussed this, and a change is coming soon ;-)
<pitti> sconklin: mvl-dove uses the same tracking bug 712610  for lucid and maverick; was that intended?
<ubottu> Launchpad bug 712610 in linux-mvl-dove (Ubuntu Maverick) "linux-mvl-dove:2.6.32-214.30 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/712610
<sconklin> pitti: that's not normally the way we do it. I'll make sure our documentation is complete on that and make sure Tim knows for next time. For this time we can probably just deal with it
<pitti> *nod*
<sconklin> thanks for noticing. It will probably break our status display
<pitti> sconklin: I think I caught everything now; please let me know if something is still missing in 2 hours
<sconklin> pitti: thanks!
<pitti> sconklin: (your status display complains then?)
<sconklin> our status display just lists kernels by series and then whether the tracking bug is set to verified. So the information for those two series will be conflated in the display
<pitti> sconklin: ah, you don't have something that shows newer packages in your PPA?
<pitti> that should ideally be empty now
<sconklin> pitti: I've been writing that tool yesterday and today
<pitti> actually, now that you use launchpadlib this should already be updated, as lplib doesn't depend on the publisher
<sconklin> we're not using lplib yet - I've been putting all that new functionality into our tools module base classes
<sconklin> https://kernel-tools.canonical.com/srus.html
<sconklin> There's the display, but it still doesn't show lucid because the cron jobs haven't run yet.
<sconklin> and I think that it currently does not show arm anyway - that's another thing on my list
<jdstrand> pitti: hi! not sure if you've seen this but bug #713115 and bug #713135 have been filed. downgrading to pygobject 2.27.0+git20110108-0ubuntu1 fixes the issue. meld is also affected (and I don't know what else)
<ubottu> Launchpad bug 713115 in pygobject (Ubuntu Natty) "[natty] virt-manager no longer starts with recent updates" [High,In progress] https://launchpad.net/bugs/713115
<ubottu> Bug 713135 on http://launchpad.net/bugs/713135 is private
<jdstrand> meh
<pitti> jdstrand: yep, currenlty debugging 713115
<pitti> jdstrand: feel free to make 35 a dupe of 15
<jdstrand> pitti: ok, I unprivated bug #713135
<ubottu> Launchpad bug 713135 in hamster-applet (Ubuntu) "hamster-applet crashed with OperationalError in execute(): no such module: fts3" [Undecided,New] https://launchpad.net/bugs/713135
<jdstrand> pitti: ack
<pitti> ah, so that one isn't virt-manager
<jdstrand> pitti: no. virt-manager, hamster and meld I know are affected, with downgrading fixing it
<pitti> OperationalError: no such module: fts3
 * jdstrand nods
<pitti> that doesn't look at all like the segfault that virtmanager gets, though?
<jdstrand> no, it doesn't, but again, if I downgrade it works
<jdstrand> pitti: meld has yet a different error
<pitti> ah, bisected the fix for virt-manager
<pitti> meh, I was afraid of that
<pitti> it fixed reference leaks
<pitti> but that uncovered tons of bugs in GTK
<pitti> so if I revert the reference leak fix, it'll probably work again, but we'll keep the mem leaks forever
<jdstrand> the hamster line in question is: self.execute("""CREATE VIRTUAL TABLE fact_index USING fts3(id, name, category, description, tag)""")
<jdstrand> I see
<jdstrand> so, I'll file the meld one then too
<pitti> I'll check first if (a) this is the reason for hamster-applet as well, and then check if i can fix it in GTK rather
<jdstrand> and undupe the hamster one
<pitti> jdstrand: hm, does the applet work for you if you just start it with
<pitti> /usr/lib/hamster-applet/hamster-applet
<pitti> ?
<pitti> it doesn't crash here (with the downgraded pygobject)
<pitti> but doesn't do anything eiterh
<seb128> pitti, well applet you need to run on the command line and then add to gnome-panel in the ui
<seb128> it will use the running instance
<pitti> ah
<jdstrand> pitti: maybe try hamster-time-tracker
<jdstrand> that will launch a non-panelized hamster
<pitti> crashes with a dbus error
<pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.534 was not provided by any .service files
<jdstrand> maybe that worked here because the panel applet was already running
<jdstrand> I see in the desktop file: /usr/lib/hamster-applet/hamster-applet -s over
<pitti> searching for "hamster" in the applet list doesn't bring up anything
<pitti> jdstrand: already tried that
<pitti> I'm under standard gnome now
<jdstrand> pitti: I think it is Time Tracker
<seb128> pitti, try to send a sigHUP to gnome-panel or restart it
<seb128> or maybe what jdstrand said rather
<jdstrand> pitti: yes, that's it
 * pitti tries restarting panel
<pitti> ah, that helped
<pitti> except that it's still crashing :/
<jdstrand> pitti: I needed to restart my session after downgrading to have hamster work
<pitti> aah - /var/crash/_usr_bin_hamster-service.1000.crash
<pitti>  OperationalError: duplicate column name: search_name
<jdstrand> presumably because there is hamster-service and hamster-applet that are running, and I only managed to restart one of them
<pitti> did that actually ever work?
<jdstrand> pitti: I use it every day. it is an integral piece of my daily work flow
<bigon> anybody understand why it doesn't find the dep? http://launchpadlibrarian.net/63550283/buildlog_ubuntu-natty-i386.empathy_2.91.6.1-1~ppa11.04%2B1_FAILEDTOBUILD.txt.gz it's linked to the GNOME3 ppa with nautilus 1:2.91.7-0ubuntu1~build1
<pitti> $ /usr/bin/hamster-service
<pitti> sqlite3.OperationalError: no such module: fts3
<pitti> ah, I think I get closer now
<pitti> jdstrand: I think what you saw just bounced the backend exceptino back to the client through dbus
<jdstrand> k
<pitti> jdstrand: but it doesn't work with the old pygobject eitehr
<jdstrand> pitti: well, I downgraded, restarted my session, and I am using it as we speak
<jdstrand> pitti: I promise I am not lying :)
<pitti> of course not, just trying to reproduce
 * jdstrand was just kidding
<jdstrand> pitti: these are what I downgraded- python-gobject python-gobject-cairo python-gobject-dev
<jdstrand> and with the exception of bzrtools (unrelated- just floated in), I am fully up to date
<pitti> ah, perhaps cairo, too
<RoAkSoAx> Anyone know if *.tar.xz tarballs are accepted in the archives?
<pitti> jdstrand: bug updated with a question for you (let's keep it there to have a better debug record)
<pitti> jdstrand: I'll check virt-manager in the meantime; can you please sub me to the meld bug?
<jdstrand> pitti: sure, filing it now
<geser> bigon: probably because of "Conflicts: libnautilus2-2, libnautilus2-dev, nautilus-sendto" from nautilus (from the gnome3 PPA)
<shadeslayer> RoAkSoAx: afaik no
<shadeslayer> but if they are .... lemme know .. i'd like to use them for Project Neon
<jdstrand> pitti: subscribed you to bug 713172 (meld)
<ubottu> Bug 713172 on http://launchpad.net/bugs/713172 is private
<RoAkSoAx> shadeslayer: i know PPA's don't. Not sure about official archives
<shadeslayer> ah ..
<shadeslayer> we use PPA's ... so thats out of the question then :P
<RoAkSoAx> shadeslayer: you might wanna ping someone from LP and ask for the support though
<shadeslayer> alrighty :)
<bigon> geser: yeah just saw it, I'm an idiot
<bigon> thx :)
 * bigon is still not sure why the Conflicts
<RoAkSoAx> jdstrand pitti Do Ubuntu archives support .tar.xz tarballs?
<pitti> I don't know
<RoAkSoAx> pitti: who do you think I might now :)?
<pitti> just try to upload to a PPA?
<RoAkSoAx> pitti: PPA's don't
<pitti> RoAkSoAx: the soyuz guys
<pitti> (sorry, in meeting)
<jmarsden> RoAkSoAx: Didn't bigjools just tell you "no" in #ubuntu-server ?
<RoAkSoAx> jmarsden: sry wasn't paying attention ther :)
<pitti> jdstrand: hm, so hamster is a miracle to me
<jdstrand> pitti: I responded to your question in the bug
<pitti> jdstrand: me too again
<jdstrand> pitti: on it
* Compositor changed the topic of #ubuntu-devel to: poop
<pitti> chrisccoulson: meh ^ can you please do @pilot in again to fix it?
<pitti> oh, hang on
<pitti> I'll fix it
<chrisccoulson> oh, what happened?
<pitti> IRC vanalism
* pitti changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson
* Compositor changed the topic of #ubuntu-devel to: Monster Quest the Curse of the Monkeyman airs Saturday February 12 11/10 Central only @TheHistoryChannel.
<ogra> could someone ban him ?
* ogra changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson
<ogra> thanks Pici
<Pici> ogra: np
<cjwatson> I'd have banned him the first time but didn't think it was worth it since he'd already left ...
<smoser> cjwatson, i seem to be unable to get the 'shift' key passed through to kvm (or something else is wrong), and thus, i can't get to a grub menu on boot
<smoser> do you have suggestion? reading grub.cfg it looks to me like i might have 3 seconds of 'sleep --interruptable', but i'm not sure how to interupt that either.
<pitti> smoser: did you try with grabbing keyboard/mouse (ctrl+alt)?
<smoser> maybe i'm just not fast enough
<smoser> i do get the it grabbed. but maybe its something else, as i'm working off a uec-image that might for some reason be slightly different.
<cjwatson> smoser: I've never been able to.  I think it's a kvm bug
<SpamapS> Hmm.. interesting conundrum ... since we disable insserv .. any package from Debian that uses insserv overrides to affect the boot introduces a boot ordering bug...
<SpamapS> for instance, bug #652433
<ubottu> Launchpad bug 652433 in krb5 (Ubuntu) "Init script dependency error: krb5-kdc starts before slapd" [Wishlist,Opinion] https://launchpad.net/bugs/652433
<cjwatson> smoser: personally I turn off GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET in kvm, but I appreciate that this is awkward if you can't even get that far
<smoser> so just comment those out ?
<cjwatson> you won't have three seconds of 'sleep --interruptible', no - that's a case that isn't used
<cjwatson> comment the first out, change the second to =false
<smoser> danke
<smoser> next question, then... can i do that in a uec build ?
<smoser> and not be prompted on a grub upgrade?
<smoser> i seem to remember some issues with me changing defaults and being prompted on grub upgrade (i can search for more info from logs if i'm not clear enough)
<cjwatson> it might depend on the exact way you disable it - you should definitely test
<cjwatson> I don't honestly know off the top of my head
<smoser> :)
<smoser> fair enough. thanks.
<smoser> and also, since we're here, GRUB_GFXMODE=text is reasonable ?
<cjwatson> smoser: GRUB_TERMINAL=console would be more usual, if you just want to not use the graphical terminal
<smoser> thanks.
<jdstrand> pitti: applying your pygobject patch made meld and hamster work again
<pitti> jdstrand: ok, as I suspected; thanks
<pitti> not that it would help much yet, except to confirm that we have this bad workaround
<pitti> but thanks a lot for testing
<pitti> jdstrand: I can perfectly reproduce virt-manager and meld, but still not hamster, though
<jdstrand> pitti: sure, np
<jdstrand> pitti: well, if you get those fixed via an underlying library, I'm more than happy to test hamster
<kees> soren, persia: only missing 2 CD, to my knowledge.
<kees> *CDs
<pitti> jdstrand, kenvandine: ok, will upload the workaround, to keep things working, and test against upstream to replicate the crashes
<seb128> is there a way to read from a C program running a system service the input from a device?
<seb128> got asked by someone who try to get a usb barcode reader working, the thing seems to be seen as a standard input
<seb128> i.e chars got printed on the command line when the reader reads something while being on a vt
<kenvandine> pitti, thx
<stgraber> seb128: you should be able to get that by reading /dev/input/<something>
<stgraber> seb128: for example on my laptop: /dev/input/by-path/platform-i8042-serio-0-event-kbd
<stgraber> seb128: for the keyboard, though there might be cleaner ways of doing it ;)
<seb128> stgraber, right, but it seems to give you non decoded input
<seb128> stgraber, i.e if you do it on your keyboard you will not get what you type
<stgraber> seb128: indeed. I don't know of any /dev/<something> device that gives you the decoded output, so you may have to do the decoding yourself ...
<stgraber> I'm guessing that what we see is essentially keycodes, so using the US keymap (or similar) it should be possible to get the ASCII value
<seb128> one way to get it work would be to get the box to autologin, run the code and read stdin
<seb128> but that's not really elegant
<seb128> would work though since the computer has that as only task, reading from this usb reader and doing what the code tells it
<soren> kees: Which ones?
<kees> soren: 7.04 Feisty Fawn Edubuntu i386 http://commons.wikimedia.org/wiki/File:Edubuntu_7.04.jpg
<kees> soren: 4.10 Warty Warthog Ubuntu amd64
<kees> soren: 5.04 Hoary Hedgehog Ubuntu amd64
<kees> but I haven't confirmed that the last two even exist
<kees> soren: and if this isn't a hand-made CD, http://commons.wikimedia.org/wiki/File:Kubuntu_6.06_CD.jpg I need the entire 6.06.1 set
<soren> kees: Looks pretty convincing if it is.
<kees> soren: yeah. :(
<kees> soren: but I can not find anyone who has ever seen those.
<kees> so, I'm almost certain Hoary came with amd64. dunno about warty.
<kees> but maybe breezy was the first with amd64 CDs
<soren> kees: http://ubuntuforums.org/showthread.php?t=233444
<soren> kees: Specifically, "Shipit will be updated within approximately the next month with Ubuntu
<soren> 6.06.1 LTS."
<soren> kees: It seems legit.
<stgraber> seb128: I did a quick test writting modifying the code of evtest and it seems quite easy to use that to decode whatever is being typed on any /dev/input/* device
<seb128> stgraber, ok thanks, I found some examples of code decoding the input stream as well
<kees> soren: aaargh, now I'm even further behind. :)
<stgraber> seb128: apt-get install logkeys
<seb128> stgraber, thanks
<stgraber> seb128: though if you need 64bit, you'll need a new upstream version (http://logkeys.googlecode.com/files/logkeys-0.1.1a.tar.gz)
<stgraber> you can give it an input device and it'll log in a file, should be simple enough to interface wiht that
<seb128> right
<cjwatson> kees: Warty had amd64, but only for the install CD (today's "alternate").  Hoary had amd64 across the board.
<kees> cjwatson: that's what I feared. :)
 * kees needs to visit London to get the missing CDs. :)
<achiang> can anyone answer a germinate question? if i create a STRUCTURE file that "overrides" a seed, what is the behavior? does my statement replace the prior one? or is there multiple inheritance?
<achiang> for instance, i say: standard: my-new-minimal-seed
<achiang> will the standard seed then only be based on my-new-minimal-seed, or will it be a combo of both minimal and my-new-minimal-seed ?
<achiang> my theory is that "last statement wins, no multiple inheritance"
<chrisccoulson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<jdstrand> seb128: hey, have you seen how strange evolution is with unity-2d?
<alexbligh> I'm making a package using dh_make (not pbuilder). How do I specify that I want a file to be owned by something other than root?
<lifeless> jcastro: see mail
<seb128> jdstrand, no
<nxvl> stgraber: ping
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bryceh
<ohsix> what's a pilot? standby guy that's gonna be around for a bit?
<bryceh> patch sponsor
<chrisccoulson> ohsix, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots
<stgraber> nxvl: pong
<nxvl> stgraber: is there any easy howto for LTSP
<nxvl> stgraber: a friend of mine wants to use it for a call center and asked me for help
<nxvl> stgraber: but i've no idea
<stgraber> nxvl: https://help.ubuntu.com/community/UbuntuLTSP would be a good start. Installation is usually as simple as having a machine with two NICs and using the LTSP option of the alternate CD
<stgraber> nxvl: depending on how powerful the clients are, your friend might want to run some software locally, for that look at the documentation for "localapps". It's basically about installing the extra software in the chroot and recompressing it
<nxvl> stgraber: so, basically it works out of the box with the alternate installer?
<stgraber> yep, just find a server with two NICs, on the CD boot menu, press F4 et choose LTSP
<stgraber> then at install time, choose the NIC that's connected to the internet, the other will be setup as the LTSP interface and a DHCP server will be started on it
<nxvl> stgraber: the clients only need an asterisk client
<nxvl> stgraber: and that's it
<nxvl> stgraber: ok, thanks for the info, will take a look
<stgraber> ok, so you'll probably want to install twinkle or something like that in the chroot then: https://wiki.ubuntu.com/LTSPLocalAppSetup
<stgraber> let me know if you have any problem with it, but usually getting the server running is very easy
<nxvl> stgraber: sure, will let you know, thanks for the info!
<cjwatson> achiang: your theory is correct - last entry for a given name in STRUCTURE wins
<achiang> cjwatson: thank you
<bobg> i am trying to find where policy is defined for upstart -- i.e. should you use /etc/defaults/mypackage, how should you allow your service to be disabled (not started at startup). anyone know?
<soreau> Hello, I have an AR5008 (pci atheros chip) that uses the ath9k driver. All had been working fine up until 2.6.35 kernels. Now, the monitor function of the card gets stuck in channel -1 and you must build/install a patched compat-wireless. While this fixes the faulty channel issue, it also introduces kernel panics soon after connecting to an ap with managed mode. How can I find more information about this?
<broder> bobg: with upstart, the recommended way to do that is to tell the admin to just comment out the "start on" line
<soreau> Specifically, I want to make sure this problem gets fixed upstream but I don't know where to find whoever works on ath9k and related mac80211 drivers
<debfx> bryceh: could you please sponsor the debdiff for maverick-proposed on bug #400851
<ubottu> Launchpad bug 400851 in kdesudo (Ubuntu Maverick) "kdesudo fails with non-ascii passwords" [Medium,Triaged] https://launchpad.net/bugs/400851
<bobg> broder, thanks. is there anything like the "Debian Policy Manual " for ubuntu specific policies?
<bryceh> debfx, on it
<broder> bobg: there's an ubuntu policy manual, but it's not actually different from debian policy (as it should be). i know that the server team is putting together docs during this release cycle for things like upstart idioms
<bobg> broder, ok, thanks
<debfx> bryceh: thanks
<bryceh> debfx, uploaded
<cjwatson> broder: well, it's somewhat different, just needs to be more so
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026160.html
<cjwatson> I would ask the server team to consider whether the documentation they're putting together includes policy-relevant sections, and if so to seek to merge them into policy rather than creating entirely new documents
<broder> cjwatson: the only difference right now is that Ubuntu Policy includes our maintainer policy, right?
<broder> but in any case, i feel like the things bobg is asking about are more about convention and idiom than policy
<cjwatson> broder: there are a few more differences than that
<cjwatson> http://paste.ubuntu.com/562749/
<cjwatson> (it could use a merge, though)
<bobg> at this moment it seems that debian policy on providing services is different than ubuntu policy. It depends on whether that is a temporary situation or a long term divergence
<broder> bobg: it's still completely ok to ship sysvinit-style jobs in ubuntu
<broder> and there's also some ongoing work to add upstart awareness to debian policy
<broder> which i think will help bridge some of the gap on these kinds of things
<bobg> broder, upstart coexisting with sysv is just a transition thing, right? Are debian and ubuntu working toward the  same service implementation policy but only at different speeds?
<broder> bobg: debian isn't going to be interested in forcing users to use a single init daemon when there are multiple options, so anything debian does will give users the choice of switching between sysvinit, upstart, and probably systemd
<broder> so their version of the policy will be about letting a package, e.g., use upstart if it's available and fall back on sysvinit otherwise
<bobg> broder, do you think ubuntu policy will be different? Or are you saying that sysvinit is here for the long haul on both ubuntu and debian?
<broder> bobg: no, i don't think ubuntu will ever let you switch back to sysvinit, but we'll take advantage of the fact that packages can support upstart and sysvinit simultaneously
<ohsix> it should be noted that the alternate init systems can use sysvinit type scripts as a lowest common denominator
<ohsix> so you can work from there and specialize if the package can take advantage of it
<broder> ohsix: right, which is basically what the debian policy changes are about codifying
<bobg> broder, thanks.  BTW, i like upstart, but find the lack of information, lack of command completion, and lack of a clear method of mapping tasks that you could do with sysvinit,  frustrating.  However I chalk all that up to it being new.
<broder> bobg: yeah, i know where you're coming from. i'm hoping that that'll get better this release with some of the documentation that's getting pulled together
<bobg> i keep meaning to figure out that confusing command completion syntax. I feel like its going to be a big learning curve,
<gurkan> hi all mates
<gurkan> is it normal that my utmp file is in /var/run
<broder> yes
<gurkan> why
<gurkan> it is not in /var/log ?
<broder> because the fhs says that it must go in /var/run?
<broder> http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS14
<gurkan> how it is possible that susch a logfile could be in /var/run ?
<cody-somerville> gurkan, /var/run/utmp is not a logfile.
<ion> utmp(5)
<Keybuk> cody-somerville: false
<Keybuk> it's kiiiinda a log file
<Keybuk> but /var/log/wtmp is a log file
<broder> Keubuk: utmp, not wtmp
<Keybuk> broder: yes, I know
<broder> oh, never mind - misread
<Keybuk> but utmp is also a log\
<broder> yeah, sure
<Keybuk> as well as a state file
<Keybuk> some of the things you put in utmp are still log entries
<Keybuk> but all of the things you put in wtmp are log entries
<Keybuk> it's the kind of cluster-fuck that comes from being compatible with something nobody cares about
<gurkan> cody-somerville ok i understand , but where do you find your utmp log file ? i have /var/log/wtmp but not utmp
<Keybuk> also most of utmp(5) is a lie, since init on ubuntu doesn't bother writing to utmp ;-)
<Keybuk> gurkan: utmp is in /var/run
<gurkan> <Keybuk ok <cody-somerville will not be agree with u i think
<Keybuk> /var/run/utmp is created by /etc/init/mounted-varrun.conf
<Keybuk> which is run as a result of /var/run being mounted as a tmpfs
<Keybuk> you can munt a system sufficiently that it won't be run
<Keybuk> but then lots of things will probably break, not just the existance of that file
<gurkan> then with utmp.h i could code an acces code to /var/run/utmp ?
<Keybuk> yes
<gurkan> ok thank keybuk
<Keybuk> good rule of thumb - things in /var/run don't survive a reboot
<Keybuk> and that's basically the difference between utmp and wtmp
<Keybuk> utmp is a "this boot only" log
<Keybuk> whereas wtmp is historic
<Keybuk> utmp also holds current state
<gurkan> this /var/run/utmp file stores like wtmp ?
<Keybuk> yes, they're similar formats
<Keybuk> but not identical
<gurkan> and in other nix this is not the same implementation ?  you said it store the current state but until the next boot of the machine ?
<Keybuk> it's broadly the same as SysV and BSD
<Keybuk> formats and details vary
<gurkan> for resume his contents are volatile
<agronholm> has anyone here been able to install ubuntu natty?
<agronholm> alpha2 that is
<agronholm> the installer crashes, and typing anything is difficult because it disables most keys on the keyboard
<bryceh> installed it on two different machines yesterday
<ohsix> can you still press a key during the bootloader to pick a keymap?
<ohsix> (like in 10.10)
<agronholm> not sure, it picked the default keymap based on the install language
<agronholm> if I type "qwertyuiop" all I get is "ertp"
<agronholm> most character keys are disabled
<agronholm> makes typing kinda difficult
<agronholm> I'm installing on a Virtualbox 4.0.2 VM on a linux host
<jono_> what is the installer package that I can file a bug against with ubuntu-bug?
<agronholm> hm
<agronholm> if I go back and manually select "Finnish", then the keyboard works as expected
<agronholm> "The installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again."
<agronholm> jono_: having similar problems?
<jono_> agronholm, nope
<agronholm> what kind of trouble are you having?
<charlie-tca> jono_: which image, desktop or alternate?
<jono_> charlie-tca, desktop
<charlie-tca> jono_: ubuntu-bug ubiquity
<jono> thanks charlie
<jono> thanks charlie-tca
<charlie-tca> You are welcome
<agronholm> ok now out of the blue, a dialog popped up "System program problem detected"
<agronholm> wasn't even doing anything
<agronholm> Report problem...
<charlie-tca> agronholm: you are trying to install natty in VBOX?
<agronholm> yes
<agronholm> "Sorry, the program "plugininstall.py" closed unexpectedly"
<agronholm> charlie-tca: I don't have real workstations to spare for testing out something like this :)
<charlie-tca> there was a workaround we used for 64bit images, if that is what you are installing.
<agronholm> yes
<agronholm> this would be more productive if it actually told me something about the error
<charlie-tca> try this - https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview#Boot,%20installation%20and%20post-install
<agronholm> I see
<agronholm> thanks
<charlie-tca> each distro has to change it slightly, but it works
<agronholm> change what
<charlie-tca> You are welcome
<charlie-tca> that workaround, purging "ubiquity-slideshow-ubuntu"
<charlie-tca> changed ubuntu to xubuntu, edubuntu, kubuntu, all work
<agronholm> well I hope it's fixed before alpha 3
<DJKorbit> good evening
<DJKorbit> i'm trying to compile eye of gnome but i'm getting an error, i don't know if this is the right place to post this question
<DJKorbit> eog-window.c:70:35: fatal error: launchpad-integration.h: No such file or directory
<DJKorbit> compilation terminated.
<bryceh> DJKorbit, see topic
<DJKorbit> i did and apt-get source eog
<bryceh> DJKorbit, maybe apt-get build-dep eog ?
<DJKorbit> ./configure ran fine so i guess this error shouldn't have happened
<DJKorbit> but i'll try that anyway
<DJKorbit> bryceh, it fails to compile even after build-dep
<DJKorbit> with the same error
<bryceh> DJKorbit, dunno then
<DJKorbit> bryceh, i'll try an apt-file search launchpad-integration.h
<DJKorbit> i've changed the include line from <launchpad-integration.h> to <launchpad-integration/launchpad-integration.h>
<DJKorbit> it compiled but now is breaking on linking
<broder> DJKorbit: do you have liblaunchpad-integration-dev or whatever installed?
<broder> that usually means that the CFLAGS for launchpad-integration aren't getting injected correctly
<DJKorbit> yes, i have them installed
<DJKorbit> now it's failing to link so i might have a problem in the LDFLAGS
<broder> oh - you probably didn't apply the patch series
<DJKorbit> i didn't how can i do that?
<broder> hmm, nope - it's 3.0 (quilt) so that doesn't matter
<DJKorbit> i didn't, how can i do that?
<bryceh> ./debian/rules patch
<broder> ah, got it - you need to re-run 'autoreconf'
<bryceh> or just run `debuild` in the source tree, that should do everything automatically and give you a .deb
<DJKorbit> i don't want a deb, i just want to fix a bug but i want to compile first to see if the latest version has the bug i'm experiencing
<bryceh> DJKorbit, in that case then I think this is not the right channel ;-)
<DJKorbit> broder, with your autoreconf i get a version mismatch error from intltool
<DJKorbit> i guess i'll have to work with the upstream version in eog's git repository
<DJKorbit> if it also has the bug, it will eventually get into gnome once i fix it
<DJKorbit> and i could also try to learn how to contribute fixed packages to ubuntu
<DJKorbit> broder, how can i apply the patch series?
<broder> DJKorbit: i was wrong - that happens automatically. you just need to run autoreconf
<DJKorbit> autoreconf and run make again?
#ubuntu-devel 2011-02-05
<DJKorbit> didn't work
<DJKorbit> its giving  version mismatch errors
<DJKorbit> ubuntu's source doesn't compile
<broder> DJKorbit: autoreconf, then ./configure again
<DJKorbit> upstream version... doesn't compile also
<DJKorbit> broder, did that and didn't work
<broder> out of ideas, then
<DJKorbit> ok, i'll try to fix the problem
<DJKorbit> i guess i'll waste more time trying to fix this problem than to fix the bug itself
<Keybuk> OT hilarious -> whois poem-ripe55-song
<bryceh> pilot @out
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<i4ba1> excuse me
<maco> yes?
<i4ba1> i wan to join with ubuntu project
<i4ba1> is anybody have team?
<maco> great!
<i4ba1> i want to join
<maco> well, there's lots of areas to contribute
<maco> what kind of skills / interests do you have?
<i4ba1> i interest in developing application
<i4ba1> sorry if my english poor
<i4ba1> my skill is java
<maco> ok. so first off i should let you know that generally we take existing applications and package them up for distribution, not write a whole lot of original software
<i4ba1> but now i still learn c to
<maco> however this does involve a lot of patching up and fixing bugs in the software we ship
<maco> so if you'd like to help fix up any of the java apps we have thatd be great
<maco> oh, and most of the GNOME desktop is written in C, so that's really useful
<i4ba1> ok, will help you to fix up any java apps
<i4ba1> what the aaplication to gic up?
<maco> so, if you type "apt-cache rdepends openjdk-6-jre" in a terminal, it'll list everything that uses java
<maco> you can search http://bugs.launchpad.net/ubuntu/+bugs for those package names to find what bugs are in them which you can then try to write patches for
<maco> gic?
<maco> when you have a patch ready to contribute just come back here or in #ubuntu-motu and someone will help you get it ready for inclusion in the archive and find a sponsor
<maco> i4ba1_: network hiccup?
<i4ba1_> sorry my connection down for a second
<maco> is ok. whats the last thing you saw?
<i4ba1_> sorry what do you mean saw?
<i4ba1_> about my down connection?
<maco> last thing you saw me say before your network went down
<i4ba1_> ouw
<i4ba1_> i see you reference site on launcpad
<i4ba1_> to know the list of bugs
<maco> ok
<maco> <maco> when you have a patch ready to contribute just come back here or in #ubuntu-motu and someone will help you get it ready for inclusion in the archive and find a sponsor
<maco> that was the other thing. and i asked what gic is
<i4ba1_> ok, will try
<i4ba1_> if i have thing to ask
<i4ba1_> can i ask with you?
<i4ba1_> you always still in #ubuntu-devel?
<maco> i might be sleeping. its about bedtime for me. #ubuntu-motu is the usual place for teaching new contributors i think
<maco> my client is always connected and in #ubuntu-devel, but i may not be in front of the computer
<i4ba1_> ok
<i4ba1_> so i have to join ini #ubuntu-motu
<maco> motu is the name of the group that maintains all the packages that arent on the cd (which is the vast majority of them)
<maco> and its traditionally been responsible for new-developer-training
<i4ba1__> sorry maco, down connection again
<lifeless> pitti: btw if I can draw your attention to bug 713526 - this is fairly important.
<ubottu> Launchpad bug 713526 in apport (Ubuntu) "apport uses launchpad edge service" [Undecided,New] https://launchpad.net/bugs/713526
<nigelb> lifeless: erm, that seems to be fixed in 1.17 release
<nigelb> lifeless: (its dated 2010-12-31)
<nigelb> lifeless: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/1807
<nigelb> Ah, the repos don't have the fix I think.  Might need backporting.
<nigelb> Natty has, but not the ones before natty.
<lifeless> nigelb: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/natty/apport/natty/view/head:/apport/crashdb_impl/launchpad.py
<nigelb> lifeless: Ah.
<ari-tczew> ogra: :)
<ari-tczew> how can I fix this FTBFS? http://paste.ubuntu.com/563169/
<ScottK> ari-tczew: scipy needs to be rebuilt against the current numpy.  IIRC there's a bug on the sponsors queue for the udpate.
<ari-tczew> ScottK: bug 	711663 ?
<ubottu> Launchpad bug 711663 in getfem++ (Ubuntu) "rebuild with python-numpy 1.5.1" [Undecided,Incomplete] https://launchpad.net/bugs/711663
<ari-tczew> ScottK: ah, probably you mean https://launchpad.net/ubuntu/+source/python-scipy/0.8.0+dfsg1-1ubuntu1
<ari-tczew> 28 hours ago last upload, so guess rebuild is no necessary
<ScottK> Ah.
<ScottK> Assuming it built, yes.
<ScottK> Looks like it did.
#ubuntu-devel 2011-02-06
<ari-tczew> Debian 6.0 released!
<agronholm> where has it been announced
<agronholm> not on the web site at least
<ari-tczew> agronholm: #debian channel
<Laney> http://cdimage.debian.org/debian-cd/6.0.0/
<agronholm> a list of changes from the previous version would be nice
<Laney> every package comes with a changelog
<agronholm> yeah but the highlights
<Laney> http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.html
<ari-tczew> Laney: 52+ CDs?
<agronholm> oh, goodie.
<Laney> ari-tczew: yeah, nice eh?
<ari-tczew> Laney: too much :P I prefer to netinst ;-)
<Laney> you only need CD1 to install
<DktrKranz> agronholm: well, if you want, I can prepare a *full* changelog... it's a 15 MB file though :)
<agronholm> DktrKranz: no, this is what I wanted to see
<DktrKranz> ari-tczew: yeah, per arch
<Laney> are they ordered by popcon inst?
<DktrKranz> CDs, you mean?
<Laney> yeah
<Laney> ones in tasks in CD1 presumably, then â¦
<DktrKranz> mmh, no
<DktrKranz> debian-cd is in charge to determine what goes into which CD
<Laney> yeah, i was just wondering how it's done
<Laney> surely they don't manually determine which package goes on every one of 52*arch CDs ;-)
<DktrKranz> suuure
 * sebner dances in excitement ~o~ ~o~ ~o~
<dupondje> could somebody check https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/290177 ? Seems like this is still occuring :(
<ubottu> Ubuntu bug 290177 in network-manager (Ubuntu) "[huawei/option] NM 0.7: GSM connections won't work with PIN code protected modems - despite having supplied the correct PIN for the connection in nm-connection-editor" [Medium,Triaged]
<evfool> hi all
<evfool> could anyone allow my bugday announcement mail on ubuntu-devel-announce list, please?
 * psusi wonders where Keybuck has been
<lifeless> california?
<psusi> what's in california?
<lifeless> google
<psusi> what's going on there?
<lifeless> tis where he works now
<psusi> oh crap
<lifeless> working on upstart stuff I believe.
<psusi> does that mean I need to find someone else to sponsor my patches to ureadahead?
<lifeless> hes still a core dev etc
<micahg> psusi: you can subscribe ubuntu-sponsors unless it's urgent, one of the patch pilots should get to it
<psusi> ohh... he is?  I see
<micahg> is apport enabled by default in natty yet?
<ohsix> i thought it was disabled always during development releases
<ohsix> er, enabled rather
<micahg> ohsix: it's supposed to be enabled during development releases, but idr when it actually gets enabled
<ohsix> shrug, i just turn it on always in /etc/default/apport
<micahg> yep, it was enabled for alpha 2
<YankeesFan> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<YankeesFan> !ops
<Hobbsee> shame on you, idiot.
<nigelb> heh
<sveinse> Do you know of a good book which talks about the debian package system?
<sveinse> ...or any other good system oriented books about ubuntu
<rsajdok> sveinse: https://wiki.ubuntu.com/PackagingGuide/Complete
<Chipzz> rsajdok: that's packag*ING*, not the package system
<Chipzz> sveinse: man apt-get; also, pls ask on #ubuntu-server
<rsajdok> Chipzz: sure, my mistake
<ohsix> is there any plans on getting changelogs for ppa's working? (like, when you press C in aptitude)
<canesin> #motu
<lifeless> mdz: around?
<agronholm> anybody know what the new dependency based boot system in debian squeeze is called?
<agronholm> is it in any way related to upstart?
<virtuald> http://debian.org/releases/stable/i386/release-notes/ch-whats-new.html#dependency-boot
<agronholm> sucks that they have a different system than ubuntu does
<virtuald> agronholm: so does fedora
<agronholm> yes
<agronholm> it'd be easier for developers if the distros could agree on a common init system
<virtuald> they're all backwards compatible with sysv init
<penguin42> virtuald: Not really, upstart is quite different
<agronholm> how do you specify dependencies with sysv init?
<agronholm> afaik you can't
<penguin42> in a way the problem is that none of them quite got to the point where they are polished and satisfy everyone
<virtuald> it runs sysv scripts if you got them, that's what i call backwards compatible
<penguin42> oh I see what you mean, yeh
<virtuald> agronholm: there's lsb headers that specify dependencies, i don't know if upstart uses them (yet)
<agronholm> parallel execution of init scripts is something every distro should be able to do
<bigon> yeah looks like all clutter things are broken on my system
<canesin> Do somebody know a work stealing module for python ??
<canesin> A implementation of ABP work stealing would be nice
<Burpaps_> i might
<Burpaps_> so you want a good copy and pasteer?
<Burpaps_> maybe even compile for you and press the buttons
#ubuntu-devel 2012-01-30
<slangasek> jibel: it doesn't appear that there've been any oneiric->precise (desktop,server) auto-upgrade tests since the job reorg :(
<achiang> apt-get dist-upgrade in precise wants to remove python-dbus-common. can that really be correct?
<micahg> achiang: yes, doesn't seem to be published any more
<achiang> micahg: ok, thanks
<stgraber> RAOF: hey there
<stgraber> RAOF: thanks for accepting the vlan package
<stgraber> RAOF: as for the extra delta in the ifenslave-2.6 SRU (one line change for /run + documentation), the idea was that reverting these just for the sake of having a smaller delta isn't probably worth it as indeed the /run change isn't needed (but won't make any change as /run is a symlink /var/run in Oneiric already) and the documentation would just be inaccurate if reverted
<stgraber> RAOF: keeping these two changes gives us the advantage of having an identical package in Oneiric and Precise, making diffing the two quite a bit easier (if we start getting more changes in Precise) and so making debugging easier
<RAOF> Fair enough.
<RAOF> Accepted
<stgraber> RAOF: thanks
<stgraber> RAOF: I just posted instructions for the vlan package. I'll do the same for the ifenslave-2.6 package tomorrow, then that should be all that's needed for that bug. I'll test the full stack from -proposed on a server I have around that's affected by the issue and hopefully the bug reporter will do the same (AFAIK he's currently running the Precise version of these packages on Oneiric)
<RAOF> Cool.
<hyperair> kk
<hyperair> oops
<YokoZar> What order will dh_install act in?  (This is important for overlapping wildcards)  Is it the order of the packages in the control file?
<YokoZar> (for multiple binary packages of course)
<ScottK> I don't think you can rely on it to be ordered (think parallel builds).
<pitti> Good morning
<pitti> jibel: hm, I see "sudo: unable to resolve host ubuntu" in the upgrade-lucid-desktop output
<pitti> jibel: uploaded a fix for gdm->lightdm autologin migration
<jibel> pitti, good morning
<pitti> jibel: bonjour, ca va?
<hyperair> YokoZar: i think dh_install installs things multiple times, no?
<jibel> pitti, I've got a cold and lost my voice, but Ã§a va :)
<jibel> pitti et toi ?
<pitti> jibel: je suis bien, merci!
<pitti> jibel: get well soon!
 * ttx turns his attention to the new #ubuntu-devel-fr channel
<YokoZar> hyperair: Yes it does, just learned that ;)
<hyperair> =)
<hyperair> you might want dh_movefiles instea
<hyperair> d
<jibel> pitti, I'll run an upgrade test today to validate the fix.
<pitti> jibel: merci; NB that it isn't published yet
<pitti> jibel: it's built, so should be on the mirrors in 45 mins
<pitti> jibel: I guess/hope you did not apply the workaround for this yet?
<pitti> jibel: i. e. ideally the user config migration tests should start working as well now?
<jibel> pitti, it should, that's what I'd like to verify.
<smb> slangasek, I saw your comment about having a reproducer now, but yes mine is on real hw but I can send out the /proc/cmdline. One special thing here is that I have console running on a serial line.
<smb> morning, btw
<dholbach> good morning
<ejat> morning dholbach
<ejat> !ping jamespage
<dholbach> hi ejat
<ejat> :)
<ejat> hows ya day ?
<dholbach> good good - how about yours?
<slangasek> smb: do you happen to have /usr as a separate filesystem?
<smb> slangasek, no I think that is in the main vg. but /boot would be differen
<slangasek> ok
<slangasek> I was specifically looking at the /etc/init/gssd.conf job, which triggers the bug if /usr is a separate filesystem
<slangasek> but if that's not it on your system, nevermind; it probably doesn't matter which job it is
<smb> Ok, still need to reactivate that machine to get the cmdline. Just refrained as it is a tad loud
<slangasek> cmdline probably doesn't matter now
<slangasek> don't worry about it - I think we've got a pretty solid reproducer now
<slangasek> and on that note, I'm off to bed :)
<smb> oh ok. bring it up anyway as its my xen test system. :)
<smb> slangasek, good night. rather surprised to see you around anyway. (actually not, you are sometimes up at surprising times)
<pitti> mvo: btw, should I binNEW apt now? this requires a full ABI transition, right?
<mvo> pitti: slangasek uploaded it, but I assume the answer is yes, binaryNEW please :) the transition should be smooth as its a proper lib package now, once its there I can upload the rdepends
<pitti> mvo: just asking because this evening is alpha-2 freeze, so I suppose we shuoldn't release it with an unfinished apt transition
<mvo> pitti: if unsure we can wait for slangasek but given that its uploaded I would say lets do it all the way, it should be fine and we prepared it in a ppa and experimental
<pitti> mvo: yes, and it is specifically targetted for alpha-2
<pitti> for the upgrade fixes
<pitti> mvo: binNEWed
<mvo> what could possilby go wrong ?
 * mvo goes and uploads rdepends
 * pitti knocks on wood
<pitti> mvo: danke!
<seb128> jibel, pitti: bug #922052
<ubottu> Launchpad bug 922052 in ubiquity (Ubuntu Precise) "panel crashed with SIGSEGV in indicator_object_get_entries()" [High,Confirmed] https://launchpad.net/bugs/922052
<seb128> the issue is ubiquity having:
<seb128> static const char* indicators[] = {
<seb128> 	"/usr/lib/indicators3/6/libsession.so",
<seb128> 	// Bluetooth
<seb128> 	"/usr/lib/indicators3/6/libapplication.so",
<seb128> 	"/usr/lib/indicators3/6/libsoundmenu.so",
<seb128> i.e hardcoded version, it needs to be updated,rebuilt with the current version
<seb128> seems like ken forgot it when he went through the rdepends
<seb128>  
<seb128> is there any ubiquity upload planned for other reasons or anybody working on it?
<mvo> Riddell: hi, when I do "bzr get lp:update-manager;cd update-manager; python UpdateManager/DistUpgradeFetcherKDE.py" I get a ugly assert failure - is this known? something wrong on my box? is that code still in use ? I'm doing pyflake cleanups and would love to actually test this stuff :)
<mvo> Riddell: fwiw the exact error is http://paste.ubuntu.com/822367/
<pitti> seb128: I'm creating a MP
<seb128> pitti, thanks, I was trying to check if somebody was planning an ubiquity upload and only having a checkout and working on it before checking the source and doing that
<seb128> the monday morning downloads are saturating my download ;-)
<pitti> seb128: I have a current checkout anyway
<seb128> pitti, danke
<Riddell> mvo: there was a binary incompatibility last week
<Riddell> mvo: I hope it's fixed but it's on my todo list for today to check
<pitti> cjwatson, ev: would appreciate if you could pull/upload https://code.launchpad.net/~pitti/ubiquity/indicator-soname/+merge/90666 today
<Riddell> mvo: make sure you have already done a dist-upgrade to check (maybe you want to be able to run the upgrade tool to do this :)
<mvo> Riddell: ok, if you have time (ahaha, I know how it is :/) it would be awsome if you could simply run " python UpdateManager/DistUpgradeFetcherKDE.py" and "cd DistUpgrade; sudo ./dist-upgrade --frontend DistUpgradeViewKDE" on latest u-m trunk on a system that has a wokring pyqt - just to ensure my pyflake fixes did not mess up stuff on your side
<Riddell> mvo: ta, will do
<cjwatson> pitti: in progress, thanks
<cjwatson> mvo: FWIW I'm working on a release-upgrader-apt update now
<cjwatson> mvo: do you think it might be worth SRUing those resolver fixes of mine to lucid and oneiric?  I don't know what you normally do here, but it occurs to me that they might cause trouble for ordinary dist-upgrades too
<brendand> Daviey - hi
<mvo> cjwatson: we are cautious usually with resolver changes, but those are pretty clear so a SRU would be a good thing
<mvo> cjwatson: when debian bzr is back I will merge them into the debian branch too
<mvo> cjwatson: oh, and of course thanks a lot! for the fixes
<mvo> if someone could binary-new libept1.4.12 that would be great
<nigelb> ev: Hapy Birthday!
<cjwatson> mvo: right, it wasn't the crazy "re-balance delicate heuristics" exercise that I'd expected
<pitti> mvo: looking at libept, but waiting for a few mins for armel to finish
<pitti> it's already in the test suite
<Daviey> brendand: hello?
<brendand> Daviey - just having a problem with the server installer, wondering if it's known about
<brendand> Daviey - just after running tasksel, debian-installer fails
<geser> cjwatson: as you're a bug contact for vim too: what's your opinion on bug #871907? I plan to merge vim once again in the next days and wonder if I should "fix" this bug too (or not)
<ubottu> Launchpad bug 871907 in vim (Ubuntu) "vim should have "set bg=dark" by default" [Wishlist,Confirmed] https://launchpad.net/bugs/871907
<cjwatson> geser: well, it's what I use personally, but it sounds like a classic case where we change the default and then the other set of people get upsset
<cjwatson> the argument in the bug seems sound though ...
<cjwatson> adding termcap entries would be a nightmare when working with other OSes
<geser> that's the reason why I rethink about fixing it
<Daviey> brendand: Is this on precise?
<cjwatson> Daviey,brendand: -> #ubuntu-installer, let's not duplicate this across channels
<brendand> Daviey - yes. as cjwatson says, discussing now in #ubuntu-installer
<cjwatson> or actually - it's not an installer bug
<cjwatson> http://paste.ubuntu.com/822408/ shows unmet dependencies in apache and nova
<cjwatson> apparently trying to install multiple conflicting providers of certain virtual packages at once
<geser> cjwatson: do you know if a dark terminal is the default for all *buntu variants?
<pitti> mvo: libept NEWed
<mvo> thanks pitti
<dholbach> @pilot in
<dholbach> hum
<cjwatson> geser: no
<cjwatson> I mean I don't know
<zyga> barry: hi, quick question, what kind of buig should I file to get a new python trove classifier considered/added
<dholbach> @pilot in
<geser> dholbach: doesn't ubottu like you as pilot?
<cjwatson> the channel was set +t a while back so it can't change the topic any more
<dholbach> geser, I'm discussing it with AlanBell in #ubuntu-irc just now
<cjwatson> unless it's that it no longer has ops or something
<AlanBell> cjwatson: so on friday did you manually set the topic when you did @pilot out?
<cjwatson> yes
<AlanBell> ok
<cjwatson> I didn't have time to track down what was wrong with the bot at the time
<AlanBell> thats fine, I was just trying to figure out when it stopped working
<AlanBell> ok, so I can op the bot, set the channel to -t or get the bot patched to use chanserv to change the topic
<AlanBell> or some combination thereof
<AlanBell> lets try that for starters, dholbach want to pilot in? (you may have to pilot out first)
<dholbach> @pilot out
<dholbach> @pilot int
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<dholbach> aha!
<dholbach> thanks AlanBell and cj
<dholbach> thanks AlanBell and cjwatson :)
<AlanBell> ok, we can add patching udevbot to use chanserv to change the topic to a todo list somewhere
<doko> smoser, pitti, cjwatson: did your glibc-2.15 test system survive?
<cjwatson> Can anyone here see a wireless network through NM with a non-ASCII SSID?  I'd like to check something.
<pitti> doko: so far it does quite well
<cjwatson> Actually, never mind, I think I've found relevant online references ...
<pitti> doko: well, it's my normal workstation, so any bigger breakage should be visible quite fast (as the svg loader one)
<lynxman> What would be the best way to create a watch file on a package to watch a git repo that's not on github? I've been googling around but can't find a definite answer
<alkisg> lynxman: completely unrelated, but I tried your debian/ dir from https://code.launchpad.net/~lynxman/ubuntu/precise/ipxe/newsnapshot along with the current ipxe git and it worked fine. Not sure why your branch is marked "needs fixing" - it'd be nice if you could upload it so that we have a working ipxe for precise (bug #916489)
<ubottu> Launchpad bug 916489 in ipxe (Ubuntu) "grub-ipxe says "B: command not found"" [Medium,Triaged] https://launchpad.net/bugs/916489
<lynxman> alkisg: I was working on that actually :)
<alkisg> Not that much unrelated then :D
<lynxman> alkisg: it was just a problem on how I bzr commited the upstream snapshot, also wanted to add a watch file for full updatedness
<alkisg> Right I think the last git numbers that you're using aren't very appropriate for version numbers, they got me a "newer version has a lower dpkg number" problem
<alkisg> It'd also be nice if we put win32-loader.exe somewhere, either in the CDs or in the web site... That puts grub.mbr + ipxe.lkrn to the *windows* boot manager, but it can't be compiled in ubuntu without workarounds because we're missing a few debian packages like cpio-win32 something
<lynxman> alkisg: that was one of the issues, I pumped up the version to 3. to avoid this after talking with the debian packager
<alkisg> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607417 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657830 for the ipxe/win32-loader.exe part
<ubottu> Debian bug 607417 in win32-loader "win32-loader: please offer a "Boot from network with gPXE" option" [Wishlist,Fixed]
<ubottu> Debian bug 657830 in win32-loader "win32-loader: Please make pxe.target depend on the ipxe package" [Wishlist,Open]
<lynxman> alkisg: hmm that'd be a nice addition indeed, I'll have a look into it :)
<alkisg> lynxman: I have a binary in http://people.ubuntu.com/~alkisg/boot/win32-loader.exe if you want to see how it works first. Select the third option in the installer, "PXE mode".
<Daviey> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, Daviey
<or4n9e> hi. may you please tell me where I can ask a question about packages in main (in my case bluez)? I.e. about the build process of the specific packages and an issue with the default distribution
<or4n9e> thanks in advance
<pitti> or4n9e: cyphermox recently dealt with bluez, he might be a good person to start discussing with
<or4n9e> pitti: ok, thanks
<or4n9e> cyphermox: may I chitchat with you quickly please?
<pitti> or4n9e: he should get online in an hour or two, he's in Canada
<or4n9e> pitti: I see. I'll just stay in here and then try again to ping him
<or4n9e> btw, to all attending the chat (I see this as an opportunity) ... THANKS for developing ubuntu, I'm using it (and having fun) since 4.10 and never looked back. my honest respect to all making this happen
<Daviey> debfx: Is bug 923343 ready for upload?
<ubottu> Launchpad bug 923343 in pkgbinarymangler (Ubuntu) "pkgstripfiles: creates symlinks that point to themselves" [Undecided,New] https://launchpad.net/bugs/923343
<debfx> Daviey: yes, but I've filed two other bugs. at least bug #923407 should be easy to fix.
<ubottu> Launchpad bug 923407 in pkgbinarymangler (Ubuntu) "pkgstripfiles: md5sum incorrect when advpng fails" [Undecided,New] https://launchpad.net/bugs/923407
<Daviey> debfx: do you want to include the fix for that in the same upload?
<scott-work> cjwatson:  can you assist me getting the user (both live and installed default) into the audio group
<cjwatson> scott-work: hmm, your preseeding is already supposed to do that
<cjwatson> data/precise/preseed/ubuntustudio/ubuntustudio.seed:6:d-i       passwd/user-default-groups      string adm audio cdrom dip lpadmin plugdev sambashare
<scott-work> cjwatson:  and also help with getting the jackd package to configure the rt privileges?  it used to but now it doesn't seem to ask, even in during the install
<scott-work> cjwatson: re: audio group - i actually have tested an older image since we weren't building them for a while
<cjwatson> you won't get questions asked with a ubiquity-based install.
<cjwatson> this shouldn't have changed lately.
<pitti> Daviey: just commented on the MP and also approved, looks good
<pitti> thanks debfx
<pitti> Daviey: yes, I think debfx' md5sum fix should also go in, that seemed easy; let me have a quick look
<scott-work> cjwatson: my understanding from looking at the jackd code (although i'm not fluent) is that it defaults to audio.conf.disabled unless the defcon is answered yes
<Daviey> thanks pitti
<scott-work> cjwatson: i suppose the ubuntustudio-default-settings could manually rename that file to audio.conf just as the jackd defcon would
<cjwatson> scott-work: better to just preseed that question.  what is its name?
<scott-work> cjwatson: the name of the file jackd renames?
<cjwatson> scott-work: no, the name of the debconf question
<cjwatson> scott-work: also, could I have casper.log from booting an ubuntustudio DVD?
<scott-work> cjwatson: re: casper.log, we can have that at the latest by tonight (i will do it if others can't, but i'm at 'work' on a windows machine)
<scott-work> cjwatson: i don't know the name of the question but i can ask someone to test today during the day, again the latest would be tonight
<cjwatson> jackd/tweak_rt_limits?
<cjwatson> is this the jackd2 package?
<scott-work> cjwatson: if you have a test install, you can just isntall jack
<scott-work> cjwatson: yes, should be jackd2
<cjwatson> I'd need to see it in context, and I'm too close to my bandwidth quota to download an ubuntustudio image just now.
<scott-work> cjwatson: i have asked in #ubuntustudio-devel, although it's pretty early for musician type people ;)
<cjwatson> Is there a bug# for this?
<cjwatson> (either)
<scott-work> (scott-work is a slight anomoly as he likes to get up early)
<scott-work> cjwatson: there is not, but i am more than happy to create one or two
<scott-work> cjwatson: would you like me to?
<cjwatson> No need
<cjwatson> Just wanted to know if there was an existing audit trail to attach commits to.
<cjwatson> I believe I've enabled jackd rt priority for you no
<cjwatson> w
<cjwatson> Of course that assumes that whatever problem is preventing default groups from being set up properly is specific to default groups rather than a general problem with preseeding.
<scott-work> cjwatson: thank you very much
<pitti> Daviey: committed a fix for the other bug, running tests now
<scott-work> cjwatson: i believe len testing the image from last night...although, i don't know if he specifically looked at the user in the audio group
<Daviey> pitti: shall i leave test/upload with you?
<pitti> Daviey: fine for me
<pitti> Daviey: debfx also reported bug 923430, I'll have a quick look, too
<ubottu> Launchpad bug 923430 in pkgbinarymangler (Ubuntu) "pkgstripfiles: md5sum incorrect when doc dir is a symlink" [Undecided,New] https://launchpad.net/bugs/923430
<scott-work> cjwatson: he might have just reported 'no rt privs', which could (as most likely) is attributable to the jack configure
<Daviey> pitti: thanks
<cjwatson> scott-work: yep, that's possible.  Worth checking specifically
<debfx> pitti: thanks. I'm not quite sure how to fix that one.
<pitti> debfx: I actually thougth I fixed that already long ago
<pitti> i. e. make it ignore files which are in symlinked dirs
<cyphermox> or4n9e: pinging you back, you wanted to know avout something in bluez?
<scott-work> cjwatson: astraljava is going to check on these questions after zsyncing the latest image
<debfx> pitti: right, so just check if usr/share/doc/$PKGNAME is a symlink?
<cjwatson> scott-work: ok, cool
<scott-work> is skaet around? or does she usually join later in the day?
<pitti> debfx: it currently does
<pitti>     # skip if doc dirs are already symlinks
<pitti>     if [ ! -d usr/share/doc -o -h usr/share/doc -o -h usr/share/doc/$PKGNAME ];
<pitti> ... return
<lynxman> roaksoax: about the ipxe review you did, how would you add a watch file for a git repo not in github? Been looking for it to no avail
<pitti> debfx: oh, that's not in symlink_doc(), its' in strip_debian_changelogs()
<debfx> pitti: I guess clean_upstream_changelogs() should check that before setting $dch
<pitti> debfx: yes, indeed; it could do dch=`readlink -f usr/share/doc/$PKGNAME/changelog.Debian.gz` instead
<pitti> but this shoudl get a test case
<pitti> bzr: ERROR: The delta generated was too large: xdelta: warning: no matches found in from file, patch will apply without it
<pitti> error: excessively large binary delta for /home/martin/ubuntu/gvfs_1.11.2.orig.tar.xz
<pitti> does anyone know a workaround for this?
<pitti> I know that pristine-tar doesn't support .xz, but in the past it just stored the whole orig tarball instead of a delta
<pitti> now it's gone from "inefficient" to "impossible"?
<stgraber> pitti: thanks for fixing the langpack!
<pitti> stgraber: well, my fault in the first place :) de rien
 * pitti uses the old-fashioned way for gvfs then and let the package importer sort it out
<stgraber> pitti: can you trigger a manual build of Edubuntu? would like to make sure it mostly works before we get into the alpha2 freeze
<pitti> stgraber: started
<stgraber> pitti: thanks
<soren> Kiall: It looks good. My only complaint is the debian/patches/debian-changes-1.11-0mit1~35.gbpd304ad
<soren> Er..
<soren> Wrong channel.
<soren> Heh
<zul> can an archive admin review kyestonelight its been sitting in the binary new queue for the past two weeks
<soren> zul: Oh, you're packaging it separately?
<zul> yeah
<soren> You know it's replacing keystone upstream, right?
<zul> soren: yep
<soren> Ok.
<zul> soren: heard 2 weeks ago :)
<soren> So.. Why do you..
<soren> Meh. You work it out :)
<Daviey> I don't think at the time we knew the name would change.
<astraljava> cjwatson: US live user is _not_ in the audio group by default. Also, ubiquity crashed when I tried to update it. Called itself, python-apt and python-apt-common obsolete. :) The file in /etc/security/limits.d/ is audio.conf.disabled. Installing now to get the casper.log for ya.
<cjwatson> the limits.d bit should be fixed with the next build
<Pici> .60
<soren> Daviey: Right. I don't think anybody did at that time, but you do now :) That's why I'm wondering.
<cjwatson> not interested in that bit for now :)
<astraljava> Yep. :)
<hallyn> jodh: is upstart supposed to build in sbuild right now?
<Daviey> soren: right..
<jodh> hallyn: alas no, due to the fact that sbuild does not provide a controlling terminal. build works fine in pbuilder.
<jodh> hallyn: I am looking at a change to the upstart test suite to allow it to build in sbuild though.
<hallyn> jodh: ok, thx
<hallyn> jodh: i expect to send you a merge request (for review) for lxc container support hopefully later today
<koolhead11> hi all
<jodh> hallyn: ok, thanks. sounds intriguing.
<barry> zyga: probably the pypi bug tracker? http://sourceforge.net/tracker/?group_id=66150&atid=513504
<zyga> barry: thanks
<cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html lists some language pack problems
<pitti> argh, did that slip in again
<pitti> cjwatson: thanks, fixing
<stgraber> pitti: is there an easy way I can get apport to submit crashes from another system (in this case from automatic upgrade testing)? apport-bug complains that it's unable to find the package
<hallyn> jodh: hm, test_conf still failed in pbuilder.
<hallyn> biab.  (will check if it's my own fault)
<jodh> hallyn: could you send me some details?
<jodh> hallyn: sorry - caught by bug 861268 yet again.
<ubottu> Launchpad bug 861268 in Ubuntu "text corruption in terminals (xterm, urxvt) and emacs" [Medium,Confirmed] https://launchpad.net/bugs/861268
<hallyn> jodh: what sort of detail?
<hallyn> jhunt, hm, i haven't noticed that since switching from nvidia to nouveau recently
<pitti> stgraber: run apport-bug --save foo.appor mypackage  on the affected system, then copy it over, and run apport-bug foo.apport
<hallyn> jodh: http://paste.ubuntu.com/822673/ shows the failed bit in 'pbuilder build *.dsc' with the current result of 'pull-lp-source upstart'
<stgraber> pitti: right, sadly the affected system doesn't really exist anymore... the only thing I get from the auto dist upgrader is a .crash. I'll try to dig a bit and see if I can get the stacktrace in a readable form so I can look for these crashes on LP.
<jodh> hallyn: thanks - do you have the rest of the log though? Need to see atleast a couple of lines of context arond the line showing BAD or FAIL
<hallyn> jodh: http://paste.ubuntu.com/822682/ is that what you need?  I can upload the whole log to p.c.c otherwise
<Riddell> mvo: hi
<jodh> hallyn: thanks. if you could send me the log, that'd be great.
<Riddell> mvo: "python UpdateManager/DistUpgradeFetcherKDE.py" complains about not being able to write to ~/.cache/something
<Riddell> mvo: when I make ~/.cache it exits successfully without showing a GUI
<Riddell> mvo: cd DistUpgrade; sudo ./dist-upgrade --frontend DistUpgradeViewKDE  is working fine
<Riddell> mvo: so new bug found in the ~/.cache issue?
<astraljava> cjwatson: Sorry, but I can't provide the casper.log. Ubiquity crashes in the middle of the installation.
<astraljava> ...repeatedly.
<cjwatson> astraljava: casper.log is generated before ubiquity starts.
<astraljava> Oh! Lemme try to get to it, then.
<nigelb> 20
<nigelb> ugh
<astraljava> cjwatson: http://astraljava.kapsi.fi/casper.log
<cjwatson> the fontconfig-voodoo stuff there isn't pretty, but not immediately relevant
<cjwatson> no obvious sign of a preseeding problem
<cjwatson> I guess I'll have to download all this and have a look :-(
<astraljava> cjwatson: Damn. Well, let me know if you need anything from me.
<astraljava> I'll keep it in this state for a while.
<cjwatson> I'd been hoping to avoid having to look directly, but sometimes there's no other way
<astraljava> Sorry...
<hallyn> jodh: http://people.canonical.com/~serge/outout (result of 'sudo pbuilder build *.dsc > outout 2>&1')
<astraljava> cjwatson: I can dig into it, too. I know you're very busy, so I don't wanna add more burden on your shoulders because of US.
<seb128> mvo, hey, is that some bug or some local corruption?
<seb128> rc  libunity-misc0                            0.2.1-0ubuntu2                           Miscellaneous functions for Unity - shared library
<seb128> $ LC_ALL=C sudo apt-get remove --purge libunity-misc0
<seb128> ...
<seb128> dpkg: error: architecture name in specifier 'libunity-misc0:ï¿½ï¿½' is illegal: must start with an alphanumeric
<seb128> it does it on other packages in a "rc" state
<cjwatson> astraljava: well, feel free certainly, but I expect this is something fairly arcane
<seb128> so seems a bug
<astraljava> cjwatson: I understand, and am a little afraid of it. :)
<cjwatson> astraljava: might be worth getting casper.log when booting with DEBCONF_DEBUG=developer on the kernel command ine
<cjwatson> *line
<astraljava> cjwatson: Alright, I'll try that.
<mvo> seb128: meh, you found a bug
<astraljava> cjwatson: There are two dashes at the end, before or after them?
<cjwatson> astraljava: doesn't matter, as long as there are spaces in between that argument and the dashes
<astraljava> Ok.
<MacSlow> mvo, poing
<seb128> mvo, where should I open it? ;-)
<seb128> open->report
<astraljava> cjwatson: Ok, file updated at the same location.
<mvo> seb128: apt
<mvo> MacSlow: pong
<mvo> seb128: and high please
<astraljava> Wonder if the burn process went bust. md5sum matches.
<cjwatson> astraljava: no, nothing to do with that
<cjwatson> despite answers.launchpad.net users' penchant for claiming everything's a burn problem
<astraljava> Hehe. :)
<seb128> mvo, bug #923807
<ubottu> Launchpad bug 923807 in apt (Ubuntu) "error: architecture name in specifier is illegal: must start with an alphanumeric" [High,New] https://launchpad.net/bugs/923807
<mvo> ta
<cjwatson> astraljava: can you file a bug on casper, please?  The problem is that preseeding is processed after user-setup is run
<hyperair> hmmm there's an unpatched sudo vulnerability around.
<hyperair> http://seclists.org/fulldisclosure/2012/Jan/att-590/advisory_sudo.txt
<smoser> anyone feel like commenting/rejecting/flaming me for https://code.launchpad.net/~smoser/ubuntu/precise/sysvinit/rc.local.d/+merge/88323 (bug 915215)
<ubottu> Launchpad bug 915215 in sysvinit (Ubuntu) "rc.local should support a runparts of rc.local.d" [Undecided,New] https://launchpad.net/bugs/915215
<astraljava> cjwatson: Yes, for sure. And I guess I'll attach the log file, but does it need something else?
<cjwatson> astraljava: nope
<astraljava> Alright.
<astraljava> cjwatson: bug 923810 filed
<ubottu> Launchpad bug 923810 in casper (Ubuntu) "ubuntu studio live-dvd 20120129 fails, crashes ubiquity" [Undecided,New] https://launchpad.net/bugs/923810
<astraljava> Very vague title, but didn't really know what to put in there.
<cjwatson> astraljava: let's keep the ubiquity crash separate
<cjwatson> astraljava: it's probably unrelated
<jdstrand> hyperair: that only affects 12.04, and our hardening should handle it sufficiently until there is a merge from Debian
<hyperair> jdstrand: cool, that's good to know
<astraljava> cjwatson: Oh okay, sorry.
<cjwatson> astraljava: happy to debug your ubiquity crash separately ...
<mvo> seb128: anything special about the pkg ? I can not reproduce the failure currently
<seb128> mvo, no, just pick anything in dpkg -l | grep ^rc ?
<mvo> seb128: aha! you rock
<seb128> mvo, sorry if the description was not clear enough ;-)
<mvo> seb128: *cough* or I was not reading carefully enough
<astraljava> Sorry about the bug title, didn't refresh in between. Changed it back to what you had.
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Daviey
<stgraber> cjwatson: hi! ldm is finally somewhat in sync with Debian and it should now be safe for people to merge as any other package. Can you remove it from the MoM blacklist?
<cjwatson> stgraber: I believe it's just in the sync blacklist (which MoM uses) - confirm that it's still OK to remove from that?
<cjwatson> (*ubuntu* versioning will still be respected, of course)
<stgraber> cjwatson: yeah, whenever the Ubuntu delta will be fully gone it'll be fine to sync from Debian, so removing from the sync blacklist sounds good
<cjwatson> stgraber: does the same go for ltsp?  it's currently blacklisted for the same reason
<stgraber> no, ltsp is still a mess, I'm hoping to resolve the situation this cycle though ;)
<cjwatson> stgraber: OK, I've just unblacklisted ldm then
<stgraber> cjwatson: thanks
<nigelb> 22
<jodh> hallyn: I can't recreate your problem using pull-lp-source or building direct from the branch. Is it repeatable?
<hallyn> jodh: yeah...  it happens every time here
<hallyn> jodh: i'll go ahead and try elsewhere then.
<astraljava> cjwatson: The ubiquity crash is on bug 923830
<ubottu> Launchpad bug 923830 in ubiquity (Ubuntu) "ubiquity crashes on ubuntu studio live-dvd 20120129" [Undecided,New] https://launchpad.net/bugs/923830
<hallyn> jodh: the pbuilder tarball was brand-spanking-new, and the schroot was just updated...
<hallyn> jodh: feh, on a canonistack instance it worked.  some breakage on my system apparently!
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand, Daviey
<slangasek> jibel: hey there!  did you catch my comment over the weekend that the oneiric->precise upgrade tests seem to have gone missing from jenkins post-reorg?  Sorry for rocking the boat and screwing this up :/
<jibel> slangasek, hey. where are you looking ? from https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-oneiric-desktop/ the test ran from Jan 26th to 29th
<jibel> same for server
<slangasek> jibel: oh, *hah*
<slangasek> jibel: I didn't notice that there was a separate listing below for all tests, I only saw the list at the top of https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ of the broken ones
<slangasek> so the other tests are succeeding and that's why I didn't see them ;)
<slangasek> jibel: thanks for the quick fix ;)
<jibel> slangasek, oh ok. They didn't failed since post-reorg :)
<voidvector> hi, i am running oneiric, how do i force a package and its dependencies to use the precise version? My alternative is compile from source, which i really don't like to do as it is a lib
<lamefun2> hello
<lamefun2> where does Ubuntu Software Center get list of software from?
<jelmer> lamefun2: from the apt repositories listed in /etc/apt/sources.list and /etc/apt/sources.list.d
<lamefun2> and how does it know if an package is an "application" or a "technical item" or a "plugin"?
<koolhead17> hi all
<mdeslaur> tedg: hi! FYI, I cleaned up a lot of screensaver/screen locking cruft out of indicator-session in precise, and I've proposed a merge into trunk
<tedg> mdeslaur, Cool!
<stgraber> geser: ping (DMB meeting)
<or4n9e> cyphermox: ping. pitti told me that I may chitchat with you about bluez distribution in ubuntu
<or4n9e> cyphermox: do you have a few?
<cyphermox> or4n9e: certainly
<or4n9e> cyphermox: great. basically I was going to re-compile bluez in order to --enable-test configure flag just to find out that it's already enabled
<cyphermox> ok
<cyphermox> oh... maybe those aren't being run though, and if not we should definitely fix that
<or4n9e> but ... I need bdaddr tool from bluez test directory and although --test-enable is ON it isn't shipped with ubuntu's default bluez distribution
<cyphermox> oh, you mean those tests
<doko> smoser, ping
<cyphermox> or4n9e: what does bdaddr do?
<smoser> doko, here.
<or4n9e> there are SOME test utils build, so thee flag isn't useless at all but bdaddr isn't built
<smoser> i've not installed your ppa :-( but if you'd like i can do that "right now"
<or4n9e> cyphermox: bdaddr changes bdaddr on supported chipsets
<cyphermox> or4n9e: ok. I guess you've looked that a fair amount already, were you able to make it get built?
<or4n9e> cyphermox: definitely CSR, not sure about the other supported chipsets
<mvo> seb128: your crash in libapt is fixed in bzr
<mhall119> ev: ping
<doko> smoser, did you get my emails about the updated eglibc packages?
<or4n9e> cyphermox: nope. I stopped once I've seen that the appropraite flag is set in ubuntu src package
<cyphermox> or4n9e:
<cyphermox> dah
<or4n9e> I then joined here to ask and pitti pointed me to you
<smoser> doko, yeah, i just haven't tried.
<doko> please do
<cyphermox> or4n9e: sure. I can have a look in a few minutes :)
<smoser> k
<seb128> mvo, oh, it was a segfault? thanks ;-)
<cyphermox> or4n9e: you're interested in that being in the Precise package, right? or previous releases as well?
<mvo> seb128: for me it was :)
<seb128> mvo, great ;-)
<mhall119> ev: I need to get a list of the 50 most used applications from software center, so we can target them for tighter Unity integration for 12.04.  Can you get me such a list?
<or4n9e> cyphermox: awesome stuff. I mean it would be perfectly appropriate to me if you may provide me a sufficient patch to be able to re-compile the src myself. not sure if bdaddr is actually needed for the masses
<or4n9e> cyphermox: I'm running oneiric
<or4n9e> bluez 4.96
<cyphermox> or4n9e: I don't know, but if it doesn't hurt to have it it's simple enough to make it get built and installed
<smoser> doko, ppa link ?
<doko> smoser, https://launchpad.net/~ubuntu-toolchain-r/+archive/glibc/+packages
<or4n9e> cyphermox: that's true! in the end the typical end-user wouldn't care either way
<or4n9e> i.e. doesn't harm
<or4n9e> cyphermox: so, you mean, you may even provide an update to the main repos? for oneiric/precise. man, that'd be great
<or4n9e> cyphermox: I even read somewhere that bdaddr is actually needed for wiimote (not sure about the details). thus it may even have an advantage to a broader audience if it gets introduced to default ubuntu
<or4n9e> cyphermox: lemme know if I can provide further info and thx a million for having a look at it
<cyphermox> or4n9e: ok. I'll take a look at that too, fortunately I have wiimotes and I've been itching to try this out
<cyphermox> or4n9e: have you filed a bug about all this?
<or4n9e> cyphermox: nope, I haven't dealed with the wiimote thingy yet (nor may I provide better info here, I just read on the interwebz that there are some people complaining about the missing bdaddr in debian/ubuntu and compile it themselves)
<or4n9e> cyphermox: I myself just need bdaddr with a shell script, so it's more of a personal issue than a "bug" interesting to the general user
<or4n9e> I.e. I haven't seen it as a bug yet :)
<or4n9e> afaik bluez test utils are anyway provided as unstable test foo and it's basically the distribution's (your) choice to ship it or not, assumed you're responsible for bluez distribution
<or4n9e> cyphermox: on a more personal note ... if you're itching to get your hands wet with the wiimote, be sure not to miss Johnny Chung Lee's Wii project page http://johnnylee.net/projects/wii/
<burli> any idea if Vala 0.15.1 come to Precise?
<burli> or is it to late for new versions?
<Atlantic777> Hi! I'm interested in translating some docs about ubuntu development. May somebody recommend me some good official guides to start with?
<JuN1x> Atlantic777: https://wiki.ubuntu.com/Translations/QuickStartGuide
<Atlantic777> tnx :)
<Daviey> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<jordi> TheMuso: hey
<jordi> TheMuso: I've finished packaging alsa-lib 1.0.25, and I'd be very happy if we could use this opportunity to bring the Ubuntu delta down to the bare minimum, if possible.
<TheMuso> jordi: Ok, give me an hour to finish what I'm doing, and I'll look over our delta and send stuff your way.
<jordi> TheMuso: I'll be going to bed soonish, however I'll leave you some comments in private
<TheMuso> jordi: ok
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<codebrainz> Hi. Is this the best place to ask about the dbus menu thing in Unity?
<ScottK> Not really.
<ScottK> At the very least #ubuntu-desktop would be better
<codebrainz> it's a dev question, if that matters. is there an ayatana (or whatever) channel?
<cjwatson> #ubuntu-unity
<ScottK> Thanks.
<codebrainz> ok, will try there. thanks
#ubuntu-devel 2012-01-31
<RAOF> Woot!  I've got a system that refuses to upgrade to precise due to an inability to configure libtinfo5 for libncurses5.  How do I get do-release-upgrade to dump enough debugging info for someone to work this out?
<elmo> RAOF: it tends to dump enough information into /var/log/dist-upgrade/ by default
<RAOF> Hah!  There it is.
<RAOF> Now available as bug #924079
<ubottu> Launchpad bug 924079 in update-manager (Ubuntu) "do-release-upgrade fails to upgrade from Oneiric to Precise" [Undecided,New] https://launchpad.net/bugs/924079
<broder> i wonder if it makes sense to make the series nomination link visible again but make it a link to a wiki page a la +filebug
<broder> backports has been seeing a non-zero number of bugs that are really SRUs. one person commented today that they were doing it to raise awareness since they couldn't nominate anymore
<broder> i wonder if that's reflective of more of those bugs than we realized
<broder> (yes, i realize that redirecting to the wiki link on +filebug sucks and that nobody likes it)
 * ScottK wonders what the feedback mechanism was meant to be when the nomination link was removed?
<broder> i think it was intended to be #ubuntu-bugs. i'm not sure how people were supposed to discover that
<micahg> nominating doesn't necessarily help without someone try drive the patch
 * ScottK was going to guess "We're drowing, we can't afford to care".
<ScottK> True.
<micahg> although, I supposed that the nomination queue could be looked at as a source of things to do if it was used as such
<ScottK> If anyone much cared about bugs ...
<micahg> we care, but we're drowning
<micahg> almost 100k open bugs with >50% new
 * micahg is reminded of the need to go through all the Firefox bugs at some point...
<ScottK> Right, but what's more important, fixing bugs or pushing new features?
<broder> what is it called again, the gnome adhd monkey syndrome? "if i replace the feature, i don't have to fix its bugs!" :)
<ScottK> Also a lot of those aren't even actually bugs.  I know a large fraction of the bugs open against postfix in Ubuntu are PEBKAC issues.
<ScottK> broder: If it's Gnome, I think you mean remove, not replace.
<broder> hmm...on a side note, i should probably get my rear end moving if pre-release backports is going to be ready by feature freeze, huh?
<micahg> would be nice this cycle :)
<broder> i think i made it as far as breaking the lp test suite last time i looked
<ajmitch> broder: you've still got a few days :)
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch, how are you?
 * nigelb waves to pitti and ajmitch 
<ajmitch> good, how are you?
<pitti> quite fine, thanks!
 * pitti waves back to nigelb
<ajmitch> hi nigelb
<tumbleweed> someone please let my ubuntu-devel-announce mail through
 * pitti arghs about listadmin being broken now; apparently something changed in our ML archive
<pitti> tumbleweed: done
<dholbach> good morning
<zyga-afk> good morning
<zyga-afk> hey dholbach :)
<zyga-afk> mvo: :)
<mvo> hey zyga-afk
<dholbach> heya zyga-afk
<geser> does somebody know why the TB mailing list isn't listed on lists.ubuntu.com? Is it on purpose or missed after it changed from private to public?
<pitti> geser: I guess the latter; this very much looks like a wiki page
<geser> who to bug about it? (assuming the TB list should appear there)
<seb128> hey
<seb128> doko, did --as-needed stop being enforced or something?
<seb128> it seems that on precise builds with a missing -l... don't fail as they should
<cjwatson> pitti: IME listadmin still works but falls over some random percentage of the time
<pitti> cjwatson: hm, it still works for ubuntu-de@ here, but for techboard it has stopped working a few weeks ago; it only gets over "nothing in queue" now from here
<cjwatson> I used it on technical-board@ yesterday
<pitti> hm, maybe I'm just unlucky, or it works worse in my mornings
<Daviey> cjwatson: I was getting high failure rate
<Daviey> I don't think it is the client, but the service timeing out.
<Daviey> ie, fetching data for ubuntu-server@lists.ubuntu.com ...
<Daviey> Use of uninitialized value in string eq at /usr/bin/listadmin line 832, <FIN> line 57.
<Daviey> Use of uninitialized value in string eq at /usr/bin/listadmin line 826, <FIN> line 57.
<Daviey> Died at /usr/bin/listadmin line 827, <FIN> line 57.
<cjwatson> yeah
<Daviey> second attempt worked.
<Daviey> and, fetching data for ubuntu-devel@lists.ubuntu.com ...
<Daviey> Died at /usr/bin/listadmin line 1310, <FIN> line 2.
<doko> seb128, no: COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
<doko>  /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/
<doko> ../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. /tmp/ccVTmo51.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o
<seb128> doko, is the --no-add-needed normal in there?
<doko> yes, but I could remove that one too
<doko> it the default for ld 2.22
<seb128> doko, ok, thanks
<seb128> I wonder why lightdm-gtk-greeter builds without error where it uses libX11 functions without a -lx11
<seb128> doko, btw is that normal?
<seb128> $ gcc-4.5 -v
<seb128> /usr/bin/gcc-4.5: not found (hardened-cc could not find target)
<seb128> that breaks builds with i.e CC=gcc-4.5
<doko> b-d on gcc-4.5?
<seb128> $ gcc-4.5
<seb128> /usr/bin/gcc-4.5: not found (hardened-cc could not find target)
<seb128> doh
<seb128> I wonder why I have the command if gcc-4.5 is not installed
<seb128> doko, it's my box, I did gcc-<tab> I didn't notice gcc-4.5 was not installed
<doko> you have hardening-wrapper installed
<doko> which diverts gcc-4.5
<seb128> I though "the binary is there so it must be installed"
<seb128> doko, danke ;-)
<tumbleweed> doko: I was assuming you'd see bug 915167 before it was noticed on the sponsor queue. It's an old release, but a trivial fix to a not entirely uncommon usecase
<ubottu> Launchpad bug 915167 in python-defaults (Ubuntu Natty) "pycompile will use /usr/local/bin/python2.6 if available and python2.6 isn't installed." [Medium,New] https://launchpad.net/bugs/915167
<doko> tumbleweed, we'll remove python2.6 before release
<tumbleweed> doko: that was a natty dh_python2 with a local python2.6 installed problem
<tumbleweed> zul: err, looks like your mtx and netifaces merges yesterday don't actually contain anything useful. Sync next time?
<doko> cjwatson, apw: what is our policy to ship separately buit kernel modules? I know that we do that for restricted modules, but is this accept for other dkms modules in main?
<apw> i am unsure if there is a policy, cirtainly we have had other dkms packages around, there was an iscsi one for some time
<doko> apw, looking at the openvswitch package
<cjwatson> IIRC it's OK strictly provided that they're dkms
<cjwatson> we've removed non-dkms ones in the past because we couldn't maintain them
<cjwatson> do look into whether they're going to be kept well up to date though ...
<apw> openvswitch is the openstack transport isn't it ?
<doko> so this comes with a openvswitch-datapath-source *and* a openvswitch-datapath-dkms binary package
<doko> yes
<pitti> that looks broken indeed
<apw> yeah if its dkms its usually liveable with, and often if it is version tied with userspace having them in the same package is better
<pitti> usually, a dkms "binary" package sohuld just ship the source tarball and dkms control script
<pitti> but it should be arch: all then
<pitti> ah, openvswitch-datapath-dkms is, looked at the wrongone
<Daviey> Hmm
<doko> so we should stop building openvswitch-datapath-source?
<pitti> it looks a little redundant
<pitti> but it seems -source would integrate with module-assistant
<pitti> whiel -dkms auto-builds with dkms
<Daviey> right, what benefit do we get from changing t?
<Daviey> it?
<pitti> we certainly shouldn't start supporting module-assistant in main
<zul> delta with debian
<pitti> but I guess we can leave that binary in universe?
<Riddell> jdstrand: security team onto this? http://packetstormsecurity.org/files/109230/advisory_sudo.txt
<Daviey> doko / pitti: if you want to increase our delta with Debian, are your teams happy to take ownership for it? :)
<doko> Daviey, the MIR team doesn't take ownership of anything ;-P
<Daviey> heh
<pitti> Daviey: err, I wasn't suggesting to change it, just thinking aloud why there are two, and that -source should stay in universe
<Daviey> Yeah, really - what i am saying, changing the current package; does it increase the maintainability?
 * Daviey feels no
<pitti> *nod*
<MacSlow> pitti, poing
<pitti> hello MacSlow
<MacSlow> pitti, just wondering if Oneiric will also get the newer libwnck3 at some point (in regards to your wnck_shutdown branch for notify-osd)
<pitti> MacSlow: no, it won't
<MacSlow> ok
<pitti> MacSlow: but the merge proposal checks the availability during configure
<pitti> MacSlow: so it will build fine with older wnck versions
<MacSlow> pitti, sure I've seen that
<MacSlow> pitti, was just curious
<pitti> MacSlow: oh, you want it for testing?
<pitti> MacSlow: I can certainly give you an oneiric build if you want one
<pitti> it just won't go into oneiric officially
<MacSlow> pitti, today I've my notify-osd maintainer hat on again... doing as much as I can on that front atm
<pitti> nice!
<doko> Riddell, bug #918289, do we consider ttf as a source format?
<ubottu> Launchpad bug 918289 in fonts-kanjistrokeorders (Ubuntu) "[MIR] fonts-kanjistrokeorders" [Undecided,New] https://launchpad.net/bugs/918289
<doko> and I assume the missing sources for the pdf files are a debian rc issue.
<Riddell> doko: it's not ideal but yes it can be considered preferred modifiable form
<Riddell> doko: yes PDF files should be taken seriously by debian and ubuntu
<Riddell> (plenty of fonts only have .ttf files even though it's not really preferred modifiable form, like the ubuntu one)
<doko> Daviey, could you have a look at bug #891232, it it's an issue for libvirt?
<ubottu> Launchpad bug 891232 in numactl (Ubuntu) "[MIR] numactl" [Undecided,Confirmed] https://launchpad.net/bugs/891232
<Daviey> looking doko, thanks
<Daviey> doko: Serge Hallyn is the libvirt maintainer for Ubuntu.. If he feels it is, then i'm going to agree with him. :)
<Daviey> (he raised the MIR)
<doko> Sweetshark, ping on bug #906402
<ubottu> Launchpad bug 906402 in graphite2 (Ubuntu) "[MIR] graphite2" [Undecided,Incomplete] https://launchpad.net/bugs/906402
<Daviey> doko: a heads up, roaksoax has at least 6 python modules which need to be MIR'd once they've passed NEW.
<doko> Daviey, I hope I'm already travelling when these are accepted ;-)
<Daviey> Yeee Haaa!
<doko> Daviey, zul: opened a runit task for bug #801244
<ubottu> Launchpad bug 801244 in runit (Ubuntu) "[MIR] vblade-persist" [Undecided,Incomplete] https://launchpad.net/bugs/801244
<Daviey> thanks doko
<soren> Daviey, zul: You guys still care about aoe support? Really?
<Daviey> soren: I was waiting for zul to to discuss that. :)
<soren> Daviey, zul: Do you still carry the driver?
<soren> Daviey: It was removed from Nova months ago.
<Daviey> I honestly didn't know.
<Daviey> soren: no, we do not
<Daviey> infact, i /thought/ we suggested switching?
<soren> https://github.com/openstack/nova/commit/eb03d47fecd3bfc24243da29ee01679b334a08fe
<seb128> doko, do you have any clue why building launchpad.net/lightdm-gtk-greeter/trunk/1.1.1/+download/lightdm-gtk-greeter-1.1.1.tar.gz on precise doesn't hit those bugs
<seb128> https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/898134
<Daviey>   * Stop depending on aoetools. iscsi is the default nowadays (and has
<Daviey>     been for a while).
<ubottu> Ubuntu bug 898134 in LightDM GTK+ Greeter "lightdm-1.1.0 fails to build with: undefined reference to symbol 'XClearWindow'" [Medium,Fix committed]
<Daviey> soren: that was a change you made in natty!
<seb128> doko, or https://bugs.launchpad.net/lightdm/+bug/916477 (which seems to happen on the debian toolchain)
<ubottu> Ubuntu bug 916477 in Light Display Manager "gio-2.0 missing from liblightdm-gobject-1.pc" [Medium,Incomplete]
<soren> Daviey: Go me!
<seb128> doko, well on gold on debian, i.e https://launchpadlibrarian.net/91537462/01_fix-configure-dso-linking.patch is required on Debian apparently where the same source builds fine in precise
<doko> seb128, is it correct that it tries to link the static lib?
<seb128> doko, dunno, that doesn't happen here, but I would think that the first bug (the missing -lx11) would stop the build
<seb128> doko, I'm not sure to understand the gio one and why the .a is listed there
<seb128> doko, hum, I wonder if the gio issue has something to do with "checking if gcc static flag -static works... no" in the debian build log
<doko> seb128, well, have a look at the config.log
<doko>   CCLD   liblightdm-gobject-1.la
<doko>   GISCAN LightDM-1.gir
<doko> seb128, ^^^ could you make this verbose in the build log?
<manish> any idea why using --prefix=/usr in distutils starts installing packages in site-packages?
<manish> shouldn't it install in dist-packages?
<seb128> doko, I will ask details to the debian maintainer (who opened the bug) or try in a pbuilder thanks, I'm still a bit confused that the missing -lx11 doesn't stop the build though
<doko> manish, you should not use --prefix=/usr. what do you want to achieve?
<manish> right now I am trying to install software-properties
<manish> it installs in /usr/local
<manish> and does not get picked up properly
<manish> when I run it
<doko> whwere it belongs to, if you install it on your own
<mhall119> ev: ping
<jdstrand> Riddell: re sudo> yes. It only affects precise and our hardening measures mitigate it until a merge from Debian
<Riddell> jdstrand: I knew we could count on our security team :)
<jdstrand> :)
<ev> mhall119: pong
<mhall119> ev: hi, I'm in need of some help that I was told you can provide
<mhall119> I need a list of the "top 50" apps in software center
<mhall119> I'm told we don't have download stats, but we do have ratings
<mhall119> so I'm thinking those with the most positive ratings
<ev> mhall119: alas, I'm not the person who is responsible for the ratings and reviews server
<ev> mhall119: mpt says there's already a top rated section.  Just click "more" next to top rated inside software center.
<mhall119> mpt: any way I can easily convert that to a list of text, rather than manually writing them down?
<mpt> mhall119, kiwinote or one of the other developers in #software-center could probably give it to you as Json, at least
<mhall119> thanks mpt
<dholbach> mhall119, highvoltage, hggdh, SpamapS, cyphermox: ready for later on? :)
 * mhall119 is always ready
<mhall119> (but not always prepared)
<quadrispro> hi all!
<astraljava> Hi Alessio!
<hggdh> dholbach: aye
<hggdh> and darn!
<highvoltage> dholbach: I think so! I have a tomboy note with a bunch of things to say ready. I think it can full up some 25 minutes and then the rest is for questions
<dholbach> excellent :)
<tgardner> skaet, have you noticed that the screen lock isn't working after a resume? Is this a known bug?
<pitti> tgardner: not known here; it still worked two weeks ago, at least
<tgardner> pitti, 4 of us k-team dudes have noticed it
<pitti> mdeslaur did two recent gnome-screensaver uploads
<pitti> the changelog entries look related, anyway
<pitti> mdeslaur: does locking after suspend work for you?
<mdeslaur> pitti: yes...
<mdeslaur> tgardner: what desktop environment are you using?
<mdeslaur> tgardner: how are you suspending?
<pitti> hm, doesn't seem to lock here
<tgardner> mdeslaur, unity on precise
<pitti> I tried with "suspend" in the indicator
<mdeslaur> tgardner: do you have autologin enabled?
<smb> there is another environment than unity...? :-P
<tgardner> mdeslaur, nope
<pitti> (my computer is closed in the dock, can't try lid right now)
<smb> mdeslaur, not here
<pgraner> mdeslaur, not here either
<apw> mdeslaur, for me its either shut lid or menu ... both do not trigger the saver, and using normal passworded login
<mdeslaur> hrm, ok, let me try
<mdeslaur> stupid screen locking whack-a-mole
<pitti> gnome-screensaver-command -l does work here, though
<pitti> so, of course it could also be a regression in gnome-session
<smb> pitti, It also locks after time for me
<pitti> no, didn't change since December
 * pitti checks settings-daemon
<mdeslaur> pitti: yes, I changes settings-daemon also
<cking> at least s3 resume is quick now ;-)
<pitti> ah, could be http://launchpadlibrarian.net/91320909/gnome-settings-daemon_3.2.2-0ubuntu12_3.2.2-0ubuntu13.diff.gz
<pitti> that seems fairly devensive, too, though
<pitti> defensive
<mdeslaur> let me dist-upgrade my test laptop and try to reproduce
<doko> jodh, are the upstart build failures on armhf and powerpc real, or temporary?
<jodh> doko: may be kernel-related (since as cjwatson observed those platforms have newer kernels). I'd started to investigate but now 100% on bug922754. Will return to that asaic.
<doko> thanks
<mdeslaur> ARGH, I can reproduce...wth
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 14 minutes in #ubuntu-classroom
<herton> pitti, hi, can you take a look when possible at copying kernels from bug 922692 to -proposed? I need it to start bugging people to verify SRU bugs this week.
<ubottu> Launchpad bug 922692 in linux (Ubuntu) "linux: 3.0.0-16.28 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/922692
<jdstrand> pitti: hi! I'm told you are able to do this: would you mind rejecting https://code.launchpad.net/~l3on/ubuntu/oneiric/usbmuxd/security-919435/+merge/90611 and https://code.launchpad.net/~l3on/ubuntu/natty/usbmuxd/security-919435/+merge/90612?
<pitti> jdstrand: done
<pitti> herton: can do
<jdstrand> pitti: heh, that was fast. Thanks! :)
<herton> pitti, thanks
<skaet> tgartner, mdeslaur - ack,  is there a bug number?
<l3on> jdstrand, I read your reply... thanks, now I see :)
<mdeslaur> skaet: not yet, I'll open one in a sec
<skaet> mdeslaur, thanks!
<pitti> herton: done
<mdeslaur> ok, GAH!
<mdeslaur> pitti, skaet, smb: ok, found it...uploading a fix in a few minutes
<smb> apw, tgardner cking ^ :)
<pitti> mdeslaur: cheers!
<cking> YAY
<smb> mdeslaur, yes, ta
<skaet> mdeslaur, :D
<mdeslaur> skaet: LP: 924336
<skaet> thanks
<jdstrand> l3on: thank you! :)
* ChanServ changed the topic of #ubuntu-devel to: new topic Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* ChanServ changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> cjwatson, is that normal that I just got an "[ubuntu/oneiric-updates] evince 3.2.1-0ubuntu2.2 (Accepted)" email?
<cjwatson> New normal, yes :-)
<cjwatson> You uploaded it, right?
<seb128> hum, did launchpad start sending emails on pocket copies?
<cjwatson> I changed sru-release to do copies differently
<seb128> cjwatson, yes, to proposed some time ago which I got an email for at this time
<cjwatson> The old method didn't send mail; this one does - but that wasn't the reason to change, the reason is that this method is asynchronous so shouldn't time out all the time like the old one did
<seb128> cjwatson, ok, it confused me for a moment, I was wondering if you reuploaded because I screwed something ;-)
<cjwatson> It's a bit annoying that the mail shows up as from me: https://lists.ubuntu.com/archives/oneiric-changes/2012-January/011816.html
<seb128> since the emails lists you in the "Signed-By"
<cjwatson> But not the end of the world I guess
<cjwatson> Yeah, it's like new-style syncs
<seb128> cjwatson, ok, that's fine, I just got surprised
<cjwatson> signed ~= requested
<seb128> cjwatson, maybe it's worth dropping a note about on the list in case others get confused as well
<cjwatson> I agree the presentation isn't entirely ideal but I figure people will get used to it :)
<cjwatson> mm, could be
 * cjwatson adds to todo
<seb128> cjwatson, thanks ;-)
<cjwatson> I suppose we could do the syncs as the katie user, which would inhibit the mail
<cjwatson> I might test that
<cjwatson> something like http://paste.ubuntu.com/823985/
<seb128> cjwatson, I'm not sure the email is an issue, it tells you that the updated got verified and moved so it can be useful informations, the change of behaviour is just a bit confusing (as any change ;-)
<cjwatson> This is true.  The Signed-By is kind of odd though.
<doko> zul, just to confirm, you did the packaging for python-keystoneclient, didn't you?
<zul> yeah
<doko> exactly, not mentioned in debian/copyright. only the upstream apache license is mentioned
<doko> so add debian/*
<zul> doko: ok ill go fix that then
<doko> and the appropriate copyright
<doko> thanks
<zul> doko: added
<smoser> anyone know what it is that creates /dev/loop[0-7]
<smoser> it seems that with current precise kernel, we can have up to /dev/loop255
<smoser> (previously that required adding 'max_loop=')
<highvoltage> smoser: /etc/udev/links.conf
<smoser> i dont have such a file
<smoser> :)
<smoser> maybe udev is responding to CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 (kernel config)
<broder> smoser: iirc the loop module does that on its own at load
<smoser> its builtin now. so it just must be the kernel adding devices on the initialization of that driver
<smoser> and udev responding perhaps ?
<broder> why does udev need to respond?
<smoser> and the min being setup by that config.
<smoser> broder, your suggesting it doesn't have to do anything because of devtmpfs ?
<broder> my understanding was that device nodes are generally created by the kernel
<smoser> (my knowledge is fuzzy here, but prior to devtmpfs i did not think that was the case)
<broder> and then udev is just responsible for figuring out which modules need to be loaded so those modules can go and create the device nodes themselves
<smoser> well, prior to devtmpfs, /dev was either a general tmpfs or a "normal(ext3)" filesystem  (or devfs) so the kernel wasn't just creating nodes int he filesystem.
<broder> smoser: you can see the loop driver creating the nodes when it initializes: http://lxr.linux.no/linux+v3.2.2/drivers/block/loop.c#L1813
<broder> i couldn't tell you how exactly it does it, but it definitely does
<pgraner> cjwatson, quick question, have you seen 11.10 server iso issues when booting from USB stick, it boots but won't find the cdrom drive
<pgraner> cjwatson, which is a strange since it doesn't have one on this box
<cjwatson> pgraner: can I have logs please?
<pgraner> cjwatson, sure which ones?
<cjwatson> syslog and partman
<cjwatson> well actually just syslog for this I guess
<pgraner> cjwatson, ack
<cjwatson> also does precise work?
<pgraner> cjwatson, haven't tried precise yet, I was installing and they planning on testing the upgrade :(
<pgraner> cjwatson, ok so I have no network and it won't see USB sticks
<cjwatson> well I need some way to see what's going on
<pgraner> cjwatson, the error is: cdrom-detect: CD-ROM mount failed: device=/dev/sr0 fstype=iso9660
<cjwatson> you could try booting the precise installer and walking through the installer up to that point, you don't have to actually do an install
<cjwatson> mm, usually need a screenful of context
<pgraner> cjwatson, ok I'll snap a pic
<cjwatson> also how did you create the USB stick?
<pgraner> cjwatson, dd
<cjwatson> ok
<cjwatson> from tty2, run 'list-devices maybe-usb-floppy; list-devices usb-partition'
<pgraner> cjwatson, both return no output
<cjwatson> well that sucks.  does the kernel actually know about any USB devices?
<pgraner> cjwatson, its sees the keyboard & mouse
<pgraner> cjwatson, not the usbstick
<pgraner> cjwatson, email sent with screen shot
<cjwatson> try booting a live CD and see what driver it uses for the USB stick
<cjwatson> er a live USB stick
<cjwatson> the kernel packaging needs to deliver that to the installer in some appropriate udeb
<pgraner> cjwatson, ok let me get one downloaded and I'll give it a shot
<cjwatson> looking specifically for the ones in usb/host I guess
<pgraner> cjwatson, ok booted,  and it looks like the livecd is using xhci-hcd
<cjwatson> pgraner: ok, so I think the right answer is to file a kernel bug asking them to add xhci-hcd to the usb-modules udeb (I checked; it isn't there)
<pgraner> cjwatson, ack, thanks
<vanhoof> pgraner: what did you have going on w/ usb3?
<bdmurray> jodh: bug 916507 looks like it is similar to bug 849414
<ubottu> Error: Launchpad bug 916507 could not be found
<ubottu> Launchpad bug 849414 in plymouth (Ubuntu Precise) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/849414
<vanhoof> pgraner: been seeing a few machines lately when usb3 is set to "auto" mode in the bios, it'll default to usb2, but when set to "enabled" it'll go usb3
<pgraner> vanhoof, the server iso doesn't have xhci in the usb-modules udeb so you can't install off a usb3 port from usb stick
<vanhoof> pgraner: ah
<vanhoof> pgraner: see if usb3 work for you once installed too
<astraljava> stgraber: Hiya, Studio wants to create a similar feature in ubiquity, that edubuntu uses. My problem is that I can't find the original source branch, that stores the ubiquity/plugins/*.py files. If you have time at some point, could you point me to the right tracks, please? Thanks!
<vanhoof> pgraner: and if not, see if you have that same bios toggle
<vanhoof> pgraner: been coming up in a few new bugs this week
<astraljava> Well, Studio as well as Xubuntu.
<stgraber> astraljava: the package selection stuff is in edubuntu-live
<astraljava> stgraber: lp:ubuntu/edubuntu-live? I was just told that it gets created on upload. So I don't get where the upload gathers the stuff from.
<stgraber> astraljava: that's indeed the branch. It's a UDD branch, uploads are automatically commited to it and people with upload rights can also commit changes to it without uploading
<astraljava> stgraber: Ok, so how would Studio and Xubuntu get similar branches, then? I see that that branch is owned by Ubuntu branches (team?).
<stgraber> astraljava: http://developer.ubuntu.com/packaging/html/udd-intro.html
<stgraber> astraljava: for now, just copy the python scripts to your own package, that's the easiest
<astraljava> stgraber: Ok, thanks!
<pgraner> vanhoof, will do
<arges> cyphermox, hello! are you the patch pilot today?
<cyphermox> arges: I am
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<arges> cyphermox, so I think I got almost everything needed for an SRU here: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/828731  . was wondering if you could take a look and see if it looks ok.
<ubottu> Ubuntu bug 828731 in kexec-tools (Ubuntu Oneiric) "kdump functionality not working as expected when /boot is a separate partition" [Medium,In progress]
<cyphermox> arges: alright
<arges> cyphermox, thanks
<cyphermox> arges: so, comments:
<cyphermox> arges: bug 828731 was needing ubuntu-sru subscribed, I added it. I can't upload kexec-tools though, so I'll have to defer to somebody else to sponsor it, but it looks correct (and has apparently already had testing)
<ubottu> Launchpad bug 828731 in kexec-tools (Ubuntu Oneiric) "kdump functionality not working as expected when /boot is a separate partition" [Medium,In progress] https://launchpad.net/bugs/828731
<cyphermox> arges: however, you're also closing bug 785425 in your changelog, so that one too should have ubuntu-sru subscribed, with an SRU rationale, and targetted to the releases
<ubottu> Launchpad bug 785425 in kexec-tools (Ubuntu) "0_kdump uses dynamic makedumpfile(8) binary, which fails horribly" [Medium,Fix released] https://launchpad.net/bugs/785425
<arges> cyphermox, ok i will check that too. how do I have ubuntu-sru subscribed?
<cyphermox> on the lp page, click subscribe someone else and search for ubuntu-sru
<arges> ok
<jodh> bdmurray: thanks for pointing that one out. I'm pretty sure all these plymouth bugs have a common cause.
<Atlantic777> Are ubuntu testing and ubuntu development the same release?
<cyphermox> Atlantic777: yes
<cyphermox> We're testing a milestone of the development release
<Atlantic777> So 12.04 is the newest release I can get?
<Atlantic777> actually it's not a release until it's released :D
<cyphermox> It is, though you should really only "use" it if you're confortable with things breaking every once in a while
<cyphermox> Atlantic777:  unless you want to help with the testing, in which case I'd invite you to join #ubuntu-testing
<Atlantic777> cyphermox: I'm interested both in testing and development of new ubuntu stuff...
<cyphermox> you're at the right place.
<cyphermox> if you want to learn how to do it then visit #ubuntu-classroom, this week it's Ubuntu Developer Week and we show how you can fix things
<Atlantic777> I'am already there. :)
<cyphermox> sorry, I didn't see ;)
<doko> zul, keystoneclient ftbfs
<zul> doko: damn it...
<zul> doko: ill get to it tonight
<doko> zul: disable the argparse check. it's included in python2.7
<zul> doko: yeah
<simmel> SpamapS: That's kind of why I didn't ask the question during the talk also = )
<SpamapS> simmel: CDBS stands alone, without debhelper, though it can help with debhelper rulesets. The key there is, with debhelper 7, thats not necessary
<directhex> cdbs /o\
<SpamapS> simmel: http://en.wikipedia.org/wiki/Debhelper
<SpamapS> simmel: see the 3 line rules file? That is a new thing.. before that, CDBS was the quickest way to be able to have something similar.
<SpamapS> simmel: I have to run now, but I'm sure you'll find lots of people who can help here. :)
 * simmel gets confused with the debhelper.mk in CDBS and actual debhalper.
<simmel> SpamapS: Thanks again.
<jtaylor> those small rules usually go by the name dh-7
<directhex> dh7 \o/
<jtaylor> saying only debhelper is a bit confusing as most of cdbs also calls dh_* stuff
<jtaylor> just all hidden in undocumented black magic
<slangasek> we should just start calling cdbs 'debhinderer' ;)
<simmel> It's not black magic if you know how to use it ; )
<simmel> One other reasons that I'm confused is because https://wiki.ubuntu.com/PackagingGuide/Complete mentions CDBS alot and not any mention that it shouldn't be used.
<slangasek> yes, not distinguishing between best practices and "things you have to deal with if you're going to be an Ubuntu developer" is a major failing of the documentation
<simmel> https://wiki.edubuntu.org/PackagingGuide/Python#The_debhelper_way looks preetty good though.
<slangasek> https://wiki.ubuntu.com/PackagingGuide does say to use http://developer.ubuntu.com/packaging/html/ instead
<slangasek> we should probably nuke /Complete, at this point
<simmel> Oh! Is there a Complete/All-pages version of that? Except Show source?
<slangasek> I'm not sure
<slangasek> barry: hey, do you know if there's a pdf version of http://developer.ubuntu.com/packaging/html/ ?
<simmel> Sorry for beeing lazy here, totally OK to reprimand me, but was debhelper >= 7 available in lucid or earlier or is it a new thing?
<jtaylor> its available in lucid
<simmel> cool, thanks jtaylor.
<barry> slangasek: i don't, but it wouldn't be hard to generate, from the trunk branch (`make pdf` should do it).  i can check, since i'm updating that branch for the new udd stuff as we speak (i have a session tomorrow)
<simmel> I will discuss this with my colleagues tomorrow and see if we can't use the new debhelper way. Also, probably should fix our Hudson buildslaves to use sbuilder instead of pbuilder too = )
<barry> slangasek: make latexpdf
<simmel> barry: Is there a single .html-file available aswell? Or is .txt and .pdf the only single-page versions?
<barry> simmel: it's sphinx so there are several options.  bzr branch lp:ubuntu-packaging-guide then run 'make' no options to see what you can generate
<simmel> barry: Thanks, I'll check it out tomorrow. Thanks everyone and good night.
<poolie> hi barry
<barry> poolie: hi
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cyphermox> logging off for dinner, I'll be back in a few hours and do more piloting
<lamont> ScottK: 2.9.0, eh?
<lamont> guess I have something to do later this week
<lifeless> barry: can land plox http://bugs.python.org/issue6598
#ubuntu-devel 2012-02-01
<ScottK> lamont: Yes.  Please.
<micahg> lamont: if you're doing Debian uploads, nmap 5.5.x would be nice :)
<Q-FUNK> say, I don't wanna sound pushy, but I've actually had to bork the dynamic /etc/resolv.conf from 2 of my 3 Precises hosts, otherwise, DNS plain doesn't resolve.
<cyphermox> Q-FUNK: can you describe the kind of setup?
<cyphermox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
<cyphermox> e.g. is it using NetworkManager, do you have static interfaces defined in /e/n/i, etc.
<Q-FUNK> cyphermox: one host has exactly one ethernet.  same result whether I directly use dhclient or via n-m.  loopback fails to resolve to the outside world.
<cyphermox> Q-FUNK: you shouldn't have anything set for loopback via dhclient directly
<Q-FUNK> cyphermox: the other one has two ethers, one using dhclient, one with a fixed IP to serve my LTSP clients, both configured  via /etc/network.
<Q-FUNK> cyphermox: you misread me.  resolvconf puts loopback as the only nameserver host.
<cyphermox> Q-FUNK: for kicks, what's in /run/nm-dns-dnsmasq.conf on the system that runs NM?
 * micahg mutters something about insserv and wanders off
<cyphermox> Q-FUNK: not really. resolvconf by itself doesn't add 127.0.0.1
<cyphermox> Q-FUNK: but NM might, if it got dns servers from a dhcp client
<cyphermox> server, I mean
<Q-FUNK> cyphermox: no idea what sets that as the only nameserver, but I know that if I purge resolvconf, I get the normal DNS servers sent by DHCP there.
<cyphermox> you should compare these DNS servers with whatever is in /run/nm-dns-dnsmasq.conf on the system that runs NM, your answer possibly lies there.
<Q-FUNK> cyphermox: on the host running n-m, /run/nm-dns-dnsmasq.conf  is what I should expect from the DHCP server.
<cyphermox> good
<cyphermox> so then is dnsmasq running?
<cyphermox> (or even installed)
<cyphermox> Q-FUNK: or is anything else listening on udp/tcp 53 acting as a caching nameserver, like bind for instance?
<Q-FUNK> dnsmasq seems to be running
<cyphermox> and doing something like "dig @127.0.0.1" results in a NOERROR with no answers, a REFUSED, or NXDOMAIN response?
<Q-FUNK> that replies with all the root servers
<cyphermox> Q-FUNK: then shouldn't things be working properly? I'm not sure I understand what the issue is then
<Q-FUNK> cyphermox: doing 'apt-get update' replies with cannot resolve host archive.ubuntu.com
<cyphermox> isn't "dig archive.ubuntu.com @127.0.0.1" working?
<cyphermox> (unless you don't have 127.0.0.1 in /etc/resolv.conf?)
<Q-FUNK> i only have that in there
<Q-FUNK> much more worrysome is the host controlled by /etc/network/interface: dnsmasq doesn't show in 'ps'
<cyphermox> sorry, I'm having a bit of trouble grasping exactly what might be going wrong if you can reach the loopback nameserver via dig, /etc/resolv.conf has 127.0.0.1 and all, unless the external nameservers just can't resolve archive.ubuntu.com (which would be something out of my control, really)
<cyphermox> Q-FUNK: on that other host NM isn't running at all?
<cyphermox> if not, I don't know what adds 127.0.0.1 to /etc/resolv.conf. you mentioned a switch or option to dhclient for that in a bug, maybe that's enabled?
<cyphermox> there's no point in having such an option enabled if there is no nameserver running locally to grab the requests and parsing/sending them out
<Q-FUNK> that's on another host; the only one on which resolvconf works as expected, oddly enough.
<cyphermox> anyway, on all systems the main idea is to see what 127.0.0.1 responds as far as the host you're interested in goes. so if "dig archive.ubuntu.com @127.0.0.1" works for any such system, and that's that IP is the only thing in /etc/resolv.conf, then I don't see why things wouldn't just work
<Q-FUNK> that's just it. on the host controlled by /etc/network/interface, dig returns nothing
<cyphermox> nothing at all or an error?
<Q-FUNK> dnsmasq doens't run on it, either
<Q-FUNK> ; <<>> DiG 9.8.1-P1 <<>> archive.ubuntu.com @127.0.0.1
<Q-FUNK> ;; global options: +cmd
<Q-FUNK> ;; connection timed out; no servers could be reached
<cyphermox> aye
<cyphermox> that's expected if dnsmasq isn't running
<cyphermox> (or any other process on port 53 to shepherd dns requests)
<cyphermox> now then, why could resolv.conf be getting 127.0.0.1.
<cyphermox> Is this written anywhere in /etc/resolvconf/* ?
<cyphermox> you should also make sure it's not coming from a file in /run/resolvconf/interface (which is where things speak with resolvconf) and that /etc/resolv.conf is a symlink to /run/resolvconf/resolv.conf (which will make sure you're really looking at resolvconf writing that entry)
 * cyphermox thinks we ought to figure out a way to include some such debug information in an apport hook for resolvconf, without including personal info
<Q-FUNK> lrwxrwxrwx 1 root root 27 helmi  1 05:09 /etc/resolv.conf -> /run/resolvconf/resolv.conf
<Q-FUNK> and /run/resolvconf/interface/eth0.dhclient has exactly what the dhcp server sent.
<Q-FUNK> ah, wait.  dnsmasq-base is used by nm, right? since I don't have any interface controlled by nm, could this be why dnsmasq isn't running?
<cyphermox> yes, dnsmasq ought to be started by /something/
<cyphermox> but if everything is controlled outside NM, is that running at all?
<Q-FUNK> that runs, but without anything launching dnsamasq, we cannot call home
<cyphermox> is there a /run/resolvconf/interface/NetworkManager file?
<cyphermox> or see if /var/log/syslog mentions NM updating nameservers
<Q-FUNK> none
<cyphermox> something like NetworkManager[1194]: <info> (wlan0): writing resolv.conf to /sbin/resolvconf in /var/log/syslog
<cyphermox> might mean you're seeing a side-effect of NM considering unmanaged interfaces as up
<cyphermox> but if there is no NM file in /run/resolvconf/interface, it's probably not it
<Q-FUNK> there isn't any
<Q-FUNK> Feb  1 04:03:40 voito dnsmasq[1090]: failed to access /var/run/dnsmasq/resolv.conf: Tiedostoa tai hakemistoa ei ole
<Q-FUNK> : file not found
<Q-FUNK> could it be that dnsmasq-base forgot to create /var/run/dnsmasq upon install?
<Q-FUNK> I grep'ed for occurences of resolv.conf
<Q-FUNK> Feb  1 05:34:19 voito NetworkManager[511]: <info> DNS: starting dnsmasq...
<Q-FUNK> Feb  1 05:34:19 voito dnsmasq[708]: no interface with address 127.0.0.1
<Q-FUNK> Feb  1 05:34:19 voito dnsmasq[708]: FAILED to start up
<Q-FUNK> Feb  1 05:34:30 voito NetworkManager[511]: <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2)
<Q-FUNK> I wonder what would cause that?
<cyphermox> well, looks like as a minimum, you're missing lo in /etc/network/interfaces
<cyphermox> (or anyway, why would dnsmasq find that there is no interface with 127.0.0.1?)
<Q-FUNK> no, it's there
<Q-FUNK> it appears in 'ip addr' too
<cyphermox> ok
<cyphermox> doesn't /var/run/dnsmasq exist?
<Q-FUNK> nope
<Q-FUNK> dnsmasq-base ships with /var/run, rather than with /var/run/dnsmasq
<Q-FUNK> either way, since this is /var/run content, it would need to be dynamically created by the init script at bootup.
<cyphermox> yes
<cyphermox> or by the application itself
<Q-FUNK> in this case, most probably by nm
<Q-FUNK> cyphermox: confirmed. dnsmasq won't really be launched unless at least one interface is managed by n-m.
<cyphermox> right, but NM won't be adding 127.0.0.1 to /etc/resolv.conf either then
<cyphermox> (otherwise it would be adding a log about it in changelog)
<cyphermox> err, syslog I mean
<cyphermox> or you can file a bug about it -- I'm just wrapping things up to go to bed now
<Q-FUNK> I'm still not sure what's causing it.
<pitti> Good morning
<ajmitch> morning pitti
<cnd> I'm confused on the policy for uploading new packages to universe
<cnd> I'm a core-dev and I've reviewed a package prepared by someone else
<cnd> do I just upload it?
<cnd> or do I need to get a second advocate still?
<lifeless> AIUI just upload
<pitti> cnd: yes, just upload it
<cnd> ok
<ajmitch> pitti: syncing a new source package (ruby-erubis) that afaict is a replacement for erubis, building the same binaries - do I need to file a removal bug?
<pitti> ajmitch: yes, please do, so that we keep some documentation
<pitti> erubis is still in Debian
<ajmitch> yeah, it's still in debian, I haven't seen a removal bug filed there yet
<ScottK> cnd: The policy is should be reviewed by two developers, not must.  It's up to you.
 * YokoZar considers the implications of the multi-arch field for transitional dummy packages...
<ricotz> YokoZar, hi
<ricotz> YokoZar, i think it is useful to request the removal of the old wine binaries
<ricotz> meaning the amd64 binaries of 1.3.28-0ubuntu1 in precise
<YokoZar> ricotz: Yes, after I upload the wine1.4 package marking them as dummy packages
<YokoZar> (to my ppa that is, to confirm working)
<ricotz> YokoZar, ok :)
<ricotz> btw 1.3.37 works fine here with multiarch on amd64
<YokoZar> ricotz: yeah but that's not the win 64-bit compatible package I've done with 1.4 :D
<YokoZar> (requires some careful surgery to get both 32/64 bit compatibility with the same wineserver)
<ricotz> oh, nice, so there will be amd64 binary again then
<YokoZar> right
<YokoZar> although, your prefix (~/.wine) will still be 32 bit only unless you make a new one
<ricotz> but the multiarch way using 32bit wine on amd64 is still the right choice then`
<YokoZar> Yup
<ricotz> ok
<YokoZar> Well, sorta
<YokoZar> the 32 bit package has to be split
<YokoZar> You'll see
<ricotz> ok, thanks :)
<YokoZar> on amd64 you install wine1.4 and then it pulls everything you need.  You could also install wine1.4:i386 and avoid 64-bit compatibility if you really wanted.
<ricotz> i see, hoping for some love for lucid too ;)
<YokoZar> ricotz: Yeah I'm not sure what to do there other than PPA uploads as every Ubuntu before Oneiric will have sound issues due to broken alsa-plugins
<YokoZar> (not that they didn't have sound issues anyway)
<ricotz> yeah, i am fine with the ppa updates, sound isnt important in my case here
<ricotz> oh speaking of alsa -- diwic, hi, i hope alsa 1.0.25 will find its way into precise
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks
<diwic> ricotz, we haven't had a discussion about that, but so far I don't see any significant improvement compared to 1.0.24. (That is, talking userspace. The drivers we get from the kernel)
<ricotz> diwic, hmm ok, you are right
<ricotz> diwic, probably still worth some over-thinking
<dholbach> good morning
<infinity> doko_: Regarding "backport multiarch dpkg for lucid(we don't need this, do we?): POSTPONED"
<infinity> doko_: Surely, we need a multiarch dpkg to be able to do single->multi upgrades smoothly for, eg, ia32-libs and flash-plugin?
<infinity> doko_: (I didn't notice you made the edit to postpone it, I'm just pinging you because the spec is assigned to you)
<infinity> doko_: Err, "didn't notice who made the edit..."
<doko_> infinity, I'll talk with mvo, I just inherited this spec
<YokoZar> Does apt not know about multi-arch: allowed yet?
<YokoZar> (or depends foo:any for that matter)
<tjaalton> the NEW queue is rather long..
<tjaalton> ..though most of it is from last week or so
<tjaalton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks, tjaalton
<tjaalton> wait, I'm a week early
<tjaalton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks
<tjaalton> :)
<jasox> Hi guys, I was wondering what font size (small/normal) do you use in ubuntu on 24" monitor(16:10) ?
<jacekmigacz> Up-arrow captures printscreen on alternative WM. Does gnome-settings-daemon altering xkbmap somehow?
<Daviey> Who can fix a missing ddeb issue for Lucid?
<seb128> Daviey, what's the issue? if the build is older than a week probably nobody out of doing a no change upload to trigger a new build
<Daviey> pitti: Do you know who can add a missing ddeb?
<seb128> Daviey, the ddebs are kept for a week
<seb128> if they didn't get copied or moved during that time you will need a new build
<pitti> Daviey: we can try to fish it out of the buildd, if it has built within the past 7 days
<Daviey> seb128: waat, is that a new thing?
<pitti> it's been like that forever
<pitti> ddebs.u.c. has been a horrible temporary hack for the past n years
<Daviey> pitti: it's a lucid sru, from last August.
<pitti> Daviey: that's gone, I'm afraid; it needs a new build
<seb128> Daviey, they are kept on the builders for a week I mean, once collected they are kept on the ddeb server while the version is the current one
<seb128> but you only get a week to "collect" them
<pitti> Daviey: this is only really going to work well once LP supports them properly
<Daviey> http://ddebs.ubuntu.com/pool/main/a/autofs5/ <-- has lucid release, but not -updates :/
<Daviey> seb128: Oh, someone needs to request them to be copies across?
<Daviey> pitti: Thanks.
<seb128> Daviey, there is a service doing that but it bugged and it's over a week since the build it's too late to sort it out without a rebuild
<pitti> Daviey: no, there are no manual requests
<pitti> Daviey: but ddebs.u.c. hit -ENOSPC often, or the apache on the buildds tend to time out, etc.
<Daviey> ah, right
<Daviey> It's going to be easier to just provide a ddeb out of band :)
<pitti> you need the accompanying .deb, too
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox, didrocks, kenvandine
<cjwatson> mvo: bug 924079 - do you think we need a release-upgrader-apt backport for oneiric as well, or would it be better to try to isolate the fix?
<ubottu> Launchpad bug 924079 in apt (Ubuntu) "do-release-upgrade fails to upgrade from Oneiric to Precise" [High,Confirmed] https://launchpad.net/bugs/924079
<cjwatson> I suppose isolating the fix would help apt-get dist-upgrade users
<cjwatson> definitely something wrong with unpack ordering and M-A: same packages
<dholbach> dpm, m_3, tumbleweed, barry, Laney: ready? :)
<dpm> dholbach, it's in 1h, right?
<dholbach> yep
<Laney> hmmm, I will be by 8pm :P
<Laney> dholbach: the formatting of the logs on the wiki is annoying, can that be improved?
<Laney> horizontal scrolling ...
<dholbach> https://bugs.launchpad.net/ubuntu-website/+bug/812337
<ubottu> Ubuntu bug 812337 in Ubuntu Website "Ubuntu Wiki: IRC style formatting needs a "word-wrap: break-word"" [Undecided,New]
<Laney> nice
<dholbach> sladen seems to be in touch with whoever is responsible
<cjwatson> mvo: I've isolated it to a single fix, although, as you may have guessed, it's Chris Baines' GSoC work on unpack/configure ordering
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks, kenvandine
<mvo> cjwatson: thanks! in a call right now - I assumed that its in there, it is probably difficult to backport that in isolation :/
<cjwatson> mvo: I think I'll take this to mail, it's quite complex :)
<mvo> ok
<cjwatson> mvo: it actually applies cleanly in isolation to oneiric, but I'm not sure about ABI implications
<mvo> aha, cool
<mvo> if you pastebin the diff I'm happy to have a look
<cjwatson> http://paste.ubuntu.com/825133/ - it changes protected members of pkgPackageManager, which I think aren't actually used in practice by binaries but I suspect that technically they may form part of the ABI
<cjwatson> I suppose one of the bazillion things wrapping libept might inherit from that class
<cjwatson> er, s/libept/libapt/
<mvo> cjwatson: yeah, but that looks not too scary, after the call I can do some poking on it to see if we can get it done in a abi compatible way
<mvo> thanks a bunch cjwatson!
<cjwatson> OK, I'll take it to mail and we can see
<mvo> ok
<barry> dholbach: mostly! it would be great to get that upg branch published by then.  i'll address the review this morning
<dholbach> barry, excellent
<dholbach> barry, I'm a bit busy right now - maybe somebody else can help review it?
<barry> dholbach: poolie reviewed it last night (which is great b/c there's lots of bzr stuff in there).  i think i have perms to land it after fixing his issues, but not to push them out to web
<dholbach> barry, dpm has access, but might be busy with his session in a few minutes
<barry> dholbach: no worries, my session is in 4h so i'll ping dpm a little later
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek day 2 starting in 10 minutes in #ubuntu-classroom
<dpm> barry, dholbach, sounds good
<dholbach> dpm, lass den cronjob einfach alle 30m laufen ;-)
<zul> doko_: python-keystoneclient should be fixed now
<dpm> dholbach, ;-)
<doko_> zul, \o/
<zul> stupid vitualenv
<m_3> dholbach: yup, I'm on at 1700UTC
<dholbach> m_3, excellent
<ali1234> mvo: ready when you are
<mvo> ali1234: hello - if you run "sudo apt-get update; sudo apt-get instlal -f" does that fix the issue you were seeing?
<ali1234> no
<ali1234> well, not unless there's a update released in the past few hours that fixes it
<ali1234> yeah, as before, that does nothing
<mvo> ali1234: could you paste(bin) the output of "apt-cache policy openjdk-6-jre-headless:i386 openjdk-6-jre-headless" please (this is bug #924096 right?)
<ubottu> Launchpad bug 924096 in openjdk-6 (Ubuntu) "update-manager wants to install openjdk-6-jre:i386" [Undecided,New] https://launchpad.net/bugs/924096
<ali1234> yes
<ali1234> mvo: http://paste.ubuntu.com/825183/
<mvo> ali1234: hm, that looks right on that level
<ali1234> yes, apt-get etc does not want to install the i386 package. only update-manager
<ali1234> there is some history n this too
<ali1234> this was a upgrade from oneiric. after upgrading, all the java packages were still installed, however there was no "java" in the path
<ali1234> as if no alternative was selected (not really familiar with how that works)
<ali1234> also looking at the list of installed files for the jre packages gave "file lists only available for installed packages" in synaptic, however, apt and synaptic both claimed that the packages were installed in other parts of their UIs
<ali1234> so i purged everything and reinstalled
<ali1234> then update manager started wanting to install the i386 package
<ali1234> so maybe i have some old oneiric files left behind that are messing it up?
<mvo> ali1234: you can run apt-get install -o Debug::pkgDepCache::AutoInstall=true install -f to see what is trying to install the java packages that might already help a bit
<ali1234> i think there is one too many installs in that command line
<ali1234> mvo: http://paste.ubuntu.com/825195/
<ali1234> *only* update-manager wants to install the java packages
<mvo> ali1234: ohhh, hold on a sec, I have a idea
<mvo> ali1234: could you please run "bzr branch lp:update-manager; cd update-manager; ./update-manager" and let me know if it still wants to do that?
<barry> dpm: branch merged.  upg ready to go
<ali1234> mvo: bzr says "bzr: ERROR: Target directory "" already exists."
<mvo> ali1234: could you create a new empty place like /tmp/foo or something please? and cd into it, then hpefully bzr will not complain anymore :)
<ali1234> that's what i did
<mvo> ali1234: odd, I just tried it here and it worked ok, took a while though
<ali1234> here it bombs out instantly
<ali1234> does launchpad to tarballs?
<ali1234> mvo: btw did i ever tell you about my update-manager patch that integrates with affecting-bugs?
<ali1234> so it the change logs it says "this bug affects you"
<mvo> ali1234: oh? no you didn't :)
<ali1234> well, there's that...
<mvo> ali1234: you can try this patch here instead http://paste.ubuntu.com/825210/
<mvo> ali1234: if the bzr branch is not working
<ali1234> apply that directly to precise version?
<ali1234> mvo: that's fixed it yes
<mvo> ali1234: awsome thanks!
<mvo> ali1234: I will do a update with that
<ali1234> mvo: http://paste.ubuntu.com/825232/ is my patch. it's a nasty nasty hack and affecting bugs wasn't even available when i made it.
<ali1234> but if i ever get bzr working i might try to clean it up a bit
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<seb128> cjwatson, ev: can we get bug #892384 assigned to someone or milestone so it doesn't slip through this cycle?
<ubottu> Launchpad bug 892384 in Ubuntu Translations "The wireless and photo applications are not translated into Simplified Chinese in Ubuntu 11.10" [High,Triaged] https://launchpad.net/bugs/892384
<seb128> it's basically gtkwidgets.py in ubiquity having some
<seb128> "        # TODO i18n
<seb128>         l = Gtk.Label('Take a photo:')"
<seb128> i.e untranslatable strings
<cjwatson> seb128: ok, I'll take it
<seb128> cjwatson, thanks
<dpm> dholbach, barry, upg update pushed to the web. Does that look ok to you? http://developer.ubuntu.com/packaging/singlehtml/
<barry> dpm: not quite.  it still looks out of date
<dholbach> barry, did the package build already?
<barry> dholbach: oh!  i didn't realize an archive upload was necessary.  let me do that now
<dholbach> currently building https://code.launchpad.net/~ubuntu-packaging-guide-team/+recipe/ubuntu-packaging-guide-daily
<barry> dholbach: ah, it's running.  okay cool
<smoser> doko_, i removed the ppa because an upgrade left my system not starting lightdm (and i immediately suspected libc and removed it) but it turned out that an upgrade had left me without ubuntu-desktop.
<cjwatson> barry: I wouldn't mind looking at -o Debug::pkgProblemResolver=true output from your system where ia32-libs is held back
<cjwatson> (well, actually, I'd hate it, but I'm prepared to ;-) )
<barry> cjwatson: ;)  sure i can generate that
<doko_> smoser, was that at UDS? the lightdm issue is fixed
<smoser> this was this week.
<smoser> but i'm fairly sure it was a result of uninstalled packages that got removed somehow in an upgrade.
<barry> cjwatson: well, that doesn't actually output much of anything.  are you sure you don't want -o Debug::pkgPackageManager=true ?
<doko_> ok
<apw> cjwatson, what are the symptoms when one tries to update a 64bit ia32libs infected system O -> P
<cjwatson> barry: for good measure, let's have 'apt-get -o Debug::pkgProblemResolver=true -o Debug::pkgPackageManager=true -o Debug::pkgOrderList=true dist-upgrade'
<smoser> and then lightdm was failing. but i seem to have not even included the trace or the segfault.
<barry> cjwatson: cool.  should i attach it to that bug or open a new bug?
<cjwatson> apw: it calculates the upgrade successfully, then when you say yes go ahead, it says "Couldn't configure pre-depend libtinfo5 for libncurses5, probably a dependency cycle."
<cjwatson> barry: maybe just a pastebin for now?
<barry> cjwatson: k
<apw> cjwatson, ok so i can hit return and find out ...
<cjwatson> apw: I'm not ruling out the possibility that there are multiple bugs involved :-)
<slangasek> seb128: soft freeze for alpha2? :)
<cjwatson> and it's possible the exact symptoms even of this one vary
<seb128> slangasek, yes?
<apw> cjwatson, i suspect my main devel box here is about to hit the issue, so do you want to keep that machine as a tester for the fix, or should i go ahead and update it
<apw> (i literally have the 'go' button on my screen when i heard about this issue)
<slangasek> seb128: eog, gedit uploads hit the CDs, and don't seem to be milestone-critical?
<seb128> slangasek, I though bug fixes updates to component which were not creating installability issues were ok?
<cjwatson> apw: are you using update-manager / do-release-upgrade to do it?
<slangasek> seb128: ah, if that's the current agreement, I was unaware of it
<seb128> slangasek, no, that was my understanding of alpha soft freeze from years ago, I'm sorry if that's off or if that changed
<apw> cjwatson, yeah 'update-manager -d' and sitting with the dialog ready to go
<slangasek> seb128: heh, that's not what the standard was when I was RM :)
<cjwatson> apw: then just go ahead - it saves a state tarball in advance which gets attached to apport bugs and can be used to recreate a chroot with all the matching packages
<cjwatson> apw: I already have one of those from RAOF
<cjwatson> so working on upgrade bugs goes "grab apt-clone state from bug, restore into chroot, set that up as an schroot with overlayfs, then repeatedly upgrade / throw away overlayfs until you get it working"
<cjwatson> it's almost enjoyable
<apw> cjwatson, you have an interesting defination of enjoyable :)
<cjwatson> I did say almost
<dholbach> barry, dpm: the natty seems to be finished - not sure though if it was published yet though
<dholbach> err, natty build
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha 2 | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs kenvandine
 * kenvandine hugs dholbach
<dholbach> :)
<highvoltage> free hugs!
 * dholbach hugs highvoltage too
<highvoltage> :)
 * ogra_ hugs highvoltage, dholbach and kenvandine 
<dholbach> hey ogra_ :)
<ogra_> :)
<kenvandine> ;-D
 * dholbach hugs ogra_
<dholbach> alright - time to call it a day - see you tomorrow
<highvoltage> have a good evening dholbach
<apw> cjwatson, ok mine went ahead and did the update even though i had ia32libs installed, interesting
<cjwatson> apw: OK, maybe I'm overstating the scope of the problem then
<cjwatson> Better than understating it I guess
<apw> cjwatson, yep, much better indeed
<apw> and mine may crater sometime in the next 3 hours that it claims are needed fo rthe update
<cjwatson> oh, it hasn't downloaded the packages yet?
<apw> yep, past that and installing them now
<cjwatson> ok, I think the failure is immediately after download
<apw> cjwatson, ok so i got past it somehow ...
<apw> it is indeed removing and replaceing a bunch of :i386 packages as wel speak
<cjwatson> oh, you already had :i386 packages installed before the upgrade?
<apw> cjwatson, yeah, though i have no idea why, i have the ia32-lib and ia32-libs-multiarch:i386 installed
<cjwatson> then it doesn't affect you - this is only for systems that didn't previously have anything :i386 installed
<apw> ahh sorry :)  then i am a false false alarm
<cjwatson> the problem is in computing the unpack ordering for libc6:i386 / libgcc1:i386 when they weren't already installed
<apw> cjwatson, so can't we just install one at random in O before the update
<apw> to trigger those to install from O
<slangasek> cjwatson: ia32-libs couldn't be installed in oneiric without :i386
<apw> rather than fixing apt :)
<slangasek> it was just a less complete conversion
<cjwatson> could do I suppose, but the apt fix is known
<cjwatson> slangasek: huh, then I've misdiagnosed something
<cjwatson> slangasek: are you *sure*?  It only Recommends: ia32-libs-multiarch
<cjwatson> slangasek: and RAOF's apt-clone file has ia32-libs installed without AFAICS any :i386 packages
<slangasek> cjwatson: oh, really?  hrm, wonder why it was only a recommends
<micahg> I would think it's only a recommends so people can selectively install the multiarch libs
<cjwatson> that does change the tone of the release note, though, so I'll amend it
<slangasek> micahg: there's nothing selective about ia32-libs
<micahg> slangasek: right, but with multiarch there could be
<slangasek> nor about ia32-libs-multiarch
<slangasek> no, because with multiarch ia32-libs is there solely for compatibility
<micahg> i.e. just install the libs you need from i386
<cjwatson> but the point of ia32-libs is to supply everything it used to supply
<cjwatson> because there are packages that depend on it and expect that
 * slangasek nods
<slangasek> so I think that was simply a bug in the oneiric package
<cjwatson> I've toned down the release note to say that this only happens sometimes and to give an example of the error message you get if you encounter this
<cjwatson> I'm not sure there's much value in explaining the exact circumstances since it's already pretty wordy
<cjwatson> apw: so yes, it's true that that's a viable fallback for *this* apt bug - but I wonder about the next one
<cjwatson> apw: this is already the third apt bug that I've considered SRUing into oneiric
<cjwatson> well, bug fix :)
<apw> :)
<cjwatson> and that's just in a week of looking at upgrade bugs on and off
<bdmurray> stgraber: I've updated bug 924836 and can get the upstart log if you like
<ubottu> Launchpad bug 924836 in ifupdown (Ubuntu Precise) "network-manager does not tell plymouth it has started" [High,Incomplete] https://launchpad.net/bugs/924836
<stgraber> bdmurray: yeah, I see nothing wrong in what you posted so upstart logging would probably help find the cause of the failure
<bdmurray> stgraber: hmm, I think I only saw the message on first boot
<stgraber> bdmurray: did you briefly see it or did you see the whole sequence of "waiting for network", "waiting up to 60 more seconds", "booting system without full network"?
<bdmurray> stgraber: the whole sequence
<stgraber> bdmurray: Riddell also said first boot in the bug report, so might be something that fixes itself ...
<stgraber> bdmurray: now that I'm waiting for some rebuilds, I'll try a clean Ubuntu desktop install in a VM
<stgraber> (and boot directly with --log on the first boot)
<stgraber> bdmurray: reproduced (with --log). Will look into what's wrong once it times out
<jdstrand> mdeslaur: do you happen to know off hand why lightdm would not be displaying 'Other user' on 12.04, or if there is a way to login as someone under uid 1000?
<jdstrand> mdeslaur: I found user.conf for lightdm, but it said that accountsservice would override anything in that file
<jdstrand> mdeslaur: if not, I'll keep poking
<mdeslaur> jdstrand: accountsservice has a minimum UID, and won't make lightdm aware of any user under that
<mdeslaur> jdstrand: what are you trying to do?
<jdstrand> mdeslaur: for quite some time on machines that I administer I create my user as 999 so that it doesn't show up in the list. I can't seem to be able to login via lightdm as that user in 12.04
<mdeslaur> jdstrand: nope, that won't work
<jdstrand> mdeslaur: do happen to know why there was this change? why won't lightdm allow me to login as someone not in the list like it used to?
<jdstrand> mdeslaur: well, that is enough for me to file a bug I guess. thanks
<mdeslaur> jdstrand: you _could_ change login.defs to lower it to 999
<jdstrand> sure, but then I show up in the list
<jdstrand> people complain to me that it is their computer, why should I be in the list at all let alone before them (since I am alphabetically before most of them)
<jdstrand> anyhoo, I know it isn't your problem, so I'll move along
<mdeslaur> jdstrand: oh, I see :)
<mdeslaur> jdstrand: you could try "hide-users=true" in lightdm.conf
<mdeslaur> jdstrand: http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/revision/236
<seb128> what do you try to do?
<jdstrand> hmm
<jdstrand> seb128: removing the 'Other' option in lightdm is causing me mild grief now, and a lot down the line
<jdstrand> seb128: I administer a not small number of machines for various people
<jdstrand> seb128: I don't own the machines
<seb128> how did you solve that issue before?
<jdstrand> seb128: so when we started displaying usernames rather than having people type them in the greeter, my name showed up
<seb128> oh, what mdeslaur said? use hide-users=true to go back to an entry rather than a list
<jdstrand> seb128: and they are like "Why are you in the list when you login?" or "Why are you before me in the list-- this is *my* computer"
<jdstrand> seb128: so I created a user with uid 999
<jdstrand> this allowed me to use 'Other' for me
<seb128> well it seems you use those machines little enough to just log on a vt when you need to log in?
<jdstrand> seb128: I wonder why this can't be configuration in the greeter. I guess I can go back to the old way, but it seems a weird change imho
<jdstrand> seb128: I can, but I do like to go into X if needed
<jdstrand> I have a feeling I am not the only one who will find this inconvenient
<seb128> jdstrand, startx? ;-)
<jdstrand> seb128: will that still setup everything correctly?
<seb128> it should be mostly working
<jdstrand> heh
<jdstrand> well, it was working perfectly in 11.10 ;)
<seb128> jdstrand, but yeah, you should open a bug on unity-greeter, not sure why robert_ancell linked the "other" option to the hide-users
<seb128> that seems like it could be its own option
 * jdstrand files
<jdstrand> seb128: thanks
<seb128> jdstrand, user testing showed that the "others" entry was confusing quite some users who wonder why there is an "other" entry on their box
<seb128> that's why they hide it by default
<seb128> but I'm sure it could be a standalone option rather than linked to the user list
<jdstrand> that's cool-- I don't care about the default, I just think it should be configurable
<seb128> yeah, I'm a bit surprised robert_ancell did it this way
<seb128> he probably did whatever was easiest, and nobody made a case for having the option before you
<jdstrand> :)
<mdeslaur> jdstrand: maybe put a little secret pi symbol on the bottom of the screen that can be clicked  :P
<jdstrand> hehe
<jdstrand> seb128: fyi, 925125
<seb128> jdstrand, thanks
<emgent> salut
<YokoZar> slangasek: ia32-libs-multiarch is only a recommends of ia32-libs in oneiric because there were amd64 packages in oneiric that needed to be built with ia32-libs and ia32-libs-multiarch is unavailable on a 64-bit build daemon
<slangasek> ah
<slangasek> so not a bug we can really fix, then
<YokoZar> slangasek: Yeah.  We could make it a depends in precise I suppose but I don't know if that would help anything
<slangasek> it's already a depends in precise
<YokoZar> Ahh, good
#ubuntu-devel 2012-02-02
<pitti> Good morning
<dholbach> good morning
<didrocks> dholbach: good morning!
<dholbach> salut didrocks
<didrocks> how are you?
<dholbach> good good - how about you?
<didrocks> dholbach: I'm fine, thanks!
<didrocks> dholbach: FYI, I just opened https://wiki.ubuntu.com/MeetingLogs/devweek1201/AutomatedUXTestingWithQt and I'm seeing that the css quote rectangle is cutting the speech :)
<dholbach> I know
<dholbach> it's a but
<dholbach> bug
<dholbach> https://bugs.launchpad.net/ubuntu-website/+bug/812337
<ubottu> Ubuntu bug 812337 in Ubuntu Website "Ubuntu Wiki: IRC style formatting needs a "word-wrap: break-word"" [Undecided,New]
<dholbach> afaik sladen is on it
<dholbach> maybe it needs newz2000 to deploy it?
<dholbach> I just pinged both of them
<didrocks> dholbach: thanks! :)
 * apw notes he has _10_ updates which considering we are in freeze ... is unexpected
<MacSlow> pitti, can you resubmit your wnck_shutdown-branch for notify-osd to be merged-proposed for lp:notify-osd/precise?!
<MacSlow> pitti, that would make more sense because of the libwnck3-requirement, which is only met by precise
<MacSlow> thanks in advance
<pitti> MacSlow: why wouldn't it also go to trunk?
<pitti> MacSlow: it's not a requirement, it's a conditional feature
<pitti> MacSlow: it shoudl certainly also go to precise, but usually via trunk and a new release?
<pitti> MacSlow: also, the precise package already has that patch
<seb128> pitti, not sure but notify-osd has a weird series handling, tarballs have been rolled from ubuntu series and not trunk for quite some time
<seb128> like it was the same in oneiric
<seb128> seems trunk is not used
<pitti> ok, re-doing the branch and MP
<pitti> MacSlow: ok, done: https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91255
<pitti> MacSlow: NB that nobody is not subscribed to that project; DX was subscribed to lp:notify-osd
<pitti> argh, ignore this, it's broken
<pitti> bzr lp-propose picked the wrong target
<pitti> MacSlow: https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91257 it is
<pitti> hmm
<pitti> I did specify lp:notify-osd/precise, but now the MP is again against lp:notify-osd
<pitti> WTH?
<seb128> pitti, just edit the target on lp
<pitti> https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91258
<pitti> third time
<pitti> it keeps setting it to lp:notify-osd
<pitti> I suppose the two are aliases
<pitti> and lp:notify-osd/precise _is_ the new trunk
 * MacSlow scratches head
<pitti> MacSlow: so, it should be good
<pitti> MacSlow: my original MP merges just fine, too
<MacSlow> sure... locally it works fine with both
<pitti> MacSlow: oh, I understand
<pitti> MacSlow: the old MP shows /oneiric now
<pitti> it seems you switched trunk from /oneiric to /precise since I created the original MP
<MacSlow> pitti, all good nos
<MacSlow> now
<MacSlow> pitti, yeah
<pitti> please don't do that
<pitti> MacSlow: anyway, https://code.launchpad.net/~pitti/notify-osd/wnck_shutdown-precise/+merge/91258 is good
<pitti> jdstrand: hm, I just saw you earned bug 673925 from kees/
<pitti> ?
<ubottu> Launchpad bug 673925 in freerdp (Ubuntu Precise) "[MIR] freerdp" [Medium,Confirmed] https://launchpad.net/bugs/673925
<pitti> jdstrand: it had already been MIR reviewed in the past, but 0.8 didn't validate SSL; 1.0 is supposed to
<seb128> micahg, jdstrand: hey, just being curious but is there any bug or similar tracking the firefox 10 update for oneiric, eta, what is blocking it etc? some users seem eager to get it and keep asking I'm not sure where to point them ;-)
<roaksoax> clear
<jdstrand> pitti: yes. it is actually on my list of things to look at today
<pitti> jdstrand: nice, thanks
<KaM^PreT> ad orng ngga?
<pitti> nuQneH?
<jdstrand> seb128: looks like bug #
<jdstrand> bug #923319
<ubottu> Launchpad bug 923319 in mozvoikko (Ubuntu Oneiric) "Firefox 10 update" [Undecided,New] https://launchpad.net/bugs/923319
<jdstrand> seb128: this is in the ubuntu-mozilla-security ppa
<seb128> jdstrand, not a lot of content there ;-) seems the update are technically ready I was wondering if somebody blocks updates
<seb128> uploads
<jdstrand> seb128: I don't know the timeframe other than I know micahg is testing them and istr him saying something about next week
<jdstrand> seb128: actually, he might have said this week. micahg, what is your time frame for ff 10? :)
<seb128> jdstrand, ok, some users are making us some bad press because we are slow to update, over a week in a 6 weeks cycle seems a lot ;-)
<seb128> jdstrand, I was trying to figure what to response
<jdstrand> seb128: we block on them to test each release on i386 and amd64
<seb128> jdstrand, thanks
<seb128> jdstrand, well 10 is frozen and in the ppa for weeks, we should have got testing by now? official version is there since sunday it seems ... do we need extra testers? i.e should we do a call for help somewhere?
<jdstrand> I know he has been actively working on that this week. I don't know when he will pull the trigger. if not today, then early next week (we avoid friday releases except in emergencies)
<seb128> jdstrand, ok thanks
<jdstrand> seb128: I doubt the older releases have gotten a lot of testing outside of chrisccoulson and micahg
<seb128> jdstrand, it's maybe something we should look at fixing ;-)
<seb128> getting testing earlier
<jdstrand> seb128: the call for help was for 9. 9 to 10 shouldn't be a big deal
<seb128> ok
<jdstrand> seb128: yes. the lonstanding goal is for micahg to have these tested and ready by release day. then we wait 24 hours for upstream to find things, then we release if no show stoppers
<seb128> jdstrand, sound great, I'm looking forward getting there ;-)
<jdstrand> seb128: that got pushed back a bit with all the firefox 9 transition in lucid and maverick. now that everything is on one release, it should be easier for micahg to achieve that
<seb128> jdstrand, excellent, thanks a lot of the details!
<jdstrand> you're welcome :)
<cyphermox> cking: I'm curious about your blog post about the 3G dongle
<cyphermox> cking: 12d1:1446 already has a definition in usb-modeswitch-data at least in precise, so that definition would be wrong if your device didn't switch on connect?
<cking> cyphermox, well, I bodged it because it wasn't working - I need to figure out why it wasn't working by default, it may be an upgrade issue
<cyphermox> cking: sounds to me like maybe the definition file isn't right for some devices despite having the same usb ID
<cyphermox> (e.g. there are some firmware impacts on how they respond to the switch message)
<cking> cyphermox, I did see the following:
<cking> usb_modeswitch_[326]: segfault at 8 ip 00007f7ca17f0541 sp 00007fffce9ff578 error 4 in libc-2.13.so[7f7ca176a000+197000]
<cyphermox> ok
<cyphermox> then that is probably entirely my fault, and I'll need to fix this
<cking> hence I forced it with my own config file. do you need any more info to help resolve this bug?
<cyphermox> I don't think so
<cking> cyphermox, i was just pleased to get some form of connectivity via 3G yesterday - if you want me to test any fixes I'm happy to try them out
<cyphermox> cking: sure
<nigelb> seb128: Hey! Can you join the classroom channels? The bot's complaining you aren't in there yet :)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 (last day) starting in 8 minutes in #ubuntu-classroom
<seb128> nigelb, done
<nigelb> seb128: Thanks! :)
<dholbach> seb128, mhall119, tumbleweed, jbicha, kirkland, warp10, ready? :)
<seb128> dholbach, no :p
<pitti> cjwatson: hm, the new sru-release method doesn't seem to auto-close the referenced bugs any more
<jbicha> dholbach: good morning
<pitti> cjwatson: ah nevermind, it just takes a minute or two
<cjwatson> yep, see "asynchronous" :)
<mhall119> dholbach: /me is always ready
<dholbach> :)
<kirkland> dholbach: more or less :-)
<kirkland> sladen: https://answers.launchpad.net/byobu/+question/185066
<kirkland> sladen: I'm getting that question fairly frequently now
<sforshee> bryce, RAOF: is precise to power off the unused gpu in hybrid graphics systems by default?
<dendrobates> mvo: hey I'm having a precise upgrade issue:  The package 'unity-scope-calculator' is marked for removal but it is in the removal blacklist
<dendrobates> mvo: can you offer any pointers?
<stgraber> hmm, it should indeed be removed (doesn't work with new Unity API and as it's a post-release extra app, it doesn't exist in Precise), these shouldn't get removal blacklisted
<cjwatson> it's because unity is there and the regex search isn't anchored
<cjwatson> or rather is only anchored at the start
<DoctorPepper>  is anyone  of  the ubuntu kde team in here ?
<cjwatson> dendrobates: fixed for next update-manager upload, thanks
<dendrobates> cjwatson: np, thanks
<mvo> dendrobates: woah, cjwatson was quicker
<mvo> thanks cjwatson - I guess the regexp was too broad
<cjwatson> -unity
<cjwatson> +unity$
<Riddell> DoctorPepper: yes
<cjwatson> considered doing the same for unity-2d but it doesn't seem to have a similar breadth of addons
<cjwatson> I mean not in that namespace
<soren> cjwatson: So this change was in update-manager?
<cjwatson> soren: yes
<soren> cjwatson: And now you've uploaded the change?
<cjwatson> soren: no
<soren> How does it land in the upgrade tool?
<soren> Oh, ok.
<cjwatson> it'll be there from the next upload
<soren> Is the generation of the upgrade tool part of the update-manager build process?
<cjwatson> yes
<cjwatson> it gets stuffed into LP as a custom upload
<soren> Ah :)
<cjwatson> basically a tarball of the DistUpgrade/ directory
<DoctorPepper> ridell: i need some help i am running kde  4.8 on 10.10  from ppa  and  i am having some wierd  issue with  python based  plasmoid not working
<soren> Ok. Is there a temporary workaround we can do locally?
<cjwatson> not sure
<soren> Yeah, it seems we'd have to be really quick.
<Riddell> DoctorPepper: this is not a support channel I'm afraid
<soren> Perhaps ctrl-z the update-manager process right after it downloads and unpacks it.
<DoctorPepper> it  seens  that nobody is able to help me on the kubuntu
<soren> ..fix the regex, and start it again.
 * soren tries that
<cjwatson> I was going to upload update-manager after the freeze ends today if mvo doesn't mind
<cjwatson> having to work around the main.log thing I fixed is annoying :)
<DoctorPepper> Riddell: it seems to me  that i am hitting a bug
<Riddell> DoctorPepper: your options are the kde and plasma developer channel and the kubuntu channels.  but python on plasma is not a much used solution so you can't expect a quick answer on irc
<mvo> soren: you could simply run "bzr branch lp:update-manager; cd update-manager/DistUpgrade; sudo ./dist-upgrade.py"
<mvo> cjwatson: I don't mind at all, but I'm happy to do it too, there is one branch from jibel waiting for review that I would like to get done at some point, but its not urgent, both is fine
<cjwatson> oh that's a handy trick
<cjwatson> mvo: ok, cool, if you're going to anyway that's obviously fine by me ;-)
<soren> mvo: Ah, yes.Neat. Thanks.
<barry> jodh: your done symbol for our next meeting: http://www.fileformat.info/info/unicode/char/1f4a9/index.htm
<jodh> barry: watcha tryin to say? ;)
<barry> no commentary implied :)
<barry> cjwatson: is this an up-to-date sync blacklist?  http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<cjwatson> barry: yes
<barry> thx
<jodh> barry: seems somewhat discriminatory - its comment is "dog dirt".
<barry> i've seen that term used on my neighborhood listserv.  as in: "hey you freakin' neighbors, clean up your dog dirt!
<ion> As opposed to dog poop?
<barry> yeah, which is funny because of the things they *do* say when the flamewars erupt over indoor or outdoor cats
<slangasek> Barzogh: pretty sure the bug is still open asking for that character to be supported in the fonts ;)
<slangasek> hmm
<slangasek> Barzogh: sorry, mistab :)
<bryce> sforshee, theoretically yes
<sforshee> bryce, what does that mean exactly? Should that support already be in place? Because I have a system with hybrid graphics, and the discrete card is not being powered off
<barry> james_w: think we should get pkgme into precise?
<JanC> for those of you who come to FOSDEM: https://wiki.ubuntu.com/Fosdem/2012 (I will further update the wiki later today & tomorrow, but feel free to add yourself, your talks and/or your ideas!)
<smoser> slangasek, ping.
<smoser> maybe you have some thoughts on this log https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-ec2/ARCH=i386,REGION=us-west-2,STORAGE=instance-store,TEST=cloud-config,label=ubuntu-server-ec2-testing/lastBuild/artifact/None/i386/m1.small/instance-store/i-e688ccd6/uec2-20120202-1453-d28473559d2145-terminated.console.txt
<smoser>  Serious errors were found while checking the disk drive for /opt.
<smoser>  Press I to ignore, S to skip mounting, or M for manual recovery
<slangasek> smoser: what's the fstab look like?
<smoser> slangasek, hold on.
<micahg> seb128: jdstrand: the goal is to release Firefox 10 today, we decided to wait ~48 hours since there have been numerous chemspills lately, this time, it doesn't look as likely
<smoser> slangasek, http://paste.ubuntu.com/826611/
<jdstrand> micahg: ah, great! :)
<smoser> slangasek, this is https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/898373
<ubottu> Ubuntu bug 898373 in cloud-init (Ubuntu) "fsck.ext3: Device or resource busy while trying to open /dev/xvda2" [High,Confirmed]
<seb128> micahg, hey, great, thanks
<slangasek> smoser: oh; well, that bug needs to be fixed then surely?
<smoser> slangasek, :) surely it does
<smoser> its rare
<smoser> but...
<smoser> so there is definitely a bug there (the 'busy')
<slangasek> well, there are no shortcuts, if that's what you're asking. :)  We're not going to change mountall to stop doing what it's doing
<smoser> but in EC2, there is no local console.
<smoser> so prompting the user for fsck (and haning the system indefinitely?) is just pointless.
<smoser> is there a way that i can configure it to say "if osmething other than / needs fsck, come up anyway"
<slangasek> no
<slangasek> you can mark the disk "noauto" or "nobootwait" in /etc/fstab, that's it
<slangasek> otherwise, the filesystem is marked as a required part of the boot, and if the fsck fails it's not ready to be mounted
<smoser> hm..
<slangasek> I don't have a good way to deal with the prompt itself, since we need plymouth to capture boot-time output and if plymouth is present mountall thinks it's ok to prompt
<smoser> well i dont like the nobootwait solution, as unless its dirty, i do want to wait.
<slangasek> but even if we solved the prompt, mountall's fallback policy is to launch a root shell and let you fix it, which is also the correct policy but doesn't help you either
<smoser> how hard, i wonder, would it be for it to launch ssh daemon ?
<smoser> what would be nice is:
<smoser>  "Uhoh, you're hosed. I've started an ssh daemon at IP:22. ssh here as root and you'll be dumped into a screen session where you can handle it"
<slangasek> smoser: sure, either fixing /etc/init/mountall-shell.conf to support this, or diverting it in a cloud-specific job, seems reasonable there
<smoser> slangasek, ok.
<smoser> so the bug there still remains thoguh.
<smoser> the device busy
<smoser> i'll leave that bug open, and would greatly appreciate foundations help on it (and i can facilitate)
<smoser> and i'll open up another bug specifically saying dirty filesystems make cloud-instances cry
<tomreyn> hi, i'm on ubuntu 11.10 (oneiric), with oneiric-proposed and xorg-edgers repositories activated, and having trouble running any virtual machines since the driver modules are not loaded, and may not have been built by dkms automatically. i'm trying to find out why this is so I can make a proper bug report against ubuntu, but am having trouble finding the root cause, can someone guide me through?
<SpamapS> smoser: hey, when is the last time you tried uncloud-init with the cloud images?
<SpamapS> smoser: I tried it last night and things did not go well. :-/
<smoser> not supported.
<SpamapS> It was a cool idea. :)
<smoser> what were you wanting to do ?
<smoser> its better done now.
<SpamapS> smoser: I ended up just converting the cloud image to raw, mounting it, and chrooting in to change the password and purge cloud-init
<smoser> but you have to use a cdrom
<smoser> but you can essentially boot the image in kvm with whatever user-data you'd like. (and your data would just do that)
<smoser> you dont have to purge cloud-init (although you can)
<SpamapS> smoser: perhaps we should update this https://help.ubuntu.com/community/UEC/Images
<smoser> SpamapS, or maybe you could just read it ;)
<smoser> https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_Local_Hypervisor_Natty_onward
<SpamapS> smoser: I did read it... but I didn't feel like figuring out how to generate the appropriate user-data..  :-P
<SpamapS> smoser: I just wanted to use it to get a quick KVM vm up
<smoser> if you copied and pasted those lines it would have worked.
<SpamapS> what would have worked? It would have somehow grabbed my ssh key and put it in the user-data ?
<smoser> but feel free to update however you'd like to make it more clear.
<SpamapS> Oh you're saying the passw0rd is embedded?
<smoser> Then, log in with 'ubuntu' and password 'passw0rd'.
<SpamapS> my laziness won the day then.. ;)
<smoser> the file 'user-data' that is referred to by 'make-iso' changes the password
<smoser> fwiw, in doing some other work, i was wanitng ot have a script that does all this for you
<smoser> that can take an image as input and basically run it in the image for you via chroot or kvm boot.
<smoser> and would use the ovf stuff behind the sceneds
<SpamapS> smoser: yeah that would be cool
<smoser> SpamapS, but seriously, feel free to make that page more readable.
<smoser> or even just write "DO NOT USE UNCLOUD-INIT"
<SpamapS> smoser: it sounded like such a simpler option ;)
<smoser> i agree.
<smoser> except for it can't be automated.
<smoser> so i dont see a lot of value in maintaining it.
<cnd> what's the real benefit of using bzr merge-update with a packaging branch that includes the upstream sources?
<cnd> vs just having a packaging branch with the debian directory?
<jtaylor> its much easier to mess with the orig source
<cnd> jtaylor, what do you mean by that?
<slangasek> cnd: using it as a real DVCS, where you have access to the full upstream source directly and can diff directly against the upstream?
<cnd> slangasek, yes, in theory that sounds nice
<cnd> but it makes bootstrapping the packaging branch more difficult
<slangasek> does it?
<cnd> it makes updating cumbersome (bzr mu with 8 options)
<cnd> and I have yet to feel like it has helped in reality
<cnd> the packaging branch bootstrapping involves tagging it in special ways, IIRC
<cnd> it's been a while since I've done it, but we are making a new package right now
<slangasek> cnd: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study/
<slangasek> cnd: for me, one of the benefits is never having to root around looking for the right upstream tarball on the mirror
<cnd> slangasek, isn't that what uscan is for?
<slangasek> no
 * cnd is confused...
<slangasek> I'm talking about the orig.tar.gz for a version that's already in the archive
<cnd> oh
<cnd> uscan --download-current-version?
<slangasek> which isn't always a bit-for-bit match for what upstream distributes
<slangasek> again, no :)
<cnd> well yeah, hopefully they're the same
<slangasek> and sometimes it isn't, and it's good to have a workflow that's built on something more tangible than hope :)
<cnd> heh
<cnd> slangasek, is that the only place where it helps though?
<cnd> if you need to add a patch to the sources
<slangasek> I am astonished that you think this is a negligible case :)
<cnd> I probably don't have as much experience in this area since I mostly package our own development work
<cnd> we make new releases if there are bugs
<cjwatson> I find it extremely beneficial to be able to bzr log/blame/etc. all in a single tree
<cnd> so there usually isn't patches
<cnd> ok
<cnd> mostly I wanted to double check that it was important for some people to have a packaging branch maintained this way
<cnd> since it is a bit harder for us to get started with
<cnd> but if it helps, then we'll continue to do it that way
 * cjwatson bangs head against lucid->precise dpkg/lzma upgrade tangles, and considers the pub instead
<slangasek> cnd: well, the only time I think it's worth the effort of doing by hand is if you're branching from an upstream VCS as described at the link I pasted
<slangasek> otherwise, you might as well just use the UDD branches, and let the importer do it for you
<cnd> ok
<cjwatson> slangasek: there you go
* slangasek changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> cjwatson: thanks
<BenC> Am I correct that powerpc and arm buildd's run the builds as root?
<BenC> Actually, I'm guessing just the powerpc buildd is that way
<micahg> infinity or lamont ^^
<infinity> BenC: No.
<infinity> BenC: dpkg-buildpackage -rfakeroot as an unprivileged user.
<kirkland> jcastro: hey, they're having trouble over in ubuntu-classroom, getting voice
<jcastro> k
<micahg> lool: do you mind if I merge ca-certificates?
<36DAARLF3> does anyone encounter this bug with google-chrome?: http://imgur.com/vu5am
<coalwater> 36DAARLF3: is it with chrome only ?
* ChanServ changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* ChanServ changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate covered ants | melior malum quod cognoscis
<jsmith-argotec> I am looking to make/submit a patch for a bug in bind9 - but that's about where my knowledge ends... anyone that might lend me some assistance?
<coalwater> jsmith-argotec: u mean in launchpad?
<jsmith-argotec> coalwater: umm idk, not sure exactly how to create a patch properly - tried once before but it was ugly...
<jsmith-argotec> coalwater: and someone I spoke to about it recommended coming here or motu and getting help/sponsor
* micahg changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jsmith-argotec> coalwater: that package was part of universe therefore motu (haven't gotten to that yet)
<micahg> jsmith-argotec: do you like bzr?
<jsmith-argotec> micahg: not real familiar with it yet, seems ok
<micahg> jsmith-argotec: well, I can point you to documentation on how to make a patch with bzr or without
<jsmith-argotec> micahg: ahh well I am not partial to either way since it's fairly new territory for me so point to the better option
<jsmith-argotec> micahg: I'm not sure if it should be submitted upstream too or if that makes a difference in which way it's made
<micahg> jsmith-argotec: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<micahg> nah, both ways you should end with with a patch against the upstream code
<jsmith-argotec> micahg: that looks easy enough. One more question - is it poor etiquette to submit a pactch that is just applying a fix someone posted in the bug report?
<jsmith-argotec> micahg: from what I've read around it sounded like submitting a patch would help get it merged at all/quicker
<micahg> jsmith-argotec: a debdiff, not at all, just give attribution where appropriate
<jsmith-argotec> micahg: perfect!
<jsmith-argotec> micahg: a couple more questions... is it only usefull if submitted against the latest distribution or ok if it's still a bug in the latest
<jsmith-argotec> micahg: I'm only running Lucid not latest...
<micahg> jsmith-argotec: umm, well, bugs need to be fixed in the dev release before they can be SRUd (https://wiki.ubuntu.com/StableReleaseUpdates)
<jsmith-argotec> micahg: I'm not as concerned (though nice) if it's SRUd more so that it is fixed for the next LTS
<micahg> jsmith-argotec: ah, ok, then just for precise is fine
<jsmith-argotec> micahg: lastly - I've verified the bug exists in squeeze also. Should I submit a patch there too/instead?
<micahg> jsmith-argotec: well, squeeze is the stable release, it would probably have to go through unstable, you can use the submittodebian tool from ubuntu-dev-tools to send the bug to Debian once you have the Ubuntu package
<micahg> you can mention there if you're willing to make a patch for squeeze if it'll be accepted
<jsmith-argotec> micahg: ok once I get through the Ubuntu process I'll look into that. Thanks for the help!
<micahg> thank you for contributing to Ubuntu
<slangasek> smoser: so what else is in the image that could account for /dev/xvda2 being busy?  Could you grab dmesg output from such a failed boot?
<smoser> slangasek, i could, yeeah, but you think there would be something there that is not on that console ?
<smoser> thats all the kernel messages.
<slangasek> well, there could be
<smoser> i can have somethign that runs dmesg on boot to a file, and then start a reboot loop later.
<slangasek> I really have no idea what else might be holding that device open
<slangasek> besides a kernel issue
<36DAARLF3> coalwater, yes chrome only
<coalwater> well i asked because it seemed similar to a bug about nvidia video driver thing, but it does that with all windows, and it sometimes gets fixed after resizing the window
<coalwater> 36DAARLF3: ^
<36DAARLF3> coalwater, any more info on that bug?
<coalwater> i dont know, i could search for it, but it wasn't on my computer so i didn't look into it that much, let me check
<36DAARLF3> thx
<coalwater> 36DAARLF3: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/752445 i think this is it
<ubottu> Ubuntu bug 752445 in nvidia-graphics-drivers (Ubuntu) "Intermittent white window contents when maximizing/switching windows" [Undecided,Confirmed]
<36DAARLF3> thx
<YokoZar> I'm guessing the archive admins were busy with alpha 2 and didn't have time for packages in New queue for the past few days yes?
<SpamapS> YokoZar: they're not allowed to approve NEW stuff during the freeze
<YokoZar> SpamapS: Even universe stuff?
<SpamapS> YokoZar: I believe universe gets a freeze as well, as there are things in universe that end up on some CDs (just not the main Ubuntu cds)
<SpamapS> but that sounds crazy when I read it back to myself
<SpamapS> so disregard
 * SpamapS goes back to trying to get a kvm vm to pxe boot
<Laney> it is probably just for time reasons
<slangasek> actually, it's generally fine to do new processing during a freeze
<slangasek> because milestones are *also* supposed to have a consistent archive :)
<RAOF> You need a MIR to promote a new binary package from a source package in main, right?
<slangasek> RAOF: nope
<RAOF> Excellent.
<slangasek> hallyn: qemu-linaro 2012.01 ftbfs on 32-bit archs due to a problem in hw/qxl.c, which seems to be spice-specific... but neither the failing code nor the spice package has changed since the last upload.  Any ideas?
<soren> slangasek: toolchain changes?
<hallyn> slangasek: no idea...  if it also fails in a sbuild i'll try to reproduce tonight/tomorrow
<soren> hallyn, slangasek: the spice package has been updated in the mean time, too. (On 2011-12-19, while the old qemu-linaro was bulit on 2011-12-15)
<soren> Oh.
<soren> Just found this:
<soren> /Â«PKGBUILDDIRÂ»/hw/qxl.c:1021:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
<soren> I get that if I build the older qemu with a fresh tool chain.
<soren> ...that's an error in the newer qemu.
#ubuntu-devel 2012-02-03
<soren> hallyn, slangasek: Found it.
<soren> # Consult white-list to determine whether to enable werror
<soren> # by default.  Only enable by default for git builds
<soren> z_version=`cut -f3 -d. $source_path/VERSION`
<soren> qemu-linaro-1.0-2011.12/VERSION:1.0
<soren> qemu-linaro-1.0.50-2012.01/VERSION:1.0.50
<soren> slangasek: So -Werror gets enabled becuase there's a microversion.
<slangasek> aha! :)
<soren> Sorry, poor cut/paste job. The first three lines there are from configure. the last to are the VERSION files from the older and the newer qemu, respectively.,
<soren> *last two
<slangasek> right, so maybe we should disable that again in the package for now
<soren> Bit of a brain bender there :)
<RAOF> soren: That error message suggests that you'll be trading a build failure for a run-time crash, though?
<lifeless> RAOF: clearly preferrable :P
<slangasek> RAOF: pretty unlikely, really
<slangasek> I suspect spice-protocol is using a wrong integer type for "int that can store a pointer"
<RAOF> slangasek: Maybe my experience is atypical, but for me that error generally indicates someone's going to try to jump through the low 32 bits of a 64bit pointer :)
<slangasek> RAOF: yes, but this error *only* occurs on *32* bit systems :)
<RAOF> Ah.  Context!
<lool> micahg: Absolutely not, it's yours
<lool> micahg: thanks for checking
<Sarvatt> SpamapS: were you specifying mtrack in your xorg.conf or something? You have a macbook air if I'm not mistaken right? synaptics works absolutely fine on these
<bryceh> SpamapS, I closed out the bug with an explanation of what's going on
<bryceh> SpamapS, thanks for filing it, I hadn't really looked at mtrack until this.
<pitti> Good morning
<tjaalton> I've uploaded mesa 8.0~rc2 which needs some help from an archive admin to push it through NEW, it adds libxatracker which is needed by xserver-xorg-video-vmware (and demoed at FOSDEM tomorrow I'm told..)
<tjaalton> so if someone could give it a push once it's uploaded, that'd be great
<pitti> ah, it's not yet in the queue
<tjaalton> yeah it'll take some time to build too
<wgrant> pitti: Bug #924181 looks like apport is trying to set a tag with capital letters in it, which is forbidden.
<ubottu> Launchpad bug 924181 in launchpadlib "unable to log bugs with ubuntu-bug for unity or unity-2d" [Undecided,New] https://launchpad.net/bugs/924181
<pitti> wgrant: ah, thanks! will adjust accordingly
<wgrant> pitti: Thanks.
<tjaalton> pitti: x86 mesa built. can you accept the new binaries now, or should the other archs be finished building before accepting?
<pitti> tjaalton: we usually wait for most arches; if it's very urgent, I can accept them now
<tjaalton> well I don't know how long the arm* and powerpc builds take
<tjaalton> I can check and get back to you
<pitti> tjaalton: I'm not that concerned about ppc -- it's notoriously behind anyway
<tjaalton> well armel will take around 11h :)
<tjaalton> but maybe armhf is faster?
<pitti> ok, looking
<tjaalton> thanks
<dholbach> good morning
<pitti> tjaalton: accepted
<pitti> hey dholbach, guten Morgen
<dholbach> hey pitti
<tjaalton> pitti: ty
<pitti> micahg: lucid-proposed has gecko-mediaplayer and moon, but the two tasks on the tracking bug are all "New"; what should happen with these?
<pitti> zul: what's with all the new package uploads to oneiric-proposed? https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0
<pitti> zul: were they meant for -backports, or something else?
<pitti> jtaylor: rejecting python-networkx oneiric-proposed, as it does not have a bug link; can you please reupload?
<FourDollars> dholbach: About https://bugs.launchpad.net/ubuntu/+bug/923637/comments/4 "ACKed, sync performed, sitting in the NEW queue, to be reviewed by our archive admins", where can I see the status?
<ubottu> Ubuntu bug 923637 in Ubuntu "Sync hime 0.9.9-1 (universe) from Debian unstable (main)" [Undecided,Fix released]
 * apw is attempting an update today and every :i386 package i have appears to be being 'REMOVED' is that to be expected in precise?
<pitti> apw: the buildds are clogged due to the rebuild test, and thus we have a lot of i386 vs. amd64 build desync
<pitti> apw: so it's not unlikely that you hit a library which already has built on i386 but not yet on amd64
<pitti> multiarch requires them to be in sync
<pitti> so perhaps only apt-get upgrade today
<apw> pitti, ok thans
<diwic> if multiarch requires i386 and amd64 to be in sync, maybe launchpad must be modified not to publish one of them but not the other?
<apw> or apt modified to not think removing my packages is the solution
<wgrant> diwic: That gets extraordinarily awkward when you have powerpc lagging, and build failures.
<apw> but to hold them back instead
<diwic> wouldn't be fun to have these kind of issues in an SRU situation, I can imagine
<wgrant> apw: A normal upgrade should do that.
<wgrant> Only dist-upgrade will remove.
<wgrant> diwic: SRUs are copied atomically from -proposed to -updates.
<apw> and dist-upgrade is what update-manager is doing no ?
<wgrant> diwic: After they've built.
<pitti> well, dist-upgrade is really the "normal" case, t hough
<diwic> wgrant, I'm not saying wait for all; just wait for amd64 and i386 to be in sync
<apw> and indeed what i am always advised i need to do to actually have what the archive intends on my machine
<wgrant> diwic: But what if I have armel installed as well? :)
<apw> thats why it needs to be apt side, it knows what combinations you have installed
<diwic> wgrant, hmm, there are no amd64-armel dependencies the way there are amd64-i386 dependencies (for certain software)
<diwic> so is the situation really applicable on that case?
<wgrant> diwic: But it's very possible to have armel binaries installed on an amd64 system.
<wgrant> And multiarch requires that the versions be identical.
<wgrant> Regardless of dependencies.
<wgrant> It's similar to the old arch-all skew issue, which we solved in Launchpad a few months ago.
<wgrant> Right around the time the multiarch problem sprung up :D
<diwic> wgrant, hmm, maybe we need to fix/improve multiarch instead then? I can understand cases where both amd64 and armel would depend on an -all package
<diwic> in which case the upgrade must be held back until both versions are ready
<wgrant> That's a bit of a challenge.
<wgrant> That would be doable, I imagine.
<wgrant> But removing the version match restriction is a little difficult.
<diwic> but maybe I should go back to discuss what I know :-) and trust you guys to work out apt for me.
<dholbach> FourDollars, normally https://launchpad.net/ubuntu/precise/+queue
<dholbach> FourDollars, but it seems it was accepted already
<dholbach> FourDollars, http://pad.lv/u/hime
<FourDollars> dholbach: Thanks.
<apw> pitti, any idea how long we are going to be skewed by the buildds?  as i have half of the X update installed now as a result of doing 'update' and i am not sure thats a good combination
<apw> pitti, hopefully its not the 12/13 days that the status page implies
<pitti> apw: no, I think a day or less
<pitti> apw: the 13 days is because we are running a rebuild test on the main builders
<pitti> but most is universe
<apw> pitti, why is the rebuild on the main builders, and if its going to be, why are we not putting some more online
<pitti> I don't know
 * apw assumes its cause they are doing armhf as well
<pitti> apw: you know, if only we had some technology to temporarily rent 200 vboxes from amazon or so..
<apw> pitti, or perhaps we had our own openstack instance
 * pitti guesses it's to heat up the DC
 * pitti brrrrrs at -14 degrees
<apw> pitti, now that is cold, i am whining cause its -1 outside
<tjaalton> you had some general warning that it might get -10 or even less :)
<tjaalton> we have -17 and a blizzard
<tjaalton> was fun driving this morning
 * apw isn't going out "there"
<Laney> One of the brakes on my bike was frozen this morning ...
<smb> apw, You would feel awake and alive... well for about 1 minute... :)
<cking> it's a relatively balmy -1 degrees C here
 * diwic weighs in at -11
 * tumbleweed waves from the land of 28Â°C :)
<dholbach>  /ignore tumbleweed
<dholbach> "oops"
<dholbach> :)
 * apw puts hit feet on tumbleweed
<apw> his
 * Laney is wearing 2.3 tog rated socks :-)
<ajmitch> tumbleweed: now that's just cruel
<Laney> mini duvets
 * tumbleweed decides he should mabe put a shirt on
<MacSlow> mvo, ping
<apw> cjwatson, i upgraded O->P and its not kept the latest kernel from the old series correctly, any idea what does that chosing ?
<cjwatson> apw: there is a ticket open already to upgrade the primary buildd pool
<cjwatson> apw: upgrade> um, not sure I understand
<apw> cjwatson, i thought that when we upgrade N -> N+1 that we keep the latest kernel installed from N as well as a fallback
<apw> my upgrade seems to have purged that kernel
<cjwatson> apw: I thought that was usually just by way of not removing the currently-installed kernel
<cjwatson> apw: if there's any specialised logic here, it must be in update-manager
<apw> cjwatson, ahh, so if i was runnning something else i'd not keep it, ok that makes sense at least
<cjwatson> apw: update-manager/DistUpgrade/DistUpgradeCache.py:MyCache.identifyObsoleteKernels(), I think
<apw> cjwatson, thanks :)
<cjwatson> indeed it removes obsolete kernels but skips the running kernel
<apw> which actually is very logical, as that one clearly works
<cjwatson> right :)
<mvo> MacSlow: pong
<apw> cjwatson, so i now forgive it :)
<mvo> *puhhh*
<Pjotr> cjwatson: in ubiquity, there's an incorrect and misleading message, which should be adapted or deleted, IMHO. Because it may lead to damage.
<Pjotr> I've made a Launchpad bug report about it: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/925427
<ubottu> Ubuntu bug 925427 in ubiquity (Ubuntu) ""Ready when you are" message is misleading and incorrect" [Undecided,Confirmed]
<Pjotr> Can you do something about it?
<cjwatson> mpt: ^-
<cjwatson> I believe that's a design-specified message, and it's already been through an iteration or two.  I'd like mpt to review and suggest an amended design rather than just changing it myself.
<mpt> ah yes
<mpt> I don't think there's been a formal test on it, but that's tripped up everyone I've watched installing
<mpt> Not that they think installation is finished, but that they sit there waiting for something else to happen
<cjwatson> The original intent was to remind people that the installer is currently waiting for you to finish answering questions before it can carry on
<cjwatson> "Get on with it"
<apw> :)
<apw> "Waiting for you to complete the configuration questions"
<cjwatson> Gets a bit long for a button :)
<cjwatson> Er, actually it isn't a button is it
<mpt> cjwatson, do you have a screenshot handy?
<cjwatson> Not immediately
 * cjwatson googles
<Pjotr> I'm sorry, I have no screenshot either...
<cjwatson> mpt: http://cache.sudobits.com/wp-content/uploads/2011/09/create-user.png
<cjwatson> from http://blog.sudobits.com/2011/09/11/how-to-install-ubuntu-11-10-from-usb-drive-or-cd/
<cjwatson> it might appear on previous question pages as well
<Pjotr> It's not related to any Ubiquity instance that needs a user action. In that way, the screenshot is a bit confusing
<cjwatson> Hmm?  It certainly is - it's waiting for the user to complete the action of answering all the questions
<cjwatson> The user setup page constitutes some of those questions
<mpt> thanks cjwatson -- I think this is going to require more than a string fix unfortunately
<Pjotr> No, the answering could have happened earlier on, and been finished already.
 * cjwatson eyes his upcoming leave
<cjwatson> Pjotr: In that case you won't get the "Ready when you are" message.
<Pjotr> the "ready when you are" message happens anyway, regardless
<mpt> I've talked about this with ev before, maybe moving the progress bar bit to the top and then saying something like "While we're doing that..."
<cjwatson> Pjotr: It's not supposed to.  That would be a separate problem.
<cjwatson> mpt: OK, I definitely won't have time for that, so I guess the question is whether we can reasonably do something intermediate
<cjwatson> Fixing the message being shown when we aren't actually waiting for the user would be an example
<Pjotr> sounds fine to me... :-)
<cjwatson> Unfortunately that code is some of the twistiest in ubiquity ...
<cjwatson> Maybe http://paste.ubuntu.com/827492/ (untested)
<mpt> "This flight is ready to depart. All other passengers are waiting for you."
<cjwatson> I had that for me once - I made like Linford Christie
<Pjotr> It's a bit above my head now... Thanks for the attention that you're giving this matter. Hopefully you'll be able to fix it before Precise ships.
<Pjotr> Goodbye
<mpt> cjwatson, how many steps are there after that progress bar appears? Is it just the "Who are you?", or are there others?
<cjwatson> Everything from location on
<cjwatson> So location, keyboard, user, possibly migration and webcam, and I have a feeling I'm missing one
<tjaalton> is alpha1 livecd still available somewhere?
<mpt> cjwatson, I've just written half a dozen possible strings and they all suck :-)
<mpt> cjwatson, how about just hiding the black area altogether? That should be a simple GTK property, right?
<mpt> And then re-showing it once stuff starts happening again.
<cjwatson> mpt: Wasn't the worry about that that people didn't notice that we were waiting for them?
<cjwatson> Maybe that isn't a real concern
<mpt> cjwatson, I think the root cause is either that they see a progress bar and think that something's happening, or that they see a filled progress bar and think that everything's finished.
<cjwatson> We'd want to avoid the window resizing
<mpt> yes
<cjwatson> Let's see.  This takes ages to test unfortunately ...
<cjwatson> I wonder how bad it would be to hide all the elements but keep the black area
<mpt> (BTW I was hunting around for a screencast of the installation process to give me more context, and then realized, oh, YouTube. There's hundreds of them.)
<mpt> cjwatson, I think that would be fine.
<cjwatson> Yeah, I don't bother keeping screencasts any more because the Internet does it for me
<cjwatson> In fact the black area balances nicely with the title area, doesn't it ...
<mpt> yes
<cjwatson> Happy to give that a try and see what it does
<cjwatson> Damn, and this test requires me to sit and watch the installer because I need to see what it does just after it's finished copying files ...
<dholbach> seb128, salut mon ami
<dholbach> what do we do with goocanvas-2.0 in the queue? :)
<seb128> dholbach, hey, sorry I was at lunch
<seb128> dholbach, I was thinking about that yesterday, what about the other sources for murray? ;-)
<seb128> didrocks, Riddell: is there any chance you could review goocanvas in source NEW? it's there since the rally and blocking some other packages to land, should be an easy enough one
<seb128> it's basically a new version of goocanvas for gtk3 renamed
<didrocks> seb128: pending to my list
<seb128> didrocks, thanks
<didrocks> yw :)
<dholbach> seb128, which other sources?
<seb128> dholbach, libgdamm and goocanvasmm and the glom update
<dholbach> seb128, you mean goocanvasmm and glom? no idea - I would have to look up if there are merge proposals for them
<dholbach> I'm a bit hard pressed for time this and part of next week
<seb128> dholbach, I don't think there are, we should find somebody to do it though ;-)
<seb128> dholbach, yeah, I didn't mean you need to do it
<dholbach> maybe a blog post or post to ubuntu-desktop?
<seb128> dholbach, yeah, I will try to figure something out ;-)
<dholbach> awesome
<mdeslaur> mvo: mind if I upload a new software-properties?
<mdeslaur> mvo: too late :)
<mvo> mdeslaur: please do and thanks!
<mdeslaur> mvo: cool, thanks
<apw> i assume the unity upload is responsible for my machines desire to remove ubuntu-desktop and unity
<apw> and ... didn't we decide building this stuff in a PPA made more sense as it always triggers this?
<cjwatson> I doubt it, it failed to build on all architectures
<mdeslaur> yeah, dist-upgrade wants to remove ubuntu-desktop and unity for me too
<cjwatson> more likely nux
 * cjwatson eyes didrocs
<cjwatson> didrocks
<didrocks> cjwatson: ABI break, unity will build as soon as bamf is published
<seb128> it's being fixed
<seb128> they run into new depreciations in the glib uploaded yesterday combined with -Werror
<mdeslaur> \o/
<seb128> but yeah, having a ppa we can pocket copy from would be nice
<cjwatson> bamf is published now for all but armel, as far as the buildds are concerned
<seb128> it would have been useful for the glib,gtk upload yesterday as well
<cjwatson> so you can retry on !armel now
<Beret> hmm
<didrocks> we should really discuss about pocket copy yeah :)
<Laney> There was discussion at UDS (also in #-motu yesterday) about using proposed for this.
<roadmr> hello! How can my (Python) app get the user's default browser (as configured in system info -> default apps) to open a URL? what's the recommended way?
<seb128> Laney, yeah, I was in that UDS session, that would work ;-)
<Laney> providing LP lets you copy down from proposed to release
<seb128> roadmr, try using the gio g_app_info_get_default_for_type () api I guess
<seb128> or g_app_info_get_default_for_uri_scheme()
<roadmr> seb128: awesome! I want to open a local .xml file, I'll give those two a try
<cjwatson> roadmr: there's Gtk.show_uri() too
<roadmr> cjwatson: thanks, another option to try!
<cjwatson> >>> from gi.repository import Gtk, Gdk
<cjwatson> >>> Gtk.show_uri(None, 'http://www.ubuntu.com/', Gdk.CURRENT_TIME)
<zul> pitti: its updated packages that are needed in order to get the openstack experience working together in oneiric
<GunnarHj> cjwatson: Hello, Colin!
<GunnarHj> cjwatson: cjwatson: Currently, if I understand it correctly, the installer sometimes sets LC_MESSAGES, LC_CTYPE and LC_COLLATE in /etc/default/locale. Considering recently uploaded changes in accountsservice and language-selector, meaning that those env. variables are no longer used, the installer should better stop doing those settings.
<cjwatson> GunnarHj: please file a bug, I'm going to need this written down permanently somewhere for the record
<cjwatson> anyway I'm not convinced
<cjwatson> the installer does that for reasons outside what language-selector happens to be doing today ...
<cjwatson> (Incidentally, I wish this would stop changing.  It's disruptive.)
<GunnarHj> cjwatson: I'll file a bug.
<GunnarHj> cjwatson: It's about a conceptual (hopefully final) change. LANG is now considered to represent the language, so in cases where people wants some other locale for regional formats, the formats related LC_* variables are now set explicitly.
<cjwatson> In other words, even if accountsservice et al are no longer consuming those variables, that's entirely irrelevant - they're part of the POSIX locale system and affect other applications.
<cjwatson> It is wrong to rely entirely on accountsservice/language-selector for that, IMO.
<cjwatson> The installer sets multiple variables when it's been given information it can't just cram into LANG.
<GunnarHj> cjwatson: Yes, but what I'm suggesting is that it should rather set the formats related LC_* variables instead of LC_MESSAGES, LC_CTYPE and LC_COLLATE.
<cjwatson> OK, IRC is too narrow for this conversation.
<GunnarHj> cjwatson: I'll try to explain it on the bug.
<barry> hello.  is anyone else noticing broken upgrades today on multiarch systems?
<MacSlow> mvo, ping
<mvo> pong
<doko> chrisccoulson, is it expected that libxul-dev is missing from firefox-dev?
<doko> ehh, libxul.pc
<chrisccoulson> doko, yeah, nothing should be linking against our libxul. what needs it?
<chrisccoulson> libxul.pc is specifically for embedders
<micahg> pitti: they need to be tested
<mhall119> stgraber: ping
<stgraber> mhall119: pong
<mhall119> stgraber: hey, can I talk to you for a minute about the ARB's rules?
<stgraber> mhall119: sure
<mhall119> stgraber: so getting 3rd party Unity lenses and scopes in software-center is a big deal
<mhall119> but scope packages will need to depend on the lens package they work with
<mhall119> I was told that we were going to get an exception for this, so a scope package in extras can depend on a lens package in extras
<mhall119> has this become the official ARB policy yet?
<stgraber> right, which they can only do if they are built from the same source or if the lens package is in the distro and not in extras
<mhall119> so we want different people making the scopes
<stgraber> the only exception we approved is for one source to build multiple packages and have them depend on each other, we still don't allow two different sources in extras to build packages depending on each other
<mhall119> so they would be in independent source packages
<stgraber> and don't plan on allowing that
<mhall119> ok, that's someething we need to consider, otherwise we will lose a lot of the benefit of the dash
<stgraber> the reason is, packages in extras need to be independent as we can pull them off at any time if they break
<mhall119> stgraber: can you join ubuntu-app-devel?
<stgraber> so I'd recommend whoever submits the lens to the ARB do the work of aggregating the scopes and send us that as a single source package building multiple binary packages
<stgraber> mhall119: can you join ubuntu-arb? :)
<bdrung> doko: openjdk-6 has still broken multiarch support
<doko> chrisccoulson, icedtea-web
<doko> bdrung, your level of detail is fantastic
<chrisccoulson> doko, oh, icedtea-web should definitely be using mozilla-plugin.pc :)
<doko> ok
<bdrung> doko: comment #2 on bug #879167
<ubottu> Launchpad bug 879167 in openjdk-6 (Ubuntu) "Broken multi-arch support" [Medium,In progress] https://launchpad.net/bugs/879167
<chrisccoulson> i thought it was already though?
<chrisccoulson> i must have been confused
<chrisccoulson> sorry about that!
<doko> yeah, a configure check still uses libxul
<bdrung> doko: the order of the "grant codeBase [...]" lines matter
<doko> bah
<mdeslaur> seb128: you can poke tyhicks about your ecryptfs issue
<slangasek> smb: hi, can you confirm that the ppa upstart still works for you with --log?  (The ppa package has --no-log as a default still)
<morphis> anyone here knows if I can build packages for my ppa and armhf architecture?
<morphis> (on launchpad)
<seb128> mdeslaur, I will open a bug later, it's basically
<seb128>  - apt-get source automake1.11
<seb128>  cd automake1.11-1.11.1
<seb128>  ./configure && make
<seb128>  cd tests
<seb128>  ./distdir.test
<brendand> morphis - no
<tyhicks> seb128: hi - I don't see any mentions of the problems in backscroll, so let me know what problems you're having
<seb128> mdeslaur, tyhicks: ^
<seb128> sorry i've to go for dinner
<morphis> brendand: so I have to build locally with qemu until I have a native board
<mdeslaur> seb128: thanks
<seb128> same issue on https://launchpad.net/ubuntu/+archive/primary/+files/automake1.11_1.11.2.orig.tar.bz2
 * tyhicks gives it a go
<seb128> it fails to rm empty file in the dist dir
<seb128> bbl
<brendand> morphis, i guess so
<brendand> morphis - #ubuntu-arm is a good channel for ARM questions too
<brendand> morphis, but i know you can't do armhf builds in a ppa
<morphis> brendand: #ubuntu-arm is a very good idea
<brendand> morphis, for that matter - can you do armel builds?
<morphis> brendand: hm, I coming from OpenEmbedded and currently trying to find out how I can do embedded development with debian/ubuntu
<morphis> brendand: I didn't tried yet
<morphis> brendand: I am just trying to find out all relevant details before I start with the real stuff
<tyhicks> seb128: I've subscribed you to bug 926292
<ubottu> Launchpad bug 926292 in linux (Ubuntu) "automake distdir.test fails because of an EPERM error" [Medium,Confirmed] https://launchpad.net/bugs/926292
<tyhicks> seb128: I'm heading out, but I'll try to get some time to chase down the problem this weekend
<seb128> tyhicks, thanks
<andrejz> hello! any unity developers out there?
<andrejz> i hae a question about new string in unity 5.2
<hallyn> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn
<ScottK> andrejz: I think #ubuntu-unity or #ubuntu-desktop would be better (I don't recall for sure).
<andrejz> ok thanks
<bladernr_> Hey, can anyone answer a quick question about apport and /var/crash... when a crash dump is created and put into /var/crash, I've noticed that there's also a hidden lock file in /var/crash.  What creates that and why?
<bladernr_> nm... found an answer in apport changelog
<hallyn> hi everyone - I've tested and verified (and 'Approved') https://code.launchpad.net/~jtaylor/ubuntu/oneiric/subversion/sasl-crash-881862/+merge/85228 .  I don't have the rights to actually upload it.  Is someone around who can finish that off?
<hallyn> roaksoax: ^
<dobey> ayone around?
<dobey> who should i subscribe to a bug to upload a new source package (which replaces an existing source)?
<jtaylor> hallyn: micahg wanted to do that soonish
<jtaylor> thanks for testing ig
<jtaylor> it
<hallyn> dobey: hi, i think you can subscribe "ubuntu-sponsors"
<dobey> hallyn: thanks
<hallyn> jtaylor: ok (np)  I just don't have the rights to actually upload it to the archive, or i'd finish it up right now
<jtaylor> me neither, and for some reason sponsors don't like me, I have 3 of the top 9 oldest things in the queue :(
<hallyn> jtaylor: well you scare me with the 'multiarch' one - that's nothing personal, i'm just a wuss :)
<jtaylor> yes thats an uglyone :/
<hallyn> jtaylor: tbh i was hoping stgraber or slangasek would look at that one.  but maybe i should man up...
<hallyn> jtaylor: so with the multiarch one - you say oneiric has been patched to work around it.  precise's too?  so you actually want that merged into lp:ubuntu/natty/python-numpy (not lp:ubuntu/python-numpy)?  Or am i misreading?
<jtaylor> no I actually wanted a fix in oneiric but it was to late in the cycle
<jtaylor> so instead the rdepends where patched
<jtaylor> this is now prettymuch to fix it for non packaged stuff
<jtaylor> though now its pretty much as late as it was when I wanted it in oneiric :/
<slangasek> we're still before ff
<jtaylor> its noot even a new feature just a minimal (ugly) workaround
<slangasek> my point is that it's not currently late at all
<hallyn> jtaylor: I'm wondering if something more like https://launchpadlibrarian.net/78315456/libxaw-1.0.9.multiarch.diff could be done (to make it - i hope - more standard - i don't judge ugliness when it comes to x stuff)
<hallyn> i.e. --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) passed to confgure in debian/rules
<jtaylor> its the issue of the buildsystem numpy *provides* for other stuff
<cjwatson> if any MIR team folks are still around, debtags and java-atk-wrapper are currently on the list for promotion to main; I've seen at least debtags breaking image builds and java-atk-wrapper looks like a possibility for that too
<hallyn> ah
<cjwatson> I'd like not to leave image builds broken over the weekend
<jtaylor> so it must now the triplet of the host its used on not where numpy wasy built on
<jtaylor> s/now/know/
<slangasek> java-atk-wrapper is breaking builds already, yes
<slangasek> jdstrand: ^^ are you up for some MIRs?
<cjwatson> the other three source promotions look like they can wait
<slangasek> I had perhaps wrongly assumed that since doko did the upload that pulled java-atk-wrapper in, and he has strong opinions about prepromotions, he might have gotten the MIR done first ;)
<jdstrand> slangasek: I have about 10 in my queue assigned to me. I was dealing with some important updates today. I won't get to them until monday
<cjwatson> *shocked face*
<jdstrand> slangasek: if you want to assign it to me-- I have an appt in a few minutes
<slangasek> I actually don't see an MIR open for java-atk-wrapper
<slangasek> perhaps it's already marked closed?
<cjwatson> neither have bugs open according to component-mismatches
<hallyn> jtaylor: I'm trying to use your "ldd -r /usr/lib/python2.7/dist-packages/kiva/agg/_plat_support.so" to verify it's broken, but i don't get the break.  I'm sorry I'm being dense, but is there any other quick recipe I can use to verify?
<cjwatson> oh, wait, java-atk-wrapper just vanished from c-m
<jtaylor> hallyn: this library is from which package?
<cjwatson> moving targets FTW
<jtaylor> hallyn: version, the one in oneiric and precise have been fixed
<jtaylor> hallyn: you have to compile the natty package on oneiric to get the broken version
<cjwatson> so it's just debtags
<hallyn> jtaylor: oh *that*'s what you were saying.
<slangasek> right, bug #849729 was the MIR for j-a-w
<hallyn> jtaylor: off to try again
<ubottu> Launchpad bug 849729 in java-atk-wrapper (Ubuntu) "[MIR] java-atk-wrapper" [Undecided,Fix released] https://launchpad.net/bugs/849729
<jtaylor> hallyn: with this numpy the workaround applied to enable is not necessary anymore
<jtaylor> hallyn: it will then find the multiarched libraries and link them correctly
<hallyn> jtaylor: thanks, got it.  fetching to build...
<slangasek> cjwatson: maybe it's better to push a s-c that drops debtags for now?
<cjwatson> dunno - debtags was in main in hardy
<slangasek> oh
<slangasek> then hmm
<cjwatson> which is a while back,but
<cjwatson> due to adept-common
<hallyn> jinkeys: bzr just segfaulted while trying that merge
 * cjwatson looks at what s-c is doing
 * slangasek teaches ureadahead about /run
<cjwatson> wuh, I thought I'd done that
<cjwatson> bah, changed locally 2011-10-22, never committed :-(
<cjwatson> http://paste.ubuntu.com/828250/
 * slangasek nods
<cjwatson> s-c actually copes if debtags is missing - it's in a try/except
<slangasek> strangely, my /var/log/upstart/ureadahead.log complains about lots of symlinks that seem to be from under proc... I wonder if those should be filtered out at an earlier stage
<cjwatson> though it looks like a fairly deliberate addition
<cjwatson> by mvo
 * slangasek nods
<cjwatson> definite feature work here
<slangasek> hah, there's an interesting question.  should ureadahead force a reprofile when the only package that's changing under /etc/init is itself?
<slangasek> (ureadahead doesn't reprofile on upgrade, because triggers don't apply to self->package)
<cjwatson> mm, postinst configure is usually meant to be a superset of postinst triggered, I believe
<cjwatson> I think it should - omitting /run from the pack is a good example of something that should cause reprofiling
<cjwatson> or it might even change its pack format
 * slangasek nods
#ubuntu-devel 2012-02-04
<hallyn> jtaylor: just a note, because (to my chagrin) packaging trees are stored with patches applied, it can confuse matters when you don't do so in your merge proposals :)
<jtaylor> I know, but I don't like it, I like my diffs small ;)
<jtaylor> hasn't that also changed now?
<hallyn> jtaylor: i dunno.  but my first build somehow failed to get your fix (i thought debian/rules build would quilt push, but apparently it didn't)
<hallyn> cjwatson: (cause i'm not sure who else to ask) once a merge proposal is approved, if the approver doesn't have upload rights, does that hit another queue where someone will see it and push it?
<hallyn> (i'd ask dholbach but don't see him here)
<hallyn> i just want to make sure the mp didn't just get buried in a hole somewhere
<hallyn> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 2 released!  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> hallyn: not afaik but I think it stays on the sponsorship queue
<hallyn> cjwatson: oh, sorry - I thought when I looked earlier it had been removed, but i see it's still there.  thx
<broder> hallyn: jtaylor: do you guys still need sponsorship for svn? i have 45 minutes at the airport before my flight boards :)
<broder> hallyn: the code for the sponsor queue is in lp:ubuntu-sponsoring - i believe that approved/disapproved/etc. reviews have no impact on whether or not something's in the queue; my recollection is that it's all based on the "status" (i.e. "work in progress", "needs review", etc.) at the top of the page
<broder> which is why you'll see people reject changes by changing the status to "WIP"
<broder> bah. it may take me all 45 of these minutes to manage to clone the bzr branch over airport wifi
<stgraber> broder: bzr co --lightweight?
<broder> huh, interesting. maybe sponsor-patch should support that
<hallyn> broder: sorry, was afk (obviously).  yeah there are two merge proposals by jtaylor that i approved but don't have rights to upload
<hallyn> svn and python-numpy
<broder> hallyn: i'm, uh, 4/5ths through downloading the build-deps for a test build, so i don't think that's likely to finish before i have to pack up
<hallyn> broder: thanks for trying :)
<hallyn> sounds like my experience trying wifi at portland airport...
<hallyn> everyone tells me it was atypical though
<broder> yeah, sfo is always crappy, but at least it's free :)
<broder> and that's my cue to leave. i can try again later, but maybe someone else will show up
<ajmitch>  /win 44
<ion> /lose 45
<cnd> slangasek, I'm having some issues with creating a new package using the debian X git guidelines
<cnd> are you still around?
<slangasek> cnd: barely
<slangasek> what's the problem?
<cnd> dpkg-source: info: local changes detected, the modified files are:
<cnd>  xorg-gtest/autogen.sh
<cnd> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/xorg-gtest_0.1.0+git5b26608-1.diff.a_LeY9
<cnd> upstream git has autogen.sh
<cnd> the shipped tarball does not
<cnd> somehow this isn't a problem in all the X packages
<cnd> but I can't figure out why it's different for this package
<slangasek> is this package source format 3.0 (quilt) where the others are not?
<slangasek> I think I've seen this error message before on a package in X git, but I don't remember the solution offhand
<cnd> yeah
<cnd> I just noticed that
<cnd> maybe that's why they haven't switched to 3.0 (quilt)?
<slangasek> I doubt that's the reason
<slangasek> you could just git rm autogen.sh on the packaging branch
<slangasek> but if debian/rules is calling dh_autoreconf, that may not be what you want
<cnd> the X stuff requires being able to call dh_autoreconf
<cnd> I'm trying to follow their approach for a new X package we're developing
<slangasek> then you probably want to stick with format 1.0 for now :)
<cnd> but moving to (3.0) quilt if possible
<cnd> heh
<slangasek> but you could ask on #debian-x@OFTC
<cnd> yeah, I just did, but I thought I'd ping you too in case you knew :)
<slangasek> yeah, dunno a perfect fix here, sorry
<cnd> slangasek, one last question, where is dpkg-source called from
<cnd> if I want to override dh
<cnd> it looks like dh_clean
<cnd> but I can't find any reference in the man page
<slangasek> dpkg-source isn't called from debian/rules at all
<cnd> what would be calling it?
<slangasek> uh
<slangasek> what command are you running? :)
<cnd> debuild -i -I
<cnd> http://paste.ubuntu.com/828346/
<slangasek> ok, then the layering is debuild -> dpkg-buildpackage -> dpkg-source
<cnd> so is dpkg-buildpackage calling dh_clean and then dpkg-source?
<cnd> yeah, man dpkg-buildpackage spells it out
<cnd> alright, I'll poke some more
<cnd> thanks :)
<slangasek> dpkg-buildpackage is calling "dpkg-source -i -I --before-build xorg-gtest", then "fakeroot debian/rules clean", then "dpkg-source -i -I -b xorg-gtest"
<slangasek> sure thing
<cjwatson> slangasek: I've promoted python-debtagshw and its source package in order to unbreak things.  Do you think it needs an MIR, given that it was previously in main and I don't remember this being a problem?
<cjwatson> the original MIR predates our use of bugs for them; https://wiki.ubuntu.com/MainInclusionReportDebtags
 * ScottK thought previously in Main was one of the "you don't need a MIR" reasons.
<cjwatson> I think I only asked because it was a while back.  Normally, certainly yes.
<slangasek> cjwatson: not sure how much my opinion counts for there :)  But debtags is pretty low-risk anyway...
<doko> cjwatson, slangasek java-atk-wrapper has a resolved MIR, pitti is just to quick to demote things ... :-/
<koolhead17> cjwatson: hello there
<rrs> m4n1sh: You there. PM ?
<m4n1sh> rrs: yes
<rrs> Or let me ask here itself.
<m4n1sh> yes, ask
<rrs> I recently switched to Ubuntu. Impressed with the work.
<rrs> My pbuilder (cowbuilder) is not honoring APTCACHE value. Do you have any clue?
<rrs> Could something be interfering? Is the cow/pbuilder patched here?
<m4n1sh> let me check
<rrs> Could apparmor be denying?
<rrs> I tries to acquire the cache (mine set is /var/cache/apt/archives/), stalls for 2 seconds, and then silently proceeds. I'm sure there's a failure there, just that it doesn't show up.
<rrs> *It
<m4n1sh> rrs: this is the package https://launchpad.net/ubuntu/precise/+source/cowdancer/0.67
<rrs> yup
<rrs> BTW, I'm using it for sid and precise.
<m4n1sh> doesnt look patched, looks like a direct import
<rrs> Followed the excellent howto by doko: https://wiki.ubuntu.com/PbuilderHowto
<rrs> Just that the cache never gets honored. The cached packages are there in /var/cache/apt/archives/ . But on next build, it again triggers a download.
<m4n1sh> that's bad. Bandwidth is limited
<m4n1sh> does it work on sid?
<rrs> Who'd be the cowbuilder maintainer here?
<rrs> Yes. It used to. Now that I'm on ubuntu, can re-check it rightaway.
<m4n1sh> yes
<m4n1sh> and here is how to check for apparmour issue (if any) https://wiki.ubuntu.com/DebuggingApparmor
<rrs> I looked at that.
<rrs> By that doc, and from what I investigated, apparmor only confines a set of apps. Not the entire system. So I doubt that apparmor is interfering.
<rrs> Who'd be the cowbuilder maintainer here? Or should I just file the bug report?
<m4n1sh> rrs: there is no specific maintainer
<rrs> A Team ?
<cjwatson> It's maintained in Debian.
<m4n1sh> universe repository is in hands of MOTU ( #ubuntu-motu )
<rrs> Hello Colin.
<cjwatson> We don't modify it for Ubuntu.
<m4n1sh> rrs: Debian maintainer shows as "Junichi Uekawa <dancer@debian.org"
<rrs> OKay!!! I guess I'll have to root cause it myself then :-)
<m4n1sh> if you find the issue, then please try to fix it in ubuntu too
<rrs> Definitely. I really love the desktop integration so far.
<dafox> hi all. Could anyone please clarify why the lcdlegacy filter does not seem to be present in the freetype package?
<dafox> other settings in /etc/fonts/local.conf are respected, even setting lcdfilter none or slight, but no matter what I do I seem to be unable to get lcdlegacy.
<ion> dafox: If youâre using gnome-settings-daemon, it needs a patch not to override that setting. If you feel like trusting my PPA, the sharp-text-rendering package should fix the issue: https://launchpad.net/~ion/+archive/gsd-lcdfilter
<dafox> ion: I have installed the sharp-text-ppa, but for some reason it doesn;t seem to be working
<dafox> I installed it on another laptop last week, and there it did work
<ion> Huh
<dafox> the difference is that that was 'regular' ubuntu, and this is xubuntu.
<ion> Ah, Xubuntu doesnât use gnome-settings-daemon indeed. If you figure out how to fix the issue in Xubuntu, iâd be happy to add that change to the package.
<dafox> I've been trying everything I can find, but nothing seems to work short of compiling freetype with the force_legacy option
<dafox> ion: any ideas what could be wrong or where to look?
<dafox> e.g. is this an xfce issue, or some other library?
<ion> Iâd try to figure out whether Xubuntu has some config files iâve missed and whether it has some kind of a desktop settings daemon that overrides other configuration (Ã  la gnome-settings-daemon).
<dafox> I'll try
<dafox> but the built-in freetype should have lcdlegacy built-in? (is there any way to check this?)
<ion> grep the binaries, the source packages and/or the respective /usr/share/doc/*/changelogs.
<ion> grep them for lcddefault since thatâs what something forces your system to use.
<dafox> tried the binaries already, it's not there (but neither on my other system), I'm looking into getting the source packages now but I'm not sure where to get them
<dafox> launchpad probably?
<ion> apt-get source packagename (but thatâs not that helpful unless you already have an idea which packages you want to look at).
<ion> The changelogs should have an entry about any lcdfilter-specific patches in installed packages.
<dafox> but would that include the configuration? e.g. the configure line, or edits done to include/freetype/config/ftoption.h
<ion> Difficult to say in advance.
<dafox> ok
<falkoned> I just can't stand this http://pastebin.com/smrNHCHe
<falkoned> Ubuntu 10.04.3 amd64
<falkoned> how to fix this?
<falkoned> many people filled a bug on launchpad
<falkoned> no fix or workaround at the moment
<falkoned> why even developers allow users to encrypt their /home when ecryptfs is so unstable and problematic?
<falkoned> this should be disabled by default until these bugs will not be definitely fixed
<falkoned> many other operating systems which have a way better support for encryption _do_not_ suggest by one-click way to encrypt any of filesystems as ubuntu does
<falkoned> and this ecryptfs errors are horrifying as hell
<falkoned> s/this/these
<mdeslaur> falkoned: that is LP: #842647, please track progress there
<falkoned> mdeslaur: so lets say some dev will fix this- will it affect release 10.04?
<mdeslaur> falkoned: tyhicks would know
<mdeslaur> tyhicks: ^
<dafox> ion: the xfce people are saying that it is impossible that xfce is at fault, since xfce-4.8 (which is used in xubuntu-11.10) does not yet support setting these options, and relies on fontconfig
<koolhead17> cjwatson: ping
<mr_pouit> dafox: check your ~/.Xdefaults file too
<falkoned> shouldn't we use ~/.Xresources these days?
<dafox> mr_pouit: Thank you!! That was it!
<dafox> the file was already there, and it contained .Xft rules setting the hinting to slight and the filter to default
<dafox> mr_pouit: you're my hero of the day :D
<falkoned> tyhicks: ping
<ion> dafox: Duh :-D
<dafox> still should probably file a bug
#ubuntu-devel 2012-02-05
<micahg> jtaylor: there's another thing I'm uploading?
<HFSPLUS> !ops
<HFSPLUS> fuck all u fuckwits
<HFSPLUS> fucking niggers
<HFSPLUS> !staff
<HFSPLUS> fuck u
<astraljava> What is this? Some bot trigger testing?
<lifeless_> no, its someone that thinks it is funny
<lifeless_> I don't know why
<micahg> spamapS: are you interested in merging pdns, you touched it last (Bug #876801)?
<ubottu> Launchpad bug 876801 in pdns (Ubuntu) "PowerDNS 2.9.22 package is out of date" [Wishlist,Confirmed] https://launchpad.net/bugs/876801
<azop> I'm trying to pass a global variable for a schroot build.  I have DEB_BUILD_OPTIONS="parallel=4" in the schroot.conf file, but it isn't passing that to the schroot like I would hope.
<azop> Am I missing something?
<micahg> azop: you want -j4
<azop> DEB_BUILD_OPTIONS="-j4" instead of DEB_BUILD_OPTIONS="parallel=4"?
<micahg> yes
<azop> k, I change it to: environment-filter=DEB_BUILD_OPTIONS="-j4"
<azop> dh_auto_build is still using make -j1
<micahg> something could be unsetting it
<micahg> you can try passing it directly to sbuild, --debbuildopt='-j4'
<azop> hrm
<azop> in debian/rules?
<micahg> which, --debbuildopt goes on the command line to sbuild, something might be overriding in debian/rules of the upstream make files
<azop> okay, I'll look into that
<azop> thanks
<tumbleweed> erm, DEB_BUILD_OPTIONS="parallel=4" should go through to sbuild just fine
<tumbleweed> but its up to the package to do something useful with it
<tumbleweed> (e.g. dh --parallel)
<micahg> right, that's true, but AIUI, -j is the classic way to do that, sorry, should have been more clear
<azop> tumbleweed: that is what I thought.  I have         dh --parallel $@
<shadeslayer> cjwatson: hi! I was wondering if you could merge the bluez package from debian, it contains a fix for bug 927097
<ubottu> Launchpad bug 927097 in bluez (Ubuntu) "C++ apps will fail to compile with current bluez package" [Undecided,New] https://launchpad.net/bugs/927097
<cjwatson> shadeslayer: sorry, I don't have time and don't really know much about bluez - my last upload was just a drive-by upgrade fix.  I'm happy for anyone else to do it
<shadeslayer> hmmm
<shadeslayer> cjwatson: I'll give it a poke myself then, I've never packaged anything apart from KDE stuff ... so don't know if I'll be able to do it
<bregma> hey folks, anyone know why I always get an error about __aeabi_unwind_cpp_pr1@GCC_3.5 not found in any library when building any package on an armhf target using pbuilder-dist?
<SpamapS> micahg: I was going to do a final sweep for merges such as that this week given upcoming FF. If you want to do pdns, its all yours. :)
<jtaylor> SpamapS: numpy and sphinx should be merged
<jtaylor> we definetly want numpy -4 for the better dh_*helper
<SpamapS> jtaylor: well I'm not doing a full sweep... just merges that I am TIL on the package for.
<jtaylor> til?
<SpamapS> jtaylor: touched it last
<DasKreecH> Hello if I was looking for support from Canonical is there a channel I can go to (or nick) to ask questions about the terms?
<micahg> spamapS: if you plan on doing it by feature freeze, there's plenty of other things for me to work on
<jbicha> DasKreecH: try http://www.ubuntu.com/business/services/overview
<SpamapS> micahg: yeah I'll do it by then.
<DasKreecH> jbicha: and in the comments I can just specify that I would like Kubuntu as the distro to be supported?
<micahg> spamapS: thanks, I was just trying to go through the bugs tagged upgrade-software-version last night to see how many we can get in by feature freeze
<jbicha> DasKreecH: I don't work for Canonical, but sure put whatever you want in the contact form
<SpamapS> micahg: I'd have done it last week but the PHP suhosin mess and mysql not maintaining their public bug tracker has been eating up a lot of my time. :-/
<micahg> heh, not a problem as long as you're on it :)
<DasKreecH> jbicha: thanks
<YokoZar> Can an archive admin comment on the wine-gecko1.4 rejection?
<YokoZar> oh nevermind
<cargo23_> man proc says that /proc/pid/cmdline will be null separated, but on my 11.10 box it has no nulls.  What gives?
<tumbleweed> cargo23_: this isn't a support channel. Works for me: http://paste.ubuntu.com/830776/
#ubuntu-devel 2013-01-28
<ejat> hi , how to check if we succesfully upload .changes to ppa ? since i didnt get the notification say its failed or accepted ..
<TheLordOfTime> ejat, how long ago did you upload to the PPA?
<TheLordOfTime> or try to... :P
<ejat> about 1 hour ago
<TheLordOfTime> should've hit by now, unless your PGP key that you signed with wasn't recognized in LP (i've seen it just ignore such things before without messages)
<ejat> hmm .. thanks for the hint .. so  LP just ignore without giving any messages?
<TheLordOfTime> it may it may not
<TheLordOfTime> i've witnessed it ignore my uploads before, but its rare for me, since all my PGP keys autosync
<zequence> ejat: As said. double check the gpg key
<TheLordOfTime> random question for devs: are packages ever synced to main from debian experimental?
<TheLordOfTime> s/synced/merged, synced, copied, or otherwise/
<jtaylor> on request when it makes sense
<TheLordOfTime> Bluefoxicy, ping.
<TheLordOfTime> jtaylor, mind answering Bluefoxicy's question to me that was in +1 then?
<jtaylor> I don't use puppet so can't answer
<Bluefoxicy> pong
<TheLordOfTime> jtaylor, who would be able to know whether it makes sense?
<TheLordOfTime> (since puppet's in main i didn't want to give an answer in case i got it wrong)
<TheLordOfTime> (since i only really know universe's take on it: Only when requested)
<TheLordOfTime> (and when it makes sense)
<Bluefoxicy> jtaylor more of is it easier/better to get the package into Debian Experimental rather than trying to get Ubuntu to bypass Debian's out-of-date version with their own
<Bluefoxicy> god I'm making a mess of this every step of the way
<TheLordOfTime> Bluefoxicy, if i interpret jtaylor's words in my own wording:
<jtaylor> assuming its a stable release you can file a request and see what people say
<TheLordOfTime> i think that is an "It depends." thing.
<TheLordOfTime> jtaylor, it needs to be in exp first - experimental's OOD as well
<TheLordOfTime> (OOD = Out Of Date)
<Bluefoxicy> it depends on a lot.  Ruby, gems, several libraries
<Bluefoxicy> oh wait
<Bluefoxicy> wrong depends
 * TheLordOfTime rdeps puppet
<micahg> rdeps aren't bad, they should probably be checked with the new version, we generally prefer to merge/sync from experimental rather than introduce a new upstream version directly
<TheLordOfTime> Bluefoxicy, so to answer your question in +1 whether Debian should release 3.0.2 from their git to experimental, i'd say they should before you go looking into syncing it to ubuntu.
<Bluefoxicy> nod
<Bluefoxicy> micahg: are you a different micah?
<micahg> different than?
<Bluefoxicy> There was one asking me this exact question on debian-devel list
<micahg> that's not me (though I idle in the channel)
<Bluefoxicy> It seems now I am relaying a question from micah to micah :|
<TheLordOfTime> hehe
<Bluefoxicy> there needs to be a handbook for this
<TheLordOfTime> Q:"Does Ubuntu ever sync from Debian Experimental?" A:"It depends.  The request has to make sense, and it has to have a limited chance of completely nuking everything else"  <-- that perhaps?
<Bluefoxicy> That way I can read the handbook and not wind up annoying a bunch of people in the process of trying to get one piece of software (in like a dozen packages) updated before release freeze
<micahg> Bluefoxicy: BTW, once 3.0.x is in raring, you can request backports to quantal and precise, we were doing backports regularly before, but there were some issues in the later versions of the packaging which made it difficult to backport earlier than previse
<micahg> *precise
<Bluefoxicy> micahg:  nod.  Makes sense I guess.  I heard Ubuntu was going to a rolling distribution eventually.
<Bluefoxicy> I thought that it was going to HAVE a rolling distribution rather than BECOME a rolling distribution, though
<micahg> Bluefoxicy: not until after 14.04 at the earliest
<Bluefoxicy> Is that going to be essentially the culmination of backports?
<Bluefoxicy> backport ALL the things?
<micahg> no, but it'll make it easier to backport to the LTSs :)
<Bluefoxicy> are there any functional rolling distributions now (besides Gentoo)?
<Bluefoxicy> I remember this being a distinctly hard problem to solve
<micahg> Bluefoxicy: right, that's why there's time needed to improve the migration and QA processes on the devel release
<micahg> testing is essentially a rolling release when it's not frozen
<Bluefoxicy> I have heard many times that Debian Testing essentially works
<Bluefoxicy> I assume you're trying to squeeze that last bit of mermaid tears and unicorn blood into it some time in the next year
<ejat> TheLordOfTime and zequence : thanks ..
<TheLordOfTime> yep
<ejat> https://launchpadlibrarian.net/129726782/buildlog_ubuntu-precise-i386.dnscrypt-proxy_1.2.0-1ubuntu1_FAILEDTOBUILD.txt.gz
<ejat> can someone help me with that log
<micahg> ejat: missing a build dependency on one of the llvm-*-dev
<micahg> sorry, it just needs libltdl-dev
<infinity> Yes, that.
<infinity> ejat: http://packages.ubuntu.com/search?suite=precise&arch=any&mode=exactfilename&searchon=contents&keywords=ltdl.m4
<infinity> ejat: ^-- Handy for finding missing files.
<micahg> it was hiding before the list of the llvm packages in the apt-file output ;)
<infinity> And definitely libltdl-dev in this case, not llvm. :P
<ejat> ok .. trying to add the dependencies ..
<ejat> thanks guys
<infinity> Didn't libtool used to depend on libltdl-dev instead of just Recommending it?
<infinity> Maybe I'm misremembering.
<micahg> I think so...
<infinity> I find no mention of such a change in the changelog.  I'm probably just suffering from getting old.
<micahg> hrm, I guess not
<infinity> It's a recommendation as far back as hardy, at least.  Too lazy to look back further.
<micahg> was there a previous broken behaviour of installing recommends in build chroots?
<infinity> Not on my watch.
<infinity> There may have been for a few weeks in one release when the apt default changed, but I stopped it pretty quickly, IIRC.
<infinity> Actually, no, I don't think it was ever broken on buildds, come to think of it, cause back then, buildds still used the host apt.
<infinity> So, I fixed it in the chroots pre-emptively.
<ejat> http://paste.ubuntu.com/1578662/
<ejat> got this while trying with pbuilder ..
<ejat> LP builder freeze ? https://launchpad.net/~fenris/+archive/ppa/+build/4252002
<infinity> ejat: Sorted.
<ejat> infinity: y using pbuilder successfully build .. but when upload to LP failed
<infinity> ejat: It hasn't failed yet...
<ejat> previous it failed .. then i try to rebuild ..
<infinity> Well, I can't say why it failed previously, since there was no log, since it was retried.
<infinity> ejat: If you mean "why did I have to add a build-dep on libevent-dev", I assume your pbuilder chroot is dirty.
<infinity> ejat: You're also getting test failures in your testsuite that assumes you have internet access (the buildds don't).
<ejat> how to check / clean pbuilder ? rebuild ?
<infinity> I don't use pbuilder, so I couldn't say.
<infinity> But yes, building a new chroot would make sense.
<ejat> in pbuilder the testsuite OKAY
<infinity> ejat: Yes, because your computer has internet access.  Like I said, the buildds don't.
 * ejat in progress building new chroot .. 
<ejat> ouch ..
<scientes_> debootstrap is idiotic about qemu-user-static
<scientes_> you have to use --foreign and then restart the second stage
<ejat> so what should i do  ?
<ejat> to make testsuite work on buildds
<scientes_> ejat, just use cowbuilder and see what happens, qemu-user-static is only a cross compiling thing
<ejat> means i cant use my ppa to build ?
<ejat> :(
<micahg> ejat: you have to disable the tests requiring network access
<infinity> scientes_: How did qemu get involved in this?  He's not building for other arches...
<ejat> micahg: the code is not mine .. so i dont really know how to disable the testsuite ... anyone can guide me ?
<infinity> ejat: The regular buildds don't have internet access either, this isn't PPA-specific.
<ejat> infinity: ok tx for d info
<FourDollars> Is there any quick way to find out all bugs between precise-updates and precise-proposed?
<infinity> FourDollars: All bugs fixed, you mean?
<infinity> FourDollars: http://people.canonical.com/~ubuntu-archive/pending-sru.html may be a good start.
<FourDollars> infinity: It is very useful. Thanks a lot.
<kirkland> sladen: hmm, mapping it to the Ubuntu logo would not be the solution I'm looking for
<pitti> Good morning
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> FTR, I don't have much time today, I'm on a (virtual) sprint
<dholbach> good morning
<sladen> kirkland: can you describe again what you have in mind?  (example use-case)
<zyga> pitti: good mornign
<zyga> pitti: do you have a minute?
<pitti> hey zyga; what's up?
<zyga> pitti: hi, I'm designing/implementing a feature for checkbox rewrite and I could use your help with regards to current desktop tech
<zyga> pitti: I need to have a part of my app run as to be able to execute priviledged programs/scripts
<zyga> pitti: and I was looking for options here
<zyga> pitti: people point me at policykit and pkexec
<pitti> zyga: right; you can write a .policy file for an executable which a process can run through pkexec
<pitti> zyga: e. g. grep -r exec.path /usr/share/polkit-1/actions/
<zyga> pitti: so would that work for a specific command or could it be more generic? in practice checkbox would start the helper each time and keep it around to spawn additional commands
<zyga> oh, let me check that
<pitti> zyga: it should be specific; otherwise you introduce a (mostly unsafe) alternative to plain sudo
<zyga> is that a pure shell / command interface or is there something I can poke from python? we may need to run headless in some cases
<pitti> zyga: NB that any process can call that, not just checkbox; so if you have somethign which can execute arbitrary code you always need to ask for authentication
<zyga> hmm
<zyga> that's not good really, previously we did not (ask)
<pitti> zyga: authentication needs a DISPLAY or a stdout/stdin
<pitti> zyga: well, you can either do something very specific which is safe and cannot be parameterized by the user, or do something generic and ask
 * zyga needs to check how it worked before but I'm pretty sure it was a sudo of some sort
<pitti> (indepedent of the particular technology)
<zyga> yeah, you are right
<pitti> zyga: pkexec checks org.freedesktop.policykit.exec.path, shows the description and then asks or not depending on the allow_* values
<zyga> pitti: looking at current checkbox code I see sudo all over the place
<pitti> for example, pkexec /usr/lib/ubuntu-release-upgrader/do-partial-upgrade
<pitti> zyga: sudo, not gksu? how does that work on a desktop tehn?
<pitti> zyga: you can run graphical programs with <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
<pitti> that will pass on $DISPLAY to the executed program
<zyga> pitti: it's a hybrid that tries kdesudo, gksu and sudo
<zyga> pitti: it also greps for gnome-panel, nooo ;-)
<pitti> zyga: so, as we are trying to get rid of gksu, pkexec is certainly the preferred method these days
<zyga> yeah, I want to do it right so that we don't run as root 90% of the time
<pitti> xdiagnose and update-notifier still depend on it, though
<zyga> it's tricky as we pretty much run arbitrary (more less) shell as root often
<zyga> well, packaged but arbitrary
<zyga> is it possible to parametrize policykit based on stuff like user logged in at console?
<pitti> yes
<zyga> like not ask for authentication if I'm logged in interactively?
<pitti> zyga: that's in fact how it always works
<pitti>      <allow_any>no</allow_any>
<zyga> ok, I guess policy kit is the way
<pitti>       <allow_inactive>no</allow_inactive>
<pitti>       <allow_active>auth_admin</allow_active>
<zyga> should I aim for direct execution of pkexec or some bindings?
<pitti> zyga: execing pkexec is fine; I'm not aware of an API for it (but there might be)
<zyga> ok, then last question
<zyga> how does this fare with testing?
<pitti> zyga: but still, you need to ask for auth if you execute something which can run arbitrary commands
<zyga> in some cases we will want to run real stuff as root for automated testing
<zyga> pitti: not arbitrary, only stuff packaged with checkbox, we can make sure it's not looking into arbitrary places
<zyga> pitti: do you think it would be appropriate to have a bus-activated service that just sits there and can start/run checkbox "job" with polkit serving as guard to run a particular job; my motivation is that a typical checkbox "session" involves dozens of jobs, most of which want root, I'd like to spawn the notification at most once per started checkbox application
<pitti> zyga: why is that additional indirection any better than just running it through pkexec?
<pitti> zyga: usually you'd either have the spawned d-bus process be the service itself, or run it through pkexec, but why combine both?
<zyga> pitti: not sure, I guess you are right that I could just spawn the daemon once via pkexec
<zyga> pitti: er, scratch that
<zyga> pitti: so dbus daemon is okay, but then it would allow anyone to just run checkbox jobs
<pitti> depends what's more appropriate; i. e. you want the service to start when someone tries to talk to it, or when you know you are going to need it but it doesn't have a single D-BUS interface
<zyga> pitti: for instnace anyone could request 30 sleep/resume cycles
<pitti> right, that's the kind of backend service that needs authentication
<zyga> pitti: so hence dbus (to run as root and get started on deman) and polkit (to ask the user if they really agree)
<zyga> pitti: but I don't want to ask the user all the time, I guess this could be provided by having some session management inside the deamon itself, where some call to com.canonical.checkbox:OpenSession() would query polkit and provide some kind of object back that has actual RunJob() methods
<pitti> zyga: there's always "auth_admin_keep" if you want to retain the priv for the current session
<zyga> oh
<zyga> maybe that's easier than
<zyga> pitti: I'm sorry for throwing all the questions at you, I'm still reading polkit docs
<pitti> no worries :)
<pitti> zyga: but frankly, if most of your tests need root privs, why don't you just run the whole thing as root
<pitti> zyga: things like "suspend" don't need root, but I guess there are things which do
<zyga> pitti: I'm somewhat worried about the multitude environments in which polkit can be used (all the conbination of agents being or not being available, etc), I wonder if just using pkexec() is a simple workaround to make sure it will allways work (ssh to a headless server)
<zyga> pitti: well we want a UI too, I don't want to run the UI as root
<zyga> pitti: then the two want to talk
<pitti> zyga: you want the UI as user so that you can talk to the user's session d-bus and the like?
<pitti> otherwise you'll probably introduce ten times more attack vectors by having this rather open "execute 120 different things as root through PK" than having the whole thing run as root and benefit from the usual process isolation
<zyga> pitti: as a user to keep root away from too many things, the UI will be basically something you start from the desktop so I don't suppose that should run as root; I don't expect it will talk to many things thoug. A few of the tests want to see the user's environment but those don't need to run as root (so can use the current job starting mechaism)
<zyga> pitti: I could write a small tool, checkbox-run-job, that can be started with pkexec, that only runs commands from /usr/share/chcekbox/jobs
<zyga> pitti: then all the app logic runs as normal user
<zyga> pitti: and the helper would only load, validate and execute a job
<zyga> (and passthrough the IO)
<pitti> zyga: right, cf. "introduce more vectors than you close" :)
<zyga> pitti: 'cf?
<pitti> "refer to", "see above"
<zyga> hmm, but how would that be more attack vectors? it would need to run as root and pkexec could handle that, there would be a prompt
<zyga> pitti: is there a better way to do that?
<zyga> (and it's still less risky than plain sudo shell)
<pitti> zyga: if you really don't want to run the whole thing as root, then I don't know any
<pitti> polkit is the standard tech for that then
<zyga> pitti: when you say 'the whole thing', does that include the UI?
<pitti> zyga: yes
<zyga> pitti:  would that be safer?
<pitti> zyga: problem with auth-admin-keep is that from then on every other process in the session can run this process
<pitti> I think privileges are by-session, not by-process, but I'm not 100% sure of that
<zyga> pitti: then auth-admin-keep would not be what I want to use
<pitti> if auth-admin-keep is given out by process, it's fine
<zyga> pitti: ok, let me read on the docs a moment
<zyga> pitti: we don't seem to have pkttyagent in quantal?
<pitti> zyga: no, never heard of that
<pitti> zyga: pkexec just asks on /dev/console / stdout for authentication
<pitti> (unless something like polkit-gnome-authentication-agent-1 is available on the session bus)
<zyga> http://www.freedesktop.org/software/polkit/docs/latest/pkttyagent.1.html
<zyga> could be something new
<zyga> pitti: to some degree this is okay, I suspect that the checkbox rewrite will only be in raring (if we push the package) and we always use ppa for certification
 * zyga checks raring
<zyga> yeah, it's in raring
 * xnox is thinking to fork xchat
<ogra_> fork ? where to ?
<mitya57> which one? xchat or xchat-gnome?
<xnox> mitya57: xchat-gnome sucks as it is, so to fork xchat.
 * mitya57 +1's
<xnox> ogra_: mitya57: I'm just annoyed that I sometimes hit "Ctlr+L" and it wipes the screen, when I was looking at the browser window on my right screen and was hoping focus-to-follow-eye and put my cursor in the adress bar ;-)
<xnox> also new messaging indicator stuff, and other ZNC proxy fixes.
<ogra_> xnox, oh, i got the same prob with focus follow eye !
<mitya57> is upstream not accepting patches?
<ogra_> file a bug !
<ogra_> i'll confirm it
<xnox> mitya57: isn't upstream dead for years now?
<xnox> latest news from 28-Aug-2010
<mitya57> the latest commit was on 2012-07-27 according to LP
<xnox> I wonder if I should be running daily build.
 * mitya57 wonders if patches from https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/xchat/raring/files/head:/debian/patches/ were forwarded
<dholbach> I'm going to need a bit of help with one of the Developer Week sessions. We have a 30 minute slot on Thu 31st Jan 18:30 UTC where we need a speaker. We were thinking of having a "here's a small bug, and here's how to fix it" demo or a short session on how to find stuff to work on - but at this stage we'd be happy about whatever session we can put into the schedule. Can anyone please help out?
<dholbach> (https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable)
<xnox> dholbach: is how to fix a package to cross-build "small" enough?
<xnox> (most of those patches are trivial, but does require understanding of autoconf terms build,host,targer-arch and the ~approx. similar DEB_HOST_ARCH & DEB_BUILD_ARCH Debian terms)
<dholbach> xnox, if you want to give a session and enlighten the audience about that, that'd be brilliant :)
<xnox> I was thinking I could present the problem, point at how to setup the environment for cross-building and demonstrate a few fixes.
<xnox> Q&A and hopefully get cross-building fixes from community =)
<dholbach> xnox, should 30 minutes be enough?
<xnox> Yes. It's actually very easy.
<xnox> And ties in nicely with Mobile Story ;-)
<dholbach> fantastic - does the timing work for you too?
<xnox> yeah, should be fine.
 * dholbach hugs xnox
<dholbach> thanks a lot!
<dholbach> xnox, would you like to use IRC or a Hangout-On-Air?
<xnox> Hmm... IRC sounds nice, but with Hangout-On-Air I guess I can share my screen.
<xnox> But with Hangout on Air, I'll need to shave. Hmm... I'll tinker with both and check what I will come up with.
<dholbach> it depends what you want to do - if you want people to copy/paste easily, IRC might work better
<dholbach> haha
<dholbach> just let me know beforehand, so we can plan it properly
<xnox> I don't want people to copy & paste stuff interractively, cause e.g. cross-build chroot setup will take a while for some people due to download sizes.
<xnox> Ok.
 * Laney tries to imagine xnox with a beard
<xnox> Laney: if you stock me on facebook enough there are some very obscure pictures when I had a thick even beard. I bet ev would be jealous.
<ev> ha! Hardly. In the time since you last saw me, my beard has grown tenfold.
<Laney> BEARD WARS
<ev> I've started to prefix GNU/ on all of my nouns.
<xnox> =)))))))))))))))))))
<dholbach> haha
<vibhav> Laney: heh
<cjwatson> mlankhorst: I'm sort of considering releasing the enablement X stack to -updates - the only insufficiently-aged piece is mesa-lts-quantal, at 5 days
<cjwatson> But given that it isn't installed by default, I'm not sure that's all that important
<cjwatson> mlankhorst: Do you have any remaining concerns?
<cjwatson> Maybe I should clean up http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html first
<mlankhorst> erm uninstallable?
<cjwatson> Component mismatches, I think
<cjwatson> I'm just sorting things out so that I get a better report
<mlankhorst> it would seem so, I can install the first one from mesa list just fine, but I'll try them all
<cjwatson> (i.e. not your fault)
<cjwatson> Don't waste time on it for now
<mlankhorst> ok well moving to updates is fine with me then
<cjwatson> Hmm, none of this appears to reproduce in chdist
<mlankhorst> yeah I remember testing earlier revisions of xxv-omap too on panda, apart from compiz fail it worked
<mlankhorst> all the ones it reports have in common that they have libdrm or mesa as dependency
<davmor2> hey guys todays libc6 update triggered a debconf in the details terminal that wasn't obvious is this known already?
<cjwatson> mlankhorst: I think it's failing to consider -updates - fixing
<mlankhorst> ah
<cjwatson> mlankhorst: OK, report is better now
<cjwatson> mlankhorst: If I just promote *-lts-quantal, am I missing anything?
<mlankhorst> I don't think so. xorg and mesa unrenamed were promoted already right?
<cjwatson> Yep
<mlankhorst> that should be enough then :)
<cjwatson> Oh, excepting linux*-lts-quantal of course
<cjwatson> OK, promoting
<mlankhorst> you do want some form
<mlankhorst> of linux*lts-quantal
<mlankhorst> else xorg-lts-quantal will suggest a package that can't be installed
<cjwatson> We already have earlier versions
<cjwatson> It's just an ABI change in -proposed right now, insufficiently tested and aged
<mlankhorst> ah sure
<cjwatson> *splat*
<mlankhorst> \o/
<cjwatson> That should make sru-report rather a lot faster
<mlankhorst> could always put https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport in -proposed :P
<mlankhorst> did glibc get an update?
<cjwatson> I accepted one for {precise,quantal}-proposed this morning
<mlankhorst> ah right, the i386 version probably needs to update first. apt-get dist-upgrade wants to remove every 32-bits package I have
<cjwatson> -proposed has no guarantee of multiarch safety
<cjwatson> -updates does
<mlankhorst> indeed, would be nice if apt would choose to hold back packages in that case, instead of uninstalling an entire arch, though
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hadess> MacSlow, filed https://bugs.launchpad.net/notify-osd/+bug/1107919 if you or didrocks wants to handle it
<ubottu> Ubuntu bug 1107919 in Notify OSD "Should have builtin actions support" [Undecided,New]
<xnox> hadess: but there is existing fallback to standard gtk implementation.
<xnox> not sure which one it is.
<xnox> the problem with that fallback is that it doesn't use GApplication, therefore if one sends ten same action notifications you get 10 poop-ups, instead of the first one to "re-focus"ed
<xnox> so I am not sure how/where this has regressed.
<hadess> xnox, there's no implementation of the notification daemon specs in gtk+
<hadess> xnox, and notify-osd still claims not to support actions in the latest quantal version
 * xnox will have to look how some apps do end up showing GtkDialogs.
<hadess> xnox, because each one of them has that code implemented as fallback
<xnox> ideally we should patch them not to show actions at all. period. =) but hey, it's almost like swimming against upstream.
<hadess> xnox, which is impossible when you have a yes/no question coming from a core part of the desktop
<xnox> but the disk errors do create a GtkDialog with buttons to inspect or cancel.
<xnox> do they do it themself?
<mpt> xnox, I was just looking for an easy way to test it, but notify-send can't, and it seems like there's nothing in lp:notify-send/tests/ that does.
<xnox> mpt: yeah, since notify-osd doesn't support those =/ I was thinking to trow a python script together to test it.
<hadess> xnox, pretty certain they do
<hadess> xnox, or did, rather
<hadess> still does actually
<MacSlow> hadess, there is a fallback that opens a gtk-dialog...
<MacSlow> hadess, but that's actually a debug/devel feature disabled by default
<hadess> MacSlow, time to promote it!
<MacSlow> hadess, a distro wanting to ship that enabled is free to do so...
<hadess> MacSlow, the only distro shipping notify-osd as the default is ubuntu
<hadess> moving the burden to application developers to do something that can easily be implemented server side isn't too nice
<hadess> and it also means patching up parts of the stack that you use (from GNOME gnome-settings-daemon, vino, etc.) to implement the fallbacks
<mpt> ev, the bug in question is bug 1018117
<ubottu> bug 1018117 in Apport "No design for crashes handled long after they happened" [Medium,In progress] https://launchpad.net/bugs/1018117
<cjwatson> mlankhorst: It'd be good if somebody could verify bug 927424
<ubottu> bug 927424 in plymouth (Ubuntu Precise) "Please backport commit to enable building without irrelevant drm libs on some arches" [High,Fix committed] https://launchpad.net/bugs/927424
<mlankhorst> cjwatson: could try on panda in a bit
<infinity> mlankhorst: Checking the build log from the buildds should do the trick.
<mlankhorst> well it no longer links against libdrm-intel1
<infinity> Right, I just checked that.
<mlankhorst> was just hoping to get it to show splash screen too, but just realized it would probably not do that on omap anyway through drm
<infinity> Not a hope.  libdrm-omap depends on kernel features that aren't in precise.
<mlankhorst> oops, also had to onew libdrm from my own ppa
<mlankhorst> it overwrote the ti one
<mlankhorst> ah well good enough for now :)
<gkcn> On 12.10, after eglibc (2.15-0ubuntu20.1) update I cannot install libc6:i386 and I get unmet dep. libc6:i386 : Depends: tzdata:i386 error. Is it normal?
<mlankhorst> you have -proposed by any chance?
<mlankhorst> if so just wait a few hours, or disable -proposed :)
<gkcn> mlankhorst, yeah I use proposed. Ah so, libc6:i386 not compiled yet?
<gkcn> all my i386 packages are gone with libc6:i386 package : (
<cjwatson> It'll sort itself out soon enough
<cjwatson> Just don't let it remove things for now
<gkcn> cjwatson, eheh too late but thanks for the info
<cjwatson> That was daft of you :)
<cjwatson> Don't ever let apt remove packages without checking
<mlankhorst> considering it was a screen full of deps for wine removal, hard to not notice :-)
<cjwatson> It's built on i386 now, so it's probably just an out-of-date mirror
<gkcn> if I wouldn't use an out-of-date mirror, is there still a chance to update at some point that libc6 update is published but libc6:i386 is not?
<cjwatson> gkcn: Yes
<cjwatson> gkcn: -proposed is not guaranteed to be multiarch-safe; it's fine for users who don't use -proposed
<xnox> cjwatson: clearly we need -proposed-proposed or not publish until fully build.......
 * xnox hides
<cjwatson> ... or not
<gkcn> cjwatson, I see.
<cjwatson> (archive complex enough)
<gkcn> cjwatson, is it hard to make it multiarch-safe or is it a deliberate decision to make testers suffer :)
<xnox> gkcn: haha. possibly we should not ask people to test stuff until build & published.
<cjwatson> It is hard
<xnox> gkcn: it's the same as arch:all (part of i386 build) finishing before arch:any (!i386 builds) packages
<xnox> such that anything that depends on -common gets broken.
<cjwatson> And in any case I tend to think that apt should behave a bit better, rather than further complexifying the archive just for this
<cjwatson> In the case xnox mentions it generally just holds things back, rather than removing lots of stuff
<xnox> holding multi-arch world back would be nice as well.
<Phonequer> Hello. How would you package a new software? Should I create a bazar repo on sf.net, for example? Or just locally?
<stokachu> barry: i got the MP created for you
<barry> stokachu: cool.  i'm piloting tomorrow so i'll take a look then
<stokachu> sounds good, thanks man
<Phonequer> If a package compiles with boost1.49 & boost1.50, which one should I choose for dependency?
<micahg> Phonequer: I believe 1.49 is default still
<dobey> Phonequer: use the one that is installed and works.
<adam_g> how do i go about replacing an ubuntu package that was introduced directly into ubuntu, with the same package that has since been released into debian? anything special or will a standard debdiff work?
<micahg> adam_g: treat it like a merge
<adam_g> micahg: how so? i can 'bzr import-dsc' from debian and merge that, but future merges from debian via bzr branches woudln't have any common ancestor. or is that workflow not expected to work?
<micahg> adam_g: I'm not sure, I don't use the bzr workflow, can we not sync whoelsale?
<micahg> *wholesale
<tumbleweed> yeah, I'd debdiff the two and review the differences
<tumbleweed> the difference between this and a merge is that the deviation wasn't intentional. So one gets to decide how important each difference is...
<adam_g> micahg: yeah, i believe a direct sync would be fine here. i guess thats my real question: how to get rid of the original ubuntu package in favor of a direct sync ?
<tumbleweed> if they have the same name, you just sync
<Phonequer> dobey: I can block some other package that relies on 1.49 this way, can I ?
<dobey> Phonequer: i don't understand what you're asking
<hallyn> pitti: hi, do you have any comment on bug 1103022 ?
<ubottu> bug 1103022 in udev (Ubuntu) "70-udev-acl.rules needs to put g+rw on /dev/kvm" [High,Confirmed] https://launchpad.net/bugs/1103022
<Phonequer> dobey: It's about targeting boost 1.49/default or 1.50
<hallyn> i'd like to know whehter the workaround for that is going to need to stay in qemu for awhile or not
<dobey> Phonequer: aren't they parallel installable? isn't that why they have the version numbers in the names for the -dev packages?
<dobey> or is it just a transitional thing?
<infinity> hallyn: Hey, speaking of qemu.  The /etc/kvm/*if* scripts are dangling symlinks on my machine (or, were until I aimed them at /usr/bin/qemu-*)
<hallyn> infinity: interesting.  those should get fixed with the next merge from debian though
<infinity> hallyn: Kay, cool.
<hallyn> though that one scares me, and i should probably talk to you about it anyway: they're splitting up qemu-system into per-arch
<adam_g> tumbleweed: thanks
<hallyn> infinity: so qemu-system-x86 (for instance) will presumably start in universe
<Phonequer> dobey: you might be right. I listed my installed libboost* packages and I have 1.50 & 1.49. The problem was when I was installing libboost-filesystem1.49 -- it reported an impossible situation. However libboost-filesystem1.49.0 (i.e. +".0") works
<hallyn> (and i can only pray i get all the new breaks/repalces/provides right)
<hallyn> on the bright side, i do think this will be the last big reworking for awhile
<hallyn> infinity: anyway i'm working on that merge right now, but i'll jot down a note to check that when i'm done, thanks
<infinity> hallyn: Will there not still be a qemu-system and qemu-user metapackage that pulls in all the tiny ones for smooth upgrades?
<infinity> hallyn: If so, there should be no issues, it'll all sort itself.
<hallyn> infinity: yes, there is a qemu-system meta-package
<hallyn> cool
<hallyn> but my fear is lts->lts upgrades,
<infinity> hallyn: (and user and user-static, assuming those are being split too)
<dobey> Phonequer: is this for a properitary app, or what? you should just list the -dev package in Build-Depends, and use ${shlib:Depends} (or was it shlibs?) in the binary package Depends:, and the right thing will get used
<infinity> hallyn: Well, test precise->raring.  And whatever hacks you have in place now, don't drop until post-14.04.  Profit. :P
<hallyn> infinity: good point - user and user-static are actually not being split.  kind of weird.
<hallyn> i guess fewer ppl use those anyway, and if they do they want other arches, not their own.
<hallyn> whereas qemu-system, mostly they want their own arch and not the others
<Phonequer> dobey: Ok
<infinity> hallyn: Fair enough, I suppose.
<Phonequer> dobey: It also appears that boost can be installed in multiple versions -- except for -dev packages.. I guess I will go for libboost-dev, and other versionless names, to choose default version
<dobey> Phonequer: eh? i see libboost1.49-dev and libboost1.50-dev
<dobey> and for each of the other boost libs, as well there are versioned dev packages
<Phonequer> can't tell, if I do apt-get install liboost1.49-dev, it lists 1.50 packages in to "REMOVE" section and removes them
<sarnold> Phonequer: perhaps these threads can help? https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036001.html and https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036069.html
<sarnold> Phonequer: the second one spills into november too: https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036079.html
<Phonequer> yeah I added #ifdefs for boost 1.50 and the TIME_UTC_, I guess on my side this is handled
<hallyn> slangasek: debian isn't willing to have qemu depend on udev.  if it lets me drop delta from debian is it ok to switch from udevadm trigger back to debian's chown+chmod?
<robert_ancell> slangasek, did you reject unity-greeter 0.2.9? What was the reason?
<hallyn> infinity: feh, so those docs which conflicted in qemu and qemu-system, which you moved to qemu;  they put then in qemu-system;  am i gonna need a replaces for that?
<infinity> hallyn: Talk them into moving them the other way, where all the other docs are? :/
<infinity> hallyn: It makes no sense to ship two docs in one package, and the rest in another.
<infinity> hallyn: And theirs is still in experimental, so a bit of breakage without a replaces for them is fine. :P
<infinity> hallyn: But yeah, if you decide to just follow suit, you'll need a replaces.
<infinity> hallyn: You could probably drop it later in the cycle, though, assuming that most partial upgraders will get it out of their system in a month or two.
<hallyn> lemme read back over the irc logs where mjt explained it...
<hallyn> infinity: oh thta'ts right it was in email, not irc, where he says he'd rather move all docs out of the metapackage (qemu)(but hasn't done that)
<infinity> hallyn: Well, if he plans to just move the lot to, say, qemu-doc, then just do that. :P
<hallyn> i think he may ahve turned new-package-shy after all the per-arch qemu-system packages
<hallyn> but maybe ishould just go ahead and create it and passit back.  though then if he change his mind we're stuc, with uglier delta
<infinity> hallyn: Bonus points if the paths change from /usr/share/doc/qemu to /usr/share/doc/qemu-doc, then no replaces necessary for smooth upgrades.
<infinity> hallyn: But yeah, I'd pass him the patch before uploading it to Ubuntu, not after.  If he agrees to take it, then yay.
 * infinity decides he needs a nap.
<hallyn> \o
<slangasek> hallyn: well, I don't think that's a very good solution, but I won't fight it...
<slangasek> robert_ancell: I don't recall rejecting unity-greeter; if I did, I would have either dropped a comment in the bug, or pinged the uploader
<hallyn> slangasek: ok i'm keeping it at the very least while it's needed to clear the acl
<robert_ancell> slangasek, I'm only basing this on https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/972537/comments/18 because I can't find any reason elsewhere why it was rejected
<ubottu> Ubuntu bug 972537 in unity-greeter (Ubuntu Precise) "lightdm doesn't allow expired passwords" [High,Fix committed]
#ubuntu-devel 2013-01-29
<slangasek> robert_ancell: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/972537/comments/16 ?
<ubottu> Ubuntu bug 972537 in unity-greeter (Ubuntu Precise) "lightdm doesn't allow expired passwords" [High,Fix committed]
<Bluefoxicy> again, using a Windows VM to access a Google Nexus phone because Linux can't do it.  Well known problem though.
<Phonequer> Should I create one bazar repo for each package version? (I am following http://developer.ubuntu.com/packaging/html/packaging-new-software.html)
<robert_ancell> slangasek, oh duh. Cheers :)
<pitti> Good morning
<pitti> hallyn: TBH I don't understand the problem -- how do udev's dynamic ACLs get in the way of static group permissions?
<pitti> dobey: since yesterday, ubuntuone-syncd goes crazy, creates a million /tmp/tmp* files, and uses 100% CPU all the time
<pitti> dobey: there hasn't been a new ubuntuone-client upload in a while; do you know what changed, and how to debug this?
<hallyn> pitti: if you setfacl group::--- /dev/kvm; chmod g+rw /dev/kvm; then ls -l will show ???rw-??? for /dev/kvm, but group owner won't actually have rw.  so, the problem
<hallyn> is only when you isntall a new system and do 'apt-get install qemu-kvm'
<hallyn> bc udev won't remove that acl, so until you reboot group kvm can't use /dev/kvm
<hallyn> once you reboot, the acl doesn't get reinstalled, so it's ok after that
<hallyn> pitti: look at qemu-system.postinst and qemu-system.udev in raring's qemu for what we have to do to work around it
<pitti> hallyn: the postinst only triggers udev to reapply its rules AFAICS
<hallyn> pitti: yes, and without adding an explicit setfacl to those rules, it's not enough
<hallyn> pitti:  (which is why i pointed out the new qemu-system.udev;  it's kind of ugly and unfortunate, and requires a depends from qemu on acl which wasn't there before)
<pitti> hallyn: so you are saying that GROUP="kvm" doesn't actually work?
<pitti> or that MODE="0660" doesn't?
<hallyn> pitti: well, ACTUALLY GROUP=kvm sometimes doesnt' work but that's another story,
<hallyn> MODE=0660 does work, but doesn't remove the acl
<hallyn> so you end up with file perms allowing g+rw, but acl denying it
<pitti> yeah, it's not supposed to remove ACLs
<hallyn> well something has to
<pitti> but ACLs ought to be additive, not remove permissions
<hallyn> they're additive in that they are always checked on top of the file perms, not in the "add more permission" sense :)
<hallyn> pitti: more to the point, though, there is no reason for a group acl ever,
<hallyn> the user acl is used by consolekit to allow the loggedin user to access /dev/kvm, but group acl is worthless,
<pitti> hallyn: I thought the point of the ACLs was to allow the local active user to access it
<hallyn> so easiest just to remove it (as in my patch)
<hallyn> yes.  user acl.
<hallyn> the group acl though is worthless
<pitti> hallyn: so why does the udev rule add this group ACL in the first place?
<hallyn> dunno
<pitti> it seems odd to me to introduce the RUN:="/usr/bin/setfacl -m g::rw $env{DEVNAME}" in the distro, and then add a patch to revert it
<hallyn> oh, i'm mis-stating what my patch does - doesn't remove the acl, just sets it to group::rw-
<hallyn> <blink>
<hallyn> i introduced that to workaroudn this udev bug
<hallyn> and want to remove it as soon as the udev bug is fixed
<pitti> (also, I'm not sure that RUN:= actually does anything different than RUN=)
<hallyn> i'm not advocating keeping my changes to the qemu-system.udev in qemu source
<hallyn> i'm advocating simply adding GROUP=0660 to the 70-udev-acl.rules
<hallyn> so that /dev/kvm always gets group::rw- rather than group::--- acl
<pitti> so I'm still confused -- why can't we just drop that odd RUN from /lib/udev/rules.d/40-qemu-system.rules ?
<hallyn> then qemu can ship a simple udev rules file to chgrp /dev/kvm to group kvm
<pitti> that already sets the MODE correctly AFAICS
<hallyn> pitti: if we *just* drop that, then after install qemu-kvm (and until rebooting) group kvm can't access /dev/kvm
<hallyn> yes, but it's too late
<hallyn> that MODE only does chmod, not setfacl
<hallyn> bc udev is not smart enough to update the acl
<pitti> hallyn: oh, you mean this is solely to fix the upgrade from that current .rules which sets that odd group ACL?
<hallyn> pitti: (if i understand you right) yes
<pitti> hallyn: i. e. you are going to drop the RUN part in 40-qemu-system.rules, but you want it to work at instant?
<hallyn> right,
<pitti> hallyn: that kind of thing is usually a job for the postinst
<hallyn> i'll go back to the old 40-qemukvm.rules
<pitti> i. e. check the version you are upgrading from, and just call chmod
<hallyn> which iirc was jsut KERNEL=="kvm", GROUP="kvm", MODE="0660"
<pitti> yeah, and that looks nice and clean
<hallyn> pitti: well i'm not sure about calling chmod - that's what debian does so i may go back to it, but slangasek prefers we do udevadm trigger...  but either way the udev rule would like tobe KERNEL=="kvm", GROUP="kvm", MODE="0660" :)
<hallyn> pitti: so all i was really pinging you about was adding 'GROUP="0660"' for the kvm case to 70-udev-acl.rules
<pitti> hallyn: calling trigger is fine, and should always be done on upgrade
<hallyn> pitti: it's fine, but it's currently insufficient :)
<hallyn> inotify is sucking
<pitti> hallyn: and on upgrade to the next version, you just additionall call chmod
<hallyn> but again that (inotify) is a different problem
<hallyn> pitti: so do you have any objectio to adding 'GROUP="0660"' to 70-udev-acl.rules? :)
<pitti> yes
<pitti> as that potentially breaks custom rules, and also is the wrong place for one-time upgrade fixes
<hallyn> one-time?
<pitti> well, it only applies for upgrades from <= 1.3.0+dfsg-1~exp3ubuntu7 (assuming that ubuntu8 will fix it)
<hallyn> group=--- for /dev/kvm (when owned by root:root) has zero advantages
<hallyn> pitti: this has nothing to do with any version of qemu-kvm, really
<pitti> so its postinst shoudl call chmod on upgrades from those versions, and then be done with it
<hallyn> chmod is not enough
<hallyn> qemu did not wrongly label anything
<hallyn> every time you install an ubuntu system,
<hallyn> /dev/kvm gets set up (when someone logs in on consoel) with a group::--- acl,
<pitti> hallyn: I thought /lib/udev/rules.d/40-qemu-system.rules was wrong (it certainly looks odd), and you were going to fix that?
<hallyn> which never gets cleared by udev (bc udev doesn't support that)
<pitti> so apparently we still talk about completely different things then
<hallyn> pitti: if the udev bug gets fixed (which is what i'm pinging you about) then i'll simplify the 40-qemu-system.rules, yes.
<pitti> udev does not add any group ACLs
<pitti> that's only from that rule
<pitti> hallyn: I still don't understand what the udev bug is here?
<hallyn> well, udev sets the initial perms, and then consolekti adds ana cl for it
<hallyn> the udev bug is that it sets group perms to --- instead of rw-
<pitti> hallyn: ^ but that ACL has nothing to do with the one from 40-qemu-system.rules
<hallyn> no it has to do with 70-udev-acl.rules
<hallyn> i pointed you to 40-qemu-system.rules to show you how we have to work around the udev bug right now
<hallyn> (i originally did it as an explicit setfacl in qemu-system.postinst, but slangasek asked me to change that)
<hallyn> pitti: so one more time (since you've set me straight :), the order of events is:
<pitti> ok, so back to my originally question: what _is_ the udev bug?
<hallyn> 1. set up a new ubuntu system, it modprobes kvm_intel, /dev/kvm gets created,
<hallyn> 2. 70-udev-acl.rules sets /dev/kvm to root:root rwx------, and tags it with acl
<hallyn> 3. user logs in, consolekit adds a group::--- acl
<pitti> hang on, why root:root?
<pitti> that should be root:kvm, as per 40-qemu-system.rules
<hallyn> because group kvm doesn't yet exist,
<hallyn> qemu-kvm has not yet been installed
<pitti> ok
<hallyn> 4. admin logs in remotely, installs qemu-kvm, triggers udev,
<hallyn> 5. udev chowns /dev/kvm to root:kvm, and sets it to rwxrw----,
<pitti> (qemu-system, BTW)
<hallyn> right
<hallyn> 6. libvirt tries to start a vm as group kvm, but the group:--- acl refuses it
<pitti> I don't understand 3.
<pitti> udev-acl only applies ACL_USER acls, it doesn't touch group ACLs
<pitti> that's only from that weird 40-qemu-system.rules run rule
<hallyn> nope
<hallyn> i don't know why the acl gets added, but it has done it since at least q,
<hallyn> i only updated that 40-qemu-kvm.rules recently to work around it
<hallyn> it only does it when user logs in on console before qemu-kvm gets installed
<hallyn> but it's hit quite a few people over the past 6-12 months
<hallyn> so anyway, all that is to say that if the 70-udev-acl.rules shipped with udev would just set GROUP=0660, then the acl gets set as group::rw-, and all works out fine
<pitti> but nowhere in udev's source code a group ACL is set
<hallyn> no, but somewhere (in the dank depths of consolekit iiuc) an acl gets set to mirror the perms udev has set
<hallyn> (well, and no, acls DO get set in udev code...)
<pitti> that's /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck
<hallyn> (but i believe you that it isn't causing this acl)
 * hallyn goes to look
<pitti> hallyn: yes, udev-acl.ck sets user ACLs, but not group
<pitti> so we need to understand where that  group:--- ACL gets set in the first place, and eliminate that
<hallyn> that woudl be ideal
<pitti> hallyn: so you are saying that group ACL had been set even before 40-qemu-system.rules got that RUN rule?
<hallyn> yes
<hallyn> that acl is there if you just boot a new ubuntu system without qemu-system installed, and log in on cnosole
<hallyn> pitti: you're sure udev-acl.c can't set that?
<pitti> hallyn: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/udev/quantal/view/head:/extras/udev-acl/udev-acl.c is that code
<pitti> hallyn: I don't see where it should set group ACLs, and that thing isn't supposed to
<hallyn> yeah doesn't look like it, good
<pitti> hallyn: you can temporarily remove /lib/udev/rules.d/70-udev-acl.rules and /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck and check if that group ACL is still there, to be 100% sure
<pitti> weird bugs are always possible, of course
<hallyn> pitti: or perhaps this is a time for systemtap (if it actually works in raring atm)
<pitti> so IF udev-acl.ck sets a group ACL, then that's indeed a nasty bug
<hallyn> and what exaclty does /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck do?
<hallyn> (i can aim to test this tomorrow, but will need to find some space to test it :)
<hallyn> (i never did trust new-fangled consolekit :)
<pitti> hallyn: it adds an rw ACL for the user that is on the currently active console, and removes ACLs for the previously active user
<pitti> hallyn: for all devices which are tagged with UDEV_ACL
<hallyn> so if i *just* remove that that should be enough to test
<pitti> hallyn: the idea being to allow the current foreground session access to things like sound cards, cameras, or said /dev/kvm, but deny it to background sessions or remote users
<pitti> e. g. getfacl /dev/dri/card0
<pitti> user::rw-
<pitti> user:martin:rw-
<pitti> the second is what udev-acl.ck does; and if I switch user, or to VT1, I lose that again
<pitti> (that makes more sense on a sound card or digicam, of course)
<hallyn> pitti: you're on raring?
<pitti> yes
<hallyn> waht does getfacl /dev/console give you?
<hallyn> do you get group::--- ?
<hallyn> oh nm, that's not an acl in that instance
<pitti> yes, but that's from normal unix perms?
<pitti> right
<pitti> /dev/kvm has
<pitti> group::rw-
<pitti> which might be either from the static unix permissions or from 40-qemu-system.rules (g::rw is the same, isn't it?)
<hallyn> pitti: right.
<hallyn> pitti: well if you have a raring iso handy to do a vmware install you can just give it a shot - but i've got to go, will see about udev-acl.ck tomorrow.
<hallyn> thanks - good ngiht
<pitti> good night!
<sarnold> removing the acl won't revoke access, though; does consolekit kill -9 processes that have resources open?
<pitti> no, it doesn't; that would be quite rude :)
<sarnold> perhaps; but perhaps someone holds a webcam open or something..
<sarnold> I guess that's one more reason to put a piece of tape over webcams and microphone ports..
<pitti> heh
 * hallyn pokes his head in just to remind sarnold real quick that we've been asking for revoke(2) syscall since around 2002 :)
<sarnold> hallyn: .. if not even earlier :)
<alwin> I was on the look out for a C++ project in ubuntu so i can apply my programming skills
<alwin> any help
<jackyalcine> alwin: a lot of stuff in Ubuntu seems to be done in Python or Vala nowadays
<jackyalcine> with the bigger dependency on GNOME.
<jackyalcine> alwin: check out U1, most of it is written in C++ using the Qt framework
<alwin> Jack: what is U1
<infinity> Pretty much anything that depends on libqt will be C++ somewhere.
<infinity> Plus all the Mozilla products.
<infinity> LLVM.
<infinity> Lots of stuff.
<infinity> But if you're asking "what do we need help with?", the answer is "I dunno".  Find a package you feel passionately about and check its bugs.
<TheLordOfTime> alwin, u1 = ubuntu one.
<TheLordOfTime> but i agree with infinity, find a package you're passionate about and start on the bugs in the package
<infinity> (base)adconrad@cthulhu:~$ reverse-depends libstdc++6 | wc -l
<infinity> 4695
<TheLordOfTime> that's what happened to me, except i went down the bug triage direction, and kind of pseudo-adopted nginx :p
<infinity> Should be some choices in those 4695 packages. :)
<TheLordOfTime> lol....
<TheLordOfTime> 4695 packages... xD
<TheLordOfTime> infinity, is gcc one of those packages?  :p
<infinity> Of course.
<TheLordOfTime> figures :P
 * TheLordOfTime is curious what you need to build gcc... *checks builddeps*
<alwin> Rabbit hole it is then :)
<infinity> TheLordOfTime: To build just the C compiler, you need precious little.  The more languages you add, the more interesting it gets.
<TheLordOfTime> infinity, i meant gcc and the whole shebang that goes with the language :P
<TheLordOfTime> basically, "What is necessary to build all the GCC and related library packages" :P
<infinity> (The only real gotcha for the C portion of GCC is that gcc/glibc are very tightly intertwined, and the bootstrap between the two is mildly entertaining)
<jackyalcine> alwin: U1 = Ubuntu One
<jackyalcine> sorry about that
<jackyalcine> upgrading to 13.04 :)
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hi pitti
<pitti> hallyn: I responded to the bug again with a detailled analysis
<pitti> hallyn: ah, saw your response, thanks! Will check that out
<pitti> hallyn: so apparently that setfacl -m g::rw does something I don't understand
<pitti> hallyn: but "man setfacl" says that it will adjust the unix permissions as close as possible to the specified ACL, so apparently this is resetting the group to "root"
<pitti> infinity: time to build fresh precise langpacks
<pitti> infinity: I didn't hear from the RT, so I guess I'll build them on a porter box instead of macquarie's chroto?
<pitti> chroot
<infinity> pitti: Yeah.  I'm guessing your chroot didn't get updated yet?
<infinity> pitti: If you can fudge it with a porter box this time, that might be nice.
<pitti> nope, hardy
<infinity> Or we can ask a vanguard if they can get to the ticket today.
<infinity> If there was one.
<infinity> I guess London's still snoozing.
<pitti> I need to copy around the GPG key, launchpadlib token, etc, but no biggie
<infinity> pitti: Alright, then let's not block on the ticket, and just hope it gets done before the next raring or precise.3 langpacks.
<pitti> infinity: ok, it's running
<infinity> pitti: Shiny.
 * pitti hopes that the porter box can talk to launchpad
<infinity> pitti: If it can't, we'll escalate the chroot ticket with vigor.
<pitti> infinity: .launchpadlib/api.launchpad.net/cache/ is getting data, so I guess it's alright
<infinity> \o/
<hrw> I hate writing xorg.conf ;(
<xnox> hrw: it's ok, it hates you too. =(
 * xnox hopes to never edit the "safe-fallback" xorg.conf in the installer.
<hrw> xnox: I have a feeling that nevermind which gfx card I have foss driver fails
<hrw> xnox: radeon + two monitors (one landscape, second portrait) can be configured in first minutes of x11 session only. later one has to display garbage instead
<ogra_> haha
<ogra_> radeon with three monitors made me eventually buy an nvidia card
<tedg> Is there a way to get a test suite to clean up child processes, no matter what?
<tedg> Like if a test that spawns a process crashes, still kill the children.
<pitti> infinity: built; I downloaded, built and binary-debdiffed all packages for de and es, looking fine
<pitti> infinity: downloading current precise daily to give them a live test in a VM
<Laney> Quintasan: Yo. I understand you've been working on packaging maliit - is that right? Where are you up to with that? I'm interested in helping out. :-)
<sladen> tedg: Lennart would probably say "use systemd process containers!!!"
<tedg> sladen, Looking at cgroups, yes.
<xnox> tedg: or you can use PR_SET_CHILD_SUBREAPER to something which will not die (meta-testsuite running process), such that it will be the parent of all run away processes. Which you will be able to kill.
<xnox> (which is what user session upstart will do)
<notgary> Does anyone here know how I can have a regular event added to the Fridge Calendar (http://fridge.ubuntu.com/calendars/)?
<cjwatson> tedg: Or separate the child processes a bit less vigorously in the first place
<tedg> xnox, I'm a bit confused on how to do that... is it something I could have a shell script set?
<cjwatson> (For instance, it should be possible to at least keep them as a member of the same session, I'd have thought)
<cjwatson> The relevant chapter of Stevens APUE should be useful
<tedg> cjwatson, acquired the volume... turns out it's in the library here at Blue Fin :-)
<xnox> tedg: well it's a syscall, but somebody did write a package $ sudo apt-get install prctl, but that package seems to lack the subreaper support. So adding subreaper option to that package would be useful, as by default it can spawn shell or execute commands with those process options set.
<cjwatson> tedg: I only need to reach for it about once or twice a year nowadays, but when I do it's invaluable
<xnox> and then it all should die gracefully.
<cjwatson> It won't document Linux-specific things; but I'd be surprised if those were necessary here, as opposed to useful
<cjwatson> xnox: PR_SET_CHILD_SUBREAPER is no use here - it was introduced in Linux 3.3, and the buildds run 3.2
<cjwatson> (i.e. precise)
<cjwatson> So it won't be usable in test suites until at least 2014
<xnox> =( can be used in DEP-8 autopkgtests and / or UTAH based tests at least.
<cjwatson> xnox: tedg's situation is that a runaway test suite is killing LP builders, so we need a solution that works there
<xnox> ack.
<cjwatson> tedg: As a belt-and-braces solution, you could get a process list before and after running your test suite, and kill any extra dbus processes that appear
<cjwatson> tedg: It's obviously not perfect but would deal with the immediate problem easily enough
<tedg> cjwatson, Yeah, I was thinking using a killall -9 -y dbus-daemon
<cjwatson> Well, I wouldn't do that, because people are allowed to build packages in their ordinary sessions
<tedg> cjwatson, It might be easier... though very brute.
<cjwatson> (also, killall is evil, use pkill)
<ogra_> ++ for pkill
<tedg> Well in their sessions the dbus-daemon wouldn't be younger than the test suite.
<cjwatson> (sorry, gut reaction from somebody who used to have to use more SysV-ish systems ...)
<cjwatson> Sure, but just killing all dbus-daemon processes would kill their session dbus too
<cjwatson> Hence needing to take a process list
<cjwatson> Oh, -y - sorry, I misunderstood that option
<tedg> It doesn't seem pkill has the same option.
<cjwatson> I guess.  I think I'd prefer something more explicit, but as you wish :)
<infinity> tedg: Why not just specify a pidfile in the config...?
<infinity> Though, I'm also curious why this dbus-daemon, being run with --nofork is being reparented to init at all.
<cjwatson> If I could control enough of the software involved, the way I'd do this would probably be simply to make sure that dbus-daemon remains in the same process group
<infinity> Isn't that kind exactly the opposite of what one would expect?
<infinity> s/kind/kinda/
<cjwatson> Then you can kill it with kill(-pgrp)
<tedg> Yeah, I do think it's odd that it's hanging out.
<tedg> This is all in libdbustest -- patches more than welcome :-)
<tedg> So if we used the temp file stuff to make PID files, and then we killed all of them.
<cjwatson> An strace would probably be illuminating (although in this case strace will probably change behaviour - I just mean to see where it's disconnecting itself)
<infinity> I'd have to go digging into other packages, but I assume the pidfile way is the general way to go.
<infinity> And it doesn't need to be in randomly-named tmpfiles.  You control the namespace in your package build.
<tedg> infinity, The problem is that we spawn probably 20-30 dbus-daemons
<tedg> infinity, Some tests spawn several.
<tedg> I guess we could have a unique name for each test... that'd be a bit crazy to manage though.
<infinity> tedg: Err, are the tests in paralle or serial?
<infinity> tedg: If they're serial, there's no problem with just reusing the same pidfile all over again (or grabbing the pid from --print-pid)
<tedg> infinity, Uhm, that's a trick question.  They can be run in parallel locally, but the packaging runs them serially.
<tedg> infinity, The problem with using the same file is that I'd have to clean up in the shell script, that would have an unknown number of dbus-daemons started.
<tedg> After the debs are published can we just kill the builder :-)
<infinity> >:(
<infinity> tedg: tools/with-session-bus.sh from the telepathy-glib source may be enlightening.
<infinity> tedg: And yeah, they use --print-pid=6 and then exec 6> $me-$$.pid
<infinity> tedg: But the whole thing may be worth cargo-culting.  I doubt there are many testsuites that hit dbus harder than telepathy, and it never has a sad.
<tedg> infinity, Well, we're a bit more sophisticated in our dbus testing than they are :-)
<infinity> tedg: I disagree. :P
<tedg> infinity, But, yes, writing out the PIDs makes sense.
<infinity> tedg: And they intentionally fork, so they can get on with their scripts.  Which is probably the right thing to do, since --nofork doesn't do anything particularly useful.
<infinity> (Sure, it keeps it attached and in the foreground... Right up until the parent dies, and it double-forks to oblivion)
<pitti> meh, I can't get the current precise dailys to work in kvm
<pitti> ... nor in virtualbox -- oh for heaven's sake!
 * pitti grumpily downloads the i386 one instead and test on his netbook
<pitti> ev: just caught my eye -- we still ship udisks in raring by default due to usb-creator; as gnome disks has had the ability to write images onto devices for a while, and our images are bootable by themselves now, do you think we could drop that? or do you (or someone else) plan to port it to udisks2?
<infinity> tseliot: I see no point in that nvidia-common upload to precise-proposed.
<tseliot> infinity: It was just to reassure people who kept on blaming nvidia-common for a bug reported on errors.ubuntu.com
<infinity> tseliot: Sure, but if it's just running a test at build time, you could have done the same thing in a PPA. :P
<tseliot> infinity: oh, sure. Had it been for me I wouldn't have done anything as the code speaks clearly ;)
<infinity> tseliot: Right, well, given that it's only ever going to show up in a build log, rather than doing something different on users' machines, I'll just reject it.
<infinity> tseliot: Should you ever upload nvidia-common to fix some other bug, feel free to include the shinier test suite too.
<tseliot> infinity: I will have to backport the linux-headers installation code, so I'll include the test suite in that upload
<infinity> tseliot: Sure.  When you do, make the bug closure reference in the changelog actually have proper syntax next time. :P
<tseliot> infinity: oh, it was missing #
<tseliot> good point
<xnox> pitti: ev: I am working on porting to udisks2 now.
<xnox> pitti: ev: we can certainly use the "dd image from here to there" method. But doing that we will lose ability to create persistence file, won't we?!
<xnox> ogra_: there are a few bugs about not being able to do update-initramfs and/or update-grub when booting from persistent usb. Can we somehow use flash-kernel to update the kernel on the real partition that has the kernel and not the bits inside squashfs?
<pitti> xnox: ah, right
<MCR1> andyrock, if you are here, could you re-approve https://code.launchpad.net/~unity-team/unity/dash-blur-to-linear-sample/+merge/144104 ?
<andyrock> MCR1, sure
<MCR1> there was a conflict with trunk that is now fixed
<MCR1> thx
<andyrock> MCR1, i now nic just pinged me
<MCR1> hehe
<MCR1> ;)
<andyrock> thanks for testing it ;)
<MCR1> I just saw the diff ;)
<ev> xnox: cheers!
<xnox> ev: not that I enjoy the new UDisks2 API with org.desktop.DBus.ObjectManager a whole load of new interfaces.
<xnox> pitti: any good examples of GDBus server python API used in the wild?
<pitti> xnox: no, because that doesn't work :(
<hallyn> pitti: oh?  when i manually do 'setfacl -m g::rw' it doesn't change the group for me.  (but i'd believe it)
<pitti> xnox: mostly due to gnome bug 656325
<ubottu> Gnome bug 656325 in gdbus "Make GDBusInterfaceVTable binding friendly" [Normal,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=656325
<pitti> xnox: so you need to use python-dbus
<pitti> xnox: or python3-dbus
<ev> xnox: this was the one that davidz was trying to defend by claiming that it was never intended to be consumed by anything but gdu, right?
<pitti> that bug has been on my "assigned" list for far too long; the urgency has greatly been diminished by barry porting python-dbus to python3
<xnox> ev: yeah.... well new API is nice and gives a bucket loads more information, but it's very backwards. And one has to do bottom-up lookups =/ (filesystem->block-device->drive-type)
<pitti> xnox: but you know there's gir1.2-udisks-2.0 ?
<pitti> xnox: that's the API you ought to use, not the raw D-BUS one
<xnox> and do guess work - oh this object has: filesystem & block interface, and it's parent drive has property Optical then I'm guessing it's optical drive.
<pitti> xnox: well, you can still use raw D-BUS if you like
<xnox> pitti: ha. let me check that.
<pitti> xnox: http://cgit.freedesktop.org/udisks/tree/src/tests/integration-test uses it, so if you want to look at that for an example
<seb128> ogra_, ok, so my nothing-on-screen-after-nexus-distupgrade ... I can see the session when I change screen backlight level
<seb128> well, it does display when I change the value then goes back to blank
<xnox> pitti: thanks. looks very similar to DBus api, apart from no need to create connection first.
<pitti> xnox: yeah, libudisks and the gir are autogenerated from the D-BUS interface
<pitti> xnox: need to run out for a bit, bbl
<xnox> =/ why would anyone support multiple ways to access the same crapy API is beyond me
<pitti> xnox: try to use libudisks from C, and then do the same with plain gdbus, and you'll know :)
<pitti> the difference is a lot smaller in Python of course
<Quintasan> Laney: uh oh, I'm supposed to start packaging plugins
<Quintasan> frameworks are done with the exception of tests which fail because they need an X instance, xvfb fails ofc
<Laney> Quintasan: did you start from their ppa package?
<dobey> pitti: the issue is probably due to the new libc6 version, which broke some stuff. there hasn't been a new upload in a while, because lots of upstream changes broke lots of things, and i've been having to deal with them all across the u1 stack for the past week, including some infrastructure breakaage/downtime
<Quintasan> Laney: More or less, I just took dependencies from there. The rest was done from scratch
<Quintasan> Laney: Do you want to see frameworks pacakging?
<Laney> Quintasan: sure
<Laney> do you think it's ready to go?
<Quintasan> If missing tests are not a problem then yes
<Laney> here I got xvfb tests working but then it's failing later on when trying to link some test with "dummyimplugin"
<Quintasan> 0.94.0?
<Laney> yeah
<Quintasan> hmm
<Laney> well I say "got", I just xvfb-run make check ...
<Quintasan> oh
<Quintasan> That's how you did it.
<dholbach> coolbhavi, tumbleweed, mhall119, notgary: ready? :)
<coolbhavi> dholbach, yup :-)
<Quintasan> dholbach: I believe I won't be able to translate the packaging manual for this cycle
<dholbach> Quintasan, do you think you could reach out to the polish loco for some help with translations?
<Quintasan> uni has to eat more stuff than I expected it to.
<Quintasan> dholbach: I'll try, but I can't promise anything
<dholbach> Quintasan, dzieki!
<Quintasan> dholbach: nie ma za co :)
<Quintasan> Laney: I'll just testbuild it before I sent you not working stuff or something :P
<Laney> ok
<Quintasan> Laney: mikhas is at #kubuntu-devel so if you have any particular thing to ask about maliit you can ping him there, or I can ask him to get in here
<Laney> ah, I just had to make -C tests and it builds those libraries
<Laney> Quintasan: here would be good so I don't have to join another channel :P
<Quintasan> Laney: http://people.ubuntu.com/~quintasan/uploads/maliit-framework_0.94.0-0ubuntu1.debian.tar.gz
<Quintasan> Here is what I got
<dobey> pitti: looks like all our necessary fix branches have landed now in our trunk, and our nightlies PPA has built fine, so i'll be able to upload the new version today
<Laney> Quintasan: thanks; I'll combine it up with what I have
<Quintasan> Laney: I don't think I have symbols file there but they (i386, amd64, arm) are pending till I get my ARM box running.
<Quintasan> Laney: I'd appreciate it if you left the uploading magic to me since we have to get it along with Plasma Active 3
 * Quintasan looks at plugins
<Laney> Quintasan: Right, I don't know anything about that
<Laney> how does that impact uploading to Debian?
<Quintasan> Hmm.
<Quintasan> Oh wait
<Quintasan> Laney: You think you can get it to Debian?
<Laney> my key's a bit rusty but it probably still fits the lock ;-)
<Quintasan> That would be like...great.
<Laney> anyway I'll get back to you before doing that
<Quintasan> Sure.
<Quintasan> I'll be taking a look at plugins then
<Laney> neat
<tseliot> cyphermox: hi, I was told that you worked on the drivers manager code for software-properties-gtk. Can you have a look at my code, please? https://code.launchpad.net/~albertomilone/software-properties/linux-headers/+merge/145386
<mhall119> dholbach: not my turn yet
<dholbach> mhall119, not immediately, but today, right? :)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 1  starting in 13 minutes in #ubuntu-classroom
<Quintasan> Laney: I think framework still needs symbols file to be generated, got arm box or something to do that or want me to take care of that?
<mhall119> dholbach: today yes, not yesteray :)
<dholbach> :-)
 * mhall119 needs much more coffee before he'll be ready
<dholbach> you should have one or the other minute :)
<Laney> Quintasan: I can do that, yeah
<Quintasan> Splendid.
 * Quintasan doesn't have to set up his arm box
<Quintasan> Muahahaha
 * Quintasan hides
<Laney> armhf is actually the only arch on which I've run maliit :P
<Laney> (nexus 7)
<cyphermox> tseliot: why have the driver packages changed in that way? seems like a better way to depends rather than introduce code to do this is it's needed to build...
<cyphermox> but I'm not aware of all the details
<tseliot> cyphermox: we agreed with infinity that we cannot make sure that the correct headers flavour can be installed with package dependencies if users decide to install a kernel flavour other that the one ubiquity installed or if they simply removed the headers
<cyphermox> ah, makes sense
<Quintasan> Laney: Mmmkay, also, be sure to bash me if I made any graves mistakes, never did libraries from scratch
<cyphermox> tseliot: I would have thought the headers to be mostly always the same though ;)
<tseliot> cyphermox: yes, I wish ;)
<cyphermox> tseliot: ah, if you could just have not added one extra space in the PEP8 reformat it would have been so much easier to review :P
<tseliot> cyphermox: heh, sorry but my text editor couldn't live with 2-spaces indentation ;)
<infinity> cyphermox: Installers always install "linux-$flavour" which, as of recent SRUs, always depends on the headers for your flavour.
<infinity> cyphermox: Any attempts to manage this outside the installer or kernel metapackages will invariably fail, as other packages just plain have no clue what you have installed.
<infinity> cyphermox: (Though, the belt-and-bracers idea to also have jockey/drivers-common/whatever suggest installing headers if you've removed them is a good thing too)
<cyphermox> yeah
<infinity> tseliot: I'm too lazy to read the diff, but if it does what the changelog says, it's not ideal.
<tseliot> infinity: how so?
<infinity> tseliot: Installing the missing headers isn't the right answer, installing "linux-$flavor" is.  Otherwise, as soon as they upgrade, they'll have mismatched headers again.
<tseliot> infinity: are you saying that linux-headers-$flavour is not enough?
<ogra_> they wouldnt be upgraded with the kernel
<ogra_> thats what the metapackages are for
<infinity> tseliot: Oh, linux-headers-$flavour (without the ABI) is enough too, but we ideally want people to have the parent package anyway.
<cyphermox> Is there any case where the headers from get_kernel_headers() might not include all that is necessary to build a dkms package while another package does? Assuming a user has removed headers before, can they install a dkms package which will cause headers to be installed and the dkms package to still finish installing?
<tseliot> infinity: yes, it's just linux-headers-$flavour, no abi or version in it
<cyphermox> (I mean still not finish)
<infinity> tseliot: Did you test the regex against various differently-named kernels?
<Esokrates> I need to setup an lxc conatiner using Xephyr for graphical output of an app. Do you know a good guide to help me achieving this? Is there a possibilite to resize the forwarded window? (I think a patch was applied to Xephyr, but I do not know if it made into the package)
<tseliot> cyphermox: when you install a driver you get: 1) the driver and its dependencies hence 2) dkms and 3) the headers (Thanks to this change)
<infinity> tseliot: Like, ones with '-' or numbers in the flavour name?
<tseliot> infinity: such as?
<cyphermox> tseliot: yeah, I'm concerned that $dkmspackage doesn't depends on $headers anymore, and $headers-flavor doesn't contain what it needs to successfully build
<infinity> tseliot: omap4, nexu7, lowlatency-pae, or the ultimate test, powerpc64-smp
<tseliot> cyphermox: headers + dkms + driver should be enough
<cyphermox> ok
<infinity> cyphermox: Erm, headers-flavour depends on exactly what dkms used to (except correctly).
<cyphermox> infinity: alright
<tseliot> infinity: I can certainly add a test for those packages in my test suite
<cyphermox> as far as I'm concerned the code for softwareproperties looks fine (although I'm not super fond of reformatting), and if we agree that the actual package to install from detect.get_linux_headers() is right, then it's all fine
<infinity> tseliot: I didn't read the regex closely, but greediness can tend to bite one if you assume things like "linux-image-(.+)-(.+) will get you what you want from the end (it may end up just returning "pae" or "smp")
<tseliot> infinity: I remember testing -generic-pae but I haven't tested all of the possible flavours. This is what the testsuite is for and I'll make sure that these cases are covered
<tseliot> cyphermox: the other changes that I'm discussing with infinity are meant will land in ubuntu-drivers-common, without any need to touch software-properties-gtk any more
<hallyn> smb: plars: do you remember or have handy the bug # for qemu failures we had with cirrus vga, which were worked around by disabling cirrus driver at boot (or something like that)?
<hallyn> I'm asking so I can tie it to bug 1103385
<ubottu> bug 1103385 in qemu-kvm (Ubuntu) "Raring crashes on 12.04 LTS host with cirrus @800x600" [Medium,Confirmed] https://launchpad.net/bugs/1103385
<smb> hallyn, Maybe ... a sec
<smb> hallyn, one related was one I opened myself: bug  1039647 (its different though because the symptom was not "no fb" back then)...
<ubottu> bug 1039647 in unity (Ubuntu) "KVM/cirrus desktop fails to start" [High,Confirmed] https://launchpad.net/bugs/1039647
<hallyn> smb: thanks.  so that's yet another.
<hallyn> smb: i was just trying out unity on 1.3.0 qemu withi vmware vga yesterday, corruption is definately still there
<smb> hallyn, Yeah I think vmware could be. Cirrus was not crashing as badly as before but the underlying circular_area thingy was maybe fixed recently
<mino> hi guys. i have a package building related question posted here: http://askubuntu.com/questions/248994/howto-handle-packaging-and-development-in-one-git-repository . Any suggestions?
<plars> hallyn: I think the one I had was https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1054129
<ubottu> Ubuntu bug 1054129 in qemu-kvm (Ubuntu Quantal) "reboot with -vga cirrus can result in broken output" [Medium,Confirmed]
<smb> hallyn, actually the better one was bug 1038055
<ubottu> bug 1038055 in linux (Ubuntu) "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Fix released] https://launchpad.net/bugs/1038055
<xnox> smb: yeah for above bug, in quantal the relevant kernel driver bit was reverted. is it back in, in raring?
<smb> xnox, Yes and now causing no-framebuffer cases for a change :)
<notgary> dholbach, ready :)
<xnox> smb: awesome!
<xnox> wait, a second....!
<dholbach> notgary, great
<smb> hallyn, For reference, this one seemed to bite occasionally when using 3D under KVM (with cirrus): bug 1043513
<ubottu> bug 1043513 in xserver-xorg-video-cirrus (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Fix released] https://launchpad.net/bugs/1043513
<hallyn> smb: meaning you still occasionally get that one?
<hallyn> funny i've patched a similar one not that long ago
<hallyn> oh, that was in xserver-xorg-video-qxl
<smb> hallyn, Must admit I have not run desktop in KVM since then... On usual machine 3D in KVM sucks a lot of time
<hallyn> smb: odd, bc so long as i dont specify -vga, desktop works pretty well for me over vnc usually
<hallyn> smb: plars: thanks for the links
<hallyn> jdstrand: do you think the security review for MIR of spice will happen soon?  If not then I should go ahead and submit a new qemu-kvm-spice source so qemu-linaro can be dropped (to make infinity happy :)
<smb> hallyn, I had a feeling it was also related to the speed of your guest. Since mine sucked it was more common. The machine I use for Xen mostly also uses an emulated cirrus but is quicker and so sees less crashes
<hallyn> smb: so then i should be able to better reproduce it with a nested guest perhaps
<jdstrand> hallyn: I can probably get to it this week. not today though
<smb> (beside the fact that Xen uses a different pci subvendor ID and thus uses the xorg-cirrus driver, while kvm when the kernel drm driver works, uses  a different one (forgot the exact name gain)
<hallyn> jdstrand: that'd be awesome, thanks!
<mdeslaur> hrm, I use quantal in kvm with llvmpipe every day with -cirrus
<smb> mdeslaur, As I said it seemed much more likely when the host was overwhelmed. Like in my case when it took 3s to fade in windows...
<mdeslaur> oh, yeah, it's slow as heck...you have to be patient :)
<mdeslaur> I usually switch it to gnome-panel if I have something graphical to test
<mdeslaur> but maybe I'm lucky
<smb> Yeah, much better. :)
<smb> Actually classic gnome with no fuzz... :-P
<mdeslaur> it makes me miss unity though, switching back to gnome 2/gnome panel makes me realize how awful that desktop was :P
<mdeslaur> (how awful gnome 2 was)
<smb> I would not say awful. Different. Sure now it feels as bad going back as it felt going forward. Nothing works like your fingers/hands think. ;)
<dobey> eh
<dobey> i'm "using" unity now, but it actually is far inferior for me, than the setup i had with the old gnome 2 panel was. :-/
<mdeslaur> sorry, didn't mean to be insulting :P
<Quintasan> Laney: Man, that xvfb-run is like magic
<Laney> heh
<Quintasan> Laney: plugins should be done today or tomorrow.
<Laney> Quintasan: Nice :-). I've been tinkering with framework a bit.
<Laney> I'll upload it somewhere later today and you'll be able to see what I've changed
<Quintasan> Laney: Be sure to poke me serveral times or send me an email - quintasan@kubuntu.org
 * Quintasan is sometimes forgetful
<Laney> sure
<tseliot> infinity: so, apparently all linux flavours but "-omap4" seem to work. The main problem is that the package source is named linux-ti-omap4 whereas the package is e.g. linux-image-3.2.0-1419-omap4 (without the "ti" part)
<infinity> tseliot: You're using the source to map?  That's going to end in pain.
<infinity> tseliot: linux-ti-omap4 isn't the only one with that oddity.
<tseliot> infinity: only when the source is linux-$something. For example, in the case of linux-image-3.5.0-19-generic in precise (a backported kernel from quantal) the source is linux-lts-quantal, therefore the correct headers are linux-headers-generic-lts-quantal, instead of linux-headers-generic
<infinity> tseliot: Oh, yeah, the lts-* stuff is special.
<infinity> tseliot: And probably makes more sense to special-case lts-* than to try to divine generic rules from it.
<infinity> tseliot: (linux-ppc in raring would trip similar issues, no?)
<tseliot> infinity: linux-image-3.5.0-19-powerpc64-smp works fine
<infinity> tseliot: That's quantal, where it comes from the linux source package. In raring, it doesn't.
<tseliot> infinity: oh, let me check
<infinity> tseliot: Anyhow, you're probably better off doing the mapping based on binary packages, unless source contains -lts-
<infinity> tseliot: Or something like that.
<tseliot> infinity: yes, if -lts is the only special case
<tseliot> infinity: thanks for the heads up, I'll change the logic a bit and make sure to add more tests
<infinity> tseliot: Cool, thanks.
<pitti> dobey: thanks for the heads-up!
<hallyn> stgraber: I'm looking to make qemu-user-static not install cross-32/64-bit handlers (work item in https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-binfmtns).  How would you recommend detecting that?
<hallyn> stgraber: should i just do a straight 'uname -m' comparison with blacklist?
<hallyn> or is there a way to just get the word size?
<hallyn> (cleanly)
<ogra_> hallyn, !
<hallyn> cjwatson: sorry to distract you, but i'm tryin gto remember our conversation at UDS about your machien... would checking 'uname -m' and refusing to install 64-bit handlers on i386 suffice?  or is that not enoguhf or you?
<hallyn> ogra_: hi
<ogra_> i think i have a never closed linux bug open for that
<infinity> hallyn: The wordsize of... The kernel, or userspace?
<hallyn> infinity: that's what i'm asking cjwatson about right now :)
<infinity> hallyn: Checking his uname would be fine.
<hallyn> i think userspace
<hallyn> because you can run a 32-bit userspace on 64-bit kernel, and then you want to stick with 32-bit binfmt handler, right?
<infinity> hallyn: I assume the bug was that on i386, it was installing an emulation handler for x86_64?
<hallyn> infinity: also installing 386 handler on 64-bit,
<hallyn> as after that you can't run 64-bit binaries any more
<infinity> That can't be true, or I wouldn't be able to run anything.
<mlankhorst> hallyn: erm wouldn't that fail on cross compile?
<ogra_> hallyn, bug 427863
<ubottu> bug 427863 in linux (Ubuntu) "binfmt allows breaking out of chroots due to not respecting namespaces" [Medium,Invalid] https://launchpad.net/bugs/427863
<rtg> cjwatson, upower is still harshing my buzz. see bug #1109076
<ubottu> Error: Launchpad bug 1109076 could not be found
<hallyn> ogra_: that looks like it'll be solved by the blueprint i linked above :)
<ogra_> hallyn, though my prob was rather stacked binfmt stuff there, but its also namespace related
<ogra_> yeah
<ogra_> great to see someone finally cares :)
<hallyn> ogra_: yeah, though i'm afraid it's going ot be postponed ntil 13.10
<ogra_> well, i opened the bug in 2009
 * ogra_ is patient 
<hallyn> ogra_: :)
<hallyn> hm, i don't seem able to install qemu-user-static:i386
<ogra_> i wonder if thats actuallyl being built
<Laney> rtg: I just saw a segfault immediately after dist-upgrading it; is that what you got too?
 * ogra_ wouldnt mind trying that on an arm ... running wine uder it to play a windows game or so *g*
<Laney> (can't see that bug)
<rtg> Laney, yeah, it happens pretty early.
<Laney> upowerd crashed with SIGSEGV in __GI___libc_free()
<rtg> Laney, my bug report is likely still waiting on the stack sanitizer
<rtg> but that looks like what I saw as well
<Laney> yep
<apw> bug #1109076
<ubottu> Error: Launchpad bug 1109076 could not be found
<GunnarHj> cjwatson: ping?
<Laney> here comes the pingfest ;-)
<GunnarHj> you bet :)
<jsalisbury> rtg, apw, I don't think 1109076 is a valid bug number
<Laney> it's just private while it waits to be retraced
<pitti> cjwatson: hm, new upower is causing crashes (like bug 1108995) and retracing fails because apache on allspice is AWOL (I'll go ask IS)
<ubottu> Error: Launchpad bug 1108995 could not be found
<pitti> not the best day
<seb128> pitti, some others pinged him earlier, he seems to not be around ... I guess one of the leak fixes turned out to be a too-much-free ... do you have an idea which one or should we just revert meanwhile?
<pitti> they both looked good, let me look again
<pitti> seb128: no firm gut feeling I'm afraid
<seb128> pitti, laney is getting the issue if you need debug infos
<Laney> you'll probably get it too if you dist-upgrade to the new upower
<pitti> just finished upgrading
<seb128> upgrade runninghere...
<pitti> I have tons of oneconf crashes, but no upower
<seb128> Laney, it might depend of the type of device, if you are on battery/ac, etc
<pitti> ah, I don't have a battery
<Laney> let me try it on my other machine
<pitti> if so, then it's the one in up_device_supply_get_design_voltage()/    up_history_finalize()
<seb128> pitti, I'm building a dbg version of upower
<cjwatson> hallyn: My system is amd64 kernel, i386 userspace, some amd64 chroots/VMs; so IMO qemu-* should avoid installing an x86_64 emulation binfmt handler if uname -m says x86_64
<cjwatson> hallyn: And this has broken for me quite recently
<Laney> seb128: pitti: Yeah must be something about batteries; saw it on the nexus
<Laney> but not on the desktop PC
<cjwatson> rtg: I can't see thatbug
<pitti> apw: seems we have some bigger prroblems with ddebs as well, cannot fetch from 7 buildds (sorting out with IS ATM)
<cjwatson> Oh, never mind, now I cn
<cjwatson> I'll sort out upower in a bit, finishing up a call
<rtg> cjwatson, np
<pitti> cjwatson: I can upload a revert if you want, to take out the pressure?
<cjwatson> pitti: please do - I haven't seen a valid stacktrace yet
<hallyn> cjwatson: when i create i386 chroot/container on amd64, install qemu-user-static doesn't break it...  did in precise, does not in raring.  but your exact use case i haven't tried.  but binfmt was acting like it has some new safeguards
<apw> cjwatson, if you run the daemon on the command line it blows up in your face
<cjwatson> apw: Didn't for me, but that was armhf.  But OK, I'll try that
<seb128> cjwatson, pitti: http://paste.ubuntu.com/1586544/
<pitti> cjwatson: yeah, that's the part of the problem I'm dealing with ATM
<cjwatson> hallyn: That isn't the same thing, certainly
<pitti> seb128: merci, that helps
<apw> *** Error in `/usr/lib/upower/upowerd': free(): invalid pointer: 0x098cfdd8 ***
<apw> cjwatson, ^
<cjwatson> The top level userspace on my system is i386, not amd64
<pitti> apw: see seb128's stack trace, got it
<cjwatson> GunnarHj: upower, or something else?
<apw> pitti, ahh right
<seb128> pitti, cjwatson: http://paste.ubuntu.com/1586548/
<seb128> valgrind log
<GunnarHj> cjwatson: Hi Colin! It's something else, not urgent, asked my question on bug 960314 instead.
<ubottu> bug 960314 in ubiquity (Ubuntu) "Unnecessary languages listed but not installed after install" [Undecided,New] https://launchpad.net/bugs/960314
<hallyn> cjwatson: well, i can try a amd64 chroot under i386 container on amd64...  maybe that comes close
<cjwatson> GunnarHj: can't deal with that this week
<GunnarHj> cjwatson: That's fine.
<cjwatson> hallyn: probably not
<hallyn> cjwatson: why not?  since there is no namespace for binfmt, i'd expec tsomething in that stack to get corrupted...
<cjwatson> pitti,seb128: IDGI, how can "energy = sysfs_get_double (native_path, "energy_avg") / 1000000.0;" be calling free on that value?
<cjwatson> hallyn: oh, container, I misread
<cjwatson> Maybe
<cjwatson> hallyn: But why don't you just tell me what you want me to try here ...
<pitti> cjwatson: it's the new free() in up_device_supply_get_design_voltage apparenlty, that's the bit I'm reverting
<hallyn> cjwatson: welli'm wondering whether new qemu-user-static (now coming from debian's qemu) or new binfmt has alredy worked around the problem you were having,
<hallyn> i.e. juts do what normally breaks (installing qemu-user-static in amd64 chroot?)
<cjwatson> GunnarHj: TBH, I don't think your mail was really very related to what I'm trying to fix, and what I am determined needs to be fixed
<hallyn> cjwatson: how did you set up your system?  install i386 system then compile your own adm64 kernel and install it?
<pitti> apw, seb128: care to try http://people.canonical.com/~pitti/tmp/upower_0.9.19-1ubuntu2_amd64.deb ?
<cjwatson> hallyn: I installed i386 eons ago, then a little while back I installed the Ubuntu amd64 kernel using multiarch
<seb128> pitti, I'm on i386; can run "make" on my current build tree if you tell me what to change though
<cjwatson> Life is far too short to be compiling my own kernels
<apw> pitti, will do
<hallyn> haha - multiarch for kernel, too cool
<pitti> seb128: http://paste.ubuntu.com/1586563/
<seb128> pitti, that fixes it
<pitti> seb128: merci, uploaded
<GunnarHj> cjwatson: Hmm.. Are possibly mixing up the paper size thing and the redundant Chinese locales?
<seb128> pitti, danke
 * pitti goes to play some whack-a-rat with the dupes
<xnox> pitti: bug #960314 links to bug #863378 which has a branch merge proposal which is against langpack-locales not special casing for zh-XXXX lang packs.
<ubottu> bug 960314 in ubiquity (Ubuntu) "Unnecessary languages listed but not installed after install" [Undecided,New] https://launchpad.net/bugs/960314
<ubottu> bug 863378 in langpack-locales (Ubuntu) "Locales not removed when removing Chinese translations" [Low,In progress] https://launchpad.net/bugs/863378
<xnox> pitti: maybe you can review it?
<pitti> xnox: sorry, not right now; two "OMGnow" things ongoing right now, and I actually wanted to call it a day over an hour ago ..
<pitti> xnox: but I can review it in general, yes; can you please subscribe me so that I get a mail?
<apw> pitti, you got a 32bit to test as well
<pitti> apw: seb128 should have a deb now
<seb128> apw, pitti: let me scp that
<pitti> lool: oh, that's also your upower crash, BTW (very very likely)
<pitti> although, maybe not; I'll have a look tomorrow
<xnox> pitti: ack.
<seb128> apw, http://people.canonical.com/~seb128/upower_0.9.19-1ubuntu2_i386.deb
<apw> wget *** Error in `/usr/lib/upower/upowerd': free(): invalid pointer: 0x098cfdd8 ***
<apw> IGNORE that
<seb128> ;-)
<pitti> amd64 build is somewhat blocked (where did all our buildds go}), rest building
<pitti> oh, moved to i386 for precise langpacks, I guess
<Laney> they probably got switched to i386 to ... that
<apw> pitti, seb128's 32bit works for me
<cjwatson> GunnarHj: I only linked the Chinese one for reference - I don't think this is directly related
<GunnarHj> cjwatson: Ok, thought it was worth asking. ;-) Thanks.
<GunnarHj> pitti: You are already asked to review the bug 863378 MP, so you probably have a mail. Not urgent.
<ubottu> bug 863378 in langpack-locales (Ubuntu) "Locales not removed when removing Chinese translations" [Low,In progress] https://launchpad.net/bugs/863378
<pitti> apw, seb128, cjwatson: ok, built everywhere (armhf is at dh_builddeb), so should be fine; leaving now, please call my mobile if you need more help
<apw> pitti, thanks
<seb128> pitti, thanks, have a good evening!
<ian__605> Can anyone give me some advice for debugging an app? A user gets inconsistent crashes with a SIGSEGV in ccsGSettingsValueChanged(). I can't reproduce it but it seems to happen every 7-8 program starts for him. Starting with gdb never reproduces it, but an apport bug report gives some info. seems that SegvReason is reading unknown VMA
<ian__605> From the top of the stacktrace: #0  0x00007fbb283f74b3 in ccsGSettingsValueChanged () from /usr/lib/libcompizconfig_gsettings_backend.so
<seb128> ian__605, try asking on #ubuntu-unity
<seb128> seems like a bug in the unity-gsettings backend
<seb128> compiz-gsettings rather
<lool> pitti: Yeah, sounds like it; I had installed updates at around the same time
<lool> pitti: thanks!
<ian__605> yeah... I will ask on #ubuntu-unity too, but is should I file a bug report with compiz-gnome since that's the package libcompizconfig_gsettings_backend.so comes from?
<seb128> ian__605, you should get an apport prompt leading you to report a bug when that happens...
<ian__605> The user gets one sometimes, but since it originated with my app, it goes to me (or would if it wasn't a ppa)
<seb128> well; it's up to you to get the infos and report the bug then I guess
<seb128> for what we know it could be a bug in your ppa and not in Ubuntu
<cjwatson> pitti: Oh, whoops, I see the bug
<ian__605> seb128, Right.. so how would I figure that out?
<seb128> ian__605, dunno, it's your ppa, you should know what you have in there and if it's likely to create such issues?
<cjwatson> pitti: For some reason the patch I uploaded didn't match the one I attached upstream
<seb128> ian__605, getting a stacktrace would be useful in any case
<cjwatson> (missing = NULL)
<ian__605> seb128, I've got the stacktrace here: https://launchpadlibrarian.net/129813827/_opt_extras.ubuntu.com_drawers_bin_drawers.1000.crash
<infinity> seb128 / tedg: More hung builds on the buildds, I thought you were going to keep that disabled until it was fixed. :/
<seb128> tedg, ^ can you get those builds disabled until the issue is resolved?
<ian__605> My app uses gsettings to store some configuration. It also uses python-compizconfig to get some info on settings
<tedg> Yeah, I'll try to figure that out.  Almost done with a fix.
<ian__605> seb128, app sets up ok, but once the Gtk.main() is called it crashes. Again, it's just once-in-a-while and I can't reproduce on my system
<seb128> ian__605, sorry, I'm not familiar with that codebase, best is to get a debug stacktrace and file a bug and see what the compiz guys say
<cjwatson> pitti,seb128: uploaded a corrected fix
<seb128> cjwatson, great, thanks ... I will install the deb once it's on launchpad to confirm if that version is working for me
<cjwatson> hallyn: Yeah, looks like it's better at the moment because qemu-user-static_i386 doesn't ship /usr/share/binfmts/qemu-x86_64
<cjwatson> hallyn: Of course, this means that for people running an i386 kernel, they don't get automatic x86_64 emulation, so it's just moved the bug around :-)
<cjwatson> (Well, assuming that's possible - maybe it isn't)
<infinity> It's possible.
<infinity> But painfully crap.
<hallyn> cjwatson: ok - i wonder if we'll be seeing a bug about restoring that emulation
<hallyn> cjwatson: thanks for checking!
<hallyn> cjwatson: so do you prefer that we postpone binfmt namespace discussions  until next cycle?
<cjwatson> hallyn: It's no particular rush for me
<cjwatson> And bazillion other things to do as usual, so as you like :)
<hallyn> cjwatson: yeah at this point it seems liek finishing up started items is more important
<hallyn> cjwatson: i'll re-raise it next cycle, thanks :)
<hallyn> smb: ^
<smb> hallyn, ok, thanks
<cjwatson> Certainly from my point of view it's been a problem since <=2000, so, you know, what're another couple of years
<hallyn> cjwatson: hopefully only a few more months! :)
<smb> hallyn, In my optimistic ways I hope to have at least done a bit more preparation (research) work until for the next discussion...
<hallyn> smb: I still think it'll have to start with my coaxing cjwatson to write the detailed namespace motivation (first WI int he blueprint)
<hallyn> oh well - lunch - bbl
<smb> late enough for me - bbml :)
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<rtg> cjwatson, upower_0.9.19-1ubuntu2 appears to have fixed my problem
<cjwatson> rtg: ubuntu3 should too
<cjwatson> hopefully
<cjwatson> my own stupid fault, I evidently misapplied the patch by hand rather than applying the one I'd sent upstream
<rtg> cjwatson, , thats the I really meant to build. drat.
<cjwatson> because it was short enough that I couldn't possibly get it wrong, right?
<dobey> slangasek and stokachu: would you care to check out my patch on https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 ? xnox already looked at it, but said he'd prefer one of you to look at it as well, as you've had issues with doing this in gnome-keyring before
<ubottu> Ubuntu bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress]
<seb128> dobey, sorry about that one, you pinged me about it but I also decided it would be better if some of the multiarch gurus had a look ;-)
<stokachu> cjwatson: if a precompiled driver exist on an external source as a udeb that driver should be copied over to the existing target or does the installer rebuild the initrd?
<cjwatson> stokachu: nothing is copied out of the installer environment to the target.  the installer rebuilds the initrd; any driver that's to be on the target system must be available as a deb
<stokachu> cjwatson: so providing a udeb to the installer should make that driver available after installation and a reboot correct?
<infinity> stokachu: No, that's the exact opposite of what he said. :)
<xnox> udeb makes that driver available during installation, you need a deb on top to make it available in the target / post-install.
<infinity> stokachu: udebs are only available to the installer itself.
<stokachu> ah i see
<xnox> stokachu: e.g. if that driver is need both during install & in the final system, one needs both .deb & .udeb.
<stokachu> ah ok that makes sense now
<xnox> there should be some examples in the archive of how to package that (e.g. duplicate the driver into two package)
<stokachu> yea ive been looking for some documentation on that
<xnox> stokachu: also note the ModAliases feature that packages can declare for ubuntu-drivers-common to auto-install relevant .deb for you.
<xnox> (e.g. any nvidia package)
<xnox> .udeb drivers are typically ethernet/wifi cards
<infinity> And filesystem and storage drivers.
<infinity> And other stuff.
<stokachu> hah ok
<infinity> stokachu: But, yeah, if it's not vital to perform the install, you don't want a udeb at all.
<infinity> stokachu: You want a deb, ideally a dkms package.
<stokachu> this is a storage driver to detect during install and after
<stokachu> it detects during installation but im missing the second part for the target system
<stokachu> if i've emailed an uploader about merging a new version of their package how long should i wait for a response?
<stokachu> the latest aptitude won't run its google mock tests without a newer google-mock package
<infinity> stokachu: We seem to be up to date with Debian already.
<infinity> stokachu: Unless their packaging had bugfixes you need.
<stokachu> there seems to be some differences in our package compared to debian's
<stokachu> i ran a test build of aptitude in sid against their google-mock and it ran the tests successfully
<stokachu> with raring it fails to find gtest
<stokachu> im still going through the changes to see what may be inconsistent
<stokachu> looks like we allow make install to proceed where debian does not
<stokachu> im guessing other software is still dependent on the previous way google-mock worked before the recommendation was to include during each application build
<xnox> stokachu: well in ubuntu, it looks to me like we have an aptitude patch that turns off building/running google-mock tests
<stokachu> xnox: yea in 0.6.8.1 but i was attempting to merge in 0.6.8.2 and re-enable google-mock since it landed in main
<xnox> I see.
<bryce> slangasek, btw on SRU #1078290 the driver got moved to -updates but there's a jockey fix that goes along with that update, which has to be rolled out as well; otherwise the driver won't install properly
<bryce> slangasek, I've tested jockey 0.9.7-0ubuntu7.7 along with the fglrx-experimental-9 update and verified that combination installs and boots fine
<slangasek> bryce: right, but the jockey in -proposed is currently awaiting verification of a different bug
<slangasek> oh, /was/
<slangasek> I guess we can move that too then
<infinity> It doesn't hurt anything to have the driver preceed jockey, does it?
<bryce> slangasek, Sarvatt verified it
<slangasek> infinity: indeed not
<bryce> well
<bryce> the kernel module will display in jockey prior to the jockey update
<bryce> if the user attempts to install that, then they get half a driver, and thus a busted system
<bryce> so I generally prefer to see the jockey changes go in first, then the driver update
<slangasek> dobey: I haven't built the package, but the source diff looks sane to (gnome-keyring)
<slangasek> bryce: ah - ok, then I'll get that published
<xnox> stokachu: right so aptitude's configure.ac is at fault here. It says if I can link mock, I don't need to build neither mock nor gtest. Which is not true in ubuntu currently as one has to still build gtest. It would be better if aptitude configure.ac checked mock & gtest separately whether to build none, one or both.
<bryce> in the jockey dialog, this situation shows up when you see the driver listed as "Experimental blah blah" rather than "AMD/ATI blah blah (**experimental**)...", which I notice is what is happening presently if you have only -updates
<xnox> stokachu: I have a crude fix to override this behaviour, by hardcoding BUILD_LOCAL_GMOCK to true.
<bryce> slangasek, thanks
<dobey> slangasek: thanks. i've built it in my PPA, and have been running with the packages installed for some time now (on amd64 with the i386 p11kit bit installed as well)
<JanC> if any of you are coming to FOSDEM, please put your names on https://wiki.ubuntu.com/Fosdem/2013  âº
<mlankhorst> It's really tentative for me
<mlankhorst> no longer sure I'm going since the train from amsterdam to brussel has been cancelled :(
<JanC> mlankhorst: there is a train between Roosendaal & Antwerp, which means you get 2 changeovers, but you should be able to get there  âº
<mlankhorst> 2 additional changeovers
<mlankhorst> its groningen->schiphol->rotterdam->roosendaal->antwerp->brussels
<mlankhorst> >:(
<mlankhorst> noty
<JanC> or you use the Thalys, if you are rich enough...
<JanC> ugh
<JanC> mlankhorst: or try to find a ride with someone else?
<mlankhorst> startpoint is groningen, good luck :/
<JanC> well, if you can get a ride from Amsterdam or so, that would help a lot too, I suppose?
<JanC> mlankhorst: I also asked in #debian-nl (on OFTC), maybe somebody there can help
<mlankhorst> I might be getting a car though
<JanC> well, at least they don't expect the weather we got last year  :p
<JanC> (last year I had to bring the Ubuntu mobile multiseat to FOSDEM during a snow storm on Friday)
<mlankhorst> hah
<mlankhorst> i was stuck for 7 hours in a car for what should have been a 2.5 hour trip to eindhoven
 * ogra_ will probably come but decide spontaneous based on the weather
<ogra_> (i'll drive)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, TheMuso
<barry> hi TheMuso.  perfect timing :)
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<jbebel> What/where is the list of packages which are supported as part of 12.04 LTS?
<jbebel> I remember there used to be a file that listed them specifically, but I can't seem to find it now.
<jbebel> It was fewer than just those in main, especially when the LTS was reduced to just server.
<jbebel> but that was for dapper, I think that I'm remembering.
<ScottK> Define "supported"
<ScottK> It can mean multiple things.
<jbebel> The S in LTS.
<TheMuso> barry: Heh cool. I often wonder whether you just forget to do that... :p
<jbebel> How does canonical define it?
<barry> TheMuso: sometimes i do! :)
<jbebel> I expected it meant security updates are provided.
<ScottK> There's a field in LP that says.
<ogra_> didnt we have a tool ?
<ScottK> For 12.04 it's somewhat complex since some desktop packages are supported for 5 years too.
<ogra_> supported-in-ubuntu or so ?
<ScottK> Dunno.
<ogra_> or was that only seeded stuff
<ScottK> We do have seeded-in-ubuntu.
<ogra_> ah, then i mixed it up
<sarnold> is that the Supported: line in apt-cache show <packagename> ?
<jbebel> I'm guessing it's at least a subset of main, not a superset.
<JanC> ogra_: the expected weather seems fine  http://www.yr.no/place/Belgium/Brussels/Brussels/long.html  âº
<xnox> sarnold: depends on the value in the support field.
<ogra_> JanC, well, its the weather inbetween :)
<ogra_> if i arrive in brussels i wont be much outside anyway :)
<ScottK> jbebel: It is a subset.
<ScottK> sarnold: Yes.  That's what I was thinking of.
<sarnold> jbebel: I think from 12.04 LTS on, the idea is we'll support main/ for five years: https://wiki.ubuntu.com/Releases
<slangasek> ogra_, ScottK: "ubuntu-support-status"
<ogra_> ah, i knew there was something !
<sarnold> jbebel: (at least, I haven't seen an equivalent to the hardy-supported.txt yet)
<matttbe> JanC: yes, I confirm that the weather is fine (much better than the week before ;) )
<ScottK> jbebel: ^^^ see slangasek's remark.
<ScottK> slangasek: Thanks.  I didn't know about that one.
<sarnold> ScottK: thanks :)
<JanC> matttbe: if you come --> see the wiki page  ;)
<sarnold> err, slangasek thanks, rather :) hehe
<JanC> matttbe: last year we had to drive through 15cm of snow in some places (first with my personal car, then with the van with the multiseat system), that was worse than anything we've had this year, I think
<matttbe> JanC: yes I remember :) And it was very hot in some classrooms!
 * xnox is 75.0% supportable and 1.2% no longer downloadable
<jbebel> Thanks everyone.
#ubuntu-devel 2013-01-30
<TheMuso> /c/c
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Good morning
<stokachu> ugh its midnight here :)
<chiluk> yes it is...
<stokachu> chiluk: o/
<chiluk> and yes stokachu I am stalking you!
<stokachu> hah, thats ok i welcome the love
<pitti> cjwatson: ah, the upstream one does have = NULL, good
<chiluk> upstream++
<dholbach> good morning
<seb128> janimo, hey, thanks for the g-s-d patch, there is no upstream or downstream bug reference in there though, do you have one, can you share it?
<hrw> can someone suggest me good example of package with 'read and accept' license?
<janimo> seb128, https://bugzilla.gnome.org/show_bug.cgi?id=691691
<ubottu> Gnome bug 691691 in xrandr "Use transformation matrix to rotate touchscreens" [Normal,New]
<seb128> janimo, thanks, would be nice to put that info in the patch "Bug: bug URL" next time ;-)
<janimo> seb128, right, will next time :)
<seb128> janimo, thanks ;-)
<pitti> yay for Bastien reviewing patches fast
<janimo> I wonder why I did not get a mail notification though, it's only now that I checked the URL did I see the review
<janimo> seb128, btw I have a new patch for g-s-d but likely not upstreamable. It solved the nexus autorotation issue without relying on kernel changes. I'll write to the ml
<geser> hrw: I know only of the non-free jre/jdk packages doing it (in the past)
<janimo> s/solved/solves/
<hrw> geser: I need it for nonfree package
<seb128> janimo, thanks, if that's not upstreamable please open at least a launchpad bug with the rational so we know why it's there next time we look at merging with Debian or review our patches
<hrw> geser: Mali T604 drivers for arm chromebook
<janimo> hrw, you may want to look at the linux-firmware-nexus package too
<hrw> thanks
<pitti> dholbach: we'll have some autopkgtest hacking on Friday? Is that announced anywhere already? (for pointing to in my talk)
<hrw> bug 1000453
<ubottu> bug 1000453 in strace (Ubuntu) "strace 4.7 is available" [Medium,Triaged] https://launchpad.net/bugs/1000453
<pitti> dholbach: I'd just ask folks to show up in #ubuntu-quality, that should do?
<dholbach> pitti, I'll prepare some things in a bit - yes #ubuntu-quality - not announced yet, but soon
<ev> would someone kindly reject whoopsie 0.2.10 and 0.2.11 from Quantal? I was tired when I uploaded those :). They're meant for Raring.
<seb128> ev, done
<hrw> janimo: thanks, linux-firmware-nexus7 looks like something I need
<ev> seb128: thanks!
<xnox> hrw: the classic example is ttf-mscorefonts-installer as that one gets it completely right.
<hrw> xnox: thanks, will look at this one as well
<infinity> doko: Is cloog-parma obsolete now?
<doko>   infinity yes
<ogra_> stgraber, yo ... i'm planning on switching the nexus7 to use the g_composite USB gadget driver, that way we can have serial and usbnet support at the same time on the USB port ... to make NM not freak out on your PC i would like to boot with usb0 disabled on the nexus, while a upstart job with "ifconfig usb0 down" will work, i was wondering if you have some more elegant idea
<ogra_> bah, crap ... i missed the nomination period for DMB ... i was actually planning to apply
<seb128> did anyone apply?
<Laney> lots of people
<Laney> ogra_: go for the TB instead ;-)
<pitti> ogra_: I'm fairly sure they wouldn't slam the door and say "too late" :)
<Laney> The poll was just sent out, which I guess is what reminded him
<dholbach> dpm, coolbhavi, achiang, mhall119: ready for your sessions later on?
<coolbhavi> dholbach, pretty much :-)
<dpm> dholbach, indeed, having gotten confused by the dates, I've been ready for about a week ;)
<janimo> seb128, is there a way of getting g-s-d run while at the lightdm login? I wonder how to get that screen to react to tablet orientation
<seb128> janimo, the unity-greeter does run g-s-d
<janimo> seb128, thanks, I'll look into debugging it then
<seb128> yw
<EagleScreen> I don't want to be boring, but fixing the bug #1063599 would be important, please take it a look
<ubottu> Error: Launchpad bug 1063599 could not be found
<EagleScreen> (it is a private bug)
<achiang> dholbach: FSOV "ready" :)
<dholbach> :)
<mhall119> dholbach: no, but I'll do it anyway ;)
<dholbach> haha
<dholbach> great
<dholbach> sounds like we're all set :)
<rperier> hi, this patch has been backported into raring ? https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1061063  , when I activate "Browsing" to "On" it does not work here, and I am running an up-to-date raring
<ubottu> Ubuntu bug 1061063 in cups-filters (Ubuntu Raring) "[FFE] Reimplement automatic appearing of CUPS queues broadcasted by a remote CUPS server" [Critical,Fix released]
<stgraber> ogra_: oops, sorry, didn't see the highlight until you mentioned it in #ubuntu-desktop :)
<ogra_> heh
<seb128> rperier, try asking tkamppeter
<rperier> ok thanks
<rperier> tkamppeter: ping
<stgraber> ogra_: so what's surprising is that something brings it up on the nexus7. By default ifupdown (the network-interface jobs) won't bring up anything that's not defined in /etc/network/interfaces
<ogra_> stgraber, *i* bring it up :)
<stgraber> ogra_: so I'm vaguely suspecting that NetworkManager is what brings it up on the nexus7 and if so, you can work around it by putting "auto usb0" and "iface usb0 inet manual" in /etc/network/interfaces (so that ifupdown doesn't "up" the device and NM considers it managed)
<ogra_> usbnet isnt modular so the kernel definitely creates that device on boot and i guess NM then picks it up but leaves it unconfigured
<stgraber> ogra_: well, you create the device, but by default it'd be "down", NM brings it "up" (speaking of link state)
<ogra_> stgraber, i wont mangle /e/n/i from a package :)
<stgraber> ogra_: not from a package, but you can from the installer
<ogra_> that will annoy everyone who gets it through an upgrade
<ogra_> NM on the desktop you attach the n7 to really goes wild
<ogra_> in a pretty nioisy manner
<stgraber> yeah, but it's not limited to the nexus7, NM annoys me just as much with all my phones (nokia phones create a usb0 too) :)
<stgraber> I think the right fix for this is to make NM only connect to usbX devices if asked to and not start doing DHCP whenever one shows up
<stgraber> that'd fix the nexus7 thing and any other phone that creates a usb network interface
<stgraber> (then if you actually want to connect to it, just click on the link in nm-applet)
<stgraber> cyphermox: does that make sense to you? ^
<cyphermox> it does
<cyphermox> it's a request in a bug too
<ogra_> awesome, so i dont need to add hacks :)
<cyphermox> I guess it makes sense I can cook up a quick patch for this today I think
<janimo> seb128, should gnome-settings-daemon be running by default in the unity-greeter? On a fresh boot I am at login but ps shows no g-s-d
 * ogra_ knew it would be  good to ask :)
<seb128> janimo, yes
<cyphermox> ogra_: fwiw I'm all for the g_composite gadget
<ogra_> already in :)
<cyphermox> is the effective USB ID on PC going to be the same as it is now?
<janimo> seb128, ok
<ogra_> hmm, no idea
<ogra_> might have changed with the driver
<ogra_> is that important ?
<seb128> janimo, you are sure you use the unity greeter?
 * cyphermox looks at the driver
<seb128> janimo, e.g not the gtk one?
<cyphermox> ogra_: somewhat if you don't want MM to also try to probe it
<ogra_> oh, i forgot
<ogra_> yeah
<stokachu> cjwatson: thanks for the added information on that installer issue
<janimo> seb128, yes unity, but I see there was an unrelated error in Xsession startup that may have interfered, I'll restart and check again
<ogra_> seb128, i think its quite visible if you use the gtk one and warp visually to 1995 :)
<seb128> ;-)
<cjwatson> np
<seb128> janimo, unity-greeter/src/settings-daemon.vala has the code
<seb128> janimo, it also has a
<seb128> settings-daemon.vala:            debug ("Could not start gnome-settings-daemon over DBus: %s", e.message);
<seb128> if it fails to start it (it tries to dbus active org.gnome.SettingsDaemon)
<seb128> janimo, check the /var/log/lightdm/*greeter...log
<ogra_> hmm, but shouldnt that be noticeable through the theme etc ?
<ogra_> i assume it looks awful without g-s-d running
<seb128> it should, be you would probably not notice it much from the greeter without using it
<ogra_> cyphermox, oh, i noticed that my BT doesnt survive a suspend/resume cycle (well, BT does, but i cant re-connect devices) i suspect there is still some work left for later
<seb128> like the background and the userlist are an image and cairo drawing
<cyphermox> ogra_: yeah, I think if the patchram ever stops sendng the messages to make hci work, it can't pick it back up
<cyphermox> I'll test this some more, but it's going to be tricky
<cyphermox> ogra_: what driver do you use for the net interface with composite?
<ogra_> we could make pm-utils unload the whole stack (or the parts of it needing to be newly initalized)
<cyphermox> yeah guess so
<ogra_> that will indeed slow down suspend :/
<cyphermox> or maybe just stopping patchram and starting it again could be enough
<ogra_> right
<cyphermox> I mean, if it somehow gets to sending crap before the tty is ready to accept data
<ogra_> cyphermox, the g_composite driver USB_CDC_COMPOSITE is the kernel option for it
<cyphermox> yeah
<cyphermox> but I mean, did you configure it already?
<cyphermox> you need to somehow specific some magic things
<ogra_> not beyond enabling it in the kernel
<cyphermox> like, what interfaces you want it to do
<janimo> seb128, indeed, such an error is logged in the greeter logs, no such service in any .service file. I may have botched something locally
<ogra_> well, it does ttyGS0 and usb0 by default
<cyphermox> hmm
<janimo> I need to do a fresh install soon anyway
<cyphermox> I must have misread then
<cyphermox> oh well
<ogra_> i tested serial and checked that i see usb0 on my PC when i plug it in
<ogra_> i didnt actually set up a TCP connection though
<seb128> janimo, do you have /usr/share/dbus-1/system-services/org.gnome.SettingsDaemon.DateTimeMechanism.service ?
<cyphermox> what USB id does it have?
<cyphermox> still 0525:whatever?
<seb128> janimo, sorry, ignore that
<janimo> seb128, yes, that file is there but I saw no other with the other service name
<ogra_> Bus 002 Device 012: ID 0525:a4aa Netchip Technology, Inc. Linux-USB CDC Composite Gadge (Ethernet and ACM)
<ogra_> yep
<janimo> while debugging I ran g-s-d from the command line
<cyphermox> ok
<cyphermox> not quite the same but close enough
<seb128> janimo, it's a bug, not a local issue, I will fix it ... g-s-d upstream dropped the dbus activation from g-s-d
<seb128> janimo, http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-6&id=b778aad98bf5e1acc9899e757345dcee3a5294fd
<seb128> janimo, we need to update unity-greeter to activate g-s-d differently (e.g just g_spawn the command)
<janimo> seb128, ah ok
<janimo> so when that is done we should probably get autorotation work in lightdm as well
<seb128> cool
<janimo> seb128, are gnome 3.8 components planned for 13.04?
<seb128> no
<seb128> well nothing in the stack components
<seb128> we might take e.g new gedit eog evince
<seb128> it depends if we decide to update gtk or not
<seb128> but no news g-s-d or g-c-c
<ogra_> nautilus ?
<Laney> can someone check u-d-a and see if there's a call for votes from micahg waiting to be moderated please?
<micahg> Laney: there's no
<micahg> *not
<janimo> Laney, I got the mail at least
<Laney> you'll have had a ballot, yeah
<janimo> but not on the ml
<Laney> the call for votes shares the manifesto thingies
<cjwatson> nothing in the u-d-a queue aside from a couple of spams
<Laney> yeah, he confirmed ^ â expect it in a few minutes
<tkamppeter> rperier, hi
<micahg> cjwatson: message should be in the queue
<rperier> tkamppeter: hi
<cjwatson> micahg: accepted
<micahg> cjwatson: thanks
<rperier> tkamppeter: on raring (updated this morning) cups automatic browsing does not work, cups-filter and cups-browsed are installed
<OdyX> tkamppeter: is that the bug that needs most recent cups which I should upload ?
<tkamppeter> rperier, in Raring the mechanism has changed. The old CUPS broadcasting is replaced by Bonjour broadcasting. The server must be CUPS 1.6.x or Ubuntu with CUPS 1.5.x or higher. The server must have printer sharing turned on and also the individual printers must be set for being shared. The client is Raring with cups-browsed running.
<rperier> the server does not run cups 1.6.x, it runs cups 1.5.x I guess
<tkamppeter> OdyX, the most recent CUPS is for another bug, bug 1069671.
<ubottu> bug 1069671 in cups (Ubuntu Quantal) "no print queues displayed in pure client mode" [Medium,Triaged] https://launchpad.net/bugs/1069671
<tkamppeter> rperier, the server must do Bonjour broadcasting. Run avahi-discover on the client and see whether the server's printers appear there as "Internet Printer".
<rperier> tkamppeter: I see "Unix Printer", "PLD Printer" and "Internet Printer"
<rperier> PDL *
<rperier> tkamppeter: however with evince, the list of printers is still empty
<tkamppeter> rperier, can you restart cups-browsed on the client and see whether the printers appear in evince (or in the output of "lpstat -v"?
<rperier> "lpstat: Transport endpoint is not connected"
<rperier> :\
<tkamppeter> Can you restart cups on the client?
<rperier> already done
<tkamppeter> rperier, do you have a file /etc/cups/client.conf?
<rperier> no
<tkamppeter> rperier, or ~/.cups/client.conf?
<rperier> tkamppeter: no
<rperier> :(
<tkamppeter> rperier, do you have any local CUPS queues on the client?
<rperier> no, it's just my personal laptop at work
<tkamppeter> rperier, so backup all what is in /etc/cups, for example via "sudo tar -cvzf backup.tar.gz /etc/cups" and then run
<tkamppeter> sudo dpkg -P --force-depends cups-daemon cups; sudo apt-get install cups-daemon cups
<rperier> done
<tkamppeter> rperier, does "lpstat -v" work now?
<rperier> lpstat -v  => "lpstat: No destinations added."
<rperier> output is different, work in progress :P
<tkamppeter> OdyX, I have added another small fix on CUPS to the Debian GIT.
<tkamppeter> rperier, now restart cups-browsed on the client.
<OdyX> tkamppeter: I hope to have the french translation done by the end of the week.
<rperier> tkamppeter: done, and I still get the same output
<tkamppeter> rperier, is avahi-daemon running on both the server and the client?
<rperier> on the client yes, on the server not sure
<tseliot> cyphermox: all of our problems with the linux headers seem to be solved now. I think it's ok to approve my merge request now
<cyphermox> tseliot: ack
<tseliot> cyphermox: thanks!
<rperier> tkamppeter: I will ask my sysadmins about the server, thanks for your help!
<cjwatson> pitti: https://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/628 - do you happen to remember why you removed "g_object_set_data (G_OBJECT(ta->tray_icon), "notification", n);"?
<cjwatson> pitti: Is it no longer meaningful to keep a handle for the notification around to close it, or something?
<rbasak> doko: could you please take a look at bug 1073147? Quite a few people are reporting that it's an error and not just a warning now. Do we need to SRU a no-change rebuild or something?
<ubottu> bug 1073147 in libapache2-mod-python (Ubuntu) " Python version mismatch, expected '2.7.2+', found '2.7.3'" [High,Confirmed] https://launchpad.net/bugs/1073147
<doko> rbasak, no change rebuild sounds fine
<rbasak> OK, thanks
<stokachu> bdmurray: ping
<bdmurray> stokachu: hi
<stokachu> bdmurray: hey man :)
<stokachu> bdmurray: i've got a case if you got a chance to look at (SRU)
<stokachu> its getting some attention and need to get some traction on it
<stokachu> bug 1101371
<ubottu> bug 1101371 in walinuxagent (Ubuntu) "[SRU] Integrate v1.3 of Windows Azure Linux Agent" [Medium,Triaged] https://launchpad.net/bugs/1101371
<bdmurray> stokachu: does this need sponsoring or approving in the SRU queue?
<stokachu> looks like it needs both at this time
<stokachu> bdmurray: do you want me to have the owner provide a debdiff for upload?
<stokachu> looks like they only linked their branches to the case
<doko> infinity, apw: is the removal of 'struct siginfo' in 3.8 intentional?
<bdmurray> stokachu: that'd help
<stokachu> bdmurray: ok ill get them to do that now
<stokachu> bdmurray: bah the owner is off this week, im going to build these diffs, mind if i ping you when im done?
<mlankhorst> well I've got proof nobody ran wine64 on valgrind yet
<mlankhorst> :D
<bdmurray> stokachu: nope
<stokachu> cool thanks
<smoser> psusi, will / would 'blockdev --rereadpt' on a re-written partition table cause the kernel to update its view?
<ogra_> thats its purpose, no ?
<smoser> well, i was asking specifically wrt partitions that have been updated like with parx at http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commitdiff;h=3b905b794e93609af7e42459d32b27e7c18ce02e
<smoser> oh...
<smoser> i know why it might not.
<smoser> blockdev int he past would REREAD ioctrl which kernel would deny
<smoser> if there were mounted filesystems on that device.
<smoser> but psusi tells me now that i can grow a mounted partition and tell the kernel about that.
<ogra_> yeah
<Quintasan> Laney: Well, I'll take a look at the packaging later but I don't think I have any changes to add there. As for the Debian mainter I'd like to be the primary maintainer. Gotta start contributing to Debian at some point at this seems like a good ocassion.
<Quintasan> Laney: By the way, any huge mistakes there? I'm almost done with plugins packaging so I'd like you to take a look at those later.
<xkernel> how to create deb package from scratch for existing project?
<psusi> smoser, right, hence the kernel and other patches
<psusi> smoser, BLKRRPART won't work if any partitions are open
<infinity> doko: No idea about the signinfo thing, a kernel git log might help (or Andy).
<infinity> doko: But, speaking of backward compatibility things, have you fixed and rebuilt all the compilers that need rebuilding so I can drop local-revert-bz13979.diff from eglibc (the FORTIFY_SOURCE / optimization warning)?
<Laney> Quintasan: Aye aye. I'll admit that I don't really know what you did with xinput.d ;-)
<Laney> I think the biggest issue (if I'm not mistaken on that) was the library package being named wrongly
<Laney> and I'm not sure the symbols file is a good idea - it seems pretty brittle
<slangasek> Laney: what's this about symbols files being brittle?
<Laney> slangasek: C++ ones
<slangasek> ah, yeah
<slangasek> they certainly can be
<slangasek> I think Russ Allbery's analysis is canonical there
<Laney> http://www.eyrie.org/~eagle/journal/2012-01/008.html
<Laney> ha, yeah, that
<cody-somerville> ev: Happy Birthday! :)
<bdmurray> slangasek: digging around in update-notifer I've discovered that it wants to call gnome-app-install in some cases (when it finds an "addon" CD)
<slangasek> bdmurray: is that a command?  I don't seem to have gnome-app-install here
<cjwatson> I think addon CDs are historical; that was Edubuntu at one point
<cjwatson> gnome-app-install used to be a package
<bdmurray> slangasek: I believe it last appeared in karmic
<cjwatson> Removed in lucid
<slangasek> ok
<cjwatson> https://launchpad.net/ubuntu/+source/gnome-app-install/+publishinghistory
<slangasek> bdmurray: so it's dead code and should be pruned, I guess?
<cjwatson> I think so.  It has quite a lot of tentacles though so try to get them all :-)
<bdmurray> Based off cjwatson saying they are historical I'd say yes
<cjwatson> Edubuntu stopped using addon CDs in I think jaunty
<cjwatson> no, karmic
<bdmurray> And it seems nobody else has complained about support being missing so away it will go.
<ritz> hi, looking to push for an sru - https://bugs.launchpad.net/ubuntu/+source/unity/+bug/806248
<ubottu> Ubuntu bug 806248 in unity (Ubuntu Precise) "unity::TimeUtil::TimeDelta returns an int value which overflows after 24 days of uptime" [High,In progress]
<infinity> That still isn't fixed in precise? :/
<arges> infinity: nope. branches are linked and ready
<cjwatson> What else is in this SRU?
<arges> I think the merge request just needs to reviewed/accepted
<infinity> arges: There seems to be a followup about your merge requests.
<cjwatson> I agree that bug is serious; if it's just that one change, I'd grant it an exception
 * infinity nods.
<arges> infinity: it was an answer to a question about the process.
<arges> infinity: i did a debdiff, but a bzr merge was requested, and I messed that up  : ) to timo did a proper merge request
<infinity> I'm inclined to disgaree that, in general, MPs are preferred over diffs, but I don't want to get into an argument in the bug comments. :P
<tjaalton> oh that's the bug I was seeing..
<infinity> (I also just get annoyed as a matter of principle when people argue that the format of a patch, rather than the content, is "wrong")
<infinity> arges: I assume this is unity-specific, and doesn't affect unity-2d?
<arges> infinity: i'm not sure. this is the first unity bug i've looked at
<arges> i thought unity-2d was derived from unity?
<infinity> Only in name.
<cjwatson> And design.
<cjwatson> The actual code is (AIUI) largely independent.
<infinity> They're completely different codebases, one being a compiz plugin, and the other abusing metacity.
<arges> well don't see anything a bug search
<arges> looking for similarly named files
<bregma> 806248 is unity-specific:  it's scheduled to go in with the regular 12.04 unity/compiz SRU in February
<arges> does look like it even uses TimeUtil::TimeDelta so I would guess it isn't affected
<infinity> bregma: Do you think it's worth a cherry-pick SRU for 12.04.2?
<xxiao> how can I add a new arch to ubuntu?
<infinity> bregma: (Colin and I are certainly inclined to accept it)
<infinity> xxiao: Which arch would that be?
<xxiao> tried bootstrap debian for a new arch in the past, PITA
<xxiao> infinity: 64bit freescale powerpc chip
<bregma> infinity, that's really up to the distro guys, certainly the patch is already in 12.10 and raring so it's well tested
<infinity> xxiao: If you just mean the kernel side, talk to BenC.  He's already on top of things with the 32-bit fsl ppc stuff.
<bregma> I have no objection to a cheryy-pick SRU
<infinity> xxiao: If you mean a ppc64 userspace, that's probably not going to happen (and largely a pointless endeavour, ppc32 userspace on ppc64 kernels is saner)
<xxiao> infinity: actually for kernel it's less urgent, the ubuntu rootfs is more interesting
<infinity> xxiao: Except that Ubuntu's userspace already supports your processor, so we're done. ;)
<xxiao> we're trying to do some enterprise level data center stuff with the 64bit ppc
<xxiao> infinity: are you sure about that on e5500/e6500 ppc?
<infinity> xxiao: Quite sure, except for kernels and installers.
<cjwatson> Not wanting to be blunt, but a new architecture involves substantial enough outlay of time, effort, and money that it's unlikely to happen without some kind of contractual arrangement with Canonical
<infinity> xxiao: It's a common misconception that you need (or even want) a 64-bit userspace on 64-bit CPUs.
<xxiao> i used that on e500 machines and got some floating point issues in the past, but e5500/e6500 does have the legacy ppc FPU now
<xxiao> i mean i used the default debian rootfs in the past
<infinity> xxiao: If you had/have FPU issues on e500, please, file bugs against the affected packages.
<cjwatson> (We've looked at ppc64 before, but it needs that kind of support to have it in Ubuntu)
<xxiao> without 64bit userspace for data-centric usage 32bit might not be enough
<xxiao> cjwatson: what kind of support?
<xxiao> debian's ppc64 efforts only work for ppc64 with VMX
<infinity> xxiao: 15:55 < cjwatson> Not wanting to be blunt, but a new architecture involves substantial enough outlay of time, effort, and money that it's unlikely to happen without some kind of contractual arrangement with Canonical
<infinity> xxiao: That kind of support.
<xxiao> infinity: that's very likely, i'm doing some pilot study here first
<infinity> xxiao: Still, I'm going to continue arguing that you probably don't actually need a 64-bit userspace (except, possibly, the occasional application built with 64-bit support).
<xxiao> infinity: for now i will actually have to use 32bit rootfs
<infinity> xxiao: Which should work fine, as I said.  If you bump into bugs, please do file them.
<cjwatson> I will say that if there were ever commercial backing for it then some of us do actually enjoy bringing up ports
<infinity> Yes, some of us do. :)
<infinity> And some of us have a soft spot for PPC too.
<xxiao> we never had e500 full support as far as i know due to its "new" fpu, but we return to the non-e500 ppc so the 32bit rootfs should work at least
<cjwatson> But with the requirements that Launchpad builders be in the data centre and that the initial tarballs be highly trusted, it isn't really something third parties can do (well, obviously you could in principle run a parallel set of builders if you wanted to, but to have it actually part of Ubuntu ...)
<infinity> xxiao: Well, we have e500 kernels and supposedly support it, so it would be nice to know what these issues were that you were seeing.
<xxiao> infinity: i thought everyone is leaving ppc for ARM nowadays :)
<cjwatson> Some of us *personally* have a soft spot for ppc, which isn't quite the same :)
<xxiao> http://pureperl.blogspot.com/2011/10/debian-powerpc-e500v2-port-part-5.html
<xxiao> for ppc there are always some little instruction difference
<xxiao> for e500 with standard debian we had issues with floating points in the past
<cjwatson> Cross-compiling of packages is getting a lot easier thanks to work being done mainly for ARM
<infinity> xxiao: That's Debian, not Ubuntu.  Just sayin', Servergy has e500 machines that they run Ubuntu on.
<cjwatson> https://wiki.ubuntu.com/CrossBuilding
<cjwatson> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot
<cjwatson> And similar efforts in Debian
<xxiao> infinity: yeah i am now working with servergy guys :)
<cjwatson> Most of this stuff is fairly architecture-independent once you have a cross-toolchain - and there's a powerpc cross-toolchain in raring
<infinity> xxiao: Then I suggest talking to BenC about the issues you've seen.
<cjwatson> (ok, not ppc64)
<infinity> cjwatson: We have a ppc64 cross toolchain too.
<infinity> cjwatson: (The cross is bi-arch)
<xxiao> we have the toolchain built from yocto
<xxiao> will find BenC
<cjwatson> xxiao: multiarch cross toolchains are slightly different
<xxiao> cjwatson: that's still been worked on indeed
<cjwatson> you want the multiarch configuration so that cross-building packages stands a chancec
<infinity> Our toolchain is slightly different in general.  I don't tend to recommend crossing for Ubuntu with some other random toolchain.
<cjwatson> infinity: mm, I expect that if we actually wanted to do cross-building to ppc64 we'd want a gcc that defaulted to it, rather than it merely being an -m64 choice
<infinity> cjwatson: Oh, for ppc64 the Debian arch, yes.
<cjwatson> the latter's fine for one-offs but not much use for crossing at scale
<infinity> cjwatson: But for ppc64, the compilation target, a biarch cross works fine.
<cjwatson> yeah
<infinity> Dangit.  Missed the post-copy-pre-publish window to promote linux-ppc back to main.
<cjwatson> really.  really.  really must fix that bug.
<infinity> Yeah.  It's merely annoying busywork most of the time, but it's pretty heinous when it does things like subtly move binaries from multiverse to universe and we don't notice.
 * xnox is yet to participate in bringing up a new arch
<infinity> xnox: I've only been involved in 5 or 6.
<infinity> xnox: You might not be missing out on much.  Some people find it an awful process.  Me, I live for awful, cause I'm a software masochist.
<xnox> infinity: hmm... did all of them make it? but i guess that doesn't really matter as rootfs and builders are done at that point.
<infinity> xnox: All of the ones I did for Ubuntu made it, to some degree or other, though many are becoming deprecated now.
<infinity> No love lost between lpia and I, good riddance to it in April.
<xxiao> what about the AARM64 support
<xxiao> looks like ARM sponsored linaro who then sponsored cannonical to do that
<infinity> xxiao: aarch64 or arm64, not aarm64. :)
<sarnold> "International Packaged Ice Association"? "International Pipe Inspectors Association"?
<xxiao> aarh...
<infinity> xxiao: And the relationships are a bit muddier than that, even, but yes, it's in progress.
<infinity> sarnold: That's LPIA, not IPIA.
<cjwatson> Don't expect people to spell out exactly who's paying whom how much in public, though.
<sarnold> infinity: ah! I missed that pixel. :)
<xxiao> wookware.org/talks/arm64linuxconf2012.pdf
<cjwatson> Yeah, we know, we work with wookey regularly
<xxiao> most ARM can not even handle 1G port...and we're all talking about arm64 server nowadays
<infinity> cjwatson: So, I shouldn't tell people that I'm being sponsored by my neighbour to fix bugs in sl?
<cjwatson> infinity: If you've signed an NDA with your neighbour, that's your look-out
 * xxiao looks the ppc board that has 4x10G ports on the bench
<infinity> cjwatson: I did, but then I ate it.  So, it doesn't count, right?
 * infinity loves that command-not-found recommends installing sl when you typo ls or have your caps-lock on.
<infinity> I wonder how many people do...
<xxiao> INFO: rcu_sched_state detected stall on CPU 21 (t=15000 jiffies)  sigh
<xxiao> another kernel lockup
#ubuntu-devel 2013-01-31
<scientes> infinity, indeed
<scientes> apt-get should also alias isntall to install
<TheLordOfTime> apt-cache should alias info to show too.
<TheLordOfTime> ((opinion))
<cjwatson> pitti: Never mind my earlier question about libnotify; having looked into the libnotify source I've answered it to my own satisfaction (i.e. there is indeed no longer a need to keep a handle around)
<cjwatson> Which is great since I can remove another chunk of code
<cjwatson> Wait.  notify_notification_close does still do something useful ...
 * cjwatson uncommits
<cjwatson> Well, only for notification-daemon, as notify-osd ignores CloseNotification.  But I suppose I should keep it around.
<xnox> dobey: I've made merge proposals to fix apport hook in ubuntuone-client, but i'm not sure about stable branches & packaging management around it. It's to fix bug 1098128 in quantal and raring. Branches are attached to that bug.
<ubottu> bug 1098128 in ubuntuone-client (Ubuntu Raring) "ubuntuone-client hook error, not python3 compatible" [High,Triaged] https://launchpad.net/bugs/1098128
<ScottK> Laney and slangasek: C++ symbols files do seem ~manageable with the symbolshelper that MoDaX did for KDE (referenced in Russ's blog post).
<hyperair> they're somewhat manageable even without, if you c++filt them.
<BenC> xxiao: e500v2 doesn't need soft-float for most cases
<BenC> v1 is a different story and I don't think there are many e500v1's out in the wild anyway
<infinity> BenC: Ahh, it was a lack of soft-float implementation?
<xxiao> BenC: does ubuntu has an e500-v2 rootfs, soft-float is fine, assume it's compiled for e500v2
<xxiao> s/has/have/
<infinity> xxiao: I think what he was driving at is that Ubuntu's powerpc userspace works fine on e500v2.  We don't have different "rootfses" for each subarch, nor do we compile userspace over and over again for each.
<infinity> xxiao: But we do have e500 kernels, and a generic ppc32 userspace that works with them.
<pitti> cjwatson: AFAIR it's not because of keeping handles, but because current notifications don't have tray icons any more
<dholbach> good morning
<Quintasan> dholbach: dzien dobry
<Quintasan> Laney: Oh I really did name it libmaliit1, so silly. As for symbols, well,  I thought it's generally good idea to provide symbols files for libraries.
<dholbach> Quintasan, czeÅÂ´c (can't get the 'Â´' on the c properly :-))
<Quintasan> :D
<Quintasan> Ä
<dholbach> ha, thanks - I'll always go back to the log and copy it from here :)
<Quintasan> I was about to suggest that but realised it would be a little bit tedious
<Quintasan> I always have my â­ in Klipper in case I ever need it again
<Quintasan> :P
<dholbach> :)
<Quintasan> Laney: Well, after looking at rules I'm kind of wondering how was I supposed to figure this cleaning magic out but if you got this covered then I really have nothing to add there.
<ion> compose C C C P â­
<pitti> ion: heh, cool!
<Laney> ScottK: Yeah, I am using that. I suppose that's OK but it does still feel slightly distasteful that I'm supposed to go through one iteration on the buildds before it's correct on all arches. Also I don't really understand why it seems to re-export symbols from dependent libraries.
<Laney> Quintasan: I nicked it from upstream's package and then noticed that some generated files were left over meaning that debuild -S failed so added those ones too. ;-)
<infinity> Laney: Clearly, you're meant to have 13 architectures in your living room, so you don't have to abuse buildds.
<infinity> Laney: (Though, to be vaguely fair, there are ways to guess/pre-mangle symbols for various arch oddities)
<infinity> Laney: A bit harder, though, to guess if a symbol is just completely ifdefed out on an arch unless you know every line of code, though. :P
<xnox> dholbach: fixing packages to cross-build will be an irc talk. And I hope to fit it nicer into 30min slot now.
<dholbach> perfect
<Laney> Quintasan: The debian-mobile guys think that it would be good to maintain maliit under their umbrella (not really an official team as such)
<dholbach> pitti, tumbleweed, ogra_, bdrung, geser: ready for later on? :)
<tumbleweed> oh, right, must write something
<geser> dholbach: I hope :) should I've prepared something?
<dholbach> no no :)
<pitti> dholbach: I'll make something up :)
<dholbach> :-D
<rbasak> Is rmadison broken for anyone else? It just hangs on me.
<rbasak> Looks like it gets there eventually (ie. 4 minutes!)
<tumbleweed> rbasak: yes, that's the normal failure mode with it
<tumbleweed> and then it's fast again
<janimo> Laney, 2 of the Linaro folk I knew got membership approval after a while (it just took longer for them to make up their minds about applying)
<ogra_> dholbach, nope, but will be by then :)
<janimo> one other said he had no interest as it takes too much time to fulfill the ancillary conditions IIRC
<sladen> if the "ancillary conditions" are taking too long this is not good, as the Debian process fails/ed for many years with similiar
<janimo> sladen, anything not pertaining to getting their 1 of 2 software modules out in the archives likely looks like ancillary to most  devs in this category
<janimo> even if they are good at their own package, they may not care about the various patch systems, build systems, UDD and whatever else may be expected from someone that touched packages across the archive
<Laney> per-package upload rights don't require that kind of knowledge
<Laney> you just need to know about stuff relevant to your package
<janimo> Laney, good to know.
<sladen> Laney: I was more assuming this was the "create a wikipage and fill it with stuff"
<janimo> sladen, that too, yes
<sladen> but if it's not that, that's good to know too
<Laney> yeah, it could be.
<tumbleweed> getting involved in any project is going to have some burden
<tumbleweed> and I don't tihnk it's reasonable to give upload rights until people have acclimatised and know their way around
<tumbleweed> which means that they are going to have to put some effort in
<janimo> tumbleweed, but when people know they way around it is not reasonable to nitpick and demotivate them
<janimo> especially PPUs which carry a lot less risk for the system as a whole
<bdrung> dholbach: i hope so.
<tumbleweed> janimo: we most certainly expect more experience for broad rights than narrow
<tumbleweed> most of the time I'm just looking at whether the applicant is capable of maintaing the package to a reasonable quality level, without a sponsor to help and review
<tumbleweed> once you have upload rights, nobody is going to help you unless you ask
<janimo> tumbleweed, I also think that other contributions to ubuntu such as advocacy should have nothing to do with PPU approval
<tumbleweed> janimo: we probably need to disentangle membership from PPU
<janimo> I know that one needs to (needed to?) be an ubuntu -member to get upload rights, but I don;t think questions like 'how do you represent ubuntu' are appropriate
<tumbleweed> but we haven't yet
<tumbleweed> the membership aspect is only rarely an issue
<janimo> for PPU, a track record in the ubuntu-changes mailing list should suffice. Especially with string endorsements and no -1 endorsements it is absurd to not approve someone
<janimo> s/string/strong/
<tumbleweed> absolutely
<janimo> sorry, but I am still baffled to learn about the libo case :)
<tumbleweed> I wasn't voting in that particular meeting, and I don't really want to discuss details about it
<janimo> The DMB like a good manager should get out of the way and _help_ developers do their jobs more smoothly not nitpick, let alone subtly patronize
<tumbleweed> I'm happily talking in broader terms :)
<janimo> yes, I am talking about broader terms but this is the only case I can think of as it is the only package high profile enough that made me comment
<janimo> but it highlights a lack of agility I'd say
<janimo> it's not that we could not use more uploaders in sandboxes who learn and improve by uploading instead of putting the barrier to entry too high and be a bottleneck
<tumbleweed> most applications are no-brainers. Someone comes in with a range of experience, and good endorsements. It's just a matter of checking that they know about release cycles & processes (and you'll learn the important bits from the meeting if weren't already familiar with them)
<Laney> Quintasan: Uploaded! If you've any changes then I'll integrate them into a -2
<xkernel> I'm creating my first deb package, where to specify the application Icon and screenshot that will be displayed in the Software Center?
<xnox> xkernel: icon is referenced in the .desktop file.
<xnox> xkernel: screenshots are uploaded here: http://screenshots.ubuntu.com/upload
<xkernel> thanks xnox, I'm creating a package for PHP code project and after I executed dpkg-buildpackage, the result package didn't contain PHP files
<xnox> xkernel: php packages don't usually show up in software center.... they are typically considered 'technical' packages.
<xnox> xkernel: there is more packaging help in #ubuntu-packaging and/or #ubuntu-motu
<xkernel> Thanks a lot
<menace> is there a possibility to download from different ubuntu sections into different own repositories? i want to separate the repositories
<jpds> menace: Different ubuntu releases?
<davmor2> ogra_: hey dude are you about?
<ogra_> davmor2, i am, yes
<menace> na, only different sections. one repository for raring, raring-updates, raring-security e.g.
<davmor2> ogra_: I get an odd issue running software-updater on the n7 it pops up a apport window and then pops up an admin window and keyboard.  However the keyboard isn't functioning so I can't report it, I've tried resubmitting it same issue
<ogra_> davmor2, fixed today, send flowers to bdmurray
<ogra_> (might not have propagated around yet)
<davmor2> ogra_: ah okay that explains it then
<davmor2> ogra_: so leave updating till tomorrow then
<ogra_> we need to drop gksu from all images ... update-notifier and xdiagnose are the last tools using it
<ogra_> u-n was fixed today xdiagnose should happen too before release (less urgent though since less visible)
<davmor2> ogra_: fair enough
<cjwatson> menace: debmirror should help
<davmor2> ogra_: I'm assuming then that the keyboard is called under the gksu too then or something?
<cjwatson> menace: in its terminology, raring, raring-updates, etc. are "distributions" or "suites".
<cjwatson> menace: (sections are something else.)
<ogra_> update-notifier called gksu to run apport
<ogra_> the dislog you see after login is update-notifier
<ogra_> *dialog
<cjwatson> u-n still uses gksu for some things, just not apport
<ogra_> oh
<ogra_> k
<cjwatson> though actually those may be fallback paths from aptdaemon and friends
<ogra_> i was hoping we could wipe gksu
<cjwatson> it still Depends on it
<ogra_> k
<cjwatson> shouldn't matter much if it doesn't get used in practice
<ogra_> well, it is still on the images, would be good to slowly educate people over to pkexec
<pitti> bdmurray: btw, was it intentional that update-notifier now hard-depends on gksu? I thought this dep should have been gone now?
<ogra_> (given that we use it since years and nobody seems to know about it)
<cjwatson> pitti: as I say, it's still used by a number of fallback paths in u-n
<pitti> oh, ok
<cjwatson> it may be an error - some of the pieces that use it seem themselves unused
<Laney> at least one path calls synaptic which is itself only a recommends
<pitti> is it? it hasn't been on the images for a long time
<cjwatson> let's see what I can do
<pitti> ah, alternative dep
<Laney> alternate with python-ap...
<pitti> python-aptdaemon.gtk3widgets preferred
<Laney> :-)
<cjwatson> yeah, I think most of this can be superseded by aptdaemon
<cjwatson> bzr log of some of the other things dates from 2004
<ogra_> seb128, are power-statistics supposed to dynamically update their UI ? doesnt seem to happen here if i look at the battery details
<pitti> for example, data/upgrade-app is being called nowhere apparenlty, nor installed
<seb128> ogra_, I don't know off hand, not sure
<pitti> same with dbus-helper
<cjwatson> pitti: too slow old man
<ogra_> heh
<pitti> cjwatson: let me guess, you already dropped it in bzr? :-)
<cjwatson> yeah
<pitti> cheers :)
<cjwatson> cddistupgrader is the last true dep, I think
<Daviey> stgraber: is there intention to SRU your UEFI fix for LXC?
<nemo_> hello :')
<ogra_> seb128, it seems to update if i switch from Details to History and back, but not if i just leave Details open, i think that worked in quantal
<ogra_> (battery details)
<seb128> ogra_, there is no code change between quantal and raring for that source
<seb128> ogra_, the only upload has this diff: https://launchpadlibrarian.net/121932082/gnome-power-manager_3.6.0-0ubuntu1_3.6.0-1.diff.gz
<ogra_> well, pitti's patch could be related
 * ogra_ checks bug 951827
<ubottu> bug 951827 in gnome-power-manager (Ubuntu) "Power Statistics window blank" [High,Fix released] https://launchpad.net/bugs/951827
<pitti> that's very unlikely to affect the running instance, unless you opened it a second time
<ogra_> ah, no, thats to trivial
<ogra_> yeah, just saw the patch
<mohamedalaa98> Hello guys :) ,My friend nemo_ Have a question about vala can you please help him? :D
<stgraber> Daviey: yes
<mohamedalaa98> nemo_: go ahead
<stgraber> Daviey: it missed the last SRU unfortunately but hallyn and I are aware of it and we'll make sure it gets with the next one
<cjwatson> bdmurray: I don't understand how your pkexec stuff in update-notifier works.  pkexec doesn't permit running X applications as another user by default ...
<nemo_>  Is here anyone who have tried to load XML UI file with Vala and the signals worked with him ?
<Daviey> stgraber: Do you have an ETA?
<ogra_> cjwatson, it does with --user i think
<ogra_> if you omit --user it uses root
<cjwatson> ogra_: u-n doesn't use --user
<ogra_> oh
<ogra_> well, then it will use root
<cjwatson> Yes, I know
<ogra_> (which it should actually)
<cjwatson> Therefore pkexec won't permit apport-gtk to talk to the X server
<cjwatson> As I sai
<cjwatson> d
 * ogra_ should probably look at the code 
<cjwatson> And there's no configuration in /usr/share/polkit-1/actions/ for it, which I guess would be needed if we wanted to allow that
<ogra_> err, but thats its purpose
<cjwatson> That's what's purpose?
<ogra_> oh, right, you need the policies indeed
<ogra_> its purpose is to act similar to gksu :)
<xnox> nemo_: yeah. Your question is general programming question, nothing to do with ubuntu development. You are better off with stackoverflow website of #vala channel on GIMPnet irc network.
<ogra_> but indeed it needs a policy to allow the subprocess to connect to X
<xnox> nemo_: you can look at packages that build-depend on vala and see how they do it....
<Laney> cjwatson: /usr/share/polkit-1/actions/com.ubuntu.apport.policy allows that
<pitti> cjwatson, gksu: not sure what you mean, but apport started to ship /usr/share/polkit-1/actions/com.ubuntu.apport.policy which has org.freedesktop.policykit.exec.allow_gui==True (therefore allowing X apps)
<stgraber> Daviey: looks like all our current SRUs have landed, so I'm busy with mobile stuff this week but I can do that early next week (I guess we need to SRU to both 12.04 and 12.10 for that one)
<cjwatson> only for root_info_wrapper, AFAICS
<cjwatson> err
<cjwatson> oh, I have an out-of-date version, typical
<nemo_> Ok , thanks.
<pitti> bdmurray added a second one to run apport-gtk
<pitti> as that was blocking the u-n migration to pkexec
<Daviey> stgraber: yeah, that would be good.  Had a few reports of juju+lxc phantom failure.. and this seems to be it.. Thanks!
<cjwatson> right, I just didn't realise I was out of date there
<Laney> ah, and it's only a recommends, indeed
<cjwatson> "com.ubuntu.pkexec.apport-gtk" is a bizarre id for that action
<cjwatson> s/pkexec/apport/ surely?
<pitti> indeed, will fix in trunk
<pitti> com.ubuntu.apport.apport-gtk-root ?
<cjwatson> *shrug*
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starts in 14 minutes in #ubuntu-classrom
<smoser> slangasek, around ?
<smoser> i was looking at bug 1031065, and 'networking' job seems to be blocked because /tmp is not yet mounted (maybe because it is blocked on 'mounted /' ?)
<ubottu> bug 1031065 in cloud-init (Ubuntu Precise) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
<smoser> (this is in precise container).
<diwic> ehm, are the precise daily images (12.04.2) known not to boot, or did I do something stupid?
<roadmr> hey folks, how to access information for a specific error in errors.ubuntu.com? it just loops me in an Ubuntu SSO page
<roadmr> I think I'd need to be in a group but I don't know which one or who to ask to be added
<diwic> roadmr, could it be canonical-ubuntu-platform?
<roadmr> diwic: could be, I'm not a member there
<cjwatson> diwic: not known
<cjwatson> diwic: which image, what architecture / firmware type?
<diwic> cjwatson, precise-desktop-i386.iso
<cjwatson> booting in BIOS mode I presume?
<cjwatson> from CD or USB?
<diwic> cjwatson, from USB, and machine is before UEFI era
<diwic> cjwatson, "ERROR: No configuration file found" "No DEFAULT or UI configuration directive found!" "boot: "
<cjwatson> you used usb-creator?
<diwic> yes
<cjwatson> don't bother, just dd it directly
<diwic> 13.04 usb-creator
<cjwatson> I suspect usb-creator has taken to breaking syslinux again somehow
<cjwatson> but likely to be a usb-creator bug rather than an image bug
<diwic> okay
<diwic> cjwatson, I will try that next, thanks
<davmor2> cjwatson: the sudo -s then  cat x.iso > /dev/sdx is pretty reliable
<diwic> yep, the dd'ed image works better
<bdmurray> psusi: is there a test case for bug 1074606?
<ubottu> bug 1074606 in gparted (Ubuntu Quantal) "gparted identifying incorrect raid arrays" [High,In progress] https://launchpad.net/bugs/1074606
<xnox> barry: I've played a little bit with pyo optimisation on the nexus7. All pyo files in total take about 40MB disk space. There are some memory footprint gains. For example, lenses can save about 100-200 kB. very big stuff like software-center 3MB.
<xnox> barry: (for some lenses, they need to be converted to a wrapper script + module, if currently they are just the script)
<xnox> and also shebang adjustments.
<xnox> barry: Do such gains validate to generate optimised byte-compiles & change shebangs?
<Suudy> Hi.  I'm working on our custom Ubuntu based distribution that we are building from scratch.  As part of our effort to move from 8.04 to 12.04, we've noted that our build setup is incorrectly handling dependencies.  I'm wondering how the Ubuntu team handles the cases of circular dependencies (such as gcc depending upon eglibc, which depends on gcc, etc).
<Suudy> We'd like to be able to have a clean build chain.
<cjwatson> Suudy: We don't have a bootstrap-from-scratch recipe as yet
<cjwatson> Suudy: When we bootstrap a new architecture, we put together chroots based on cross-compiling or partial builds or whatever as appropriate, and build a few stages until we reach a reasonable fixed point
<cjwatson> Suudy: After that, all builds start by unpacking the base chroot and upgrading all packages contained therein to whatever's current in the archive
<cjwatson> Suudy: And the chroots are occasionally upgraded centrally, but that's just for performance's sake
<cjwatson> Suudy: The ability to bootstrap from scratch has some interest to us, but it's mostly academic as we very rarely need to do it
<Suudy> So, for example, if you have in your base chroot a version of eglibc, then you build a newer version of eglibc in that chroot?  Then update the chroot with the newer version?
<cjwatson> Yeah
<Suudy> And you build this chroot using debootstrap?
<cjwatson> The build logs record all the versions of everything involved, so we can go back and reproduce previous state if we have to, but that's almost never actually necessary in practice
<cjwatson> debootstrap --variant=buildd, basically.  (I think it's actually a custom script but --variant=buildd is close enough.)
<Suudy> Sure, sure.  That's what we do.  But debootstrap pulls from some base repo.  In our case, we have a local web server with the base 12.04 release.  Then we build the individual packages.  The problem we have is that we build eglibc.  So depending upon build order, some packages will build against the repo version of eglibc, and after eglibc is built, they will build against the newly built eglibc.  If these versions differ....
<Suudy> So it seems you just make sure your repo is always the same.
<Suudy> er, is up-to-date.
<cjwatson> It's very rare for such differences to matter, and when they do they should be expressed using versioned build-dependencies
<cjwatson> Our archive cycles every half an hour so it updates reasonably quickly, though not instantly
<cjwatson> Bear in mind that we never have to do something like going directly from 8.04 to 12.04 - by definition we've gone through all the intermediate stages
<cjwatson> So that naturally smooths out most of the problems
<cjwatson> In your situation I'd probably build 12.04 once internally, rebuild the binaries against the result, and publish the second build
<barry> xnox: i think they do yes.  esp. -OO which removes docstrings - that should give us a big savings
<Suudy> Well, this is more for bookkeeping purposes.  We want to be able to say that we build what we release.  And if some of the packages are pulled from a repo with 3rd party packages, we can't make that claim.
 * xxiao wonders if he can upgrade windows 95 to windows 8 in one step...
<xnox> barry: *sigh* I did just pyc vs pyo (-O)
<Suudy> Well, we aren't exactly going straight from an 8.04 base distribution to 12.04.  Rather, we have several packages from 8.04 that we are upgrading to 12.04.  We have a custom deboostrap script to assemble the distribution.
<xnox> barry: does pycompile support -OO ?!
 * xnox looks in the source
<barry> xnox: apparently not from the -h
<xnox>     cmd = "/usr/bin/python%s%s -m py_compile -" \
<xnox>         % (version, ' -O' if optimize else '')
<barry> xnox: should be easy to hack in though
<xnox> *sigh*
<barry> yeah
<barry> (and worth getting upstream i think)
<xnox> I think I'll do that next on my train to brussels =)
<barry> xnox: when's that? :)
<xnox> and measure some memory. At least something that doesn't require network.
<xnox> barry: tomorrow morning =)
<barry> cool.  that was the next thing on my list, so maybe i'll work on the patch today
<cjwatson> Suudy: Right, but if you go round a second cycle you should be able to be pretty confident of that.
<cjwatson> Suudy: And certainly keep all your build logs and make sure they record versions of everything (sbuild should take care of that)
<xnox> barry: hmm. ok. But then /etc/python/debian_config needs to support it as well. & pythonX.Y[-minimal] postinst scripts as well. And since there is not .pyoo one will get pyo's which can be one thing or the other.
<barry> xnox: hmm, that's true
<xnox> barry: I mean for memory comparison I can just monkey patch pycompile and be done with it.
<barry> xnox: right.  it would be worth getting those numbers, but i bet they'll be significant
<xnox> barry: also I haven't found and easy way to retrigger python2.7 postinst and all packages post-install re-bytecompilation.
 * barry wonders if we can subvert the pep3147 tags to co-install all optimization flavors
<xnox> I'm sure everyone will be happy! =)
<xnox> so right now I grepped /var/lib/dpkg/info/*.postinst for "py[3]compile -p" & used sed on it to find all the things I can re-bytecompile (including private dirs)
<xnox> i guess if we flip the switch by default, it's not a problem since everything will be correctly compiled on the first time it's installed.
<barry> xnox: i'm not sure we want it on by default.  on plats where it doesn't matter, it's better to use the pycs
<xnox> without docstrings .pyo files should be smaller as well =) so less disk-space penalty.
<barry> xnox: at the cost of introspection
<xnox> barry: well enabling optimised means that _ in addition _ to pyc there is _also_ pyo generated.
<xnox> barry: and we will need to modify shebangs.
<barry> xnox: right, i'm not sure whether we want pyos w/ or w/o docstrings by default
<xnox> barry: so e.g. ipython / python interpreters should use pyc for development style with docsrings.
<xnox> barry: disk penalty seems ok, and every KB counts....... see what small amounts colin was hunting down this week.
<xnox> barry: well =) we can also cross-train to vala developers ;-)
<barry> xnox: yes, for nexus7 definitely.  but i would probably still want docstrings in my pyos on my desktop
<xnox> and QML/Qt
<xnox> barry: why? you will always have them in pyc.
<xnox> (enabling pyo, doesn't remove pyc)
<xnox> also note that nexus7 is your desktop under convergence plan =)))))
 * barry can't wait for his 16gb + 1t nexus 7
<xnox> =)))))))))))
<xnox> 16GB RAM and 1TB SSD? =)
<xnox> nice
<barry> xnox: i'll send you a picture of my weekend soldering hack :)
<xnox> barry: http://images2.wikia.nocookie.net/__cb20090309234128/starwars/images/e/ee/DeathStar2.jpg ?
<barry> xnox: close, but i think they crossed pin 3 with ping 917409239840953023948000109348
<barry> *pin
<xnox> barry: hmm... pin 3 or 4 looks like could be either. but definately with pin 917409239840953023948000109348
<xnox> =)))
<barry> :-D
 * xnox loves your numbers
<psusi> bdmurray: yea, have a raid array present but not described in /etc/mdadm.conf.. the superblocks may say it should be md0, but since it isn't in mdadm.conf, mdadm activates it as md127 instead... the old gparted code thoguht there should be an md0 and erroed because there wasnt
<psusi> bdmurray: also I think this part requires an intel fakeraid or ddf metadata format, but mdadm reports a "container" pseudo array that doesn't actually have a dev node... gparted was picking up on that as if it was supposed to be a real disk as well
<bdmurray> psusi: could you update the bug for sru verification then?
<mlankhorst> doko: looks like libLLVM-3.2.so.1 is installed twice, you need to move it out of usr/lib/llvm3.2/ to usr/lib/arch/ else llvm3.2-dev installs it too
<doko> mlankhorst, it's supposed to be a symlink, afaik
<mlankhorst> doko: I can see the use for a second libLLVM-3.2.so symlink since mesa packaging seems to want it (and doesn't find it now), but a extra copy of libLLVM-3.2.so.1 ?
<doko> mlankhorst, it's supposed to be a symlink, afaik
<doko> so, send a patch
<Suudy> cjwatson:  Sorry, got pulled away from my desk.  Thanks for the info.
<Suudy> cjwatson:  Just one final question.  With regard to the cyclical updates.  You do these incremental builds, each time updating the repo?  So your repo is pretty much a snapshot of the most current builds of at least the base packages (e.g. eglibc, gcc, etc)?
<dobey> barry: hey, do you know if anyone's even bothered trying to use python3-twisted stuff in raring?
<barry> dobey: nope
<barry> dobey: i vaguely remember that being on someone's list for february (not mine tho ;)
<dobey> barry: ah. just wondering. i just tried, and it's horribly unusable :-/
<xnox> =/////
<barry> dobey: oh no.  is it a problem with twisted itself or the packaging, or ...?
<slangasek> smoser: 1031065> is /tmp listed as a separate mount point in /etc/fstab?  If running mountall --verbose, what tag is shown for /tmp?
<xnox> do we have enough on python3-twisted* bits to use it?
<smoser> slangasek, i found the issue
<smoser> (i think)
<dobey> barry: twisted itself. lots more porting work needs to be done it seems. ran into some usage of UserDict still, and zope.interface requires using a @implementer decorator instead of implements() call now
 * barry is aware of that last one :/
<smoser> when run with my full cloud-init patch, i found that the 'cloud-init-container' job was running before /run/network was created.
<dobey> barry: not sure how much work it will be to fix it, but it's > 5 lines at least :)
<barry> dobey: have you communicated these problems upstream?
<barry> (i've been talking w/ some of those guys about our buildbot)
<xnox> slangasek: hmm... what's the difference between local & virtual?
<slangasek> smoser: ah - is that fixable by just having cloud-init-container mkdir -p /run/network?
<smoser> yeah
<slangasek> xnox: isn't it obvious? :)
<smoser> thats what i have.
<smoser> and it seems to work.
<slangasek> smoser: cool
<dobey> barry: not yet, was just trying to run ubuntuone-dev-tools test suite with py3 and hit these issues, while doing other stuff
<slangasek> xnox: local is a filesystem backed by local storage.  virtual is not backed by storage.
<slangasek> by persistent storage, I mean
<slangasek> (it's an in-kernel fs)
<smoser> slangasek, ifquery would exit non-zero and not list network devices if /run/network wasn't there.
<slangasek> smoser: heh, quite
<xnox> slangasek: ok. Funny how /run/user/tdlk/gvfs is local =))))
<smoser> so cloud-init-container.conf would think it had nothing to do.
<dobey> barry: that one bug in the buildbot glyph reported, because it's apparently on 13.04 now instead of 12.10?
<xnox> slangasek: also why does my every boot prints "/tmp is not mounted. Continue to wait or skip...." message?
<smoser> i'm not completly sure why i'd not seen that problem in quantal or raring.
<slangasek> xnox: I don't know, the bug has been reported for some time but I've never reproduced it, please help diagnose :)
 * xnox /tmp is _not_ a separate mountpoint just part of '/' (which is ext4, on top of lvm on top of cryptsetup)
<dobey> xnox, seb128: btw, slangasek said my patch on https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 looked ok, though he didn't try to build/install it. can we move forward with that? it's still not giving me any trouble here :)
<ubottu> Ubuntu bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress]
<slangasek> xnox: /tmp is listed in /lib/init/fstab as a template, so that mountall knows to handle it specially *if* it's listed in /etc/fstab; but mountall ought not be making noise about it unless it really is found in /etc/fstab
<xnox> slangasek: well it definatly started after the upload to make it do all things in parallel or something like that.
<slangasek> xnox: hmm, that may be a timing thing - I know there were other reports of this issue prior to those changes.
<xnox> before - never so that message, after that upload - I always do.
<xnox> shoudl I run upstart & mountall in more verbose modes to get logs?
<slangasek> xnox: bug #1067836 and/or bug #1091792 - I would like to see mountall --verbose output for this
<ubottu> bug 1067836 in mountall (Ubuntu) "Disk drive for /tmp error displayed briefly after Lubuntu PP -> QQ dist-upgrade" [Medium,Confirmed] https://launchpad.net/bugs/1067836
<ubottu> bug 1091792 in mountall (Ubuntu) "The disk drive for /tmp is not ready yet or not present" [Undecided,Confirmed] https://launchpad.net/bugs/1091792
<slangasek> xnox: also your /etc/fstab + /etc/crypttab
<xnox> slangasek: just mountall --verbose now, e.g. in the terminal - or as it's running during boot?
<slangasek> xnox: as for /run/user/tdlk/gvfs being local, that's just mountall saying "I don't care which bucket we put this in, it's not in /etc/fstab so we track that it's present but since it's already mounted it doesn't impact anything"
<slangasek> xnox: during boot
<xnox> ack.
<xnox> slomo: well rebooted like 10 times and I cannot reproduce it when mountall is under --verbose.
<xnox> slangasek: ^
<xnox> slomo: sorry for miss-ping.
<xnox> maybe it needs something else special going on =/
<xnox> infinity: maybe you can get a boot.log when mountall.conf has --verbose in it ?
<slangasek> xnox: hmm.  But it's consistently reproducible when booted without --verbose?
<xnox> not any more =)
<xnox>  /o\
<xnox> I guess booting with --verbose once fixes it =/
<xnox> (brother printers can't print on tuesdays bug?!)
<infinity> It's consistent here (or has been recently), I can try to do some debugging.
<xnox> i can try shutting it down as it usually happens - run out of battery in the middle of sbuild after like 5 days of suspend/resume cycles with a few dist-upgrades in between with ureadahead running & a new kernel etc....................
 * xnox ponders if fsck & ureadahed will actually race this bug or not.
<xxiao> in ubuntu, qemu-ppc64abi32-static, qemu-ppc64-static, qemu-ppc-static, what does ppc64abi32 mean?
<xxiao> 64bit kernel with 32bit user space?
<xxiao> trying to debootstrap a 32bit userspace rootfs for a 64bit ppc kernel here
<xnox> xxiao: $ mk-sbuild --arch powerpc raring
<xnox> and that's it....
<xxiao> will that work for precise?
<xnox> you have a chroot that you can $ schroot -c raring-powerpc -u root     into
<xnox> xxiao: it should.
<xnox> xxiao: if for some reason it doesn't, try mk-sbuild from lp:ubuntu-dev-tools it gained a few features.
<xxiao> let me try it from x86_64 precise
<xnox> xxiao: with that chroot you can also use sbuild to build powerpc packages
<xxiao> never used that, studying...
<xnox> sbuild --arch=powerpc -d raring bla_
<xnox> sbuild --arch=powerpc -d raring bla_1.0-1.dsc
<xnox> should then build a package for you.
<xnox> with latest mk-sbuild you can also cross-build, but I'm not sure how well cross-building would work on precise, as we only did cross-building fixes in raring.
<xnox> infinity: BenC: why did qemu-ppc-static just core dumped on me?
<xnox> debootstrap --second-stage
<xnox> qemu-ppc-static: /build/buildd/qemu-1.3.0+dfsg/linux-user/signal.c:4587: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed.
<xnox> qemu: uncaught target signal 6 (Aborted) - core dumped
<xxiao> xnox: the idea is to bootstrap a 32bit ppc rootfs, then do second-stage, then hopefully build the rest natively
<xnox> xxiao: yeah, sure.
<xnox> xxiao: well you can grab precise powerpc chroot off launchpad.....
<xnox> but then you'll need to add qemu to it.
<xxiao> one challenge i see is to use my own pre-built gcc to build build-essential
<BenC> xxiao: what are you aiming for here?
<xxiao> BenC: i'm trying to load a 32b rootfs to fsl's 64bit e5500/e6500 board
<xnox> hello BenC =) /me hands it over and runs away
<xxiao> xnox: thanks!
<xxiao> BenC: all i have is a yocto rootfs, trying ubuntu precise
<BenC> If you have a yocto, why not create the ubuntu rootfs through there to avoid qemu
<BenC> Also, I can create a raring rootfs from debootstrap if you need me to
<BenC> or quantal or precise, for that matter
<xxiao> i prefer to do any build other than using yocto, which is just too _slowish_
<xxiao> :)
<infinity> There's a powerpc ubuntu-core already.
<BenC> xxiao: Any chance you'll be able to allow other people (*cough*me*cough* access to that e5500/e6500 board?
<xxiao> BenC: i will attend the March meet-up at Oracle, you will see the board there
<infinity> http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<BenC> xxiao: Excellentâ¦just finishing up my travel arrangements for that
<xxiao> we're planning to set up some remote access, so far the board locks up under stress
<BenC> infinity: nifty, I had never known about that before
<infinity> xnox: qemu-ppc-static is known-broken, if I recall.
<xnox> =(
<BenC> xxiao: what kernel are you using? I'd like to get an e5500/e6500 kernel built for ubuntu (might be too late for raring, but who knows)
<xxiao> infinity: how nice...any precise version of that
<xnox> xxiao: sure: http://cdimage.ubuntu.com/ubuntu-core/precise/daily/current/
<xnox> wait...
<xxiao> BenC: shamely it's 3.0.x still, but is upgrading to 3.8.* now
<infinity> xnox: Which doesn't have powerpc, cause I only enabled it in Q...
<infinity> xxiao: There's a quantal one http://cdimage.ubuntu.com/ubuntu-core/releases/quantal/release/
 * xnox !@#@#!!!
<xnox> xxiao: just use quantal one or raring to bring the board up. To get any ubuntu chroot.
<BenC> xxiao, xnox: If I roll out a kernel for that in Ubuntu, would you mind testing it?
<xnox> xxiao: then build the precise one. and switch to it.
<xxiao> BenC: absolutely!
 * BenC suggests raring
<BenC> The QEmu in that supports the KVM stuff in the v3.8 kernel
<xnox> BenC: I have no powerpc kit. I'm the only powerpc-less member of ubuntu foundations team =(
<infinity> Well, it's not like precise will ever have the right installer/kernel support for the board anyway.
<xxiao> xnox: we should enable you with sending you a nice board
<xnox> xxiao: yes, please =)
<infinity> If you're handing out nice boards...
<cnd> smoser, do you know how the azure ubuntu images have been modified to operate on the azure platform?
<cnd> or, who would?
<smoser> utlemming, can tell you more.
<cnd> I may have found what I was looking for here: https://github.com/windows-azure/walinuxagent
<cnd> thanks
<TheLordOfTime> clear
<TheLordOfTime> oops sorry
<TheLordOfTime> was targetting a terminal window, accidentally clicked xchat due to laptop
<TheLordOfTime> :/
<infinity> cnd: There's a bit more than just walinuxagent.
<cnd> infinity: any docs I can look at?
<infinity> cnd: hv-kvp-daemon-init comes to mind too.
<infinity> cnd: Not sure about docs.  utlemming's the man to talk to.  On the other hand, why not just use his images from the Azure gallery?
<cnd> infinity: I'm investigating how to deploy a cloud service on azure
<cnd> the only really documented way it to deploy workers that simply run on windows
<cnd> that sucks in many many ways
<cnd> so I'm trying to figure out more about how the ubuntu image works
<shbk1> hello, does anyone know whether it's possible to look content of /usr/share/misc/magic.mgc in the  understood form?  I need know what magic numbers it uses for detecting files  for program in c++ (which is supposed to work in windows too, and I wouldn't like to use library)
<cjwatson> shbk1: 'apt-get source file' and look at src/magic.*
<cjwatson> (and possibly other nearby files)
<shbk1> in documentation to file is written that it uses database that is hold in magic.mgc. as I understand it takes signatures from there, so source code possibly will not help
<xnox> cnd: to deploy workers on ubuntu cloud images, it is usually preferred to use juju. http://www.ubuntu.com/cloud/orchestration/juju
<shbk1> I check magic.mgc , it looks like it really contatins this information   - http://storage1.static.itmages.com/i/13/0201/h_1359666402_3148352_b5463d55c1.png
<shbk1> if it only were possible to look at it in the understood form
<xnox> cnd: also see #juju channel. It's a tool to right a "charm" which then you can deploy to nodes. The charm will configure the nodes and connect them all up to do stuff.
<xnox> s/right/write/
<cnd> thanks xnox
<xnox> cnd: https://juju.ubuntu.com/ is more developer oriented site.
<xnox> cnd: also askubuntu.com with tag juju is monitored and has a rich knoweledge base.
<cjwatson> shbk1: eh, the entire database is in the source code of 'file' - you mean you're looking for the source of magic.mgc itself?
<shbk1> no, I want to look at database
<cjwatson> right, the source of magic.mgc
<cjwatson> shbk1: it's in the magic/ directory under the directory that 'apt-get source file' gives you
<cjwatson> mainly magic/Magdir/
<cjwatson> <cjwatson@sarantium ~/src/packages/file/file-5.11/magic/Magdir>$ fgrep -il c++ * | xargs
<cjwatson> c-lang fonts gcc msdos msvc vxl
<shbk1> hm, thanks  http://storage2.static.itmages.com/i/13/0201/h_1359667045_7519190_f7637925cf.png   it seems I 'm on the right road already
<shbk1> but where is information about formats like mp3, ogg? http://storage4.static.itmages.com/i/13/0201/h_1359667114_9584312_1027c29b2e.png    Music file contains nothing useful
<stgraber> jdstrand: ?? I'm definitely subscribed to bugs for libseccomp
<scientes> did arm support ever get merged?
<scientes> kees cook posted patches
<scientes> oh i see it did
<scientes> in 3.8
<cjwatson> shbk1: use grep
<cjwatson> shbk1: mp3 is in 'animation', ogg is in 'vorbis'
<cjwatson> shbk1: it'll be easier to use grep than to try to work out the file naming scheme
<kees> scientes: hm? I thought everything was up to date now?
<doko> infinity, do you have any idea about https://launchpad.net/ubuntu/+source/clang/3.2-1~exp5ubuntu1/+build/4254653 ? could that be fs corruption too?
<infinity> doko: Didn't it have the same failure a day or two ago and get retried?
<doko> no, your memory is wrong, old man ...
<infinity>   * Merge with Debian; remaining changes:
<infinity>     - Default to softfp on armel.
<infinity> ^-- There's no reason for us to carry that delta anymore.
<doko> the bug was fixed in llvm-3.2
<infinity> Oh, this is a shiny new failure?  Fair enough. :P
<jdstrand> stgraber: weird. you didn't show up when I looked
<jdstrand> oh, I think I looked at *my* subscriptions for it
<jdstrand> hmm
<Suudy> Hi.  I'm having some trouble getting our custom debootstrap to install some base packages with dpkg.  The problem I'm having is with installing libc6, libgcc1, and libc-bin.
<Suudy> If I do "dpkg -i libgcc1 libc-bin libc6" (with the appropriate paths and trailing information to the debian packages), I get an error about "libgcc1 depends on libc6 (>= 2.2.4); however: Package libc6 is not installed."
<bdmurray> xnox: usb-creator is starting up for me for devices without vendor id 18d1
<Suudy> But if I do "dpkg -i libc6 libgcc1 libc-bin" I get "libc6 depends on libgcc1; however: Package libgcc1 is not installed."
<Suudy> It doesn't seem to matter what order I put the packages, they don't satisfy dependencies.
<Suudy> I could ignore the issue with --force-depends, but it seems kinda fuzzy.
<Suudy> These are 12.04 packages built from source.
<Suudy> There appears to be this circular dependency that dpkg can't resolve.
<sarnold> wb Suudy_, you didn't miss anything while you were gone
<Suudy_> Sorry, got booted by our firewall.
<Suudy_> Ok.  Thanks :)
<infinity> Suudy_: This is in a debootstrap scenario (ie: none of the packages are installed yet)?
<sarnold> (last we saw was "circular depedency that dpkg can't resolve")
<Suudy_> Yep
<infinity> Suudy_: If so, that's expected.  And the answer is "do what debootstrap does".
<Suudy_> :)  If it were that easy.... ;)  The precise debootstrap script isn't the easiest to follow.
<Suudy_> Ok.  I'll muck around some more there.
<infinity> Suudy_: Unpack them with deps forced, then reinstall, is the easiest way to get around it.
<infinity> Suudy_: I could ask why you're not just using debootstrap, since it does the right thing...
<xnox> bdmurray: =/ weird.
<xnox> bdmurray: can you give me lsusb output please? =/
<xnox> (me has updated upstart job in lp:usb-creator branch you could try that to see if that one is better?!)
<Suudy> Damn firewall...corporate pain in the butt.
<xnox> https://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/view/head:/debian/usb-creator-gtk.upstart
<Suudy> We aren't using debootstrap, because we are creating root filesystem for installation on media, and we build everything ourselves.  So essentially, we have our own script that mimics much of debootstrap.
<Suudy> For extraction, we do the 'ar -p <deb> data.tar.gz | tar xzf -', follow that with 'chroot <path> dpkg --force-depends".  But even with the "--force-depends", it complains mightily.
<Suudy> But the stock debootstrap doesn't spew pages of warnings about dependencies, so I thought perhaps there was something wrong with our setup.
<xnox> debootstrap is versatile and it can be used to prepare root filesystem for installation on media.
<xnox> don't reinvent the wheel if you don't have to.
<Suudy> Hmmm....that does get me thinking.
<xnox> create repository, cross-build packages (or use stock from ubuntu), debootstrap, add other bits you need
<xnox> shove it to media. rinse repeat until you can boot.
<xnox> (raring, quantal, debian should not matter)
<Suudy> We build everything, but debootstrap isn't one of those things.  Our build system could build it, then when we make the root filesystem, extract debootstrap to our debootstrapp'd build environment, and invoke it directly.
<xnox> once you booted you can rebuild everything native twice over to finally get the golden image.
<bdmurray> xnox: s/enchanced/enhanced/
<Suudy> Well, we build on a native system (PPC), but we build in a debootstrapp'd environment.
<xnox> Suudy: note the debootstrap --second-stage flag.
<Suudy> :q
<infinity> Suudy_: You can point debootstrap at any apt-alike repository you want, it's not tied to our archive.  You don't even need to build a new version (unless you really need to change it).
<xnox> first stage resolves, download and unpacks (done outside chroot), second-stage is done inside to finish configuring all packages and needs/wants native execution.
<Suudy> Ooops.
<infinity> Suudy_: "debootstrap --variant=minbase raring raring-chroot http://company.internal/ourstuff" would work just fine.
<Suudy> But you need that internal repo, which we'd have to construct on the fly as packages are built.
<infinity> You kinda want that anyway, don't you?
<Suudy> Right now, our build system compiles all the packages, then we install them manually into the chroot using dpkg.
<infinity> If you have all the debs, you have the repo.
<Suudy> Well, install them via a script using dpkg.
<Suudy> Right, but don't we need the Packages, Indices, etc?
<infinity> cd place_with_debs && apt-ftparchive packages .
<infinity> Done.
<infinity> And you can point debootstrap at a file:// URL.
<Suudy> Ah.  Hmm....
<Suudy> Can you custom tailor what packages as part of minbase are installed?  Say we use busybox instead of coreutils?
<infinity> At least, I think it can use a file:// URL.  Would be a glaring misfeature if you couldn't.
<infinity> Suudy_: minbase operates based on package priority/section headers.  If you prefer different things to be Essential/Required/etc, and you're rebuilding them anyway, fix up debian/control to reflect what you want.
<infinity> (Or build a proper apt archive with overrides, but that's far more effort)
<Suudy> Oh, I see.  It parses the debs themselves.  Go it.  We were specifying required, base, etc.
<infinity> It parses the Packages file.
<infinity> But that all comes from the debs (or from archive overrides that override the debs)
<Suudy> Which is generated by apt-ftparchive, right?
<Suudy> cd
<infinity> *nod*
<infinity> Basically, if you look at "apt-cache show coreutils" and "dpkg-deb -I coreutils", you'll notice some shocking similarities.
<infinity> Because the former derives from the latter.
<infinity> And the latter comes from debian/control in the source package.
<infinity> (That dpkg-deb -I was meant to be aimed at a coreutils.deb)
<xnox> Suudy: you can even use a lighter tool dpkg-scanpackages with overrides as needed. Here is a talk about it: http://www.wiggy.net/presentations/2001/DebianWalkThrough/handouts/handouts.html#AEN780
<Suudy> And all deboostrap needs is the Packages file?
<xnox> yeah....
<xnox> Suudy: it's all very lightweight. It has to be. As that's how debian architectures are bootstrapped.....
<xnox> it can verify checksums on the Release and etc. but that is all optional and it should be possible to skip through.
<xnox> infinity: should we finally tell them that debian has http://wiki.debian.org/PowerPCSPEPort for e500v1/v2 ?
<infinity> xnox: This is assuming anyone cares about spe.  I've gotten the impression from Ben that the plan is just to ignore the old cores and move forward with the brave new world.
<infinity> xnox: And default PPC works fine on newer e500ish systems.
<xnox> infinity: I see. well debian also has ppc64 port. But I don't know powerpc chips that well.
 * infinity heads out for a bit.
<bryce> !pilot in
<bryce> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryce
<Suudy> xnox, infinity:  Thanks for the tips.
<TheMuso> [B/c
<Suudy> (Sorry for the disconnects, our corporate firewall doesn't seem to like the web client, and our direct access is blocked)
<Suudy> What about the Release file, with the md5sums of Packages?  dpkg-scanpackages doesn't create that (I presume apt-ftparchive does).  it appears that debootstrap requires this file
<xnox> <xnox> Suudy: it's all very lightweight. It has to be. As that's how debian architectures are bootstrapped.....
<xnox> <xnox> it can verify checksums on the Release and etc. but that is all optional and it should be possible to skip through.
<xnox> but indeed apt-ftparchive can generate the rest of the files if you want
<xnox> Suudy: here is like overly complete apt-ftparchive config http://debian.scribus.net/debian/apt-ftparchive.conf you probably need much shorter one
<Suudy> I'd rather not use apt-ftparchive, since it appears to be overkill.  But it appears that debootstrap looks for the Release file, and I don't see an option to ignore it (though I do see an option to ignore the signature the Release file)
<xxiao> unfamiliar with upstart, i added a ttyS0.conf under init, how can I add it to upstart manually before I can boot off raring-ubuntu-core-rootfs.tgz?
<xxiao> i'm booting over nfs
<xnox> it just should pick it up. it walks /etc/init/*.conf at boot and starts them all event based.
<xxiao> ok. thanks. let me boot it
<cjwatson> Suudy: if I were you I'd write a Release file, rather than going to all the effort to avoid it.  You can use 'apt-ftparchive release' if you don't want to write it by hand or use the full 'apt-ftparchive generate' stuff.
<xnox> https://help.ubuntu.com/community/SerialConsoleHowto if there is any trouble with ttyS0
<xxiao> xnox: that worked
<xnox> =)
<xnox> upstart is great ;-)
<xxiao> now with root as the user, what's the magic password for ubuntu-core
<xxiao> xnox: with upstart can I still bypass it with init=/bin/sh?
<xnox> yeah.
 * xnox thought there are no passwords in ubuntu-core, unless you pre-setup the user with a password yourself.
<xxiao> in this case i need somehow reset a password for root, ttyS0 disallow my login
<cjwatson> xxiao: if you use init=/bin/sh then you aren't using upstart
<cjwatson> upstart is entered by the default value of init= (/sbin/init)
<xxiao> cjwatson: i c, got it, i need /bin/sh to debug sometimes
<xxiao> xnox: it's indeed odd, nfs server showed empty root password, getty keeps asking for it
<xxiao> minigetty has the autlogin option but getty does not have it
<xnox> root + enter, or grab ubuntu core - chroot into it, create user account with sudo:admin groups and then boot that. Then you know that you will have an account with full sudo.
 * xnox typically creates the account in ubuntu-core before booting it.
<xxiao> ok will do that now
#ubuntu-devel 2013-02-01
<mterry> cjwatson, thanks for quick review!  It was too quick.  I tried to put the merge in WIP mode, but you must have reviewed before I did that.  If you'll look at it again, it should be better
<cjwatson> I saw the WIP but thought it might be worth saying anyway
<xxiao> ok works
<xxiao> had to /bin/sh in to passwd then reboot
<mterry> cjwatson, well I had been an idiot and forgot about pkexec stripping DISPLAY.  So I had to redo it altogether after I thought to at least test it  :)  Thankfully synaptic ships a pkexec version now, and I don't think we need to stress about cddistupgrader, assuming the "Suggests" status is appropriate for it
<mterry> In the sense that update-notifier-common merely Suggests gksu
<cjwatson> re-reviewed
<xxiao> hold on...i am inside ubuntu-core as the rootfs over nfs, the thing does not include ifconfig/dhcp then how can I get an ip then do apt-get? is this just for chroot then add stuff?
<sarnold> xxiao: is 'ip' installed?
<cjwatson> ubuntu-core is intended as a base chroot that you add more things to as needed
<xxiao> sarnold: thanks forgot that :) it's there
<xnox> xxiao: https://wiki.ubuntu.com/Core   bring your own bootloader, kernel, configs
<xnox> xxiao: https://wiki.ubuntu.com/Core/InstallationExample
<xxiao> cjwatson: ubuntu-core also works as a standalone rootfs, the only thing I need is to change root passwd for ttyS0 access, now i can apt-get
<cjwatson> xxiao: well, sure, but it's not guaranteed to have things like useful networking :-)
<cjwatson> if you can use it standalone that's a bonus
<xxiao> so far so good, loading stuff to it now
<bryce> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xxiao> BenC: 13.04 rootfs is basically usable, until kvm is needed that is
<BenC> xxiao: How do you mean?
<xxiao> BenC: could not install qemu-kvm
<xxiao> i am installing folsom which pulls in kvm
<xxiao> dumb me, kvm is not enabled in the kernel yet
<infinity> xnox: Both those Debian ports are unfficial for a reason.  They're largely unnecessary, but fun toys.
<infinity> xnox: (Well, and spe is also usually mostly broken, so could never meet the release port criteria)
<pitti> Good morning
<pitti> infinity: want me to mass-copy all the precise langpacks to -updates?
<infinity> pitti: If you think they're as validated as we can manage, go nuts.
<pitti> infinity: they haven't gone through the usual validation cycle of per-language community testing in that short time, of course
<pitti> infinity: we can do that, of course; but at least for the languages on the images we probably want to copy them to reduce size
<infinity> pitti: The images are still building from -proposed currently, I believe.  Though, that should change.
<infinity> Oh, maybe they're not anymore.
<dholbach> good morning
<dholbach> wow, xsensors tell me it's 95Â°C
<mvo> dholbach: hey! does "cat /proc/acpi/ibm/thermal " tell that as well?
<dholbach> mvo, file does not exist :)
<dholbach> but ../fan says "speed: 4485" :)
<mvo> dholbach: :)
<ajmitch> dholbach: I'd say that was a bit warm, but my old laptop was topping out at 105 when it was spamming syslog about throttling power :)
<dholbach> ajmitch, I'm back to 58Â°C already :)
<dholbach> it might have been the two builds which were running :)
<ajmitch> possibly :)
<pitti> "Fetched 14.1 MB in 213503982334601d 6h 0min 40s (0 B/s)" -- go apt!
<pitti> looongest update evar
<pitti> (it really just took some 5 seconds, FTR)
<astraljava> It just felt like 5 seconds, it actually took longer than what the range for time data type allows, and started over from the negative end.
<soren> pitti: wtf? Did ntpdate run in the middle of the apt-get run?
<soren> pitti: Yeah, that adds up. 15 seconds real runtime, a clock that goes an hour backwards and then 64 bit timestamp.
<pitti> soren: perhaps; it was a freshly booted VM
<soren> 213503982334601d 6h 0min 40s is 18446744073709548040 seconds. 2^64 is 18446744073709551616. -
<soren> 18446744073709548040-18446744073709551616 = -3576
<soren> An hour minus 14 seconds backwards.
<pitti> hah, neat
<cjwatson> infinity: I haven't changed them to point to -updates yet; if somebody else has it would be nice if they'd told me ...
<Laney> hmm, I don't think the old gksu u-n caused a root browser to be spawned, did it?
<cjwatson> Laney: a root *browser*?
<Laney> root     10972  7.3  0.4 917900 139716 ?       Sl   10:05   0:01      |           \_ /usr/lib/firefox/firefox https://bugs.launchpad.net/ubuntu/+source/kmod/+filebug/f4e681b0-6c56-11e2-8e58-0025b3df357a?field.title=kmod+assert+failure%3A+modprobe%3A+..%2Ftools%2Fmodprobe.c%3A550%3A+print_action%3A+Assertion+%60kmod_module_get_initstate%28m%29+%3D%3D+KMOD_MODULE_BUILTIN%27+failed.
<cjwatson> bless you
<cjwatson> oh, right, so apport launches firefox ... hmm
<Laney> I wonder why it worked properly when gksuing though
<cjwatson> apport has a thing to look at SUDO_UID
<Laney> I always just got an additional tab in my existing browser session
<Laney> ah, so that's not passed along any more
 * cjwatson wonders if pkexec sets anything usefuPKEXEC_UID=1000
<cjwatson> er, yeah, mangled, but YKWIM
<cjwatson> pitti: would it be reasonable for apport to check PKEXEC_UID as well as SUDO_UID?
<pitti> cjwatson: yes, absolutely; I'll fix that now
<cjwatson> thanks
<cjwatson> Laney: thanks for the report
<Laney> sure
<pitti> yeah, thanks Laney
<Laney> It was a "WTF, where's vimperator?" that tipped me off
<pitti> hm, why don't I get a notification for that in the first place now
<pitti> oh, I do; compiz put apport in the back
<pitti> it seems to do that for new windows now
<ogra> pitti, now ? i have that in precise on my desktop
<pitti> cjwatson, Laney: uploaded, thanks for reporting
<Laney> great, thank you
<shadeslayer> cjwatson: hi, would it be possible to merge a new live-build from debian? alternatively, just apply the patch from here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693250 ?
<ubottu> Debian bug 693250 in live-build "live-build: wrong copy of files from config/archives/repo.pref.chroot" [Normal,Fixed]
<shadeslayer> I've tested the patch and it works for me
<shadeslayer> ( using live-build from raring ofcourse )
<cjwatson> shadeslayer: OK - I'd rather merge than cherry-pick, but not sure I'll quite get to it today
<cjwatson> shadeslayer: but on my to-do list now
<shadeslayer> cjwatson: sure, no problem :)
<shadeslayer> and thanks!
<cjwatson> (we're a bit further behind than I'd realised)
<xxiao> interesting, lunbuntu has ppc version iso
<shadeslayer> yeah, I noticed they released 4.0 O_O
<xxiao> precise 12.04
<shadeslayer> they're like ultra quick
<cjwatson> well, I wouldn't merge from experimental
<Quintasan> Laney: Did you upload maliit-framework to Debian?
<mpt> ev, https://wiki.ubuntu.com/ErrorTracker#settings-developer
<Laney> Quintasan: sure did
<Laney> you can fetch the packages from raring NEW
<Quintasan> Laney: Do you have appropriate powers in Ubuntu to sync the package?
<Laney> I have ALL the powers
<Quintasan> :D
<Quintasan> I'VE GOT THE POWER!
<Quintasan> Laney: Can you sync it then?
 * Laney gyrates
 * Laney hands the mind bleach to anyone reading
<Laney> Quintasan: yeah, when it gets accepted I can
<Quintasan> Laney: Splendid. I'll throw plugins your way when I'm done with them
<Laney> Quintasan: Oh, I uploaded that one too
<Quintasan> Laney: You did that already?
<Laney> but I can reupload any improvements over the top of what's already there
 * Quintasan hides
<Laney> yeah I said in the email
<Quintasan> Well, I'll take a look but I doubt there is anything I can improve there
<Laney> I'm sure there will be :-)
<Quintasan> Ha, it seems like a challenge.
<amitk> /quit/quit
<zyga> cjwatson: do you know if it's possible to use pybuild to generate packages for 12.04+
<cjwatson> zyga: You may have mistaken me for a pybuild expert
<cjwatson> zyga: But, AFAIK, you won't be able to build *on* 12.04/12.10 unless somebody has backported pybuild; however the binary packages that pybuild produces don't in themselves require anything special
<xnox> zyga: the binaries should be usable on 12.04, but pybuild itself is not available on precise, so it will not be able to build there.
<zyga> ah
<zyga> so if my desire is to release a new package of my own library I should be able to build it on raring (the source package), push to a ppa and just copy to other releases?
<xnox> yes
<zyga> will I need to manually modify the changelog per package to get it to co-exist in all systems?
<xnox> only the top version wins, so you'll either have the same binary (and hence the same version number) across all - or you don't use pybuild and upload source package per release
<xnox> (or e.g. use a recipe to do those)
<zyga> hmm
<xnox> zyga: packaging without pybuild is easy and has been done before.
<zyga> I'm _probably_ fine with using the same binary
<xnox> zyga: do you have both python2 and 3 or just one python series?
<zyga> yeah, I know, I just feel annoyed each time I want to package a trivial pure python package
<xnox> %:
<xnox>        dh $@ --with python2
<xnox> done.
<zyga> that has a library (for 2k,3k pythons), maybe a few command line programs (this time none) and some shared data, and docs
<zyga> well, I want py3k too
<xnox> make a second source package
<xnox> %:
<xnox>          dh $@ --with python3
<zyga> what?
<zyga> why two source packages?
<xnox> done and it works across all precise -> raring in PPA.
<zyga> I mean, duplicate debian/ directory or just another entry in control
<infinity> cjwatson: Oh, wait, PROPOSED moved from being an environment twiddle in cron to an etc/config file thing, didn't it?  I live in the past.
<xnox> well sed the top line in changelog, source & package names in control, & python2 -> python3 in debian/rules.
<zyga> xnox: could you show me an exampl?
<infinity> cjwatson: So, yeah, no one switched it, I was just mistakenly looking at crontab. :P
<xnox> zyga: hehe =) or I can just upload pybuild backport into precise & quantal ;-)
<cjwatson> infinity: it's in a couple of places still, I think
<xnox> zyga: I am yet to figure out if pybuild lets me choose what shebang the scripts have (e.g. python2 or 3)
<zyga> xnox: normally I generate scripts with setuptools
<zyga> xnox: IIRC there were parts in dh_python that sed them to be right
<infinity> cjwatson: Well, the two usual suspects, cdimage/etc/config and debian-cd/CONF.sh ... Except, curiously, the latter is commented out.
<infinity> cjwatson: Have we only been half-proposed this whole time? :P
<PrincessLuna> Are the multitouch patches for kernel 3.8 included in the rc5?
<roadmr> ev: how to get access to stack traces on errors.ubuntu.com? (I get stuck in the infamous login loop)
<cjwatson> infinity: oh, I fixed bug 1023991 and forgot about it
<ubottu> bug 1023991 in Ubuntu CD Images "consolidate places needing to be changed to build from PROPOSED" [Medium,Fix released] https://launchpad.net/bugs/1023991
<micahg> zyga: xnox: I'd be happy to process a backport request for pybuild if someone files the request with requestbackport and does the testing
<cjwatson> stgraber fixed most of it, actually
<cjwatson> infinity: I've cleaned up the bit in CONF.sh
<ev> roadmr: you need to be in ~canonical-ubuntu-platform
<cjwatson> infinity: so, I don't know.  my gut feel is that I'd still like a few more things in -updates to avoid impeding verification.
<ev> roadmr: slangasek is working with legal on an NDA for this
<roadmr> ev: I see.. so is it best to wait for that, or is there an interim process, like getting help from someone with access?
<xnox> micahg: I'd like to first test and see that it does everything it says to do on the tin ;-)
<roadmr> ev: I want to look at stack traces for auto-reported checkbox crashes, but I guess it's not urgent, after all there's still plenty of time to fix bugs
<micahg> xnox: please do :)
<infinity> cjwatson: Yeah, I'm in no massive rush to do switch flippery.  It just came up because pitti was chomping at the bit to copy langpacks, not realising we were still building against proposed and, thus, building with the new ones already.
<ev> roadmr: there's no alternative process yet, but I can't imagine it taking much longer. slangasek will be able to say for sure. If it does look like it's some time off, we can add additional teams, but I'd like to run that by elmo if we're going to do it.
<infinity> cjwatson: s/copy/promote/
<roadmr> ev: ok, understood. I'll wait then :) thanks!
<ev> sure thing
<cjwatson> infinity: aye
<slangasek> ev: it's still a ways off, so if there's a pressing need I would suggest working around it
<ev> noted, thanks
 * cjwatson gets down to fifteen remaining Ubuntu deltas in grub2 (and 4300+ lines of changelog diff due to all the "remaining changes" entries)
<cjwatson> I wonder if I can get that to zero for 13.04
<roaksoax> slangasek: howdy!! I ws wondering somthing about the MAAS stuff. So when we continue to include the yui3/raphael libraries within the source, wouldn't there be a conflict when sruing the same upstream version to both quantal and precise, because the source package differs from each other (quantal no yui3 libs, precise will have those libs), as what happens in PPAs?
<roaksoax> s/source package/upstream tarball
<slangasek> roaksoax: you could possibly add the yui3 and raphael bits into the debian packaging rather than the upstream tarball?  that might be easiest
<roaksoax> slangasek: yeah that indeed seems to be the easiest
<bdmurray> pitti: these nexus7 stacktraces don't seem very helpful bug 1112443
<ubottu> bug 1112443 in gnome-control-center (Ubuntu) "gnome-control-center crashed with SIGSEGV in <unavailable> in ??()" [Medium,New] https://launchpad.net/bugs/1112443
<slangasek> that looks like the error I was seeing when first trying to get cross-retracing working
<jtaylor> why does python-imaging have such a weird version number?
<jtaylor> nevermind, says in the changelog
<wjtaylor_> Is ubuntu associated with ubuntuupdates.org? Or is this a 3rd party collecting packages and forming ppas?
<roadmr> wjtaylor_: read here: http://www.ubuntuupdates.org/about
<infinity> ev: Any plans to upload a fixed whoopsie?
#ubuntu-devel 2013-02-02
<slangasek> infinity: fixed wrt what?
<infinity> slangasek: Oh, it's been FTBFS for a while, he has it fixed in bzr, just not uploaded.
<slangasek> infinity: ah
<Niraj_> hi, I am not sure if this is right channel to post packaging related doubts, but can someone help me package bash source for oneiric?
<tjaalton> shouldn't dh pass --datadir automatically?
<tjaalton> the default which is /usr/share
<slangasek> tjaalton: it doesn't pass --datadir by default because the autoconf built-in default is fine
<tjaalton> slangasek: ah, it comes from there.. well for some reason it doesn't seem to work right for sssd, the __init__.py file has "${prefix}" where the .in file had @datadir@
<tjaalton> passing --datadir makes it right, but that shouldn't be necessary
<slangasek> the default value of --datadir is ${prefix}/share
<tjaalton> heh, ok
<slangasek> so that seems like a malformed substitution somewhere
<slangasek> the .py probably needs to be generated from a Makefile instead of directly by autoconf, to get the necessary expansion
<tjaalton> ok, I'll try that
<nn0101> hello!
<nn0101> is anyone aware of lvm+luks setup failing on 12.10?
<nn0101> i dont understand why the option exists during the installation.
<nn0101> i know luks is lvm+luks works because i liveusb'ed it, put passphrase and mounted them successfully.
<nn0101> yet when i boot, my laptop just keeps blanking the screen (as if it's trying to boot off my luks'ed partition but failing to do so because of no passphrase prompt or whatever).
<nn0101> trying these: /boot is unencyrpted, MBR in /dev/sda, /dev/sda5 is LVM+LUKS. would be great if anyone know if this setup worked on theirs.
<trijntje> nn0101: this is probably not the right channel to ask, try #ubuntu
<Niraj_> bump: can someone help me package bash source for oneiric?
<zykes-> how can I build a package in a directory that has a debian folder ?
<ion> debuild -b -us -uc
<GunnarHj> slangasek: ping?
<jtaylor> why was python-imaging changed?
<jtaylor> it breaks a bunch of other packages
<xxiao> BenC: no kvm
<xxiao> somehow i can not send msg to mklinux
<BenC> xxiao: Nick not registered with nickserv?
<xxiao> then why can I msg here
<xxiao> used to work fine
<BenC> xxiao: Are you using qemu-system-ppc64?
<BenC> xxiao: Each channel can forbid unregistered nicks from messaging the channel
<BenC> Perhaps #mklinux does and this channel doesn't force that
<xxiao> hmm but i used to talk on mklinux just fine, will check
<BenC> Any ideas why the buildd's can't install packages (unmet deps) that I am able to install locally (raring)?
<BenC> https://launchpadlibrarian.net/130223052/buildlog_ubuntu-raring-powerpc.haskell-lens_2.4.0.2-2_FAILEDTOBUILD.txt.gz
<BenC> Specifically this
<ev> infinity: ja
<ev> probs monday
<quadrispro> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<quadrispro> bug #1110326 incorrect linking order led to "undefined symbols" errors
<ubottu> bug 1110326 in portmidi (Ubuntu) "portmidi 1:200-0ubuntu1.12.04.1 is broken" [High,Confirmed] https://launchpad.net/bugs/1110326
<quadrispro> I gotta go now, I already uploaded a fix to precise though, I'll work on other releases within few hours
<Quacky2200> Hello
<Quacky2200> is anyone doing ubuntu development at canonical?
<Quacky2200> Does anyone here work at canonical?
<infinity> BenC: Are you taking -proposed into account before you ask that question?
#ubuntu-devel 2013-02-03
<infinity> pitti: Hrm.  It seems like a misfeature that pkgstripfiles removes files from -doc packages.
<infinity> pitti: (In the case I'm looking at, it strips all the upstream changelogs out of glibc-doc)
<infinity> pitti: Opinions?  I'm thinking of just making clean_upstream_changelogs() return if the package is a -doc.
<BenC> infinity: well, I am using -proposedâ¦are the buildd's not?
<infinity> BenC: They are, yes.  You can see in the build logs exactly what it's doing.
<infinity> BenC: And replicating it should be easy.
<BenC> infinity: I ran the exact same apt-get command as in the chroot, and I didn't see the dep problems
<infinity> BenC: Anyhow, haskell in proposed is deep in painful transition land, I wouldn't hold out much hope for any of it moving soon (given that many packages still need upstream fixes)
<infinity> BenC: Then you didn't have the same sources.list and an up-to-date apt-cache.  I can reproduce it trivially here.
<BenC> infinity: I ran it from a pristine chroot with updated raring packages, using an updated cache
<BenC> *up-to-date
<infinity> BenC: Just reproduced here again, to make sure I wasn't crazy.
<infinity> http://paste.ubuntu.com/1603451/
<infinity> Anyhow, like I said, we need to sort out that transition anyway, and this will all fall out of that.
<BenC> Works for meâ¦
<infinity> Not sure what to say. :P
<infinity> Your computer is special?
<BenC> I meant, leaving it alone and letting it all sort itself out "works for me" :)
<infinity> Well, that's kinda the only option right now anyway.
<infinity> Either that, or I remove all of *ghc* *haskell* from proposed.  But I see no reason to not just do the transition, it'll just take some effort (most of which needs to happen in Debian right now).
<quadrispro> hi everybody
<quadrispro> slangasek, bug #1110326 is done now
<ubottu> bug 1110326 in portmidi (Ubuntu Quantal) "portmidi 1:200-0ubuntu1.12.04.1 is broken" [Undecided,New] https://launchpad.net/bugs/1110326
<quadrispro> cheerio
<lifeless> infinity: you've climbed around eglibc before, right? wth is close defined ?
<infinity> lifeless: man 2 close?
<lifeless> infinity: the source, not the header :)
<lifeless> infinity: I've found a stub version, and a hurd version
<lifeless> infinity: I seem incapable of finding the common case version :(
<sarnold> that's my usual experiences with the eglibc sources :/
<lifeless> sarnold: I'm glad I'm not alone.
<mjt> it is a syscall lifeless
<mjt> there's no source for it in glibc
<infinity> ^
<mjt> they do some syscall magic in one go for all syscalls in a generated file
<lifeless> oh; I had assumed it would still need a thunk
<mjt> yeah it does
<mjt> but these are auto-generated
<mjt> i don't know the process. this reminds me of a file named SYSCALLS somewhere in the sources
<lifeless> ./sysdeps/generic/sys/syscall.h perhaps
<lifeless> mjt: thank you, tells me what I needed anyhow ;)
<infinity> lifeless: Well, more likely to be in linux sysdeps (or arch-specific), but...
<infinity> close           -       close           Ci:i    __libc_close    __close close
<infinity> Actually, sysdeps/unix/syscalls.list for the simple ones like close()
<lifeless> infinity: thanks!
 * lifeless is now grabbing linux source...
<sarnold> aha, thanks :)
<lifeless> I'm digging into why close(1) blocks when doing dd to a block device.
<infinity> lifeless: Standard answer.
<lifeless> infinity: whats that ?
<infinity> lifeless: "Because it hates you" was the implied answer (other answers are even less CoC friendly). :P
<lifeless> infinity: ah! naturally.
<infinity> lifeless: But in all seriousness, happy hunting.  That's getting too close to the vfs layer for my liking.  There's a reason I sit firmly on this side of syscalls. :)
<lifeless> infinity: hah :). So, you'll love it when I say 'and then I need to establish behaviour with iscsi in the mix
<infinity> lifeless: I suspect you'll find that, short of fundamental constraints imposed by VFS features and/or bugs, behaviour like what you're looking at may be entirely filesystem-specific.
<infinity> lifeless: So you may be better off starting with iscsi and working backward.
<infinity> lifeless: But ymmv, maybe blocking close is a fundamental vfs assumption.
<lifeless> infinity: well, there is no fs in play
<infinity> Oh, right, block device.
<lifeless> infinity: I need to understand both local behaviour, and the behaviour with tgtd etc
<infinity> Well, one layer lower, then.  Fun.
<lifeless> so that I can decide how to ensure The Right Thing happens.
<infinity> Sounds like a fantastic learning experience for someone who's not me.  Enjoy. :P
<lifeless> infinity: it is actually.
<mjt> if you want to know why dd blocks this way, do a kernel stack dump first
<mjt> if strace tells you it is in close, that'll be in kernel not in glibc
<infinity> (My usual response to kernel questions is "whine at a kernel engineer")
<lifeless> mjt: can you do that without rebooting ?
<mjt> even for a non-kernel-engineer it might be sometimes enlightening, since the stack sometimes show functions which suggest something.  Somethingh like, "wait_on_alloc_pages"
<lifeless> mjt: sorry, s/rebootiong/rebuilding/
<mjt> lifeless: echo t > /proc/sysrq_trigger  and see your dmesg (kern.log) -- search the hung dd pid in there
<mjt> (it will generate a ton of info, trace of all running tasks!)
<lifeless> thank
<lifeless> interestingly, while I had a blkid task caught by 'hung for > 120s' that didn't seem to catch the dd; perhaps 1G isn't enough to block that long.
<mjt> and if you don't understand what's in there, -- this is the basic info any kernel engineer will ask you about, so if you include that stack trace right away it'll save you a roundtrip
<mjt> wait.
<mjt> you dd sleeping on close -- close of the file you just wrote?
<mjt> huge file?
<lifeless> mjt: block device
<mjt> the same thing
<mjt> is it the thing to which you just wrote a ton of gigs of data?
<lifeless> specifically, dd of=/dev/sdb1 ...
<lifeless> and yes.
<mjt> so it is kinda expected it blocks
<lifeless> close is blocking until nr_writeback hits 0
<mjt> yeah
<lifeless> mjt: why? No fsync/fdatasync/sync calls.
<mjt> well. this is grey area indeed. but it is the only way to know if the writes succeeds or not.
<mjt> much better way to write to block devices is to use of=direct
<mjt> er
<mjt> oflag=direct
<mjt> and a reasonable blocksize (say, bs=1M)
<mjt> this way write will be smooth, it wont affect the rest of the system, it wont trash your block cache
<mjt> and it will be significantly faster too
<lifeless> mjt: well, yes, and on the initiating machine I will be doing that.
<lifeless> mjt: but I'm mainly trying to establish all the parameters righ tnow
<lifeless> mjt: the bigger picture goal is to ship a GB or so from machine A to a block device on machine B, as fast as the network will handle it, without waiting for it to hit disk - and then for machine B to validate the data itself one way or another, flush to disk and reboot.
<StevenK> lifeless: nc ?
<lifeless> mjt: currently using iscsi for that, but I'm suspecting a userspace process on the target is better suited
<lifeless> as it can orchestrate things more directly
<lifeless> StevenK: indeed
<lifeless> StevenK: I inherited the current code.
<lifeless> mjt: would nonblocking cause close to not block (but not arbitrarily cancel any of the IO ?)
<infinity> StevenK: Heh.  It never ceases to amaze me the number of useful things one can abuse a concept as simple as nc for.
<StevenK> I would have thought ISCSI would be a little heavy handed, TBH.
<mjt> lifeless: just try it
<lifeless> StevenK: you can also use rsync with the block device patch, but it doesn't scale to Big Disks, which some folk mighy use.
<StevenK> infinity: Haha. nc is wonderful, I find myself reaching for it more
<mjt> lifeless: but still, direct i/o is way to go there, since it will be faster than using buffer cache
<lifeless> mjt: heh - so I can; the main concern is knowing what the guarantees are, not the 'what happens when I try'
<StevenK> lifeless: nc and tar? Nice, simple and fast?
<lifeless> mjt: our network is faster than the target hard disk, buffer cache is a big win :)
<infinity> StevenK: *nod*... It's very classic UNIX in it's simple tool that can be slotted into thousands of usecases.
<lifeless> mjt: [for the whole story]
<mjt> lifeless: and your app on node B will validate what? content of buffer cache?
<lifeless> mjt: so, ideally O_DIRECT on the source machine avoids buffering there, but we want buffer cache on the target.
<lifeless> mjt: do a sync, then O_DIRECT read of the partition I think.
<mjt> and how is the size of data compared with the amount of RAM on B?
<lifeless> mjt: tiny fraction
<mjt> will whole thing fit in ram?
<lifeless> mjt: typical cases are 500M->1G data, RAM is - well, lots more than that, I can't say more :)
<mjt> speaking of guarantees, -- as i said it is a grey area already even without O_NONBLOCK
<mjt> and may depend on the underlying stack, i dunno
<lifeless> yeah, thus my climbing through source rather than simply asking the lazyweb : though I sure do appreciate the info you have shared.
<mjt> (i didn't know close(block device) waits till writes are complete, until now)
<mjt> and this is definitely in kernel. not glibc :)
<mjt> lifeless: btw, how your source disk speed compared with the target disk speed? :)
<lifeless> mjt: don't care, source will be cached.
<mjt> with O_DIRECT?
<lifeless> mjt: O_DIRECT on writes, not reads; oflag=direct
<mjt> ok. count me officially confused. ;)
<mjt> so it looks like the only thing you need is to stop close() from blocking. that's kernel question.
<lifeless> mjt: indeed
<lifeless> mjt: well, I need to get the behaviour when iscsi is in the picture pinned down.
<lifeless> mjt: but thats just a matter of time :)
<lifeless> mjt: infinity: for your interest;
<lifeless> with tgtd serving out a block device, and dd to that via a regular iscsiadm connection
<lifeless> oflag=direct has minimal impact on performance, either way the close() at the end waits for all data to have traversed the network. but it does not wait for it to hit disk at the far end - it buffers quite happily.
<lifeless> oflag=direct does of course avoid wasting the senders buffer cache
<lifeless> this is without the sync or direct flags set in tgtd
<lifeless> could do that, but it would actually be counter what we want... which is to clear the network as quickly as possible - we wouldn't be able to tell when dd finished vs when teh disk finished.
<lifeless> so I'll need to do something fugly on the far end to tell (or switch to nc :))
<lifeless> StevenK: ^
<Quintasan> hello
<tomreyn> hi
<tomreyn> is it possible, as an upstream, to get access to apport submitted error reports for packages in ubuntu? if so, what's the process?
<Elbrus> tomreyn: in principle, anybody can subscribe to a package
<Elbrus> in launchpad, go to the bugs in the package
<Elbrus> click link "subscribe to bug mail"
<tomreyn> Elbrus: i don't think bug reports still get created for apport submissions
<tomreyn> Elbrus: i'm referring to crash logs
<Elbrus> tomreyn: sorry, didn't know that
<Elbrus> I thought they did
<tomreyn> it feels like canonical wants more information to be internal only now than in the past.
<tomreyn> of course this can be just an architectural change and this information which used to be publically accessible just has not yet been made accessible again (about a year after the change took place), or i just lack the knowledge on how to access it.
<penguin42> https://errors.ubuntu.com/  has teh stats but none of the detail
<stgraber> tomreyn: the new workflow is essentially: crash => upload to errors.ubuntu.com => when we notice it happens often => file a public bug report and link it
<stgraber> tomreyn: so fixes will still be linked to bug reports, but we won't have bug reports with thousands of duplicates anymore
<penguin42> stgraber: I think tomreyn's original question was what happens to an upstream if they're interested in watching for bugs on their package
<stgraber> tomreyn: for privacy reason the details of the crashes on errors.ubuntu.com are currently restricted to Canonical employees but I believe this is being worked on so that other people may access those provided they sign an NDA
<stgraber> penguin42: upstreams should monitor Launchpad. Any frequent crasher will be forwarded there once we know for sure it's a bug.
<penguin42> stgraber: Yeh that's a bit restricting for them, but I can understand the privacy stuff to want to filter peoples coredump stuff - but backtraces without the data should be safe
<tomreyn> inded, we would never sign an SDA. we would, however, be quite happy to have access to any data which can be made available without endandering the submitters' privacy.
<tomreyn> and i believe this is very much automatable.
<stgraber> penguin42: they are most of the time, the problem is that they aren't 100% of the time. We can't know that every single piece of software in the archive won't show user credentials in an exception for example
<tomreyn> sure, it does take a bit of time, but not too much
<stgraber> tomreyn: then what you want to look at is Launchpad, because that's where we forward those crashes after they've been looked at and cleaned up
<tomreyn> s/SDA/NDA/
<penguin42> stgraber: You could show purely the sequence of symbols/offsets in the backtrace with NO data
<tomreyn> right. and that's appreciated. from my experience the process of reviewing crash logs could take anywhere between a day and a year when they were public, so, if the situation is the same now (but I would assume it is worse since fewer people will likely have access to these, so fewer reviewers, too), i'm not sure whether this is worth too much for upstreams.
<stgraber> penguin42: true, rendering the backtrace mostly useless in the process (at least in python, which we happen to have a lot of, the actual exception text is what's most relevant, the problem is, it's also the bit that can contain any string including exposing potential private information)
<tomreyn> do you have statistics on this?
<tomreyn> to not be misunderstood, i do understand how the users' privacy must come first, and I actually appreciate this.
<penguin42> stgraber: Ah, I'm more of a C person, just the symbol stuff would often be useful there
 * tomreyn seconds penguin42 
<stgraber> penguin42: right, C should be fairly easy to automatically forward, just retrace, send the backtrace and don't attach the core
<penguin42> stgraber: Yeh, possibly missing out the parameter data
<tomreyn> stgraber: are you in a position to stifle a discussion on this internally? if so, this would be great for us and many, many other free software projects in Ubuntu.
<penguin42> I don't think stifle is the required op here
<tomreyn> whoops, right, i meant trigger :)
<tomreyn> sorry, not an english native speaker here
<penguin42> tomreyn: start
<tomreyn> sounds good
<stgraber> tomreyn: well, the right people have been highlighted above and I'm sure they'll see that discussion, so that's pretty much done. Generally, we definitely want more people to have access to that data, but we need to process step by step, the first and easiest one appears to be the NDA for those who're fine with that, and hopefully finding ways of exposing relevant data without any user data at a later point
<tomreyn> It's good to know that the relevant people will be aware now how this is a strong nice-to-have for open source developers now. I can see how an NDA can seem the most logical solution for a business which deals with other businesses or organisations. I would bet, however, that signing an NDA is not an option for a large share, possibly the majority, of those who develop the software which forms Ubuntu.
<tomreyn> So if Canonical wants to get a step closer to the free / open source software community again without risking anything on the other and and investing very little this could be a good way.
<penguin42> agreed
<tomreyn> (and something one could blog about)
#ubuntu-devel 2014-01-27
<Noskcaj> Since requestsync keeps breaking, can someone sync gthumb?
<Noskcaj> I fixed the existing delta in the latest upload, and it's only exp because of debian's gtk3.10
<pitti> jtaylor: I enabled doko's PPA which sets the default to 3.4 (https://launchpad.net/~ubuntu-toolchain-r/+archive/python3)
<pitti> dobey: FTR, apport is reporting to LP again in trusty; I'll look at the MarkForUpload bug today
<pitti> Good morning
<pitti> cjwatson: is it still true that "Packages in
<pitti>       the base system may not use bzip2"
<pitti> ?
<pitti> cjwatson: (from libpng's merge changelog)
<cjwatson> pitti: I'd prefer to keep that; the problem is that it limits the use of debootstrap to bootstrap Ubuntu on non-Debian/Ubuntu systems
<pitti> cjwatson: ok, thanks; so we'll keep that (the other delta is gone now, that's why I asked)
<pitti> cjwatson: and, early for you!
<cjwatson> pitti: also, it breaks debootstrap in d-i (which could be fixed by reconfiguring busybox, but we'd still run into the above)
<cjwatson> pitti: about to get a train to the core sprint in London
<cjwatson> so injecting coffee ..
<pitti> cjwatson: ah right
<pitti> wgrant: do you know why https://launchpad.net/debian/+source/bzr-upload still hasn't picked up 1.1.0-4? It got uploaded to sid two days ago
<mitya57> xpdf/experimental from 2 days ago also isn't picked up for some reason
<pitti> same for cups; it looks like autoimport is generally not working?
<mitya57> pitti: Does bug 1273075 break some packages? (If yes, then I probably should apply it in Debian as well)
<ubottu> bug 1273075 in sphinx (Ubuntu) "Copying html_logo file over improperly checks for file basename instead of relative name" [Undecided,Fix committed] https://launchpad.net/bugs/1273075
<pitti> mitya57: autopilot AFAIK (that's why I backported the fix, on veeber's request)
<pitti> mitya57: it's just a backport from upstream, so it'll get into Debian sooner or later anyway; but of course feel free to backport it as well
<mitya57> Then it's not urgently needed in Debian :)
<pitti> mitya57: yes, that's what I thought
<dholbach> good morning
<dholbach> Laney, happy birthday!
 * Laney hugs dholbach 
<wgrant> pitti, mitya57-mobile: I think our internal Debian mirror is out of date. Will investigate once IS appears.
 * dholbach hugs Laney back
<pitti> wgrant: ah, thanks
<slangasek> RAOF: looking at libgusb merge, I see you've added DEB_BUILD_MAINT_OPTIONS = hardening=+all; is there a particular reason to have this delta here?  +all only adds PIE and -Wl,-z,now, neither of which is relevant for a library AFAIK
<Laney> hmm
<Laney> Is there a path back to fixed image builds? Robert's intention wasn't to bring unity-control-center onto them yet - AFAIK, everything has alternates & the idea is/was to switch the seeds at some point.
<Laney> But it looks like having unity-control-center as the primary dep/recommends of things is causing it to be chosen
<cjwatson> Laney: explicitly seeding the old one for now might fix things
<Laney> cjwatson: it is
<Laney> I don't see it in the germinate output though so it looks as if the package relationships are being resolved first
<cjwatson> how about gnome-control-center-datetime?
<Laney> nope
<cjwatson> explicitly seeding that (and uploading ubuntu-meta) might help
<cjwatson> since unity-control-center-datetime is being pulled in by indicator-datetime per germinate
<Laney> yep, I see that
<Laney> worth a try
<Laney> this is a ppc64elfest
<arges> doko: hi. Do you mind if I take on the sudo merge?
<doko> arges, not at all
<arges> doko: : ) cool
<Laney> cjwatson: looks like that worked
<cjwatson> Laney: great
<Laney> the mysterious inner workings of OMG I just found a hidden creme egg
<mitya57> wgrant: import seems working now, thanks!
<wgrant> mitya57: Ah yes, sorry, fixed it to use a different mirror
<wgrant> pitti: ^^
<Mirv> could I get a core-dev to look at this packaging change before uploading http://pastebin.ubuntu.com/6826135/ . background at https://code.launchpad.net/~timo-jyrinki/qml-friends/fix_qt52_ftbfs_adding_dependencies/+merge/203012
<Mirv> I could reproduce the failing build's error message on device, but I didn't find other explanation than that the dependency resolving is complex. that is, friends-facebook already depends on account-plugin-facebook, but only when adding those dependencies explicitly PPA builder got happy.
<Mirv> similarly I needed to apt-get install account-plugin-facebook first on the device before friends-facebook was happy to install.
<Mirv> what I'd need is an ack (or not) to proceed with uploading that change via cu2d.
<highvoltage> 5
<pitti> wgrant: splendid, thakn you!
<pitti> wgrant: syncpackage now crashes differently, but at least it got further
<pitti> ubuntutools.archive.DownloadError: Signature on bzr-upload_1.1.0-4.dsc could not be verified
<pitti> wgrant: I'll try again in a bit, supposedly it needs some time to catch up?
<smoser> hm.. anyone have an idea here?
<smoser> i've got a python program (cloud-init) that runs early in boot.  I'm trying to wait a reaasonable amount of time for a http resource to appear (120 seconds).
<smoser> it does that by setting the timeout (default 50 seconds), and then if it times out, adding that to a counter and checking that that counter is < 120 seconds and then trying again if so
<smoser> the issue I think is that ntp is kicking in and setting the clock after first reading of the conter
<smoser> of the clock
<smoser> (i read the clock with time.time())
<smoser> so in summary the issue is that reading the clock with 'time.time()', waiting some time, then reading the clock again with 'time.time()'. ends up with time going backwards.
<smoser> i could use /proc/uptime for my time reading. but is there any way in python that would be safe to the clock being set backwards ?
<arges> infinity: can you take a look at http://people.canonical.com/~arges/sudo/sudo_debian.debdiff
<cjwatson> smoser: use python >= 3.3 and you can use time.clock_gettime(time.CLOCK_MONOTONIC) or something along those lines
<smoser> yeah. i got that same answer in #python cjwatson.
<smoser> thanks.
<cjwatson> (there might be better ways, that's just the first that comes to mind)
<infinity> arges: Did you test that that LDFLAGS bit was actually still necessary before merging it into a different makefile target?
<arges> infinity: no I'll test if that is still necessary
<infinity> arges: Oh, nevermind, I now see what it's doing.  Yeah, it's necessary.
<infinity> arges: But if there are any new targets, they'd all need it added.  I hope you checked for that.
<arges> infinity: yea so the libcommon target was renamed to libsudo_util (found in the changelog)
<infinity> arges: Kay.
<arges> infinity: that's the only target 'change' and I made sure the LDFLAGS addition was there
<infinity> arges: As a nit pick, I'd clean up the mess that MoM made of the Debian changelog at the tail end there.  Not that you did that, it's probably been like that for years.
<infinity> arges: I'll review the rest of the merge in a bit.  I need some not-so-fresh air.
<arges> infinity: ok.
<arges> ok changlog cruft fixed
<Laney> Mirv: how can that problem be reproduced?
<shadeslayer> dpm: ping
<Logan__> infinity: please look at netcdf :)
<wgrant> pitti: Hm, shouldn't be any delay. Can you recheck now?
<pitti> wgrant: I synced it successfully some 15 mins ago now
<seb128> wgrant, hey
<wgrant> seb128: Hi
<wgrant> pitti: Great
<seb128> wgrant, is there any chance you could have a look to https://bugs.launchpad.net/launchpad/+bug/1260754 ? by then you said it should fix itself once the initial import queue was dealt with, but that didn't seem to happen
<ubottu> Ubuntu bug 1260754 in Launchpad itself "Translation not imported from source to launchpad" [Undecided,New]
<wgrant> seb128: Do you have an example that hasn't imported in the last couple of weeks?
<seb128> wgrant, gtk+3.0 got an upload since, https://launchpad.net/ubuntu/+source/gtk+3.0/3.10.6-0ubuntu3
<seb128> but that's more tahn "couple of weeks"
<seb128> I can do another upload if you think that's worth trying
<wgrant> seb128: Hum, will have a look soonish
<wgrant> Thanks
<shadeslayer> dpm: would be nice to get https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 merged soon
<seb128> wgrant, thank you
<cjwatson> tseliot: http://people.canonical.com/~ubuntu-archive/pending-sru.html is still looking kinda nasty for nvidia ...?
<tseliot> cjwatson: bug #1268027 is not really a regression and we should stop the bot from claiming that verification failed. Speaking of bug #1076414, that should not affect my packages in proposed any more because nvidia-settings will be the only package of its kind. As for bug #1222670, my packages in proposed fix it
<ubottu> bug 1268027 in nvidia-settings (Ubuntu) "nvidia-settings crashes on exit" [Medium,Incomplete] https://launchpad.net/bugs/1268027
<ubottu> bug 1076414 in nvidia-settings-updates (Ubuntu) "Transitioning between nvidia drivers (updates, 304, 310) results in install failure due to conflicting nvidia-settings" [High,Invalid] https://launchpad.net/bugs/1076414
<ubottu> bug 1222670 in nvidia-graphics-drivers-319 (Ubuntu Precise) "[nVidia GTX645][10de:11c4] Unable to boot to desktop with nvidia-319 driver" [High,Triaged] https://launchpad.net/bugs/1222670
<cjwatson> bdmurray: ^- can you help tseliot with pacifying the bot?
<tseliot> cjwatson: I also uploaded a new jockey for bug #1259237 but if you approve bug #1272311, you'll get that for free
<ubottu> bug 1259237 in bbswitch (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
<ubottu> bug 1272311 in jockey (Ubuntu Precise) "Add support for AMD Kaveri graphics chipsets" [High,In progress] https://launchpad.net/bugs/1272311
<cjwatson> tseliot: it's *really* tight for 12.04.4.  is it absolutely critical for that?
<cjwatson> the only way I can get new uploads in in time at this point is to waive the waiting period.
<tseliot> cjwatson: it's for hardware enablement and I think we need the code to be in 12.04.4 for our images
<cjwatson> tseliot: I think we at least need to get the existing bbswitch in first before superseding it?
<cjwatson> oh, it doesn't include bbswitch, hmm
<tseliot> :)
<slangasek> ogasawara, bdmurray, infinity: update-manager released to quantal; upgrades will now go straight from 12.10 to 13.10
<ogasawara> slangasek: ack, thanks
<arges> infinity: here's an update: http://people.canonical.com/~arges/sudo/debian_sudo.debdiff
<vlad_starkov> Copy-pasted from #ubuntu-kernel:
<vlad_starkov> I probably found a bug in some module. Can't boot Ubuntu Server on my machine. It raises CPU soft lockup errors all the time. The system even can't boot.
<vlad_starkov> I tried to boot from grml USB flash, and it does almost all the same. But when I tried to boot grml with 'noudev' boot option, the grml has booted just fine and htop shows me all my 8 CPU cores with 0-2% load.
<vlad_starkov> What does 'noudev' boot option in my case?
<slangasek> vlad_starkov: it's not a standard kernel boot option, the definition of it would be specific to grml
<vlad_starkov> slangasek: hmm
<cjwatson> bdmurray: bug 1259237
<ubottu> bug 1259237 in bbswitch (Ubuntu Precise) "Hybrid graphics enablement in 12.04.4" [Medium,In progress] https://launchpad.net/bugs/1259237
<tseliot> cjwatson: oh, and I think
<slangasek> vlad_starkov: the most obvious guess, however, is that it doesn't launch udev and let udev load drivers
<tseliot> cjwatson: bug #1262238 is required too
<ubottu> bug 1262238 in fglrx-installer-updates (Ubuntu Precise) "[SRU] Add support for the lts-saucy stack" [Medium,In progress] https://launchpad.net/bugs/1262238
<cjwatson> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1259237/comments/11 has instructions for you on what to do ... did you try following thenm?
<cjwatson> *them
<tseliot> right, let me do that
<vlad_starkov> slangasek: It seems like reasonable explanation of what is 'noudev'.
<zul> mterry:  ping i subscribed the server team oslo.rootwrap to the bugs can we get it MIRed now
<vlad_starkov> slangasek: is there anything like 'noudev' for Ubuntu Server?
<mterry> zul, OK, thanks!
<mterry> zul, will do a pass after lunch
<zul> mterry:  cool thanks
<vlad_starkov> slangasek: "grml noudev                disable startup of udev (disables module loading)"
<dpm> shadeslayer, yeah, I had no success pinging danilo at the time, but perhaps dobey can have a look at it? (https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112)
<slangasek> vlad_starkov: no, there's nothing like that for Ubuntu; it's not a case we would support, so it would only be useful for debugging
<vlad_starkov> slangasek: What would be the right strategy to find the buggy module and disable it?
<slangasek> not sure, honestly
<slangasek> #ubuntu-kernel may have ideas
<vlad_starkov> slangasek: there are no answers for the moment on #ubuntu-kernel
<pitti> stgraber: autopkgtest email notification is currently broken (ev is on it AFAIK), so relaying: lxc fails its autopkgtest, thus held in -proposed
<ev> retoaded: ^ I thought this was fixed?
<retoaded> ev, that is part of the smtp-lab.canonical.com time out issue
<stgraber> pitti: yeah, I know, it's the lab's fault, I pushed a force-badtest to the hints branch
<jibel> pitti, stgraber forced it because test fails due to networking issues and he ran them successfully in an adt environment outside if the lab
<stgraber> pitti: juju blew up for unknown reason, jibel is looking into that, lxc failed because of broken network in the lab and some of the debootstrap calls failing
<stgraber> both succeeded when run on my own jenkins+buildd so I'm just blaming the lab and forcing stuff through until that's resolved
<ev> retoaded: I thought James just checked it was working?
<jibel> stgraber, and of course when I try the copy succeeds http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-juju-core/ARCH=i386,label=adt/39/console
<stgraber> jibel: hehe, of course :)
<retoaded> ev, James checked that the server was up and working but not the connectivity from the lab to it.
<jibel> same arch, same host, same base VM
<ev> retoaded: can you pursue this and keep pitti in the loop?
<retoaded> ev, ack
<doko> barry, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+builds?build_text=&build_state=failed
<doko> barry, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
<jtaylor> barry: numpy followup, should fix pandas build: https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream-20140124/+merge/203159
<YokoZar> Is "new" queue processing anyone in particular's responsibility?
<rbasak> YokoZar: The ubuntu-archive team. See: https://launchpad.net/~ubuntu-archive
<jtaylor> does ppc64 work with qemu?
<vlad_starkov> BUG detected http://paste.ubuntu.com/6828163/
<Logan_> I feel like I missed the DMB meeting. That's sad.
 * Logan_ checks logs.
<Logan_> Looks like Noskcaj was confused. He put himself on the agenda. :P
<Logan_> infinity: Did you take a look at netcdf yet?
<RAOF> slangasek: Should be fine to drop, that was probably just "shouldn't break anything" leftovers from convincing me that the no-fortify-functions was indeed a false-positive.
<juliank> Logan_: Logan__: I still find the autoreconf bug reporting in Debian a bit unfortunate. We now have a usertag   "User: debian-devel@lists.debian.org" "Usertags: autoreconf". It would be nice if you could set them on the bugs you report.
<juliank> Possibly manual using the bts tool after you received confirmation from the bts
<Logan_> juliank: Yeah, I plan on doing that in batch retroactively to all of my autoreconf bugs. I just haven't had the time so far to get them all in a list.
<Logan_> I'll do that ASAP, though.
<Logan_> Right now I'm forwarding some more that I did the other day.
<juliank> Logan_: OK, thanks, I just wanted to let you know in case doko did not tell you
<Logan_> Yeah, he let me know. I've been delinquent in actually doing it. :P
<juliank> Logan_: If you do not have a list already, bts status $(bts select submitter:logan@ubuntu.com) fields:bug_num,subject | grep -B1 '^subject.*dh-autoreconf' | awk '/^bug_num/ {print $2}'  gives you one
<Logan_> Brilliant. That'll make my life a lot easier.
<juliank> Right, you can then just build your usertagging email (or bts command, but email building is easier) by looping over the numbers.
<Logan_> Smart. I'll do that tonight.
<Logan_> Is there a limit for one email?
<juliank> I don't know.
<juliank> None you should hit, I think
<Logan_> I guess we'll find out. :)
<Logan_> Heh, you'll be surprised at how many I've filed.
<Logan_> Or maybe you won't, since you apparently get pinged every time. :P
<juliank> Yes, if I am on IRC I get pinged. And I know you filed about 180 bugs
<juliank> at least the dh-autoreconf ones.
<Logan_> Oh wow.
<juliank> The other ones are not interesting.
<Logan_> I'll try to spice them up then.
<juliank> If you want to go crazy, this should generate the entire email: echo "user debian-devel@lists.debian.org"; for bug in $(bts status $(bts select submitter:logan@ubuntu.com) fields:bug_num,subject | grep -B1 '^subject.*dh-autoreconf' | awk '/^bug_num/ {print $2}'); do echo "usertag $bug autoreconf"; done; echo "thanks"
<Logan_> I'm not exactly a bash expert, so I was probably going to ask you for a command to generate the email anyway. :P
<juliank> You just need to send the output of this command to control@b.d.o
<Logan_> I'll do that tonight so I'm sure to pull in the bugs I file today.
<Logan_> juliank: Is there any way to make it so that it excludes the ones that already have that tag? :P
<juliank> You could select the ones with a tag and then calculate the differences of those sets, but I'd not do that in bash anymore, but rather in Python, as it gets to ugly otherwise.
<juliank> But retagging does not hurt, so no real need to worry.
<juliank> People do not even get a notification for usertags IIRC
<Logan_> Okay, sweet.
<juliank> None of your bugs were tagged yet anyway.
<juliank> http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=logan@ubuntu.com;users=debian-devel@lists.debian.org;tag=autoreconf is empty
<Logan_> True.
<Logan_> I'll fix that. :P
<juliank> This website should give you a list of all untagged bugs mentioning dh-autoreconf in the subject: http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Adh-autoreconf;submitter=logan%40ubuntu.com;exclude=tags%3Aautoreconf;users=debian-devel@lists.debian.org
<juliank> In case the script happens to miss something, you can see it there.
<Logan_> Thanks so much for your help!
<Logan_> Actually, I'll run it now.
<juliank> No problem, it's midnight here anyway, so there's not much else to do.
<juliank> Well, OK, sleeping would be an option. But this here is more interesting
<Logan_> juliank: So the user command doesn't need the bugs after it as well?
<juliank> The user command sets the user, and then each usertag command tags a single bug.
<juliank> for the last set user
<Logan_> Okay.
<Logan_> Sent.
<Logan_> Prepare for BTS downtime, lol.
<juliank> Seems to have worked.
<juliank> Apart from vanessa-socket (736891)
<Logan_> Awesome.
<Logan_> Yeah, I just filed that one.
<slangasek> RAOF: okey-dokey; have dropped it
#ubuntu-devel 2014-01-28
<Logan_> cjwatson: Is there any way I could help out with the backlog in ~ubuntu-archive?
<pitti> Good morning
<pitti> stgraber: thanks for the heads-up
<dholbach> good morning
<dpm> hi jamesh, around for a quick chat on mediascanner 2.0?
<dpm> morning dholbach!
<jamesh> dpm: sure.
<dpm> cool, thanks :)
<dholbach> hey dpm
<jamesh> dpm: is there anything in particular you want to know about it?
<dpm> jamesh, on your e-mail you said the QML bindings are blocking on feedback. Are you waiting for someone's feedback in particular? Can we provide that feedback from the Music app side of things to unblock them?
<jamesh> dpm: I was waiting on Victor, but if anyone else on the project has ideas of what's needed, that would be great.
<dpm> jamesh, ok, cool, I'll ping him with a reminder. Do you have a bug to track this feedback, or would just e-mail work?
<jamesh> dpm: we were just using email, but I can set up a bug report if that'd be easier
<jamesh> we're at https://launchpad.net/mediascanner2 now, due to some issues with handling packaging of multiple lines of development from a single LP project
<dpm> jamesh, yeah, if you don't mind, a bug would be useful, so that we can have a single place to track it. I'll then ask Victor to comment on it.
<jamesh> looks like I don't have permission to turn on bug reporting for the mediascanner2 project.  Hopefully sil2100 can help with that when he's online later
<dpm> ack. Are you setting the project for bugs and filing the bug report, or do you want me to file it?
<dpm> ah, ok
<dpm> let me see if I can find someone who's online with the right permissions
<Unit193> mvo: Here?
<infinity> Logan__: Not yet, I'll try to get to it todat.
<infinity> Logan__: Or today.
<dpm> jamesh, lp:mediascanner2 is now set up for bug reporting. Would you mind reporting the bug about QML bindings feedback and then we'll take it from there?
<Laney> life would be better if offlineimap didn't hang at least once every two days
<pitti> Laney: wow, I've been using it for years, I never had that (or any problem really)
<Laney> how do you run it?
<pitti> $ offlineimap
<pitti> nothing fancy
<pitti> with .offlineimaprc http://paste.ubuntu.com/6831043/
<Laney> oh, something else does the SSHing for you
<pitti> Laney: yes, preauthtunnel; best thing ever
<pitti> no password for imap
<Laney> I don't know about that!
<pitti> passwords are so "eek"
<Laney> I could certainly use that for my personal acct, wonder about the work one
 * Laney notes it down
<pitti> Laney: I'm still one of these old farts who reject to use gmail and have @ubuntu.com etc. forwarded to my own server
<Laney> yeah I host my own too
<jamesh> dpm: bug filed here: https://bugs.launchpad.net/mediascanner2/+bug/1273625
<ubottu> Error: Could not gather data from Ubuntu for bug #1273625 (https://launchpad.net/bugs/1273625). The error has been logged
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
<doko> http://qa.ubuntuwire.com/ftbfs/
<doko> http://qa.ubuntuwire.org/ftbfs/ppc64el.html
<doko> http://qa.ubuntuwire.org/ftbfs/arm64.html
<doko> http://people.canonical.com/~ubuntu-archive/
<slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<slangasek> yay, url time on IRC ;)
<dpm> jamesh, thanks!
<seb128> slangasek, I was about to say :p
<slangasek> seb128: sorry, we're in a room with the CTS team at the moment and teaching them all +1 maintenance :-)
<seb128> slangasek, I see ;-)
<Unit193> seb128: Sorry if I come off sounding short.
<doko> slangasek, desktop doesn't know the concept of +1 maintenance anymore ;p
<seb128> doko, no, looking a build issues, transitions, etc is just something included in our daily workflow ;-)
<cjwatson> tseliot: fglrx-xpress/precise-proposed - looks like amd-xconfig should be in a clean target somewhere, since there are mostly-duplicate files amd-xconfig and amd-xconfig.in
<tseliot> cjwatson: true but I like to regenerate it for testing using the test_amd_xconfig script
<cjwatson> tseliot: right, but it shouldn't be in the source package
<cjwatson> (I accepted it anyway)
<seb128> Unit193, no worry, it's weird that apt-get upgrade wants to install old Recommends for you that you didn't want to install/removed in the past, are you sure it's not a new recommends/a one time thing?
<seb128> Unit193, and it seems pavucontrol should just be listed an alternative recommends there if it's one of the options in the code
<Unit193> seb128: I'd presume you won't add pavucontrol first in the list, which I get.  That option sounds fine to me, it'll end up doing the same thing since I already have that.
<seb128> Unit193, right, the most common usecase is listed first, but as you said, it shouldn't be an issue if you have one of the options
<ogra_> package libc6-amd64 is not ready for configuration  cannot configure (current status `half-installed')
<ogra_> GRMBL
<ogra_> infinity, !
<Unit193> In that case I'll remove my proposal as it isn't as good as adding pavucontrol.
<seb128> Unit193, your call, or update it to add pavucontrol as an alternative if you can
<Unit193> seb128: Just thought of that, since it'll update.  Might want to review since it's quite late and brain no work well now.
<tseliot> cjwatson: thanks
<seb128> Unit193, ok
<Unit193> Thanks for taking a look.
<bluesabre> Unit193: at this point, the term is "early"
<bluesabre> :D
<Unit193> bluesabre: Shhh, you stinker.
<knome> hey seb128, do you have by any chance time to look at bug 1207493 again? we should have a correct debdiff and all there now
<ubottu> bug 1207493 in xubuntu-docs (Ubuntu Precise) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Fix committed] https://launchpad.net/bugs/1207493
<mitya57> barry: by django changes, you mean https://github.com/django/django/commit/e1d18b9d2e8ac2 ?
<mitya57> I am asking because there is also https://bitbucket.org/birkenfeld/sphinx/commits/ce0b17bcd7c9, let me know if you need that as well.
<seb128> knome, sure, adding that to my todo for this afternoon
<slangasek> hallyn: bug #1273654
<ubottu> bug 1273654 in qemu (Ubuntu) "qemu-arm64-static binfmt registration for non-existent binary" [Undecided,New] https://launchpad.net/bugs/1273654
<hallyn> slangasek: thanks
<barry> mitya57: right.  i looked at both the django and sphinx ones.  the sphinx one is just a workaround for the django bug, which is the real problem.  the sphinx patch isn't enough (i added another fix which does make it work, but i'd rather fix django properly instead)
<xnox> seb128: please review & approve https://code.launchpad.net/~ted/upstart-app-launch/application-task/+merge/202768
<xnox> seb128: it's a fix proposed by slangasek
<seb128> xnox, why me? ;-)
<xnox> seb128: you happen to have the right permissions on lp.
<seb128> xnox, you don't have access to the status?
<seb128> k
<xnox> seb128: i'm not PS enough.
<Laney> fauxww
<seb128> xnox, that's ok young padawan, did it for you
<slangasek> hallyn: XS-Debian-Vcs-Git
<xnox> seb128: i want to join ~indicator-applet-developers
<slangasek> seb128: ubuntu-core-dev wants to join ~indicator-applet-developers ;)
<Laney> that's a nice idea
<seb128> slangasek, you would have to ask an admin of that team I guess
<Laney> talk to an admin :P
<seb128> seems like you want ted
<mitya57> barry: OK, so I assume nothing is needed from me
<barry> mitya57: not unless you know where the dmpt branch actually lives :)
<mitya57> I think someone just forgot to update the SVN
<barry> i suspect the package has been uploaded without updating the branch
<barry> mitya57: exactly... :(
<mitya57> Do it yourself then :)
 * barry grumbles
<barry> mitya57: yeah, i'll probably do that when i've verified the patch actually fixes the problem
<mdeslaur> wgrant: congrats!
<hallyn> slangasek: actually, is a version check actually needed?  The only way a user would have a qemu-aarch64 binfmt file is from the 1.6 version(s) which had qemu-user-aarch64;  so postinst could just unconditionally remove it?
<slangasek> hallyn: debatable in this case, but in general you don't want maintainer scripts to re-apply changes more than once on upgrade that may clobber local changes the admin has made
<slangasek> hallyn: patch sent to the bug, anyway :)
<hallyn> thanks
<doko> seb128, could you do another merge of poppler from experimental?
<doko> or maybe package 0.25.1 if it's not a development series
<seb128> doko, it's a dev serie (and they often change sonames there)
<seb128> doko, what change do you need from experimental? we just merged on them
<doko> seb128, there are several ftbfs currently (cvs, gdb-doc, etc, ) which go away when I switch poppler and texlive-bin to the debian versions
<didrocks> xnox: https://code.launchpad.net/~autopilot/autopilot/1.4
<didrocks> slangasek: FYI (done) ^
<seb128> doko, we have the same version than debian experimental (upstream version) and our packaging diff is small, do you have specifics on those ftbfses?
<slangasek> didrocks: ta
<didrocks> yw
<seb128> doko, note that the new poppler got uploaded this week and is trusty-proposed atm (libreoffice needs to migrate with it and some other things like calligra didn't got rebuilt yet)
<doko> seb128, we have 0.24.3 , experimental 0.24.5
<seb128> doko, https://launchpad.net/ubuntu/+source/poppler/0.24.5-0ubuntu1 ?
<doko> ahh
<seb128> doko, there was a soname change in 0.24.5 and transition is ongoing ( Sweetsha1k needs to fix libreoffice)
<doko> seb128, so it looks like all the ftbfs like cvs, gdb-doc are caused by the new poppler
<seb128> doko, do you have a build log showing the error?
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html
<doko> seb128, only show on i386, goes away when building poppler with -O0
<seb128> "fun"
<seb128> toolchain issue?
<pitti> stgraber: hey, how are you?
<doko> seb128, are there any poppler tests?
<pitti> stgraber: do you have any idea how to achieve the "lxc-wait for a time when it's safe to interact with the container" without using runlevels or extra init scripts in the template?
<seb128> doko, the srcdir has some but not a lot
<pitti> stgraber: i. e. is it possible to poll from the outside, like repeatedly trying to run a command like "runlevel" from e. g. adt-virt-lxc?
<seb128> doko, you want a smaller testcase/reproducer? maybe tsdgeos can help you, he's upstream for poppler
<pitti> stgraber: that would be much easier than the ridiculous "sudo readlink /var/lib/lxc/.." hacks that adt-virt-lxc does ATM
<pitti> stgraber: AFAIUI, lxc-execute starts a new container; is there a counterpart for "run command in a running container"?
<doko> seb128, sure, that would be nice. so problem seems to occur when the @ sign is encoded itself in an texinfo file
<wgrant> pitti: lxc-attach?
<pitti> wgrant: oh, thanks!
<wgrant> I think it's relatively new
<wgrant> But very handy
<slangasek> yep, it's newish
<pitti> rbasak: so instead of this mad /var/lib/lxc/ poking, why don't we just run lxc-attach until the runlevel switches to 2?
<slangasek> I think it requires newish kernel support, in particular
<pitti> ah, so not something you could use in saucy or precise?
<slangasek> it's in saucy, I don't know if it works on precise
<slangasek> hallyn: ^^?
<pitti> ah
<pitti> well, good enough
<pitti> the lxc runner is fairly new anyway
<pitti> rbasak: FYI, I filed bug 1273725 to remind me
<ubottu> bug 1273725 in autopkgtest (Ubuntu) "simplify adt-virt-lxc startup checks" [Undecided,New] https://launchpad.net/bugs/1273725
<hallyn> slangasek: does not work with the precise kernel.  works fine with the saucy backported kernel on precise
<hallyn> pitti: ^
<pitti> hallyn: thanks
<mitya57> doko: I see webkit in your rebuild logs, I think it can be deleted as it has been renamed to webkitgtk.
<doko> mitya57, maybe file a bug report and subscribe ubuntu-archive?
<Laney> it's done
<Laney> I asked about it last week or so
<mitya57> bug 1261721
<ubottu> bug 1261721 in webkit (Ubuntu) "RM: webkit -- ROM; renamed to webkitgtk" [Undecided,Confirmed] https://launchpad.net/bugs/1261721
<Laney> they declined to process it, just ignore
<doko> mitya57, https://launchpadlibrarian.net/163863694/buildlog_ubuntu-trusty-i386.python-django_1.6.1-1_FAILEDTOBUILD.txt.gz
<doko> with the current sphinx
<mitya57> doko: barry if fixing that
<doko> ahh, good to know
<barry> mitya57, doko will be uploading that fix to debian
<mitya57> doko?
<mitya57> I think he is not going to do that if he asked me...
<doko> didrocks, https://launchpadlibrarian.net/163915490/buildlog_ubuntu-trusty-i386.oneconf_0.3.5_FAILEDTOBUILD.txt.gz  b-d's should be on -all-dev
<doko> kenvandine, https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5524030
<kenvandine> doko, interesting failure... i'll fix it
<seb128> doko, I think you should ping barry for oneconf, he's buggy since the python3 port and didrocks said he has no free slot to look at it (barry did the port by then)
<infinity> YokoZar: Ugh, I didn't notice the epoch on the wine packages before I accepted them.  Haven't accepted the binaries yet, though.  Do we really need to introduce that just to smooth over a PPA version?
<doko> seb128, kenvandine: you may want to look at other failures in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140127-trusty.html  not yet announced, main stillre building
<Laney> what's special about this test build?
<seb128> infinity, did you ever get at the bottom of that ubuntu-wallpapers/dh_install/find/\' in filenames issue?
<doko> Laney, python3.4 is the default, nothing else is special
<infinity> seb128: I got distracted by some other things, but I've not completely forgotten about it.
<seb128> infinity, ok, so I consider that you still "own" it ;-)
<Laney> pwn
<infinity> seb128: Yeah, I'm fine with that for now.  Unless you have some bright ideas.
<seb128> infinity, it's easy enough to workaround by escaping the ' in the .install
<seb128> but then people are going to forget about the issue and it's not going to be fixed
<seb128> otherwise no, no clever idea about what changed that creates the issue
<barry> seb128: i keep trying to find cycles to look at oneconf but they always seem to get eaten up before i can do it.  at least i still have a tab open on the bug ;/
<seb128> barry, ok
<doko> seb128, I'm tempted to blame poppler ... I can reproduce this with the 4.7 toolchain, both linaro and fsf, and fsf 4.8. on both armhf and i386. need to find a machine to check on powerpc too. but this looks like a 32bit issue in poppler
<seb128> doko, ok, and it just started with .5? e.g if you rebuild .3 on current trusty it works fine?
<doko> no, maybe earlier
<jhenke> hi, is there anybody I can ping to take a closer look at bug #1272664 ? the bug is either in the grub installer or efibootmgr and breaks usage of ubuntu on hyper-v gen2
<ubottu> bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [Undecided,New] https://launchpad.net/bugs/1272664
<doko> seb128, hmm, not seen in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140108-trusty.html
<seb128> doko, http://cgit.freedesktop.org/poppler/poppler/log/?h=poppler-0.24 ... there is like 10 commits between those poppler versions
<seb128> doko, do you have a small testcase?
<doko> seb128, no, not directly. try to build gdb-doc
<doko> or iproute2
<seb128> that's not a small testcase
<seb128> k
<seb128> well, I guess first trying with the trusty version of poppler (e.g not the proposed one) rebuild would be useful
<seb128> then if that works there is like a 10 commits diff, shouldn't be too difficult to find which one created the issue
<seb128> I can have a look, but that's not going to be for today
<doko> seb128, now filed #1273779
<seb128> doko, thanks
<seb128> doko, do you know if it happens in Debian as well?
<doko> seb128, only checked the poppler version in nustable, and I can't reproduce it
<seb128> doko, ok
<stgraber> pitti: you could poll using "lxc-attach -n <container> -- runlevel" or something like that
<pitti> stgraber: right, that's what I came up with; thanks!
<dobey> mardy, kenvandine: hey, is there any work on supporting google hosted apps accounts in online-accounts? (in a way that is easy to differentiate them from standard google accounts, if it already "works")
<pitti> $ sudo lxc-start -n nosuchcontainer
<pitti> lxc-start: Executing '/sbin/init' with no configuration file may crash the host
<pitti> stgraber: ^ want a bug, or known issue?
<pitti> stgraber: (it's at least confusing)
<stgraber> pitti: the error message seems right to me
<stgraber> pitti: a container doesn't need to exist in /var/lib/lxc to work
<stgraber> pitti: you could pass parameters using -f or multiple -s without having it in the lxcpath
<pitti> oh, I didn't know that
<pitti> but I didn't give -f or any other option
<jtaylor> nice py3.4b2 -> py3.4b3 regresses doc strings
 * Logan_ waves to Noskcaj.
<Noskcaj> hey Logan
<Logan_> Noskcaj: I saw the logs from the DMB meeting. You seemed confused. :P
<Noskcaj> I'm currently stuck with no internet and overslept the meeting. So things could be better
<Noskcaj> i'd only had 4 hours sleep before the meeting, so that would be why
<Logan_> :/
<Noskcaj> Logan_, The darktable merge should be done now
<Logan_> yes master
<Noskcaj> ;)
<Noskcaj> Now if applying for MOTU by email would unbreak
<qengho> kees: I saw your post about "-fstack-protector-strong". Looks really promising. I'm also interested in "-fPIE -pie" as default, at least for 64-bit archs. I wonder if there are any valid objections any more.
<jtaylor> does -pie finally not mess up shared libraries now?
 * qengho doesn't know.
<jtaylor> in that if you add it to dpkg-buildflags for lib + binary package like asterisk it ftbfs
<qengho> I'll test.
<jtaylor> you'll have to remove the hardening wrapper first, its still useful for this case
<mardy> dobey: hi!
<dobey> hi mardy
<mardy> dobey: Google Apps accounts do work, just write the e-mail address and keep the password field empty
<mardy> dobey: at least, they were working last time I tried :-)
<dobey> mardy: is there any way to differentiate them from normal google accounts?
<dobey> parse the e-mail address?
<mardy> dobey: mmm... what differentation would you like to see?
<mardy> dobey: yes, we do that, and use the email address as display name for the account
<dobey> mardy: how to know that an account is for an ubuntu.com google apps thing, for example
<mardy> dobey: are you in Ubuntu Touch or on the desktop?
<dobey> mardy: my workstation. but it's more of a general question.
<mardy> dobey: so, you are saying that after creating an account, you don't see the email address under it, in the account list?
<mardy> dobey: I've to quit now, but if that's so, please file a bug; something might hav broken recently
<dobey> mardy: no, i'm asking if technically there is a way to programatically determine if an account is related to a specific apps for domains, domain
<YokoZar> infinity: ~20% of users were on PPA last I looked, so I'd say yes.
#ubuntu-devel 2014-01-29
<infinity> YokoZar: That's rather unfortunate. :/
<YokoZar> infinity: I find it unfortunate we've both missed the opportunity to make an epoch fail pun.
<hyperair> w 1
<hyperair> whoops
<pitti> Good morning
<pitti> stgraber: is lxc-* eventually supposed to work as user? ATM it only creates some files in ~/.local/share/lxc/ and then fails to chown them
<pitti> stgraber: per-user containers sounds cool, is the isolation robust/strong enough by now to allow that?
<dholbach> good morning
<darkxst> Laney, can you add me to desktop-extras while you work on the ubuntu GNOME packageset?
<Sweetshark> wgrant infinity cjwatson: any hints of what went wrong here: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2/+build/5530899 ?
<Sweetshark> "failed to build", no log, happened multiple times to me in recent days.
<wgrant> Sweetshark: Let me see
<wgrant> That usually means that your build is evil enough to kill the builder, but there were some issues witha buildd upgrade yesterday that might be relevant.
<seb128> wgrant, that's libreoffice you are talking about, what could go wrong ;-)
<wgrant> Yeah, that was an upgrade issue. Retry should work.
<wgrant> seb128: I wasn't going to say that, but yes :)
<Sweetshark> wgrant: of course my builds are evil enough to kill builders. but usually they are in a good mood and spare them.
<wgrant> Sometimes!
<seb128> wgrant, oh, btw, I uploaded a new gtk yesterday, translations got imported this time, https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports
<Sweetshark> wgrant: well a builder that shows up with to little discspace had it coming for him. That builder has nobody to blame but himself.
<seb128> wgrant, should I just close the launchpad bug I had open?
<wgrant> seb128: Unless you see it again, yeah
<seb128> wgrant, ok, doing that then
<wgrant> Thanks
<Laney> darkxst: righto
<stgraber> pitti: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
<pitti> stgraber: bonjour -- oh, you are in London, I presume?
<stgraber> pitti: and to answer your question, yes, it's safe because no code is actually running as root at all, well, except for a minimal setuid binary to setup the network device on the host (as the user isn't allowed to add a new device to the host)
<stgraber> pitti: I am indeed, core sprint
<pitti> stgraber: ver nice!
<shadeslayer> dpm: any news on the intltool MR?
<seb128> shrug, doko
<seb128> that "build poppler with -O0 is wrong"
<seb128> that "build poppler with -O0" is wrong
<dpm> shadeslayer, not really, no. I'd suggest pinging danilo and dobey
<shadeslayer> dobey: ping pign
<shadeslayer> *ping
<seb128> stgraber, can you get doko on IRC? ;-)
<stgraber> seb128: there you go ^
<seb128> stgraber, thanks
<seb128> doko, hey, is poppler blocking anything? why do we need to jump on a workaround, making our pdf rendering slower, rather than fixing the issue,
<seb128> ?
<seb128> doko, I started looking at the issue yesterday, why can't it wait a day for us to fix it?
<doko> seb128, yes, it is blocking sensible results from the test rebuild
<pitti> could we perhaps put the -O0 poppler into the test rebuild PPA only?
<seb128> right, I was going to say
<doko> pitti, why?
<doko> to hide the issue?
<seb128> doko, because that's a workaround
<seb128> you are hidding the issue by using -O0
<seb128> making our pdf rendering slower on the way
<pitti> doko: well, -O0 is obviously not a solution, that hides the issue as well
<doko> now at least the rebuild did uncover a missing -fPIC
<pitti> it was just an idea
<seb128> doko, how did the rebuild uncover things when poppler isn't built/published yet?
<Laney> build failure
<seb128> https://launchpad.net/ubuntu/+source/poppler/0.24.5-0ubuntu2
<seb128> it ftfbs
<seb128> well done doko
<doko> seb128, you didn't listen. it happens with both versions
<seb128> what changed?
<seb128> poppler built some days ago
<doko> pitti: yesterday I spent a day trying to make some progress with this issue. just to have to hear that "Not sure that's a poppler issue" without any futher evidence
<seb128> doko, I tried to build gdb-doc in a trusty fresh pbuilder without proposed yesterday evening and I hit the same build issue
<seb128> doko, you said the issue was new to the new poppler
<seb128> so I'm not sure I understand your description of the issue anymore
<seb128> doko, please revert the -O0 hack in the archive, we need to fix that bug properly
<darkxst> Laney, thanks
<Laney> yw
<doko> seb128, no. the bug affects everything which is newly uploaded
<seb128> doko, what bug are we talking about? the poppler/tex one? or the fPIC thing?
<seb128> sorry I'm slightly confused
<doko> seb128, better spend some time why the Poppler-0.18.o is built without either -fPIC nor -fPIE
<seb128> doko, what makes me say it's not poppler is that https://launchpadlibrarian.net/162010028/buildlog_ubuntu-trusty-i386.gdb-doc_7.6.1-1_UPLOADING.txt.gz
<seb128> doko, that package used to build and it fails now in trusty with the exact same version
<seb128> same binaries, there was no rebuild in between
<seb128> libpoppler43 i386 0.24.3-0ubuntu12
<doko> your analysis is flawed. take a step back and calm down please
<seb128> how is it flawed?
<seb128> poppler 0.24.3-0ubuntu12 on jan 08, gdb-doc built fine
<seb128> poppler 0.24.3-0ubuntu12 on jan 28, gdb-doc fails to build
<seb128> (tested in a fresh pbuilder yesterday as said)
<seb128> how can it be poppler creating tex issues if poppler didn't change?
<seb128> doko, ?
<slangasek> seb128: is this not related to the poppler in trusty-proposed?
<seb128> slangasek, no, as said to doko twice, I get the same issue rebuilding gdb-doc using a trusty fresh pbuilder without proposed
<whandi> hey
<slangasek> seb128: ah
<seb128> slangasek, using 0.24.3-0ubuntu12 which was used in the success rebuilds from jan 08
 * slangasek nods
<seb128> slangasek, doko: that fPIC issue with today rebuild looks like it's probably a new issue due to gobject-instrospection (that got updated yesterday in trusty)
<seb128> not a poppler bug imho, I fail to see how the -O0 hack would have lead to that
<seb128> shrug
<seb128> slangasek, please talk to doko, jumping on such hacks isn't helping us, we should fix the real issue with tex and not try to workaround build doing poppler -O0 rebuild hacks
<seb128> that's just hiding issue and leaving us with performance regressions and hacks to clean up later
<slangasek> right, I think that's clear
<seb128> thanks
<pitti> seb128: g-i is stuck in -proposed due to a transient amd64 VM failure; I take it I should NOT retry this for now, to keep it in -proposed until this is examined?
<Fudge> hey guys, when I accidently hit enter on a tv show I am watching in Nautilus, it spawns a second movie player. Is that behaviour intentional?\
<pitti> seb128: (I mean the failed umockdev autopkgtest on amd64)
<seb128> pitti, well, I'm just random guessing there
<seb128> pitti, but that seems a likely candidate, since the fPIC issue happens in g-i commands and the same poppler built less a week ago
<pitti> seb128: ok; let's leave it in -proposed for now, it's not urgent
<seb128> pitti, I doubt -O2 -> -O0 is creating that issue
<seb128> pitti, danke
<pitti> right, but I thought there were two different ones
<seb128> "different ones"?
<seb128> we have tex issues, that doko is blaming poppler for, he uploaded a poppler rebuild using -O0 to workaround those
<pitti> I mean the missing -fPIC is unrelated to the -O0 bug (whatever that is, I didn't look into logs)
<seb128> that rebuild is failing now though because of the g-i fPIC thing on arm*
<seb128> right
<ypwong> zyga, hi, is there any plan to update command-not-found? I'd like to see bug 1029204 fixed in trusty
<ubottu> bug 1029204 in command-not-found (Ubuntu) "locale.Error: unsupported locale setting" [High,Fix committed] https://launchpad.net/bugs/1029204
<seb128> doko, slangasek: Unpacking texlive-latex-recommended (2013.20131219-1) over (2013.20140123-1) ...
<seb128> doko, that downgrade fixes the gdb-doc build in a trusty pbuilder for me
<zyga> ypwong: hey
<zyga> ypwong: hmm, that's a *very* good question
<zyga> ypwong: I'm okay with fixing trunk, I have no upload rights
<zyga> ypwong: and the project doesn't have releases upstream that get packaged, it was all handled by mvo before he left
<zyga> ypwong: I'd like to work together to fix issues somehow, just not sure how
<ypwong> zyga, ah ok, I think we could use some help from ubuntu developers here?
<zyga> ypwong: indeed, I'm just unsure how
<zyga> ypwong: one thing that could be done is a entirely new upstream release
<zyga> ypwong: before it was all somehow fluid, without real releases
<pitti> this is a native package, there's not really another upstream
<zyga> pitti: but I have no rights to upload it
<zyga> pitti: what would be your recommendation?
<pitti> Vcs-Bzr: doesn't exist any more either, so I suppose that tag should be dropped
<zyga> pitti: I was thinking about making it non-native
<pitti> zyga: err, why?
<seb128> pitti, you can unblock the g-i update, turned out that the poppler ftbfs was because the -O0 hack from doko was buggy and nuked the hardening flags from the build
<zyga> pitti: just because I know that workflow better, I might propose it to debian
<zyga> pitti: and really handle the software, not the distribution part
<pitti> zyga: c-n-f is also in Debian
<pitti> but it's still a native package
<zyga> pitti: the same one or different?
<pitti> (but Debian's is much older)
<pitti>  command-not-found | 0.3ubuntu8    | trusty         | source, all
<zyga> pitti: I see
<pitti>  command-not-found | 0.2.38-1 | sid     | source, all
<zyga> (well suse has c-n-f but entirely different (just named the same)
<zyga> 0
<zyga> )
<ypwong> debian one has not been updated since 2009..
<zyga> one problem is that it's really tied to the archive so whoever really maintains it needs to have a loop that rebuilds the hint database basically, every week, and uploads on any change
<pitti> zyga: so I recommend branching off UDD, updating it, and proposing a merge, so that it'll go via the sponsoring queue
<pitti> yeah, and it should be updated for trusty, too; I suppose that there's some command in it to do it
<zyga> pitti: it's non-trivial, I had several failed attempts to rewrite it entirely to make it easier to maintain but I never had enough time
<slangasek> seb128: right - though even though it was the tex upgrade that triggered the regression... how could rebuilding poppler with -O0 work around a tex bug?  The root bug must be in poppler or the compiler anyway, because a -O0 rebuild doesn't change any of the library interfaces
<seb128> slangasek, right, -O0 working says compiler bug to me
<slangasek> seb128: indeterminate; it could be either a compiler bug or a poppler bug
<seb128> slangasek, right, in any case it's not a bug in the new poppler
<slangasek> correct
<seb128> it's already there in the 0.24.3 binaries
<ogra_> is anyone else getting a "Connection Refused" error from upload.ubuntu.com when dputting ?
<Laney> it's being upgraded, see #ubuntu-release
<ogra_> Laney, yup, #is told me
<zyga> hmm, I'm trying to link to a copyright file on packages.ubuntu.com
<zyga> specifically to http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.3/python3.3_3.3.1-1ubuntu5.2/python3.3.copyright
<zyga> but it seems that all copyright files are 404
<zyga> is this expected?
<zyga> similar link works fine on packages.debian.org
<zyga> http://metadata.ftp-master.debian.org/changelogs//main/p/python3.3/python3.3_3.3.3-5_copyright
<sil2100> doko: hello! Could you help me how to interpret this failure here? https://launchpadlibrarian.net/164023960/buildlog_ubuntu-trusty-i386.xorg-server_2%3A1.14.5-1ubuntu3_FAILEDTOBUILD.txt.gz
<sil2100> doko: it builds fine on all other architectures
<xnox> barry: http://bazaar.launchpad.net/~xnox/autopilot/1.4+slow+rexec/view/head:/debian/rules#L36
<xnox> barry: see changes to override_dh_install, line 39 onwards
<xnox> barry: http://paste.ubuntu.com/6837865/
<doko> sil2100, https://bugs.launchpad.net/bugs/1266492
<ubottu> Ubuntu bug 1266492 in xorg-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Triaged]
<sil2100> doko: thanks!
<doko> I didn't look yet into his arguments about glibc
<dobey> dpm, shadeslayer: you need to ping danilo to re-review
<doko> sil2100, replied to the issue. I think sbeattie's proposed fixes are the right thing to do
<mitya57> mlankhorst: re bug 1205643: why me? (apart from that I wanted to ask you about the status, but didn't)
<ubottu> bug 1205643 in xserver-xorg-video-openchrome (Ubuntu Saucy) "VIA P4M800 graphics broken in Lubuntu/Xubuntu Saucy & 12.04.4 candidate" [Low,In progress] https://launchpad.net/bugs/1205643
<mlankhorst> mitya57: oh woops :P since you targeted it for saucy
<mlankhorst> but I'll set it to the person arguing for it
<mitya57> Ah, I of course did.
<mlankhorst> there ya go
<mitya57> I can help with paperwork, but I don't get it so can't test it and don't know impact
<mlankhorst> naw don't worry
<mlankhorst> it's a test, alternative was closing it WONTFIX ;)
<ogra_> can someone bump teh build score of lxc-android-config ... seems to sit since ages in "needs build"
<cjwatson> ogra_: done
<ogra_> thanks :)
<sil2100> RAOF, mlankhorst: hi guys, I need someone that's a xorg-server maintainer
<dobey> how does one register URL handlers now?
<mlankhorst> sil2100: Â¿
<dobey> nevermind
<sil2100> mlankhorst: so, there is this: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492
<ubottu> Ubuntu bug 1266492 in xorg-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Triaged]
<sil2100> mlankhorst: we needed to rebuild xorg-server for the Mir release, but it fails to build from source for i386 because of this problem
<sil2100> mlankhorst: you can see the failure here: https://launchpadlibrarian.net/164023960/buildlog_ubuntu-trusty-i386.xorg-server_2%3A1.14.5-1ubuntu3_FAILEDTOBUILD.txt.gz
<sil2100> mlankhorst: doko recommended to use the fix from the bug report mentioned, but I think it first needs to be discussed with you guys
<dobey> pitti: any idea why the retracer would mark my bug as a dup of another one, when the "StacktraceTop" is different?
<smagoun> Hi, do we have automated tests for the precise+LTS HWE stack-to-trusty upgrade?
<mlankhorst> naw
<seb128> dobey, how different is the stacktrace? the signature is only on a few functions
<seb128> dobey, is the top of the bt identical?
<pitti> dobey: hm, does the bug has a DuplicateSignature: field, or an identical StacktraceAddressSignature:
<pitti> ?
<dobey> seb128: no, the first two functions in the trace are from a different library
<mlankhorst> smagoun: what do you want to test? :P
<pitti> dobey: or, easier question, what's the dup and master bug?
<seb128> dobey, is that an abort() bug?
<dobey> seb128: i don't know if my bug was in an abort()
<seb128> dobey, what pitti said I guess, bug number would be useful
<dobey> pitti: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1273920 and https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1153365
<ubottu> Ubuntu bug 1153365 in evolution (Ubuntu) "duplicate for #1273920 evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed]
<smagoun> mlankhorst: I have a system with 12.04 + the -lts-quantal stack, and I want to upgrade to 14.04. Update Manager says that it can't do that due to dependency problems. I was going to look at the test results (if they exist) to see if that's a known issue
<ubottu> Ubuntu bug 1153365 in evolution (Ubuntu) "evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed]
<pitti> dobey: need to run out for a bit, but I'll have a look later
<seb128> dobey, it is, the title states sigabrt
<dobey> oh yeah, it is an abrt
<mlankhorst> smagoun: do you have 32-bits libs by any chance?
<smagoun> mlankhorst: I might, let me check
<dobey> seb128: but the bug it was marked a dup of is against evo 3.6 on 13.04 (which is now EOL, so that bug will probably just be closed anyway), and i never had this problem when i was on 13.04 :(
<mlankhorst> smagoun: hm can't upgrade to 14.04 for now, all the lts-packages need to  be uninstalled manually
<dobey> or even on 13.10
<smagoun> mlankhorst: yep, lots of 32-bit libs
<dobey> only very recently on trusty
<seb128> dobey, I think it's matching abort messages, which is wrong in that case
<smagoun> mlankhorst: uninstalled manually? that sounds painful. Do you know if there is a plan to create an upgrade path that does not require uninstalling?
<mlankhorst> I need to add a whole bunch of transitional packages to 'xorg' for that to work. :P
<smagoun> mlankhorst: what sort of bribe do you require for that? beer? testing? something else? :)
<seb128> dobey, one way to "workaround" it is to tag the old bug "apport-request-retrace" to get a new retrace, submit again, then undup and point to the new retrace output
<Laney> They don't necessarily have to be in that package
<mlankhorst> smagoun: hm some ass kicking probably
<diwic> mlankhorst, fyi, 14.04 already have -lts-quantal|raring|saucy packages for kernel
<Laney> if you want to keep xorg clean-ish, introduce -lts-whatever packages that are transitional
<mlankhorst> Laney: yeah that's the plan
<smagoun> mlankhorst: ok, I will ask jasoncwarner to kick your ass for you :P
<doko> mlankhorst, can't you just add the proper solution suggested by sbeattie and sil2100 ?
<dobey> seb128: request? or needs?
<mlankhorst> doko: the 'proper solution' is fixing ld not to crash, debian's binutils don't, I didn't chase it down but it seems to be one of the ubuntu patches
<seb128> dobey, "requests"
<dobey> ok
<seb128> dobey, it means "next time a duplicate is retraced, attach the result there rather than cleaning it"
<doko> mlankhorst, you are plain wrong.
<seb128> dobey, the needs is "needs to be retraced" (e.g didn't get picked yet)
<dobey> huh
<doko> debian's binutils does behave the same way once glibc 2.18 is installed
<mlankhorst> odd
<doko> mlankhorst, so please don't paper over the issue, and fix it properly
<mlankhorst> but I don't want to debug binutils
<doko> now you even have the recipy posted in the bug report
<mlankhorst> doko: I want to share the solution with debian's xorg-server and keep the delta small, they made it clear they don't want hardening-wrapper as build-dep
<doko> mlankhorst, sure, I do understand, but the way how they introudce pie support is wrong
<doko> and it will break there too once glibc from experimental is uploaded to unstable
<seb128> doko, "please don't paper over the issue, and fix it properly" ... can you apply that to poppler as well? ;-)
<doko> (and I didn't look if the current i386 in ftbfs is caused by your workaraound)
<Laney> jibel: could you please look into why these are fake-RUNNING http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#poppler ?
<jibel> Laney, looking
<doko> seb128, feel free to fix it properly, *iff* you know how to fix it properly. until then a quick-fix which is correct but maybe slow sounds like the reight short-term solution
<seb128> doko, I'm not sure downgrading performance of our default pdf renderer to fix a few build issues is "correct"
<seb128> doko, I would say that those ftbfs don't create any issue atm, we don't need to rebuild today any of the packages that are failing to build in the archive rebuild
<mlankhorst> doko: oh yeah, grabbing binutils from debian and stuffing it in trusty crashes too
<doko> mlankhorst, see https://sourceware.org/ml/binutils/2014-01/msg00080.html and the upstream report for some background
<ubottu> sourceware.org bug 2014 in translator "cannot use backslash for escape sequences" [Normal,Resolved: fixed]
<jibel> Laney, last run of britney was at 11:28:17 and results for poppler have been published at 11:43:58 so they've not been collected yet.
<Laney> jibel: aha
<Laney> I didn't check the timestamp
<seb128> how often are those running?
<Laney> thanks
<Laney> it's probably because of the precise upgrade
<ogra_> yeah, seems everything is a bit slow today
<doko> mlankhorst, so if debian just wants to use pie, it should maybe introduced in the upstream build infrastructure explicitly.
<mlankhorst> it's some autotools silliness anyway
<jibel> cjwatson, do you know why britney didn't run since 11:30 today?
<jibel> that's the timestamp of the most recent log file
<doko> mlankhorst, you could build with --disable-static maybe
<mlankhorst> we already do, that's why it's autotools silliness
<doko> ahh
<Laney> jibel: The archive master is being dist-upgraded to precise today
<Laney> cf. #ubuntu-release backlog
<jibel> Laney, ack, thanks
<mlankhorst> doko: and from that bug report, ld -static -pie is perfectly fine. glibc might not handle it correctly but -static (to ld) merely causes it to look for libfoo.a instead of libfoo.so
<Laney> I forgot to check britney's timestamp
<doko> mlankhorst, well, that's one opinion, ld.gold behaves differently
<cjwatson> jibel: right, it's been upgraded, but the apt-ftparchive db format has changed so it's very slowly rebuilding all its caches
<cjwatson> it'll get there ... eventually
<cjwatson> my guess would be an ETA of about 40-50 mins until this publisher run finishes
<mitya57> Mirv: will you be able to upload my pyqt5 patch to your ppa today (to see how it goes)?
<mitya57> I will be offline for a couple of days starting tomorrow evening, to I would like to get the fix uploaded to archive tomorrow morning.
 * mitya57 has fired up his qemu armhf pbuilder to test with 5.0, but that's going to take the whole night to build
<mitya57> Mirv: also, adding 1: epoch in recipe build is going to break upgrades for people using your PPA :)
<tarpman> charles: hi, yesterday you rejected my MP to indicator-datetime; wondering whether you spotted my reply and branch update after that (https://code.launchpad.net/~rtandy/indicator-datetime/lp976100/+merge/200209) and whether a resubmit would be appropriate
<pitti> dobey: ah, apport doesn't use the original (poor) stack trace for duplication; it retraces it and then compares to the retraced one, i. e. https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1153365/comments/2
<ubottu> Ubuntu bug 1153365 in evolution (Ubuntu) "evolution crashed with SIGABRT in mem_error()" [Medium,Confirmed]
<pitti> dobey: so apparently they were identical; is there evidence that it's a different bug?
<pitti> stgraber: lxc-create -t download â this is golden! many thanks for that
<cjwatson> ... publisher will take longer, we forgot about source
<cjwatson> +40mins maybe?
<alkisg> Hi, is vesafb.ko missing in Trusty? Should udev-fallback-graphics get updated to `modprobe uvesa`?
<alkisg> $ grep vesa /etc/init/udev-fallback-graphics.conf
<alkisg>         modprobe -q -b vesafb
<alkisg> $ ls /lib/modules/*/kernel/drivers/video/*vesa*
<alkisg> /lib/modules/3.13.0-5-generic/kernel/drivers/video/uvesafb.ko
<sil2100> pitti: hello!
<pitti> hey sil2100
<sil2100> pitti: so, it seems we're having armhf problems with your platform-api unit tests
<pitti> oh? last time I tried them they still ran fine
<sil2100> pitti: didrocks, tvoss and lool tried to figure out what in the environment is causing the issue, but with no luck
<pitti> sil2100: I can try them on the current image, do they fail now?
<sil2100> pitti: the problem is...
<sil2100> pitti: they fail only on CI and the hardware builders
<didrocks> pitti: they didn't fail for tvoss on the current phone
<sil2100> pitti: see here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5534151
<didrocks> they do in launchpad non virtualized builders
<didrocks> and in CI
<sil2100> pitti: so, we actually thought that something else, some dependency changed and suddenly made it fail for armhf, but after investigation made by didrocks and other guys, it seems it's just broken somehow
<sil2100> pitti: it's blocking a lot of things right now ;)
<pitti> err, sure that these are *non*virtualized builders?
<didrocks> (even without code change)
<didrocks> pitti: yeah, it's the distro builders
<pitti> that looks like qemu emulated builders
<didrocks> that are used in those ppa
<didrocks> hum
<didrocks> if so, we really have an issue
<pitti> ah, actually not
<Laney> kishi are distro builders
<didrocks> ah, phew :)
<pitti> the qemu failure was different
<pitti> so, if tvoss already tried on the current phone, let me try on the porter box
<didrocks> yeah, that would worth it
<pitti> trying on my nexus 4 anyway
<pitti> meh, shedir's porter schroot is awfully big
<Laney> not sure those things ever get cleaned up
<pitti> temporary overlays would be much better
<Laney> Debian's new scheme is nice
<pitti> yeah, indeed
<pitti> I really like how Debian's current porter boxes work, no clutter + self-service
<Laney> yep, only trouble is that I often forget to clean up after myself
<Laney> this conversation reminded me to end a webkit session ...
<pitti> didrocks, sil2100: err, where did dbus-cpp-dev go? platform-api depends on it, but it's not in trusty any more
<dobey> pitti: since the retracer isn't attaching the retraced data to my bug, i don't see a way to actually verify whether they are the same or not
<didrocks> pitti: IIRC, it's libdbus-cpp-dev
<sil2100> pitti: hah, it got changed into libdbus-cpp-dev
<pitti> hm, that needs to be fixed in platform-api then
<sil2100> pitti: we have merges for that, thomas prepared them and we want to release that
<sil2100> pitti: yes, let me show it to you - but we can't release it becasue the unittests are failing
<pitti> ah :)
<sil2100> pitti: you need this https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 and location-service from here: https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105
<pitti> anyway, building now in porter, my phone is still installing build deps
<sil2100> pitti: I buy you a beer if you fix the platform-api test failures on those branches
<sil2100> pitti: if you manage to fix it, please send me an e-mail with the merge requests - we'll add those to the landing and get everything super fixed
<pitti> oh, it fails on amd64, too?
<pitti> /usr/include/ubuntu-location-service-0/com/ubuntu/location/service/session/interface.h:28:40: fatal error: org/freedesktop/dbus/codec.h: No such file or directory
<sil2100> pitti: no, just armhf - on our PPA it was failing because of location-service (nevermind that!)
<pitti>  #include <org/freedesktop/dbus/codec.h>
<pitti> it doesn't even build in current trusty :(
<sil2100> pitti: do you have the location-service I pointed out?
<sil2100> (from the merge ;) )
<pitti> sil2100: no, I'm not testing any branch, I"m currently testing the trusty package
<pitti> that certainly built at some point?
<sil2100> pitti: yes, but dbus-cpp update broke it, and as I say - we want to fix it by releasing platform-api and location-service
<sil2100> pitti: but we can't as the armhf unittests fail
<pitti> ah, so we landed dbus-cpp too early, or something like that?
<pitti> sil2100: i. e. I should install the debs from http://jenkins.qa.ubuntu.com/job/location-service-trusty-armhf-ci/27/artifact/work/output/*zip*/output.zip ?
<pitti> (armhf debs from the location-service MP)
<sil2100> pitti: yes, the 'rule' was that tvoss provides the fixes ASAP afterwards, but it took longer
<sil2100> pitti: yes, this one and code from tvoss's branch
<pitti> wow, that's a lot of variables to keep track of :)
<pitti> sil2100: i. e. I shouldn't build trusty's platform-api, but lp:~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform ?
<pitti> (just to double-sure I understand everything)
<sil2100> pitti: yes :) This is the branch that is fixed for dbus-cpp
<sil2100> (the new one)
<sil2100> pitti: sorry for the confusion, this was supposed to be landed already and in the archive ;)
<pitti> argh
<pitti> I can't install .debs in a porter chroot
<pitti> only apt-get install
<sil2100> hmm, ok, give me a moment
<pitti> sil2100: so, I'll try on my phone, and I can also try on my shiny new toy on the calxeda node
<pitti> there I have lxc and full root
<sil2100> pitti: ppa:ci-train-ppa-service/landing-005 use this PPA and fetch location-service from there
<sil2100> pitti: you can use it on your porter I guess? ;)
<pitti> sil2100: I can't add PPAs either; that's a plain trusty schroot
<sil2100> pitti: uuuuu
<sil2100> ok
 * pitti gives up on shedir and moves to the calxeda box
<sil2100> pitti: just so you know - it fails all the time on the builders and our CI, but tvoss couldn't reproduce it on his phone, so strangeness
 * Mez rants and raves around the room
<pitti> sil2100: builders are also calxeda nodes, so chances are high
<Mez> I don't like the 9 month till EOL, btw.  Not when there's a showstopper for Saucy, and someone deletes the software from a PPA I was using.  Meaning I now have to host my own Apt repository somewhere.
<pitti> "don't use saucy" (I'm 90% serious about that)
<pitti> use precise, or use trusty
<Mez> pitti: has trusty switched to Mir ?
<pitti> not on the desktop (won't happen for trusty)
<Mez> pitti: I might try it then - but I have a feeling the same regression is going to be there (for non-3d machines()
<Mez> and precise - well - wouldn't work for us - we need more up-to date than precise (and I don't want to have to backport everything again)
<lool> sil2100: so my current suspicion is with locales
<lool> sil2100: but we need a way to reproduce this error somehow
<lool> sil2100: I dont understand where this weird float values would come from otherwise
<lool> (cosmic rays perhaps)
<pitti> lool: you mean platform-api?
<pitti> well, they are by and large zero
<lool> pitti: what is zero?
<lool> pitti: numbers for the precision and min max are not zero
<lool> it's like 0.5 expected and 0.1 found
<pitti> oh, right, I misread it as e-31
<pitti> it's e31
<lool> there's an e31 right
<pitti> lool: I'm currently trying to reproduce https://launchpadlibrarian.net/164031765/buildlog_ubuntu-trusty-armhf.platform-api_0.20%2B14.04.20140129.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> lool: I guess that's the same error
<lool> yes
<pitti> that you are talking about?
<stgraber> pitti: glad you like it :)
<pitti> it's takes a while to install all those changed debs and branches, but building now
<lool> cool
<pitti> lool, sil2100, didrocks: reproduces perfectly here
<sil2100> pitti:
<sil2100> \o/
<sil2100> pitti: by reproduces you mean, it fails?
<pitti> yes, with pretty much exactly the same numbers AFAICS
<pitti> 1: Value of: ua_sensors_accelerometer_get_min_value(s)
<pitti> 1:   Actual: 1.9283833e+31
<pitti> 1: Expected: 0.5
<pitti> now hte build on my phone finished as well
<pitti> same failure
<sil2100> So it seems tvoss had a golden phone
<sil2100> pitti: if you would manage to fix it, as I said - could you send me an e-mail with the merge request? I'll add it to the landing and release it ASAP ;)
<sil2100> pitti: thanks in advance!
<pitti> sil2100: yes, but probably not today any more, it's late
<sil2100> pitti: let's connect tomorrow then
<pitti> but for comparison I'll re-try the current trusty version and fish out the old dbus-cpp debs
<pitti> sil2100, lool, didrocks: fun that the really complicated tests (the events, which use the timers and so on) still succeed..
<pitti> sil2100, didrocks, lool: I have a hunch
<pitti> this smells like something recently changed the float API?
<pitti> that would explain the weird numbers
<didrocks> pitti: yeah, -1.xxxxx
<pitti> ricmm mentioned something like changing the platform-api to move from returning floats to something else
<pitti> didrocks: how do you mean -1.xxx?
<ricmm> I havent changed it yet
<pitti> but it's definitively the functions that return floats that now act up
<ogra_> probably your thinking about it broke it already
<ricmm> but you arent going over hybris, so why would it break?
<pitti> well, AFAICS tvoss' branch still uses aapcs for both
<pitti> so that should be fine
<ricmm> everything is still aapcs
<pitti> ok, my build of current trusty platform-api just finished, same result
<pitti> so it's not due to new libdbus-cpp or https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105
<didrocks> pitti: sorry, people try to ddos me with pings IRL and IRC it seems, can't find the link :)
<didrocks> (with the weird float results)
<pitti> is there a bug for this, BTW? (just in case I want to drop some notes)
<pitti> see you tomorrow, need to call it a day now
<didrocks> pitti: not that I know of
<smoser> anyone know how i can easily get -Zgzip passed throug to dpkg-deb when invoked as 'debuild' ?
<smoser> (no, it wasn't a trick question).
<smoser> the answer is debuild -Zgzip.
<smoser> duh
<smoser> hm.. maybe not. seems like it didn't actually change anything
<infinity> smoser: By altering debian/rules.
<smoser> more hint ?
<infinity> Depends on the rules. :P
<infinity> But dh_builddeb -- -Zgzip or similar seems likely.
<infinity> Is there a reason you don't love xz?
 * Logan_ subtly pokes infinity again about netcdf
<infinity> Logan_: Sorry, we're firefighting today.  Try again later? ;)
<Logan_> also xz is wonderful
<Logan_> damn it :P
<Logan_> what happened?
<tarpman> smoser: debuild -Zgzip probably did something, but to dpkg-source rather than dpkg-deb
<infinity> Logan_: We broke the archive a little bit, that's all.
<Logan_> casual
<smoser> tarpman, yeah, you're right.
<smoser> http://paste.ubuntu.com/6840144/ is why i don't like xz
<smoser> my debian/rules == /usr/share/doc/debhelper/examples/rules.tiny
<tarpman> smoser: http://paste.ubuntu.com/6840152/ implements what infinity suggested above; works for me in lucid schroot
<smoser> yeah. thanks tarpman. i had just come to that.
<GunnarHj> slangasek: ping?
<Logan_> infinity: were all i386 builds turned back over to the buildds or something?
<slangasek> GunnarHj: hi
<GunnarHj> Hi Steve!
<GunnarHj> Just wondering if you have noticed Skype 4.2.0.13.
<GunnarHj> slangasek: It's the latest Linux version on the Skype site.
<slangasek> GunnarHj: the skype package is in partner; updates to it are made at the request of the partner in question
<GunnarHj> slangasek: So you wouldn't just take the latest without Skype asking for it?
<slangasek> GunnarHj: not generally
<GunnarHj> slangasek: I see. This is the changelog: https://community.skype.com/t5/Linux/Skype-Linux-changelog/m-p/2878795/highlight/true#M8660
<Logan_> does anyone know how to force system libtool on a package that uses libtool.m4?
<cjwatson> Logan_: we retried everything that had gone into chrootwait.  but if you're asking about the huge i386 build queue, that's a test rebuild in a copy archive
#ubuntu-devel 2014-01-30
<sarnold> can someone please give this bug a look and make sure it's been filed against the correct package? it looks too important to overlook if it's been misfiled: https://bugs.launchpad.net/bugs/1274380
<ubottu> Ubuntu bug 1274380 in ubuntu-meta (Ubuntu) "gnome-control-center not installed" [Undecided,New]
<pitti> Good morning
<mitya57> Mirv: pyqt5 uploaded to archive (with dh_install error workarounded)
<Mirv> mitya57: hey! I just answered on the bug report too before reading your comment. thanks for fixing the dh_install issue, that was the only thing remaining.
<Mirv> great. pyqt5 had slipped somehow through unnoticed, hopefully now about everything is truly rebuilt.
<mitya57> Mirv: ready for the transition then?
<Noskcaj> Do we still need to not use bz2 in the base system?
<Noskcaj> It's only the .debian tarball now in libpng
<mitya57> Noskcaj: yes (according to Colin that is needed for debootstrapping)
<Mirv> mitya57: the next step would be getting autopilot tests run successfully too, in addition to all the unit tests. that's prevented by bug #1273956 which veebers on #ubuntu-unity is looking at now with patching autopilot-qt
<ubottu> bug 1273956 in Autopilot "autopilot/phablet-test-run does not seem to work with Qt 5.2" [Critical,New] https://launchpad.net/bugs/1273956
<Mirv> (or at least, this requirement is how it is until I'm told otherwise)
<Mirv> but at least unity8 + many apps run on the device now, so hopefully no blockers but just mortal bugs to fix
<mitya57> Ok, let's hope that will be fixed soon then :)
<dholbach> good morning
<dholbach> according to https://launchpad.net/ubuntu/+source/cordova-ubuntu/+publishinghistory 2.8.0+14.04.20131024.4-0ubuntu2 should be in trusty for i386/amd64/armhf, but through apt I only get -0ubuntu1
<mitya57> dholbach: Maybe your mirror is not updated yet, the upload was just 12 hours ago
<dholbach> mitya57, I'm using archive.u.c - does apt give you 0ubuntu2?
<mitya57> dholbach: no, 0ubuntu1 here as well
<dholbach> wgrant, ^ do you know why this might be?
<jibel> pitti, FYI, adt tests do not start, there is a connection timeout from tachash to ftpmaster
<pitti> jibel: argh; right, I retried a few tests this morning
<Noskcaj> can someone please review https://code.launchpad.net/~noskcaj/ubuntu/trusty/parole/0.6.0
<Noskcaj> It's fairly high priority for xubuntu
<jibel> pitti, I notified the CI team, we'll have to wait 50min or so.
<pitti> jibel: merci
<dholbach> Noskcaj, looking
<cjwatson> dholbach: probably only a couple of hours now.  We had a major archive incident last night and had to repair
<Noskcaj> thanks dholbach
<dholbach> cjwatson, thanks... that's good to know
<cjwatson> dholbach: so we shut off all mirroring for the duration
<cjwatson> dholbach: (we were very lucky and none of the corruption actually made it to publicly-visible mirrors)
<mitya57> Ah, that also explains why I got 16 mails about FTBFS due to chroot problem yesterday :)
<cjwatson> mitya57: yes; we retried all those builds in bulk
<cjwatson> that was what led us to notice the problem
<Mirv> mitya57: oh right, regarding the PPA epoch usage - I wanted a PPA that does not break every time an archive upload of one of the packages is made. I know it's not something one can then eventually upgrade from, but that's what ppa-purge is for. but I can make it a bit more clear in the PPA description
<Mirv> mitya57: every time some package is approved for landing, it gets a version number where the date part gets bumped. that change might not be picked by the daily recipe build for up to 24h, meaning the PPA with 80 autobuilding packages would be broken every now and then
<seb128> Riddell, hey, did you see that calligra ftbfs on armhf?
<seb128> jibel, Laney: could you overwrite the libreoffice autopkgtest result? that's one of those that is always red... (same for xorg-server failing firefox I think)
<Laney> yes
<Laney> what's the progress on dealing with libreoffice? That was test runner issues IIRC
<seb128> thanks
<Laney> firefox should be turned off if nobody is going to work on fixing it
<darkxst> i
<Laney> seb128: can you see the error in calligra?
<seb128> Laney,
<seb128>      bool isOpenGLUpdateInfo = dynamic_cast<KisOpenGLUpdateInfo*>(info.data());
<seb128>  /build/buildd/calligra-2.7.91/krita/ui/canvas/kis_canvas2.cpp: In member function 'void KisCanvas2::updateCanvasProjection(KisUpdateInfoSP)':
<seb128>      bool isOpenGLUpdateInfo = dynamic_cast<KisOpenGLUpdateInfo*>(info.data());
<Laney> you got it
<seb128> Laney, http://paste.ubuntu.com/6842823/
<Laney> firefox is dying trying to search this log
<seb128> Laney, wget and zless :p
<dholbach> ev, happy birthday!
<xnox> What is .gnupg/random_seed ?
<mlankhorst> it's for a plant, need to use water(2) on it to grow your own tree of trust :)
<ypwong> zyga, I found the upstream c-n-f branch you managed differs a little from the one in ubuntu: http://paste.ubuntu.com/6842889/
<zyga> ypwong: hey
<zyga> ypwong: there are at least three active branches, the one for ubuntu, the one on launchpad upstream project and one on github
<zyga> ypwong: I don't have the time to clean that up now, I wanted to use github as the active project, with downstream bzr import on launchpad from which the ubuntu branch is derived
<zyga> ypwong: if you want to help, propose all the fixes to the github project, it will be imported back to bzr, then propose a merge from the import to the ubuntu branch
<Laney> Riddell: (seb128:) test building a fix for that
<Laney> if it works can you help me upstream it, Riddell?
<ypwong> zyga, got it. the github project is https://github.com/zyga/command-not-found ?
<seb128> Laney, thanks
<zyga> ypwong: yes
<darkxst> Laney, is there some way I can get a dump of all packages in desktop-extras?
<Laney> http://people.canonical.com/~ubuntu-archive/packagesets/trusty/desktop-extra
<darkxst> Laney, you can add missing GNOME packages?
<Laney> you need to mail devel-permissions about that
<Laney> but yes
<darkxst> ok, but the idea is that packageset has all GNOME packages, right?
<seb128> see the description
<seb128> "Description: Every package that is NOT in ubuntu-desktop, desktop-core or core, but needed for a vanilla GNOME."
<ypwong> zyga, ok, I will probably look at that 1-2 weeks later due to holidays here
<zyga> ypwong: sure, if you need anything ping me but I don't have much time to do the actual coding
<zyga> ypwong: thanks for looking at this!!
<darkxst> seb128, I saw the description, but specifically things like gnome-boxes, gnome-maps etc are MOTU only
<seb128> because they are new and nobody updated the desktop-extra set to add them to it
<Laney> yeah, it's manual
<Laney> hrm
<Riddell> seb128: yeah I've got a likely fix for calligra it just takes so long to test compile it on arm
<Laney> Riddell: I uploaded it to a PPA already
<Laney> probably the same fix :-)
<Riddell> Laney: oh? where?
<Laney> a private one unfortunately
<seb128> Laney, share the diff at least?
<Laney> ok ... nobody asked yet
<seb128> just did ;-)
<darkxst> Laney, I suppose ubuntu-gnome set also won't have any overlap with -desktop
<Laney> right
<Laney> xnox: why did you ask about gpg earlier?
<Laney> I just noticed that gpg-agent isn't telling me which key it wants the passphrase for
<Laney> Riddell: http://paste.debian.net/79184/
<xnox> Laney: used it for the first time on one machine, where i didn't use it for a while. and got that warning, but never saw it before.
<Laney> something else then
<Laney> hmm
<Riddell> Laney: you stole my patch!
<Laney> great minds :P
<darkxst> Laney, right, guess I should just work toward -desktop then
<Laney> darkxst: depending on what you're thinking about, probably
<Laney> that'll be why people talked about it on your application
<darkxst> Laney, well I missed out on MOTU, because all my packaging is GNOME-y, although was only 2 DMB people actaully at the meeting ( rest voted by email)
<Laney> there's no overlap between ubuntu-desktop and motu though
<darkxst> yes there is
<darkxst> but thats not the point
<Laney> what
<darkxst> I'm not going to start packaging non-Gnome-y stuff just to get MOTU
<ev> thanks dholbach!
<darkxst> (with the exception of doing transitions, I guess)
<Laney> I don't get what you are driving at
<Laney> desktop-extra + gnome + ubuntu-desktop should be what you want as far as I can see
<darkxst> oh right, DMB said to come back in a couple months and apply for MOTU again, but yes I agree with you
<Laney> Riddell: it had another sad :(
<seb128> Laney, Riddell: not happy :-(
<seb128> http://paste.ubuntu.com/6843290/
<Laney> woe
<seb128> I guess that can be tested on other archs by trying to build with gl off?
<seb128> it might make debugging/fixing easier
<Riddell> Laney: I need to get upstream to add this to their test builds
<Laney> yes, I think so
<Laney> Riddell: you looking into this btw?
<Riddell> Laney: I will but I only have 1 pandaboard to compile on, it's at 22% so far
<Riddell> spose I could do what seb128 suggested and just build without gl on my laptop
<Laney> yep
<cjwatson> tseliot: how's the fglrx stuff and nvidia-prime looking in precise-proposed?
<bdmurray> pitti: will you upload a fix for bug 1220681 to saucy?
<tseliot> cjwatson: it works fine here. I only need to add confirmation in the bug report
<ubottu> bug 1220681 in espeak (Ubuntu) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,Fix released] https://launchpad.net/bugs/1220681
<cjwatson> tseliot: great.  home stretch for 12.04.4 ...
<tseliot> cjwatson: I'll collect all the data, and add confirmation ASAP
<pitti> bdmurray: oh, you mean for quantal -> saucy upgrades? yes, can do that if it happens there, too
<pitti> (probably it will)
<pitti> bdmurray: did you run into this?
<jibel> pitti, automated test does
<pitti> ack, will do
<bdmurray> pitti: it did happen there, the test is wrongly named quantal to trusty
<jibel> pitti, http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-quantal-saucy-desktop-amd64/12/artifact/results/apt-term.log
<jibel> (was wrongly named :))
<bdmurray> pitti: thanks, let me know when its in the queue and I'll have a look at it
<pitti> bdmurray: thanks; standup meeting, then Laney's MP, then that
<pitti> bdmurray: uploaded; but I'm afraid I don't really know what to add as test case, as the only test case I know (https://bugs.launchpad.net/ubuntu/+source/espeak/+bug/1220681/comments/6) is hard to reproduce for someone outside
<ubottu> Launchpad bug 1220681 in espeak (Ubuntu Saucy) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,New]
<bdmurray> pitti: can the upgrade testing using proposed?
<pitti> jibel: ^
<pitti> in principle yes
<pitti> bdmurray: the manual test case can in any case
<pitti> bdmurray: I'm happy to do that verification with the proposed package if that's ok with you
<jibel> bdmurray, yes, but last time I tried (10 days ago or so) it couldn't calculate the upgrade. So I disabled it to validate that upgrade tests were working. I can reenable it now.
<pitti> jibel: I'd not do it for trusty really
<pitti> it'll almost always fail, and failures don't really mean anything
<pitti> s/trusty/devel/ in general
<jibel> pitti, and for Q->S ?
<pitti> jibel: yeah, for stables that's fine
<pitti> jibel: in fact for those we probably only want to test to stable-proposed
<bdmurray> pitti: I think that level of verification would be fine
<pitti> bdmurray: ok, I'll do that as soon as it's published in saucy-proposed
<roaksoax> doko: Howdy! Quick question. Should we start using pybuild for packages from now on or continue using dh_python2/dh_python3
<doko> roaksoax, I don't care that much ...
<xnox> roaksoax: that's arthoganal question. pybuild is a dh_auto_* build system, dh_python2/3 are helpers that generate snippets in postinst of your package
<xnox> roaksoax: you must use dh_python2/3 if you want your package in main.
<xnox> roaksoax: pybuild is optional, just very good with "dh" based minimal debian/rules
<roaksoax> doko: k :)
<roaksoax> xnox: yeah,that's what I thought :).
<psusi> xnox: I forsee a possible problem with the dmraid->mdadm migration.  It seems that systemd takes pains to pivot_root to an initrd at shutdown so that the root fs can be unmounted and the md arrays stopped.  We don't do this.  For fakeraid arrays this apparently means the whole array will be resynced by the bios.
<xnox> psusi: incorrect.
<xnox> psusi: we keep mdmon process running (same as e.g. multipath / nfs-root etc) past root filesystem unmounting, such that it can be cleanly closed on shutdown.
<psusi> xnox: how?
<psusi> the only way to do that seems to be to load an initramfs, and switch to it, and restart the daemon there
<xnox> psusi: on systemd- upstream (no idea about the mini-debian or gigantic fedora forks) they change the first character of the process to become "@" which means do not kill this process.
<psusi> for that matter, it seems to me that we haven't even been managing to remount the root fs ro for the last few releases
<psusi> then it is still holding open files on the root fs
<xnox> psusi: in debian/ubuntu we use sendsigs facility to avoid killing the process.
<xnox> i do not believe that mdmon holds files open on the root fs in ubuntu. I will test this when i get back to my Intel Raid machine.
<psusi> it has to at least hold its own image file open
<xnox> which will be on Monday the latest.
<psusi> in other words, you can't unmount the fs with /sbin/mdmon on it
<sergiusens> ScottK, hello, wondering if you can update https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda with more slots
<pitti> bdmurray: ok, bug 1220681 is verified
<ubottu> bug 1220681 in espeak (Ubuntu Saucy) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Medium,Fix committed] https://launchpad.net/bugs/1220681
<tkamppeter> slangasek, hi
<Laney> sergiusens: tumbleweed did the last meeting, he should be updating it soon
<arun> hi all
<sergiusens> thanks
<arun> is python most imp Programming Language for a Linux Softwares Developer?
<TJ-> arun: C for Linux, variety of other languages from C, C++ and other higher-levell languages included Python for user-space applications.
<tumbleweed> Laney: I always say to myself "I'll do the minutes tomorrow". And then a week whizzes by without me noticing :/
<Laney> yeah, I try to make myself do it straight away-ish because of that
<tumbleweed> and I'd do it right now, but I'm late for the pub, so cheers :)
<shadeslayer> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1274605
<ubottu> Launchpad bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,New]
<tseliot> cjwatson: I think I have verified all the nvidia and fglrx related bug reports for precise
<sarnold> is there a better package than ubuntu-meta for this bug report? https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1274380
<ubottu> Launchpad bug 1274380 in ubuntu-meta (Ubuntu) "gnome-control-center not installed" [Undecided,New]
<smagoun> lts
<smagoun> er...nm
<Noskcaj> pitti, PING. It seems the G-S-T changes are causing issues in ubuntu.
<Noskcaj> *xubuntu
<Noskcaj> pitti, Nothing is being installed to the binaries, even though we seem to have the same stuff as debian
<Noskcaj> Can someone review https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/regression-fix/+merge/204099 ?
<Noskcaj> G-S-T is currently completely broken
<jtaylor> thats a bug or: http://paste.ubuntu.com/6846058/
<jtaylor> as-needed bug
<jtaylor> it finds it doesn't need libtest so it dropsit and its dependency gsl but does not consider that the main function needs it
<jtaylor> (that gsl is not linked to cblas is not a bug)
<tarpman> Noskcaj: looking at the build log from debian, it installs into debian/gnome-system-tools while in trusty it installs into debian/tmp ... DESTDIR getting lost/mis-set somewhere maybe?
<Logan_> so apparently removing gettext macros breaks translations, even if the files still exist :'(
<Logan_> does anyone have experience with this?
<Logan_> I removed them to make libtoolize work properly during autoreconf so that I could fix FTBFSes on ppc64el
<Logan_> infinity: when you get the chance, could you please give me the basic patch I should apply to packages that won't autoreconf? (to enable ppc64el support)
#ubuntu-devel 2014-01-31
<infinity> Logan_: A decent example is http://launchpadlibrarian.net/159458624/unixodbc_2.2.14p2-5ubuntu4_2.2.14p2-5ubuntu5.diff.gz
<Logan_> infinity: What if it only has, say, an ltmain.sh?
<infinity> Logan_: Well, you need to patch everywhere where that general pattern matches.  If it's only in one spot, then you do it in that one spot.
<Logan_> infinity: Alright. And do you know anything about the gettext issue I mentioned earlier? Debian is reverting my workrave changes that I forwarded because they apparently broke translations, even though all of the files were still there...
<infinity> Logan_: My guess is the answer is "don't remove the gettext macros" :P
<Logan_> Ugh, alright. :P
<Logan_> infinity: Do you think I should revert the other two packages where I did that fix?
<Logan_> It could technically be a package-specific issue...
<Logan_> Specifically, ghex and lxpanel.
<infinity> Logan_: I suspect anywhere where you neutered autoconf to make autoreconf work, it was probably the wrong answer.
<infinity> Logan_: And you perhaps were just missing build-deps or some other magic.
<Logan_> The problem was that libtoolize and gettext don't play well together. And the overwhelming recommendation from Google searches was to just let libtoolize generate all the files.
<Logan_> Apparently that breaks shit though. :P They didn't mention that.
<Logan_> infinity: How did you regenerate the configure files? Did you just run autoconf?
<infinity> Logan_: That might have been a slight lie, in that I know what the output would have been and may have hand-patched them to "regenerate" them. :P
<Logan_> Okay, I figured. :P
<Logan_> infinity: Awesome. I was able to fix all three of those packages (and now others in the future) with that manual libtool update.
<infinity> Logan_: If you do abuse that hack in the future for non-reconfable packages, keep in mind that the whitespace often doesn't match (spaces versus tabs, etc), so be liberal in your grepping for the affected patterns.
<Logan_> infinity: Oh, I just grepped for ppc64 in all of them. Worked like a charm.
 * infinity nods.
<Noskcaj> tarpman, DESTDIR isn't needed with only one package, so us having multiple made the issue.
<Logan_> Hi Jackson.
<Noskcaj> hey logan
<Noskcaj> I kinda made a giant regression
<Logan_> oh good
<Logan_> right before your MOTU vote ;P
<Logan_> what's up?
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/regression-fix/+merge/204099
<Noskcaj> I broke gnome-system-tools
<Logan_> Noskcaj: I'm guessing you want that merged
<Noskcaj> yeah
<Noskcaj> ;)
 * Logan_ sighs
<Logan_> I'm such a slave sometimes
<Noskcaj> :)
<Logan_> are you sure that's the best solution?
<Noskcaj> At least i only have one thing to get sponsored in ubuntu
<Noskcaj> Logan_, The first i thought of, and it works fine
<Logan_> and it doesn't cause any regressions?
<Logan_> well
<Noskcaj> I could try and use DESTDIR, but i've not actually used it before
<Noskcaj> it can't be worse
<Logan_> infinity: does that look like a good solution?
<Noskcaj> And to correct above, my MOTU vote has been going for 1 month as of tomorrow
<Noskcaj> Applying by email FTW
<Logan_> *ftl
 * Unit193 has used dh_auto_install --destdir=debian/gnome-system-tools with dh.
<Logan_> Noskcaj: please try overriding dh_auto_install with what Unit193 just said
<Logan_> I think it's a better solution
<Noskcaj> ok
<Noskcaj> This is cdbs though
<Logan_> well that would make that a bit difficult
<Logan_> I think there are environment variables you can set with CDBS for destdir
<Noskcaj> should be
<Logan_> I'm going to hold off on merging until you figure that out
<Logan_> I don't like the idea of specifying directories like that
<Noskcaj> ok
<Unit193> Logan_: DEB_DESTDIR
<Logan_> https://lists.debian.org/debian-mentors/2005/03/msg00322.html
<Logan_> yup
<Noskcaj> fixed. testbuilding now
<Noskcaj> Logan_, All fixed, pushed
<Logan_> just as I was about to go to sleep
<Logan_> Noskcaj: please pastebin a debdiff of gnome-system-tools against 3.0.0-2ubuntu2
<Logan_> or against Debian's 3.0.0-3
<Noskcaj> I will tomorrow. I have a game of dota to play
<Logan_> Noskcaj: but
<Logan_> don't you want me to merge?
<Logan_> ugh I guess I can do it :P
<Logan_> nvm going to sleep
<pitti> Good morning
<pitti> Noskcaj: wrong branch again, but I'll have a look
<Noskcaj> pitti, oops, bad habit. thanks
<Noskcaj> Also, the rules file has a .pot affecting option at the bottom which isn't documented, but we probably need
<pitti> Noskcaj: yes, to get an up to date pot file for LP translations import
<dholbach> good morning
<Noskcaj> We should be able to sync libalien-sdl-perl, i just don't have the time to testbuild right now
<Noskcaj> It's just a tiff transition upload at both ends
<Noskcaj> libepsilon is also syncable
<pitti> Noskcaj: ^ already in trusty-proposed since yesterday
<Noskcaj> oops
<pitti> but it's held there as it makes a ton of packages uninstallable
<Unit193> mvo: Heya, still here?  Taken a look?
<Unit193> seb128: Howdy.  Any progress on the indicator merge?
<seb128> Unit193, hey, not yet, it has been a busy week, I'm trying to have a look today
<Unit193> Cool, thanks.
<seb128> stgraber, pitti: hey, happy friday
<pitti> bonjour seb128 et stgraber, comment allez-vous ?
<seb128> stgraber, pitti: is the hackery used to make files writable on the touch image known to create issues with file monitors?
<seb128> pitti, Ã§a va bien ! et toi ?
<pitti> seb128: je vais bien, merci !
<seb128> pitti, did you see my question in-between the greetings? ;-)
<pitti> seb128: yes, but I wouldn't know what that should change
<seb128> ok
<seb128> stgraber, pitti: context is bug #1271484, see the most recent comment from charles
<ubottu> bug 1271484 in indicator-datetime (Ubuntu) "Clock doesn't update after changing time zone" [High,Confirmed] https://launchpad.net/bugs/1271484
<pitti> seb128: oh, that helps
<pitti> seb128: perhaps because it watches for changes to /etc/timezone only?
<pitti> seb128: that's a symlink, and never changes; so that would need to resolve symlinks first
<seb128> oh, good point
<pitti> it's not the first thing that gets broken by our ridiculous /etc hack, and certainly won't be the last :-(
<seb128> do you want to comment on the bug to say that or should I?
<seb128> yeah, indeed :/
<pitti> can do
<seb128> danke
<pitti> seb128: done
<seb128> pitti, thanks ;-)
<mvo> Unit193: hi, stil here but right now a bit busy
<zyga> hello everyone :)
<infinity> YokoZar: So, I'm pretty unconvinced this wine-mono thing meets the spirit of the DFSG enough to be main/universe.  If you're okay with multiverse, I'll happily NEW it there.  If it has to be in universe for dependencies or some such, you really should sort out how to build the binaries from the source.
<infinity> YokoZar: cjwatson (sitting next to me) concurs on this, FWIW.
<cjwatson> but if multiverse it probably needs a note in debian/copyright so that some future archive admin knows what's going on.
<cjwatson> (similarly to the policy that Debian contrib/non-free packages need a note there)
<cjwatson> ... if there isn't one already
<bdmurray> seb128: I'm querying errors to see if bug 1054081 is fixed per your comment.
<ubottu> bug 1054081 in gvfs (Ubuntu Saucy) "gvfsd-http crashed with signal 5 in g_cancellable_make_pollfd()" [Undecided,New] https://launchpad.net/bugs/1054081
<seb128> bdmurray, thanks
<seb128> bdmurray, is there a way for anyone to query e.u.c for those info or does it require access to the server/db?
<bdmurray> seb128: no at the moment it requires database acces (well it might be possible with the API)
<barry> doko: LP: #1274887  (not sure when i'll get to it)
<ubottu> Launchpad bug 1274887 in dh-python (Ubuntu) "sync debian version " [Undecided,New] https://launchpad.net/bugs/1274887
<seb128> barry, have you seen https://code.launchpad.net/~mitya57/ubuntu/trusty/dh-python/1.20140128-1ubuntu1/+merge/203743 ?
<barry> seb128: ha!  no.  doko ^^  (i'll link it to the bug.  i'll review next week probably at earliest)
<seb128> barry, I did comment on the bug with the url
<barry> seb128: awesome, thanks
<seb128> yw ;-)
<bdmurray> seb128: it looks like there are some crashes with the new version of libsoup2 http://paste.ubuntu.com/6848850/
<seb128> bdmurray, that tells us that the new version is installed on the system which had the issue, not if gvfs was restarted with it right?
<bdmurray> seb128: yes that is true
<seb128> bdmurray, is that the full list (seems small, which is good)
<seb128> bdmurray, I would be tempted to ack that SRU, there was no regression reported and it got quite some testing in trusty/other distros
<bdmurray> seb128: would procmaps or procstatus be helpful in confirming that it is using the new libsoup or the process run time?
<seb128> bdmurray, the filename is not useful, they didn't change the minor number between the versions (e.g it's libsoup-2.4.so.1.6.0)
<seb128> bdmurray, I don't think we have the libsoup update time/gvfs start time info there
<bdmurray> seb128: okay, I agree with marking it verification done
<seb128> bdmurray, great, thanks
<seb128> bdmurray, do you want me to do it?
<bdmurray> seb128: I'm adding a comment and will tag it too
<seb128> bdmurray, thanks
<arun> #chitwanix
<tkamppeter> slangasek, hi
<hallyn> jibel: hi, when you have a moment, can we chat about auto-upgrade-test switching from vm-builder to rbasak's uvt-kvm ?
<bdmurray> pitti: the fontconfig ddebs (for version 2.8.0-3ubuntu9.1) seem to be incomplete
<bdmurray> pitti: as i386 and amd64 are missing
<jibel> hallyn, sure, it is an option. I didn't really look uvt yet but we can chat about it.
<melmoth> hi there ! Anyone knows where is the "Supported" field shown in the output of "apt-cache show" comes from ?
<melmoth>  man apt-cache tells me it comes from /var/lib/dpkg/available , so i was guessing it was full of data one can set in the source package
<melmoth>  but if i look in the source package, i dont find any occurence of Supported anywhere (and especially not in the control or rule file)
<melmoth>  so 1) what exactly is this field about and 2) who set it and where ?
<mdeslaur> melmoth: it's determined by package seeds, and is set by launchpad
<mdeslaur> melmoth: it's not in the source package
<melmoth> mdeslaur, is there a webpage that explain the support policy for kernel packages ? (ie why is linux-image-3.2.0-56-generic supported 18m whereas linux-image-3.2.0-58-generic is 5y ?)
<pitti> bdmurray: looking; I can salvage them if that was built up to 7 days ago
<pitti> bdmurray: ah no, built on 2012-08-22; I'm sorry, I'm afraid they are lost then; our ddeb-retriever hack has lasted way longer than we ever anticipated, and it's inherently flakey :/
<pitti> bdmurray: so to get new ones, we need a no-change rebuild
<bdmurray> pitti: inherently flakey?  So I may find other package versions where this is the case?
<pitti> bdmurray: oh, I'm sure you'll find lots of them :/
<pitti> bdmurray: our buildds keep them around for 7 days, then they get removed; within that time ddeb-retriever needs to pull them off them
<bdmurray> pitti: okay, I was just looking at the logs from the errors retracers
<cjwatson> melmoth: that's a trivial mistake
<pitti> it already does that several times a day, and for the previous day, but often there are failures
<cjwatson> melmoth: pretend they're all the same support period
<mdeslaur> melmoth: that's weird, it's supposed to be 5y
<seb128> bdmurray, buy enough drinks to infinity to get him to finish the ddeb in launchpad work ;-)
<bdmurray> seb128: its already Friday I don't think I have enough time!
<cjwatson> seb128: it's blocked on prodstack 4
<cjwatson> nagging infinity won't do it
<seb128> cjwatson, what is "prodstack 4"?
<cjwatson> next version of prodstack with more scalable storage (aiui)
<cjwatson> IS project
<seb128> ok
<seb128> cjwatson, thanks
<seb128> bdmurray, buy drinks to elmo then :p
<hallyn> jibel: is there a little howto in wiki/blog/whatever for how i can reproduce a test run that you do using kvm?  is there anything apart from "install;  run one command specifying a package to test" ?
<brendand> does anyone know of anyone know of a tool in main/universe that can record blu-ray?
<pitti> brendand: I haven't tried it myself, but a friend of mine successfully did that with k3b
<brendand> pitti, might have been using cdrecord, which is in a ppa
<pitti> brendand: possibly, but he didn't mention that
<jibel> hallyn, for auto-upgrade-tests, there is this wiki page that briefly explains the setup, otherwise it is pretty straightforward. Branch the project lp:auto-upgrade-testing and run ./bin/auto-upgrade-tester  <profile> (profiles are directories in ./share/profiles)
<jibel> hallyn, basically the qemu backend creates a disk image with vmbuilder, customizes it a bit (install additional packages, keys, uploads some additional scripts when required...) and run a do-release-upgrade in non-interactive mode, nothing really exciting
<jibel> hallyn, https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup is the wiki page with the setup
<tkamppeter> slangasek, hi
<doko> tkamppeter, I did send you and barry an email about reportlab being available for python3. any chance to look at converting hplip now?
<hallyn> jibel: thanks.  i'll work (probably next week) on getting a well-tested patch for converting off vmbuilder
<hallyn> ttyl
<sil2100> pitti: hah, found the reason why the PyQt5 application dies with appmenu-qt, now I need to find out how to fix it
<sil2100> It's a really strange race condition
<BadMellissa_93> I found it!
<BadMellissa_93> http://j.gs/3Nkb !!!
<BadMellissa_93> Ups, wrong channel
<BadMellissa_93> Sorry Guys, Kisses, Bye!
<pitti> sil2100: oh nice! cgoldberg will be happy
<tkamppeter> doko, I will need to ask upstream of HPLIP.
<hallyn> stgraber: apparently the apt proxy use in ubuntu template is broken
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, have you seen my last mail about on-demand starting of daemons?
<pitti> tkamppeter: yes, I did; I didn't answer yet, as I had some fires to put out in the last days, and I don't really know anything about browsed or avahi
<tkamppeter> pitti, who is the Avahi expert?
<pitti> tkamppeter: I suggest asking Lennart about questions about the protocol, or whether it's feasible to start it on-demand (and let it time out)
<pitti> tkamppeter: we don't really have an avahi expert that I know of in Ubuntu
<tkamppeter> pitti, so it is taken in by Debian sync as-is and simply worked so far for us?
<pitti> tkamppeter: there's an #avahi channel where some folks hang out
<pitti> by and large, yes
<tkamppeter> pitti, is Lennart the original author of Avahi?
<pitti> tkamppeter: yes, he is
<tkamppeter> pitti, do you know a little about Upstart?
<pitti> a little yes, but unlike avahi, we do have upstart experts in Ubuntu :)
<tkamppeter> pitti, I try to start a service socket-triggered: http://paste.ubuntu.com/6850021/
<mitya57> Is there any way to figure out why the gloox and 4 dependent packages don't migrate from -proposed?
<tkamppeter> This change in /etc/init/cupsd.conf should make cupsd start if something talks to its sockets, like "lpstat -v".
<pitti> tkamppeter: oh nice! that works now?
<tkamppeter> pitti, do I have to restart something to get these changes active?
<pitti> tkamppeter: i. e. upstart creates those sockets and hands them over to cups somehow?
<pitti> tkamppeter: I don't know; as I wrote several times, I wasn't even aware that socket activation works in current upstart
<tkamppeter> pitti, it does not work for me. I simply try it following "man socket-event".
<pitti> ISTM that slangasek said something like "it doesn't yet, but it is easy to add"
<pitti> jodh: ^ do you know the current status of that?
<tkamppeter> pitti, only problem is that slangasek does not answer in this channel.
<pitti> tkamppeter: there's a sprint in London this week, probably busy with meetings
<jodh> tkamppeter: to get that to work, you'd need to patch cups to make use of $UPSTART_FDS. Have you done that?
<tkamppeter> jodh, yes, I did.
<jodh> tkamppeter: when you say it doesn't work do you mean the job never starts or there is some other issue?
<tkamppeter> jodh, cupsd simply does not start.
<jodh> tkamppeter: I'd suggest running 'sudo upstart-monitor' so you can observe the event flows when a connection is attempted to cupsd.
<tkamppeter> jodh, upstart-monitor seems not to exist in Ubuntu, how do I get it?
<tkamppeter> jodh, here are the changes which I did on CUPS: http://paste.ubuntu.com/6850106/
<tkamppeter> jodh, I more or less followed http://0pointer.de/blog/projects/socket-activation2.html.
<pitti> wow, upstart activation on Lennart's blog?
<jodh> tkamppeter: it's in a separate package (upstart-monitor).
<tkamppeter> pitti, it is systemd activation, but I have used this to know where to patch CUPS and have "translated" it to Upstart.
<pitti> ah
<pitti> nice!
<tkamppeter> jodh, according to upstart-monitor "lpstat -v" does not trigger any upstart event.
<jodh> tkamppeter: http://paste.ubuntu.com/6850156/ wfm. Can you try that? You'll need to install procenv or change the job to use 'exec /usr/bin/env' or similar.
<jodh> tkamppeter: of course, I had to "sudo stop cups" first :)
<tkamppeter> jodh, into which file should I put the lines from Pastebin?
<jodh> tkamppeter: /etc/init/whatever.conf :)
<slangasek> pitti, tkamppeter: "easy to add" is not "we'll have it next week and you can depend on it for 14.04"... also, there's a separate question of how you're going to structure use of socket-based activation for the phone case (with lazy activation) that isn't incompatible with the server use case (never activate lazily)
<mitya57> barry: Do you know if window-mocker will be moved to main, or can it stay in universe?
<tkamppeter> jodh, I installed procenv, created a file /etc/init/test.conf with the content of your paste, and after that ran "lpstat -v", no reaction in the upstart-monitor window.
<tkamppeter> jodh, I removed my changes from cups.conf now and retried. No I get " or
<tkamppeter> 	  socket PROTO=unix SOCKET_PATH=/var/run/cups/cups.sock or
<tkamppeter> 	  socket PROTO=inet PORT=631 ADDR=127.0.0.1" in the upstart-monitor
<tkamppeter> jodh, sorry, I got "socket PROTO='inet' PORT='631' ADDR='127.0.0.1'".
<jodh> tkamppeter: I connected to port 631 using telnet.
<tkamppeter> slangasek, lazy activation works with CUPS as long as one does not share printers. Red Hat does this with systemd, see http://0pointer.de/blog/projects/socket-activation2.html.
<slangasek> tkamppeter: yes, I understand that constraint; we need the package to continue to work correctly for users who *do* share printers
<pitti> why doesn't it work with printer sharing, provided that it's also activated on the TCP port?
<slangasek> pitti: because cups has to advertise the printers
<pitti> ah, ok (I thought it would be sufficient to tell avahi once, but I don't know how this stuff works in detail)
<pitti> thanks
<tkamppeter> pitti, yes, it should do. I only do not know whether CUPS will then be kept up permanently by avahi-daemon. What probably will not work well is turning on legacy CUPS browsing in cups-browsed, but this we have off by default anyway.
<tkamppeter> slangasek, AFAIK avahi-daemon advertizes the printers, but I do not know how often avahi-daemon communicates with cupsd for that.
<slangasek> tkamppeter: avahi-daemon doesn't parse cups's config to advertize them; it needs cups to be running so that it can push this info to avahi
<tkamppeter> slangasek, so we need to do on-demend cups only if no printers are shared, and sharing on the phone will never happen, so on the phone it would actually stay on-demand. If printers are shared CUPS shopuld be started at boot time and stay running, this will only happen if a user actually opts for sharing, and this is usually on a PC or server.
<barry> mitya57: it's a dep of python-autopilot-tests, and i'm not sure what's going to happen with that package yet, so i guess it will just follow p-a-t
<tkamppeter> slangasek, so we chack at boot via cups' config files whether we are sharing and only if so (or if we have still jobs from before last shutdown) we start CUPS at boot. CUPS stays running as long as printers are shared or as jobs are still to be processed. If all jobs get printed and all printer sharing turned off, CUPS stops and is startable on-demand. If printer sharing or jobs still are there up to system shutdown, CUPS only stops
<tkamppeter> with shutdown.
<slangasek> tkamppeter: you can't easily make the upstart jobs on disk vary with the cups config
<tkamppeter> slangasek, this way on servers CUPS runs permanently as before, on other machines on-demand.
<tkamppeter> slangasek, is it not possible in the cups.conf to read a config file and the env variables and then decide on whether run the daemon or not?
<slangasek> tkamppeter: possibly
<slangasek> tkamppeter: that does imply you need two different jobs on disk, for the two different ways of starting it
<tkamppeter> slangasek, are you in London next week?
<slangasek> tkamppeter: no
<tkamppeter> slangasek, I am there due to a desktop sprint. Probably I will you contact several times on IRQ and/or report bugs on Upstart.
<tkamppeter> slangasek, I have to go out for ~30 min now. After that I am back and I will try some more things.
<xnox> tkamppeter: i'll be in on monday.
<mitya57> barry: Ok, my main concern is whether pyqt5 is going to be in main...
<barry> mitya57: yep. dunno about that, but my window-mocker port should be pretty easy to switch back to pyqt4 if needed
<mitya57> No, please don't do that :)
<jtaylor> barry: I have a new numpy merge, current numpy in trusty breaks pandas :(
<jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/trusty/python-numpy/new-upstream-20140124/+merge/203159
<barry> jtaylor: you'll have to ping me next week, if you don't find someone to take a look before then
<barry> slangasek: i do not think it's in dbus.  dbus_1.6.18-0ubuntu1_i386.deb was the last release *before* the last system-image release, and it's exhibiting the same crash
<pranith> Hi, How do I request a sponsor for a package in my PPA?
<mdeslaur> infinity: mind if I merge libyaml?
<barry> slangasek: i'm not suspecting apparmor either
<infinity> mdeslaur: Go nuts, I'm not attached to TIL for FTBFS fixes.
<mdeslaur> infinity: yeah, I figured. thanks.
<PaulW2U> 5
<roaksoax> stgraber: howdy! I was wondering if you could process both maas-test and crochet from the trusty new queue if you are not too busy :)
<stgraber> roaksoax: at the pub in London at the moment, so not the best time for new reviews I'm affraid :)
<roaksoax> stgraber: bummer! enjoy!
<roaksoax> stgraber: (bummer for me that I'm not at a pub in London :) )
<tkamppeter> slangasek, still around?
<hallyn> why pray tell is ubuntu-desktop depending on click?
<hallyn> cjwatson: ^ ?
<bkerensa> Do we know why wpasupplicant is included in Ubuntu Server?
<infinity> bkerensa: It's not?
<stgraber> possibly for 802.1x authentication
<infinity> Oh, it's in the 'server' task.
<infinity> I never install that...
<bkerensa> infinity: all the cloud providers do
<bkerensa> just saw it when pulling updates and was like huh
<hallyn> apparently there are server farms which need it.
<hallyn> OTOH, i don't see why i need click running on my laptop
<infinity> What's pulled click in on your laptop?
<hallyn> infinity: near as i can tell, ubuntu-deskto
<hallyn> but it runs under lightdm's userid
<hallyn> i can't purge it, and it wants to respawn
<hallyn> (even when i mark the clickitywahtever.conf job manual)
<infinity> Ugh.
<slangasek> hallyn: marking it 'manual' doesn't affect the current running job which would still respawn if that's how it's configured
<hallyn> slangasek: thing is i dont' see an upstart job for it
<hallyn> it feels lieka  virus
<slangasek> tkamppeter: not really, just stopping in on my way to bed, early flight tomorrow :)
<slangasek> hallyn: ah, no idea then
<slangasek> hallyn: /usr/share/upstart/sessions/click-user-hooks.conf ?
<hallyn> slangasek: gah, so i can't just look under /etc/init?  still, i get:
<hallyn> serge@tp:~$ sudo initctl list|grep click
<hallyn> click-system-hooks stop/waiting
<hallyn> click-apparmor stop/waiting
<hallyn> how can i list the instances?
<slangasek> hallyn: you're sitting next to jodh, have him show you ;)
<hallyn> hey jod
<hallyn> oh, he doesn't sit on irc
<sarnold> lol
<stgraber> for those missing context, jodh, hallyn, infinity and slangasek are all at most 10m apart
<pranith> hi, I am looking for a MOTU sponsor...
<hallyn> stgraber: 10 minutes is a long walk to ask such a question
<stgraber> for anyone looking at this channel earlier, the click/content-hub/... issue that's causing some machines to use 100% of CPU is caused by a dependency change in unity-webapps-qml
<stgraber> as it's late here and we don't want this broken for the weekend, I'm uploading a revert
#ubuntu-devel 2014-02-01
<tkamppeter> slangasek, where are you flying to? Are available on IRC next week?
<xnox> slangasek: cjwatson: jdstrand: mdeslaur: with updated ovmf, SecureBoot keys survive OVMF cold-boot. Also efi manager "ubuntu" entry is set/saved, but fails to boot -> investigating.
<xnox> slangasek: cjwatson: mdeslaur: we should be able to automate smoketesting in uefi / SecureBoot / modes, once boot entry is sorted.
<xnox> slangasek: cjwatson: filed bug #1275162 with boot entries that generated update-grub and don't work + working entries as added from efi shell using "fs1:\EFI\ubuntu\shimx64.efi" and the mapping that resulted from doing that.
<ubottu> bug 1275162 in grub2 (Ubuntu) "incorrect efibootmgr command is set by update-grub under OVMF" [Undecided,New] https://launchpad.net/bugs/1275162
<xnox> stgraber: ^ might find interesting as well =)
<jhenke> Hi!
<jhenke> is by chance anybody here feeling responsible for the boot process/uefi boot entries/grub?
<slangasek> tkamppeter: flying to> I'm flying home from a sprint; so yes, I'll be on IRC next week, in my usual timezone (US/Pacific)
<slangasek> xnox: ovmf> huzzah! what options do we need to pass to give the qemu session somewhere to write the nvram to?
<slangasek> (and can we make it COW so that we can distribute a pre-configured nvram blob?)
<xnox> slangasek: cp /usr/share/ovmf/OVMF.fd .; qemu -pflash OVMF.fd -cdrom ubuntu-desktop.iso
<slangasek> so you have to copy the whole firmware image?  Not ideal
<xnox> slangasek: you can "boot" ovmf.fd and enroll keys the usual way.
 * slangasek nods
<xnox> slangasek: yeah, parts of the firmware image is reserved memory for nvram.
<xnox> slangasek: not sure if one can make it a qcow2 image with 3 snapshots (empry, microsoft keys, custom keys)
<xnox> but due to efibootmgr / update-grub bug it doesn't generate the correct boot entry on install.
<xnox> maybe we should ship keys in the installer and allow pre-seeding key enrollment at install time.
<TJ-> xnox: So with some jigging about with loop and md linear we could create a writable firmware that puts the NVRAM in a separate file... cool!
<xnox> TJ-: interesting idea. let me talk to #edk2 people on OFTC about it.
<TJ-> xnox: I use that approach for repairing broken block devices; create a 1MB file and chain the file-system onto it, to enable booting block devices that do not contain partition tables.
<slangasek> xnox: was that bug reproducible when using a *not* nvme disk?
<xnox> slangasek: correct.
<slangasek> ok
<xnox> slangasek: ubuntu-custom -> is the working nvme disk; ubuntu-custom-normal -> is the working -hda qemu default disk; ubuntu is the entry that update-grub generated.
<slangasek> ok
<xnox> slangasek: since update-grub does work correctly on real uefi laptops, i wonder if OVMF is being funny here.
<xnox> i guess there a multiple ways of addressing UEFI hardware, cause my laptop is using Boot0000* ubuntu	HD(1,800,8e800,ad01ebb3-3866-4648-b8a0-e126abbc6817)File(\EFI\ubuntu\shimx64.efi)
<xnox> which is partuuid addressed HD.
<slangasek> multiple ways> indeed
<xnox> slangasek: so for some reason update-grub is using "short fs-uuid" (mbr style), instead of "full gpt partition uuid" (gpt style)
<xnox> under ovmf.
 * slangasek nods
<slangasek> actually, that should be all efibootmgr, shouldn't it?  I didn't think update-grub did the calculation
<tkamppeter> slangasek, I am flying to a sprint tomorrow. I have tested socket triggered CUPS start with Upstart, CUPS gets actually started, but is not able to overtake the socket FD.
<slangasek> tkamppeter: you know that the upstart and systemd socket activation protocols are different?
<slangasek> (this is something we intend to fix on the upstart side, but not immediately)
<tkamppeter> slangasek, did not know that and started systemd-like, now I have seen in the man page that one has to accept() the FD and so I have done an upstart_checkin function like this: http://paste.ubuntu.com/6856965/
<tkamppeter> slangasek, but this still not works and I get "upstart_checkin: Unable to get local address - bad file descriptor", so the accept() failed.
<slangasek> tkamppeter: ok.  I don't know the answer offhand; I've never written code to use upstart's socket activation (and didn't write the upstart code either), I would have to dig into it
<tkamppeter> slangasek, the original author is Scott James Remnant?
<slangasek> tkamppeter: yes, and he's no longer involved in upstart development.  I believe jodh did the landing of the code in upstart upstream, so he might be able to help
<xnox> tkamppeter: i did write code that successfully used upstart-socket activation.
<xnox> tkamppeter: it was a python daemon however, but semantics are the same across any language.
<tkamppeter> xnox, can you send me the code or a link to it?
<tkamppeter> slangasek, thank you very much, will talk with jodh (James Hunt?) and xnox. I will come back to you next week if needed.
<xnox> tkamppeter: http://cheesehead-techblog.blogspot.co.uk/2013/12/upstart-socket-bridge.html
<xnox> tkamppeter: article was updated with my patches, so all should be good.
<xnox> tkamppeter: i'll be in Bluefin on monday, if you are there as well.
<xnox> tkamppeter: yeah, jodh is James Hunt.
<xnox> here is uwsgi support for using socket activation with upstart
<xnox> http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html
<tkamppeter> xnox, thank you very much!
<tkamppeter> xnox, I will be in Bluefin next week, too. So we can meet and get it working.
<xnox> tkamppeter: i'm there on monday only, not all week.
<tkamppeter> xnox, no problem, we can meet on Monday.
<tkamppeter> xnox, I have looked in your C code and it seems to be the same as I did in CUPS (see http://paste.ubuntu.com/6856965/) but in CUPS it does not work.
<xnox> tkamppeter: i'm not in the mood to dive into it, can you push a branch with it and i will look into it on monday?
<xnox> tkamppeter: i'm deep in python3 porting at the moment.
<tkamppeter> xnox, we should also talk about HPLIP then ...
<xnox> tkamppeter: ha, yeah =) doko was at bluefin last week.
<Noskcaj> xnox, on the topic of python3, the new pidgin is out. I've made a basic debdiff, but there's probably extra changes needed
<jhenke> hi, is by chance somebody here who could take a look at a bug related to efibootmgr/grub? bug #1272664
<ubottu> bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [Undecided,Confirmed] https://launchpad.net/bugs/1272664
<xnox> Noskcaj: well, have you fixed Bug #1272455 yet?
<ubottu> bug 1272455 in xchat-gnome (Ubuntu) "multiple issues with git20131003" [High,Confirmed] https://launchpad.net/bugs/1272455
<xnox> jhenke: is the VM booted in UEFI?
<jhenke> affirm
<jhenke> the problem is the creation of the uefi boot entry
<xnox> jhenke: it creates a wrong one or overrides existing ones?
<xnox> jhenke: i found with OVMF that wrong entries are generated.
<xnox> jhenke: so efibootmgr "manages" "ubuntu" boot entry, i've successfully created a different one, e.g. "ubuntu-custom" that works and those tend to persist.
<jhenke> not sure, as soon as an entry is generated the VM configuration becomes corrupted so you cannot access the VMs properties anymore nor does Hyper-V recognize it
<Noskcaj> xnox, no, sorry. I barely know C, let alone gtk
<Noskcaj> I'd not been able to reproduce the bug locally as i understood it, but i'm not sure there's anything i can do to that package
<jhenke> *not does Hyper-V recognize the VM any longer, sorry
<xnox> jhenke: i see. I'll ask cjwatson about it.  it's best not to corrupt VMs just because a package gets installed (abeit called efibootmgr)
<jhenke> indeed it is
<jhenke> basically right now you cannot properly install ubuntu in a gen 2 VM, which I think is very bad
<jhenke> thanks for pinging the right person :)
<xnox> cjwatson: assigned Bug #1272664 to you based on ^ maybe you can take a look at it.
<ubottu> bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [High,Confirmed] https://launchpad.net/bugs/1272664
<wgrant> It's a bit of a worry that a VM can affect the hypervisor like that.
<wgrant> Sounds like a Hyper-V bug...
<xnox> slangasek: edk upstream says that they are working with qemu to provide external variable storage, but it's not implemented in qemu yet. So current storage arrangement is the current state of the art.
<jhenke> I guess it is proably due to the facct that efibootmgr interacts slightly differently with the uefi than windows does
<jhenke> since installing windows 2012r2 works well and the uefi boot entry is created correctly
<jhenke> so efibootmgr must doing it a bit differently which causes this problem
<tkamppeter> xnox, doko, reported HPLIP upstream bug https://bugs.launchpad.net/hplip/+bug/1275353.
<ubottu> Launchpad bug 1275353 in HPLIP "Make HPLIP working with Python 3" [Undecided,New]
<xnox> tkamppeter: that bug is not new.
<xnox> tkamppeter: some dependencies are ported but not all, and needs further investigation.
<tkamppeter> xnox, but is it already reported to HPLIP upstream?
<xnox> tkamppeter: barry was involved it in.
<xnox> tkamppeter: i believe doko did talk with hplip upstream about it, yes.
<xnox> tkamppeter: you need hplip urgently on the phone?
<tkamppeter> xnox, important is that we do not carry a huge Debian/Ubuntu patch but upstream switches over.
<tkamppeter> xnox, HPLIP is not needed on the phone at all, I thought they talked to me because of getting rid of Python 2 in general, also on the normal desktop.
<tkamppeter> xnox, on the phone printing will only be done to network printers with known standard languages, not with tons of printer-model-specific drivers.
<xnox> tkamppeter: cool. yeah getting off python2 is a general goal on touch/server/desktop.
<xnox> tkamppeter: so any help on that front is greatly appreciated.
<slangasek> xnox: ack
#ubuntu-devel 2014-02-02
<Ademan> is there a reasonable way (maybe through dbus) 1. when the screensaver goes active/the screen is locked and 2. when the user is prompted for their password? (I want to run some intense stuff during idle time, and disable it as soon as the user is prompted for their password, as it causes significant keyboard latency)
<Ademan> Hrm  AuthenticationRequestBegin exists, but only on org.gnome.ScreenSaver, is there no freedesktop interface?
<c_korn> how can I tell ant to take openjdk-7-jdk for compiling (which I installed) and not to use openjdk-6 (JAVA_HOME=usr/lib/jvm/java-6-openjdk-i386/jre).
<c_korn> ok, need to build-conflict on openjdk-6-jre-lib
<spec4d> I'm trying to get involved with Ubuntu development. Is there anything I should be reading to get started besides this wiki? http://packaging.ubuntu.com/html/
<Noskcaj> spec4d, depends on how you want to help
<Noskcaj> That's just packaging, and it's not particularly complete
<spec4d> well I've been trying to fix a bug with Ubuntu Software Center, but I can't even get that to compile for me to test the patch I wrote. I'm not really tied to any piece of software or project in Ubuntu at the moment. I'm just trying to get used to the process and contibute.
<Noskcaj> ok. A few questions. 1. what bug? 2. what version of ubuntu are you one? 3. Are there any specific packages you'd like to help with?
<spec4d> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1107824
<ubottu> Launchpad bug 1107824 in software-center (Ubuntu) "Not obvious how to access payment support from the UI" [Medium,Triaged]
<spec4d> ^easy stuff, but like I said I'm more concerned with just learning the process (for the moment)
<spec4d> I'm on 13.10
<darkxst> spec4d, how are you building the USC package?
<darkxst> also development of patches etc, should be done against the current devel series (i.e trusty)
<spec4d> of course :)
<spec4d> I've been trying to follow this. I got as far as the "testing the fix" section, but I don't know enough about USC bzr, pbuilder and dpkg to get it to compile. http://packaging.ubuntu.com/html/fixing-a-bug-example.html
<spec4d> I tried following the sources readme and that did not help either
<Noskcaj> Use "pbuilder-dist trusty amd64 create" to make a schroot, the "debuild -S" and "pbuilder-dist trusty amd64 build" to build it
<spec4d> Thanks I'll look into that. I'm used to using vbox in windows development, but I don't have that much experience with chroots.
<spec4d> The funny thing about programming is that the first part of the learning curve always looks like a cliff :)
<spec4d> But I have a CS degree so I'm used to that
<Noskcaj> spec4d, in the most basic form, a chroot is a temporary VM for building stuff in. one command and then it works then removes itself
<Noskcaj> and you're right. That's sorta why i still don't know any actual programming languages
<spec4d> I geuss I know what you mean. I don't know python, but that didn't stop me from writing this patch. lol
<darkxst> Noskcaj, don't spread lies :) a chroot is nothing like a VM
<Noskcaj> darkxst, it's still a decent explaination
<spec4d> Lol. I installed Crouton once on a chromebook so I already know the diff
<darkxst> and pbuilder is not really your typical chroot
<spec4d> But that was my only real experience with it
<Noskcaj> for -weather:  many icons are under a non-DFSG-compliant license
<Noskcaj> woops, wrong channel
<Noskcaj> darkxst, ^
<darkxst> Noskcaj, what license?
<Noskcaj> darkxst, I'll look into it tomorrow, that was just my reply from debian
<spec4d> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/software-center_13.05-0ubuntu4.diff.8WQK7Z
<spec4d> ??? Does that mean the source on my machine isn't latest
<darkxst> spec4d, that means the .orig tarball is probably messed up
<spec4d> I think what happened is BZR branched the 13.10 source instead of 14.04 and it's complaining about it not being latest. Does that make any sense?
<spec4d> Wait. Where am I supoused to grab source from. "bzr branch ubuntu:software-center" gives me an out of date copy. Should I be grabbing it using " bzr branch lp:software-center"
<spec4d> ?
<infinity> spec4d: If the Ubuntu branch is out of sync with the archive, what you want is "pull-lp-source software-center"
<infinity> Since the archive is authoritative.
<spec4d> Thanks infinity. That looks like it will work.
<Logan_> Hi Jackson.
<Noskcaj> oh, hey Logan_
<Noskcaj> i really need to pay more attention to irc
<Logan_> Or be pinged by "Jackson."
<Logan_> Because I often ping people with their real names. Just to be anarchist or something.
<Noskcaj> fixed
<Unit193> Logan_: Ping me? ;)
<Logan_> Hi Unit. :P
<Unit193> Eww.
<LBo> I'm creating a package  (my first). The program that I'm packaging creates two (empty) files on runtime. These files are not included in the source. I would like them to be installed with the package so the two files get removed when the package does
<LBo> I could add two `touch` commands in debian/rules
<LBo> Or I could add an extra patch to debian/patches which creates the two empty files
<Noskcaj> LBo, You can use a postrm script to make that unnecessary, or maybe make a blank file the us dh_install to put it where it's needed
<LBo> Noskcaj: where should I store those blank files?
<LBo> Is there a directory in debian/ where I can store such files?
<Noskcaj> debian/FILENAME
<Noskcaj> Although a postrm is probably the best solution
<LBo> ok
<LBo> And then use packagename.install to copy them to the right location?
<LBo> debian/packagename.install
<infinity> postrm is the right place to remove them.
<infinity> If they're generated at runtime, that is.
<infinity> They shouldn't be included or installed in the package at all.
<infinity> LBo: Also, what are these files?
<infinity> If they're being written, but in a read-only location (ie: anywhere in /usr), there's still something very wrong happening.
<LBo> infinity: It's a config file that is not included with the source but the program makes an empty file the first time it is ran
<infinity> So, it's in /etc?
<LBo> Yes
<infinity> You might want to ship a sane skeleton file, then.
<LBo> Yeah, that seems nice
<LBo> With some comments in it and an example
<LBo> I can store the skeleton file in debian/?
<infinity> For bonus points, I'd also patch out the part of the upstream source that thinks it's a good idea to write to /etc at runtime.
<LBo> OK
<infinity> Yeah, you can toss it in debian/foo.conf.example or something, and then install it.
<LBo> infinity: awesome, thanks
<arun> guys is this command correct sudo apt-ftparchive packages main | gzip -9c > dists/quantal/restricted/binary-i386/Packages.gz  ??
<xnox> arun: sudo is lost at pipe, and you are indexing /main/ directory and then call the result /restricted/
<arun> xnox: oh thank dude. I fixed it xD
<LBo> I'm having some troubles when building a source package from my package (https://github.com/LeonB/linux-malware-detect/tree/master)
<LBo> Building the binary works fine
<LBo> When I build the source package I get error messages when applying the debian/patches/
<LBo> These are the messages I get: http://paste.ubuntu.com/6864226/
<LBo> I've got a hunch the patches get applied twice?
<darkxst> LBo, looks like you need to refresh the patch, patches with 'fuzz' are not allowed.
<LBo> OK. What is fuzz?
<darkxst> it is basically telling you the hunk was applied, but patch is not sure that its correct
<jtaylor> LBo: are the patches accidentally applied in the orig tarball=
<LBo> jtaylor: could be that the error is in that direction
<LBo> I'm building from a git repository and not a tarball
<jtaylor> or its just a different snapshot
<jtaylor> its a bit weird it partially applies
<LBo> jtaylor: I cloned the repository from github in another directory and now it worked...
<LBo> So some kind of crap I did with my local repo I think
<LBo> jtaylor: Jay, it worked! https://launchpad.net/~leon-tim-online/+archive/linux-malware-detect
<LBo> Thanks!
<mwhudson> uh, is there a good reason for me having a file /etc/modprobe.d/intel_11n_disable.conf ?
<lifeless> n being broken?
<lifeless> it might not be anymore, but it was for a while
<RAOF> For what it's worth, I *don't* have that blacklist on trusty.
<mwhudson> yeah, i'm sort of hoping that it was created when i installed quantal or whatever version i first installed
<mwhudson> i hope it isn't broken now because my internet is now faster than g :)
<mwhudson> (is there some way i can tell which version i installed vs. upgrades?)
<mwhudson> hm, probably oneiric
<TJ-> mwhudson: Yes, you likely created to work around the Intel iwl4965 802.11n suffering lots of dropped packets
<RAOF> mwhudson: Yes, there's clearly some way, because apport has originally-installed-release data.
<RAOF> mwhudson: Also, that file doesn't appear in any supported Ubuntu release. Presumably we failed to remove it on upgrade at some point.
<mwhudson> RAOF: i may have created it myself at some point i suppose
<mwhudson> have no recollection of that though
<RAOF> Plausibly.
<RAOF> Anyway, enjoy your order of magnitude more wireless bandwidth!
#ubuntu-devel 2015-01-26
<Noskcaj> BenC, I don't have enough internet to check right now, but i believe there's a small database of debian developer locations used to find people for keysigning
<rsalveti> xnox: was syncing the package in the archive with the branch, because I was planning on doing a small upload against it
<rsalveti> wasn't in sync
<rsalveti> would be nice to keep the packages in sync with the uploads
<mitya57> lpotter: hi, is https://codereview.qt-project.org/102665 something we need to have in vivid 5.3.2 packages?
<mitya57> I see Timo uploaded that to a silo but didn't commit to bzr for some reason.
<pitti> Good morning
<pitti> gnuoy`: feel free to steal merges :)
<pitti> stgraber: network config which hangs> oh, can you please write a bug about that? will look at that ASAP
<stgraber> pitti: bug 1414544
<ubottu> bug 1414544 in systemd (Ubuntu) "Machine never boots, stuck at network bringup" [Undecided,New] https://launchpad.net/bugs/1414544
<pitti> stgraber: ah, merci
<dholbach> good morning
<LocutusOfBorg1> hi developers
<LocutusOfBorg1> hi pitti I'm wondering if my mail went into your spam folder :)
<pitti> LocutusOfBorg1: no, I still have Friday's and didn't get a new one
<LocutusOfBorg1> sent again :)
<pitti> LocutusOfBorg1: got it
<LocutusOfBorg1> wonderful!
<xnox> rsalveti: yes. sorry about that. In essence there was a branch with changes "~xnox/upstart/systemd-bridge" however I've used silo to land the upload.
<xnox> and it was manual dput, and separate branch
<xnox> and at cleanup I did not push the branch at the same time.
<xnox> sorry about that. Usually lp:ubuntu/upstart is up to date, or has staged changes to be uploaded next time.
<ari-tczew> xnox: ping
<xnox> ari-tczew: yo
<ari-tczew> xnox: question about esys-particle package. you've added a couple of files like /debian/test/* in release 2.2.u2-2ubuntu4, but Debian has applied only one file debian/test/box30.0.geo. however, Debian approved also autopkgtest.
<ari-tczew> xnox: can we sync that package?
<xnox> i did not intentionally add things to debian/test dir.
<xnox> do check if there is any delta left, and do test build in vivid before syncing
<ari-tczew> xnox: just FYI: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/esys-particle/vivid/revision/13
<ari-tczew> xnox: ok, delta is approved in debian and I'm building package right now.
<tseliot> infinity: hi, do you know if this fix has ever been included in glibc? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/967149
<ubottu> Launchpad bug 967149 in nvidia-graphics-drivers (Ubuntu) "Solution to Nvidia + cairo-gl memory problem proposed by Nvidia" [Undecided,Confirmed]
<Madkiss> hey there.
<Madkiss> is ppa.lp.net down?
<ivoks> Madkiss: some network issues... should be over soon, if it's not already
<Madkiss> ah, alright, thanks
<dholbach> slangasek, who can help with the following merge proposals?
<dholbach> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate/+merge/246189
<dholbach> https://code.launchpad.net/~ubuntu-mate-dev/ubiquity/ubquity-mate-fixed/+merge/246079
<dholbach> https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/livecd-rootfs-ubuntu-mate/+merge/244446
<xnox> dholbach: i've tried mvo , infinity is a good one to try as well
<xnox> i can do ubiquity myself, but at the moment my ubuntu time is focused on the hardest stuff i can work on (i.e. upstart->systemd)
<cyphermox> xnox: thanks, I'm aware. I'll upload the fix in a bit
<mlankhorst> what's gmsh?
<mitya57> mlankhorst: http://launchpad.net/ubuntu/+source/gmsh â "Three-dimensional finite element mesh generator"
<mlankhorst> I'm more curious how it blocks mesa..
<mitya57> oh, an autopkgtest failure
<mitya57> That seems to be a random segfault as it succeeded on amd64 and failed only on i386
<mitya57> Perhaps pitti can retry it.
<mlankhorst> oke
<mlankhorst> pitti: ^ ?
<pitti> (already at it..)
<mlankhorst> thanks
<pitti> err no, it's not random
<pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-gmsh/?
<pitti> it has never succeeded
<pitti> i. e. it has always failed on i386, and succeeded on amd64
<mlankhorst> ok could you override mesa then?
<pitti> jibel: do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mesa happens even though gmsh never succeeded?
<pitti> jibel: https://jenkins.qa.ubuntu.com/job/vivid-adt-gmsh/?
<pitti> mlankhorst: I will, but we shoudl investigate this first ^; I think I've seen it on other occasions
<mlankhorst> maybe because amd64 passes?
<jibel> pitti, looking
<shadeslayer> is there a way to get pull-lp-source to download from vivid instead of vivid-proposed?
<pitti> shadeslayer: just add "vivid" as the second argument
<shadeslayer> pitti: doesn't work :(
<pitti> shadeslayer: or "precise", "trusty-proposed", etc.
<shadeslayer> try doing it for firefox
<pitti> shadeslayer: sorry, "vivid-release"
<shadeslayer> it downloads 36 here
<shadeslayer> ah
<shadeslayer> yep, that does the trick, thanks
<rbasak> You can also just use the exact version string you want as the second argument.
<rbasak> (assuming you know it already and don't have to go look it up)
<xnox> shadeslayer: vivid-release
<xnox> oh, sorted
 * xnox is slow
<shadeslayer> xnox: yeah :D
<shadeslayer> btw firefox 35 never migrated to the release pocket in vivid?
<xnox> shadeslayer: you should know how to check that yourself by now.
<xnox> shadeslayer: using docs at https://wiki.ubuntu.com/ProposedMigration
<shadeslayer> xnox: yeah, I'm just curious if someone is looking into that? or no ff 35 for vivid?
<shadeslayer> rmadison says only 34 is available in -release and 36 in proposed, and 35 in proposed for architechtures that 36 didn't build on
<xnox> shadeslayer: yeah, so what?
<shadeslayer> xnox: so vivid users don't get FF 35
<xnox> shadeslayer: 35 ftbfs on armhf, 36 ftbfs on arm64/powerpc/ppc64el. but only a complete set is ever considered for migration.
<shadeslayer> they'll just go from 34-36?
<shadeslayer> right, so no 35 for vivid then
<xnox> shadeslayer: read ProposedMigration page....
<slangasek> dholbach: cyphermox is your man
<cyphermox> howdy!
<dholbach> ah ok, thanks
<dholbach> cyphermox: I just askef for flexiondotorg_ who could review his MPs:
<dholbach>  https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate/+merge/246189
<dholbach>  https://code.launchpad.net/~ubuntu-mate-dev/ubiquity/ubquity-mate-fixed/+merge/246079
<dholbach>  https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/livecd-rootfs-ubuntu-mate/+merge/244446
<dholbach> s/askef/asked
<cyphermox> yep, just opened them from scrollback
<cyphermox> I'll review
<LocutusOfBorg1> thanks pitti :)
<cyphermox> flexiondotorg_: if you're around, I noticed there's a typo in your change to tools/add_live_filesystem for debian-cd; if you want to fix that while I continue the review.
<slangasek> cyphermox: thanks :)
<brainwash> we would like to push a micro release update for xfdesktop4, but it's stuck in trusty-proposed since 2 months. this bugfix update does not resolve one of the several issues completely (it's triggered less often), and therefore the verification has been marked as FAILED. however, people did not notice any regressions or new bugs.. so, can I mark the verification as DONE?
<brainwash> it's bug 1365965
<ubottu> bug 1365965 in xfdesktop4 (Ubuntu Trusty) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1365965
<mitya57> Laney, hi, can you top-approve https://code.launchpad.net/~mitya57/ubuntu-themes/wncktask/+merge/245292 please? It has been approved by larsu but he can't set the status.
<Laney> he should get in the team
<Laney> who is Frank Schoep?
<Laney> but yes, fine
<mitya57> Laney: thanks
<ari-tczew> cyphermox: congrats on get network-manager merged! I think it was a huge job.
<bdmurray> pitti: Is it time to enable apport reporting to launchpad for Vivid?
<cyphermox> ari-tczew: you have no idea ;P
<ari-tczew> cyphermox: well, s/I think/I guess :P
<cyphermox> heh. there was a test regression I hadn't quite squashed properly though, so there's an update still waiting to get to proposed; depwait due to libndp
<pitti> bdmurray: after alpha-2 is kind of the traditional time; at some point we wanted to phase this out in favor of just errors.u.c., but I guess until we have the more elaborate "additional plugin to collect more information" powers, we should keep LP for devel?
<ari-tczew> cyphermox: yeah, I'm looking now on bug 1392385
<ubottu> bug 1392385 in libndp (Ubuntu) "[MIR] libndp" [Undecided,Fix committed] https://launchpad.net/bugs/1392385
<pitti> hallyn, stgraber: new systemd uploaded with the lxc cgroup ownership fix, works great now!
<bdmurray> pitti: I think so yes
<stgraber> pitti: great, thanks!
<pitti> it'll be stuck in -proposed for a fair while though; powerpc builders are clogged, and arm64 too
<stgraber> pitti: so I guess that means LXC no longer is a blocker for the switch to systemd
<hallyn> pitti: cool, thanks
<pitti> stgraber: indeed not; it's pretty much down to maas and juju now (for !touch)
<pitti> hey stgraber -- did you arrive in one piece this time, without further cancellations?
<hallyn> he hasn't left :)
<hallyn> safely hasn't left
<pitti> ah
<stgraber> pitti: leaving for the airport in ~4 hours
<stgraber> arriving at 1pm tomorrow (instead of the original 8am)
<pitti> bdmurray: uploaded
<pitti> infinity: are adare and ross down deliberately, or is teh "no route to host" a glitch?
<pitti> stgraber, hallyn: oh, does the new lxc release include the fix for bug 1350947? it got committed upstream months ago, so I figure it did?
<ubottu> bug 1350947 in lxc (Ubuntu) "apparmor: no working rule to allow making a mount private" [High,Fix committed] https://launchpad.net/bugs/1350947
<pitti> ah yes, it does
<pitti> \o;
<pitti> ouch -- \o/
<hallyn> "doc it hurts when I do this:  \o;".  "don't do that then"
<slangasek> mlankhorst: hi, so I notice trusty already has llvm-3.5 binary packages, from llvm-toolchain-snapshot; instead of adding a new llvm-toolchain-3.5 package in SRU, can we just use the existing llvm-toolchain-snapshot source package name?
<infinity> pitti: Not sure what the state of ross and adare are right now, but we also haven't been using them for months.
<doko> slangasek, mlankhorst: yes in theory, but haven't checked for packaging changes. and the llvm-toolchain-snapshot package is now blacklisted. not sure if this is relevant for trusty
<slangasek> doko: packaging changes shouldn't matter, really?  whatever's in utopic for llvm-3.5, we would take as part of the HWE stack, this would just be taking over the llvm-toolchain-snapshot source name to reduce the archive inconsistency
<infinity> rbasak: Any progress on LP: #1412830 ?
<ubottu> Launchpad bug 1412830 in spamassassin (Ubuntu) "[AHBL] spamassassin is returning false positives by default" [Critical,Triaged] https://launchpad.net/bugs/1412830
<infinity> rbasak: I just realised I've been rejecting some mail because of it. :/
<flexiondotorg_> cyphermox, Thanks for reviewing my merge proposals.
<flexiondotorg_> cyphermox, I'll prepare re-submissions based on your feedback.
<cyphermox> flexiondotorg_: cool; let me know and I'll merge what I can :)
<flexiondotorg_> cyphermox, https://code.launchpad.net/~ubuntu-mate-dev/ubiquity/ubquity-mate-fixed/+merge/247641
<bluefoxxx> Anyone else on 14.10 experiencing this?
<bluefoxxx> http://pastebin.com/NVAv2Rrf
<bluefoxxx> 15:59:54 up 2 days, 22:53,  3 users,  load average: 1.87, 0.72, 0.52
<bluefoxxx> I'm using Chromium browser, Virtualbox, and Gnome-3.  /home is a separate hard disk entirely.
<bluefoxxx> Nothing in particular going on, it's just a desktop.
<bluefoxxx> Obviously, there are some 34GB of deleted files.  I reclaimed about 1GB by SIGHUP'ing update-manager (it was holding open deleted partial package downloads)
<rbasak> infinity: I asked kickinz1|afk to look at it but he had to take this afternoon off. I'll follow up tomorrow.
<infinity> rbasak: Kay.  It's pretty critical for people who haven't noticed yet. :/
<infinity> rbasak: Once I realised the problem, was easy enough to comment out the bits, but I'm sure there are lots of people out there silently dropping mail on the floor without knowing, which sucks.
<infinity> (Which was me, up until my brother complained a few hours ago)
<bluefoxxx> why oh why isn't there an open-deleted-file histogram tool
<bluefoxxx> that needs to be an option in ncdu
<bluefoxxx> I'm having no luck tracking this down with lsof :|
<infinity> bluefoxxx: Not to be facetious or ruin your fun, but if you're putting that much effort into hunting down open handles on deleted files to try to fix them, why not just reboot and be done with it?
<bluefoxxx> infinity, the system has been up for 2 days and done nothing special
<bluefoxxx> Am I to believe Ubuntu simply bloats space usage with deleted files as normal, accepted behavior, and will use dozens of gigabytes of space and need a reboot every couple days?
<bluefoxxx> 13GB of files, 47GB of used space
<infinity> bluefoxxx: No.  And that's not "normal" here.
<bluefoxxx> that's my issue
<bluefoxxx> nobody told me there was a 100GB / partition requirement to run this system
<infinity> bluefoxxx: So whatever non-special thing you aren't doing, I'm not doing it harder. :P
<bluefoxxx> wait.  it's btrfs.
 * bluefoxxx squints really hard.
<jrwren> ha! btrfs strikes again.
<bluefoxxx> oh haha.
<bluefoxxx> Can you guess what happened?
<bluefoxxx> http://pastebin.com/Z6v1e7e5
<infinity> bluefoxxx: That doesn't look like it "suddenly" happened over 2 days. :P
<bluefoxxx> infinity, I said it's been up for 2 days
<bluefoxxx> I didn't say i ever looked before
<bluefoxxx> also, holy crap, snapshots have been automatic since quantal
<bluefoxxx> well, that got me down to 35G.  :|
<bluefoxxx> I'll continue my investigation.
<flexiondotorg_> cyphermox, Thank you!
<cyphermox> flexiondotorg_: np. maybe by tomorrow we can merge things, I need to wait for mvo and cjwatson for some questions and some buttons I can't push  ;)
<flexiondotorg_> cyphermox, No probs. Thanks for helping.
<infinity> utlemming: Can you look at LP: #1414752 and reassign, fix, close as appropriate?
<ubottu> Launchpad bug 1414752 in Ubuntu on EC2 "Ubuntu Trusty AMD64 Cloud Image is i686" [Undecided,New] https://launchpad.net/bugs/1414752
<utlemming> infinity: ack, looking now
<smoser> does anyone else belive that update-initrramfs gets called during 'apt-get upgrade|isntall' more than its supposed to?
<utlemming> *\
<infinity> smoser: Yes, Andy and I have a plan.
<sarnold> infinity: yay :)
<smoser> infinity, is there a bug ?
<infinity> smoser: There may be, but we're not tracking one that I know of.
<infinity> smoser: It's a fundamental rewrite of how initramfs-tools and the kernel interact for triggers, not a simple "oh, this is a bit broken" bugfix.
<infinity> pitti: Don't suppose you're still around?
<infinity> mlankhorst: Minor complaint (which I'm not rejecting for, but should be fixed).  Many of the lts-X packages have a symlink to usr/share/bug/xserver-xorg-core/script which isn't being placed in the right renamed spot.
#ubuntu-devel 2015-01-27
<nagromlt> who here likes ubuntu
<pitti> Good morning
<pitti> infinity: ah, ok; they don't have anything in particular in their status other than an obsolete error message, so I didn't dare and turn them to auto again
<pitti> infinity: oops, did you see that glibc fails to unpack now?
<pitti> infinity: I'm aware of debian bug 776257, could it be that?
<ubottu> Debian bug 776257 in patch "Fails to apply patch with dangling symlink" [Serious,Open] http://bugs.debian.org/776257
<pitti> would be weird if patch would have gotten broken in two different ways
<pitti> rbasak: did you see that mysql-5.5 is stuck in -proposed as it seems to make pinba-engine-mysql-5.5 uninstallable?
<infinity> pitti: I saw the test failure, but I can't reproduce it, so I have no idea what autopkgtest is doing differently.
<infinity> pitti: Downloading the source and running dpkg-source -x works fine.
<pitti> infinity: I can reproduce it easily here
<pitti> infinity: i. e. mere apt-get source glibc under vivid
<infinity> pitti: Oh.  Maybe my patch isn't up to date.  Didn't see the bug was patch, not dpkg.
<pitti> infinity: do you have patch 2.7.3-1?
<infinity> pitti: No, 2.7.1-7 ... Hence why I couldn't reproduce.
<infinity> pitti: Anyhow, I *could* fix the git-updates patch, but really, patch needs fixing.
<pitti> infinity: in the systemd package I worked around that by changing my patch to not create a dangling symlink, but it was trivial there
<pitti> infinity: yes, indeed
<infinity> pitti: Given that my git-updates patch is auto-generated, I don't really want to mangle it to work around bugs.
<pitti> anyway, I need to leave for the train station, bbl
<infinity> pitti: Thanks for the bug pointer, though, I was stumped.
<pitti> infinity: yeah, me too when I saw the systemd bug report
<pitti> infinity: was that what you pinged me about last night?
<dholbach> good morning
<infinity> pitti: It was, yeah.
<mlankhorst> morning
<mlankhorst> infinity: that might be on purpose
<mlankhorst> not 100% sure
<mlankhorst> in case other packages depend on it
<mlankhorst> infinity: /usr/share/bug/xserver-xorg-core/script is a symlink to ../xserver-xorg-core-lts-utopic/script
<mlankhorst> oh you mean the specific packages, hmm..
<mlankhorst> I'll fix that for the -vivid backprot
<pitti> jibel: did you see anything weird about the gmsh test? i. e. always failed on i386, always passed on amd64, but britney considers it a regression?
<jibel> pitti, I didn't find why. And it is just for gmsh/mesa.
<jibel> pitti, you can force the result in the history file
<pitti> jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough
<pitti> jibel: ok, doing that then; I did the same for a similar case recently, but it's happending seldomly enough
<Laney> (echo in here)
<pitti> I got disconnected after lagging for 5 mins, I wasn't sure if my last message went through :)
<Laney> :P
<pitti> ... through .... through
<pitti> mlankhorst: I forced gmsh, mesa should propagate now
<highvoltage> wom 21
<highvoltage> oh my
<mlankhorst> thanks
<LocutusOfBorg1> hi dear developers
<LocutusOfBorg1> mdeslaur, how do you feel about getting openssl 1.0.2 into vivid? Just asking since you said that the merge was in hold until the next release
<LocutusOfBorg1> of course I can do the merge and give it to you for review
<LocutusOfBorg1> hi folks, why virtualbox/precise-proposed didn't migrate yet?
<LocutusOfBorg1> in proposed since  2015-01-16
<rbasak> pitti: no, I wasn't aware (it was a security upload). I'll look - thanks.
<rbasak> Looks like pinba-engine-mysql just needs a no change rebuild every time there's a new microrelease of MySQL.
<rbasak> I wonder if that means its uninstalling in stable releases as well.
<rbasak> Indeed it does.
<rbasak> mdeslaur: ^^ something to be aware of. Looks like a no change rebuild is required for every release for every mysql 5.5 microrelease if we don't want to break pinba-engine-mysql.
<rbasak> I'd argue that the strict versioning is wrong, mind. There should not be any ABI breaks in microreleases.
<rbasak> Nobody has complained, either. There are no Launchpad bugs for the package.
<rbasak> Ubuntu popcon reports: 1 install, no votes.
<rbasak> Looks like it's been blocked from jessie for almost a year for the same reason.
<Laney> Don't think Ubuntu popcon really works any more, so I wouldn't use that for data
<rbasak> No uploads in Debian in that time.
<rbasak> (unrelated) How do I find reverse dependencies for a virtual package?
<rbasak> apt-cache rdepends doesn't seem to know about these; nor "reverse-depends"
<rbasak> Do I need to resort to grep-dctrl?
<pitti> Laney, cjwatson: hm, so I don't understand why systemd breaks libguestfs at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> systemd in -proposed drops the obsolete libsystemd-{login,journal,daemon,id128-}0 libs, but there are no reverse dependencies any more
<pitti> all of these binary packages install just fine in a vivid-proposed schroot
<pitti> and libguestfs0 now depends on libsystemd0 only
<pitti> (and that rebuild already propagated)
<pitti> any idea what I can do to find out what britney is complaining about?
<pitti> there's some NBS involved here, but I can't possibly remove the old libs from vivid before -6ubuntu1 gets promoted to vivid
<Unit193> Laney: Re: popcon.  At least right now, it's broken (not updating the page correctly) again, but since it's opt-in anyway...  Normally rt needs poked to fix it, and it seems to break every few months.
<Unit193> And indeed, congrats making it another year.
<pitti> didrocks: btw, I sorted out https://translations.launchpad.net/ubuntu/vivid/+source/systemd/+imports
<pitti> should appear in the next langpacks
<sitter> didrocks: heya, I hear we are getting bluez5 in vivid? any ETA on that? ;)
<pitti> sitter: I think that's more a question for cyphermox?
<ogra_> and i guess it really depends how fast the phone can get ported over
<brainwash> can someone please move xfdesktop4 from trusty-proposed to -updates? bug 1365965
<ubottu> bug 1365965 in xfdesktop4 (Ubuntu Trusty) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1365965
<Laney> pitti: hmm, let's see
<sitter> ogra_: that isn't even ported yet :O
<cjwatson> pitti: libguestfs0 still Depends: libsystemd-journal0
<cjwatson> pitti: if you tried to rebuild to make shlibdeps go away, then I think perhaps it has a hardcoded dep in debian/control
<Laney> It's put in there by a substvar which comes from some data in the source tree
<cjwatson> ah yeah
<cjwatson> ./appliance/packagelist.in:81:  libsystemd-journal0
<ari-tczew> cyphermox: the merge for isdnutils from unstable is quite ready, but now came another problem. libcapi20-3 is now in separated package, which we need yet to sync.
<pitti> Laney, cjwatson: no, I already checked that debian/control doesn't have a hardcoded dep (it did, but I fixed those)
<pitti> I rebuilt it locally, and it only depends on libsystemd0; ubuntu4 now also does that
<pitti> ah, I'll try to update ./appliance/packagelist.in too, although I don't see how that affects the built debs
<cjwatson> It's via a twisty chain of stuff
<cjwatson> I didn't bother to fully investigate but it's fairly clear from ${appliance:Depends}
<didrocks> sitter: depends on the phonefundation team for Touch, blocked on their kernel and integration
<didrocks> sitter: I noticed that rsalveti put that on their list for the next few weeks
<sitter> goody, thanks for the update :)
<didrocks> yw!
<rbasak> infinity: around?
<rbasak> (mysql)
<mdeslaur> rbasak: hrm, interesting, but also a PITA for something potentially nobody uses :)
<rbasak> mdeslaur: yeah. I'm tempted to ignore it unless someone complains, given that it's not in jessie and appears unmaintained.
<mdeslaur> rbasak: +1
<rbasak> mdeslaur: (except to no-change rebuild in vivid and future development releases which we need for proposed migration)
<mdeslaur> oh, vivid didn't migrate? sorry about that, I had not noticed
<xnox> didrocks: pitti: i'm starting to work on "/dev/null to remove wants" set of patches for systemd
<xnox> at the moment only did a trivial: systemctl --system --global enable to generate symlinks in /lib
<xnox> instead of /etc
<xnox> where shall i send this work in progress?
<xnox> and/or publish.
<didrocks> xnox: maybe we should get some kind of upstream agreement?
<xnox> didrocks: we do.
<didrocks> hum, I missed that message on the ML
<xnox> didrocks:  in december archives lennart said that he will take patches that cleanly implement logic as specified to "unwant if symlink target is to /dev/null" I believe i've added links to the messages from lennart on the pad
 * xnox makes a git repository
<xnox> on github
<didrocks> xnox: but not on the --global -> symlinks
<xnox> didrocks: yeah, but it's kind of convenient to have whilst hacking on these things =)
<xnox> didrocks: plus e.g. i imagine we would want packaging to use --system --global to genere symlinks at package built time or some/such.
<xnox> otherwise running --enable and iterating moving things from /etc to /lib is pain.
<didrocks> xnox: well, I would really wait for the sprint, as there is no clear agreement, even with debian, on the finale decision
<xnox> didrocks: i need this not for debian ;-)
<mitya57> cjwatson: hi, can you please look at bug 1409433?
<ubottu> bug 1409433 in perlqt (Ubuntu) "Please demote perlqt to universe" [Undecided,New] https://launchpad.net/bugs/1409433
<didrocks> xnox: and not in ubuntu then ?
<xnox> didrocks: elsewhere
<cjwatson> mitya57: Just the demotions?
<mitya57> cjwatson: yes, not only perlqt, but the list in bug description
<cjwatson> Yeah, I think you missed a couple from that even, but I'm checking component-mismatches
<cjwatson> qimageblitz and smokegen can go too
<mitya57> Great
<ari-tczew> cyphermox: I uploaded your ppp from -proposed, libcapi20-3 from unstable and merged isdnutils to my PPA.
<ari-tczew> cyphermox: Every from those packages built fine. You can try to use it. (https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+packages?field.name_filter=&field.status_filter=published&field.series_filter=vivid)
<ari-tczew> cyphermox: libcapi20-3 is already in NEW. (https://launchpad.net/ubuntu/vivid/+queue?queue_state=0&queue_text=)
<cjwatson> I'd be wary of NEWing libcapi20-3 until the new isdnutils source is also on its way into the archive
<ari-tczew> If new libcapi goes to -release, we have to rebuild all reverse depends. (http://paste.ubuntu.com/9897689/)
<cjwatson> Just to avoid problems with the overwritten binary
<cjwatson> The new libcapi won't go to the release pocket until all reverse-dependencies are rebuilt, I wouldn't expect?  proposed-migration should ensure that
<ari-tczew> cjwatson: should do I to upload isdnutils right now?
<cjwatson> Unless the dependencies are wrong
<cjwatson> I don't know, I haven't reviewed it :)
<cjwatson> mitya57: .
<ari-tczew> cjwatson: do you need to review? I thought I have permissions ;-)
<cjwatson> ari-tczew: I don't, but you asked me a question to which I don't have the answer without reviewing it :)
<mitya57> cjwatson: thanks a lot
<ari-tczew> cjwatson: so if you'd be nice to answer it would be good, because we're staying in the place :)
<ari-tczew> However, isdnutils needs ppp to get built.
<mitya57> cjwatson: launchpad still thinks pyqt5 is in main: https://launchpad.net/ubuntu/+source/pyqt5/5.4+dfsg-1~ubuntu1/+publishinghistory
<ari-tczew> ppp is waiting in -proposed. :(
<cjwatson> ari-tczew: I'm not blocking it
<cjwatson> If you have the technical permission to upload it, you're taking responsibility for it, you think it's correct, and nobody's objecting, you should probably upload it :)
<cjwatson> I'm happy to accept the libcapi20-3 sync once there's an isdnutils dep-waiting on it
<ari-tczew> cjwatson: ok, I'll upload it
<cjwatson> mitya57: https://launchpad.net/ubuntu/+source/pyqt5/+publishinghistory clarifies, there was a separate upload in release vs. -proposed
<cjwatson> mitya57: sorted now
<mitya57> cjwatson: oh yes, I should have said that, thanks anyway
<doko> urgh, everybody moves away from isdn ...
<ari-tczew> cjwatson: ok, isdnutils is dep-waiting already
<doko> pitti, https://launchpadlibrarian.net/195907605/buildlog_ubuntu-vivid-ppc64el.openjdk-8_8u40~b22-1_FAILEDTOBUILD.txt.gz
<doko> ugh, and is there a way to tell oemstrip to leave some files untouched?
<cjwatson> ari-tczew: libcapi20-3 accepted
<ari-tczew> cjwatson: cool, thanks. I'll rebuilt all reverse-depends.
<ari-tczew> s/rebuillt/rebuild
<pitti> doko: hm, is that a timeout or something? I don't see an error message
<pitti> ah yes, I see it at the end
<doko> pitti, yes, but a timeout during stripping? and how can I tell oemstrip not to touch libjvm.so?
<pitti> (it's pkgstriptranslations)
<pitti> doko: could it be that this is just a large build tree, and finding/taring the *.po files is slow on that builder?
<doko> there are no .po files
<doko> and ppc64el should be one of the fastest
<pitti> doko: as for your question, debian/rules can export NO_PKG_MANGLE=1
<doko> pitti, that would be all or nothing
<cyphermox> ari-tczew: thanks for looking into isdnutils
<cyphermox> I had started but couldn't make sense of the new libcapi20-3, I didn't think to look in new
<cyphermox> what's the source package for it?
<ari-tczew> cyphermox: you're welcome,
<ari-tczew> cyphermox: https://launchpad.net/ubuntu/+source/libcapi20-3/1:3.27-1
<cyphermox> ah
<ari-tczew> cyphermox: these two binaries were shipped in isdnutils, but they have been splitted out to separate source libcapi20-3 (link above)
<cyphermox> yeah, I saw
<ari-tczew> cyphermox: I saw you've merged nm-applet. have you been dreaming about that?
<cyphermox> what do you mean?
<cyphermox> it's not quite a merged
<ari-tczew> cyphermox: I guess you've spent a half of night :P
<cyphermox> I've taken it a few steps closer to being mergeable
<cyphermox> nah, actually it took far less time than I had expected
<cyphermox> I had more trouble with an accessibility patch than with the indicator patch
<ari-tczew> not bad
<ari-tczew> cyphermox: what are the next steps to do?
<ari-tczew> plugins from universe?
<cyphermox> network-manager-pptp, which I had already started
<cyphermox> that will unblock things
<cyphermox> after that yes, the other plugins
<cyphermox> also, whatever libcapi reverse-depends.
<pitti> doko: hm, if it doesn't have any desktop files, gnome help, or translation files, then it's basically just a bunch of "find" commands; I can't see from the log where it's stuck :/ we'd need a set -x output, or just retry the build and see whether it gets further/hangs at a different place, and maybe inspect dmesg to see if it has a stuck process?
<ari-tczew> cyphermox: I'm on it in the evening
<ari-tczew> till all libcapi20-3 builds are ready
<ari-tczew> arm64 is still waiting
<cyphermox> ari-tczew: ok, in that care let me know when you have time, because I'll start on them
<pitti> hallyn, stgraber: ah, systemd with the user lxc cgroup permission fix finally went in
<ari-tczew> cyphermox: ok. I hope in a few hours rebuilds are ready.
 * ari-tczew is going away. exams @school this weekend.
<stgraber> pitti: yay!
<taihsiang> hi, I tried the latest vivid-server-amd64.iso  today http://cdimage.ubuntu.com/ubuntu-server/daily/20150127/
<taihsiang> and found an issue: Jan 27 14:39:30 in-target: The following packages have unmet dependencies:
<taihsiang> Jan 27 14:39:30 in-target:  perl : Depends: perl-base (= 5.20.1-4) but 5.20.1-5 is to be installed
<taihsiang> but I am not sure where is the best place to report this bug.
<taihsiang> May someone tell me where to report this issue? Thanks.
<cjwatson> taihsiang: https://bugs.launchpad.net/ubuntu-cdimage since that's an image build problem
<caribou_> I would need some help from some AA to remove makedumpfile from the sync-blacklist so I can sync it from experimental
<taihsiang> cjwatson, thanks
<taihsiang> cjwatson, if I remember correct, it is very usual issue when playing around with a daily image. This kind of issues (package dependency, especially perl-*) happened to me several times.
<cjwatson> taihsiang: This one is because the image build system's mirror didn't get properly updated when that image was being built, possibly a locking issue that we've run into before.
<taihsiang> cjwatson, understood. thanks for the clear explanation.
<cjwatson> caribou: done
<caribou> cjwatson: many thanks sir
<alexbligh1> rbasak, any news on https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged]
<pitti> jibel: bah, so who broke php :)
<rbasak> pitti: o/
<pitti> rbasak: I got a gazillion test regressions as php seems uninstallable now
<rbasak> pitti: yeah, that's expected. I needed to rebuild a new php-json after uploading php5. That's done now.
<pitti> right, that's one of the first items in the pkgProblemResolver output
<pitti> rbasak: ah, so we only need to rebuild few packages, not all of them?
 * pitti restarts a random one to see
<rbasak> pitti: need to rebuild everything that depended on the old ABI. About 50. I just uploaded the rebuilds a few minutes ago.
<rbasak> I'm not sure how that maps to the dep8 tests exactly.
<rbasak> So I wasn't going to ask for retests until those builds had finished.
<pitti> rbasak: ah nice; so every package which did get an upload will at least trigger its own test and thus auto-fix itself
<pitti> rbasak: and the rest we just retry tomorrow morning then
<pitti> rbasak: thanks for the heads-up
<rbasak> pitti: ack. Sorry I didn't warn in advance. I don't know how else I could have approached this, but I'll warn next time.
 * cjwatson re-enables adare and ross for now
<pitti> rbasak: no problem at all -- the smiley was deliberate :)
<rbasak> :)
<cjwatson> Though not totally sure they're going to manage openjdk-6 in finite time.  Oh well
<pitti> rbasak: we have -proposed exactly for this; I was just a bit surprised when I looked in my mailbox
<kirkland> pitti: howdy, systemd question for you....
<kirkland> pitti: does /usr/sbin/service need any additional logic to start/stop/status systemd services?
<kirkland> pitti: it does a good job of being a layer of abstraction between sysvinit and upstart services
<kirkland> pitti: it crosses my mind that perhaps some new logic might be needed for systemd services...
<pitti> kirkland: what do you mean wrt. "new logic"?
<pitti> kirkland: btw, if you want to write anything which is portable between init systems, don't use systemctl, but invoke-rc.d (for package maintainer scripts) or "service" (for programs)
<pitti> these get alogn with sysv, upstart, and systemd
<pitti> like "service foo start"
<kirkland> pitti: exactly :-)  (fwiw, I wrote /usr/sbin/service many moons ago)
<pitti> kirkland: oh, that was you? didn't know that :)
<kirkland> pitti: indeed :-)
<pitti> #   * August 2008 - Dustin Kirkland <kirkland@canonical.com>
<kirkland> pitti: the earliest code was a port from RH, but it grew far beyond that, with upstartedness
<kirkland> pitti: anyway, I was just wondering if it needed anything else to support upstart, and I was checking if you guys were already on top of it
<pitti> kirkland: as far as I'm aware, invoke-rc.d and service fully support all three now
<pitti> kirkland: utopic's still had some bugs, though, so I'm talking "vivid" here
<kirkland> pitti: fantastic, I should have known you were on top of it :-)
<kirkland> pitti: ah, look at that (I just opened the code, which I should have done BEFORE opening my mouth) :-)
<pitti> kirkland: no worries at all :)
<ivoks> CVE-2015-0235
<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-0235)
<ivoks> ubottu: thanks, that was fast :)
<ubottu> ivoks: I am only a bot, please don't think I'm intelligent :)
<rbasak> alexbligh1: sorry, I haven't forgotten. I'm asking around to see if anybody else can take it on. Otherwise it'll probably after I've got mysql 5.6 done, which is taking longer than I expected.
<alexbligh1> rbasak, no problem. If there's anything I can do to speed things up do drop me a line.
<pfsmorigo> hi, I'm setting a preseed. What's the diff between d-i apt-setup and apt-mirror-setup?
<pfsmorigo> hmm.. maybe that's not the channel for this doubt, sorry
<pitti> stgraber: oh, and if you could confirm that your machine with the bond interface is booting/working correctly now, I'd appreciated
<pitti> stgraber: I made some guesses about reproducing it (do you use ifenslave?)
<stgraber> pitti: that machine uses ifenslave, yes and I'll check in about two weeks
<stgraber> being 7000km away from it, not feeling like taking the chance :)
<pitti> stgraber: ok; using ifenslave is the most important bit of it (I don't know if there's another way)
<pitti> stgraber: with ifenslave, the reason for the hang was quite clear
<stgraber> ah yeah, ifup bond0 waits for ifup of ethX (or the other way around depending on the order they're brought up)
<pitti> stgraber: so, should be all good now
<ogra_> stgraber, tks ... 7000km ... just strech your arm a bit
<doko> pitti, https://launchpadlibrarian.net/195961040/buildlog_ubuntu-vivid-ppc64el.openjdk-8_8u40~b22-1ubuntu1_UPLOADING.txt.gz  so no processes hanging, now just building with PKG_NO_MANGLE
<semiosis> DktrKranz: ping?
<semiosis> DktrKranz: regarding https://bugs.kde.org/show_bug.cgi?id=343376
<ubottu> KDE bug 343376 in VNC "KRDC crashes when connecting to Mac server" [Grave,Unconfirmed]
<infinity> rbasak: I was not around, it was 5am.
 * cyphermox -> lunch
<jamespage> doko, apologies its taken me a while to find time but component-mismatches is now alot cleaner - less maven explosion
<rbasak> infinity: I never know what timezone you're in :)
<rbasak> infinity: I'm EOD now. Can we chat tomorrow?
<infinity> rbasak: I never know what timezone I'm in either, and sure.
<doko> jamespage, much appreciated
<alexbligh1> I have made a cockup on some software which has been deployed to some of our customers. In essence, when Ubuntu was at 12.04, I shipped package A with a version number of X (which was our internal s/w version and nothing to do with package A's version). Trusty now ships a more modern version of package A (let's say version Y), but unfortunately X>Y. This means apt-get upgrade doesn't upgrade the packages. Apart
<alexbligh1>  from apologising for being an idiot, what is the safest way to remedy the situation without the customer having to type specific incantations? Package A is brought in by a package we ship.
<semiosis> alexbligh1: i think you can make your package depend on a specific version (or range of versions, less than X) so that apt will pull in the trusty universe package
<alexbligh1> semiosis, mmm. OK. So if I depend on 'foo<N' and foo 0.01 is in one repo, and foo 9.00 is in another, that will automatically take foo 0.01 rather than ignore foo 0.01 because it's outdated?
<semiosis> seems worth a try
<alexbligh1> semiosis, this is all a bit of a mess as (to my shame) I actually cocked up three of four packages which depend on eachother
 * alexbligh1 buries head in hands
<nijopa> Afternoon everyone
<nijopa> Is this the appropriate channel to ask a quick question about getting debug symbols for the GCC toolchain under Ubuntu 14.04 LTS?
<nijopa> If not, can you suggest an appropriate one?
<RAOF> nijopa: #ubuntu would also be appropriate. In general, https://wiki.ubuntu.com/DebuggingProgramCrash#Installing_debug_symbols_manually
<RAOF> nijopa: (The gcc tools have a bunch of -dbgsym packages with the stripped symbols)
<nijopa> RAOF - thanks
<nijopa> I've found the debug packages, and I know about how to do the install
<nijopa> I'm actually having trouble installing them (getting dependency errors) and also, the contents don't appear to be what I'd expect.
<nijopa> For example, what appears to be the top level debug symbol package only contains a handful of files
<nijopa> when I'd expect it to contain more, or install a bunch of dependencies.
<nijopa> It's not a big deal - I can build the toolchain from scratch easily enough
<RAOF> nijopa: Yeah, you'd need to install all the individual debug packages; we don't do a âinstall all the symbols for the whole stackâ metapackage.
#ubuntu-devel 2015-01-28
<rbasak> pitti: I think everything is built now. Please could you retest everything listed as a regression in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5? I just tried myself, but I don't seem to be able to reach anything via batuan.
<ari-tczew> cyphermox: Well, I think I'm ready with libcapi20-3 transition. I did a rebuild on all reverse depends. I'll look later whether are they all build fine.
<infinity> rbasak: Still around?
<infinity> rbasak: It's awfully late, so I'm going to assume no.
<infinity> rbasak: Anyhow, I'm going to assume you tested this spamassassin change and it works, but if it had been me, I would have also commented out the line in 50_scores.cf
<infinity> rbasak: All accepted.  Please verify ASAP, happy to fasttrack this once you sure it both solves the bug and doesn't otherwise break anything.
<rbasak> infinity: thanks. I'll verify after sleep. I did consider commenting out 50_scores.cf, but if I did that I'd also want to do the translations, and tested that it works across all releases without any warnings or anything by just doing the definition.
<rbasak> I suppose in part it's because testing across all releases is tedious, so I started with the minimal, and that worked, so I didn't feel the need to go further.
<pitti> Good morning
<pitti> rbasak: yes, my retry button finger was busy last night and this morning :)
<pitti> rbasak: there are still a few regressions; e. g. jmespath.php looks like a victim of the same patch regression that hit systemd and glibc: debian bug 776257
<ubottu> Debian bug 776257 in patch "Fails to apply patch with dangling symlink" [Serious,Open] http://bugs.debian.org/776257
<dholbach> good morning
<LocutusOfBorg1> hi dholbach !
<LocutusOfBorg1> hi all
<dholbach> hi LocutusOfBorg1
<mlankhorst> can I get libepoxy promoted to main for trusty?
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1342605 was the bug for utopic, but I need it in main for xorg-server-lts-utopic
<ubottu> Launchpad bug 1342605 in libepoxy (Ubuntu) "[MIR] libepoxy" [High,Fix released]
<mitya57> pitti, jibel: vivid-adt-software-properties fails since Jan 20th, but for some reason it blocks pyqt5 which got built only yesterday
<mitya57> Please do something :)
<pitti> well, best would be to fix software-properties :)
<pitti> I'll look at it later, it also blocks gtk+3.0
<jibel> pitti, it seems it's failing because the path to dbus-launch is wrong
<pitti> jibel: oh, indeed
<mitya57> pitti, jibel: it probably needs to add dbus-x11 to Depends
<pitti> mitya57: yeah; running test locally now, will upload if that works
<cjwatson> rbasak: You need to switch to the new company VPN; the old batuan one is AFAICT essentially dead/broken as of the end of last year.
<rbasak> cjwatson: I thought it might be that. Thanks!
<rbasak> pitti: Thanks - I'll follow up.
<mlankhorst> doko__: hm mesa 10.4.2 fails to build against llvm 3.6
<pitti> mitya57, jibel: software-properties uploaded
<mitya57> thanks :)
<hallyn> arges: hi, on your next sru stint could you please take a look at 1404388?  its fix has been baking for awhile...
<mlankhorst> doko__: I've grabbed some patches from git, but I would prefer to skip to 10.5 first
<mlankhorst> still, it seems to build, no idea if it really runs..
<mlankhorst> crash crash
<mlankhorst> tons of stuff failing that failed before, I'll try with master..
<mlankhorst> slightly better there, maybe I missed some backports :-/
<mlankhorst> definitely did.. grabbed 1 more and llvm-3.6 works a lot better now
<doko> mlankhorst, cool, looks promising
<mlankhorst> seems to have no regressions in llvmpipe compared to 3.5
<mlankhorst> I'll have to test i386 to be sure
<Riddell> mvo: I wonder if you could help me and harald with a apt resolver problem
<Bluefoxicy> https://lkml.org/lkml/2015/1/23/688
<Bluefoxicy> this is also going on on linux-mm
<Bluefoxicy> http://marc.info/?l=linux-mm&m=142242638202925&w=2
<Bluefoxicy> .... oh.  Rik van Riel's response isn't on the archives yet
<Bluefoxicy> "The Android low memory killer does exactly what you want, and for very much the same reasons.
<Bluefoxicy> See drivers/staging/android/lowmemorykiller.c"
<Bluefoxicy> Trying to get the reclaim code un-stupided so the computer doesn't just thrash like hell when you've eaten 99% of your RAM and have no space for page cache
<xnox> didrocks: your emails came out as attachments, instead of inline =/
<xnox> unless my mail client is acting silly
<pitti> no, same here; but that's ok? avoids line wrapping and is easier to save?
<xnox> no idea if the standard is attachments or inline. I guess i like inline only, and most other people send things like that as well.
<xnox> surely one syncs mailbox as mbox / maildir anyway thus they are already saved. (well integrators usually do)
<didrocks> xnox: yeah, did that to avoid line wrapping
<didrocks> xnox: did that last time as well, didn't seem to have been a biggy
<xnox> meh fair enough.
<Bluefoxicy> static inline?
<arges> hallyn: sure thing
<arges> hallyn: hey we just need bug 1393548 verified to release that fix, its whats been blocking it
<ubottu> bug 1393548 in libvirt (Ubuntu Utopic) "libvirt's apparmor profile denies access to sgabios.bin" [High,New] https://launchpad.net/bugs/1393548
<mlankhorst> doko: ok seems that on 32-bits llvm 3.5 -> llvm 3.6 has no regressions, just some fixes.. presumably from a commit that fixes unaligned access
<flexiondotorg> cyphermox, Hi
<flexiondotorg> cyphermox, What are the next steps for me to get Ubuntu MATE being built officially?
<flexiondotorg> cyphermox, I see some of the merge proposals are approved but not merged yet.
<flexiondotorg> cyphermox, How do I go about get me meta package integrated?
<hallyn> arges: oh, feh.  thanks
<cyphermox> flexiondotorg: yes, I'm fixing this in a bit, as soon as I'm done with what I'm currently working on
<cyphermox> flexiondotorg: is your metapackage prepared already? I could take a look
<flexiondotorg> cyphermox, Sure - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/ppa/+packages
<cyphermox> great
<flexiondotorg> cyphermox, It's called ubuntu-mate-meta. You want version 1.118~15.04~12
<cyphermox> ack
<flexiondotorg> cyphermox, I realise I need to clean up the version number for import.
<flexiondotorg> cyphermox, Source is here - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-meta
<cyphermox> thanks
<xnox> cyphermox: you do know how to correctly do meta package updates?
<xnox> as in merge into seed branch, pull package, run update, upload.
<xnox> they are semi-automatic
<rbasak> pitti: all the remaining issues for php5 now are the dpkg symlink problem. Not sure what to do about that.
<pitti> rbasak: yeah, me neither; this is currently being discussed with patch upstream
<pitti> rbasak: we could revert the security fix for the time being of course;
<cyphermox> xnox: I know how to do it, but this would be a new package
<pitti> hm, just got a bug report: "I am running Ubuntu 12.05, and most things work fine."
<pitti> where can I download it? :-)
<ogra_> linaro ?
<ogra_> :)
<xnox> cyphermox: =/ i've never done a new seed from scratch. as there are a few bits that need to happen elsewhere in the infra to get it working
<cyphermox> one step at the time, we'll make it work. I'm not worried
<rbasak> barry: around? I'm helping matsubara with bug 1412545. A reporter is asking about an embedded copy shipped in virtualenv.
<ubottu> bug 1412545 in python-urllib3 (Ubuntu Trusty) "proxy isn't used after a dropped connection" [Undecided,Triaged] https://launchpad.net/bugs/1412545
<rbasak> barry: do you know about how the unvendoring and wheel stuff works, please? Does this need a rebuild of pip and then a rebuild of virtualenv to update virtualenv with a fix?
<cyphermox> flexiondotorg: one of the next steps I'd propose is to try to get more uploads sponsored, so that you can eventually get upload rights to at least some of the MATE packages, this would help you get stuff done.
<flexiondotorg> cyphermox, Agreed.
<flexiondotorg> cyphermox, Right now I am hoping to get all the "infrastructure" stuff completed. Then start to address the package uploads.
<cyphermox> very well. I'm happy to sponsor things if you need
<flexiondotorg> cyphermox, Great. dholbach has also sponsored stuff in the past.
<flexiondotorg> I'll start preparing the few packages that require upload. Basically, settings and artwork.
<flexiondotorg> I'll need a day or so to get round to that.
<barry> rbasak: okay, you are either screen capturing me or reading my responses to LP: #1415028
<ubottu> Launchpad bug 1415028 in python-virtualenv (Ubuntu) "virtualenv's included pip does not use system libraries" [Undecided,New] https://launchpad.net/bugs/1415028
<barry> rbasak: and unfortunately, i do know how all that works ;)
<barry> or in trusty's case, doesn't work
<cyphermox> flexiondotorg: you may want to start working on ubiquity-slideshow-ubuntu-mate if it's not already prepared :)
 * rbasak reads
<flexiondotorg> cyphermox, Already done.
<cyphermox> great
<flexiondotorg> I've submitted a merge proposal which has been merged.
<barry> rbasak: basically, this was all fixed in debian, and inherited in ubuntu, but not until *after* trusty.  pyvenv is deliberately broken in trusty because it violates debian policy. virtualenv violates it too, but that wasn't discovered until after trusty.  so trusty's virtualenv works by accident.  this is all done correctly in jessie, and thus inherited by ubuntu post-trusty.  i talk to *a lot* of people about this
<flexiondotorg> However, it has not been built.
<rbasak> barry: understood, thanks. I didn't know about the other bug there.
<flexiondotorg> cyphermox, If you can trigger a build that would be helpful because I have translator who can't work on it until it is built.
<flexiondotorg> *translators
<cyphermox> ok
<barry> rbasak: i've changed my opinion on what should be done.  i now mostly agree this should be fixed properly in trusty (essentially what jessie/vivid has) but that's a lot of work and a lot of sru'ing
<rbasak> barry: so I'm mentoring some people on my team on Ubuntu development, and matsubara is tackling 1412545. I think I'll just go through and SRU python-urllib3 and not bother matsubara with the virtualenv of things, if that's OK.
<barry> rbasak: so first, i want to see if i can get some resources to do that work, then discuss on u-d@ to see if the stack of sru's we'd need would actually get approved.  this includes adding things like python-wheel which didn't show up in debian until after trusty
<rbasak> I can leave a bug task open in that bug for virtualenv.
<rbasak> OK
<barry> rbasak: i think that's reasonable.  probably as a workaround, you can create the virtualenv, and then `pip install --upgrade urllib3`
<barry> which would pull the newer version from pypi
<rbasak> Thanks - we'll put that in the bug.
<bdmurray> cyphermox: Can you have a look at bug 1410573?
<ubottu> bug 1410573 in debian-installer (Ubuntu Vivid) "Expert mode installation fails with error" [Undecided,Triaged] https://launchpad.net/bugs/1410573
<rbasak> infinity: bug 1412830 verified, if you want to fast track it.
<ubottu> bug 1412830 in spamassassin (Debian) "[AHBL] spamassassin is returning false positives by default" [Unknown,New] https://launchpad.net/bugs/1412830
<infinity> rbasak: Thanks.
<infinity> rbasak: Will release now.  If it breaks my mail server on upgrade, I will return and yell at you. ;)
<rbasak> infinity: my mail server will get the update too :)
<infinity> rbasak: Right, I'll be sure not to yell at you via email if it's broken, then.
<rbasak> :-)
<xnox> lol
<bdmurray> cyphermox: this SRU upload seems to have an accidental change - https://launchpadlibrarian.net/195843293/gnome-bluetooth_3.8.2.1-0ubuntu4.1_3.8.2.1-0ubuntu4.2.diff.gz
<cyphermox> oh. opps, that's true
<bdmurray> cyphermox: okay, rejecting then. let me know when there is another one to review.
<cyphermox> sure, it will be in a second
<cyphermox> bdmurray: thanks, should be good now. I just uploaded it with the correction
<bdmurray> cyphermox: it looks the same to me
<cyphermox> gah
<cyphermox> ah, no?
<cyphermox> anyway, not the changelog issue
<cyphermox> are we both looking at http://launchpadlibrarian.net/196059612/gnome-bluetooth_3.8.2.1-0ubuntu4.1_3.8.2.1-0ubuntu4.2.diff.gz?
<bdmurray> -+	<device oui="7C:1E:52:" type="mouse" name="Microsoft Touch Mouse" pin="0000"/>
<bdmurray> ++	<device oui="7C:1E:52:" pin="0000"/>
<cyphermox> that's on purpose
<cyphermox> 7C:1E:52: devices aren't necessarily mice or calling themselves Microsoft Touch Mouse
<bdmurray> that's not called out in the changelog
<cyphermox> ugh, I see
<bdmurray> so I thought it was an error because the last SRU did the opposite
<cyphermox> take three
<cyphermox> yes
<cyphermox> it is most likely an error anyway to revert the previous SRU
<cyphermox> bdmurray: please reject it
<cyphermox> I'm sorry for wasting your time with this
<bdmurray> cyphermox: no problem, so what's the plan for gnome-bluetooth then?
<cyphermox> to really fix that upload
<cyphermox> I've re-done it
<cyphermox> triple-checked the debdiff
<cyphermox> I think it should be good this time :)
<cyphermox> flexiondotorg: have you built any kind of almost-daily image somewhere instead of your 14.10 images?
#ubuntu-devel 2015-01-29
<catbus1> Does anyone know when 14.04.2 will be released?
<Sarvatt> catbus1: https://wiki.ubuntu.com/DraftReleaseSchedule feb 5th
<Sarvatt> which is actually cutting it pretty close because the lts backport X stack *just* got in :D
<catbus1> Sarvatt: thank you.
<ari-tczew> cyphermox: around?
<cyphermox> ari-tczew: yes
<ari-tczew> cyphermox: hi. I saw the stuff is moved to -release. do you still need a help?
<cyphermox> no, that's covered I guess
<cyphermox> unless you want to merge the other vpn plugins, I'm not sure when I'll get around to those
<ari-tczew> cyphermox: I can take those. The question is, should do I just merge from Debian, or additionally upgrade to new upstream release?
<cyphermox> I think they're already at their newest release, but that's up to you
<cyphermox> I would merge + update if it's worth updating
<cyphermox> Logan_: hey, btw n-m-iodine migrated to -release if you didn't notice yet :)
<Logan_> I saw :)
<cyphermox> great.
<cyphermox> I'm not sure if iodine is the plugin I never ever managed to make work properly ;)
<pitti> Good morning
<Unit193> Howdy.
<dholbach> good morning
<LocutusOfBorg1> hi dear developerz
<LocutusOfBorg1> does anybody know which kernel will land on vivid?
<alkisg> mvo, stgraber: hi, could I ping you about LP #1415785 ? update-manager blacklists ltsp, and removes it on dist-upgrades (normal upgrades, not release upgrades), and that breaks ltsp installations. I'd like to help in fixing + SRU'ing this for 14.04 and 12.04...
<ubottu> Launchpad bug 1415785 in update-manager (Ubuntu) "Please remove all ltsp* blacklisting" [Undecided,New] https://launchpad.net/bugs/1415785
<mvo> alkisg: thanks, if you could prepare a diff and the sru test instruction I'm happy to sponsor it for you
<alkisg> Thank you mvo, will do
<infinity> mlankhorst: Does libevdev need a utopic->trusty backport too, or will my copying the trust/universe version to trusty-updates/main be enough to make xserver-xorg-input-evdev and xserver-xorg-input-synaptics happy?
<mlankhorst> infinity: I didn't update it at least
<mlankhorst> and works locally
<infinity> mlankhorst: Alright.  We'll see how that goes, then.  I think those are the only two not built now.
<mlankhorst> ah k
<Odd_Bloke> I'm hitting "libgcc1 : Depends: gcc-5-base (= 5-20150128-0ubuntu1) but it is not installable" when building arm64/ppc64el images; is this (likely to be) a transient problem, or should I report a bug?
<mlankhorst> do you have -proposed enabled?
<Odd_Bloke> mlankhorst: Shouldn't do; Ctrl-F of the build log (https://launchpadlibrarian.net/196091740/buildlog_ubuntu_vivid_arm64_cpc_FAILEDTOBUILD.txt.gz) suggests proposed isn't mentioned anywhere.
<Odd_Bloke> It is in http://ports.ubuntu.com/dists/vivid/main/binary-ppc64el/Packages.bz2.
<cjwatson> Odd_Bloke: It's a component mismatch.  Fixing.
<mlankhorst> ah
<cjwatson> Odd_Bloke: Retry your build once "rmadison gcc-5-base" says "vivid" rather than "vivid/universe" (give it maybe half an hour or so)
<Odd_Bloke> cjwatson: Thanks, will do.
<Odd_Bloke> For my understanding, does this mean that someone uploaded gcc-5-base in to universe when it should have been uploaded to main?
<cjwatson> Odd_Bloke: Components are overridden centrally, not in general up to the uploader.  New packages tend to land in universe.
<cjwatson> So if they're dependencies of stuff in main then we need to adjust the overrides to account for that.
<cjwatson> Often this requires an explicit signed-off main inclusion request, but in this case that wasn't necessary since gccgo-5 is obviously just a newer version of stuff already in main.
<cjwatson> (that's the source package building gcc-5-base right now)
<Odd_Bloke> Right, got it.
<Odd_Bloke> cjwatson: Not sure if what you've done will cover it, but "gcc-5-base | 5-20150128-0ubuntu1 | vivid-proposed/universe | armhf" just popped up in the rmadison output as well.
<cjwatson> Odd_Bloke: It'll be easier to check after an archive cycle or two when our reports update.
<Odd_Bloke> Cool.
<mlankhorst> doko: are you there?
<mlankhorst> I did some testing on 10.4.2 vs 10.4.2 with llvm-3.6, results look good. r600 with experimental llvm had no regressions compared to !llvm, swrast i386 and amd64 look good too..
<mitya57> sil2100: hi, I am going to upload oxide-qt to landing-005, do you know if there should be any differences against the archive version?
<mitya57> I see two patches in d/patches, but not sure if that's all or they are still needed
<sil2100> mitya57: hah, hey, we just briefly talked about that with tsdgeos - not sure about that, but from Mirv's e-mail I somehow felt that some changes were needed, I think Timo added hack_qt540.patch to make it buildable
<sil2100> And made some packaging changes
<sil2100> So this might need rebasing on the newer oxide
<sil2100> As I didn't hear anything about those being ported upstream
<mitya57> sil2100: I see that Timo had two patches but looks like the second one is no longer needed.
<mitya57> I don't see any other packaging changes
<mitya57> sil2100: Ok, I have something that I can upload and see if it builds
<sil2100> mitya57: thanks :) oxide is really huge, we might need to bump the PPA size limit in case a re-upload is needed
<cjwatson> Let me check the current size limits
<cjwatson> ubuntu/landing-005 already has a 20GiB limit.  It seems unlikely that you'll run into trouble.
<mitya57> yes, should be no problem
<mitya57> uploaded
<rbasak> infinity: around for the mysql chat?
<mlankhorst> doko: I've uploaded mesa 10.4.2-2ubuntu2
<doko> mlankhorst, so from your point is it ok to make 3.6 the default?
<mlankhorst> yeah looks like it
<mlankhorst> and pushed the changes for it :p
<mitya57> sil2100: btw I just committed your qtbase change to bzr, so that it's again in sync with ppa
<jrwren> ~
<pitti> cyphermox: oh, now I understand what you meant by NM 0.9.10 having veth support -- when I start/stop LXC containers I get a ton of "you are now connected to vethDH32FO" notifications
<shadeslayer> mvo: did you notice the synaptic upload got rejected
<cyphermox> pitti: yeah. I'm considering patching that out of nm-applet or something
<sil2100> mitya57: thanks! That was one thing I wasn't sure about, if we are using a bzr branch to keep track of the current ongoing work or not
<mitya57> sil2100: the 5.4 packaging is in qtFOO-opensource-src branches, while 5.3.2 is in qtFOO-opensource-src_532
<sil2100> ah, ok, saw the _532 but still wasn't sure if the trunk ones are supposed to have our 'experimental' bits in it
<pitti> cyphermox: should they even be considered connections that NM has to care about?
<cyphermox> pitti: they are already not managed, all you really do is connect/disconnect, and if you really want you could change settings (not that it wouldn't break things)
<pitti> (brb)
<cyphermox> that's why I'm thinking explicitly ignoring the virtual devices in nm-applet, since one probably shouldn't touch them, but NM isn't breaking them
<cyphermox> pitti: ^
<pitti> cyphermox: *nod*, thanks
<pitti> ah, and I see lxcbr0 now, too
<pitti> with an option to disconnect it
<cyphermox> yep
<cyphermox> they all come up as virtual devices, and pretty clearly separated in nm-applet so hiding those should be trivial
<cyphermox> I'd do the same for VLANs, tunnels, bridges, bonds
<cyphermox> not usually that common on desktop machines, or at least not in a case where you actually want to touch them
<lefteris> hi there, i want to make an sru in update-manager
<lefteris> i read the wiki for sru and says that firstly must branch and apply the fix to the development branch (vivid)
<lefteris> i am using ubuntu 12.04; should i download ubuntu 15.04 for building the source and testing it
<infinity> lefteris: Working on the branches isn't strictly required, you can just file a bug and attach patches.
<infinity> (against the source from the archive)
<lefteris> or i can to build the source to the presice
<lefteris> infinity: hello, firtsly; thanks for your help
<lefteris> my actual question is: if i want to debuild the source code from vivid branch must have ubuntu 15.04 or i can to do this from precise; i am aksing because debuilding source code of vivid require python3-all 3.3.0-2 and in precise is available the python3-all 3.2.3-0ubuntu1.2
<lefteris> sorry, my question may be stupid, but i am new to making sru's
<cjwatson> lefteris: For your test build, you should use a clean 15.04 build environment, but that doesn't involve upgrading your base system.  https://wiki.ubuntu.com/SimpleSbuild
<cjwatson> lefteris: If you set that up then you can also use an schroot environment for running "debuild -S" easily enough
<cjwatson> lefteris: Though in this particular case it probably doesn't actually matter just for building the source package; I'd be inclined to use "debuild -d -S" to ignore build-dependencies, and then compare the source packages with debdiff on the old and new .dsc files to make sure that didn't introduce anything unexpected
<cjwatson> lefteris: But for building the binary packages you should definitely use sbuild or similar, not try to get it to build on your 12.04 base system.
<LocutusOfBorg1> dholbach, kbuild sync from debian/experimental? (bug 1408285) :D
<ubottu> bug 1408285 in kbuild (Ubuntu) "Please sync kbuild, virtualbox and virtualbox-guest-additions-iso from debian/experimental" [Undecided,Confirmed] https://launchpad.net/bugs/1408285
<dholbach> let me take a look
<LocutusOfBorg1> :)
<lefteris> cjwatson, infinity: thank you very much for your help
<lefteris> cjwatson: Î¿Îº, i got it; thank you
<LocutusOfBorg1> thanks dholbach :)
<dholbach> anytime
<pitti> dobey: look! "autopilot PASS" with --setup-commands ubuntu-touch-session :)
<pitti> dobey: thanks for the report
<balloons> woot!
<pitti> seems vivid's upstart changed behaviour a bit
<pitti> that was in qemu, testing in LXC now for completeness
<dobey> pitti: nice :)
<pitti> wow, that fails with http://paste.ubuntu.com/9939333/, but I'm not sure that's my fault
<pitti> yep, python3 -c 'import psutil' reproduces it
<dobey> fun
 * pitti files a Debian bug
<pitti> dobey: ok, bug sent, so running in LXC is broken for now; but qemu at least works fine now
<ovidiu_calbajos> hello all, do you know if the libc6 has been patched already for the ubuntu 12.04 openvz image?
<infinity> ovidiu_calbajos: You might need to elaborate on what you mean.
<ovidiu_calbajos> hi infinity, well one of my clients tries to update the libc6 library on his machine and doesn't get any update, also i couldn't find anything related to libc6 + openvz + ubuntu 12.04 + ghost vulnerability on the internet
<pitti> I suppose the recent security fix?
<zyga> tseliot: hey
<pitti> ah yes, ghost
<infinity> ovidiu_calbajos: Oh.  openvz rolls their own libc.  We know nothing about that, here.
<zyga> tseliot: are you the right person to talk about graphics, drivers and such?
<infinity> ovidiu_calbajos: The libc6 that we provide for 12.04 has been updated.
<ovidiu_calbajos> infinity: indeed I saw the update on the 12.04 but I didn't see it on openvz
<ovidiu_calbajos> thank you for your time
<infinity> ovidiu_calbajos: In other words, this is a question for openvz, not for Ubuntu.
<ovidiu_calbajos> infinity: thanks again, I will try to contact them :)
<zyga> tseliot: I want to ask you about a potential candidate for GPU stress tests
<zyga> tseliot: and if you have heard of the tool or others like it http://wili.cc/blog/gpu-burn.html
<tseliot> zyga: I'll have a look and let you know
<zyga> tseliot: thanks
<tseliot> zyga: I think that would be limited to the nvidia binary driver, as it involves using CUDA (I had a quick look)
<dobey> pitti: awesome. i guess i'll need to grab the deb from vivid to install on the host, or it will just update when i run the tests and work?
<pitti> dobey: right, you need vivid's autopkgtest package (but you need that anyway if you want to do anything on the touch platform)
<zyga> tseliot: do you know of other tools that we could use for stress testing GPUs?
<pitti> dobey: note that ATM the fix is only in git, I didn't upload to Debian/Ubuntu yet
<pitti> dobey: you can of course check out git if you want and run /your/checkout/dir/run-from-checkout
<pitti> dobey: or just grab the fixed setup script and copy it to your machine :) (http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/plain/setup-commands/ubuntu-touch-session)
<dobey> pitti: do i need it on the host or just in the vm though?
<pitti> dobey: it's unrelated to the VM; just on the system where you call adt-run
<pitti> dobey: i. e. --setup-commands <path to that script>
<dobey> pitti: ok. i wasn't sure if it was using the one on the host or in the vm for that
<pitti> dobey: the VM doesn't have anything special (it can be any VM, or you can use a schroot, or a phone, or whatever)
<dobey> anyway, copied the new script onto my host and trying a run now :)
<tseliot> zyga: that would be tests that involve using OpenGL. I think checkbox already uses the phoronix test suite, which, in turn, relies on some OpenGL tests.
<zyga> tseliot: I don't recall if we use any stress tests from pts
<zyga> tseliot: and we definitely don't have anything for opencl (or cuda)
<zyga> tseliot: so in general, the tool I've likned to is suitable for nvidia but not applicable for amd/intel, is that accurate?
<tseliot> zyga: opencl would work with both fglrx and nvidia. I'm not sure we support opencl with open drivers. Cuda is nvidia only AFAIK
<tseliot> mlankhorst, Sarvatt: ^
<dobey> pitti: well, my tests still fail, but with a different error now :)
<tseliot> tjaalton: ^
<dobey> ** (run.py:17865): WARNING **: Unable to find keyfile for application 'com.canonical.payui_payui_15.01.last'
<dobey> not sure how to fix that though
<pitti> dobey: ok, that's not my bug then :) is that gsettings? missing schema?
<dobey> pitti: i think it's ubuntu-app-launch complaining
<dobey> i guess it can't find the .desktop file for some reason
<pitti> dobey: ah, bug 1333215
<ubottu> bug 1333215 in ubuntu-app-launch (Ubuntu) ""Unable to find keyfile for application": clicks installed in current session don't create UAL cache, and UAL does not look for .desktop files in click pkgdir" [High,Triaged] https://launchpad.net/bugs/1333215
<zyga> tseliot: right about cuda, I don't know the current opencl story, I know all three vendors do their own drivers but they are not open IIRC
<pitti> dobey: you could work around it by "click install"ing it manually on the phone, restarting, and then running adt-run --click com.ubuntu.whatever (i. e. name instaed of a local .click file)
<dobey> pitti: oh i guess so
<dobey> pitti: well this is in qemu so phone won't help i guess :)
<pitti> dobey: I tried that with the calculator in qemu and it worked fine though
<pitti> dobey: hm, I wonder what I did differently then
<dobey> i wonder why the hooks aren't run when the package is installed in qemu?
<pitti> dobey: oh, which autopkgtest version do you have?
<pitti> dobey: it's not specific to qemu or lxc; it's a bug which affects all click packages
<dobey> pitti: 3.0.1
<pitti> dobey: eww old; try the current vivid one, I think I added a workaround for this some moons ago
<pitti> dobey: you can just download the deb and install it on anything >= precise
<dobey> oh i thought it was the latest. it was a month ago when i installed it anyway :)
<pitti> dobey: hm, trusty has 2.14, utopic has 3.6, vivid 3.9.3; so 3.0 isn't actually that easy to get :)
<dobey> i should set up a recipe for backports of it in my ppa
<dobey> pitti: vivid only got 3.9.3 yesterday :)
<dobey> or well, tuesday
<dobey> oh, when did i install 3.0.1
<dobey> weird
<dobey> whenever the last time you told me to install the latest version was, i guess :)
<dobey> i guess i should set up a backport recipe for it, to make life easier
<pitti> git! git! git! :-)
<dobey> is there an upstream import of it into bzr? :)
<pitti> Date:   Thu Jul 3 07:47:54 2014 +0200
<pitti>     Fix workaround for LP #1333215
<ubottu> Launchpad bug 1333215 in ubuntu-app-launch (Ubuntu) ""Unable to find keyfile for application": clicks installed in current session don't create UAL cache, and UAL does not look for .desktop files in click pkgdir" [High,Triaged] https://launchpad.net/bugs/1333215
<pitti> dobey: so the workaround for it was quite some time ago, but it landed in 3.1
<pitti> so 3.0.1 is only just a teensy bit too old
<dobey> well, whatever. SRU it or set up a backports PPA if you want people to always use the latest version :)
<pitti> vila has something like that
<pitti> git import -> LP recipe
<vila> git clone <url> trunk
<vila> bzr branch trunk feature
<pitti> vila: no, I mean your "crack of the day" autopkgtest PPA
<vila> me too ;-)
<vila> cd autopkgest ; git pull
<vila> cd ../vila
<vila> bzr pull
<vila> test
<vila> bzr push
<vila> trigger recipe
<pitti> ah, ok; I thought you set up an automatic bzr import (these work rather well)
<vila> bzr-git seems to work far better when dealing with a local repo than with a remote repo
<pitti> no, I mean LP does it all for you
<pitti> e. g. https://code.launchpad.net/~pitti/python-dbusmock/trunk is an automatic import of git
<vila> I don't do git push either (which is nice ;)
<dobey> and launchpad uses bzr-git
<dobey> manually pulling/pushing/etc seems like a pain in the ass for building a PPA package
<vila> pitti: oh, for a backports PPA, sorry, missed that bit
<dobey> pitti: lol. anyway, i updated and still get the keyfile error :-/
 * pitti uploads autopkgtest 3.9.4 to Debian sid, will auto-import into vivid tomorrow
<pitti> dobey: meh; I wonder if your click is slightly different than the calculator then
<pitti> dobey: feel free to open another bug and attach (or point to) click source and binary, then I can have a look on Monday?
<pitti> (systemd hackfest tomorrow, and EOD today, sorry)
<dobey> oh
<dobey> pitti: yes, payui isn't an actual app
<dobey> pitti: so not your bug. i'll talk to ted about it
<tjaalton> zyga, tseliot: enabling opencl in mesa needs some packages moved to main first, and there is a plan to enable it once the MIR is done
<pitti> dobey: hm, still sounds related (or even identical) to #1333215?
<dobey> pitti: nope
<dobey> pitti: this doesn't have a "desktop" entry in the manifest, so there is no .desktop file in ~/.local/share/applications/ (and there isn't supposed to be)
<dobey> pitti: so will have to figure out something special cased for this in our ap tests
<dobey> pitti: so i'll talk to ted and leo about it
<pitti> ah, ok; cheers!
<Noskcaj> Laney, Are you planning to package pinta 1.5 somewhere?
#ubuntu-devel 2015-01-30
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg1> hi developers!
<seb128> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<seb128> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ari-tczew> doko_: can we sync a package openjdk8 from unstable? there is only new thing in Debian: "Remove CACAO packaging bits."
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<dholbach> :)
<ginggs> Hi, where can I request the deletion of a binary package for a specific arch? (LP: #1403494)
<ubottu> Launchpad bug 1403494 in libqt4pas (Ubuntu) "Please remove arm64 binaries" [Undecided,New] https://launchpad.net/bugs/1403494
<rbasak> ginggs: I see you've already subscribed ~ubuntu-archive? They will review their bugs some time this cycle.
<ginggs> rbasak: ok, I was just worried this bug had fallen through the cracks
<rbasak> ginggs: AIUI, they don't process their bugs that frequently, since it's only really needed to happen by release.
<rbasak> So they batch them all together.
<Laney> Wel, that bug is causing something to back up in proposed.
<shadeslayer> mvo: poke poke
<shadeslayer> mvo: re @ synaptic
<mvo> hey shadeslayer, let me check that rejection mail
<shadeslayer> :)
<ginggs> Laney: right, so who can i bug about it, or should i just wait?
<geser> ginggs: if you can wait then wait, if it blocks your work then try to ping someone from the ubuntu-archive team (https://launchpad.net/~ubuntu-archive/+members#active)
<ginggs> geser: thanks, i was hoping someone from ubuntu-archive might have been hanging around here
<cjwatson> ginggs: .
<ginggs> cjwatson: thanks!
<flexiondotorg> cyphermox, Do you have a sec?
<cyphermox> flexiondotorg: sure, what's up?
<flexiondotorg> I;ll PM.
<lefterisnik> hi there, i am trying to make an sru to update-manager but i have confused. Should upload sru to https://code.launchpad.net/~ubuntu-core-dev/update-manager/main or to https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/update-manager/vivid;
<lefterisnik> i notice that in the second url the version stops to "1:0.196.3" but the developent version from the first url is 1:15.04.1 (the actual package delivered in vivid daily builds)
#ubuntu-devel 2015-01-31
<aeoril> I am wanting to start developing for Ubuntu.  I am interested in low level development (like kernel, drivers, modules, etc) but have not developed on Linux in a while.  I am trying to pick an appropriate image to start developing on from cdimage.ubuntu.com.  I found the images for Ubuntu 14.04.1 LTS (Trusty Tahr).  Would that be a good choice?
<aeoril> Also, is there an IRC channel for beginners to Ubuntu development?  #ubuntu-beginners-dev says "invite only" when I try to join
<Noskcaj> aeoril, #ubuntu-kernal is for most low-level stuff
<Noskcaj> oops, spelt it wrong
<aeoril> Ok, I will repeat my question there
<Noskcaj> #ubuntu-kernel
<Noskcaj> there's no real beginner developer stuff other than the "bitesize" bug tag, the 100 papercuts project, and then just finding whatever issues affect you
<aeoril> Noskcaj I have been idling on #ubuntu-kernel for some time and it is very low volume - I think my question is pretty general, thouhg - what image to use to start development on?
<Noskcaj> I run xubuntu vivid (15.04), but you can develop from any ubuntu image really
<aeoril> Noskcaj how did you get it to run?  The only images I see on the website are source images, except for the daily builds, for that version
<Noskcaj> 14.04.2 is going to come out in a week, so maybe the daily for it, see if there's anything you can help with, although it's mostly testing that late in the cycle
<aeoril> Noskcaj did you load from the daily build image?
<Noskcaj> i upgraded from 14.10, but you can install with the daily
<Noskcaj> you get the same result
<aeoril> Noskcaj I am wondering if I should stick with 14.04.1 for now because I fear the dailies may not be as stable - I do not think I need the absolute latest to just get started with - I am in learning mode right now, going through some textbooks to learn some theory and stuff for kernel/driver/module development
<Noskcaj> 14.04.2 dailies are pretty much as stable as 14.04.1 now, but like i said, you can use whatever version of ubuntu you want
<aeoril> Noskcaj oh, that is good to know - so just because it is a daily does not mean it is necessarily unstable?
<Noskcaj> no
<Noskcaj> daily means it's built using whatever is current for that release
<aeoril> I was thinking of using 14.04.1 LTS as my base, then using virtual machines under it to run other versions for development and learning - does that sound reasonable?
<Noskcaj> yep
<aeoril> Does Ubuntu come natively with VM support?
<Noskcaj> you need to install something like qemu or virtualbox from the repositories for VMs
<aeoril> I have not really looked that far yet
<aeoril> oh, ok - any preference for most developers which VM software they use?
<Noskcaj> I think kvm/qemu is slightly better most of the time from a devel perspective, but a lot of people like each option
<Noskcaj> vmware is pretty good if you don't need an opensource VM too
<aeoril> Is vmware free as well?  I thought it was pay
<darkxst> aeoril, vmware player is free for non-commercial use
<darkxst> and despite the name, it can create VM's
<aeoril> ok, thanks, darkst
<aeoril> Unfortunately, there is noone answering my query on #ubuntu-kernel - it just does not seem to get much traffic, from what I have seen
<darkxst> aeoril, vmware has the best 3D support, but if you don't need that kvm/qemu are good
<Noskcaj> aeoril, a few of the devs are probably asleep in -kernal. What timezone are you?
<darkxst> Noskcaj, except the HWE stack has not landed
<darkxst> (for 14.04.2)
<aeoril> I am in Central time USA (Chicago)
<Noskcaj> darkxst, In that case, slightly less stable
<aeoril> Last time anyone posted to #ubuntu-kernel was 10 hours ago ...
<Noskcaj> aeoril, Just be aware that this is a global community, so not all questions can be answered at any time
<Noskcaj> although -kernel isn't a super active channel
<aeoril> Noskcaj ok, I will keep that in mind
<aeoril> Well, I guess I will use that plan for now - 14.04.1 with VMs for newer or older versions
<Noskcaj> :)
<Noskcaj> Depending on how much you have setup, maybe start by finding a bug or build failure you can reproduce yourself and try and fix that
<aeoril> Right now, I am doing theory.  I am reading Tannenbaum's "Modern Operating Systems," and need low level source code to be able to follow along with the theory in that textbook by looking at actual working code in Linux to see how things are really done in live production
<aeoril> So, I will be viewing the kernel source and headers and doing builds and stuff, and building low-level hacking stuff to learn as I follow along in my books
<aeoril> Once I have a sufficient basic understanding of theory (e.g., along the lines of what I would get at Univesity) I will delve into trying to help with Ubuntu - the kernel site says their biggest need is bug triage, so I figure maybe that would be a good place to start actually helping the Ubuntu community?
<aeoril> I am active a lot on #osdev here on freenode - they are very active, and have been very helpful to me as I learn
<Noskcaj> aeoril, bug triage helps us at lot, but really anything you are willing to help with helps
<aeoril> They also have a great book list
<Noskcaj> For example, i'm pretty bad at coding, but do a lot of packaging and triage work
<aeoril> Noskcaj what is the best way to learn?  To get my feet wet?  I like to do things in a very organized fashion, building on basics first then going up from there.  I have a long history of coding under my belt, but just not a whole lot on Linux (but a fair amount on Unix)
<Noskcaj> Find a bug that affects you or you can reproduce, do something to make it closer to being fixed
<Noskcaj> bugs with the "bitesize" tag are often easier to start with
<aeoril> Yes, that makes sense
<Noskcaj> If there's a program that you use regularly, i could run you though the steps of fixing a bug in it.
<Noskcaj> brb, need lunch
<aeoril> ok, thanks
<aeoril> Noskcaj I am really getting into this book right now - I am working on learning about all kinds of low-level stuff, and I kind of want to stick with hacking the kernel source right now
<aeoril> For instance, the thing I am working on right now is understanding and implementing spinlocks in the kernel in assembler because that is where I am in the book
<aeoril> Noskcaj I need to get my development machine up and running, then get the kernel development environment all set up with the appropriate source code, etc.
<Noskcaj> ok, just ping me if you get stuck
<aeoril> Noskcaj cool!  Thanks!  I really appreciate the help!
<Noskcaj> no problem
<Noskcaj> It's great to see someone new around
<aeoril> It's great to be here!  I have a background in doing some Linux (and Ubuntu) development, but mainly Solaris and real-time variant Unix systems and embedded OSes and even some firmware development and hardware integration for embedded systems and simulations
<aeoril> I was fairly active in the Ubuntu development community some years ago but only for a few months - I took a detour into Web development because it seemed very interesting (and it is) but I finally felt I wanted to get back to my low-level roots.  I think I can be of more service there and will like it better, I hope
 * aeoril likes bit-twiddling
<hillma> is this bug, https://bugs.launchpad.net/ubuntu/+source/mit-scheme/+bug/373018 , fixable now as debian already have amd64 for mit-scheme ?
<ubottu> Launchpad bug 373018 in mit-scheme (Ubuntu) "There does not exist a 64-bit version of mit-scheme. A deb of mit-scheme-c (portable) would fix this." [Undecided,Confirmed]
<Noskcaj> happyaron, ping
<Noskcaj> Any chance you could fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776694 ? It should be a pretty minor patch
<ubottu> Debian bug 776694 in libxml2-dev "libxml2-dev: dependency to libicu-dev missing" [Normal,Open]
#ubuntu-devel 2015-02-01
<happyaron> Noskcaj: yes, today
<Noskcaj> thanks happyaron
<mitya57> metacity is stuck in -proposed but there is no info at all in update-excuses or update-output... What happened?
<sn33zy> okay, Im trying to find the latest version of libva but freedesktop.org hasnt been updated since 2013.  is there another website for the project?
<sn33zy> a google search cant find anything.
<Noskcaj> cjwatson_, Are you planning to merge /wireless-regdb any time soon
<mwhudson> does the archive contain a gdb with support for other architectures?
<mwhudson> (for use with target remote $blah)
<lifeless> mwhudson: gdb-multiarch ?
<ogra_> ogra@anubis:~/datengrab$ apt-cache search gdb |grep eabi
<ogra_> gdb-arm-none-eabi - GNU debugger for ARM Cortex-A/R/M processors
<ogra_> that one perhaps ?
<lifeless> mwhudson: though target remote, isn't that built in?
<mwhudson> ogra_: i want arm64 :)
<ogra_> heh
<mwhudson> lifeless: target remote is, but i think gdb needs to be built to understand the arch at the other ned
<lifeless> mwhudson: I always thought one would run gdb-server on the arm board
<mwhudson> (i might be wrong aobut this, but it seems plausible)
<mwhudson> also the other end is qemu
<lifeless> ah no
<lifeless> you run regular gdb on the target
<ogra_> i think thats what the phoone sdk guys doo all the time ... but thats just x86 to armhf
<lifeless> mwhudson: https://sourceware.org/gdb/onlinedocs/gdb/Server.html#Server
<ogra_> i could imagine you need 64bit versions on both sides
<lifeless> mwhudson: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Stub.html#Remote-Stub
<mwhudson> lifeless: well i don't know about that, but gdb-multiarch is working better than plain old gdb
<lifeless> mwhudson: oh good :)
#ubuntu-devel 2016-02-01
<Mirv> mitya57: it's already March 1st now. I fear it will simply be too late to rush into Ubuntu LTS, but let's see when it's really out and how does it work.
<Mirv> but having an upstream .0 release somewhere after FF is not a very good starting point
<Mirv> mitya57: so the current real plan is to backport enough patches to 5.5.1 in order to be happy with it
<dholbach> good morning
<pitti> Good morning
<ioanm> can I sync this? https://bugs.launchpad.net/ubuntu/+source/cmd2/+bug/1539921
<ubottu> Launchpad bug 1539921 in cmd2 (Ubuntu) "Sync cmd2 0.6.8-1 (main) from Debian unstable (main)" [Wishlist,New]
<ioanm> i mean package it for ubuntu?
<tvoss> xnox, are you around?
<tvoss> xnox, I'm looking into boost::coroutine and wondering, why we don't build .so's for it
<wgrant> doko: Is there meant to no longer be Python 2 support in xenial's vim?
<Laney> He disabled it on purpose, so meant to in that sense...
<doko> wgrant, Laney: my understanding is that having both just won't work. but I may be wrong
<doko> reason was to get python2 off the cloud images
<Laney> right, you can't have both in the same process I guess
<wgrant> I guess it's time to port all my stuff then :(
<ginggs> tvoss: see debian bug #802509, that should be fixed in 1.58.0+dfsg-5 currently in NEW
<ubottu> Debian bug 802509 in libboost-coroutine-dev "libboost-coroutine-dev: The boost-coroutine library is only compiled as a static library" [Wishlist,Open] http://bugs.debian.org/802509
<Unit193> pitti: Finally filed it, got some time to figure out where it's happening: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1540282 (Which is different than https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1536965, that one might just be lightdm weirdness there.)
<ubottu> Launchpad bug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Undecided,New]
<ubottu> Launchpad bug 1536965 in dbus (Ubuntu) "System can freeze on restarting dbus" [Undecided,New]
<Unit193> So to be clear, the one I reported is directly the Ubuntu delta in dbus.
<pitti> Unit193: err yes, restarting dbus has never been a supported operation
<mitya57> Mirv, okâ¦ I was hoping that we can get rid of appmenu-qt5 this cycle, but that requires quite a lot of backporting (some needed patches will be in 5.6.1 and some in 5.8)
<mitya57> The main motivations for dropping appmenu-qt5 are its usage of internal QMenu methods (instead of QPlatformMenu public APIs) and bugs like #1378935
<doko> pitti, please could you override the ruby-redcarpet autopkg tests? I think we don't care, and they failed in the past as well
<Unit193> pitti: Yes, we went over this.  It's not supported, but it shouldn't require you to hard reboot to fix it.  No 'service' or 'systemctl' commands work, when with the same system only in Debian (or, using Debian's dbus), they do.
<pitti> doko: yup, done
<pitti> Unit193: so I suppose we should just disallow restarting?
<pitti> I think we used to in the past, but this might have gotten lost in the move to systemd
<Unit193> pitti: Nah, it's part of the Ubuntu delta, looks like something is just off.  I didn't disable patch by patch and recompile though.
<pitti> doko: I'll wave through ruby2.2, seems good enough to me; objections?
<Mirv> sil2100: ^ see above for appmenu-qt5 notes which you might be interested in
<doko> pitti, no, and then we should be ready to remove ruby2.1
<sil2100> Mirv, mitya57: I saw Dmitry's proposals on qt/qtbase, didn't have time to look at them but I'm aware of the whole initiative and am +1 in overall :)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<smoser`> pitti, you had a merge of open-iscsi ?
<smoser`> right?
<pitti> smoser: I don't because of debian bug 797112
<ubottu> Debian bug 797112 in open-iscsi "open-iscsi: Prevent testing migration" [Serious,Open] http://bugs.debian.org/797112
<pitti> smoser: but I did go through the delta and submitted some bits to Debian (and it was applied too)
<pitti> smoser: AFAIR our only remaining delta is the addition of that integration autopkgtest now
<smoser> ok.. so what to be done ? are you planning on getting through ?
<pitti> smoser: if the  Debian maintainer says the current version isn't good for releasing, I'm cautious
<pitti> smoser: I don't know the first thing about open-iscsi, so I wouldn't want to push it from my side
<smoser> :)
<pitti> if someone knowledgeable says that this works for Ubuntu, I'm happy to do the merge
<smoser> yeah, i agre on that. i'd be hesitent on the upgrade things too.
<pitti> but for now I'm content with knowing that the actual merging will be trivial now as our  delta got sorted out, apart from dropping this testlib.py thingy
<Unit193> pitti: You do have http://paste.openstack.org/show/9HuJPkUvl8NhOgMsYMRq to prevent restarts, but it actually only prevents stopping so when you 'restart' it launches another instance causing issues.  I don't know what else seemed to cause irrecoverable problems, though.
<smoser> pitti, thanks.
<smoser> ideally we would have a autopkg test that pushes it through iscsi root. thats the biggest thign that has always been tricky for us.
<LocutusOfBorg> hi folks, a while ago dholbach syncd for me fonts-android in main. the new release dropped fonts-droid, because it isn't unsupported anymore upstream
<LocutusOfBorg> the replacement is fonts-noto (actually in universe, so it might require a MIR)
<LocutusOfBorg> or a fonts-droid-fallback package
<LocutusOfBorg> what is your opinion? I even fail to completely understand which package needs a fix for this fonts-android to migrate
<ogra_> "it isn't unsupported anymore"
 * ogra_ grins
<LocutusOfBorg> "
<LocutusOfBorg> Since Android upstream stopped shipping Droid fonts and its been
<LocutusOfBorg> declared that Noto fonts will be superseding the DroidÂ¹Â² we in
<LocutusOfBorg> "Debian Fonts Task Force" team decided to drop fonts-droid package."
<LocutusOfBorg> Â² http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20151031/011f4334/attachment.mht
<LocutusOfBorg> Â¹ https://github.com/googlei18n/noto-fonts/issues/555
<LocutusOfBorg> as example you can see the debian bug: #804678
<ubottu> Debian bug 804678 in blender "blender: Please switch from fonts-droid to fonts-noto" [Serious,Fixed] http://bugs.debian.org/804678
<ginggs> LocutusOfBorg: reverse-depends -r xenial fonts-droid
<LocutusOfBorg> ok, so now I have to get in touch with the maintainers and ask them about their favourite font solution
<LocutusOfBorg> thanks ginggs
<cjwatson> wgrant: I had to spend a bit of time beating pyflakes.vim into submission (fortunately not too long; if you're using that, let me know).
<cjwatson> neovim can have both Python 2 and 3 at once because it has out-of-process plugins, but that's a bit too raw for the moment.
<dgadomski> pitti: hey, can I somehow check what is holding the ifupdown release after verification? (bug 1337873)
<ubottu> bug 1337873 in ifupdown (Debian) "ifupdown initialization problems caused by race condition" [Unknown,New] https://launchpad.net/bugs/1337873
<dgadomski> pitti: are there any regressions reported?
<xnox> tvoss, i will check that.
<cyphermox> good morning!
<pitti> dgadomski: no, I didn't hear about any other regressions
<dgadomski> pitti: is the promotion to -updates after verification automatic or manually triggered?
<pitti> dgadomski: it's manual; I do it now
<dgadomski> pitti: I would appreciate it, thanks!
<teward> any of the apport hooks pros around?
<seb128> teward, you better just ask your question, maybe some "non-pros" would be able to answer
<seb128> or are you interested by having a response only if it comes from a pro? ;-)
<teward> seb128: debugging why an apport generic hook in Ubuntu failed for a given bug
<teward> i.e. hook errors in the global "ubuntu.py" apport hook
<seb128> well, just describe your issue
<teward> though i'm not aware of why it *would* have failed
<teward> well... in triaging a bug in nginx, neither my nginx package hooks were triggered, and there is an error on the global hooks - https://launchpadlibrarian.net/235605675/HookError_ubuntu.txt
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1539316 is the nginx bug, but the issue is that that's the first time i'm seeing hook errors, wasn't sure if there was an issue reported anywhere
<ubottu> Launchpad bug 1539316 in nginx (Ubuntu) "package nginx-core (not installed) failed to install/upgrade: il sottoprocesso installato script di post-installation ha restituito lo stato di errore 1" [Undecided,Incomplete]
<seb128> teward, looks like python encoding handling issues
<teward> hmm
 * teward checks the status on his QA Testing VM
<teward> oh good that's usable, i think i'll try and replicate this...
<teward> maybe there's a bug somewhere
<pitti> teward: yes, looks like the "line" there is already a byte array, that can't be encoded again (only strings can)
<pitti> I guess it's stumbling over some non-UTF-8 stuff in some log
<teward> pitti: then that'd be a bug in the global hooks?
<teward> ah
<pitti> yes
<teward> pitti: has this been reported previously as a bug against apport, or would you like me to file one now?
<pitti> cjwatson, infinity_: hm, what did I do wrong in https://launchpad.net/ubuntu/+source/grub2-signed/1.61ubuntu1 ? seems the binary packages get an ubuntu1 twice in the version
<pitti> teward: I don't know by heart, but that should be simple enough to search for
<teward> ok
<pitti> cjwatson, infinity_: hmm, 1.61ubuntu1+2.02~beta2-35ubuntu1 << 1.61+2.02~beta2-35 (that's not very intuitive, but dpkg --compare-version agrees), so I figure I'd somehow need to construct a different version of grub2-signed?
<seb128> pitti, seems like that package is not made to have non native versioning?
<seb128> just do 1.62?
<pitti> grub2 was in sync, I uploaded an ubuntu change and forwarded to Debian, but it didn't get applied yet
<pitti> seb128: ah yes, I guess so
<pitti> indeed, this is an Ubuntu-only package with Debian version numbers, argh
<cjwatson> pitti: yeah, just use 1.62, but it doesn't really matter
<cjwatson> pitti: ah yes, version ordering is a bit counterintuitive here
<pitti> cjwatson: ack, 1.62 built/uploaded, thanks
<pitti> cjwatson: initially I thought they were kind of "in sync", I didn't realize grub2-signed wasn't in debian
<cjwatson> pitti: It will be eventually, but infrastructure ...
<pitti> yep, just got confused by the version numbers, all good now
<seb128> tyhicks, pitti, thanks for landing that schroot ecryptfs umount fix! \o/
<pitti> right, sorry for taking so long -- this wasn't in the sponsoring queue
<pitti> tyhicks: thanks for the fix!
<pitti> seb128: wow, you watch uploads like a hawk :)
<tyhicks> pitti: which one did you upload?
<seb128> pitti, I get notify-osd bubbles for those when my mailer is open ;-)
<pitti> tyhicks: we have 1.6 in xenial, so that patch
<kirkland> I think seb128 raised that one a LONG time ago :-)_
<tyhicks> seb128: can you confirm that the segfault that you hit earlier this morning was not the fault of ecryptfs?
<seb128> tyhicks, yes, it was in libnss3.so and debsums indicates that file was corrupted and reinstalling the lib fixed it
<seb128> I might have an issue with the kernel -5 though
<tyhicks> odd
<seb128> ata error and fs corruption, seems to be fine with -2
<seb128> tyhicks, apt and sudo would segfault as well
<tyhicks> oof
<tyhicks> that's not a good state to be in
<seb128> indeed
<seb128> well they would segfault after doing their stuff so it's ok
<seb128> like I could sudo apt-get install --reinstall libnss3
<seb128> and get a segfault
<seb128> but the file was valid again
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * seb128 hugs dholbach
 * dholbach hugs seb128 back :)
<seb128> dholbach, thanks for sponsoring xdg-utils, it was pending for a while and Chad was waiting for it
<dholbach> anytime
<mitya57> cjwatson, is there any progress on renaming python-click?
<mitya57> It would be nice to get it done before FF
<cjwatson> mitya57: https://code.launchpad.net/~cjwatson/click/rename-python-packages/+merge/280575
<cjwatson> mvo: ^- could you have a look at that?
<mitya57> cjwatson, are there any consumers of click module outside click source?
<mitya57> reverse-depends tells me about debocker and mycli but those are synced from Debian so they are probably using the other click
<mitya57> If that's true, then maybe you can make the module private and merge it into click binary packageâ¦
<mitya57> (by private I mean install into /usr/share/clicksomething, not dist-packages)
<mvo> cjwatson: sure
<cjwatson> mitya57: There are a couple of out-of-archive things I'd prefer not to break.
<mitya57> cjwatson, okâ¦ though if you add sys.path.insert calls to those out-of-archive things, then they'll work with both old and new versions
<cjwatson> mitya57: sure, but I also don't want to have to spend lots of time tracking them all down :)
<cjwatson> the above MP is a viable stopgap at least
<caribou> xnox: FYI, the server team asked me to look at the clamav merge
<xnox> caribou, yes please
<bladernr_> Are there any known issues trying to do-release-upgrade -d from Trusty (14.04.3) to Xenial?  I am trying and its choking on Utopic for some reason.  If I omit the -d, it seems happy to update to Vivid though.
<bladernr_> http://pastebin.ubuntu.com/14850836/
<bladernr_> Should I file a bug for this?
<infinity> bladernr_: Is Prompt=lts set in /etc/update-manager/release-upgrades ?
<bladernr_> infinity: no, I just changed it to "normal"
<bladernr_> ^^ before trying the upgrade
<infinity> bladernr_: Well, normal won't get you from trusty to xenial.
<bladernr_> How would I get there?  The only docs I could find on updating from Trusty to Xenial via do-release-upgrade are lubuntu related, and they just point to a wiki page on do-release-upgrade itself :/
<bladernr_> I can go and update to vivid, then wily, then hopefully xenial... but in theory, I should not have to jump through hoops to jump from LTS to LTS (even if that LTS is an alpha)
<bladernr_> hrmmm... damn.
<infinity> bladernr_: You should be able to do lts->lts if that's set to =lts, unless we haven't mangled things yet to allow that.
<infinity> bdmurray_: Are lts->lts development upgrades set up yet?
<bladernr_> infinity: that sound you hear is my beating my head against my keyboard because I completely overlooked the obvious.
<bladernr_> sigh... setting it BACK to lts works... I am not sure why I changed it to begin with, but at the time I assure you it made sense to me
<infinity> Heh.
<infinity> bdmurray_: Unping. :P
<bladernr_> I blame Monday
<infinity> Monday is a bane to us all.
<sarnold> hearhear
<infinity> sarnold: Oh hai.  How do you feel about swapping in state on LP: #1417608 ?
<ubottu> Launchpad bug 1417608 in servicelog (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,Confirmed] https://launchpad.net/bugs/1417608
<sarnold> infinity: oy ppc64-diag.. there's a blast from the past..
<sarnold> wow I forgot how many annoyances I found..
<infinity> sarnold: Maybe you're just easily annoyed?
<sarnold> infinity: too right you are
<pitti> xnox: ah, I had another systemd fix queued up (and lots of fixes in Debian), but oh well
 * pitti commits your change
<bladernr_> ok, so the upgrade from Trusty to Xenial failed spectacularly.  It looks to me that it all centers around fontconfig.  that fails to update, and from there is a cascade of 168 other packages that won't install.
<bladernr_> http://paste.ubuntu.com/14852379/
<bladernr_> ^^ aptlog from the machine.  I can access it directly, so it's running, but just barely.
<bladernr_> and this seems to be (according to the error when trying to install fontconfig alone) the issue causing all the grief: http://pastebin.ubuntu.com/14852409/
<bladernr_> fwiw, I filed this bug https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1540591
<ubottu> Launchpad bug 1540591 in fontconfig (Ubuntu) "fontconfig breaks Trusty - Xenial upgrade" [Undecided,New]
<Saviq> infinity, hey, can I please bother you to recycle the regression in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity8 - it's a known flaky test (bug #1532358)
<ubottu> bug 1532358 in unity-scopes-shell (Ubuntu) "flaky autopkgtests cause migration issues" [High,In progress] https://launchpad.net/bugs/1532358
<Saviq> oh actually, mterry could you â
 * Saviq found a core dev on the team, will bother him instead :)
<mterry> Saviq, :)
<Saviq> infinity, unping
<mterry> Saviq, submitting
<mterry> Saviq, submitted rather
<Saviq> tx
#ubuntu-devel 2016-02-02
<darkxst> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<mitya57> Trevinho, hi, so are you still going to do a libwnck upstream release?
<dholbach> good morning
<caribou> We don't support direct upgrades from Precise to Xenial, right ?
<rbasak> caribou: correct. Must go via Trusty.
<caribou> rbasak: thanks
<ginggs> doko, can you remove the armhf binary for julia 0.4.2-3 please? it is holding up the suitesparse transition. i don't yet know why 0.4.3 FTBFS on armhf in ubuntu (debian is fine), and 0.4.2-3 now also FTBFS on  armhf.
<darkxst> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs darkxst
<Trevinho> mitya57: hi, yes... I'll do that soon
<darkxst> dholbach, np ;)
<seb128> darkxst, btw that font/seed bug, it has an approved MIR
<seb128> you commented saying it needs one
<mitya57> Trevinho, ta
<darkxst> seb128, yeh saw aaron's comment
* tepper.freenode.net changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<caribou> Can someone explain why grab-merge outlines conflicts on files that are part of the pristine tarball ?
<sil2100> dholbach: hey! Regarding
<sil2100> unity-settings-daemon
<sil2100> dholbach: this is a CI Train released package, the MPs were for the train to release them ;)
<sil2100> Since it's managed in bzr
<caribou> shouldn't those only be touched by patches in debian/patches ?
<sil2100> dholbach: so no need for that to be sponsored, it'll be released as part of a silo
<dholbach> sil2100: I'm sorry - I uploaded it to xenial
<mitya57> dholbach, sil2100: we should probably remove these two entries then
<mitya57> http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-sponsoring/trunk/view/head:/sponsors-page.py#L23
<mitya57> u-s-d and u-c-c
<seb128> no we shouldn't
<sil2100> dholbach: no worries, I already published the big silo with all 3 projects
<seb128> those are projects that we maintain and we want to have changes sponsored
<mitya57> seb128, okâ¦ I don't see why these two should be special and different from other Canonical-is-upstream stuff, thoughâ¦
<seb128> well other projects should probably be on the sponsoring list as well
<seb128> since those are things that are part of Ubuntu and uploaded to the archive
<mitya57> Then fine :)
<Laney> https://launchpad.net/~unity-settings-daemon-team/+members#active
<Laney> anyone in ubuntu-desktop can indeed sponsor these changes
<__marco> Hello. I am sorry to boring you, but I would like to receive a comment about https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/776818
<ubottu> Launchpad bug 776818 in vde2 (Ubuntu) "[MIR] vde2" [Undecided,Incomplete]
<__marco> vde2 is a big package and its inclusion in main is not feasible, but the inclusion of one of its library is enough to support vde in qemu
<__marco> Its inclusion in Ubuntu 16.04 would be a big goal, but the bug report seems stagnant.
<__marco> Should I open a new bug report for the inclusion of that library only?
<seb128> __marco, no need of a new report no
<seb128> (doh, nicknames starting with a _ are annoying to type!)
<Unit193> seb128: Irssi is for the lazy, it knows that and will complete "marc<tab>" with __marco. :P
<seb128> Unit193, clever ;-)
<Mirv> pitti: regarding https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html - could we get some retries for the failed non-overridden ones? none of the failures seem to have something to do with alt-tab behavior that the update changes. also one qtmir i386 rerun needed at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-023/excuses.html
<Mirv> pitti: kwin is probably something to do with "new hybris or not" as seen at http://autopkgtest.ubuntu.com/packages/k/kwin/xenial/amd64/
<__marco> Unit193: weechat does the same
<seb128> bdmurray_, hey, is there a known issue with the retracers? most of 16.04 entries on the weekly view have no symbols
<seb128> bdmurray_, e.g
<seb128> nautilus (11) /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4705.0+b1681 â /usr/bin/nautilus+46a8f â /usr/bin/nautilus+36b57 â /usr/bin/nautilus+48719 â /usr/bin/nautilus+487d3 â /usr/bin/nautilus+4916a â /usr/bin/nautilus+49692 â /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+feff â /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+2250e â /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+2ad8c â /usr/lib/x86_64-lin
<seb128> ux-gnu/libgobject-2.0.so.0.4705.0+2b0bf â /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.6+35c9fa â /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+16748 â /usr/bin/nautilus+71c9b â /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+14d25
<seb128> ups, sorry, I didn't think that it would copy chars not rendered on screen
<bdmurray_> seb128: Do you have a url I could take a look at?
<seb128> bdmurray, https://errors.ubuntu.com/problem/cb2fdb3c6dbe918d9e1c57027213f63dc685e402
<seb128> https://errors.ubuntu.com/problem/8b87caa038f87a22ec7dda992a85a22f583d6144
<seb128> https://errors.ubuntu.com/problem/1d6559c22aacf083d27a9f591f320d97706adc22
<seb128> https://errors.ubuntu.com/problem/ea90702c93dd24bd24156ea1bb7c013b070292b7
<seb128> 4 components differents
<seb128> apt nautilus u-c-c gnome-disks
<seb128> there are quite some others examples on the weekly view
<bdmurray> seb128: I'll dig into it.
<seb128> thanks
<tinoco> hello. im having problems understanding where mstflint xenial package is coming from
<tinoco> https://code.launchpad.net/ubuntu/+source/mstflint
<tinoco> it looks like there isn't a xenial lp branch for latest debian merge
<tinoco> xenial is merged with sid but i can't find its bzr branch
<tinoco> does someone know why ?
<tinoco> the merge request came from: https://bugs.launchpad.net/ubuntu/+source/mstflint/+bug/1528791
<ubottu> Launchpad bug 1528791 in mstflint (Ubuntu) "Update mstflint to the latest upstream " [Wishlist,Fix released]
<cjwatson> tinoco: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
<cjwatson> tinoco: just grab the source package
<tinoco> cjwatson: ok. will work with debdiffs only for SRUs then
<tinoco> cjwatson: tku
<cjwatson> that was always a good idea anyway, the importer's behaviour was always especially ropey for SRUs
<cjwatson> even when it worked at all
<tinoco> cool
<mitya57> And that reminds me that half of our packaging.ubuntu.com guide still describes UDD workflow
<tinoco> mitya57: i was going to send an email to ubuntu-devel regarding this
<pitti> kees, infinity: TB meeting reminder
<infinity> stgraber: And you.
<doko> xnox, is numactl supposed to ftbfs on s390x?
<awe__> seb128, thanks for reviewing my bluez mp; just updated it based on your comments
<seb128> awe__, thanks, let me have a look
<seb128> awe__, looks good, approved
<awe__> thanks seb128
<seb128> awe__, you might want to set a commit message, CI landings tend to want one
<seb128> yw!
<tinoco> doko: xnox: PR/SM manages physical CPU dispatchers and it changes whenever a LPAR is activated/deactivated (or, if IFL is shared, dispatcher can change vCPU mappings).
<tinoco> so.. i don't see numactl working on s390x even for LPAR deployments
<doko> tinoco, ta
<tinoco> you can get a "virtual topology" having an idea if CPUs are close to each other at that particular moment
<tinoco> but the topology is "virtual"
<tinoco> not related to the physical one
<awe__> seb128, ack
<awe__> seb128, commit msg added; thanks again!
<seb128> awe__, yw!
<xnox> doko, Â¯\_(ã)_/Â¯
<doko> tinoco, is openmpi "supported" on s390x? e.g. I just test built it: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+build/8929782
<tinoco> doko: despite the fact that running mpi jobs on s390x is way expensive
<tinoco> it should work for tcp/ip intercommunication
<doko> tinoco, cool, then we don't have to care about mpich
<tinoco> doko: i haven't ever seen someone running openmp/mpi stuff
<tinoco> considering that s390x had 1 fp per cycle
<tinoco> :o)(
<tinoco> now it has 2 :o
<doko> sure, but it makes things easier when we can handle it in the archive like all other archs
<tinoco> doko: +1
<tinoco> i dont think they "depend" on something that would ftbfs
<tinoco> mpi implementations might rely on infiniband (librdma/libmlx/libibverbs)
<tinoco> that *could* in theory be problematic. but then, for s390x, we could remove those dependencies
<tinoco> and stick with tcpip
<xnox> doko, +1 to switch to openmpi.
<pitti> caribou: hey! are you planning on merging rsyslog again, to fix bug 1534106? it's a real nuisance and breaks juju-local quite hard :/
<ubottu> bug 1534106 in rsyslog (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [High,Triaged] https://launchpad.net/bugs/1534106
<xnox> pitti, could you please let systemd through? multipath tools brekage is known and being work on.
<pitti> xnox: I thought it was already fixed
<xnox> horum. let me check harder then.
<pitti> xnox: I retried it this morning, see http://autopkgtest.ubuntu.com/packages/m/multipath-tools/xenial/i386/ -- the retry ran with ubuntu11
<xnox> pitti, yeah, i see it fails to remove loopbacks, cause the device is still busy.
<xnox> i think kpartx -av, followed by -dv is too quick, and needs "udevadm settle" in between.
<pitti> xnox: I suppose that's just a race in the test now, though?
 * pitti lets it through then, not related to the new systemd
<xnox> let me upload that, and see if that improves things.
<pitti> xnox: hint committed
<mdeslaur> is anyone planning on trying to get wine back in sync with debian?
#ubuntu-devel 2016-02-03
<matv1> hi all
<matv1> does anyone know of a working qml app that does xmlhttp requests ?
<matv1> or alternatively: does anyone know of a way to use it without apparmor messing it up
<sarnold> what are your DENIED lines?
<matv1> hi sarnold hang on i'll chuck it in a pastebin
<matv1> http://pastebin.com/xGXphnEi
<matv1> i have to add that it only fails when i deploy the app to the phone. running it in the sdk on the desktop, it does great
<sarnold> heh I hadn't expected dbus errors...
<sarnold> matv1: could you file a bug against click-apparmor source package, include these lines, any DENIED lines from syslog, and perhaps a small copy/paste of the function that generated these errors? thanks
<sarnold> matv1: either 'ubuntu-bug click-apparmor' (if that works on the phone?) or https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+filebug
<matv1> sarnold sure. no problem
<matv1> sarnold are you canonical if i may ask?
<sarnold> matv1: I am
<matv1> sarnold great thanks :)
<sarnold> matv1: you're welcome, I hope this helps sort it out ;) I don' tknow much about the wrappers around the apparmor policy, but I'm pretty sure filing a bug there will sort things out :)
<matv1> hmm not sure about that :) but i will stay hopefull
<matv1> i had been tinkering with this a while back. about 6 months ago. gave up on it then. hope it would have been better now. because there is a bug about this where at least jamie strandboge participated in, I recall
<sarnold> yeah, and he'll probably participate in this one too :) but the trick is there's a huge amount of qml/qt infrastructure and it doesn't all fit with our security goals. so some APis are allowed, some are forbidden, and mostly we only investigate adding ones as people run into them
<sarnold> there's some connectivity API with Qt that apparently allows way too much personally identifiable information or similar to be handed to confined apps, which is why we block it, but nothing prevents rewriting the APIs or services to expose only what's needed. the trouble is there's only so many hours per day and so many people to work on things..
<matv1> sarnold I appreciate that. I will do that bug report. let's see how it goes. Thanks again
<sarnold> thanks matv1 :) have fun
<ginggs> mdeslaur: is the "Ubuntu Wine Team" https://launchpad.net/~ubuntu-wine no more?
<pitti> Good morning
<caribou> pitti: I'm done with the rsyslog merge, just want a second look before uploading; hopefully today
<pitti> caribou: yay, great
<dholbach> good morning
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100, darkxst
 * dholbach hugs sil2100
 * sil2100 hugs dholbach back
<Mirv> pitti: hey, could you consider retrying some https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html related results and maybe overriding kwin and/or hinting it not to try it together with the hybris update? and also i386 qtmir retry at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-023/excuses.html
<Mirv> I'm hearing rob_ru might be bringing "retry" button to those pages in a few weeks, which sounds wonderful
<pitti> Mirv: retry button> that needs some legwork on my side first, but yes, we should do that
<dholbach> can somebody moderate my mail on u-d-a through?
<ginggs> Is it possible to get the armhf binary for julia 0.4.2-3 removed? it is holding up the suitesparse transition. i don't yet know why 0.4.3 FTBFS on armhf in ubuntu (debian is fine), and 0.4.2-3 now also FTBFS on  armhf.
<pitti> Mirv: I retried the armhf failures (xenial, will do vivid in a sec); but kwin passes in Ubuntu
<pitti> Mirv: and that failure looks like some API change, not a transient issue?
<pitti> dholbach: done
<Mirv> pitti: it's when it's tested with the new libhybris, not because of qtdeclarative changes
<dholbach> thanks pitti
<Mirv> pitti: thanks.
<Mirv> pitti: there are also older failures in archive when the new libhybris is being tested.
<pitti> Mirv: qtmir retried for the vivid PPA
<pitti> ginggs: yes, there are no reverse depends (just some reverse recommends from science-* metapackages)
<pitti> Mirv: ah, I guess robru tests PPAs against all -proposed
<pitti> Mirv: so, I don't want to override that in ubuntu as it's clearly a regression, and either libhybris or kwin needs to be updated
<pitti> and by overriding we would let libhybris in and land the regression
<ginggs> pitti, ok, can you do remove it please, or shall i file a bug?
<pitti> Mirv: so I'd recommend to just ignore that one failure for this landing
<pitti> ginggs: removed
<Mirv> pitti: the problem is convincing QA to get that silo manually in to their consideration :) but I believe they might believe me if I quote you, and if the other non-overridden tests pass. thank you again.
<ginggs> pitti: thanks!
<pitti> Mirv: yes, you have my blessing and you can quote me on that :)
<pitti> Mirv: it would probably be better if we tested PPAs not against the entirety of -proposed, so that they are better isolated against such unrelated breakage
<pitti> or, once someone fixes libhybris or kwin, we can retry it and then it'll work too
<Mirv> pitti: ok, robru could change the behavior so that not all of -proposed would be used
<pitti> Mirv: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html looks better now
<Mirv> pitti: indeed it does! just waiting for the vivid i386 qtmir still.
<Mirv> ..and it updated
<pitti> yay
<rharper> hi, I've been working on a libnl sru into trusty (https://bugs.launchpad.net/ubuntu/trusty/+source/libnl3/+bug/1511735) ; the update is in trusty-proposed and the new package exposed a bug in NetworkManager (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1539634) which has been fixed and pushed into trusty-proposed as well;  One of the users suggested that we add a Breaks: and release an update to libn
<rharper> l with the Break to ensure that no users get the older networkmanager and the newer libnl;  is network-manager (<< 0.9.8.8-0ubuntu7.3) sufficient ? and is this something we should do to ensure users install the newer NM before upgrading libnl ?
<ubottu> Launchpad bug 1511735 in libnl3 (Ubuntu Trusty) "libnl: fail to bind() netlink sockets" [Medium,Fix committed]
<ubottu> Launchpad bug 1539634 in network-manager (Ubuntu Trusty) "network-manager crashes when using libnl-3-200-3.21.1-1ubuntu1" [High,Fix committed]
<cjwatson> rharper: Breaks sounds correct and sufficient
<rharper> cjwatson: and should I limit the Breaks to the packages that NM depends upon ?
<rharper> libnl provides more than just those 3
<cjwatson> rharper: I don't quite understand the question
<rharper> in libnl debian/control, we list multiple binary packages, do I apply the Breaks: line to each of those or only the entries for the packages that NM actually depends up (and installs)
<cjwatson> rharper: Put it at the root of the dependency hierarchy; since there is a root here, you only need it in a single place
<rharper> cjwatson: ok, thanks!
<cjwatson> rharper: That is, you only need it on libnl-3-200, not anywhere else
<cjwatson> rharper: Well, strictly, it should be on the package where the actual code that breaks is shipped, but I'm guessing that's in the core library
<rharper> ok
<smoser> hey. i'm in need of some help.
<smoser> https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/34/consoleFull
<smoser> thats a log of a seeded install
<smoser> my understanding is at that end of that install, it tries (reasonably) to unmount the target
<smoser> i think that umount_active is asking us a question because it tried to unmount the target and failed
<smoser> ie, the target was "active" because some process was running there and had open file handles.
<smoser> can someone at least verifiy that my understanding of 'umount_active's purpose for that question is right ?
<cjwatson> No, that isn't correct
<smoser> ]o/!
<cjwatson> Let me find you the code
<smoser> thank you!
<cjwatson> An important thing to understand is that this is during partitioning, not at the end of the installation process; processes shouldn't generally be running that aren't the installer (and there are no such process checks)
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/partman-base/ubuntu/view/head:/init.d/parted#L154
<cjwatson> The second comment there basically explains the idea
<smoser> its not during the partitioning tough
<smoser> look at that log, cjwatson
<smoser> oh. maybe.
<cjwatson> I have, and you are incorrect.
<smoser> :)
<cjwatson> The last menu item that is logged as selected is partman-base.
<smoser> so what else would be mounted ?
<cjwatson> So the question is ... that
<smoser> this is a transient failure
<smoser> that is what is really odd
<smoser> and i'm pretty sure the input disk to the installer is full of zeros
<smoser> (ie, no old filesystem or swap or antying like that that could possibly get mounted)
<cjwatson> Is /var/log/partman from this install logged somewhere?
<cjwatson> Can't see it directly in the build artifacts
<smoser> well, that one got killed
<cjwatson> smoser: This log seems to contain two runs of the installer
<smoser> i dont know that the file is collected.
<smoser> interesting. so it rebooted to the installer, and the second time then found a disk that got automatically mouinted or something
<cjwatson> There are two hits for "Menu item 'partman-base' selected", and the first is followed by the installer doing more stuff after that
<smoser> definitely
<smoser> and 2 kernel boot logs
<cjwatson> Yeah.  Race in the reboot arrangements?
<smoser> thank you colin. that is at least somethigng to look at
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<cjwatson> smoser: I'm a little surprised by the automounting too, since the second install hasn't reached the point where it would do the automounting I'm aware of yet, and in any case that automounting is off by default ... but it could be somewhere else I'm not remembering, and who cares really since this is all in the land of consequential failures
 * dholbach hugs sil2100
<mdeslaur> ginggs: oh, I was going to say no, but it does look like mlankhorst uploaded to the ppa in december
<mdeslaur> (re: wine)
<ginggs> mdeslaur: i noticed the Ubuntu Wine Team PPA is no longer listed on the WineHQ download page, but instead a new team https://launchpad.net/~wine
<doko> tinoco, xnox: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8~+rc1-1~exp1
<smoser> cjwatson, are you sure it woudl be a mount ? if it would notice that lvm had holders and fail, thent that coudl be it.
<cjwatson> smoser: yeah, that information is read from /proc/mounts if you look at the code, it has to be a mount
<rharper> trying to build a source package (libnl) and getting an error from debuild -S, complaining: dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input data in general section of control info file (http://paste.ubuntu.com/14865920/)
<rharper> xenial host
<cjwatson> rharper: ignore
<cjwatson> that's a warning not an error
<rharper> ok, error further down
<cjwatson> rharper: oh, you are seeing an error but it's not the one you summarised here
<cjwatson> rharper: debuild -S -nc
<cjwatson> rharper: you need to have the build-depends satisfied if you aren't using -nc; using -nc avoids that requirement but means you need to be more careful to ensure that your source tree is clean
<rharper> ah
<cjwatson> given that you just pulled a fresh source package here and modified it, -nc is safe (but remember to edit the changelog too!)
<rharper> cjwatson: thanks for the tip; I though I had build-deps satisfied but I did not;  yep will update changelog too
<tinoco> doko: o/
<tinoco> doko: i dont think ocaml is available on s390
<doko> tinoco, it is available. disabling lldb works around the build failure
<tinoco> cool!
<LocutusOfBorg> doko, hi, do you plan to sync llvm-toolchain-3.8 from experimental?
<LocutusOfBorg> I might give some time in fixing build failures
<LocutusOfBorg> oh well, already there, sorry
<LocutusOfBorg> amd64 failed for ENOSPACE
<seb128> barry, hey, bug #1541407 seems due to your python3 changes, can you have a look?
<ubottu> bug 1541407 in apt-xapian-index (Ubuntu) "/usr/share/apt-xapian-index/update-apt-xapian-index-dbus:SyntaxError" [High,New] https://launchpad.net/bugs/1541407
<seb128> barry, bug #1541408 also seems to be due to the xapian update
<ubottu> bug 1541408 in sessioninstaller (Ubuntu) "/usr/bin/session-installer:AttributeError:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@38:/usr/bin/session-installer@23:/usr/lib/python3/dist-packages/sessioninstaller/core.py@53:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@39" [Undecided,New] https://launchpad.net/bugs/1541408
<seb128> 'xapian' has no attribute 'DatabaseOpeningError'
<xnox> rbasak, is it normal that we have php5 and php5.6 packages which are both php 5.6?
<nacc> xnox: it's 'normal' in that debian has it that way .... what's a bit weird is that php5.6' version is different than php5
<nacc> i believe php5.6 is a metapackage, as well
<barry> seb128: okay, thanks.  i'll take a look
<seb128> barry, thank you!
<xnox> nacc, i shall slowly back away then =)
<nacc> xnox: yeah, it's quite gross
<nacc> xnox: hopefully, we'll just drop it all :)
<barry> seb128: LP: #1541407 is an easy fix.  LP: ##1541408 doesn't yet make sense ;)
<ubottu> Launchpad bug 1541407 in apt-xapian-index (Ubuntu) "/usr/share/apt-xapian-index/update-apt-xapian-index-dbus:SyntaxError" [High,New] https://launchpad.net/bugs/1541407
<barry> LP: #1541408
<ubottu> Launchpad bug 1541408 in sessioninstaller (Ubuntu) "/usr/bin/session-installer:AttributeError:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@38:/usr/bin/session-installer@23:/usr/lib/python3/dist-packages/sessioninstaller/core.py@53:/usr/lib/python3/dist-packages/sessioninstaller/utils.py@39" [Undecided,New] https://launchpad.net/bugs/1541408
<seb128> barry, yeah, the syntax error looked like a simple one, thanks for fixing it!
<barry> seb128: if i can't figure out the session installer one before i have to start sprinting, i'll upload the fix for the first one and come back to it
<seb128> barry, unsure about the other one, either there was an incompatible change in the bindings or something weird?
<seb128> barry, yeah, it's less of an issue, I would say that can wait for after ff
<barry> seb128: that's the thing, from the cli the imports work fine
<barry> cool
<seb128> k, don't bother for now then
<seb128> the syntax error is the important one
<seb128> it prevents that file to work at all
<barry> seb128: cool.  let me upload that one right now then
<seb128> thanks
<barry> cheers
<scaldwell> Does anyone know if Ubuntu is planning a dynamic /etc/fstab similar to what has been done for /etc/motd?  This would make it much easier to build cloud environments.
<jrwren> scaldwell: to what end, and how would it make it easier?
<ogra_> probably not soon ...
<ogra_> but i could imagin that we switch to systemd mount units at some day
<ogra_> pitti might know if there are any plans
<pitti> not really a "plan", but you can do this today if you want
<ogra_> technically you can boot without fstab today already as long as you have a single partition setup .... ubuntu will happily boot using /dev/root
<scaldwell> It would allow me to parameterize EFS volumes.
<pitti> i. e. create .mount units instead of fstab entries
<pitti> systemd itself does that via a generator which reads fstab and synthesizes .mount units in /run/systemd/generator/*.mount
<scaldwell> true.  I just was talking about the new dynamic /etc/motd and we started discussing IRL how it would be nice to have one way to rule them all.
<xnox> pitti, cyphermox, we activate lvm volume groups with udev rules, by default, including inside d-i. Which when done on s390x dasd drive, make it impossible to format it. Should we disable udev rules that auto-activate lvm volumes in lvm2 udeb?
<xnox> bug #1536664
<ubottu> bug 1536664 in debian-installer (Ubuntu) "Installer cannot use DASD if it was used with LVM before" [High,New] https://launchpad.net/bugs/1536664
<pitti> for EFI systems systemd can also read their partition UUIDs, and as long as they are correct, auto-mount them
<pitti> but to this date our installer still writes wrong UUIDs, so that doesn't work
<xnox> oh
<pitti> cyphermox: ^ which reminds me, we quickly talked about that ages ago, but never got around to it..
<xnox> pitti, i can fix the installer uuids, i think.
<cyphermox> hum, what?
<jrwren> scaldwell: on ec2?
<cyphermox> xnox: so you're installing on a system where the drives were used for LVM before, they got auto-activated, and now you can't remove the volumes to format the drives?
<cyphermox> pitti: wrong UUIDs?
<pitti> https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs â this
<ogra_> pitti, but that will only work with GPT
<cyphermox> ah, jes
<pitti> cyphermox: last time I checked, all GUID partitions that d-i created were of the generic type "Linux filesystem data", not "root partition", "home partition", "swap", etc.
<cyphermox> the UUID for the EFI partition
<cyphermox> ah
<ogra_> pitti, also parted doesnt know about GUIDs
<pitti> ogra_: sure; there is no counterpart to do that with MBR, for that you need fstab
<xnox> cyphermox, yes, and where "format" i mean "mainframe specific operation for dasd drive specifically to `format` them with dasdfmt before partman was even run"
<ogra_> pitti, i just had to move all of snappy to sgdisk thanks to that lack
<xnox> cyphermox, aka re-initialise the drive
<cyphermox> xnox: does it have to run before partman runs?
<pitti> ogra_: indeed, it's annoying; I didn't find a good CLI way to change partition type UUIDs
<pitti> ogra_: sgdisk does that? good to know
<ogra_> pitti, sgdisk ;)
<pitti> xnox: how does it prevent formatting? You mean you want to re-format a PV into e. g. a plain ext4 partition?
<cjwatson> ogra_: It kind of does, they're just mapped into parted-speak
<cjwatson> And maybe not completely so
<xnox> cyphermox, yes, otherwise partman will see gibberish on the disk, and will not be able to e.g. create a valid parition table on it, or write a valid partition table.
<cjwatson> e.g. I'm pretty sure we do actually set a swap GUID
<xnox> pitti, prevents "dasdfmt" to succeed, if one chooses to reinitialise the drive (dasdfmt)
<cyphermox> cjwatson: I think that might be the only one
<ogra_> cjwatson, well, i needed to dynamically set them to certain values to create the proper boot setup for the dragonboard (each bootloader bit checks for the next piece to load by GUID there)
<pitti> xnox: ah, and it's not an option to run vgremove/pvremove before either, I suppose?
<cyphermox> xnox: in such a case, partman does not see the drives at all?
<cjwatson> cyphermox: possibly, yes
<pitti> xnox: if you remove the udev rules in d-i, then you can't re-install onto an existing LVM, or d-i needs to be modified to piece them together manually?
<xnox> pitti, cyphermox - it's a step/udeb/menu before partman.
<ogra_> cjwatson, and i didnt find anything in parted itself for this ...
<cjwatson> tricky though, because parted isn't really told about the purpose of the partition, only (at best, and probably not always) what FS type it's going to contain
<xnox> pitti, no. as debian-installer has all that. E.g. in partman, you enter lvm menu, activate volume group, etc.
<cjwatson> somebody should take this to parted-devel to discuss requirements
<cyphermox> xnox: seems to me like it shouldn't care that there are LVM volumes, and that if it does it could just as well be told to disable then before doing whatever it does
<nacc> xnox: question for you on one of your merges for bacula from 2013 :)
 * ogra_ points to http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/partitioner.sh ... which uses http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt to create the bootloader setup required
<xnox> cjwatson, in clearlinux, after partitioning, i would reset the part-type uuid with the "systemdish" ones, cause at that point i had the information "yeap, this will be rootfs partuuid".
<cjwatson> it would perhaps be possible to do that in partman-target
<cjwatson> it has the mount information
<cyphermox> yeah
<xnox> cyphermox, pitti - i think it's wrong to auto-activate lvm groups with udev, and thus interfeering with d-i state machine.
<pitti> xnox: you know d-i much better than I, I trust your word :)
<xnox> pitti, i wonder if desktop/ubiquity breaks if i change the udeb udev rules though =)
<cyphermox> I wouldn't expect it to
<pitti> xnox: what do you want to change there?
<cjwatson> this is why we generally try to beat the udev rules into submission rather than removing them
<pitti> xnox: (LVM auto-activation is in lvm, not udev)
<cjwatson> to avoid having to have a different workflow in ubiquity
<xnox> ude B i meant.
<xnox> as in lvm2.udeb
<pitti> debian/{dmsetup,lvm2}-udeb.install
<pitti> xnox: so, that reduces one line of delta :)
<xnox> oh.
<barry> seb128: fixed a couple other problems with -dbus while i was at it <wink>
<pitti> two actually (one for each udeb)
<seb128> barry, great :-)
<xnox> pitti, well, debian doesn't have udev rules for lvm full stop.
<pitti> xnox: right, this is an ancient delta of our's
<pitti> xnox: these days they have a lot of fancy units, but I never looked at those in detail
<xnox> pitti, surely we don't care about lvm on the phone, and we should drop this stuff and use something systemd-ish? a generator?
<pitti> xnox: I suppose easiest thing might be to install Debian sid on LVM into a VM and see how it works there?
<xnox> hm, yeah.
<pitti> i. e. what puzzles together VGs there; it ships the units, but no udev rules
<xnox> they still have some udev rules, but not the activation ones.
<pitti> or maybe it's still just the scripts/units that run once on boot, but that'd be rather poor
<xnox> pitti, i wonder if it's best to eg. look at upstream and/or fedora.
<pitti> i. e. this ought to work for hotplugged drives too
<nacc> xnox: specifically if you knew why the postgres dependency was bumped to 9.3 .. we're going to move bacula to universe, so it might be nice to remove that from the delta
<xnox> nacc, if it builds and runs unmodified, and e.g. "libncurses-dev" and "liblzo2-dev" build depends are present in bacula.
<xnox> nacc, one can just sync it, and demote it to universe.
<xnox> nacc, as far as i can tell all our changes were done to make it suitable for main.
<nacc> xnox: ok, i'll make a note of that; it seems like the upstream code has fixed the ncurses dependency
<xnox> nacc, cool.
<nacc> and liblzo2 is merged
<nacc> upstream, i mean
<xnox> pitti, looking at upstream alone, there is a systemd instance unit that binds to all block devices to scan and activate them.
<xnox> pitti, which is nice, cause then one can stop the unit.
<pitti> xnox: that unit gets activated via udev, I figure
<xnox> which would fix the https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081
<ubottu> Launchpad bug 1088081 in lvm2 (Ubuntu) "udev rules make it impossible to deactivate lvm volume group with vgchange -an" [High,Confirmed]
<xnox> pitti, yeap, udev->systemd-> generate the fake .device units that these things bind to.
<pitti> they aren't "fake" :)
<xnox> which would still be ubuntu-ish "auto-enable all the lvm groups" but "without bugs"
<pitti> if you tag an udev device with "systemd", you will get a systemd .device unit for it with proper state, and can then make that trigger services or other stuff
<xnox> pitti, i'm also pointed at lvmetad thing
<xnox> oooh lvmetad does nested lvm properly.
<xnox> right, i think i have screwed up this d-i bad enough. let me reboot it.
<xnox> cyphermox, pitti: i wonder if i should use the force, when doing dasdfmt.
<xnox> and that's it.
<cjwatson> Laney: http://archive.ubuntu.com/ubuntu/dists/xenial/main/dep11/ etc. if you fancy having a look
<caribou> pitti: newest rsyslog has made it to the archive, you may want to update & retest your juju bug
<pitti> caribou: cool, thanks
<hallyn> dpm: hey,
<hallyn> whois dpm
<hallyn> d'oh
<dpm> that'd be me :)
<hallyn> just making sur ei'm buggin ther ight person :)
<dpm> but I'm on the phone
<hallyn> dpm: if you need help with cgmanger ping me when you're off the phone
<dpm> awesome, thanks
<smoser> cjwatson, back on that partman failure thing...
<smoser> in d-i, if there was swap partition would boot magically use it and then d-i see it busy? i suspect not, but grasping at what would have mounted something on that disk
<smoser> as that seems completely non-sensical (and is probably a bug)
<cjwatson> smoser: that wouldn't show up in /proc/mounts, so cannot be relevant
<smoser> does it dump /proc/mounts anywahere or could it ?
<smoser> on failure to find a disk, that'd likely be useful.
<cjwatson> smoser: I don't think it does right now; it would be a reasonably easy patch to partman-base to make it log that in the cases where it asks a question
<smoser> yea. thanks for your help cjwatson
<smoser> since you're here.... and you're last touch (in gutsy)
<smoser> https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-drop-ppp/+merge/284941
<smoser> https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-ppp-to-server-ship/+merge/284943
<smoser> your thoughts are very appreciated there.
<ginggs> doko: i see you uploaded mpi-defaults recently, do we need debian bug #813494 fixed as well?
<ubottu> Debian bug 813494 in mpi-default-dev "mpi-default-dev: Please depend on openmpi (>= 1.10.2 -3 )" [Important,Open] http://bugs.debian.org/813494
<dpm> hallyn, so, to debug why apps don't start on unity 8, is it essentially these steps? http://pastebin.ubuntu.com/14868891
<cjwatson> smoser: I don't really have an opinion on that
<hallyn> dpm: the cgmanager debug step isn't quite right.  but hold on, you're on xenial?
<dpm> hallyn, yes I am
<hallyn> dpm: ok, libpam-cgfs is replacing libpam-cgm there.
<hallyn> we can still test with libpam-cgm, but...
<hallyn> dpm: your original failure was with libpam-cgfs installed?
<dpm> tried both
<hallyn> dpm: and right now you have libpam-cgm installed?  ok, lets proceed with that then.  systemd is running, right?
<dpm> hallyn, hold on, otp again, sorry
<hallyn> inthat case, do 'sudo systemctl stop cgmanager', then 'sudo /sbin/cgmanager -m name=systemd --debug' (in a term with scrollback or piping into a file)
<hallyn> dpm: np.  anyway, ^ do that and then try again starting the app and pastebin the cgmanager debug output
 * hallyn biab
<dpm> hallyn, ok, back if you are around. I've got libpam-cgfs installed
<Laney> cjwatson: thanks - now to find out why apt doesn't download it. :)
<Laney> it knows about the indextarget and the URL seems right
<Laney> juliank: if you're around, is it you who knows about IndexTargets?
<hallyn> dpm: ok, and it still fails?
<hallyn> with the new version?
<hallyn> (0.17-0ubuntu3)
<Laney> juliank: I install appstream on xenial and update, and apt-get indextargets --no-release-info shows it with the right URL (without .gz but that appears to be correct), yet it's not downloaded
<dobey> pitti: hey. who all has access to do autopkgtest retries for britney on silos?
<sarnold> I thuoght it was anyone who could upload the package or the triggers..
<pitti> dobey: those: ubuntu_archive:x:2552:cjwatson,seb128,doko,pitti,adconrad,vorlon,didrocks,stgraber,laney
<pitti> sarnold: for ubuntu yes, but web retry isn't implemented yet for silos
<sarnold> ahhhh
<dobey> oh, only archive admins? ok
<hallyn> dpm: libpam-cgfs does not use cgmanager at all.  So if it fails with libpam-cgfs and with the '-c freezer' removed from the line in /etc/pam.d/common-session, that'll be very curious
<dobey> sarnold: well, i don't have permissions to upload the package or the triggers, i don't think; but at least "any motu" would probably work for that situation
<hallyn> dpm: in that case we'll have to assume that libpam-cgfs is not being called, and look into why.  (we'll have to verify that by having the app launcher sleep right before final exec of the app and look at /proc/pid/cgroup)
<dobey> pitti: well, since you're here, can you rerun the unity-scope-click test on xenial armhf for silo 41?
<pitti> $ run-autopkgtest -s xenial -a armhf --ppa ci-train-ppa-service/stable-phone-overlay --ppa ci-train-ppa-service/landing-042 --trigger pay-service/15.10+16.04.20160114-0ubuntu1 unity-scope-click
<pitti> dobey: ^ done
<dobey> pitti: 41 not 42 :)
<dobey> but thanks
<pitti> dobey: that cannot be -- 42 is TEH RIGHT ANSWER!
<dobey> heh
<pitti> (kicked the right one)
<dpm> hallyn, ok, then I'll give libpam-cgfs another go and double-check sure I've got -c freezer removed
<dpm> hallyn, so with libpam-cgfs installed, having removed '-c freezer', still same result: apps won't start
<dpm> hallyn, installed libpam-c* packages -> http://pastebin.ubuntu.com/14870814
<dpm> and contents of /etc/pam.d/common-session -> http://pastebin.ubuntu.com/14870817
<juliank> Laney: Is it listed in the Release file?
<juliank> No entry there, no fetching
 * juliank is a little bit slow right now with writing as he just cut into his right thumb
<hallyn> dpm: ok, so let's try restarting cgmanager with --debug as i described above, and change the pam.d/common-session line from pam_cgfs to pam_cgm
<juliank> Hmm, it seems to be listed
<hallyn> dpm: that way we can see whether any requests are being made of pam
<Laney> juliank: Yeah, http://archive.ubuntu.com/ubuntu/dists/xenial/Release
<juliank> Laney: But only the compressed dep11 files are listed in the xenial Release file, APT probably needs the uncompressed  ones as well
<dpm> hallyn, would you mind re-pasting the cmanager restart command? I'm on my laptop now and don't have the scrollback
<Laney> o rly?
<hallyn> dpm: 'sudo systemctl stop cgmanager;  sudo cgmanager -m name=systemd --debug'
<Laney> juliank: actually I don't even - Debian lists them in there but they don't exist?
<juliank> Laney: Sure uncompressed Contents and Packages files don't exist either.
<dpm> hallyn, and do I need to install libpam-cgm before changing the common-session file?
<dpm> hallyn, it seems at least I need to install the 'cmanager' package to get the cmanager command
<hallyn> dpm: i thought you said you had libpam-cgm installed
<hallyn> yes.  so install cgmanager and libpam-cgm i guess
<hallyn> actually maybe it would have been easier to strace -f -p pid-of-launcher (upstart?) and look at that strace
<dpm> hallyn, no, I had -cgfs installed, IIRC (see pastebin above)
<hallyn> i was looking at http://pastebin.ubuntu.com/14870814/
<hallyn> but no matter - actually can you do the strace first instead?  it may tell us what we need
<Laney> juliank: ok, so Launchpad should be generating this?
<hallyn> dpm: that's assuming you know which task fires off the app, which ia ssume you do.  (upstart user session?)
<juliank> Laney: I think so, yes
<Laney> cjwatson: ^- apparently you need to list the files uncompressed too
<hallyn> back in 5
<Laney> cf Packages
<dpm> hallyn, right, on http://pastebin.ubuntu.com/14870814 I've got -cgfs installed (just making sure I've got the right one)
<dpm> hallyn, I've no clue which task fires the app, no
 * juliank would also list checksum for uncompressed Contents files while at it
<dpm> hallyn, nm, I need to run, thanks for the help and let's continue tomorrow
<hallyn> d'oh.  who would know...
<lpotter> wish I could edit comments in launchpad
<cjwatson> Laney: Ah, I wondered, but wanted to see whether it was needed
<cjwatson> Laney: I came up with a plan for that, so I'll put that into practice later
<cjwatson> juliank: that's a little more effort for reasons, but will see what I can do
<cjwatson> I guess if I need it for Contents as well then maybe I should deal with it in the publisher itself rather than hacking around it in ubuntu-archive-publishing scripts as I'd initially planned
<juliank> cjwatson: It will be needed for Contents for apt-file 3.0 to work
<juliank> I suppose it's possible to hack around things by including .gz in the APT configuration and removing the setting to keep files compressed, but that's somewhat ugly.
<juliank> That is, in the files shipped by appstream and apt-file 3
 * juliank is afk for 45 minutes
<cjwatson> juliank: Yeah, historically we've hacked around it in a fairly ugly way for Packages (we generate uncompressed Packages and then remove them in postprocessing) but that isn't done for Contents and I think it's time to fix it in a more graceful way
<cjwatson> bah, timing
<mwhudson> infinity: ping
<mterry> robert_ancell, hello!
<mterry> robert_ancell, limba looks kinda nuts is all
<robert_ancell> mterry, hi!
<robert_ancell> mterry, yeah, thought that might be a little like that. Just say no in the MIR and we'll take it as a packaging issue.
<mterry> robert_ancell, well I'm expecting security to say no.  But that no might take a while to get to you, they're quite busy
<robert_ancell> mterry, thanks for the review
<mterry> robert_ancell, I can review the packaging to try to find an early reason to say no  :)
<mterry> robert_ancell, or maybe just patch it out for now and if they come back and say it's fine after all, add it back
<robert_ancell> mterry, yeah
<robert_ancell> mterry, there's plenty of other MIRs that need doing first
<mterry> truth
<mterry> robert_ancell, I'd never heard of limba.  Is it popular?
<robert_ancell> mterry, no, it's new
<mterry> robert_ancell, is packagekit 1.0 being packaged shortly?
<robert_ancell> mterry, we're having issues tracking down all the loose ends. We may have to drop PK1.0 and work around it.
<robert_ancell> mterry, it is packaged in the sense that the Debian version is what we'd use
<mterry> robert_ancell, gotcha
<cjwatson> maybe I'm going to have to take a day and sort out the click native-dbus branch, since apparently nobody else is
<cjwatson> (re pk 1.0)
<robert_ancell> cjwatson, wasn't it decided to drop PK support? (but fixing is better obviously)
<cjwatson> robert_ancell: err
<cjwatson> robert_ancell: the way to drop PK support is to land the native-dbus branch
<cjwatson> robert_ancell: that's the point of it
<cjwatson> robert_ancell: can't just drop it otherwise since click currently entirely relies on it
<robert_ancell> cjwatson, oh ok
<mwhudson> has something changed in xenial in the last few days that means it's now required to add -lpthread to a link?
<sarnold> did one of the libraries you require suddenly add pthread support?
<mwhudson> sarnold: i guess i should check
<mwhudson> liblxc maybe?
<jtaylor> -lpthread should never be required
<jtaylor> -pthread maybe
<mwhudson> huh the package versions for the successful and failed builds are the same
<mwhudson> wtf is going on
<mwhudson> failed: https://launchpadlibrarian.net/235984198/buildlog_ubuntu-xenial-amd64.lxd_2.0.0~beta1-0ubuntu6_BUILDING.txt.gz
<mwhudson> succeeded: https://launchpadlibrarian.net/235963097/buildlog_ubuntu-xenial-amd64.lxd_2.0.0~beta1-0ubuntu5_BUILDING.txt.gz
 * mwhudson aft
<mwhudson> ohh i know what the difference is
<mwhudson> i don't know why it's a problem, but i expect that's easier to figure out
#ubuntu-devel 2016-02-04
<pitti> Good morning
<Pharaoh_Atem> rbasak: ping
<rbasak> Pharaoh_Atem: pong
<Pharaoh_Atem> rbasak: so I'm trying to update the dep8 tests to be "unversioned"
<pitti> utlemming: recent cloud images don't boot any more (i. e. ssh never comes online), apparently they dropped the ifnames=0 but still don't create a matching interfaces? known?
<Pharaoh_Atem> but I'm not sure how to make it so that the files in tests/ are read and rewritten before being used to run tests
<Pharaoh_Atem> rbasak: if you don't remember, this is for php7.0
<rbasak> Pharaoh_Atem: I'm not sure I follow your question.
 * rbasak looks up the email about this.
<Pharaoh_Atem> I'm not sure I follow what ondrej is asking me to do, so I'm probably doing a terrible job asking
<rbasak> I don't think what he's asking will work. Let me see if I can understand what he wants.
<Pharaoh_Atem> rbasak: I spent the better part of the week trying to do what he asked
<Pharaoh_Atem> things blow up
<Pharaoh_Atem> a lot
<Pharaoh_Atem> maybe I just suck at Debian packaging :/
 * Pharaoh_Atem has @_@ status after all of this
<Pharaoh_Atem> if this worked like how RPM'
<Pharaoh_Atem> how RPM's %check section worked, then sure, I can see this working like he wants
 * mgedmin discovers that when unattended-upgrades causes a reboot, all other cron.daily scripts are skipped that day
<Pharaoh_Atem> mgedmin: isn't that fun?
<Pharaoh_Atem> I've actually caused people to yell at me about that
<Pharaoh_Atem> because apparently no one expects that
<mgedmin> maybe I should report a bug
<Pharaoh_Atem> rbasak: but RPM's %check section would also not satisfy the kind of tests this pulls off
<Pharaoh_Atem> as what we're really doing is spinning up instances and configuring things and stuff
<Pharaoh_Atem> this stuff is weird, and I'm not sure the tests will work like we want it to in an "unversioned" state
<rbasak> mgedmin: please do!
<rbasak> Pharaoh_Atem: I replied to Ondrej's email. I think it'd be better for the test to dynamically discover the package version using dpkg-parsechangelog, or for the package to provide some shell (not make) infrastructure to extract the right strings.
<Pharaoh_Atem> rbasak: so... does dpkg-parsechangelog have an option to strip the release version from the field?
<Pharaoh_Atem> it doesnt' seem like there is
<Pharaoh_Atem> *doesn't
<ginggs> morning pitti!  on update_excuses, suitesparse still lists julia 0.4.2-3, does something need to happen fo this to change to 0.4.3-1build1 ?
<pitti> ginggs: yes, we need to bump the hint
<dholbach> good morning
 * mgedmin files https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1541730
<ubottu> Launchpad bug 1541730 in unattended-upgrades (Ubuntu) "all cron.daily scripts are skipped on a day when unattended-upgrades triggers a reboot" [Undecided,New]
<pitti> ginggs: done
<Pharaoh_Atem> rbasak: actually, I'm not exactly sure how to use dpkg-parsechangelog to do this
<Pharaoh_Atem> from looking at the man page, it seems to indicate that it just spews the whole Package header
<rbasak> Pharaoh_Atem: -S maybe?
<Pharaoh_Atem> ah, yes, I see it
<rbasak> Pharaoh_Atem: also probably some cut or awk or sed may be necessary
<Pharaoh_Atem> yeah
<Pharaoh_Atem> I can be reasonably certain that the first dash is the cutoff point
<Pharaoh_Atem> unless there's more package name-version contorting that I don't know about that's allowed?
<rbasak> Technically it's the final dash IIRC, but that won't matter unless upstream happen to use a dash.
<ginggs> pitti: danke
<rbasak> I wouldn't worry about it if it's awkward.
<rbasak> There might be some tooling that I don't know about that might help here.
 * Pharaoh_Atem misses having a separate Version and Release field
 * Pharaoh_Atem pokes more dpkg manpages
<Pharaoh_Atem> hmm, doesn't look like the dpkg-dev toolsuite has anything
<mwhudson> Pharaoh_Atem: i find this sort of thing to be least horrible in perl, of all things
<rbasak> Pharaoh_Atem: see /usr/share/dpkg/pkg-info.mk
<rbasak> It has the right shell snippets
<Pharaoh_Atem> you know things are bad when you resort to perl as the least horrible option :/
<Pharaoh_Atem> rbasak: looks like DEB_VERSION_UPSTREAM is what I want, ne?
<Pharaoh_Atem> rbasak: are these variables available inside the test environment, or should I just copypasta them into the tests?
<rbasak> Pharaoh_Atem: I would copy and paste them. Ugly, but I'm not sure of any better way.
<Pharaoh_Atem> yeah, that's what I think
<rbasak> dpkg-parsechangelog and version strings are very well defined. So as long as the code is correct, it shouldn't ever change under our feet.
<rbasak> Of course having the code in one place is good for bug fixes too.
<rbasak> Though hopefully if it does wrong our tests will fail.
<rbasak> rharper: while I remember, it might be worth checking with bdmurray that phased updates won't be impacted by the network-manager/libnl3 breaks SRU thing.
<rharper> rbasak: yes, thanks!
<rbasak> bdmurray: a newer libnl3 in trusty-proposed breaks network-manager in the release pocket due to a latent bug, for which we have a fix also for network-manager in trusty-proposed.
<rbasak> We will have a newer libnl3 with breaks: network-manager (...) soon.
<rbasak> Users need to not phase libnl3 before network-manager.
<rbasak> Just want to check that the phasing will not be thrown by the breaks.
<Pharaoh_Atem> rbasak: when the tests are running, do they have access to the changelog file that's above the tests/ folder?
<rbasak> Pharaoh_Atem: yes. Tests are defined to have a $PWD of the top of the source tree.
<rbasak> http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst is the spec
<Pharaoh_Atem> so $PWD/debian/changelog is a valid path in tests?
<pitti> https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html is the formatted variant for nicer reading
<Pharaoh_Atem> hmm
<Pharaoh_Atem> rbasak: oh crap, I just realized, this has to be rewritten into shell script
<Pharaoh_Atem> I don't even know what some of this even DOES
<Pharaoh_Atem> http://fpaste.org/318293/45457554/
<Pharaoh_Atem> hmm
<Pharaoh_Atem> maybe I can make this work
<Pharaoh_Atem> rbasak: uhoh
<Pharaoh_Atem> I can't update the control file reliably
<Pharaoh_Atem> rbasak: I'm going to take a wild guess and say that control files are not shell scripts, nor can they be rewritten like this
<rbasak> Pharaoh_Atem: ah, right. Yes - the control file will need to be version-agnostic. Is that possible?
<Pharaoh_Atem> not with the way Debian is determined to package this
<Pharaoh_Atem> each and every package name has the PHP version embedded in it
<Pharaoh_Atem> consequently, my deps are versioned in the control file
<Pharaoh_Atem> so... I'm screwed
<Pharaoh_Atem> if it was just the php major version like before, it would be workable
<Pharaoh_Atem> but it's the major plus the minor version now
<Pharaoh_Atem> rbasak: I'm not sure it's even possible to do this
<Pharaoh_Atem> unless the packages all have virtual Provides to major version only, I can't really do this
<Pharaoh_Atem> but if they have that Provides, things get really screwy once there's more than one PHP stack installed
<Pharaoh_Atem> that has the same major version
<Pharaoh_Atem> actually, come to think of it, it would already be quite unpredictable with correctly handling it if neither were installed anyway
<Pharaoh_Atem> rbasak: yeah, I don't know how to make these tests work the way ondrej wants them to
<cpaelzer_> I'm looking for some advise on packaging debian/*README* files. I have a source package building various binary packages.
<cpaelzer_> and the Readme covers a lot of cross package things, so it is not really applicable to split it into debian/packagename.README.debian
<cpaelzer_> but on the other hand I want the information available for the user, no matter what package he installs
<cpaelzer_> it is a bit controversial, ideas that we could come up so far are all unsatifying - e.g. like linking all debian/packagename.README.debians to just one file
<cpaelzer_> that would provide the info whatever the user installs, but it doesn't feel right
<pitti> utlemming: I filed bug 1541757 with details, not sure if that's the right project
<ubottu> Error: Launchpad bug 1541757 could not be found
<pitti> (it's private)
<cpaelzer_> on the other hand making the one package that brings this information a dependency just for the README file is even worse
<cpaelzer_> however and hint is welcome if there is something else that would apply
<Pharaoh_Atem> rbasak: I'm clearly too tired to be useful now
<Pharaoh_Atem> I just mail-bombed you with my stupidity today :/
<cpaelzer_> I might just bind it to the -doc package and be done with, probably cleaner than everything else we came up so far
<Pharaoh_Atem> rbasak: I think I've about bought the farm today, so I'm going to go to sleep for a few hours
<rbasak> Pharaoh_Atem: OK, no problem. Thank you for this work! I think we'll need to see what Ondrej thinks about your latest patch.
<Pharaoh_Atem> I've not submitted a patch for the tests, because I don't really know how I'm going to make this work
<rbasak> Oh, OK.
<Pharaoh_Atem> but the two patches I sent in (after fixing the author field) basically fix php-cgi.conf and add php-fpm.conf
<rbasak> I'm a bit tied up this week but we can look together on it soon.
<Pharaoh_Atem> I hope so
<Pharaoh_Atem> we're inching really close to that Feb 18 drop dead date
<Pharaoh_Atem> rbasak: I'm thinking that we're most likely going to have to give up on the idea of a versionless set of tests
<Pharaoh_Atem> it's getting messy to figure out how it would work correctly
<Pharaoh_Atem> the php-fpm config file patch would be needed anyway
<Pharaoh_Atem> since I'm adding a php-fpm test
<Pharaoh_Atem> anyway, ttyl
<LocutusOfBorg> hi Logan can you please merge cinnamon? :)
<LocutusOfBorg> or alternatively, can I steal your merge?
<LocutusOfBorg> pitti, ^^^ you are the last uploader (even if a no change rebuild shouldn't count as real upload to me :p )
<pitti> LocutusOfBorg: please steal, thank you!
<pitti> the whole Borg collective doing merges, awesome!
<LocutusOfBorg> :D
<LocutusOfBorg> are you aware of the package src:borgbackup?
<pitti> "You will be merged. Delta is futile."
<LocutusOfBorg> I'm maintaining it just for fun :D
<LocutusOfBorg> loool
<pitti> LocutusOfBorg: I suppose it uploads your entire HD into the hive^Wcloud ?
<LocutusOfBorg> yes, but only in the alpha quadrant
<LocutusOfBorg> :)
<pitti> LocutusOfBorg: what? they are in the Delta quadrant
<pitti> what if a fire breaks out in Alpha and kills all backups?
<LocutusOfBorg> true, but they were in alpha too :)
<cjwatson> pitti: so, I gather that I can retry autopkgtests in silos, but I'm not sure of the exact invocation.  Could you clue me in?
<pitti> cjwatson: it's essentially the same, but with adding the two --ppa args; e. g.
<pitti> run-autopkgtest -s xenial -a armhf --ppa ci-train-ppa-service/stable-phone-overlay --ppa ci-train-ppa-service/landing-042 --trigger pay-service/15.10+16.04.20160114-0ubuntu1 unity-scope-click
<cjwatson> ah, good, that was my guess
<cjwatson> but wanted to check
<pitti> cjwatson: clicky-clicky implementation is being worked on
<cjwatson> pitti: thanks
<pitti> this mostly needs verifying the PPA args, packages in those, etc.
<mterry> doko, oh huh, clang doesn't use the new ABI?  I guess that makes sense but hadn't thought about it.  Do they have plans for that?
<doko> mterry, yes, but afaik it's not yet implemented
<doko> mterry, we promoted llvm when clang was built from a separate source. so nobody looked yet at promoting clang
<mterry> doko, makes sense
<cyphermox> good morning
 * mterry waves at cyphermox
<seb128> hey mterry cyphermox
<alexabreu> pitti, ping
<pitti> alexabreu: hello
<alexabreu> pitti, hi, do you think you could retry britney for silo 16? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html
<pitti> alexabreu: kicked
<alexabreu> pitti, thx !
<pitti> cd
<tjaalton> update_excuses still thinks ikiwiki-hosting and libalien-wxwidgets-perl tests are blocking llvm-3.8
<tjaalton> doko: libclc builds with llvm-3.8 btw
<ginggs> pitti, what else is needed for suitesparse to migrate - ignore the julia i386 regression?
<pitti> ginggs: ah, I bumped julia, but this ran against the previous version; I'll re-add the hint
<pitti> ginggs: but this had been a valid candidate for a long time, and it caused uninstallability
<pitti> i. e. some transition still needed
<pitti> ginggs: next cycle will have suitesparse as valid candidate again, and you can see it in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt again -- this tells you which other packages become uninstallable with that
<ginggs> pitti: ok, will look
<doko> ginggs, pitti: I assume this is all stuck in the openmpi/netcdf transitions
<doko> tjaalton, sure 3.8 is better than 3.7, but the point is that we should use exactly one system compiler
<ginggs> surprise openmpi transition... btw doko, is this needed? debian bug #813494
<ubottu> Debian bug 813494 in mpi-default-dev "mpi-default-dev: Please depend on openmpi (>= 1.10.2 -3 )" [Important,Open] http://bugs.debian.org/813494
<tjaalton> doko: understood, I'll try with g++
<doko> ginggs, makes sense
<tjaalton> doko: nope, needs llvm-config, and readme has "libclc is intended to be used with the Clang compiler's OpenCL frontend"
<tjaalton> doko: oh I read your comment now.. didn't we settle on 3.8 to be the new default?
<tjaalton> now that it's available mesa can move to it
<doko> tjaalton, read backlog, it's still in -proposed
<tjaalton> doko: I know, but once it's out :)
<tjaalton> uh, and the comment was from mterry not you, damn :)
<tjaalton> doko: ok now I see the clang problem, I thought 3.8 would support the libstdc++ abi.. so mesa can use 3.8 once it's out of proposed, but doesn't have to enable opencl yet
<doko> sil2100, you merged ocaml, but didn't follow-up with the ocaml transition
<sil2100> doko: when?
<sil2100> doko: last time I touched ocaml was during xenial beginnings when I was doing the ocaml transition
<sil2100> I didn't merge it recently, at least I don't recall doing that
<doko> sil2100, I know ...
<pitti> slangasek: /usr/lib/tmpfiles.d/{legacy,x11}.conf have some examples, like 'r! /fastboot'
<pitti> slangasek: the '!' means to only run that at boot, not when you restart/upgrade things (see tmpfiles.d(5))
<doko> who speaks ocaml? https://launchpad.net/ubuntu/+source/coq-float/1:8.4-5build2/+build/8964835
<ackk> hi, I'm trying to configure APT methods (the http one specifically) to skip proxy config for a certain domain, I'm trying with "Acquire::https:Proxy::<domain>=DIRECT", but it doesn't seem to work. am I doing something wrong?
<cjwatson> ackk: missing colon
<cjwatson> ::Proxy not :Proxy
<ackk> cjwatson, argh, I read that line a thousand times and didn't notice :/
<ackk> cjwatson, thanks :)
<cjwatson> also you said http in one place there and https in another
<ackk> cjwatson, yeah I actually have that config for both
<xnox> pitti, could you retrigger node-websocket-driver with nodejs 4.2.6~dfsg-1ubuntu4 as trigger on ppc64el?
<xnox> it's a tmpfail.
<xnox> somehow ppc64el failed / got stuck a bit on nodejs tests....
<pitti> xnox: done
<caribou> slangasek: regarding mstflint (which is in Universe btw) - would the mstflint-4 (from Xenial) be considered a new package ?
<slangasek> caribou: yes
<caribou> slangasek: so how does that happen in a stable release ?
<caribou> or can it ?
<slangasek> caribou: same as elsewhere, it just requires you to actively prod the SRU team about letting it in
<bdmurray> seb128: I'm fairly certain those retrace failures you mentioned the other day are due to needing a new version of gdb on the retracers.
<xnox> caribou, same way lts-yname-backport stacks happen. It land in new queue for -proposed, but then migrates to -updates. We totally have brand new source and binary packages in -updates =)
<seb128> bdmurray, ah, nice finding ... can you get it updated?
<bdmurray> seb128: its building in a PPA now, then need to submit RT etc...
<seb128> thanks
<seb128> is there anything we can do to see when that happens next time?
<seb128> like do we have stat of numbers of retraces that fail to give useful stacktraces?
<bdmurray> seb128: the fix for bug 1517257 should avoid the issue
<ubottu> bug 1517257 in apport (Ubuntu) "apport-retrace should install and use gdb for target release" [Medium,Triaged] https://launchpad.net/bugs/1517257
<seb128> great
<doko> tjaalton, is the libclc MIR really needed until clang gets the compatibility with the new libstdc++ ABI?
<xnox> pitti, hm. the nodejs re-trigger didn't work, has it? is there a way to retrigger harder? I guess the proposed migration output should have retry buttons for test in progress things too? or like for tmpfail stuff.
<xnox> pitti, or just hint it? i'm sure that single node package on a single arch is fine. I can't wait to have nodejs available on s390x =)
<tjaalton> doko: it was needed for opencl support in mesa
<tjaalton> the clang compat requirement was new to me
<doko> tjaalton, does mesa work with opencl?
<tjaalton> doko: debian has it
<tjaalton> since ~2y ago
<tjaalton> (mesa-opencl-icd)
<pitti> xnox: oh -- I triggered node-leveldown, not node-websocket-driver, sorry
<pitti> poked
<highvoltage> 0/win 15
<cjwatson> Laney,juliank: all right, I spent all day on https://code.launchpad.net/~cjwatson/launchpad/uncompressed-indexes/+merge/285109 - once that's reviewed/merged/deployed, both DEP-11 and Contents should work properly
<cjwatson> also makes xz indexes a bit easier to arrange for in the near future
<juliank> cjwatson: Wonderful
<pitti> Mirv, alex-abreu, cjwatson: FYI, https://requests.ci-train.staging.ubuntu.com/static/britney/xenial/landing-021/excuses.html â silo excuses now have retry links
<pitti> (production will update in a bit)
<alex-abreu> pitti, awesome ! no more bothering you :)
<pitti> clicked on the i386 regression, queued on http://autopkgtest.ubuntu.com/running.shtml#pkg-qtcreator-plugin-ubuntu
<alex-abreu> pitti, they only appear on *new* britney results
<pitti> alex-abreu: the pages will all be regenerated, give it another 30 minns
<alex-abreu> pitti, great thx
<mwhudson> infinity: ping
<infinity> mwhudson: gnop
<mwhudson> infinity: have you had the chance to form an opinion on https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1536882 yet?
<ubottu> Launchpad bug 1536882 in golang (Ubuntu) "upload golang1.5 package for trusty" [Undecided,New]
<infinity> mwhudson: I've been decidedly opinion-free this week, trying (somewhat unsuccessfully) to avoid too much multitasking.
<mwhudson> infinity: fair enough, can i schedule an opinion-forming slot?
<mwhudson> infinity: it's not urgent, exactly, but at the same time i don't want it to sit there forever
<mwhudson> and i asked slangasek who to bug and he said you :-)
<infinity> Heh.
<infinity> mwhudson: Maybe put something on my calendar for next week?
<infinity> mwhudson: And we can actually have a chat about it.
<mwhudson> infinity: done, feel free to move it around
<mwhudson> although not too much earlier in the day pls
<slangasek> y
<cjwatson> pitti: excellent
<infinity> mwhudson: My brain doesn't wake up until mid-afternoon, "earlier" isn't in my scheduling vocabulary.
<mwhudson> infinity: execellent
<pitti> cjwatson: oh, thanks for beating me to updating lupin (I have a half-written update here, but wanted to wait until systemd landed)
<pitti> cjwatson: this isn't systemd specific FYI, it was done 4 years ago in Debian already (between sysvinit and util-linux)
<pitti> cjwatson: but I thought we also need to consider the case if /etc/adjtime does not exist at all only has one or two lnies
<pitti> lines
<pitti> (that's the "half-written" part, too tired to figure this out today properly)
 * pitti waves good night .. morning already, actually
#ubuntu-devel 2016-02-05
<cjwatson> pitti: Well, I was pretty sure it would be fine to sync it with clock-setup, where that code came from in the first place anyway
<xnox> pitti, tah.
<xnox> mwhudson, infinity src:golang-1.5 =)
<Mirv> pitti: \o/
<Mirv> that was very fast feature bring up
<xnox> pitti, cpr is needed for ppc64el on autopkgtest. Queues are piling up, and none are running.
<xnox> pitti, oh, they seem to be back alive
<pitti> Good morning
<pitti> xnox: yep, looking; utlemming fixed the ppc64el images yesterday, but apparently that didn't make it into yesterday's
<pitti> xnox: at 0600 UTC the janitor cronjob runs which cleans up orphaned instances and restarts stuff, but it can't fix the reason for the ssh timeouts
 * pitti prods the armhf runners too
<xnox> fun =/
<pitti> there is some lxcfs lockup on armhf
<pitti> utlemming: hm, apparently something changed in the underlying environment -- I can't boot wily ppc64el images any more either :/
<pitti> utlemming: can you please trigger new ones for wily, vivid, and trusty too?
<pitti> utlemming: with yesterday's live-build fix, I mean
<pitti> utlemming: hm, actually, console-log doesn't show me *any* detected network card, so maybe that's unrelated
<pitti> PSA: disabling autopkgtesting on ppc64el, this is just broken
<pitti> Laney, wgrant, infinity ^ FYI -- collecting logs and filing RT
<pitti> apw: ^ affects your kernel tests, too
<rbasak> rharper: for Debian bug/patch submissions from your Ubuntu hat, please use https://wiki.ubuntu.com/Debian/Usertagging - it helps when people complain that we don't contribute to Debian.
<rharper> rbasak: thanks
<dholbach> good morning
<pitti> utlemming: ok, unping -- eth0 exists, but it doesn't get a DHCP address, this is an IS problem
<roaksoax-brb> pitti: howdy! I'm seeing stuff like "maas-proxy.service is a disabled or a static unit, not starting it." all over for things that used to work last week.. any ideas why? my debian/rules: http://pastebin.ubuntu.com/14886037/
<pitti> roaksoax-brb: no [Install] section?
 * pitti needs to leave for doctor appointment, back in ~ 1 h
<doko> mitya57, building metacity I see:
<doko> dh_autoreconf
<doko> m4/glib-gettext.m4:39: error: m4_copy: won't overwrite defined macro: glib_DEFUN
<doko> m4/glib-gettext.m4:39: the top level
<doko> Laney, ^^^
<Laney> doko: m4/, sounds like a toolchain problem :) :) :) :)
<doko> Laney, sure, it's called glib ;-P
<Laney> doko: I think you can delete that file since aclocal should get the system one
<Laney> it must be doing some kind of deduplication and that breaks since glib changed /u/s/aclocal/glib-gettext.m4 in a recent release
<Laney> previously m4/glib-gettext.m4 and the system one would have been identical
<Laney> you can copy one to the other to confirm this
<doko> that works
<Laney> see, toolchain problem!
<doko> starts with g* ...
<Laney> the macro was always defined twice
<Laney> aclocal was hiding this from us before
<Laney> happy fix anyway
<Laney> cjwatson: good work
<Mirv> pitti: otherwise going fine, but interestingly https://autopkgtest.ubuntu.com/retry.cgi?release=xenial&arch=amd64&package=qtcreator-plugin-ubuntu&trigger=qtdeclarative-opensource-src-gles%2F5.5.1-2ubuntu4&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-023 says "You are not allowed to upload qtcreator-plugin-ubuntu or qtdeclarative-opensource-src-gles to Ubuntu, thus y
<Mirv> ou are not allowed to use this service." even those are both universe packages and I'm a MOTU
<Mirv> pitti: I was able to retry the same qtcreator-plugin-ubuntu tests under the non-gles qtdeclarative-opensource-src though
<xnox> cjwatson, i'm trying to figure out where and how built-using should be processed in germinate... It's a relationship declared on binary packages, but the values are source packages. I'm pondering if those sources' binaries should end up in extra.
<xnox> e.g. store them somewhere, and if binaries from those sources did not end up anywhere, add them into extra.
<xnox> or some such.
<pitti> Mirv: can you please file a bug against auto-package-testing? No off-hand idea right now, I'm afraid
<Mirv> pitti: ok, I was just filing a bug against bileto so there it is, bug #1542239.
<ubottu> bug 1542239 in Bileto "Unable to run some retries" [Undecided,New] https://launchpad.net/bugs/1542239
<roaksoax-brb> pitti: this is my debian/rules http://paste.ubuntu.com/14886246/ I'm definitely missing something then
<pitti> roaksoax-brb: what's the output of "systemctl status maas-proxy.service"?
<pitti> roaksoax-brb: but I suspect these overrides are wrong -- can you just drop them? dh_systemd_* should already enable all units in that package, and --name doesn't exist as an option AFAIK
<pitti> roaksoax-brb: sorry, --name does exist for dh_systemd_enable
<wgrant> pitti: ppc64el vbuilders are still working fine, so I guess the neutron2 dnsmasqs, or possibly just your dnsmasq, is/are dead.
<wgrant> We've been seeing some related issues on vbuilders over the past two weeks, but they only hit the occasional boot.
<pitti> wgrant: for me, I sometimes get bursts of failure mails where all of them failed, then it works again for half a day, etc.
<pitti> right now it's again not working at all
<xnox> cjwatson, failing to grasp what "build_tree" flag is
<xnox> too
<xnox> =(
<mitya57> doko, Laney, so what should I do in metacity? dh_clean that file?
<Laney> mitya57: I guess, not that sure why it is in m4/
<Laney> aclocal --install I guess
<Laney> this is annoying
<doko> mitya57, for now, I just updated it
<cjwatson> xnox: build_tree basically means that germinate is processing something that it got to via a Build-Depends
<mitya57> doko, I see, thanks
<Laney> mitya57: updating it is a bad idea for unstable atm, since it only changed in exp
<xnox> cjwatson, aha. right, i see that in adding all the things read from e.g. Build-Depends-Indep et.al.
<cjwatson> xnox: Built-Using presumably wants to be specifically not build_tree though, otherwise what's the point, it wouldn't change anything
<xnox> i'm now wondering, if i should add all sources, as if it was the source package of a given binary. Or, like, find intersction of binaries(produced by Built-Using sources) && binaries(build-depends)
<xnox> and then seed those binaries.
<cjwatson> I feel like adding all binaries would probably cause a bit too much explosion
<cjwatson> But getting the intersection is going to be really really really hard
<xnox> yeah.
<cjwatson> Because it might be transitive
<xnox> especially thanks to transitive build-deps.
<xnox> you type faster =)
<xnox> #not fair
<mitya57> Laney, I hope new release will use upstream gettext, so there won't be m4/glib-gettext.m4 in tarball at all
<xnox> cjwatson, i shall study existing built-using for a bit.
<cjwatson> xnox: Maybe we just need to make sure it's annotated somewhere in germinate's output and then people can manually hike those up to seeds :-/
<xnox> cjwatson, given my vision for the new world order. I would have them show up in components missmatches, as source-only promotion to main, with .dot graphs indicating that these are built-using src packages.
<xnox> cjwatson, and that way e.g. security team would know -> it's in main, source only -> it must be the crazy statically linked in thing into _everywhere_
<pa> hello
<cjwatson> xnox: mm, causing Built-Using to include just the source but no binaries is probably quite a good way to handle this in germinate, indeed
<cjwatson> (well, no binaries unless something else includes them, of course)
<xnox> yeah. and transitive build-deps are not broken, because new-world-order.
<pa> are you guys still supporting the decision of having a windows7 alike ctrl-tab on ubuntu touch?
<xnox> pa, most people here have no idea about windows7, nor ctrl-tab =) and i think touch development is done in another channel, like #ubuntu-touch (?!) i can't recall.
<cjwatson> xnox: well, even then, Built-Using is roughly always a subset of Build-Depends
<pa> ok i try to ask there
<xnox> pa, do you have screenshots on the internet of this ctrl-tab thing?
<pa> i understand that in ubuntu desktop you already have plenty of problems ;)
<pa> yes i can find
<pa> sec
<pa> xnox, this counterproductive thing: http://i1-news.softpedia-static.com/images/news2/Ubuntu-Touch-RTM-Update-10-Important-Milestone-Achieved-Screenshot-Tour-466165-8.jpg
<mitya57> On phones it's not ctrl-tab, but rather some gesture (I guess) :)
<pa> yes
<pa> but on win7 it is :)
<xnox> pa, i totally misunderstood your question, i thought you were asking us to include something like that.
<pa> no i actually hope that to be dropped asap :)
<xnox> pa, anyway, such discussion is offtopic. And i think behaviour of those things is different on different form factors. I think on tablet/desktop things fly in expose mode, rather than in a carousel. Better ask in #ubuntu-touch.
<pa> i wish you guys won't end up like another firefoxOS :)
<pa> ok i tyr
<pa> try
<xnox> pa, this carousel design seems reasonabl-ish.
<pa> xnox, it
<pa> it's not just useless
<pa> it's counterproductive
<pa> a bloody simple matrix is 10.000 times better
<xnox> but it's *pretty* =)
<pa> yes it seems pretty when you arent using it
<xnox> i use terminal, emacs in the terminal and a web-browser. I don't see myself having more than two windows like ever =0
<pa> well on a phone you might have multiple apps open at the same time
<pa> in particular because the app launch time on ubuntu phones is not small
<pa> like text app, mail app, calendar, browser, etc.
<pa> but i'll ask there
<xnox> pa, i don't use, have or develop ubuntu touch UX / UI at all. try #ubuntu-touch, it should have more people who are actually involved in that.
<xnox> people here are scewed towards core-platform development.
<rbasak> cjwatson: IIRC you once told me that in an Ubuntu merge Vcs-Browser should technically be changed to XSBC-Debian-Vcs or something, but I can't remember exactly what and my IRC log grep fails to find it. I've just received a merge request with this in the diff. Is there a normative thing that Ubuntu does here please?
 * rbasak found https://wiki.ubuntu.com/XS-Vcs but that doesn't have the answer.
<cjwatson> rbasak: that links to a thread which ends up at https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023379.html, i.e. XS-Debian-Vcs-*, which is what I've always done
<cjwatson> rbasak: I don't remember if that was written down elsewhere
<cjwatson> (XSBC- is silly because this doesn't belong in .deb control files or .changes, but XS- is reasonable)
<rbasak> That's great, thanks.
<roaksoax-brb> pitti: tmaas-proxy.service: unrecognized service , the weird thing though, is that the overrides were working last week
<marlinc> How 'breaking' would it be to run 16.04 as daily driver until its released as actual stable
<marlinc> I'll be using on a ZFS root so I can make snapshot to go back when something does go wrong
<marlinc> dasjoe, ^ how bad would you say it is?
<marlinc> I can just try it
<xnox> marlinc, well, you will always get to keep both pieces =)
<marlinc> Glueing them together would definitely work
<dasjoe> marlinc: I try to stay on LTS releases, so you'll be on your own. Also, as of 15.10 I still prefer dajhorn's PPA to the official packages provided by cking, as dajhorn's PPA is at 0.6.5.4 and I'm not sure the official packages support rpools
<marlinc> I've tried a rpool using the default packages in 16.04 on my USB. That appeared to work
<marlinc> Although I am unsure about GRUB2's ZFS feature flag support. I'm not sure if its in yet
<marlinc> Ah, yes. I was looking for https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1530457
<ubottu> Launchpad bug 1530457 in grub2 (Ubuntu) "grub2: cherry-pick support for ZFS pool feature flags, bugfixes" [High,Fix released]
<seb128> doko, http://launchpadlibrarian.net/236385287/libcmis_0.5.0-4ubuntu2_0.5.0-4ubuntu3.diff.gz ... did you forgot the actual change?
<seb128> the diff only has a changelog entry
<doko> seb128, it's a permission change
<seb128> oh ok
<seb128> misleading changelog text :-)
<marlinc> When's the feature freeze?
* marlinc changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<marlinc> Wut, woop
<seb128> marlinc, https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
* marlinc changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
<marlinc> Thanks!
<pitti> infinity, cjwatson: any known problem with teh ppc64el builders?  I got a weird "chroot problem" complaining about some invalid zlib stuff on  unpack, and now https://launchpadlibrarian.net/236387344/buildlog_ubuntu-xenial-ppc64el.mbr_1.1.11-5ubuntu1_BUILDING.txt.gz
<pitti> segfault during dpkg
<pitti> (retry worked)
<cjwatson> pitti: happens every now and again, incidence is low enough that it's tolerable
<pitti> cjwatson: ok; I got it three times in 15 minutes, so it felt like something broke
<cjwatson> pitti: can you see why qtcreator-plugin-ubuntu on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-046/excuses.html is sad?  it's installable in xenial
<smb> pitti, Speaking of odd things... have you ever had "TZ=UTC date" not print the date in UTC? Asking because somehow the Xenial image I seem to pull with adt-buildvm-ubuntu-cloud does exactly that and I think that causes the build-tests of libvirt which I try to run through adt to fail. Felling somewhat dumbfound.
<smb> (note that another Xenial VM which I manually installed works just like expected)
<menace> hi, how big's the chance, that kernel 4.5 comes to 16.04?
<jrwren> eventually, very likely ;]
<menace> i meant on release (16.04.0) :-D
<michael-vb> Hello.  Bad moment to ask, as I have to leave almost at once, but could someone take a look at this (development) question re unity-settings-daemon?
<michael-vb> https://answers.launchpad.net/unity-settings-daemon/+question/284461
<michael-vb> Thanks in advance.
<roaksoax> pitti: this is weird, postinst scripts do end up with: # Automatically added by dh_systemd_start -> which actually tells the service to start
<roaksoax> pitti: but maas-rackd.service is a disabled or a static unit, not starting it. -> still shown in install
<roaksoax> pitti: and the service ends ujp being stopped
<jrwren> menace: i don't know, but i'd guess not likely
<menace> jrwren: i hear that from several sources... but if one wants to support an ubuntu lts edition and has to write own externel (3rd party) kernel modules for that release, a little bite more reliability would be nice =) or even factors where i can recognize, if it gets more likely.... but okay then, thanks for your time.
<jrwren> menace: I don't see the issue. gl hf
<marlinc> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1542358
<ubottu> Launchpad bug 1542358 in grub2 (Ubuntu) "GRUB does not include ZFS modules in EFI partition" [Undecided,New]
<cjwatson> marlinc: ah yes, fair point, will fix
<cyphermox> cjwatson: there's another bug for this
<cyphermox> ok, maybe not quite the same thing
<cyphermox> cjwatson: do you have anything against applying the changes from Chad in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727 too?
<ubottu> Launchpad bug 1527727 in grub2 (Ubuntu) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,Confirmed]
<cjwatson> there's a different one about ZFS probing which will take a bit more thought
<cjwatson> I want to think about that patch :)
<cyphermox> yeah, that's really what I'm asking :)
<marlinc> Ah thanks for taking a look cjwatson :) Any idea what's causing it or what I can do to help?
<cjwatson> marlinc: just missing entries for those modules, I already committed a fix and uploaded to Debian
<marlinc> Very nice
<marlinc> I was told by someone that I had to test ZFS stuff on Xenial before feature freeze
<marlinc> I'm going all in by trying a rpool on Xenial
<marlinc> Can I follow it somewhere cjwatson?
<cjwatson> marlinc: follow what, sorry?
<marlinc> The Debian package, to see when it gets imported into Xenial for example
<cjwatson> marlinc: well it'll show up in xenial in a day or so, once everything gets processed and published and synced and built and published etc.
<marlinc> This is the first time I'm actually testing stuff for a new release so I've got no idea how those packages get handled between Debian and Ubuntu
<cjwatson> I'm not sure there's much that's desperately interesting to follow en route there :)
<marlinc> Okay :p
<marlinc> Is the patch available somewhere?
<cjwatson> but it's https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=a293f3b3349327b4e25f5e4998753f05aa7144c3, it'll show up on https://tracker.debian.org/pkg/grub2 in a little bit, then on https://launchpad.net/debian/+source/grub2, then eventually on https://launchpad.net/ubuntu/+source/grub2
<marlinc> Ah interesting, thanks!
<pete-woods> mdeslaur: hi. I've been looking at getting gnome-keyring running on the phone for password storage, but initially it crashed in some of the ARM asm inside libgcrypt
<pete-woods> and as the only canonical person I recognise on the changelog for that project, was hoping you'd take a look at my MR
<pete-woods> https://code.launchpad.net/~pete-woods/ubuntu/wily/libgcrypt20/disable-arm-asm-rijndael/+merge/284893
<pete-woods> which basically just disables the ARM assembler for AES
<pete-woods> after this change, gnome-keyring functions correctly
<pete-woods> I'm happy to revise the patch to follow patch conventions (as you can see from the MR message, I was initially unsure if this change would even help :) )
<mdeslaur> pete-woods: hrm, sure, one se
<pete-woods> thanks!
<mdeslaur> pete-woods: I think that makes sense, but please file a bug upstream about it
<mdeslaur> I don't see any further fixes in the git tree
<pete-woods> mdeslaur: okay, cool, will report the upstream bug
<marlinc> cjwatson_, do you know of a way to fix my grub image so that the workaround can be avoided?
<cjwatson> marlinc: since you're already running xenial, I don't think it's worth expending energy on thinking about workarounds
<cjwatson> marlinc: upgrade in a day or two instead :)
<marlinc> Okay :p
<smb> pitti, Ok, to answer my question about the weird date output in the adt test image... Something (not sure what and when) screwed up the zoneinfo, so /usr/share/zoneinfo/UTC pointed to something wrong. Forcing a reinstall of tzdata in the disk image fixes the problem.
<bdmurray> Does anybody know what the lxc error is here? http://pastebin.ubuntu.com/14888364/
<dannf> doko: did you have anything queued for a gccgo-4.9 trusty SRU? you cool w/ me uploading for LP: #1542080?
<ubottu> Launchpad bug 1542080 in gccgo-4.9 (Ubuntu Trusty) "Needs tar/xattr support to build docker" [Undecided,Triaged] https://launchpad.net/bugs/1542080
<dannf> doko_: ^
<doko_> dannf, sure, go ahead
<dannf> doko_: thx
<dasjoe> cking: cjwatson: Thanks again for your work on our favorite file systemâ¢! Now, let's get it into snappy ;)
<cking> were moving forward ;-)
<pete-woods> mdeslaur: FYI, here is the upstream bug report for the libgcrypt crash: https://bugs.gnupg.org/gnupg/issue2242
<pete-woods> okay, I gotta EOD and pick up kids
<pete-woods> thanks for your time!
<jtaylor> is util-linux a package one can safely backport?
<marlinc> Anyone running into issues with Rhythmbox and GStreamer? I'm getting the following error when trying to play a mp3 file. (21:21:14) [0x1dc1c40] [rb_shell_player_error] rb-shell-player.c:2443: playback error while playing: Problem occurred without error being set. This is a bug in Rhythmbox or GStreamer.
<marlinc> Playback does however work in the Videos app and in VLC
<marlinc> I've installed the codec as Video's asked for it
<marlinc> https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1542471
<ubottu> Launchpad bug 1542471 in gstreamer1.0 (Ubuntu) "Playing mp3 files causes: Problem occurred without error being set. This is a bug in Rhythmbox or GStreamer." [Undecided,New]
<marlinc> Interesting, when I now Google the issue I'm having with Rhythmbox I actually get my bug report as first result
#ubuntu-devel 2016-02-06
<lpotter> hate that.
<ginggs> hi - are there any reasons why i should not rebuild cmake against the new libjsoncpp?
<marlinc> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-352/+bug/1542629
<ubottu> Launchpad bug 1542629 in nvidia-graphics-drivers-352 (Ubuntu) "Session crashes when second monitor is connected" [Undecided,New]
<damascene> Hi, If I report a bug upstream and find that it's in Ubuntu too, should I report it on launchpad too?
<marlinc> Who are the people who get packages from Debian and put them in Ubuntu?
<marlinc> Is there a wiki page for that?
<cjwatson> marlinc: Ubuntu developers in general, though in the majority of cases it's automatic
<marlinc> Ah okay, because if this package https://launchpad.net/debian/+source/phpmyadmin/4:4.5.4.1-1 :)
<cjwatson> marlinc: We don't automatically sync from experimental
<marlinc> It fixes the following bug: https://bugs.launchpad.net/debian/+source/phpmyadmin/+bug/1542665
<ubottu> Launchpad bug 1542665 in phpseclib (Ubuntu) "phpseclib's Crypt/Random.php's file does not contain a class" [Undecided,New]
<cjwatson> marlinc: Usually Debian developers upload to experimental when they're not comfortable with it having a wide audience yet
<marlinc> Ah, that's something different then
<marlinc> That explains why I'm not getting the package in a Debian sid chroot
<cjwatson> I expect we'll get that once it hits unstable (assuming we aren't in import freeze by then)
<marlinc> I do hope it gets released before any of the Ubuntu freezes because the phpmyadmin package is completely broken at the moment
<marlinc> Thanks for the explanation cjwatson
<damascene> Hi, If I report a bug upstream and find that it's in Ubuntu too, should I report it on launchpad too?
<rbasak> damascene: if you want some action taken in Ubuntu or want to communicate with other affected Ubuntu users, then sure. Otherwise, no need, since any fix will get to Ubuntu eventually anyway.
<damascene> I see, do Ubuntu developers apply some patches to an older version of a package if the upstream did not make a patch for it?
<rbasak> For an existing Ubuntu stable release? To fix bugs, yes: https://wiki.ubuntu.com/StableReleaseUpdates
<rbasak> This assumes a patch is available of course.
<rbasak> (and thtat I've understood your question - you didn't provide any specifics)
<damascene> for example lxde-panel for RTL languages is broken, if the upstream make a fix they probably will not port it back to the version in 16.04
<damascene> this is one example
<rbasak> If no fix is available, then it can't be fixed by definition, unless someone makes a fix, at which point it might be a candidate for an SRU depending on the nature of the fix.
<damascene> thank for explaining it
<rbasak> No problem.
#ubuntu-devel 2016-02-07
<marlinc> cjwatson, awesome your fix ended up in Ubuntu and fixed the issue. Thanks a lot!
<cjwatson> marlinc: Great.
<lotuspsychje> hello guys, are there any known bugs for decrypt/encrypt not being able to decrypt anymore after a recent update?
<doko> xnox, please could you submit all involved object files in a bug report? https://launchpadlibrarian.net/236878588/buildlog_ubuntu-xenial-s390x.mopac7_1.15-6ubuntu1_BUILDING.txt.gz
<xnox> doko, ouch.
<xnox> doko, http://people.canonical.com/~xnox/mopac7-1.15.build-dir.tar.xz
#ubuntu-devel 2017-01-30
<nacc> doko: thanks, will work on it on monday
<cpaelzer> good morning!
<rbasak> o/
<cpaelzer> o/ rbasak
<dupondje> lets hope we quickly have a firefox update :P
<dupondje> seems its broken on all ubuntu's now :x
<rbasak> dupondje: is there a bug on this please?
<dupondje> https://bugs.launchpad.net/bugs/1659922
<ubottu> Launchpad bug 1659922 in firefox (Ubuntu) "Firefox 51.0.1 does not display pages/shows blank pages." [Critical,Triaged]
<dupondje> the fix is easy :)
<rbasak> dupondje: looks like this bug is a complete regression but only for users with an enforcing Firefox AppArmor profile. But this is not the default. Is this correct?
<rbasak> dupondje: what's the fix? I don't see one.
<rbasak> Ah, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239/comments/3 may be a reasonable fix.
<ubottu> Launchpad bug 1627239 in firefox (Ubuntu) "Web pages not rendering with e10s enabled and AppArmor profile in enforce mode" [High,Confirmed]
<dupondje> rbasak: well don't know whats the default apparmor status is ... :)
<rbasak> dupondje: AFAICT, Firefox ships with a non-enabled-by-default AppArmor profile. Users can enable it, but it restricts Firefox. The new Firefox does stuff that the AppArmor profile doesn't permit to the point of complete breakage.
<caribou> who's the resident expert on systemd nowadays ?
<caribou> I'd appreciate a second look at LP: #1654600
<ubottu> Launchpad bug 1654600 in unattended-upgrades (Ubuntu Xenial) "unattended-upgrade-shutdown hangs when /var is a separate filesystem" [High,Confirmed] https://launchpad.net/bugs/1654600
<seb128> caribou, not sure we have a "resident" one but you can try xnox or slangasek
<caribou> seb128: yeah, thought so
<infinity> caribou: Your analysis sounds reasonable.  systemctl list-dependencies will give you a tree that you might sort of be able to parse to understand what your changes do.
<infinity> caribou: Which is better than testing and being subject to "oh, I beat the race, I must have fixed the bug" logic.
<caribou> infinity: that was my worry, especially since the window where the lock might be taken can be quite short
<caribou> infinity: that and I'm not too found of a unit *starting* when we're shutting down but that's debatable
<infinity> caribou: It's a oneshot, starting or stopping amount to the same thing.
<infinity> caribou: (But it may be true that claiming Start or Stop might subtly change ordering)
<caribou> infinity: apparently not in that case as ExecStart will only be triggered after the Before= are shutdown
<caribou> infinity: anyway thanks for looking
<infinity> caribou: Though, ExecStop isn't even documented in systemd.unit... Did you make it up? :)
<caribou> infinity: documented in services
<infinity> Ahh, indeed.  Silly docs.
<infinity> caribou: Docs claim that ExecStop won't run at all unless a service is actually running, though.
<infinity> caribou: Which for a oneshot, then gets trickier.
<infinity> caribou: See "Example 3. Stoppable oneshot service"
<caribou> infinity: hence the RemainAfterExit
<caribou> infinity: well, this seems to work, I'm just worried about "just being lucky"
<infinity> caribou: Yeah, but that won't do anything without an ExecStart, surely.
<infinity> (or something to start)
<caribou> infinity: k,I'll double-check that
<infinity> Maybe it will, though.  I dunno.
<infinity> Easy to check.  "start" it, and then check status.
<infinity> If it's running, you won, if not, you didn't, and your stop will never run.
<ginggs> infinity: is it ok to sync libv8-3.14 now? it builds on ppc64el but not powerpc, and powerpc is no longer a release architecure in ubuntu, right?
<infinity> ginggs: We haven't dropped it yet.
<infinity> ginggs: We don't have a concept of "release" and "non-release" architectures.  It's in until it's out.
<infinity> ginggs: But no reason it can't be synced after we definitely do drop it.
<infinity> "Add support for powerpc, ppc and ppc64el platform merging patch from Ubuntu"
<infinity> That implies it added ppc32 support too, though?
<ginggs> infinity: ok, well i'm not sure it will not build ubuntu, but it didn't in debian
<ginggs> infinity: and i can't test in a PPA :(
<infinity> Hrm.  It looks like it wouldn't indeed.
<infinity> Curious what they broke in taking our patch. :P
<infinity> ginggs: Ask me in a few days, and I can maybe help clean it up.
<ginggs> infinity: ok, thanks
<dupondje> chrisccoulson: how are things going with firefox? :)
<elopio> Laney: are you around? We are having issues with the armhf autopktest again.
<seb128> elopio, he's on vac today (doesn't mean he's not going to look to IRC at some point but you probably shouldn't count on it)
<elopio> seb128: thanks for the info. I've sent an RT, but I'm not sure if they have control over those machines.
<seb128> elopio, you can maybe try people in the foundations team as well
<seb128> they are the ones supposed to maintain that service
<seb128> or at least p_itti was in their team so I guess they had some handover
<elopio> slangasek: anybody else from your team can poke the armhf autopkgtest machines?
<elopio> infinity: and for the record, now the problem is rustup, which doesn't know what to do when it receives armv8l :)
<cjwatson> You probably always want to look into fixing the package that's failing as well
<cjwatson> Not to say that the infra shouldn't take the conservative route, but it's still a bug in the package.
<elopio> cjwatson: I will report a bug in rust. It's no package, it's a curl | bash: https://github.com/rust-lang/rustup.sh/blob/master/rustup.sh#L1551
<slangasek> elopio: so, what the issue regarding armhf autopkgtest machines?  I don't see excessive armhf-specific queues, has this already been resolved?
<cjwatson> slangasek: apparently they're running without the compat_uts_machine=armv7l (or whatever it is exactly) command line hack to stop uname reporting armv8l
<elopio> slangasek: related to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520627
<ubottu> Launchpad bug 1520627 in linux (Ubuntu Xenial) "New personality for more accurate armv7l emulation on arm64" [High,Fix released]
<elopio> uname regressed to return armv8l
<slangasek> elopio: ah, you're saying there's been a change in behavior on the test runners?
<chiluk> slangasek mind sponsoring https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1660372 since you are the debian uploader?
<ubottu> Launchpad bug 1660372 in cifs-utils (Ubuntu) "merge cifs-utils with debian 2:6.6-5" [Undecided,New]
<chiluk> also cyphermox can I get sponsorship for https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/1660362
<ubottu> Launchpad bug 1660362 in clock-setup (Ubuntu) "Merge clock-setup with debian 0.131 for zesty" [Undecided,New]
<chiluk> also slangasek cyphermox if this request annoyed you https://wiki.ubuntu.com/chiluk/CoreDevApplication  ... my DMB coredev meeting is this afternoon.
 * cyphermox looks
<slangasek> chiluk: ah; I saw a mail from you that suggested I had already missed the deadline before I'd even read the mail, so I hadn't followed up :)
<chiluk> slangasek ... DMB didn't reach quorum last meeting.
<slangasek> "the debian uploader" - well, I'm /a/ Debian uploader, who doesn't upload it
<chiluk> slangasek... stop beign so pedantic.
<chiluk> Uploaders: Steve Langasek <vorlon@debian.org>, Christian Perrier <bubulle@debian.org>, NoÃ¨l KÃ¶the <noel@debian.org>, Jelmer VernooÄ³ <jelmer@debian.org>, Mathieu Parent <sathieu@debian.org>
<chiluk> you were listed first...  must make you important..
<slangasek> chiluk: it's ok you have slavic background I give you pass for definite and indefinite article confusion
<chiluk> is true.
<slangasek> chiluk: half of your merge changelog is false because it is not a remaining change
<slangasek> elopio: so when did this regress?  I'm not aware of any changes we've made to the armhf autopkgtest runners recently
<slangasek> elopio: also, that kernel bug says it's fixed for xenial in 4.4.0-3.17; porter-arm64 is running a later linux-lts-xenial generic kernel, and uname -m returns armv8l.  Perhaps this regressed in the kernel?
<chiluk> slangasek you are absolutely correct.
<elopio> slangasek: we noticed on Friday. Last time this happened, Iain said something about rebooting the machines.
<slangasek> elopio: I can't imagine why rebooting the machines would fix the uname output...
<slangasek> chiluk: ok, changelog edited locally, and uploading
<elopio> Â¯\_(ã)_/Â¯
<chiluk> thanks slangasek...shame on me..
<slangasek> elopio: can you point me to specific autopkgtest logs showing the failure?
<chiluk> I checked for the keyutils.. but didn't occur to me that you might have fixed debian.
<cjwatson> slangasek,elopio: it's certainly worth checking /proc/cmdline if you can ...
<cjwatson> maybe they somehow got rebooted without the override param
<elopio> slangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20170129_193742_803b1@/log.gz
<elopio> search for rustup: unknown CPU type: armv8l
<cjwatson> that seems more likely than a kernel regression, just in an Occam's razor kind of way :)
<slangasek> oh, this requires a kernel parameter? it doesn't just dtrt under linux32?
<cjwatson> slangasek: No, for reasons, basically that it was too late by the time we noticed this was a problem and the 32-on-64 ABI was already defined
<cjwatson> slangasek: my memory was indeed correct and it's spelled compat_uts_machine=armv7l
<cjwatson> slangasek: LP builders run with that
<elopio> cjwatson: btw, do you know why is it that our armhf executions are slower?
<cjwatson> elopio: executions where?
<elopio> cjwatson: on those autopkgtest machines.
<elopio> this is armhf: Ran 28 tests in 3581.469s
<elopio> this is amd64: Ran 28 tests in 2746.484s
<cjwatson> elopio: I know nothing about the autopkgtest machines.
<cjwatson> Can't help you.
<cjwatson> elopio: My comments above are just from sharing experience with how the LP builders are configured.
<elopio> I know. I was just wondering :)
<elopio> not a big deal anyway because now we are moving some platforms to the nightly run.
<dobey> elopio: different load on the machines when the tests ran?
<elopio> dobey: this was on sunday morning, I think no other tests were running. But maybe.
<hallyn> Is there a way for non Canonical employees to verify whether someone has signed the CLA?
<jgrimm> hallyn, "Canonical Contributor Agreement" team participation
<hallyn> jgrimm: not sure that's reliable - i'm not listed there
<jgrimm> hallyn, wonder if you are part of a team that has membership
<jgrimm> hallyn, or something missing because you are a former canonical employee?  no idea
<hallyn> ok - thanks.  it's not terribly important, guy had a merge request against vmbuilder.  but that's being forked on github anyway so i asked him to resubmit as  PR there where no CLA requirement exists
<jgrimm> hallyn, if i look at your lp profile I'm able to see that you've signed.. is that field not visible if you look at someone elses id?
<jgrimm> hallyn, cool
<hallyn> jgrimm: where do you see that?
<jgrimm> hallyn, i was wrong. sorry
<hallyn> ok
<hallyn> hm.     i don't seem able to push to lp:vmbuilder
<hallyn> wonder whether it has to do with the switch to git
<hallyn> hm, no, i seem to have been dropped from vmbuilder-dev
<nacc> hallyn: wouldn't it be lp:vm-builder?
<nacc> hallyn: oh i see there's a distinct 'upstream'
<hallyn> no
<hallyn> yeah that naming was always funky
<hallyn> anyway, now someone needs to approve my membership, but there's noone to do that
<hallyn> maybe mvo
<hallyn> oh, smoser
<hallyn> smoser: can you hit approve on my request to join vmbuilder?
<smoser> here ? https://launchpad.net/~vmbuilder/+members#proposed
<smoser> i dont see you
<hallyn> sorry, no, vmbuilder-dev
<smoser> apparently, i cannot
<smoser> soren ^ ?
<hallyn> lol
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<elopio> slangasek: did you find anything about armv8l ?
<slangasek> elopio: I'm just getting sshed in over there now, it's been a stack of meetings this morning
<elopio> slangasek: thank you.
<elopio> slangasek: Sergio told me to mention the alternative of skipping the rust tests for now in armhf, as this is blocking our SRU.
<elopio> I know you don't like skips so I'm scared while I say this :)
<elopio> I can make sure that they pass in rpi3.
<slangasek> barry, tdaitx: what do you know about administering the armhf lxd autopkgtest runners?  I don't seem to have creds to ssh into the guests, and can't reach the host
<slangasek> elopio: which SRU is blocking on this?
<elopio> slangasek: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1659946
<ubottu> Launchpad bug 1659946 in snapcraft (Ubuntu Zesty) "[SRU] New stable micro release 2.26" [Undecided,New]
<sergiusens> slangasek: I didn't push yet to xenial or yakkety as I wanted zesty to pass
<sergiusens> slangasek: we can either disable the tests that use rust which has the machine detection problem or wait for the fix
<barry> slangasek: i don't believe i have access either unfortunately
<slangasek> barry: hrm, so this wasn't part of the training from pitti?
<barry> slangasek: no.  i suppose we need to talk to is to give more of us access
<slangasek> mmk
<chiluk> Dmitrii-Sh: can i get an upload for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225
<ubottu> Launchpad bug 1655225 in qemu (Ubuntu) "Under heavy load qemu hits bdrv_error_action: Assertion `error >= 0' failed" [Medium,New]
<chiluk> Dmitrii-Sh: I have a feeling you are asleep by now... but maybe you can catch it in the morning.
<Dmitrii-Sh> chiluk: 1 sec
<chiluk> oh awesome.
<chiluk> you just seem to be doing lots of qemu uploads recently
<chiluk> so I figured I'd ping you.
<Dmitrii-Sh> chiluk: oh, well I cannot do uploads myself yet
<mwhudson> infinity: hey, does this look like a glibc bug do you? https://bugs.launchpad.net/snapd/+bug/1657504/comments/18
<ubottu> Launchpad bug 1657504 in Snapcraft "asciinema 1.3.0 snap is segfaulting on 14.04" [Critical,In progress]
<chiluk> oh ok.. ah I understand you have just packaged up public patches.
<Dmitrii-Sh> chiluk: those were patches I was seeking sponsorship for basically
<chiluk> thanks Dmitrii-Sh I'll find someone else to sponsor the uploa.. I should have checked your perms.
<Dmitrii-Sh> chiluk: ok, np at all
<chiluk> good night Dmitrii-Sh
<Dmitrii-Sh> chiluk: thx
<infinity> mwhudson: Maybe?  But I'd have to see more debug output.  I'm shocked to discover we're using runpath for this.  I guess I naively assumed snaps ran chrooted *in* the core snap somehow.
<infinity> mwhudson: So, yes, this may well be a bug, as this is very infrequently exercised code, because Who Does That?
<mwhudson> infinity: this is for classic snaps
<mwhudson> which are a different breed of hack
<infinity> mwhudson: On the other hand, some googling suggests the behaviour is correct, and the docs are muddy.
<mwhudson> infinity: hm ok
<mwhudson> the docs are not muddy, they are wrong :)
<infinity> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638
<ubottu> Launchpad bug 1253638 in eglibc (Ubuntu) "dynamic linker does not use DT_RUNPATH for transitive dependencies" [Undecided,Confirmed]
<infinity> mwhudson: That Qt blog seems to be frequently referenced from anyone else discussing the issue.  I'd like to think it being widely-known for 6+ years would mean someone might have mentioned it upstream. :P
<mwhudson> infinity: what DT_RUNPATH is only 13 years old, do you think people are actually using it yet? :)
<mwhudson> infinity: open since 2012 https://sourceware.org/bugzilla/show_bug.cgi?id=13945
<ubottu> sourceware.org bug 13945 in dynamic-link "RUNPATH behaviour is not transitive" [Normal,New]
<infinity> 'The current gABI says "One object's DT_RUNPATH entry does not affect the
<infinity> search for any other object's dependencies."'
<mwhudson> oh heh https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html
<ubottu> sourceware.org bug 2002 in general "frysk's custom /usr/lib/frysk/pkgconfig/glib-java.pc is corrupt" [Normal,Resolved: fixed]
<mwhudson> ubuntulog_: lol
<mwhudson> ubottu: lol
<mwhudson> "The application or library can use whatever
<mwhudson> prefix it put in its DT_RUNPATH on the strings it passes to dlopen directly."
<mwhudson> except the library is sodding nss
<slangasek> elopio, sergiusens: I would prefer having the failing test selectively disabled in the package on armhf (yes, my views on skip-test are well known! ;). but yes, I'm willing to ignore the test failure manually on a one-time basis if that helps.
<infinity> mwhudson: So, yeah.  I think ld and dlopen are spec-compliant here.
<slangasek> elopio, sergiusens: of course, disabling it in the package would mean working around an infrastructure issue, so ignore that I even said that. Yes, I'll skip-test this for you.
<mwhudson> infinity: fair enough
<infinity> mwhudson: One could argue that libc itself might want a RUNPATH to be able to find its own modules.
<infinity> mwhudson: And I'd entertain that line of reasoning.
<sergiusens> slangasek: sounds good
 * sergiusens sees runpath/rpath conversations everywhere now
<infinity> mwhudson: But I tihnk what snappy is trying to do here is RPATH (or LD_LIBRARY_PATH), not RUNPATH.
<mwhudson> infinity: the thing that makes this extra fun is that the core snap is sometimes at / (for strict confinemt) and sometimes at /snap/core/current (for classic)
<mwhudson> sergiusens: you can't escape!!!
<infinity> mwhudson: Fun.  glibc isn't exactly the only library with plugins.  It's just the most obvious one.
<infinity> mwhudson: And I bet some *do* set RUNPATH, and that'll break if you're relocating them.
<mwhudson> yep
<infinity> Kinda sounds like this all needs LD_LIBRARY_PATH wrappers of doom.
<mwhudson> infinity: zyga is talking about patching the dynamic linker in the core snap
<mwhudson> which is kinda the extreme version of that i guess
<mwhudson> infinity: tbf we don't have to care about all libraries here
<infinity> Patching it to do what?
<mwhudson> just ones in the core snap
<mwhudson> infinity: change search paths depending on whether the process is a classic confinement snap or not
<infinity> I'm fundamentally opposed to ld.so (and, by extension, glibc) differing between a classic Ubuntu system and the ubuntu core snap.
<infinity> For so many reasons.
<infinity> So very many.
<zyga> infinity: oh, thouse would not differe
<zyga> infinity: on core we don't support confinement: classic snaps
<infinity> zyga: Then expand on "patching the linker in the core snap".
<zyga> infinity: we could ship the same glibc everywhere
<mwhudson> ups kinda outstayed my welcome in this cafe biab
<zyga> infinity: the core snap is used as the "runtime part" of supporting confinement: classic snaps on "classic" ubuntu
<zyga> (the word classic has three meanings, sorry about that)
<zyga> (classic snap on core, classic ubuntu and classic confinement)
<infinity> zyga: Yes.  I get that.
<infinity> zyga: I'm curious how you intend to patch the linker without patching the linker.
<zyga> infinity: I intend to patch the linker and ship it everywhere in ubuntu (and upstream if possible, but not required)
<sergiusens> slangasek: I'll be pushing something shortly then
<zyga> infinity: simply the effect would only be visible on classic ubuntu running classic confinement snaps
<zyga> infinity: (or any classic distro for that matter)
<zyga> but that case is perhaps more complex so let's solve the easier case first
<infinity> zyga: FWIW, as both glibc maintainer in Ubuntu and an upstream committer, I'm likely to push back on this unless it's got some very sane rationale, obvious thought about security considerations for heuristic lookup relocations, and some really solid likely/unlikely branching that makes it a near no-op for most cases.
<infinity> zyga: But happy to see initial rough cuts of what you *mean* at least, so I can maybe steer in another direction. :P
<zyga> infinity: ok, you have much better understanding of the internals than I do, perhaps just the simple goal statement would work; if you think that goal is hard to achieve (or unlikely for other reason) we can abort the process early
<zyga> infinity: the goal is to have a way where people can unpack debs into their confinement:classic snaps (or just build something locally without voodoo) and have that work*
<zyga> infinity: without the use of mount namespaces
<zyga> infinity: so that it uses predictable (good) dynamic linker and shared libraries
<infinity> And how do you envision that looking on the filesystem?
<zyga> infinity: on the filesystem it looks as follows
<infinity> Can I have both ubuntu-core 16 and ubuntu-core 18 snaps installed?  How do I know which one is which when I do a magic lookup?
<zyga> infinity: the core snap is mounted at /snap/core/current (current is a symlink) but we are allowed to rely on it
<zyga> infinity: yes, they would be different base snaps (gimme a sec)
<infinity> Kay.  I'll go for a smoke while you type and come back to the full explanation. :)
<zyga> infinity: the snap in question (say hello-classic) is monted at a similar location /snap/hello-classic/current/
<zyga> infinity: when you execute hello-classic wrapper generated by snapd, via snap-run/snap-confine/snap-exec the predictable dynamic linker from the core snap is invoked (side-stepping any linke in the distro)
<zyga> infinity: dynamic libraries should be resolved from the core snap, from the snap in question (hello-world) and not from the classic distro
<zyga> infinity: when you exec something then we need to be careful (hence glibc patches) to intercept that and use our linker again
<zyga> infinity: unless the executable is outside of /snap, where the normal behavior is expected (no magic)
<infinity> So, all binaries have a wrapper?
<zyga> infinity: similar redirection should happen when dlopen is used, it should not rely on libraries from classic distribution
<zyga> infinity: no, just declared apps
<zyga> infinity: but those are the only entry points
<infinity> If you have a wrapper, I'm not sure why you need a special linker.  You can set LD_LIBRARY_PATH
<zyga> infinity: but once you run (say declared app foo) you can freely exec any internal executable on the core snap, in your snap or on the host distro
<zyga> infinity: that would leak to the child processes and it is not sufficient to ensure we use the right dynamic linker
<zyga> infinity: that's my idea (so far), please tell me what you think
<zyga> infinity: as a closing remark: classic confinement works "almost" allright as long as you build software from source
<zyga> infinity: but it breaks if you want to use prebuilt software that people are more familiar with
<zyga> infinity: (the only thing that breaks is the glibc bug that mwhudson found)
 * zyga turns all ears
<mwhudson> zyga: which apparently is not a bug and maybe snapcraft should use rpath not runpath after all
<infinity> zyga: How do you propose finding the "correct" linker without specifying it manually?
<infinity> http://paste.ubuntu.com/23896033/
<infinity> Note that if I don't specify it there, I get the host system's linker/libc/libnss, which also works fine.
<infinity> Or, you're proposing the host ld.so first checks the binary's path, then forks the ld.so in the ubuntu-core root?
<zyga> infinity: snap-exec would know that it runs a confinement-classic app nffsdfsdfsfdsdfsdfadasd
<zyga> re
<zyga> sorry, lost connection
<zyga> infinity: snap-exec would run the desired application through the right linker if it was instructed to do so by snapd
<chiluk> hey cyphermox.. here's the qemu bug I'm needing sponsorship on https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225
<ubottu> Launchpad bug 1655225 in qemu (Ubuntu) "Under heavy load qemu hits bdrv_error_action: Assertion `error >= 0' failed" [Medium,New]
<zyga> infinity: so to be clear, running executables directly from (e.g. from shell) would not work
<zyga> infinity: it would only work if it got initiated by snap-exec
<zyga> infinity: and if we implement glibc changes to exec, from any process that uses classic confinement
<zyga> infinity: looking at the pastebin now
<infinity> zyga: Okay, so no linker changes needed there if snap-exec is divining which one to call.  ld.so is itself an executable for this very use-case.
<sergiusens> mwhudson: let me do a test run with rpath
<zyga> infinity: not directly, we'd run the linker instead of the executable in snapd
<zyga> infinity: the host linker would never see the executable
<mwhudson> sergiusens: s/--enable-new-dtags//g or whatever?
<mwhudson> sergiusens: would be interesting to see
<zyga> infinity: I don't know if this would work for the case that mwhudson found but perhaps we were just using the feature incorrectly due to bugs in the documentation
<zyga> (though reading the elf spec I find this aspect confusing)
<zyga> infinity: (the dlopen case)
<infinity> zyga: Oh, s/RUNPATH/RPATH/ will definitely fix mwhudson's issue, but it does nothing for your pre-build binary case.
<zyga> infinity: correct
<infinity> And fixing the prebuilt binary case means you don't need RPATH in the from-source case either.
<zyga> infinity: but there (I hope) we can patch the linker to chage its behavior
<infinity> So that seems like a distraction.
<zyga> infinity: oh? sorry, can you explain please?
<zyga> infinity: how would it work for pre-build binaries?
<infinity> zyga: You read my statement backwards. :)
<zyga> infinity: ah
<zyga> infinity: correct
<infinity> zyga: I'm saying that if there's a solution for pre-built binaries, from-source doesn't need RPATH hacks, as they can be built with the same assumptions as a deb was.
<zyga> (kids-going-to-bed-moment, sometimes distracting)
<zyga> infinity: yes, I understand and totally agree
<zyga> thanks
<infinity> I'm still knee-jerking at the claim that the linker needs any special knowlege of this.
<zyga> infinity: I think someone has to change the default search path, can it be anything but the linker?
<zyga> infinity: does the linker take any arguments we could use?
 * zyga runs --help to see 
<infinity> --help won't help much. ;)
<zyga> infinity: do you think setting --library-path is sufficient?
<infinity> --library-path is effectively the same as LD_LIBRARY_PATH.
<zyga> mmm, that's very promising then
<zyga> infinity: but that still leaves the exec case open
<infinity> Though, may fix your concern about leak-on-fork.
<zyga> infinity: yes, it does fix the leak
<zyga> infinity: and seems like a much cleaner solution
<infinity> (FWIW, tangentially related, but I think relying on 'current' symlinks is incredibly short-sighted here)
<infinity> Right now, you have one core ABI.  When 18 happens, you'll have two.  Without a flag day where all apps upgrade at once, you *need* any library-path wrapping magic to use versioned paths.
<zyga> infinity: I think the plan for core will change before 18, AFAIK the idea is that we will have many base snaps and still exactly one core
<zyga> infinity: and what you think of core will largely become base
<zyga> infinity: (core will be a small snap with mostly just snapd itself)
<infinity> And linker/libc?
<zyga> infinity: if we had many bases then each classic confinement snap will link against a specific core
<zyga> infinity: unclear, this is hand-wavy territory
<zyga> infinity: I think it is safe to say that we'll see base-16 and base-18 (perhaps base-16 will just be called base for legacy reasons)
<infinity> I mean, I know we've been kind enough to give you a stable ABI for almost 2 decades, but one should always prepare for their world being rocked by libc7. ;)
<zyga> infinity: if we were to say that we cannot rely on the current symlink we can still resolve things correctly by running ld.so directly, I suspect
<zyga> infinity: was it two decades already? wow
<infinity> Anyhow, I'd think an app meant to run against core-16 should know that, and the wrappers should be set up to know that.
<zyga> infinity: in case abi does change we should be fine as we can always run the right dynamic linker for each particular snap
<zyga> infinity: right, the snap/app knows that and so does snapd
<sergiusens> mwhudson: https://asciinema.org/a/bjzuw6ujlg3l39cx1ai1bn6ii
<zyga> infinity: if we don't use rpath/dt-runpath and instead use ld.so directly I think we don't have a problem with (eventual) abi transitions, right?
<infinity> zyga: It certainly makes life easier.
<zyga> infinity: we only have the exec patch for glibc that lives in core/base
<zyga> infinity: (still assuming that is needed unless we can find a way to make do away with it)
<infinity> zyga: Which exec patch?
<infinity> Did we just run full circle? :)
<zyga> infinity: the (theorethical) patch that would allow a process to exec anything and still DTRT
<zyga> infinity: maybe, bare with this for a moment
<zyga> infinity: a process running under classic confinement can exec anything it wants from the core snap
<zyga> infinity: if it runs /snap/core/current/bin/true we need to intercept that
<infinity> zyga: IMO, any snap that's on the path should be taking care of its own runtime setup.  So, if it needs a wrapper, the thing on the path is a wrapper.
<zyga> infinity: or it would again run with the system dynamic linker, right?
<zyga> infinity: that's at odds with reusing prebuilt software where you don't know anything about that and at odds with not leaking LD_LIBRARY_PATH
<infinity> zyga: Ahh.  I see.
<infinity> zyga: So, if a snap runs /bin/true, you want it to run the core version, not the host version.
<zyga> infinity: I think it is fine to limit this special behavior to just processes started by a snap
<infinity> (true probably being a stupid example, but I get the point)
<zyga> infinity: well, not really, /bin/true should be the host true
<zyga> infinity: but /snap/core/*/bin/true should be the core version
<zyga> infinity: e.g. imagine a bash shell snap
<infinity> Why would a snap ever call something in that namespace that way?
<zyga> infinity: it should be able to run stuff normally
<zyga> infinity: when you said namespace did you mean to refer to linux namespaces or was it just a word clash?
<infinity> My brain predates linux namespaces. :)
<zyga> infinity: classic confinement snaps are allowed to use core resources _and_ host resources if they want to
<zyga> hehe :)
<zyga> infinity: so if you build a quick snap with stuff from firefox.deb
<infinity> That feels like a strange design choice.
<zyga> infinity: it should work fine even if it wants to run something from your distro
<zyga> infinity: as long as it works fine by itself (I mean, it should not link to distro libs but it can run any executable and expect it to work normally)
<zyga> infinity: that's the design we've got, perhaps I misunderstand mark's intent but I think it feels like a "this is what you can count on but you can use anything you like"
<nacc> doko: in ldb 2:1.1.26-1ubuntu1, you changed -Xldb.so to -Xldb. in override_dh_makeshlibs. Was that intentional?
<zyga> infinity: it should allow people to use snaps quickly without learning new things
<doko> nacc: I assume that's an oversight
<nacc> doko: and, iiuc, the reason to switch from -c4 to -c3 in that release was since a new library was being introduced for python3?
<zyga> infinity: or even having to use devmode confinement (and have various other issues)
<nacc> doko: ok, np, just wanted to confirm, I'll probably ahve other questions : )
<zyga> infinity: if we can deliver that
<infinity> zyga: But doesn't it seem odd to have people calling things in that bizarre path?
<zyga> infinity: I think that's a big win
<zyga> infinity: no, why? if I tell firefox snap to use "evince" from my system to open PDFs then it should just do that
<zyga> infinity: it depends on each case but I think it is an important "no-barriers" design decision
<infinity> I don't want to muddly my code with calls to /snap/core/current/usr/bin/thing when what I really want is to call 'thing' and get a working one if one exists.
<zyga> infinity: move off debs/rpms/random stuff to stuff with no barriers in place
<infinity> Or are you prepending all the /snap/blah paths to PATH and hoping for the best?
<zyga> infinity: I'm doing neither, I don't think I understand your concern
<infinity> Cause that way does indeed lie madness.  You're calling into a chroot without chrooting.
<zyga> infinity: can you make an exaple, I think this is not mad and it should work OK but perhaps we're confusing something
<infinity> zyga: So, you say that people should be free to use /snap/core/*/bin/command despite NOT being chrooted.  How do you expect them to call it?  On PATH, or directly, or?
<zyga> infinity: I think I see your point, I didn't mention this but it should not be allowed (supported) to run /snap/* executables from the classic distro without going through /snap/bin and the snap-exec in the way
<zyga> on the way
<zyga> infinity: once that has happened (you ran via snap-exec) you should be able to execute any executable on the system correctly though
<zyga> infinity: as long as you give your app and entry point (which we control) this seems like a reasonable limitation
<zyga> infinity: e.g. a bash classic snap would work normally
<zyga> infinity: so would any less demanding program
<infinity> zyga: No, I'm not talking about how to run a snap from classic.  I'm talking about a snap itself forking.
<zyga> infinity: ok, so a snap itself forks
<zyga> infinity: if it chooses to exec something from the host that's fine (no patches needed), right?
<infinity> zyga: And you're saying a forking snap should be able to call binaries inside core.
<infinity> zyga: How is it calling them?
<zyga> infinity: it would go through the systmem linker
<zyga> infinity: yes
<zyga> infinity: and that's the place where I believe we need to patch glibc
<infinity> How.  Is.  It.  Calling.  Them?
<zyga> infinity: so that exec is changed to exec via core's ld.so
<infinity> You bring up a "bash snap" (I assume you mean a shell script).  Is that shell script calling things as /snap/core/current/bin/thing?
<zyga> infinity: (I meant bash itself deployed as a snap)
<infinity> Well, bash itself is just a binary like any other.
<zyga> infinity: yes but let's say you want to snap install bash
<infinity> There's nothing special about it.
<zyga> infinity: (some new version)
<zyga> infinity: and use that on your system for everything
<zyga> infinity: (e.g. your login shell)
<zyga> infinity: (* not everything but daily stuff)
<zyga> infinity: you'd expect that bash to have no unreasonable limitations
<jdstrand> I don't want to get embroiled in this cause infinity will be able to recomend the best course of action, but, if I ship 'foo' as a snap, aiui, /snap/bin/foo should use core's libraries/etc but 'foo' exec'ing 'ture' should get the host's 'true'. it going to /snap/core/current/bin/true seems like a huge corner case
<infinity> Then /snap/bin/bash is a wrapper that configures it correctly.  This isn't relevant to the forking thing.
<zyga> infinity: correct
<infinity> So, again, no glibc patching.  Check.
<zyga> infinity: what if in bash I run /snap/core/current/bin/true
<jdstrand> if it wants to call its own stuff, it needs to use /snap/bin
<infinity> Why are you running that?
<jdstrand> yes, why?
<zyga> infinity: because any app can run any command from core transparently as a normal course of action
<infinity> How is that a use-case we want to waste any time supporting?
<zyga> infinity: and that is supported today in other snaps
<infinity> Any confined app can, yes.
<zyga> infinity: and removing this would surely break something
<infinity> classic apps are meant to run as if they're on the hose system.
<zyga> infinity: (e.g. stuff running stuff via system() and what not)
<jdstrand> I think the use cases are incredibly few
<infinity> s/hose/host/
<zyga> jdstrand: I disagree, we specifically say that you can rely on anything in the core snap being there
<zyga> jdstrand: this translates to people using that
<infinity> zyga: Here's the fundamental difference.  A confined app runs /bin/true and gets the core version.  To get the core version in a classic app, you have to obtusely call /snap/core/version/bin/true
<zyga> jdstrand: and I don't think we want binary wrappers for any executable in the core snap
<zyga> infinity: correct
<jdstrand> zyga: classic, aiui, is about running your stuff as a snap and able to call the host's stuff without issue. calling into /snap/.../ without going through /snap/bin is totally unreasonable imho
<infinity> zyga: The latter use-case makes zero sense to me.  This isn't about transparently supporting something.
<zyga> infinity: hmm, I disagree, if I know that core snap has well-defined "awk" I may just decide to use it
<zyga> infinity: why would it be unreasonable?
<zyga> infinity: core snaps run in an unknown world where the only save heaven is the core snap
<zyga> infinity: if we say that they cannot run any executable in the core snap then that feels like a broken story
<infinity> zyga: Because calling into a weird chroot path is exactly the opposite of transparently running on the host system? :P
<jdstrand> zyga: the one case I could see as interesting is foo wants to calls something in its own $SNAP, but that is easily remedied by exposing that thing being in /snap/bin
<infinity> If your goal is for classic to have all the same features as a confined snap, you will fail.
<infinity> Period.
<zyga> jdstrand: except that's not something that they do today
<jdstrand> zyga: but classic is fundamentally different than devmode or strict
<zyga> infinity: that's not my goal but the goal is to offer classic as a simple way to have more things working as a snap, I think that not allowing to run executables from the core snap is at odds with that idea
<zyga> jdstrand: technically yes but we should do our best to make that seem less so
<zyga> jdstrand: it's a step towards devmode towards strict
<infinity> zyga: And, to be clear, to support your use-case, you need to patch the HOST libc, not the core one.  Which means either this only works on Ubuntu, or you need to patch *all* host libcs.  If it only works on Ubuntu, we have a set of things people can rely on for classic snaps, it's called "Essential: yes" in dpkg/apt.
<zyga> infinity: can you tell me why I'd have to patch the host libc?
<jdstrand> zyga: my understanding of what is desired is to be able to run your thing and anything on the host, not your thing, anything on the host and any arbitrary thing in /snap that happens to have the x bit set
<infinity> zyga: Because you're calling /snap/foo/bin/true, and the kernel is invoking the host ld.so.
<infinity> zyga: Welcome to ELF.
<zyga> infinity: I know, but my idea was that since this would *only* be allowed from classic confinement snaps
<zyga> infinity: those would run with our libc
<zyga> infinity: and those could have patched exec that injects the linker at that time
<zyga> infinity: (as I said this doesn't apply to someone just wanting to run /snap/core/current/bin/true from outside of a snap)
<jdstrand> why would they only use our libc?
<jdstrand> classic isn't supported on other distros?
<zyga> jdstrand: because on all distros they would link to our libc
<zyga> jdstrand: via the ld.so trick we discussed earlier
<infinity> Eh?
<infinity> One of your stated goals for classic is to not rebuild binaries in special ways.
<zyga> I think there's something fundamental that I'm either wrong about or I didn't state earlier
<jdstrand> the ld.so trick was a snap run thing (ie /snap/bin wrapper), no?
<zyga> infinity: correct,
<zyga> jdstrand: correct
<jdstrand> so, this thing is running now
<zyga> jdstrand: and at that time you run against our libc
<jdstrand> it execs /snap/random/binary
<zyga> jdstrand: becuase our linker ran /snap/random/binary
<jdstrand> that is going to use the host's libc
<zyga> jdstrand: with altered library paths
<zyga> jdstrand: no
<zyga> jdstrand: that's the part I disagree aobut
<zyga> *about
<infinity> That's not how linkers work.
<zyga> jdstrand: wait, sorry, (lag on irc)
<zyga> infinity: I know what you mean
<zyga> my assertion is as follows:
<zyga> any app that *starts* executing via snap-exec + ld.so trick uses our libc?
<zyga> can we all agree on that?
<jdstrand> that sounds reasonable to me
<infinity> I run /snap/bin/foo, which is a wrapper that calls into the core linker and loads foo with the core ld.so and libc.  So far, we're on the same page.  Then foo invokes /snap/core/current/bin/true, THAT will load with the system ld.so
<zyga> yes
<zyga> I agree and that's why I keep saying I think we need to patch our libc to do something different then
<infinity> No.
<zyga> how can a process run another application? only via exec right?
<zyga> infinity: I agree that as things stand now /snap/core/current/bin/true will load with the distro/system ld.so
<infinity> There are many entry points to the fork syscall.
<infinity> What you want is a kernel patch, not a libc patch.  And you don't want a kernel patch either. :P
<zyga> infinity: fork != exec, fork doesn't hurt us
<zyga> infinity: I bet we can do this with just libc, what else is there? what am I missing?
 * jdstrand reasserts that running /snap/core/current/bin/true would not be a case we should support. classic gives you your snap, /snap/bin and running host binaries. period. anything random executable in /snap is not supported by snapd proper, but a snap could invoke it on its own
<jdstrand> (by setting whatever enviornment it wanted)
<infinity> zyga: fork is exactly the case we were discussing.
<zyga> jdstrand: that's not what mark described; I'm not arguing with you
<zyga> jdstrand: I don't disagree with your POV but if we're asked to support /snap/core in its entirety that's what we need to do
<jdstrand> zyga: I wasn't in those meetings but what I've read on the subject, I'm surprised /snap/core/current/bin/true is meant to be a supported use case
<zyga> infinity: can you tell me how forking is a problem?
<zyga> jdstrand: I can ask mark / gustavo to clarify
<infinity> zyga: You want to be able to fork /snap/core/current/bin/true ... You can't.
<zyga> jdstrand: but regardless I'd like to understand if we can technically do it
<infinity> And I don't understand why you'd want to.
<zyga> infinity: I think you exec /snap/core/current/bin/true, not fork it (then we agree)
<zyga> infinity: fork just forks the process, right?
 * jdstrand said his piece and wanders off
<infinity> exec replaces a process with another process, fork creates a child process.
<infinity> You may well want both, but both are fundamentally silly in this context.
<zyga> infinity: and exec is a library call via glibc (I agree that it would not block someone going at the raw syscall)
<zyga> infinity: ok we are in agreement on this; fork is not a problem because it doesn't interact with any of the parts at play, exec is the only point where we have issues
<infinity> system(), for instance, is a fork.
<infinity> Calling any process from a shell script is a fork.
<zyga> infinity: fork + exec
<infinity> Calling anything from python is a fork.
<zyga> infinity: yes
<zyga> infinity: sure but I don't see any issues in fork alone
<infinity> Some languages use the raw syscall to do so.
<zyga> infinity: you just have a new process running the same thing at that time
<infinity> ...
<zyga> infinity: that's interesting and that's indeed a problem
<jdstrand> I will say one other thing. executing something in /snap/random/... is not a path towards devmode since that isn't at all supported by devmode
<infinity> BUT YOU WANT TO ALLOW PEOPLE TO FORK /snap/core/current/bin/true
<infinity> Just no.
<zyga> infinity: (please don't shout at me, I'm trying to understand technical side, I want people to fork+exec /snap/core/bin/true and my assertion is still that with patched exec that's well possible to achieve
<infinity> Classic snaps on Ubuntu have a defined set of things available to them.  It's called Essential.
<zyga> jdstrand: except that /snap/core/current/bin/random may be allowed by the default policy or by an interface, then we do allow that
<infinity> Classic snaps on other distros might not have such a set, but we can't "fix" that without patching the HOST.
<sarnold> infinity: fork(2) absolutely must remain available. THat's how most unixy processes do threading.
<jdstrand> zyga: but not at /snap/core/current/bin/random. /snap/core/current/bin/random isn't in your PATH
<infinity> sarnold: Erm, yes.  But not relevant to this discussion.
<zyga> jdstrand: that's true
<zyga> infinity: I don't want to argue if it is a good idea to support that thing
<jdstrand> so a classic snap has to go *completely* out of its way to call something in /snap/random/...
<zyga> infinity: just to understand if it is technicaly doable
<infinity> zyga: It's not doable without patching the host.  Host libc for reasonable coverage, host kernel for total coverage.
<zyga> jdstrand: ok, I agree but I think we need to spin this around a little
<zyga> jdstrand: let's forget about core
<infinity> zyga: Neither of those seems like a thing we should do.
<jdstrand> if it is going to do all that, it can call with the right linker or we can provide a helper for it to use that calls the linker
<zyga> jdstrand: a snap can run its own apps
<zyga> jdstrand: and if that's just a random app they have inside they should be ale to run it
<zyga> jdstrand: and they cannot run it on !classic confinement if they expose it as an app
<infinity> Sure, running their own stuff is simple, though, as they should be exposing it with the same wrapper style as the primary binary was.
<zyga> infinity: that's not as simple as you think, we have some strong semantics of what that means
<zyga> infinity: and they don't have to use any wrappers, today, to run executables from the same snap
<jdstrand> zyga: core doesn't run anything. as for the random app of its own, that is the only interesting case. I think exposing that in /snap/bin is not unreasonable. both would be in its path
<jdstrand> but, there is perhaps some thinking that needs to be done there
<zyga> jdstrand: but that also lets users see it and it may not be something you wanted
<zyga> jdstrand: and it would have different name
<zyga> jdstrand: e.g. /snap/bin/$SNAP_NAME.foo
<zyga> jdstrand: so breaks unpacking debs
<infinity> So snap needs a libexec concept.
<jdstrand> I understand. that is why I said it is the interesting case
 * zyga is still convinced that we need to path exec to achieve transparency (except syscalls, I totally agree with infinity on that)
 * jdstrand has to run
<zyga> the libexec idea is intereting
<zyga> I think it is worth exploring
<zyga> e.g. for snapctl
<zyga> jdstrand: o/
<zyga> infinity: sorry for being so tought in this conversation, I really want to understand what we are standing on now
<zyga> infinity: and I'm not desigining anything, just implementing a design (that I may misunderstand as it stands)
<infinity> Well, designs can sometimes be wrong, too.
<zyga> infinity: I'll talk to gustavo/mark about what are the guarantees we expect people to have in classic confinement
<infinity> Shockingly.
<zyga> infinity: totally
<zyga> infinity: but wrong != impossible
<zyga> infinity: and I was trying to probe what's doable
<infinity> And Jamie and I seem to agree that a design that says classic snaps can execute things in the core snap is probably not quite right.
<zyga> infinity: even if that's unorthodox behavior to say the least
<zyga> infinity: I think that's fine and as I said a moment ago, the case of running stuff from their own snap without going through wrappers is far more interesting
<infinity> The corollary there is: Not impossible != right
<zyga> infinity: and perhaps the answer is indeed libexec
<zyga> infinity: as that has many advantages (simplicity and flexibility)
<infinity> And yes, being able to run your own subordinate binaries is a much more interesting and valid use-case.
<zyga> infinity: but it also has some downsides that I can think of quickly
<infinity> As it's a very UNIX thing to do, and dozens of applications do it.
<zyga> infinity: e.g. hardcoded paths that don't go through path search
<zyga> infinity: e.g. gtk/glib running some internal helpers that have baked-in paths based on prefix
<infinity> The general way is either to ship subordinates in /usr/bin (in which case, they're expected to be on path, and should be wrapped in /snap/bin) or to ship in /usr/lib/$app/ and called directly, which needs a snap mapping think, probably.
<sarnold> btw why not just recompile with ./;configure --prefix=/snap/ or whatever?
<zyga> infinity: and people using --prefix=/snap/$SNAP_NAME/current/usr
<zyga> infinity: I don't think that libexec idea can support that
<zyga> eh, laggy again, probably lost connectiong
<zyga> *connection
<infinity> zyga: I didn't literally mean we need a BSD-style libexec (and, indeed, if snap mirrors the FHS, it's library subdirs per app), but that we're dealing with the concept of libexec, that is executables in a library directory.
<infinity> zyga: That is an interesting problem to discuss (and should be entirely doable with the same launching/wrapping techniques used for /snap/bin)
<infinity> Or, if you prefer "executables off the path", we just happen to stuff them in library dirs. :P
<zyga> sarnold: debs
<zyga> sarnold: people love to have snaps that just unpack 12 debs
<zyga> sarnold: and expect them to run
<zyga> sarnold: and if we can support that, we win hearts
<infinity> But, unlike "all the things in /bin and /usr/bin in the core snap", the off-path executables in a package are a known quantity, identifiable, taggable, and wrappable.
<zyga> infinity: I only agree if "good practice" == "actual practice"
<zyga> infinity: if that breaks gedit I'll want exec interception
<zyga> infinity: if gedit/gimp/whatever run fine then I won't argue :)
 * zyga needs to EOD
<zyga> as irssi tells me it's past midnight and my wife tells me I should stop working at some stage
<zyga> infinity: can we use that idea even if an app ships hardcoded path to run something?
<sarnold> zyga: gnight :)
<infinity> Hardcoded paths are problematic in new and exciting ways. :P
<infinity> But I also need to escape this discussion at least for today.  So you should EOD so I stop typing.
<zyga> infinity: take care, thank you very much for the conversation :)
<infinity> zyga: Have a good night unwinding and not arguing on the internet. ;)
<infinity> (Though, there's plenty to argue about these days that isn't work related too :/)
#ubuntu-devel 2017-01-31
<nacc> doko: also, there seems to be an undocumented change to drop the CFLAGS support ('noopt' in DEB_BUILD_OPTIONS), not sure if that was intentionally done (or which changelog entry it corresponds to)
<nacc> doko: i'm also unclear on the use of dh-exec (it was added to python-ldb-dev.install it seems)
<pdeee> rbasak, RAOF, hlieberman: am I correct in undetstanding that the only outstanding task for the Certbot SRU is getting an extra reviewer for the change to the python-letsencrypt package?
<RAOF> pdeee: That is my understanding
<RAOF> pdeee: I believe rbasak will be doing that review.
<pdeee> RAOF, in comment #27 he said that he wanted someone else to do it. But I'd be happy to hear that is no longer the case! :)
<RAOF> I think he got the 2nd opinion from an archive admin.
<pdeee> great to hear! rbasak does that mean that we're basically ready?
<ginggs> mitya57: hi, would you please look at this build failure https://launchpad.net/ubuntu/+source/python-hypothesis/3.6.1-1ubuntu6 - is this a bug in sphinx?
<rbasak> pdeee: I had some notes, but they're not on this computer. I'll pull them out within a couple of hours. I had a couple of minor requests only. IIRC, a changelog and NEWS entry describing the behaviour change (that the cronjob is now active) was one of them. And update-maintainer. I'll check for others when I can get to the notes.
<cpaelzer> rbasak: hiho, do you remember when we discussed last week about "when exactly" the dpdk upload will be ready to do a no change rebuild for openvswitch-dpdk?
<cpaelzer> I happend to miss that it was blocked on the new queue at first
<cpaelzer> this was resolved and we discussed where on LP exactly one could/should check if it is available
<rbasak> cpaelzer: yes
<cpaelzer> rbasak: it seems we were wrong, but I'm still trying to understand
<cpaelzer> rbasak: even after it showed up where we discussed last time it wasn't "pulled in" for the build
<cpaelzer> rbasak: I'm currently assuming it was because of a (known) component mismatch in DPDK
<cpaelzer> rbasak: that way it might have appeared on LP as if it would be "all ready" but the later rebuild of openvswitch still took the old version
<cpaelzer> rbasak: would that make sense?
<cpaelzer> I got to this as I have tests failing now looking for old sonames, and then checked the openvswitch build log to find it using the older version
<cpaelzer> I have a new DPDK which would get rid of the component mismatch for now, but really really want to avoid inflating openvswitch no-change-rebuilds too much :-)
<cpaelzer> so I want to full yunderstand
<rbasak> I'm not sure myself.
<rbasak> cpaelzer: what version did you need it to build against?
<rbasak> 16.11-1?
<rbasak> cpaelzer: and which package has the component mismatch please?
<rbasak> Although component mismatches can't happen on build deps now.
<rbasak> So it can't be that, can it?
<cpaelzer> rbasak: sorry had a interrupt
<cpaelzer> rbasak: yes 16.11-1 it should have build against
<cpaelzer> rbasak: and I uploaded the no-change after https://launchpad.net/ubuntu/+source/dpdk showed us it was built and available in proposed
<cpaelzer> rbasak: the component mismatch is on pytohn-elftools, you can see it e.g. in update_excuses
<cpaelzer> rbasak: it is a runtime dependency
<cpaelzer> rbasak: I have an upload to DPDK ready which drops that from a recommends to a suggests to make it happy
<cpaelzer> rbasak: a bit of version magic as we will have to be "in front of" Debian for a few weeks because of their freeze, but other than that ok
<cpaelzer> rbasak: yet I want to time and order it absolutely correctly to avoid having more than one more rebuild of openvswitch
<cpaelzer> rbasak: I have the new DPDK in bileto and all is fine, except - of course - the dependent openvswitch test fails because it was build against the too old version
<cpaelzer> rbasak: Now I wonder if that would be the right approach 1. publish new dpdk without component mismatch from bileto; 2. once that is available and passed dependencies in update_excuses it will block on the openvswitch test 3. only after that I'll upload another (hopefully final) no-change to ovs
<cpaelzer> rbasak: the DPDK upload also fixes a ppc test issue which currently blocks several reverse dependencies
<cpaelzer> rbasak: I mentioned that yesterday on ubuntu-releae as FYI but I want to unblock all those other things
<cpaelzer> rbasak: and it will pick up the new Xen
<cpaelzer> all could be so fine if things ever would work as intended :-)
<rbasak> cpaelzer: if you build locally with sbuild, does it build correctly?
<cpaelzer> rbasak: remaining open question - I'm not sure yet if the publish from Bileto will be right to get this as intended or if instead I'd have to upload "normally"
<cpaelzer> rbasak: you mean if I re-build openvswitch-dpdk with a proposed enabled sbuild locally?
<rbasak> Publishing from Bileto copies the binaries, right?
<cpaelzer> rbasak: yes it does
<cpaelzer> DPDK binaries in that case
<rbasak> So is the Bileto build correct?
<rbasak> Of openvswitch
<cpaelzer> I have no openvswitch in it (yet)
<cpaelzer> right
<rbasak> Ah, OK.
<cpaelzer> I could put the new openvswitch in there
<rbasak> So yes, try there or locally maybe?
<rbasak> I don't know the answer, just suggesting how I'd approach figuring it out
<cpaelzer> yeah, ovs in there would at least avoid polluting archive version numbers if things go wrong
<cpaelzer> and doing "joint" migrations was one of the things in bileto I wanted to try anyway
<rbasak> I understand your desire to understand what's really going on, but I don't know what's really going on :-/
<cpaelzer> rbasak: one puzzle piece at a time
<cpaelzer> for now I just memorize component mismatches as a hiden inhibitor that I should consider in future
<cpaelzer> mabye later on somebody else can shed some extra light on it after reading this
<rbasak> Now that builds always have universe enabled, I don't see how a component mismatch can have anything to do with it
<Laney> elopio: ah oops, I forgot to pull the commit to actually do the reboot /o\ /o\ /o\
<pitti> barry, slangasek: you can reach the arm64 runners from the autopkgtest-cloud-worker/0 instance (they have its ssh key)
<pitti> nobody from outside is supposed to have ssh access (I didn't have either)
<josvaz> Got some questions about development from a PPA (Eg. https://launchpad.net/~cloud-support/+archive/ubuntu/rax-devel/+packages pkg rax-openstack-guest-agents)
<josvaz> I am gussing to start development (if you lack a LP repo) you should download the .dsc orig.tar.gz and the debian.tar.xz in this case
<josvaz> then use dpkg-source -x ...dsc to get the sources ready to work with them
<josvaz> Anything special there I might be missing?
<josvaz> cause when I build the package it does build clean the first time, but the second it complains that a file I did no touch had been modified (by the build scripts I guess)
<josvaz> can it be I am missing some cleanup command?
<josvaz> I am using debuild to build the source
<juliank> Eww, seems I forgot to cherry-pick the changes for apt 1.2.17 in xenial (bug 1642386) into yakkety. How odd
<ubottu> bug 1642386 in apt (Ubuntu) "At least one invalid signature was encountered." [High,Fix released] https://launchpad.net/bugs/1642386
 * juliank is supposed to c-p downwards and not just skip branches :/
<juliank> Ah no, that was fixed there in 1.3~rc3
<Laney> elopio: FTR, it's a reboot required to actually apply the new linux cmdline
<jgrimm> barry, FWIW, I seem to be hitting exactly this too -> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202#19
<ubottu> Debian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open]
<barry> jgrimm: that went away for me when i upgraded to zesty.  what are you on?
<jgrimm> yakkety. :)
<barry> there ya go ;)
<jgrimm> same delays, same final timeout error. :)
<barry> i never did figure out why yakkety had that problem
<jgrimm> I'll upgrade my nuc to zesty and see if it goes away for me too.  but i'll probably file an ubuntu bug at least
<barry> jgrimm: +1
<jgrimm> thanks sir
<rbasak> jgrimm: FWIW, there's a newer version of autopkgtest in yakkety backports
<jgrimm> rbasak, oh.. i'll look, thanks
<zul> doko: ping
<elopio> thanks Laney :)
<zul> doko: when you get a chance can you review python-os-xenapi its in source new and nova is is in dep-wait because of it
<doko> zul: unlikely today, leaving early
<zul> doko: ok
<zul> doko: thanks
<slangasek> pitti: I was on autopkgtest-cloud-worker/0 when trying to access them
<pitti> slangasek: oh sorry -- I meant wendigo, Laney and me created the instances from there
<pitti> slangasek: i. e. nova boot with https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata as userdata
<slangasek> pitti: ah, ok
<pitti> (probably still in bash_history somewhere)
<Laney> ya
<chiluk> bdmurray: why did you undo the verification for LP: #1587039 ?
<ubottu> Launchpad bug 1587039 in qemu (Ubuntu Trusty) "aio: strengthen memory barriers for bottom half scheduling" [Undecided,Fix committed] https://launchpad.net/bugs/1587039
<chiluk> was there a particular reason, or just because it's not obvious what work seyeong did in testing?
<jgrimm> rbasak, barry: interstingly the -backports autopkgtest didn't exhibit the problem.  \o/
<barry> yeah, that is interesting
<slangasek> pitti: indeed, it is in scrollback, and actually shows the runners do have the correct commandline.  Does this mean Laney got in and fixed this before me?
<slangasek> sure does
<slangasek> Laney: thanks
<slangasek> and indeed, I did wonder that I didn't see any logic to reboot them
<Laney> np, sorry for the bus factor
<Laney> mapreri: ricotz: Are either of you fixing the x265 ppc64el build failure?
<ricotz> Laney, oh, wasn't aware that it failed
<ginggs> Laney: https://bitbucket.org/multicoreware/x265/issues/320/fail-to-build-on-power8-le
<Laney> ricotz: Was doing so in experimental too
<Laney> ginggs: Yes
<ricotz> Laney, I see
<doko> rbasak: could you do the kombu and python-glanceclient validations for the trusty updates?
<rbasak> doko: I don't see kombu. python-glanceclient would normally be done by the openstack team. Any particular reason you're asking me?
<doko> rbasak: hmm, wait, you didn't do the updates ...
<bdmurray> chiluk: Because there was no indication what testing was performed.
<doko> coreycb: could you do the kombu and python-glanceclient validations for the trusty updates?
<mapreri> Laney: I sent it upstream, but haven't yet had time to deal with it myself /cc ricotz
<mapreri> oh, ginggs linked it already
 * mapreri is busy
<Laney> mapreri: Right, I saw it, just a bit annoying due to being a transition
<coreycb> doko, yes i will today.  i think i already verified kombu.
<ricotz> Laney, mapreri, simply disabling ALTIVEC should work
<ricotz> e.g. https://paste.debian.net/plain/911927
<ricotz> this feature only concerns power8
<mapreri> ricotz: thanks, I'll see later for it.
<mapreri> Laney: yeah, I didn't check the buildd in debian before syncing...
<mapreri> sorry
 * mapreri â afk for some more time
<chiluk> Yeah bdmurray, I'll get that sorted with seyeongkim later today.  I highly suspect that he did testing, but it got lost in translation
<chiluk> bdmurray... from what he's said it may not be easy to do bug verification, so we may have to live regression testing instead.
<chiluk> bdmurray: if it makes you feel better a large cloud is already running with those fixes.
<chiluk> I frankly feel that to be almost verification enough.
<chiluk> either way I'll get it sorted tonight..
<Laney> ricotz: mapreri: yeh, will look
<Laney> ricotz: mapreri: I uploaded that, thx
<mapreri> Laney: thank you.  Should I proceed with the rebuild of the relevant rdep(s)?
<mapreri> (published 6 minutes ago, for all archs already)
<jbicha> mapreri: you might need to wait a bit longer for the repos the Launchpad builders use to get the new binaries
<mapreri> jbicha: sure, I'd do that later anyway, I don't have the needed right now.
<jbicha> by the time rmadison shows the new files, you should be fine though
<mapreri> needed key*
<gQuigs> oops.. I missed that the verification tags got reset - https://bugs.launchpad.net/python-jujuclient/+bug/1644153
<ubottu> Launchpad bug 1644153 in python-jujuclient "SSL handshake fails on xenial, yakkety, zesty" [Undecided,New]
<gQuigs> should be good to SRU
<mapreri> Laney, ricotz: JFYI: started the rebuilds
<ricotz> mapreri, handbrake and libav?
<ricotz> I mean ffmpeg
<mapreri> not only those, but yes
<ricotz> and vlc
<mapreri> see https://release.debian.org/transitions/html/auto-x265.html for a start (ok, debian, but the list should be pretty much the same)
<mapreri> I'll see if there are more once the update_output log becomes readable
<mapreri> and/or I'll be bothered enough to deal with that grep-dctrl invocation I can never remember
<ricotz> gst-bad should be fine already
<mapreri> no, the ppc64el build picked up the old li
<mapreri> lib*
<ricotz> right
<mapreri> https://launchpadlibrarian.net/304596806/buildlog_ubuntu-zesty-ppc64el.gst-plugins-bad1.0_1.10.3-1ubuntu1_BUILDING.txt.gz => Get:373 http://ftpmaster.internal/ubuntu zesty/universe ppc64el libx265-95 ppc64el 2.1-2 [1111 kB]
<mwhudson> slangasek, infinity: do either of you happen to know if debian-installer does Something(tm) to get 'shift tab' to emit '\033[Z' on the linux console rather than just ^I?
<slangasek> do not know
<slangasek> cyphermox: ^^ ?
<cyphermox> I don't know
<cyphermox> if it's the case, it's certainly some termios magic that won't be all that obvious
<mwhudson> googling leads me to http://knowledgebase.progress.com/articles/Article/000049337
<mwhudson> which does actually seem to work
<mwhudson> but uh
<mwhudson> i don't know what that's doing at all
<cyphermox> loadkeys is redefining what happens when the system receives a keycode
<cyphermox> that would probably be stuff in console-setup
<sladen> scancode -> linux keycode -> /dev/input code -> ansi sequence -> X mapping -> X keypress
<mwhudson> sladen: talking about the console here, no X at least :)
<mwhudson> cyphermox: any idea how to find it?
<mwhudson> or who might know how to find it?
<sladen> mwhudson: what are you wanting to do?  Just put the keyboard in ansi mode?
<sladen> mwhudson: I expect ncurses probably puts the keyboard in raw mode and does the magic/handling internally
<mwhudson> sladen: in the linux console, by default shift tab just sends the tab character
<mwhudson> sladen: in d-i though, it sends, well, something different, probably \033[Z
<mwhudson> sladen: i want to find the code that makes that change
#ubuntu-devel 2017-02-01
<nacc> doko: ok, so the merge for ldb is pretty ugly because of the python3 churn. I've put up what I think is the broken out delta (the order may not be fully correct yet, but I think it's close) at: https://git.launchpad.net/~nacc/ubuntu/+source/ldb?h=merge I've also pushed a few tags (old/debian, old/ubuntu, new/debian which should help give some reference to what is being merged where)
<nacc> doko: i put your nick in a few commit messages, if you could look and help me understand then :)
<nacc> s/then/them/
<cpaelzer> I need an advise how to resolve something in zetsy proposed migration
<cpaelzer> I verified DPDK (new version) and Openvswitch (no change rebuild against it) both test fine
<cpaelzer> Then I published from bileto
<cpaelzer> I have expected that they test the same
<cpaelzer> but in my case openvswitch is fine (testing the new OVS vs the new DPDK)
<cpaelzer> yet the autopkgtests for DPDK run against the OLDER version of openvswitch
<cpaelzer> those fail, but that is clear
<cpaelzer> can I in some way tell the autopkgtets on DPDK to run against the newer openvswitch version?
<cpaelzer> then all would resolve and both could migrate
<cpaelzer> rbasak: ^^ TL;DR copying both from bileto as we discussed yesterday triggered the old OVS to be tested
<sarnold> if the package requires the newer version should it use a versoined depends?
<cpaelzer> sarnold: openvswitch depends on dpdk, and after build it gains versioned depends automatically by the binaries
<cpaelzer> sarnold: but vice versa - DPDK does not depend on openvswitch at all
<cpaelzer> sarnold: it only triggers the dep8 test of (the old) openvswitch
<sarnold> cpaelzer: oh. ofccourse. because dpdk is useful even without.. isgh. I should have gone to bed an hour ago. :)
<cpaelzer> sarnold: I'm happy to discuss any suggestion before I do another "no change upload"
<cpaelzer> sarnold: and - yes - sleep well and soon :-)
<sarnold> cpaelzer: if you don't get any better answers, this looks promising https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst#n91
<infinity> cpaelzer: So, the new dpdk breaks the old openvswitch?
<sarnold> hey look it's better answers :)
<infinity> cpaelzer: Why does the new dpdk break the old openvswitch?
<cpaelzer> infinity: TL;DR of a more complex detail "by no more providing the same .so version"
<infinity> cpaelzer: (Or, put another way: this is exactly why autopkgtests exist)
<infinity> cpaelzer: Erm.  Come again?  If there was an ABI bump *and the packages were renamed to match*, there wouldn't be a failure here.
<infinity> cpaelzer: If you have an ABI bump/break and the packages are not renamed, you have a bug in your library.
<cpaelzer> infinity: you remember our discussion on upstream dpdk craziness
<cpaelzer> that is the TL;DR part I meant above
<infinity> Yes, and the conclusion of that conversation was that upstream crazy would not affect us.
<infinity> You have versioned packages for every library.  So, what went wrong?
<cpaelzer> hmm maybe I really need breaks for this special case
<cpaelzer> let me try to summarize
<infinity> You don't need Breaks yet until you can explain why this isn't working as-is. :P
<cpaelzer> hehe
<cpaelzer> some of the libraries got abi bumps and thereby new package names
<cpaelzer> some other sublibs did not get bumps, so they did not get renames
<infinity> So far, all of this should work.
<infinity> So, what broke?
<cpaelzer> but most sublibs that got a bump, depend on some others that got one
<cpaelzer> what I've seen when reproducing locally it ended up with OVS depending on the old soname and another lib, that other lib depended on the new soname
<infinity> So, uhm.  WTF.
<cpaelzer> I need to start that again locally to get the exact versions, but eventually ldd on ovs ended up referring to BOTH ABI versions
<infinity> Why is librte-cryptodev1 in zesty-proposed as an arch:all package?
<infinity> And libethdev4
<infinity> And librte-eal2
<cpaelzer> infinity: the old versions are transitional packages to the newer versions
<cpaelzer> yeah that might be the break
<infinity> If those are "transitional" packages, someone very much doesn't understand why libraries have package name to sover mappings.
<infinity> cpaelzer: DO NOT DO THAT EVER. :P
<infinity> If appfoo depend on libbar2, libbar3 is not a replacement.  Thus, you can't have a transitional package.
<infinity> Kinda the whole point.
<cpaelzer> I tihnk in that case I only missed it on a reivew , but yeah that is it
<cpaelzer> I'll tackle that
<infinity> If those transitionals go away, then the tests will pull in the right libs, and it should all work.  If that remains untrue, you have an undeclared ABI break somewhere.
<infinity> (And when they go away in the packaging, you'll need to ask an archive admin to remove the NBS cruft from -proposed)
<infinity> cpaelzer: ^
<cpaelzer> infinity: yeah thank you
<cpaelzer> infinity: can we remove them right away until ther is a fixed upload available?
<infinity> cpaelzer: I'd prefer not to.
<infinity> cpaelzer: In that I want to make sure the fix is correct, by seeing britney tell me that you no longer build X/Y/Z package.
<infinity> cpaelzer: They do no harm sitting in proposed.
<infinity> (I'd be more concerned if there was a similar issue with -dev packages, and thing were being misbuilt, but that doesn't look to be the case)
<cpaelzer> infinity: but when I want to verify that a fix in a 16.11-1ubuntu2 helps it will still find and consider the bad trnasitional packages
<cpaelzer> infinity: but I'm fine pinging to clean up once there is a new upload
<infinity> cpaelzer: Also, please apply a verbal ruler to the knuckles of whoever did this.  It displays a pretty fundamental misunderstanding of why library package names are versioned, so it would be nice to make sure they "get it".
 * cpaelzer goes away to clean up and to sort out if he punches himself or others
<cpaelzer> thanks infinity
<infinity> cpaelzer: Yeah, upload, wait for binaries, ping for removal of cruft, rerun tests, verify in the logs that the tests didn't pull in stuff from the bad version, (hopefully) win.
<infinity> Score a win for autopkgtest finding real bugs, though.
 * sarnold hangs his head
<sarnold> score a loss for sarnold for looking for the 'lets fix it quick' answer
<infinity> sarnold: Standard bug reporting practice: Start from the problem (updating dpdk breaks openvswitch) rather than the proposed solution (update both together), and then hunt down the "why".
<infinity> sarnold: Alternately, be a jaded jerk like me and just start from the assumption that someone's done something wrong (I don't recommend this method, it's a bitter and lonely world view).
<sarnold> infinity: <3
<cpaelzer> once asking here the assumption that something is wrong is mostly true
<cpaelzer> and better pointing out old mistakes to make a good fix than sneaking by
<sarnold> infinity: I think my mistake was starting with the unsaid assumption that a new feature wasn't being tested as expected vs existing stuff broke..
<zul> doko: ping can you have a look ath python-os-xenapi, python-tinyrpc, and python-marathon please?
<doko> zul: sorry, forgot about that from yesterday
<zul> doko: no problems
<coreycb> doko, can you also take a look at neutron-lbaas-dashboard please?  that would cover everything in the new queue for us in openstack!
<hikiko> hey :) @packagers: https://bugs.launchpad.net/ubuntu/+source/libsoxr/+bug/1658318 there's a bug in this package the fix is 1 line (on sid it's ok) could you get a look?
<ubottu> Launchpad bug 1658318 in libsoxr (Ubuntu) "libsoxr is built with debug flags and prints too much stderr info" [High,New]
<seb128> hikiko, hey, seems like you have a clue what to change, you could perhaps try to see if you can get the package source and provide a patch to sponsor?
<seb128> hikiko, in fact seems it bug #1649224 and fixed in zesty so should be easy enough to backport the patch if you want to have a try
<ubottu> bug 1649224 in libsoxr (Ubuntu) "Package compiled with DEBUG flag" [Undecided,Fix released] https://launchpad.net/bugs/1649224
<doko> zul: done
<zul> doko: thanks
<zul> doko: tinyrpc as well?
<hikiko> seb128, to be honest I don't know how to backport it that's why I only reported it, are there any instructions?
<seb128> hikiko, you never backported a patch from e.g a devel compiz to a stable one?
<seb128> hikiko, basically apply the diff/commit to the stable codebase the same way you would do for the current one
<hikiko> no :) I submit the code on trunk and then Marco decides what to backport :p
<seb128> interesting
<Laney> hikiko: https://anonscm.debian.org/cgit/pkg-multimedia/libsoxr.git/commit/?id=3e438f41361a533fdefdd270b0326398592fa47b <- probably need to apply that diff
<seb128> I suggest that's something you should get familiar with then ;-)
<hikiko> yep
<hikiko> I agree
<hikiko> +all that SRU stuff that sounds chinese to me :)
<hikiko> Laney, https://launchpadlibrarian.net/300174877/libsoxr_0.1.2-1_0.1.2-2.diff.gz
<hikiko> I think there's already a diff in launchpad
<seb128> hikiko, read https://wiki.ubuntu.com/StableReleaseUpdates
<hikiko> shouldn't I apply that?
<seb128> hikiko, SRUs tend to focus on just applying the strictly required changes so you probably just want the part Laney gently pointed out doing the work for you ;-)
<hikiko> ok ok give me a few minutes to read all that
<seb128> hikiko, if you have any question let me know
<hikiko> thanks seb128
<xnox> barry, it looks like armhf (lxd on arm64?!) runners are setup differently to the s390x (lxd on s390x) runners
<xnox> e.g. s390x is sufficiently good to pass docker.io smoke-test; but armhf is not.
<xnox> E: Cannot install into target '/tmp/tmp.IjgK7JuH0D' mounted with noexec or nodev
<xnox> on armhf; which is not seen on s390x.
<xnox> see this: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2430/zesty/armhf/d/docker.io/20170201_115223_319e7@/log.gz
<xnox> and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2430/zesty/s390x/d/docker.io/20170201_114941_319e7@/log.gz
<hikiko> seb128, https://code.launchpad.net/ubuntu/+source/libsoxr/+all-branches there's no xenial package here :s
<hikiko> sorry found :)
<seb128> hikiko, work from the source package and debdiff, http://packaging.ubuntu.com/html/traditional-packaging.html#
<coreycb> doko, i tagged the glanceclient bug as verification-done.  kombu is fix-released now.
<seb128> hikiko, UDD is not used much anymore, just read that page it explains what you need
<barry> xnox: interesting.  i'll look more closely in a bit
<xnox> barry, thanks. Would be nice to make "armhf" more like "s390x" then docker.io smoke-test would pass there too
<zul> doko: can we get them out of binary new as well?
<CRogers> Hi folks. :)
<CRogers> I was wondering if there are plans to remap alt-drag window moving to Super-drag.
<CRogers> It interferes with all the creativity tools. Every single one of them.
<CRogers> So it's really crippling to new users.
<CRogers> With only a few exceptions, I think all wm actions should be mapped to use the super key.
<CRogers> so they do not clash with application hotkeys.
<CRogers> The only exceptions being alt-tab and alt-shift-tab
<CRogers> Because of cross-platform compatibility.
<doko> coreycb: does neutron-lbaas-dashboard have a python3 port?
<doko> anyway, accepted
<Laney> gah at full /boot
<Laney> xnox: barry: Looks like mknod works for lxc but not lxd - that much reproduces locally
<Laney> i.e. you can debootstrap in the former but not the latter ootb without any special autopkgtest setup
<xnox> oh, armhf runners are lxc based, instead of lxd?
<Laney> yes
<xnox> horum.
<Laney> no
<Laney> the other way around
<xnox> s390x is lxd for sure.
<Laney> wrong
<xnox> bah
<barry> yeah, i thought they were lxd also
 * xnox wants scalingstack all the things
<Laney> nope
<Laney> they're lxc
<Laney> you can see that near the top of the log
<barry> yep, i see that now
<barry> wait
<barry> "lxd -r lxd-armhf-10.43.44.70 lxd-armhf-10.43.44.70:autopkgtest/ubuntu/zesty/armhf
<barry> autopkgtest [11:47:12]: @@@@@@@@@@@@@@@@@@@@ test bed setup"
<barry> so armhf lxd; 390 lxc
<Laney> yes
<Laney> and that corresponds with what can do debootstrap here too
 * barry wonders what stgraber thinks about that difference
<barry> Laney: do you know why the two don't use the same thing?
<stgraber> barry: LXD is safe by default, LXC isn't
<xnox> possibly because lxd cloud images for s390x were not yet published when pitti setup adt runners
<stgraber> LXD uses unprivileged containers, LXC runs as real root in the container. And you can't mknod as an unprivileged user as that'd be a straight escalation to real root and escaping the container.
<barry> xnox: could be, could be.  if they're published now, it might make sense to switch s390x; seems like we'd want to reduce the environmental differences between the different architectures as much as possible (env differences are hard to discover magic)
<stgraber> if you don't care about that kind of security (and it may well be that you don't), then setting security.privileged=true for your LXD container should give you roughly the same behavior as LXC
<Laney> barry: s390x runs on some random static machines
<Laney> It's not in the cloud
<xnox> barry, i'd rather keep s390x as it is; until bos02 is up and we move it to kvm instances off scalingstack.
<barry> xnox, Laney i'd be inclined to add isolation-machine to docker.io's basic-smoke test in d/tests/control
<xnox> barry, i removed it, such that the test is run on s390x and passes.
<xnox> barry, the test passes and would have caught regression of us shipping docker.io into xenial-updates which could not launch any container =)
<xnox> barry, also note that currently docker-in-lxd test case is broken too, and I believe it is one of our features to support docker inside lxd.
<xnox> barry, i wonder if I can tweak the smoketest to pull/download a container rather than debootstrap it.
<xnox> (ibm noticed and it was kind of embarrassing)
<Laney> It reproduces perfectly well locally on your x86 system, so go wild :-)
<xnox> true.
<barry> xnox: yeah, that seems like a good thing to try.  my only question is whether that should be the same basic-smoke test or a copy of it, and whether it should try to do debootstrap if it can (i.e. not deviate too much from debian for the existing test, but add another test that would pass on armhf, since that could be pushed up into debian)
<lamont> should I be able to do-release-upgrade -d to zesty ?
<slangasek> yes
<xnox> and check that update-manager config file specifies non-lts releases as viable options.
<xnox> Prompt=normal in /etc/update-manager/release-upgrades
<bdmurray> xnox: Do you still have plans to work on bug 1651623? I'd like to turn on crash reporting to LP for Zesty.
<ubottu> bug 1651623 in apport (Ubuntu Yakkety) "adt tests fail on zesty for apport" [Undecided,New] https://launchpad.net/bugs/1651623
<xnox> yes, i do
<bdmurray> hmm, maybe I should have been more specific. ;-)  soon?
<xnox> yes. it did slip January target now, which is sad.
<lamont> it complains that htere is an unresolvable issue in calculating the upgrade... what file or options do I want to feed it?
<lamont> slangasek: ^^
<bdmurray> lamont: look at /var/log/dist-upgrade/main.log or apt.log
<bdmurray> lamont: or use ubuntu-bug ubuntu-release-upgrader and I can have a look at the logs
<lamont> that sounds best, since my next question was "what am I looking for in the logs..." :/
<bdmurray> lamont: I've got an errand to run, but let me know the bug and I'll look when I get back.
<lamont> bdmurray: it's still churning.  I'll toss you the bug number whne I get it
<lamont> bdmurray: specifically, bug 996916
<ubottu> bug 996916 in update-manager (Ubuntu) "postgresql packages in the removal blacklist making it hard to upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/996916
 * lamont purges postgresql-9.5 and postgresql-common and tries again
<lamont> bdmurray: and then also removing postgresql-9.5-postgis-2.2-scripts and postgresql-9.5-postgis-scripts made for a happier upgrade
<halvors> Hi!
<halvors> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1634855
<ubottu> Launchpad bug 1634855 in systemd (Ubuntu) "Assertion 'link->state == LINK_STATE_SETTING_ROUTES' failed at ../src/network/networkd-link.c:697, function link_enter_configured(). Aborting." [Critical,Confirmed]
<halvors> I'm experiencing this bug, and i wounder if there is a developer online.
<halvors> A developer or maintainer that can backport the fix from upstream systemd.
<halvors> This causes a lot of issues since basically if the link goes down for a moment, the whole network stack crashes.
<rbasak> networkd isn't default, is it?
<rbasak> halvors: see https://wiki.ubuntu.com/StableReleaseUpdates and https://wiki.ubuntu.com/SponsorshipProcess. If you can attach debdiffs to the bug for Zesty (if applicable) and Xenial, follow the SRU procedure and subscribe ~ubuntu-sponsors, somebody will able to process it through the sponsorship queue.
<halvors> No it's not. But it's used a lot since the "ifupdown" package is unreliable when it comes to newer network technologies that is not supported by it.
<halvors> Also Ubuntu as far as i know is moving towards systemd-networkd.
<rbasak> Sure, it's a bug and we should fix it. But it's hardly Critical.
<nacc> iiuc, already fixed in z and y (by virtue of upstream version)
<halvors> rbasak: Yeah. Anyone here knows how to do a backport with diffs?
<halvors> And are willing to do it?
<nacc> rbasak: ntfs-3g and snapd failed to import, could you take a look at why that might have happened?
<rbasak> nacc: where do I look?
<nacc> rbasak: try to run the importer locally :)
<nacc> rbasak: on those src pkgs
<rbasak> Ah, of course. Thanks :)
<nacc> rbasak: np, just got a report of a few failures (first in a while) in the importer report to the list and i'm heads-down on the iscsi stuff
<zul> doko: when you get a chance can you review python-murano-pkg-check
<nacc> rbasak: is LP: #1661092 also what makes ntfs-3g fail?
<ubottu> Launchpad bug 1661092 in usd-importer "Import fails when debian directory is a symlink" [High,Triaged] https://launchpad.net/bugs/1661092
<nacc> rbasak: and thanks for tracking that down :)
<rbasak> nacc: no, ntfs-3g is a separate failure.
<rbasak> I think it's a parent determination problem.
<rbasak> It didn't use the parent in the proposed pocket when importing the release pocket.
<rbasak> After that parenting is correct.
<rbasak> But the result is that ubuntu/yakkety-devel is non-fast-forwarding
<rbasak> I don't see any obvious reason for that from the DAG alone.
<nacc> hrm
<nacc> rbasak: ok, this *might* be a case of ntfs-3g having been imported with an older version of the importer
<nacc> rbasak: could you do a run with -o baz or whatever and see if it does use y-p properly (with --no-push --no-clean i suppose)
<rbasak> nacc: can do, but I see nothing wrong with the current state.
<nacc> rbasak: well, other than y not using y-p as a changelog parent
<nacc> rbasak: as, iiuc, that version should have already been imported to y-p when the publish to y was found
<rbasak> Ah. I hadn't seen that.
<nacc> it might have been imported by a buggy importer (there was some churn a while ago wrt the changelog parent)
<nacc> right, so on lp, y-d points to y-p (1:2.016.2.22AR1-3), but the importer is moving it to y-u, which has has parents (going backwards), y-s, and y, and since y does not have y-p in its ancestry, the ff failed.
<nacc> i wonder if we should switch the devel pointers from branches to refs
<nacc> i'm not entirely sure they are guaranteed to be ff generally
<nacc> symbolic refs, that is
<rbasak> I see
<rbasak> You mean symbolic refs?
<rbasak> Or generic refs with no particular type?
<nacc> yeah, then we could just move them as we update where they point to (the 'latest' published version in a series)
<nacc> it would break existing imports, though, i guess
<nacc> i guess we could delete the branches and create the refs, possibly
<rbasak> Yeah. Or just delete the branches and re-run the importer on everything?
<nacc> right
<nacc> that's true, it'd 'fix' them all up
<rbasak> I suppose, because of the security trumping proposed thing, logically the devel pointers (or branches or whatever they are) _can't_ be fast forwarding.
<nacc> well, first step is seeing if the importer is 'correct' if started fresh, at least for src:ntfs-3g, then we can decide how best to proceed
<rbasak> Unless we create another parent to make it so.
<nacc> rbasak: right, that's the reason, i agree
<nacc> rbasak: they really are meant to just be references, i think -- just shortcut names
<rbasak> I can see how a user might expect to follow a -devel branch though.
<nacc> rbasak: yeah, i agree -- we probably need to have a think about it
<doko> zul: MIRs approved. one lacking a python3 package
<doko> zul: will do the other NEW review tomorrow
<nacc> doko: if it'd be easier to review the ldb changes / questions, I can send e-mail with a debdiff (I realize the git tree may not be the most clear necessarily)
<doko> nacc: sorry. yes, then the chance is lower that I forget about it :-/
<nacc> doko: np! thanks :)
<rbasak> nacc: re-importing all of ntfs-3g works. Is that because yakkety-devel is only set at the end?
<nacc> rbasak: in that import, does y have y-p has an ancestor?
<jgrimm> nacc, when you get a moment can you import python-boto? does not seem to be auto imported yet
<nacc> jgrimm: running
<jgrimm> nacc, thanks, maybe moin too while you are at it?
<nacc> jgrimm: also running
<jgrimm> :) you rock!
<nacc> jgrimm: python-boto is done
<jgrimm> nacc, i saw thanks.  i'll watch for moin, no need for you to poll
<nacc> jgrimm: ok, np
<foli> This it to notify the we are beginning maitenance on Canonical data centre firewalls.
<jgrimm> thanks foli
* ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 00:00 UTC | Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
<rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
<rbasak> git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
<rbasak> nacc: git merge-base --is-ancestor lpusip/ubuntu/yakkety-proposed lpusip/ubuntu/yakkety && echo yes || echo no
<rbasak> I'm sorry. I was scrolled up. Thought it wasn't pasting.
<rbasak> Anyway, the answer was "no".
<rbasak> I pushed to lpmep:ntfs-3g
<nacc> rbasak: ack, will look
#ubuntu-devel 2017-02-02
<foli> The Canonical data centre firewall maintenance is done now.
<sarnold> thanks foli :)
* ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<pitti> xnox, stgraber, barry: a bit complicated -- we must use lxd for armhf as we run them on arm64 cloud instances and need the "remote" feature; and s390x isn't in scalingstack yet, so we only have that old setup
<pitti> but there is no principal reason why s390x couldn't move to lxd
<pitti> (i. e. that's just historical)
<wgrant> pitti: You could also use actual armhf nova instances, though it's not quite as simple.
<pitti> wgrant: I played around with direct kernel boot some time ago, but back then there were still some bugs/config issues that broke that
<pitti> if it works now, that'd be nice of course, we could run kernel tests
<pitti> but anyway, s390x was promised to get into scalingstack, so I never bothered to move them to lxd
<wgrant> pitti: Yep, it's happening Soonâ¢.
<rbasak> mapreri: I know you're waiting on inkscape PPU. Is there anything else for you still pending?
<rbasak> I have an action "rbasak to get mapreri's PPU additions done by the TB" but the TB has already done sbuilder and libreoffice-dictinataries I see. I'm not sure if there's anything else.
<mapreri> rbasak: No other requests pending, thanks.  (OTOH I wonder whether, given the apparent complexity of getting such rights I should ask also for the other 2 packages that I maintain which are in main, "just because" and without any particular need)
<rbasak> mapreri: now that I understand it takes only one DMB member, it's one DMB approval and one TB action. We're also working on smoothing the DMB request -> TB process.
<mapreri> That's my perception now too.
<tsdgeos> sil2100: can you click https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=i386&package=unity8&trigger=unity8%2F8.15%2B17.04.20170131.1-0ubuntu1 (unity8 rebuild) for us?
<sil2100> tsdgeos: sure
<tsdgeos> sil2100: appreciated :)
<mapreri> rbasak: btw, "Is the DMB asking for too much from applicants before granting core dev and/or MOTU?" => No, the requests are just fine, don't reduce them.
<tsdgeos> got bunch of flacky tests
<mapreri> (imho)
<mapreri> That just a so weird corner case.
<sil2100> Test request submitted. <- yw ;)
<tsdgeos> rbasak: not sure if totally related to your case or not, but it's also a bit "weird" that I as an employee unity8 developer can submit unity8 in bileto to land and it will land, but if like now a flacky test fails, i can't press the "retry" button
<mapreri> tsdgeos: Isn't that a case already covered by PPU?
<mapreri> Is just that you're not going to upload directly to the archive because you have your own "deployment" pipeline
<rbasak> tsdgeos: that's solely an ACL issue I think. Technical, not organisational.
<rbasak> tsdgeos: perhaps bileto should grow a feature to allow you to do that.
<tsdgeos> mapreri: maybe, if i knew what PPU means :D
<tsdgeos> rbasak: that makes some sense i guess
<mapreri> tsdgeos: => that's probably a sign that you shouldn't apply for that then :) - (and instead autopkgtests/bileto grow something)
<tsdgeos> i'll try to talk to robru
<mapreri> tsdgeos: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders
<mapreri> (FYI)
<tsdgeos> mapreri: tx, i tried googleing for it and only could find people's wiki/applications for it
<rbasak> stgraber: thank you!
<rbasak> mapreri: you should be done.
<mapreri> \o/
<mapreri> rbasak: thank you!
<mapreri> rbasak: FYI, I'm subscribed to the tech board ML.
<Mirv> xnox: umbrello against s390x seems to be in infinite loop http://autopkgtest.ubuntu.com/running#pkg-umbrello eg against my qtbase-opensource-src-gles/5.7.1+dfsg-2ubuntu3~2 it has started over numerous time without anyone specifically triggering it. so it's always left at "Test in progress" http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles
<Mirv> I've seen the Running for time being reset today least three times
<xnox> Mirv, fun. However I don't have access to the infra. Try Laney and/or barry
<Mirv> xnox: thanks for highlighting.
<xnox> no problem.
<Laney> mmm
<Laney> <VirtSubproc>: failure: (down) ['cp', '-r', '--preserve=timestamps,links', '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/umbrello-16.12.1', '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/build.8Xe/umbrello-16.12.1'] failed (exit status 1, stderr "cp: error writing '/data/adttmp/autopkgtest-virt-lxc.shared.2l76ah7r/downtmp/build.8Xe/umbrello-16.12.1/obj-s390x-linux-gnu/unittests/testpythonwriter': Cannot allocate memory\n")
<Laney> Feb 02 00:41:08 aupkg01 kernel: cp invoked oom-killer: gfp_mask=0x24000c0, order=0, oom_score_adj=0
<Laney> wtf
<pitti> Laney: must be a helluva file :)
<Laney> pitti: it passed before a few times http://autopkgtest.ubuntu.com/packages/u/umbrello/zesty/s390x
<Laney> :(
<zul> doko: ping python-murano-pkg-check?
<ricotz_> why is 15.04/Vivid still marked as support on launchpad?
<mdeslaur> ricotz_: it's used by the phone, if we deactivate it on launchpad we can't build packages for the phone anymore
<ricotz_> mdeslaur, I see, quite a weird situation then
<mdeslaur> ricotz_: yes, launchpad needs to be fixed to be able to mark a release as unsupported without deactivating it
<mdeslaur> ricotz_: but this was only supposed to be temporary
<ricotz_> mdeslaur, ok, but one should not be able to build things for it in random ppas/recipes
<cjwatson> We don't really mind hugely if people can.
<jgrimm> rbasak, thanks for pointing out test log history, indeed dogtag-pki has been failing for long time, unrelated to merge. http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/amd64
<nacc> jgrimm: right it's realted to tomcat, iirc
<nacc> jgrimm: and 'known'
<nacc> tjaalton: --^ iirc was looking at it
<greyback> Hi folks, migration of https://bileto.ubuntu.com/#/ticket/2404 from proposed failed again, we've a single flaky test on i386. It's something we've struggled to fix, as we can't reproduce it anywhere except on britney
<jgrimm> nacc, cool thanks.. context was that it showed up in the list of regressions on latest nspr upload
<jgrimm> nacc, good to know what its actually attributed to tho!
<nacc> jgrimm: right, probably unrelated
<jgrimm> thanks sir
<barry> doko, caribou o/
<caribou> barry: doko: o/
<caribou> barry: doko: to summarize, trusty & xenial builds using the release's gcc don't show any sensible differences
<caribou> (trusty & xenial builds in a schroot using the release's gcc)
<barry> caribou: that's very interesting, and mostly what i'd expected.  i just couldn't find any upstream python change that could have affected performance (but there are a lot of changes between .6 and .12)
<caribou> I'm now re-running the initial tests (i.e. using the latest gcc in trusty/xenial) to verify the previous round of tests
<caribou> doko: the only compiler difference I noticed b/w trusty's 4.8 and xenial's 5.3 is the addition of -fstack-protector-strong in Xenial
<caribou> and -Wdate-time but that shouldn't matter
<doko> caribou: what is "release's gcc"?
<caribou> doko: the one in trusty/main (not the one in -updates or -security)
<doko> ta
<caribou> doko: barry:  I'll let you know once I get the new set of results (most probably tomorrow)
<barry> caribou: cool.
<Laney> Mirv: xnox: I reverse engineered pitti and now umbrello passes :-)
<xnox> Laney, can you clone or fork pitti too?
<Laney> I think only his wife has that CAP
<xnox> latency is too large on that CAP
<tjaalton> jgrimm, nacc: yes, tomcat 8.5 broke dogtag, and is blocking a lot of updates. 8.5 should be removed from proposed and blocked for now
<nacc> tjaalton: i assume we need an AA to do that?
<tjaalton> yep
<jgrimm> tjaalton, thank you!
<GunnarHj> bdmurray: Thanks for approving my yakkety upload at bug #1655036! Any chance you have a couple of minutes to sponsor the xenial debdiff at that bug? xenial is more important, and I don't have the permission yet.
<ubottu> bug 1655036 in im-config (Ubuntu Xenial) "HIME rc doesn't assign QT_IM_MODULE, breaks usage in Qt5 application" [Medium,In progress] https://launchpad.net/bugs/1655036
<GunnarHj> https://lists.ubuntu.com/archives/devel-permissions/2017-January/001014.html
<bdmurray> GunnarHj: I left the tab open and will try and do it today
<GunnarHj> bdmurray: Thanks, crossing my fingers. :)
#ubuntu-devel 2017-02-03
<nacc> slangasek: would you have a moment for a question about image (cloud-images specifically, but I think generic) generation?
<slangasek> nacc: sure, maybe I can answer wrt cloud images :)
<sarnold> better hurry though with this wind who knows how much longer our internet cables will hold up
<nacc> slangasek: :) -- so I'm working on curtin iscsi support and at the same time hoping to resolve LP: #1444992. I *think* the underlying issue is that we (well, the open-iscsi package) generates the initiator name at pkg install time (due to LP: #1057635). But for the cloud image, since open-iscsi is seeded in server (I think this is why?) it's configured at image creation time (effectively).
<ubottu> Launchpad bug 1444992 in MAAS "fastpath install duplicates iSCSI initiator names, blocking iSCSI HW" [High,Triaged] https://launchpad.net/bugs/1444992
<ubottu> Launchpad bug 1057635 in Ubuntu Quantal "initramfs built during install does not contain a valid iscsi initiator name" [High,Fix released] https://launchpad.net/bugs/1057635
<slangasek> nacc: yes, that sounds accurate to me
<nacc> slangasek: and what i'm trying to understand, given i don't know much about the image creation process, is what are possible fixes? My initial thought is to change the image creation tooling to undo the change from the second bug and set the intiatior name back to Generated=yes
<nacc> slangasek: but, given that the package is present always, do we need to worry about churning through all the random strings that are used (aiui, generated has a fixed prefix (from Debian) and then a suffix of some number of characters)
<slangasek> nacc: the image build process can have post-processing of the image contents to do things like removing or editing the config file; if you look at the init script you'll see that it will auto-generate the initiator name on first run if it doesn't already exist
<slangasek> (he says, having for some reason looked at this package recently)
<slangasek> nacc: so basically, adjust the rules in livecd-rootfs to rm /etc/iscsi/initiatorname.iscsi
<nacc> slangasek: hrm, on my reading of startup-checks.sh, though, if that file doesn't exist, it just errors out? (this is a ExecStartPre for iscsid.service)
<nacc> slangasek: maybe i'm looking at the wrong init script?
<slangasek> nacc: hmm double-checking
<slangasek> nacc: ah right, you need to actually set GenerateName=yes in that file
<nacc> slangasek: ack, that is my read of it as well
<nacc> slangasek: i'll take a look at livecd-rootfs
<nacc> slangasek: is it just me or is live-build/ubuntu-cpc/060-ipv6.chroot about to break for z+1 (and technically is already wrong but unaffected probably by warty < trusty?) Just getting my head around the src pkg :)
<slangasek> nacc: hngh
<slangasek> nacc: you are not incorrect
<mwhudson> ah haha
<mwhudson> i wonder how much of the 17.10 cycle is going to be finding all of those
<nacc> mwhudson: :)
<nacc> slangasek: iiuc, then, would it be so straightforward as adding an iscsi hook? which basically does `echo GenerateName=yes > /etc/iscsi/initiatorname.iscsi`?
<slangasek> nacc: should check for existence before overwriting, but yes
<slangasek> mwhudson: well, cdimage was future-proofed quite some time ago :P
<mwhudson> slangasek: because warty > breezy?
<nacc> slangasek: ack
<mwhudson> slangasek: i'm sure no code with new assumptions has been added in the last 12 years or so
<bswartz> hey ubuntu guys, I'm trying to upload a package to a PPA I just created, and it said "Successfully uploaded packages." but there's still nothing on my PPA
<jgrimm> bswartz, did you check your email as possibly got rejected while actually processing the upload
<bswartz> jgrimm: ty! I just checked my email and it was rejected
<jgrimm> bswartz, you should get a rejection/success email
<jgrimm> bswartz, cool
<bswartz> didn't know it sent email responses
<bswartz> jgrimm: I was able to upload my package but when I try to apt-add-repository on my own PPA it fails with "Error: signing key fingerprint does not exist"
<bswartz> oh maybe that's because the build of the package is pending still
<bswartz> I'll try again after this build completes
<sarnold> indeed that's possible, if this is the first package build in your ppa; I think launchpad creates the keys -after- a package has successfully built
<bswartz> darn the package built successfully but I'm still getting the "Error: signing key fingerprint does not exist" error when trying to add the PPA
<bswartz> google saves me again -- I had to run "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ...."
<sarnold> ewwww
<sarnold> probably waiting ten minutes was the real solution
<tsimonq2> (either way, DuckDuckGo FTW :P)
<cjwatson> mwhudson: warty/breezy was still in the era of special-casing for everything; the serious future-proofing was much later
<cjwatson> mwhudson: (I did most of it when rewriting the whole thing in Python)
<fossfreedom_> andyrock: quick question - did you manage to discuss our (Ubuntu Budgie) gnome-menus merge-proposal with seb128 ? TIA  https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1631745
<ubottu> Launchpad bug 1631745 in gnome-menus (Ubuntu) "Ubuntu Budgie - panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress]
<GunnarHj> rbasak: I just uploaded to xenial successfully, so the fix of my packageset seems to be fine. Thanks!
<rbasak> GunnarHj: great! Sorry it took so long.
<rbasak> I think my DMB queue is now clear \o/
<mitya57> Can someone please mark monkeysign failures as ignored? I.e. on i386 it passed only one time of 19, according to http://autopkgtest.ubuntu.com/packages/monkeysign/zesty/i386.
<mitya57> And it is the last package that blocks sphinx migration.
<rbasak> I can't (no ACL bit) but sphinx migration \o/
 * rbasak had something blocked on that but can't remember what :-/
<mitya57> Laney, ^^ are you the right person to ask about this?
<mitya57> rbasak, by the way I don't see anything that depends on Sphinx on the proposed-migration page.
<mitya57> Maybe you are talking about sphinx-the-speech-engine, not sphinx-the-doc-generator? :)
<rbasak> No it was the doc generator. It's an FTBFS with the old sphinx that builds successfully in Debian. With the new sphinx, I'm hoping it'll work.
<rbasak> Though, the new sphinx is in proposed already, and we build against that already.
<rbasak> So perhaps finishing the transition won't help.
<rbasak> I wish I could remember what package it was.
<mitya57> rbasak, in case you remember it, please let me know â I want to make sure all packages can build against both 1.4 in Debian and 1.5 in Ubuntu.
<rbasak> Will do.
<andyrock> fossfreedom: I forgot tbh
<andyrock> and seb is likely travelling to fosdem
<fossfreedom_> andyrock: ah.  ok - thanks for the info.
<andyrock> sorry about that
<fossfreedom_> andyrock: yeah - sorry to be persistent - this bug is kind of a show-stopper for us :/
<barry> i guess bitlbee now hijacks port 6667 via systemd :/
<enyc> barry: hhahahah
<enyc> barry: devuan to the rescue?
<barry> enyc: systemctl start emacs.service
<GunnarHj> bdmurray: Re that im-config bug: rbasak fixed my permissions, and since you didn't do it yesterday, I uploaded it myself a couple of hours ago, so now there is a duplicate... Sorry, should have made a note on the bug report.
<bdmurray> GunnarHj: or unsubscribed the sponsors team. ;-)
<GunnarHj> bdmurray: Actually I did that.
<bdmurray> GunnarHj: oh, maybe I should have refreshed that tab
<GunnarHj> bdmurray: ;)
<bdmurray> cjwatson: You have some familiarity with debmirror right?
<cjwatson> bdmurray: I do, but I'm about to go away for the weekend so now isn't the best time
<bdmurray> cjwatson: Okay, its not a big deal but if you could look at bug 1658203 sometime that'd be nice.
<ubottu> bug 1658203 in debmirror (Ubuntu) "debmirror isn't mirroring trusty's Contents-*.gz files" [Undecided,New] https://launchpad.net/bugs/1658203
<cjwatson> I suspect it's because trusty didn't list Contents in Release
<cjwatson> or at least related to that
<dobey> is there a way to use globs with seeded-in-ubuntu?
<sarnold> if you need to build an ugly script you might find apt-cache pkgnames helpful
<dobey> no, i just want to see the seed list for a set of packages
<dobey> ie indicator-*
<dobey> from source packages, that is
<nacc> rbasak: heh, fun issue with the importer / cron, if launchpad hiccups during one of its connections, something (presumably launchpadlib, but i'm not sure) doesn't seem to notice and just hangs ... so when we had the fw maintenance earlier, the importer got stuck (but didn't crash)
<nacc> jgrimm: --^ fyi, that's why openvpn hadn't picked up the new version yet, i just restarted the script
<jgrimm> nacc, aha! ok
<nacc> jgrimm: it might take the importer a bit to catch back up, but it should relatively soon
<jgrimm> nacc, no worries at all.  plenty of other work i can pivot to
<rbasak> nacc: wrap the cron with a timeout command perhaps?
<rbasak> timeout -k60 3600 usd ...
<jgrimm> nacc, thoughts on how to rebase my current work to newer/debian?
<jgrimm> not that its that hard to start over, its all pretty minor
<nacc> jgrimm: ack, so i *think* the simplest way is
<nacc> git checkout <your branch/ref/whatever>
<nacc> git fetch lpusip
<nacc> <presuming it updates the debian/sid branch>
<nacc> git rebase -i lpusip/debian/sid
<nacc>  ... drop the merge-changelogs, reconstruct-changelog, update-maintainer bits
<nacc> then re-run those steps, except for merge-changelogs you'll need to pass
<nacc> git merge-changelogs old/debian old/ubuntu lpusip/debian/sid
<nacc> and correspondingly
<nacc> git reconstruct-changelog lpusip/debian/sid
<nacc> alternatively to all that :) you can probably checkout ubuntu/devel again, and run `usd merge -f --tag-only`
<nacc> e.g, `usd merge -f --tag-only ubuntu/devel lpusip/debian/sid`
<jgrimm> heh, i'll give those a try on monday.. brain at EOW sluggishness
<jgrimm> nacc, thanks!
<nacc> jgrimm: you're basically doing a normal git-rebase at this point
<nacc> it would be good to test, actually, i think the merge-changelogs step might 'just work' (with fuzz/offsets)
<nacc> as in, you don't need to drop it
<nacc> but reconstruct will fail, as it wont' find the right context (or it'll put it somewhere below the top of the file)
<nacc> udpate-maintainer will probably carry-forward, though
<jgrimm> right, this'll be an interesting test / good exercise
<jgrimm> nacc, '> - While it's not wrong by any means to have a carry-forward and revert of
<jgrimm> > the CVE delta, it does mean that the next merger has to think a bit about  '
<jgrimm> nacc, I agree.. though we may want to recommend 'edit' instead of pick on the rebase to new/debian
<jgrimm> nacc, as otherwise it clean rebases something you intend to drop (which is how i got there)
<nacc> jgrimm: oh i see
<nacc> jgrimm: hrm, well if you first squash those and commit an empty-commit
<nacc> jgrimm: it should result on rebase in it being dropped
<jgrimm> yes, i could easily fix it .. was following the docs
<jgrimm> nacc, indeed -> squash and empty-commit would work as well
<nacc> jgrimm: ack, it's on my todo list to update more use cases on the wiki for stuff like this
<nacc> recommended practices for changing delta, for dropping delta, etc.
<jgrimm> nacc, it was a great observation, so thank you for seeing that
<wxl> anyone here that can help sponsor a bugfix upload of konversation in yakkety? debdiff's big but that's because it includes translations. https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/1635911
<ubottu> Launchpad bug 1635911 in konversation (Ubuntu Yakkety) "Konversation crashes on quit - please package latest version" [High,Triaged]
<sarnold> 578 KB debdiff for what looks like a _one line_ fix? ouch
<sarnold> are you sure the translation changes are needed? I only inspected a hansdful but most looked like they were updating comments
#ubuntu-devel 2017-02-04
<wxl> they're not necessary, i guess, sarnold
<wxl> they're really for AppData
<wxl> which may explain their strange nature
<sarnold> I can't really speak for the patch pilots but I can say a 20-line debdiff with one line of code change is a thousand times easier to review :)
<wxl> well, can i just cherry pick that one little change? it's not a "released" version. i dunno.
<lamont> are versioned recommends even a thing?
<slangasek> sure
<slangasek> if you recommend by version, and that version isn't available, it won't be installed by default by apt
<sarnold> "All of the fields except for Provides may restrict their applicability to particular versions of each named package" https://www.debian.org/doc/debian-policy/ch-relationships.html
<lamont> coolness  and if we're configured to install recommends by default, it'll pull in an updated package if so recommended/
<lamont> ?
<slangasek> yes
<slangasek> (maybe)
<lamont> bonus
<lamont> ta
<lamont> I  love it when things do what it seems obvious they should do :D
<sarnold> :)
<xnox_test> xnox: does telegram push notification work?
<xnox_test> totally does excellent.
<xnox_test> xnox: let's test another highlight
<xnox_test> xnox: test
<xnox_test> s390x
<xnox_test> xnox: test
<xnox_test> xnox: hi
<xnox_test> xnox safsfs
<Bluefoxicy> is there an appropriate team to which to assign #1649580
<Bluefoxicy> I don't know if that should be on the Mono team's watch list
<Bluefoxicy> although it's too late for Zesty now
<mapreri> xnox: I have telegram notification for IRC thanks to znc-push (implies that I'm using znc as a bouncer).  What do you use?
<xnox> mapreri, yes, that is what i am trying to set up =(
<xnox> mapreri, unfortunately, it's failing to send me notifications for additional keywords =(
<mapreri> oh
<xnox> (e.g. extra things, other than my nick)
<mapreri> xnox: I use it only for my nick, as nothing else is usually so important to bother me on the mobile
<xnox> mapreri, cool. i'll have to check if it works, so far it was unreliable. If i don't get any notifications next week, i will look into re-setting it up
<mapreri> xnox: I must say for me it's pretty reliable instead :)  (I setted it up quite several months ago and never touched it since)
<Laney> mitya57: anyone on the release team can. looks like you might want to skip this testcase though - the instances can't talk to keyservers (or maybe keyserver.u.c will work)
<Laney> looks like keyserver.ubuntu.com does work from a quick test
<tsimonq2> xnox: :O What wonderful thing did you set up?
#ubuntu-devel 2017-02-05
<anon^_^> had a question, maybe someone with build experience can help
<anon^_^> trying to compile an app, hit the following dependency issue
<anon^_^> checking for intltool >= 0.40.6...  found
<anon^_^> configure: error: Your intltool is too old.  You need intltool 0.40.6 or later.
<anon^_^> http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=intltool
<anon^_^> every intltool-debian package from 12.04 LTS to current is 0.35.0
<wxl> anon^_^: you need intltool, not intltool-debian
<anon^_^> thought that was a dummy package
 * anon^_^ laughs
<SpamapS> anon^_^: 12.04 _is_ pretty old...
<SpamapS> anon^_^: you might look in backports for a newer intltool
<SpamapS> anon^_^: https://launchpad.net/ubuntu/+source/intltool show 0.50 ???
<SpamapS> oh
 * SpamapS should read to the end
<anon^_^> yes
<anon^_^> heh
<anon^_^> I should too
<anon^_^> sorry to bother chan, one other compile question
<anon^_^> configure: error: Package requirements (gmime-2.4 >= 2.4.0) were not met:
<anon^_^> No package 'gmime-2.4' found
<anon^_^> libgmime-2.6-0 is installed
<anon^_^> only package available
<anon^_^> there's additional error output suggesting adjustment of PKG_CONFIG_PATH, GMIME_CFLAGS and GMIME_LIBS, but not sure how to invoke that correctly or if it's needed
#ubuntu-devel 2018-01-29
<mdeslaur> valorie: wait a day and I should appear by itself when we do monday triage
<mdeslaur> it*
<valorie> ok
<tsimonq2> valorie: also I saw that Debian applied these fixes, that might help too
<tsimonq2> s/applied/released/
<valorie> excellent
<tsimonq2> valorie: You might want to point them towards bug 1745635 as it seems to be the tracking bug for this.
<ubottu> bug 1745635 in clamav (Ubuntu) "Security release 0.99.3 available (CVE-2017-12374 CVE-2017-12375 CVE-2017-12376 CVE-2017-12377 CVE-2017-12378 CVE-2017-12379 CVE-2017-12380)" [Undecided,Confirmed] https://launchpad.net/bugs/1745635
<valorie> tsimonq2: thanks for that -- passed along
<cpaelzer> bdrung: hi
<cpaelzer> bdrung: I think smb will do the next iproute2 merge somewhere along kernel 4.15
<cpaelzer> I'm wondering which way to install a file to use
<cpaelzer> dh_install doe sonly want to move, but not rename
<cpaelzer> suggestions are made to dh-exec
<cpaelzer> but I need mv + rename + chmod afterwards
<cpaelzer> should I just go for a few lines in d/rules instead?
<alkisg> Hi, some package in the Ubuntu archive has some security issue (details deliberately omitted) that ends up in all /home/*/.config folders being world-readable. Is it possible to reset that directory to its proper permissions for all users with a package upgrade, or is that prohibited by the Debian policy?
<cpaelzer> alkisg: if it can be safely detected that the reason access is open is the bug in said package an update can fix it up I think
<cpaelzer> alkisg: but otherwise I think it is bad to mess with access controls kind of unconditionally
<cpaelzer> after all people might have set up the same intentionally
<cpaelzer> therfore the "is it safe to detect" question
<cpaelzer> in general LP bugs can be opened private + security which allos discussions on non disclosed security issues
<alkisg> cpaelzer: very nice, where would you put the detect/restore login, in postinst or in an /etc/xdg/autostart script?
<cpaelzer> alkisg: depends too much on the actual issue that caused it to answer, I'd expect a postinst actually
<cpaelzer> as packages could be used on non graphical environments - so xdg/autostart would never trigger
<alkisg> Hmm indeed, although they may also be installed when /home is unmounted :/
<alkisg> Thanks, I think a private+security bug report might be the best place to discuss this
<alkisg> I filed LP: #1745929.
<ubottu> Error: Launchpad bug 1745929 could not be found
<valorie> alkisg: none of use will be able to look at it unless we're part of the security team
<valorie> thanks for doing that
<alkisg> valorie: the package maintainer (I assigned the bug to him) will still be able to see it, right?
<valorie> that I don't know
<Unit193> "Should"
<alkisg> I think I've seen some security issues that were assigned to my packages in the past, so I believe so...
<alkisg> (wrongly assigned to my packages :P :D)
<valorie> I would assume that the maintainer will see the proposed patch at least
<Unit193> My favorite are errors.ubuntu.com bugs, contain no info and just link to a place you can't view details (though to be fair, a quick poke and people usually are very willing to help by pasting stuff into the report.)
<juliank> ugh, systemd-journal uses 100% CPU again.
<juliank> ah / remounted r/o again
<juliank> yay
<Unit193> Why'd you do that?
<Unit193> You're silly.
<juliank> btrfs remounted itself r/o because it was "full"
<juliank> And I'm back.
<juliank> Rebooted, deleted a few snapshots of / and added another 100 MB to the LV it's on
<juliank> now my vg has no free space left :(
<juliank> I'm not sure I like btrfs remounting r/o when it's out of space
<juliank> or journald going insane on CPU usage
<alkisg> Remount-ro on errors sounds sane, 100% cpu, not so much
<juliank> alkisg: well at least it helps you notice the problem!
<alkisg> Haha, an effective way :D
<juliank> jibel: I think I figured u-r-u / bug 1744722 out  https://code.launchpad.net/~juliank/ubuntu-release-upgrader/valid-release/+merge/336761
<ubottu> bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,In progress] https://launchpad.net/bugs/1744722
<juliank> The goal was to check if the entry we are creating is valid. Checking that the dist is a valid toDist seems to be the right thing
<juliank> Rather than just checking if the old entry was a valid old distribution
<jibel> juliank, ok, but actually wouldn't the right fix to change the current entries to old-releases.u.c if it's a valid mirror?
<jibel> then recheck if there is a basemetapackage and proceed with the upgrade
<jibel> nowhere we tell the user that its release is EOL afaik
<juliank> huh
<juliank> Doesn't it look at the meta package for the target release?
 * juliank not sure what it does
<jibel> juliank, let me check again but I don't think so. I does the veirfication before rewriting sources.list
<juliank> In any case this fix seems like a fixed variant of your fix
<jibel> juliank, indeed, sounds good to me
<juliank> jibel: So I'd merge and upload this then. Unfortunately, I don't see how we could SRU that to artful - we need a proper test case for it.
<juliank> If only we had the sources.list
<juliank> jibel: Ah, got a test case
<jibel> juliank, we have the sources.list from the reporter. I'm testing your fix with his list
<juliank> jibel: I added "deb https://dl.bintray.com/aluxian/deb/ stable main" to the test data which causes the problem to occur
<juliank> It then generates deb http://archive.ubuntu.com/ubuntu stable main # auto generated by ubuntu-release-upgrader
<juliank> It's not even that code generating that entry
<juliank> Maybe I just ran the test wrong :D
<juliank> Yeah, it works
<juliank> or not
<juliank> well it also worked before
<jibel> juliank, for the test you need a valid mirror with an obsolete release and an entry with a third part repo eg a ppa
<jibel> third party*
<juliank> jibel: I'm trying to write a test case for it, but I have not found anything that breaks yet
<juliank> It breaks and fixes when I run tests/test_sources_list.py manually, but if I run via nose-tests it works in both cases.
<juliank> the test suite is of course, somewhat broken, as usual.
<juliank> (if you run tests with python-apt, you basically have to run apt_pkg init at least in a setupClass or something)
<juliank> otherwise some state might stick around from other tests
<juliank> Oh, my test case is broken.
<juliank> # deb https://dl.bintray.com/aluxian/deb/ stable main # disabled on upgrade to gutsy
<juliank> is there all the time
<juliank> but before, there also is
<juliank> deb http://archive.ubuntu.com/ubuntu stable main # auto generated by ubuntu-release-upgrader
<juliank> there are a ton of bugs in the test suite because we only check that the expected sources are there, not any unexpected
<juliank> jibel: I added/modified a test case now in https://code.launchpad.net/~juliank/ubuntu-release-upgrader/valid-release/+merge/336761 and verified that it was broken before and passes now
<jbicha> xnox: please open a new bug for your comment at LP: #400573
<ubottu> Launchpad bug 400573 in ubuntu-meta (Ubuntu) "[include in live-cd] wvdial (1.60.1+nmu2)" [Wishlist,Fix released] https://launchpad.net/bugs/400573
<xnox> jbicha, the comment was on purpose, such that people who are subscribed to that bug get the notification. As I was trying to reach them. If there is no responses there for a while, I will be opening a brand new bug to "demote" wvdial.
<jbicha> could you go ahead and open that bug now? :)
<jbicha> I am a fan of demoting/removing stuff earlier in the release cycle if possible so there's more time to notice problems :)
<tsimonq2> xnox: I'll pull the OpenSSL 1.1 patch in during the Qt 5.9.4 transition I'm currently prepping in Bileto if that's OK?
<xnox> tsimonq2, if that does dual-build, where the qt builds with either openssls, then yes, please.
<xnox> tsimonq2, if it does "require openssl1.1.0 only" then that would obviously will ftbfs.
<xnox> tsimonq2, still discussing when and how to introduce openssl1.1.0
<tsimonq2> xnox: ok, I'll take a closer look later and let you know
<xnox> tsimonq2, tah!
<sforshee> doko: this is from your test rebuild - https://launchpadlibrarian.net/353098637/buildlog_ubuntu-bionic-arm64.linux_4.13.0-17.20_BUILDING.txt.gz
<doko> sforshee: ohh, it's in superseded section :-/  does 4.15 build?
<sforshee> doko: I don't think I've tried 4.15 yet with that binutils, will test
<doko> sforshee: maybe wait for the final 2.30, once it's built
<sforshee> ack
<juliank> doko: ld from proposed segfaults on armhf trying to build systemd: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3114/+build/14286752
<juliank> it also does not build on i386 or arm64
<juliank> i386: /usr/bin/ld: /tmp/ccp5bmno.ltrans0.ltrans.o(.text+0x3362): unresolvable R_386_PLT32 relocation against symbol `__udivdi3'
<juliank> arm64: ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against `EFI_SUBSYSTEM' can not be used when making a shared object
<jibel> could someone re-run the failed autopkgtest for network-manager on ppc64el https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#network-manager
<seb128> jibel, done
<jibel> seb128, thanks
<seb128> yw!
<ginggs> How can I figure out why the build-dependencies of hwloc-contrib and eztrace-contrib are not installable?
<seb128> xnox, slangasek, is systemd/persistant log something you are (still?) looking at for the LTS?
<seb128> there was an ubuntu-devel@ list discussion but it didn't get any real traction
<xnox> seb128, it's enabled, not sure if it has migrated yet.
<seb128> xnox, oh ok, might be good to follow up on that list discussion to say that then :)
<seb128> good news
<xnox> ack
<seb128> yeah, looks like it migrated
<LocutusOfBorg> juliank, https://sourceware.org/bugzilla/show_bug.cgi?id=22751 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888478 :)
<ubottu> sourceware.org bug 22751 in ld "LTO broken for libgcc libcalls" [Normal,Resolved: fixed]
<ubottu> Debian bug 888478 in binutils "binutils: lto broken for libgcc libcalls" [Serious,Open]
<juliank> cpaelzer: Oh, you updated sanlock. Now we just need to get it into main
<juliank> lvm2 wants it :(
<cpaelzer> juliank: well I didn't want ti MIR it
<cpaelzer> juliank: I just wanted to make it somewhat usable
<cpaelzer> like able to install :-)
<juliank> cpaelzer: :)
<cpaelzer> juliank: it didn't seem MIR-worth to me when I looked at the code this afternoon
<cpaelzer> juliank: could you go without in lvm2 ?
<juliank> cpaelzer: Well lvm2-lockd needs it. some people want lvm2-lockd.
<GunnarHj> doko: Did you see my ping at #ubuntu-desktop?
<GunnarHj> https://irclogs.ubuntu.com/2018/01/29/%23ubuntu-desktop.html#t12:31
<juliank> cpaelzer: nacc knows more about that https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1741986
<ubottu> Launchpad bug 1741986 in lvm2 (Ubuntu) "Please merge lvm2 from Debian unstable for lvmlockd and sanlock support" [Wishlist,Fix committed]
<juliank> cpaelzer: But I'm sure we'll figure something out eventually
<juliank> We could also demote lvm2-lockd to universe
<juliank> but I don't want to decide that :D
<TJ-> juliank: Yes, we very much would like lvm2 with proper lock support, several users of it
<TJ-> juliank: nacc took it on when we dealt with it recently
<juliank> TJ-: Right. It will go to universe it seems, unless a team MIRs it.
<TJ-> juliank: that'll be good; saves having to maintain a custom build :)
<slangasek> xnox: you've enabled persistent log in systemd?  What steps have you taken to avoid double-logging to syslog?
 * juliank thinks double logging sounds like a good idea for now
<juliank> Well, at least you don't lose logs that way :)
<bbear> you can still double lose them.
<tsimonq2> kor
<tsimonq2> (mistype)
<xnox> slangasek, given that one has full timestamps, and the other one does not, i choose to keep data.
<xnox> slangasek, let's talk about enabling nano-timestamps in syslog by default, and thus breaking everyone's syslog parsing regexp-es? aka all the logwatch / graylisting things.
<xnox> slangasek, and enable journald module of syslog by default
<slangasek> xnox: the full timestamps are in the journal, yes?  I'm not saying we shouldn't do the persistent journal, I'm asking how we get rid of the duplication of data that is syslog
<xnox> slangasek, well, imho we currently have dataloss since `systemclt status` and `journalctl` do not read syslog files and the user gets the "no logs available" messages and/or incomplete output.
<xnox> slangasek, imho syslog should be pulling data from journal using the journald module that it has.
<slangasek> xnox: I think you're misunderstanding my objection
<xnox> slangasek, I think you are misunderstanding our users =)
<slangasek> enabling persistent journal - yes, +1
<xnox> slangasek, all of our users want more logs, not less.
<slangasek> still having data logged to syslog, causing redundant disk usage - -1
<xnox> well.
<xnox> slangasek, our users expect to have both plain text logs; and useful `systemctl status` output.
<xnox> i have as many people shouting at me that we shall not remove plain text logs; and that we should have complete journals across reboots.
<xnox> slangasek, note that xenial's journalctl fails to read bionic's .journal files =/
<slangasek> xnox: so I'll gather a bunch of people on my side to also shout about the wasted disk space ;-)
<xnox> and everything can read plain text syslog.
<slangasek> and then it'll be well-balanced
<xnox> slangasek, disk space is not wasted, as logs are rotated.....
<xnox> slangasek, oh, i totally do have roughly equal amount of people shouting at me about all the logs and disk space =)
<xnox> at the moment, keep everything prevents dataloss.
 * xnox .... log-loss?
<xnox> slangasek, do you know of a way to support 1) plain text logging 2) remote syslog logging 3) full journals -> without duplication?
<alkisg> Plain text logging isn't very important if there's a command that can display plain text output...
<slangasek> xnox: nope :)
<xnox> slangasek, cause to have full remote logging journal should be pushed to syslog, and to not have duplicate disk space somehow plain text syslog and journal should be picked for some/all/split logs.
<slangasek> xnox: right - so rsyslog has all kinds of clever filtering, and I think it would be appropriate for us to configure rsyslog by default to not write to disk logs that systemd is also writing to the journal
<slangasek> while having systemd continue to /send/ them to syslog, for remote logging etc
<xnox> slangasek, interesting.
<jbicha> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
#ubuntu-devel 2018-01-30
<doko> nacc: are you handling php and the 7.2 transition? if not. please point somebody else to it ... looking at component mismatches proposed: libsodium needs a bug subscriber, dh-php a MIR, argon2 as well
<doko> plus xml2
<doko> rbalint: flash-kernel merge: mtd-utils probably needs a MIR
<doko> jamespage: pycryptodome and pysmi need a MIR (dep of python-pysnmp4, openstack maintained)
<doko> juliank: lvm2 merge: thin-provisioning-tools needs a MIR, or recommends dropped to suggests
<doko> xnox: libzstd needs a MIR (for new btrfs-progs)
<doko> juliank: please see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for cryptsetup (unsatisfiable Depends)
<doko> tsimonq2: libindi is stuck in proposed
<Unit193> doko: I'd presume you saw Debian #888531 and https://wiki.debian.org/Teams/Ruby/ruby2.5?  (Including the test rebuild results.)
<ubottu> Debian bug 888531 in release.debian.org "transition: ruby2.5" [Normal,Open] http://bugs.debian.org/888531
<doko> Unit193: and?
<Unit193> You expressed interest.  Good then.
<doko> Unit193: it's scheduled for demotion
<Unit193> Ah, that works too.
<doko> ginggs: gazebo ftbfs (unstable as well)
<juliank> doko: lvm2 ok, well, britney does not care, so I did not see that. cryptsetup hopefully sorts itself out once argon2 is MIRed and lvm2 is migrated.
<doko> juliank: you see that in component mismatches proposed
<doko> somebody has to write the argon2 MIR, either foundations, or server
<juliank> doko: The argon2 MIR is at security review already :)
<doko> ahh, ok. do they know? ubuntu-mir is not subscribed to the bug
<juliank> Sure they are
<juliank> https://bugs.launchpad.net/ubuntu/+source/argon2/+bug/1746047
<ubottu> Launchpad bug 1746047 in argon2 (Ubuntu) "[MIR] argon2" [Undecided,In progress]
<juliank> "Notified of all changes MIR approval team"
<doko> hmm, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't show the subscription
<juliank> and cyphermox did the review and reassigned to ubuntu-security
<juliank> doko: It's older than the MIR I think
<juliank> bug is 17:16, mismatches 12:24
<doko> looks like it's out-of-date
<ginggs> doko: ok, i'll look
<juliank> doko: fixed lvm2. (I think it might be worth considering MIRing thin-provisioning-tools given that missing it could make your system unbootable if you use a cache LV, but um, let's worry about that later)
<juliank> maybe it should just be made a bit smarter and refuse to generate cache LVs without them installed.
<cpaelzer> xnox: we talked about lp 1744328 / debian 888764 - I'm kind of blocked on this, but unless Debian says yes I'd at least have a 2nd opinion to take it as Ubuntu Delta
<ubottu> Launchpad bug 1744328 in nss (Ubuntu) "libfreebl3.so should be public, not in the nss subdir" [Undecided,New] https://launchpad.net/bugs/1744328
<ubottu> Debian bug 888764 in nss "libfreebl3.so should be public, not in the nss subdir" [Normal,Open] http://bugs.debian.org/888764
<xnox> doko, tah
<tjaalton> cpaelzer: mike won't accept anything that upstream hasn't marked public :/
<tjaalton> i've fought things like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855879 for years
<ubottu> Debian bug 855879 in libnss3-dev "Please add blapi.h to libnss3-dev" [Normal,Open]
<tjaalton> which I need for nss-pam which is needed for certmonger to be useful
<cpaelzer> thanks for the info tjaalton
<tjaalton> even looped in redhat folks
<cpaelzer> I'm leaning towards adding that as a delta then, but would be pleased if a few people could ack on it
<cpaelzer> I might prepare a proper MP for an Ubuntu Delta on it and add you and xnox to comment there
 * cpaelzer is fully reading tjaalton's example bug now ...
<tjaalton> was thinking if bringing this up on CTTE would be warranted or not
<cpaelzer> sorry tjaalton - abbreviation overload - CTTE ?
<tjaalton> debian technical committee
<cpaelzer> I like your patch to 855879
<cpaelzer> although reading all that makes me feel bad
<tjaalton> crickets..
<cpaelzer> maybe a combined version that would make the .so's accesible (for cases like mine) and the .a files (as suggested by you) would be the best
<xnox> cpaelzer, hm..... surely all you need is a one line to create a symlink in like debian/libfoo.links and that's it, no?
<xnox> cpaelzer, and just upload that into ubuntu direct.
<cpaelzer> I know what I need :-) I just want to have a few acks on the way I do it :-)
<xnox> cpaelzer, (possibly with dh-exec if you need DEB_HOST_MULTIARCH location)
<cpaelzer> and after reading into all of tjaalton it might be the time to do a more generic overhaul
<cpaelzer> xnox: but I hear you are not opposed to making the libs accessible - that was the important pre-check
<cpaelzer> slangasek: pointed me to "talk to xnox on this" - that is what I'm doing :-)
<tjaalton> the new pkg for nss-pem can be added later
<cpaelzer> tjaalton: ok so you have time to escalate this to Debian and back for nss-pem then?
<cpaelzer> ok then I might really only change the .so's being a less invasive change
<tjaalton> yes
<tjaalton> filed the ITP for nss-pem
<tjaalton> see what happens
<cpaelzer> thanks, it still was very very sueful to get all that context on this
<cpaelzer> useful even
<xnox> cpaelzer, i don't think it is a good idea to create a new package, i don't think changing library location is ok, i think symlink is fine to satisfy everything you want, there is no need for new source or binary packages.
<cpaelzer> yep, after the last few minutes of discussion here I'm agreeing to that xnox
<xnox> tsimonq2, i made a huge mistake of uploading nodejs tweak =/ the amount of autopkgtests is humongous
<doko> tsimonq2: does kubuntu care about qdigidoc? https://launchpad.net/ubuntu/+source/qdigidoc/0.4.1-0ubuntu2
<doko> that seems to be out-of-date since 2012
<doko> cjwatson: are you ok with temoting tickcount?
<cjwatson> doko: yes
<cjwatson> doko: I have a todo item to remove our use of it entirely (we need a sort of partial replacement, but can't continue using interpreter ticks)
<doko> ok, unseeding then
<cjwatson> doko: in general it doesn't make sense for python-* to be seeded on Launchpad's behalf any more.  Since ~2009 we've only used a relatively small number of system-packaged Python packages, and mostly use buildout (until end of last year) / pip (now)
<cjwatson> doko: python-tickcount was an exception to that, but as I think I mentioned on the bug, if necessary we could keep it in our deployment PPA anyway
<doko> ok. I'll just demote, don't remove it yet
<xnox> doko, do we have a place to document / record 32-bit only issues that I have to dig/hunt to solve? e.g. I'm currently looking at i386 and i386+armhf only adt failures triggered by openssl upload.
<doko> xnox: no, not afaik
<doko> besides the i386 float stuff probably
<cpaelzer> links/dh-exec doesn't like me :-/
<cpaelzer> has someone an example of dh-exec in .links to create multiarch links?
<xnox> cpaelzer, is the .links file executable?
<xnox> cpaelzer, does it have dh-exec shebang?
<xnox> cpaelzer, or can you push your repository somewhere for me to check it?
<cpaelzer> it is just me never using it that way - I iterated a bit but it keeps failing with
<cpaelzer> dh_link: symlink(nss/libfreebl3.so, debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/) failed: No such file or directory
<cpaelzer> I'm sure I do something wrong, but without an example to check against it is stupid iterating through trial-and-error
<cpaelzer> I'm in a chroot of an sbuild and can tweak it
<cpaelzer> atm it is like
<cpaelzer> http://paste.ubuntu.com/26488822/
<cpaelzer> and files relative to the build are like
<cpaelzer> http://paste.ubuntu.com/26488823/
<cpaelzer> I (currently) assume it doesn't have the variable exported or something like it
<xnox> cpaelzer, there should never be leading '/' in any of these files
<xnox> it should be executable
<cpaelzer> I tihnk I had all variations of this :-/
<xnox> thus something like:
<xnox> horum =/
<xnox> cpaelzer, and it should be full paths before and after....
<cpaelzer> oh that I never tried
<cpaelzer> ..
<xnox> usr/lib/${DEB_HOST_MULTIARCH}/nss/libfreebl3.so usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
<xnox> i think, yet manual has leading slashes in examples.
<cpaelzer> it also is the variable
<cpaelzer> only when I drop the var I get to the "is a directory" error
<cpaelzer> which is about the filename on the second argument as you just said
<xnox> fun
<cpaelzer> so "usr/lib/x86_64-linux-gnu/nss/libfreebl3.so usr/lib/x86_64-linux-gnu/libfreebl3.so" works
<cpaelzer> now I need to find what I miss to get the variable resolved
<cpaelzer> I had $() and ${} and tried on exporting the variable
<xnox> include /usr/share/dpkg/default.mk on top of debian/rules?
<cpaelzer> have it working now
<cpaelzer> interesting
<cpaelzer> it was the full path incl file on the second argument
<cpaelzer> just when variables are used the error without it is way off
<xnox> whoop whoop
<cpaelzer> thanks xnox, now all that back into proper packaging for another full try :-)
<cpaelzer> xnox++
<cpaelzer> (we should have more of you)
<doko> ohh no, I can't stand more noise ;p
<cpaelzer> xnox: grml - we only made it 75% - it now links to a literal ./debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so :-)
<xnox> cpaelzer, as per $ man dh-exec-subst it says ${DEB_HOST_MULTIARCH} will be substituited....
<cpaelzer> yes, but it is not :-/
<cpaelzer> mabye it only calls plain dh-links in my case
<cpaelzer> that is how it seems to me atm
<cjwatson> cpaelzer: what's your debhelper compat level?
<cpaelzer> 9
<cjwatson> ok, 9 should work
<cjwatson> cpaelzer: how about your source format?
<cpaelzer> 3.0 (quilt)
<cpaelzer> nothing too special on any of that
<cjwatson> can I see the source package?
<cpaelzer> sure it is essentially pull-lp-source nss + experimenting with debian/libnss3.links as http://paste.ubuntu.com/26488955/
<xnox> cpaelzer, you have dh-exec as build-dependency right?
<cpaelzer> I've had it
<cjwatson> ideally I'd like to see your actual .dsc + extra files
<cjwatson> especially the .debian.tar.*
<xnox> cpaelzer, scp it to people.canonical.com?
<Laney> the file is executable?
<cpaelzer> executable - yes
<cpaelzer> I'll upload and share a link
<cpaelzer> I put all in a tarball at http://people.canonical.com/~paelzer/nss-links-multiarch.tgz
<cpaelzer> I realized I had it not executable in the packaging yet (only per chmod in the sbuild chroot)
<cpaelzer> so I cahnged that as well and am currently rebuilding
<cpaelzer> I'll ping if this (as in the tarball) is still failing me on the rebuild
<cpaelzer> nice - it really was the +x permissions before buildpackage
<cpaelzer> I'll save all that as big learning experience
<cpaelzer> thanks for your patience Laney, cjwatson and xnox
<cpaelzer> it now worked (breaking things post dh_link due to that, but worked)
<cjwatson> executable in the packaging> yep, that was why I wanted to check the .debian.tar.* :-)
<cpaelzer> the follow on fallout is interesting
<cpaelzer> dh-exec creates debian/tmp (as th emanpages tells me)
 * Laney has been there before
<cpaelzer> and until now the d/rules had mkdir debian/tmp (without -p)
<Laney> forgetting to commit the mode change and being surprised when it didn't survive gbp buildpackage -S or something like that
<jbicha> doko: LP: #1745634 would make it easier for me to try to demote xterm to universe
<ubottu> Launchpad bug 1745634 in ubuntu-meta (Ubuntu) "Demote idle to universe" [Undecided,New] https://launchpad.net/bugs/1745634
<doko> jbicha: yeah, probably worth doing that
<jbicha> doko: cool. Could you unseed it or comment on the bug if you'd prefer I do it?
<tjaalton> slangasek: hi, finally wrote a small patch to pam-auth-update to fix https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1192719
<ubottu> Launchpad bug 1192719 in pam (Ubuntu) "[pam-auth-update] add support for enabling non-default configs" [Wishlist,Confirmed]
<doko> xnox: are you undoing my libp11 no-change uploads?
<xnox> doko, ..... libp11 was not rebuild against openssl1.1.0 because we don't have that... thus p11 3 abi is a lie.
<xnox> doko, we need to redo those uploads, properly, to rebuild that 3 abi, against the right openssl.
<doko> yes, seen that now. will you do, or should I?
<xnox> doko, either or. as you wish. I was planning to do the unwind.
<doko> xnox: ok, please do
<nacc> doko: yes
<nacc> doko: (re: php7.2)
<nacc> doko: i'll be promoting it to main once i get it all fixed up, just like we did 7.1 previously, and removing 7.1 from the archive
<doko> ta
<doko> nacc: well, write the MIRs first ...
<nacc> doko: yep
<nacc> doko: to be clear the dh-php one is already resolved, just hasn't been caught up it seems (dh-php is only a suggests)
<tsimonq2> doko: I'm aware.
<tsimonq2> xnox: nodejs> ack :( thanks for telling me
<nacc> doko: afaict, argon2 is not related to php?
<tsimonq2> doko: I think at this point if it's KDE 4 or Qt 4 and you can handle rdeps, take it out
<tsimonq2> I wonder if Bileto access could be reconsidered now that all PPA arches are unblocked.
<tsimonq2> Maybe allow ~ubuntu-dev access or something :)
<tsimonq2> I have access to do Qt transitions but I know it would be really useful to use with other Ubuntu Developers (with upload access)
<tsimonq2> I might start a discussion on ubuntu-devel unless it's decided here :)
<nacc> doko: ok, we've subscribed ubuntu-server to libsodium; is that enough to re-main it, once necessary?
<ginggs> doko: gazebo and cyphesis-cpp uploaded, i think tinyxml2 will migrate if you rm openmw:arm64
<doko> mwhudson: why is golang-1.8-go still in main?
<doko> ginggs: done
<ginggs> flexiondotorg: would you add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
<ubottu> Launchpad bug 1740708 in telegram-desktop (Ubuntu) "package telegram-desktop 1.1.23-1 failed to install/upgrade: trying to overwrite '/usr/share/applications/telegramdesktop.desktop', which is also in package telegram 1.1.23-1~artful1.0" [Undecided,Invalid] https://launchpad.net/bugs/1740708
<ginggs> doko: ta!
<flexiondotorg> ginggs: OK
<ginggs> flexiondotorg: ta!
<slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 7?
<mdeslaur> ack
<mwhudson> doko: dunno, shouldn't be afaik
<juliank> cjwatson: I'm looking at archivepublisher now to see where changes would be needed for valid-until support. It does not seem _that_ difficult. Basically we add the field for all -updates, -security releases; and add the release files to the set that needs updates if it's older than a week.
<juliank> (and make validity 2 weeks)
<juliank> old releases might be tricky
<juliank> not sure
<juliank> or, rather then looking at the age of the release file, we open it and check that valid-until does not expire for more than a week
<juliank> I guess it needs a flag in the model somewhere that tells it "Valid-Until" is allowed
<juliank> well "needs"
<juliank> LP takes a while to branch :D
<juliank> cjwatson: That is, https://paste.ubuntu.com/26491551/ or https://code.launchpad.net/~juliank/launchpad/valid-until
<juliank> I have not run any tests yet...
<juliank> update: http://paste.ubuntu.com/26491574/
<juliank> forgot initialize...: http://paste.ubuntu.com/26491591/
<juliank> now it needs tests and some testing
<juliank> but I think the idea is clear.
<juliank> ugh, should have posted in #launchpad
 * juliank moves to #launchpad-dev
 * tsimonq2 is curious about what Valid-Until support means and what the use case would be
<cjwatson> juliank: something like that is probably a good start (note that when the bug was just filed it would have been a *lot* harder, because the ability to write just the Release file wasn't really there), but it'll need extensive tests
<juliank> yeah
<juliank> cjwatson: I also posted in #launchpad-dev now, so we can follow up there if needed :)
<slangasek> tsimonq2: if you know that your archive is periodically republished, then including in the signed data that a given archive state is invalid after a given date prevents a silent replay attack
<cjwatson> (assuming reasonably synced clocks etc.)
<juliank> tsimonq2: To further comment, you can prevent what you could call update starvation. That is, for -updates, currently you can feed apt an old archive state all the time, and it says "oh fine, no updates".
<tsimonq2> slangasek: Hm ok, interesting.
<tsimonq2> juliank: So then what will apt do in the case of an old archive state?
<juliank> tsimonq2: If the archive is not valid anymore it will give you an error if you update
<juliank> tsimonq2: You can easily try that yourself in a Debian chroot, just set the clock backward :D
<tsimonq2> juliank: heh OK :)
<tsimonq2> juliank: What if I just have an outdated archive mirror that's *purposely* set that way for some reason? (obviously not in prod but for testing) Will I be able to override this in sources.list the same sort of way I override untrusted entries?
<juliank> tsimonq2: You can set check-valid-until to no
<juliank> you can also configure valid-until-{min,max}
<juliank> these are in seconds, BTW
<tsimonq2> Could you give an example (or a manual I can RTFM on)?
<juliank> tsimonq2: It's all documented in sources.list, but no excamples in there I guess
<juliank> tsimonq2: in the manpage, that is
<juliank> tsimonq2: This feature is over 6 years old already
<tsimonq2> juliank: oh hah, TIL
<juliank> tsimonq2: Here's the LP bug from 2011: https://bugs.launchpad.net/launchpad/+bug/716535
<ubottu> Launchpad bug 716535 in Launchpad itself "Please support Valid-Until in release files for security.ubuntu.com" [Low,In progress]
<tsimonq2> juliank: subbed, thanks
<Unit193> http://snapshot.debian.org/ also notes the use of check-valid-until.
<tsimonq2> Oh, right. Interesting.
<juliank> tsimonq2: It's a bit inconvenient in some use cases with historical distros, but it's a huge security improvement IMO
<juliank> :D
<tsimonq2> :D right
#ubuntu-devel 2018-01-31
<doko> nacc: libsodium promoted again
<jbicha> doko: could you try demoting the list from my latest comment at LP: #1745634 and xterm LP: #1720482 ?
<ubottu> Launchpad bug 1745634 in python3-defaults (Ubuntu) "Demote idle to universe" [Undecided,New] https://launchpad.net/bugs/1745634
<ubottu> Launchpad bug 1720482 in xterm (Ubuntu) "Demote xterm to universe" [Undecided,Confirmed] https://launchpad.net/bugs/1720482
<jbicha> xterm at least shows up on component-mismatches-proposed now
<nacc_> doko: yep
<nacc_> doko: slangasek: i don't recall filing a MIR for php7.1 in artful. We went through the transition via php-defaults then. Does php7.2 need an explicit MIR?
<doko> nacc_: no, just make sure that 7.1 gets demoted
<doko> jbicha: xterm is still recommended in the release pocket
<doko> xnox, jbicha: https://launchpadlibrarian.net/354753363/buildlog_ubuntu-bionic-s390x.babl_0.1.42-1_BUILDING.txt.gz
<sforshee> doko: I tried building an arm64 kernel with 2.30-1ubuntu1 and still get the link error - https://launchpadlibrarian.net/355195922/buildlog_ubuntu-bionic-arm64.linux_4.15.0-6.7_BUILDING.txt.gz
<doko> sforshee: where is the source for this build?
<doko> sforshee: the kernel build log is notorious for not printing command line options
<doko> could you extract these from the link line, and provide this together with all the object files?
<sforshee> doko: you can get the source package from the ppa https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap, or lp:~ubuntu-kernel/ubuntu/+source/linux/+git/unstable
<sforshee> doko: I'll also get your the link line and the object files, will take a bit
<cpaelzer> rbasak: I don't really know what to do about https://lists.ubuntu.com/archives/ubuntu-release/2017-December/004255.html
<cpaelzer> it is up 6 weeks now, my ping in early january still waits for moderator approval
<cpaelzer> according to the doc it just needs one (1) SRU member to ack
<cpaelzer> since I seem to be unable to get hold of one, could I ask to get you to consider parsing through the MRE wiki page and acking it if ok?
<doko> dpdk: is that the python3 version?
<sil2100> cpaelzer: oh, I think I wanted to take a look at that but then it fell between the cracks somehow
<cpaelzer> I don't mind who takes a look
<cpaelzer> I just want it to be not staying down in those cracks :-)
<doko> nacc_: php7.2 -> net-snmp -> perl ... that looks like fun
<doko> for migration
<doko> infinity: fyi, dropping the libgcc-compat patches as done in debian doesn't help the glibc cross build
<jjohansen> stgraber: hey do we have a bug for the apparmor ns_name issue that is causing profile loads to fail in artful/bionic
<stgraber> jjohansen: hmm, that's a good question, I don't think so
<jjohansen> okay, I'll create one
<cpaelzer> what is the obvious extension to get perms/ownership controllable in d/package.dirs?
<cpaelzer> is there some dh-exec magic or similar to this as well, or goging for d/rules (or postinst) to do so?
 * cpaelzer is reading through dh_* man pages for now
<doko> juliank: fyi, apt's own autopkg tests fail
<cpaelzer> ah user id is not static anyway, so I'll need postinst I guess
<juliank> doko: I know. Seems to be a umask issue or something. Gotta investigate the changes
<sforshee> doko: looks like you have an account on kathleen, ~sforshee/binutils-arm64
<sforshee> build.log has the verbose build output including the ld command
<doko> sforshee: which one is kathleen? a porter box?
<doko> tdaitx: https://launchpad.net/ubuntu/+source/maven-archiver/3.2.0-1/+build/14224913
<tdaitx> doko: looking into that
<doko> juliank: "The libfastjson library is a fork from json-c with a focus on performance"  such forks tend to be dead after a year or two ... is json-c not maintained anymore upstream?
<juliank> doko: Well, I don't know, but rsyslog switched to it. I'm not sure if they're compatible.
<juliank> doko: Seems it's maintained by the rsyslog people, so they'll know what they need
<juliank> doko: I think modifying rsyslog to use json-c again would be more work, but I have not tried.
<doko> juliank: yes, but it would add just another json implementation into main, what we are trying to avoid. I'm fine with it if we can switch the other packages to this implementation
<juliank> doko: Apparently it does not really have a very stable API yet
<xnox> infinity, has Tokyo timezone changed somehow? or maybe the tests in ruby2.3 are dead wrong? getting ADT failures in test_time_tz.rb in ruby2.3 with "off by one hour" for tokyo in 1951.
<xnox>   1) Failure:
<xnox> TestTimeTZ#test_asia_tokyo [/tmp/autopkgtest.lP30YH/autopkgtest_tmp/test/ruby/test_time_tz.rb:129]:
<xnox> TZ=Asia/Tokyo Time.local(1951, 5, 6, 2, 0, 0).
<xnox> <"1951-05-06 03:00:00 +1000"> expected but was
<xnox> <"1951-05-06 02:00:00 +1000">
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/r/ruby2.3/20180131_082235_fe969@/log.gz
 * xnox reruns...
<juliank> xnox: does not help, see #-release
<xnox> ah
<juliank> doko: uploaded an attempt to fix that apt thing (set umask 022 at start of script), let's hope it works.
<sil2100> cpaelzer: I'm looking at the SRU exception for dpdk right now
<sil2100> cpaelzer: looks good, but I'd like to formalize it a bit more - you mention more or less how testing of dpdk is carried over, but I'd like to have a step-by-step list of what is being tested before verification-done is marked in the SRU section of the page
<rbasak> sil2100: thank you for looking at that
<sil2100> cpaelzer: as an easy to see summary of the testing procedures
<sil2100> cpaelzer: something that will make it easy for an SRU member to look at and see if such testing was performed during verification
<cpaelzer> sil2100: ok, let me add something
<cpaelzer> sil2100: you mean in section https://wiki.ubuntu.com/StableReleaseUpdates/DPDK#Testing_and_verification right?
<sil2100> cpaelzer: yes, exactly ;) Maybe some short bullet-point summary of what was written in the sections above, for SRU purposes
<sil2100> cpaelzer: additionally to what is already there
<cpaelzer> sil2100: added
<cpaelzer> sil2100: the MRE temaplate as well as the section linked above got some new text
<cpaelzer> essentially the uploader is supposed to run the test suite and attach the log
<cpaelzer> everythin in there shall be passed or explained-why-not
<cpaelzer> https://wiki.ubuntu.com/StableReleaseUpdates/DPDK?action=diff&rev1=1&rev2=2
<cpaelzer> sil2100: ^^ for the diff
<cpaelzer> would that cover what you wanted to see?
<sil2100> Oh, that's also fine then
<doko> ginggs: should pocl's testsuite errors be ignored on armhf or arm64, or should we remove the binaries?
<ginggs> doko: i think remove the binaries
<doko> ginggs: ok, need to figure out the rdeps ...
<doko> ginggs: could you have a look what needs to be done for the qgis transition?
<ginggs> doko: sure
<doko> ta
<ackk> cjwatson, hi, around?
<cjwatson> slightly.  if it's py-macaroon-bakery, still on my list :-/
<cjwatson> I have to run in a moment to pick up the kids though
<ackk> cjwatson, it's related to that :) do you foresee any issue with an MIR for macaroon/bakery libraries? AFAICS that requires a few dependencies to be promoted too
<cjwatson> ackk: no, I think I even replied to the MIR to ack it?
<ackk> cjwatson, oh, is there one already?
<cjwatson> oh, maybe I'm thinking of the SRU bug
<cjwatson> anyway, I wouldn't anticipate a problem (libsodium at least is already in main), though I'm sure the security team will want to give it a review
<ackk> ah nice, thanks
<ginggs> doko: it looks like qgis is blocked on qscintilla2, which is blocked on some octave autopkgtests - looking at those now
<jbicha> doko: xnox: babl/s390x is a pain and I don't know how to fix it. See also GNOME bug 790745 and Debian bug 888769
<ubottu> Gnome bug 790745 in babl "babl 0.1.38: float-to-8bit test fails on s390x" [Normal,New] http://bugzilla.gnome.org/show_bug.cgi?id=790745
<ubottu> Debian bug 888769 in src:gegl "gegl: FTBFS on machines with lots of cores" [Normal,Open] http://bugs.debian.org/888769
<slangasek> nacc_: no, php7.2 just needs a team subscriber and a swap in the archive
<nacc_> slangasek: ack, that's all ready to go as well then
<nacc_> slangasek: (well ready as far as components, the migration is still under way in dependent packages)
<nacc_> doko: ack, thanks
<nacc_> doko: yeah :/
<nacc_> (re: the dependency chain)
<doko> nacc, slangasek: we might want to pre-promote argon2, ok from a MIR standpoint, but still waiting for security review (asked to priotize it). currently everything fails in the autopkg tests
<nacc_> doko: i thought argon was for cryptsetup?
<slangasek> doko: pre-promotion is no problem from my side
<doko> ok, done
<doko> nacc_: you will have to give back a lot of php-defaults autopkg tests
<nacc_> doko: yep, that's on my plate nonw
<nacc_> doko: fwiw, i think many of these will go away once ig et phpunit migrated
<nacc_> and it's own dependencies, that is
<jbicha> rbalint: can you push your latest libnfs changes to the Debian VCS? also can you cherry-pick the upstream fix for Debian bug 882540?
<ubottu> Debian bug 882540 in src:libnfs "libnfs FTBFS with glibc 2.25" [Serious,Open] http://bugs.debian.org/882540
<jbicha> btw,I filed #1746598
<nacc_> doko: and fyi, the latest php7.2 should fix the remaining c-m, sorry about that
<rbalint> jbicha: i fixed the repo, need a bit more time to get new upstream packaged
<jbicha> rbalint: I understand. Could you cherry-pick the ftbfs commit though?
<rbalint> jbicha: if it takes too much time i'll cherry-pick
<jbicha> cool, thanks
<rbalint> jbicha: popcon for libnfs skyrocketed last year :-)
<jbicha> blame gvfs :)
<jbicha> infinity: could you forward this upstream? https://launchpad.net/ubuntu/+source/gvfs/1.34.1-1ubuntu3
#ubuntu-devel 2018-02-01
<infinity> slangasek: I'm curious about that livecd-rootfs change.
<infinity> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on lgw01-amd64-026.buildd
<infinity> ^-- From a build log today on the host that you linked your failed build from.
<infinity> slangasek: I'm less convinced that the hostname filtering is the issue, and more convinced that that code just plain hasn't been tested in years (it was last used for the panda ubuntu-server preinstalled image).
<infinity> slangasek: It's possible that 'if [ -z "$MIRROR" ]; then' isn't tripping, which would cause one to think it was broken the way you saw.
<infinity> slangasek: OH!
<infinity> slangasek: FFS.
<infinity> slangasek: Bug updated.  Also, I feel dumb for not using my own debugging info in the log the first time. :P
<infinity> Yay for layers of complexity on top of layers of complexity. :/
<sarnold> you sound like you could use a nice new clean abstraction layer on top of everything to simplify things!
 * sarnold runs
<infinity> sarnold: *glare*
<tsimonq2> Sounds to me like problems were *stacking* up, much like the abstraction layers :P
 * tsimonq2 runs
<slangasek> infinity: ah, heh. thoughts on a reasonable fix? lp-*?
<infinity> slangasek: That's what I'm comitting now.
<slangasek> ok
<infinity> slangasek: While also cleaning out some older entries.
<slangasek> :)
<infinity> slangasek: And making .buildd a thing again.
<slangasek> ok
<infinity> slangasek: Of course, fixing this still leaves the open quest of "do we really want to germinate uncondictionally for every single build?" which seems a bit nutty.
<infinity> slangasek: Laney cargo-culted my code I was using to build a /pool/, for which germinate was a useful tool, but now it's running for literally every build.
<infinity> And by "nutty", I mean "expensive".  germinate isn't quick.
<tsimonq2> (amen)
<slangasek> infinity: my understanding was that this was meant to do a very small subset of germinate for purposes of getting a list of snaps
<slangasek> but I haven't reviewed
<nacc> slangasek: would the stuff you've been working on today lead to latency copying packages to the archive? just wondering how long to wait on phpunit being available (so I can trigger the rebuilds that are waiting on it)
<slangasek> nacc: no
<nacc> slangasek: ok :)
<nacc> slangasek: i'll be patient then
<nacc> i think i've got it unwedged now, just waiting on the copying
<wgrant> I don't see any pending copies of phpunit on LP
<nacc> hrm
<nacc> https://launchpad.net/ubuntu/+source/phpunit/6.5.5-1ubuntu1
<wgrant> That looks already copied?
<wgrant> Uploaded, in fact.
<nacc> maybe i just hit a small window where it wasn't yet copied
<nacc> ok i'll retry the builds now
<wgrant> What do you mean by copied?
<wgrant> Looks to me like you uploaded that directly.
<nacc> sorry, built and then actually available for other packages to use
<wgrant> Ah, published.
<nacc> yeah, wrong term
<nacc> wgrant: thanks as always!
<wgrant> That can take up to an hour after the build completes.
<nacc> wgrant: ok, good to know
<doko> rbasak, nacc, cpaelzer: please comment on https://bugs.launchpad.net/ubuntu/+source/moin/+bug/1735388
<ubottu> Launchpad bug 1735388 in moin (Ubuntu) "Server seeded Python2 packages" [Undecided,New]
<cpaelzer> doko: nacc: answered with my limited insight to the case on the bug
<cpaelzer> good enough to start a discussion if needed, because so far it is a "no, because ..." answer
<doko> cpaelzer: no, that's good enough
<doko> rbasak, cpaelzer: mariadb-10.1 has autopkg test failures since 70 days ...
<cpaelzer> doko: rbasak mentioned yesterday that he knows and wanted to take a look
<cpaelzer> it was something more complex, but consider it actively worked on by him
<cpaelzer> sil2100: thanks for the ack, and I see you linked it up in the wiki already
<doko> just asking because it blockes thinks
<cpaelzer> yeah he mentioned that as well
<tjaalton> doko: do you have any idea why dfvfs fails to build on bionic, fine on sid? I think it's blocking pyasn1, or at least one of the blockers
<tjaalton> a test fails
<doko> tjaalton: given back now, but there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888139
<ubottu> Debian bug 888139 in src:dfvfs "dfvfs FTBFS: ERROR: testScanFVDE (helpers.source_scanner.SourceScannerTest)" [Serious,Open]
<tjaalton> ah
<doko> tjaalton: but the ubuntu one is different, floating point exception
<tjaalton> yeah
<tjaalton> testFind
<doko> rbalint: opengcs ftbfs on 32bit archs
<rbasak> doko: if you need mariadb-10.1 through, I think it's appropriate to force-badtest it.
<doko> rbasak: can you address this on #ubuntu-release please?
<rbasak> doko: I filed Debian bug 888956 yesterday
<ubottu> Debian bug 888956 in src:mariadb-10.1 "dep8 tests regressed by removal of mariadb-test" [Important,Open] http://bugs.debian.org/888956
<rbasak> doko: you mean change channel? Or something else?
<doko> I mean, we entangle now everything with everything, so one more package not migrating probably doesn't matter
<doko> rbasak: yes
<rbalint> doko: yes, i know, it is an upstream issue but since it works only in windows hyper-v vms only amd64 is interesting
<rbalint> doko: i just open LP: #1746697 to track the failure
<ubottu> Launchpad bug 1746697 in opengcs (Ubuntu) "Opengcs FTBFS on 32 bit architectures" [Low,New] https://launchpad.net/bugs/1746697
<doko> LocutusOfBorg: you can't build a package in main with dietlibc, it's in universe, and I don't see the point doing that at all
<LocutusOfBorg> doko, why gdbm (1.8.3-14 to 1.14.1-2)
<LocutusOfBorg>     Maintainer: Dmitry Bogatov
<LocutusOfBorg>     0 days old
<LocutusOfBorg>     Valid candidate
<LocutusOfBorg> britney seems happy with that...
<doko> not component mismatches
<doko> jbicha: what's going on with dconf/d-conf?
<jbicha> doko: someone needs to figure out why a 2-line patch appears to break notify-osd's autopkgtest on armhf
<jbicha> https://git.gnome.org/browse/dconf/commit/?id=701d19d1
<jbicha> and we're renaming d-conf to dconf
<GunnarHj> tjaalton: Hi Timo, do you have time to sponsor bug #1746544?
<ubottu> bug 1746544 in xkeyboard-config (Ubuntu) "Upgrade to xkeyboard-config 2.23" [High,In progress] https://launchpad.net/bugs/1746544
<tjaalton> GunnarHj: someone just complained about 2.23 breaking something
<tjaalton> on #xorg-devel
<GunnarHj> tjaalton: Oh.. Will take a look.
<tjaalton> 14:19 < arekm> hm, xkeyboard-config 2.22->2.23 and: $ setxkbmap pl
<tjaalton> 14:19 < arekm> Error loading new keyboard description
<tjaalton> could be user error
<GunnarHj> tjaalton: I played with 2.23 successfully yesterday. Is #xorg-devel on freenode?
<tjaalton> yes
<GunnarHj> bbl
<doko> ginggs:  sbuild-build-depends-hwloc-contrib-dummy : Depends: nvidia-cuda-dev but it is not going to be installed
<doko> tsimonq2: is kubuntu interested in https://launchpadlibrarian.net/355405407/buildlog_ubuntu-bionic-amd64.choqok_1.6-1.isreally.1.5-4ubuntu2_BUILDING.txt.gz ? if yes, please fix, or else we should remove
<tsimonq2> doko: If it's KDE 4 or Qt 4, RM; otherwise we're interested if it's seeded.
<tsimonq2> (on mobile, can't check)
<doko> libtelepathy-qt4-dev,
<doko> debian has a recent version ...
 * tsimonq2 looks
<doko> tsimonq2: that probably should be merged again
<tsimonq2> doko: ack, want to do that or should I?
<doko> tsimonq2: please do
<doko> I have no idea about the kubuntu specific patch
<tsimonq2> doko: Ok, will do later, ta
<GunnarHj> tjaalton: I can confirm that there is an issue with the Polish layout, but can't tell why. Uploaded 2.23.1 to the PPA - let's see if that makes a difference.
<tjaalton> GunnarHj: alright
<rbasak> nacc: could you glance at http://autopkgtest.ubuntu.com/packages/p/php-horde-activesync/bionic/amd64 please? It's holding up mysql-5.7 on some test dependency problem. Is this related to your recent PHP work?
<GunnarHj> tjaalton: 2.23.1 didn't help, but I spotted it: https://bugs.freedesktop.org/show_bug.cgi?id=104904
<ubottu> Freedesktop bug 104904 in General "Polish symbols file broken by typo" [Critical,New]
<GunnarHj> Probably they'll soon release a new version; let's wait a bit.
<tjaalton> GunnarHj: ok, I'll push that to debian then
<GunnarHj> tjaalton: Well, nothing of this is in Debian yet... https://bugs.debian.org/884822
<ubottu> Debian bug 884822 in src:xkeyboard-config "Please upgrade to 2.22" [Wishlist,Open]
<tjaalton> GunnarHj: if that simple patch fixes it then that could be added as a distro patch for now..
<GunnarHj> tjaalton: Sure, I can do another upload to the PPA with that patch, if you like.
<tjaalton> no need
<tjaalton> is there a diff to ubuntu?
<tjaalton> or is it synced
<GunnarHj> tjaalton: There is a permanent Ubuntu delta.
<tjaalton> GunnarHj: uploaded to debian, merge with that
<doko> juliank, xnox: about the systemd ftbfs on arm64. I think binutils is right. so can you find out why crt0-efi-aarch64.o has such a relocation?
<xnox> doko, ooooooouuuugh
<xnox> doko, I bet you will be running around brussels yelling at me "fix systemd kthxbye"
<GunnarHj> tjaalton: Ok, will do. (Which will be similar in substance to adding that pl patch.)
<doko> well, fix it before brussels ;p
<juliank> maybe it's a gnu-efi bug :D
<juliank> I have a PPA for the new gnu-efi https://launchpad.net/~juliank/+archive/ubuntu/gnu-efi-staging
<juliank> but no aarch64 build
<juliank> that is, arm64 is not enabled there.
<doko> well, you can enable it
<juliank> doko: Will it rebuild gnu-efi in there then?
<juliank> or rather, build it for that
<juliank> I can also copy all stuff in a new PPA
<doko> not sure if it automatically creates a new build record. maybe just re-upload after enabling arm64
<juliank> I just copy-package gnu-efi and systemd into gnu-efi2 PPA :D
<juliank> Ugh, I'm terrible at this
<juliank> gnu-efi is building in  https://launchpad.net/~juliank/+archive/ubuntu/gnu-efi-arm64 now
<juliank> I probably should just fix refind and roll out that transition via bileto in one go if that fixes systemd.
<doko> juliank: is proposed enabled in this ppa?
<xnox> juliank, well, if there is something to patch in systemd, it's best to send pull request to systemd upstream; and in packaging we have a handy git-cherry-pick script to cherrypick the patch by commit id.... which debian also needs.....
<xnox> and then just merge into ubuntu as usual.....
<cjwatson> you could have just copied the package over the top of itself with --include-binaries
<cjwatson> that schedules any missing builds
<xnox> wow
<xnox> neat
<juliank> cjwatson: wow
<rbasak> Skuggen: ^
<rbasak> Skuggen: that might solve your PPA question earlier :)
<doko> xnox, juliank: I also tried to disable lto in systemd, but the issue persists. but in general, it's always better to debug issues like these without lto first
<nacc> rbasak: yes, it needs the new phpunit and a few other things, which are going through now
<rbasak> Ah, thanks.
<rbasak> Skuggen: the tool you'd need is copy-package from ubuntu-archive-tools
<rbasak> Skuggen: "bzr checkout --lightweight bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-archive-tools/"
<nacc> rbasak: i belileve if you use phpunit from proposed it shoudl work, or you can wait till i get the transition done
<doko> juliank: your arm64 ppa doesn't have proposed enabled
<rbasak> nacc: I'm not sure how to do that for proposed migration. Or can the release team do that with a hint?
<juliank> doko: ooh, now I understand.
<juliank> ugh
<nacc> rbasak: you can do it
<nacc> rbasak: take the url & triggers=phpunit/<version> (iirc)
<nacc> rbasak: it's documented on the wiki
<nacc> rbasak: i can do it later today too
<rbasak> Right, but will britney actually pay attention to that specific result?
<Laney> Yeah
<nacc> yeah
<Laney> And you can actually test that if you pass --apt-pocket=proposed=src:pkg1,src:pkg2,... packagetotest locally
<nacc> uyeah
<nacc> that's what i do locally for the bootstrap
<nacc> it just takes a bit to get the archive to that poinnt :)
<juliank> doko: Stupid me :(
<doko> ginggs: the cuda rdeps now built. pycuda could be be built for ppc64el too
<ginggs> doko: thanks, will take a look
<ginggs> doko: is there anything still needing gcc-5 now?
<doko> ginggs: I didn't look, but it builds =)
<ginggs> doko: hmm, didn't build for me - we don't have a libcuda for ppc64el in ubuntu
<doko> and there we go, php and ruby transitions in parallel ...
<xnox> doko, did you mean golang too?
 * xnox is not sure how to read "go, php and ruby" =)
<doko> golang is not verb
<doko> unless mwhudson goes wild with 1.10 ...
<ginggs> anything can be a verb in English
<nacc> doko: i should be able to get a lot of php unstuck once the new xdebug migrates from debian
<nacc> doko: that's what is preventing phpunit from workign right now
<nacc> how often does the auto-syncer run?
<cjwatson> 0 5,11,17,23 * * *
<nacc> cjwatson: thanks
<ginggs> I thought it was 4, 8, 15, 16, 23, 42
<cjwatson> I'm not sure what you're thinking of but it must be something else
<ginggs> i must be lost
<doko> nacc, fyi, I added http://people.canonical.com/~ubuntu-archive/transitions/html/php7.2.html  but there seems to be something wrong. feel free to correct it (just copied from debian)
<nacc> doko: ok, thanks
<nacc> doko: it's becuase we went ahead of debian
<nacc> (to 7.1)
<nacc> i'll fix
<nacc> doko: actually how do i correct it ?
<nacc> doko: it should be phpapi-20160303 for us
<nacc> (as bad)
<nacc> doko: oh do i just branch the tracker and update?
<doko> nacc: yes, but already done
<nacc> doko: thankns
<doko> you'll see the update in an hour or so
<nacc> doko: ok, i'll keep an eye out
<nacc> doko: if my grep-dctrl-fu is right, we don't have a ton of packges to rebuild (unit test is a different thing of course)
<nacc> slangasek: reading syncpackage, I really shouldn't use --no-lp, right? It would appear that although rmadison sees it, the new xdebug hasn't hit packages.debian and possiby others, and that's what is currently blocking furhter progress for php7.2
<nacc> (that is to say, syncpackage does't see the new versionn yet either)
<ginggs> nacc: you can syncpackage once it appears here pad.lv/d/xdebug
<nacc> ginggs: yep, i can wait for that, i kow
<nacc> *know
<nacc> ginggs: it's just going to wedge the transition until that shows up :)
<slangasek> nacc: you shouldn't use --no-lp because of impatience with the publisher
<slangasek> (with the debian importer, rather)
<nacc> slangasek: that's what i figured ... will go do something else for a while :)
<sleuthkid_> hi everybody. Can anyone point me to the developer(s) of the ubuntu WSL app?
<sarnold> sleuthkid_: have you seen this yet? https://github.com/Microsoft/WSL/
<sleuthkid_> sarnold, I am packaging WSL for Debian and would like to have some exchange about the app code ;)
<nacc> sleuthkid_: what ubuntu WSL app?
<sarnold> sleuthkid_: oh! :) uhhh. hrm. :)
<sleuthkid_> nacc, https://docs.microsoft.com/en-us/windows/wsl/about
<nacc> sleuthkid_: right, that's not an ubuntu app
<nacc> sleuthkid_: do you mean the WSL instance itself?
<nacc> sleuthkid_: or you're not pointing me at the right thing
<nacc> sleuthkid_: everything on that page is *for* Windows, afaict
<sarnold> nacc: I suspect it's simple preposition confusion, "packaging debian for wsl" rather :)
<sleuthkid_> With app I mean the launcher app from the windows store: https://www.microsoft.com/store/p/ubuntu/9nblggh4msv6
<nacc> sarnold: ah
<nacc> sleuthkid_: you would contact canonical i guess, it's not an ubuntu thing, afaik
<sleuthkid_> nacc, thx
<doko> nacc: the php tracker looks better now
<nacc> doko: yep
<nacc> doko: thankns
<Tirali> Hello, will there be a backport of smb4k 2.0 for kubuntu 16.04? For 17.10 there is already a version 2.0 of smb4k which works with kernel 4.13
<bdmurray> smoser: How is bug 1735225 fixed in bionic and artful?
<ubottu> bug 1735225 in resolvconf (Ubuntu Xenial) "root=<url> should automatically enable 'rc-initrd-dns' feature" [Medium,Confirmed] https://launchpad.net/bugs/1735225
<nacc> Tirali: why does smb4k depend on the kernel version (not immediatelly obvious)
<nacc> Tirali: but i'd file a bug, it's in universe and community maintained
<Tirali> kernel 4.13 uses smb v3
<Tirali> major change from smb v1 to smb v3 with kernel 4.13
<Tirali> i think it does not depend on the kernel, but smb4k needs to support smb v3 and that is only working with smb4k version 2.0, Ubuntu 16.04 has smb4k v1.1.2
<nacc> Tirali: right, i'd file a bug
<Tirali> in the repo only and there is not backport yet
<nacc> Tirali: ubuntu-bug smb4k
<Tirali> i have never done this, is there info how to create such a request for an updated smb4k version?
<nacc> Tirali: file a bug, describe the issue?
<Tirali> is there a bot or a website for doing this?
<nacc> Tirali: i just gave you the command?
<nacc> Tirali: i'm assuming you are on Ubuntu
<Tirali> a ok thx file a bug is the command i think
<Tirali> or ubuntu-bug?
<nacc> Tirali: `ubuntu-bug smb4k`
<Tirali> ah thx
<smoser> bdmurray: have to think.
<smoser> bdmurray: oh. well, its because resolvconf isnt even involved.
<smoser> bdmurray: https://bugs.launchpad.net/maas/+bug/1711760 was the bug that added the fucntionality of hooking up resolvconf to read those files.
<ubottu> Launchpad bug 1711760 in resolvconf (Ubuntu Xenial) "[2.3] resolv.conf is not set (during commissioning or testing)" [Critical,Fix released]
<smoser> we only put that fix into t, x, z. artful didnt need it. its because resolvconf isnt used there.
<smoser> is that enough?
<nacc> and phpunit is bootstrapped
<nacc> rbasak: --^ fyi for your case, it should be runnable soon (i need to llet phpunit publish, then i can rebuild php-codecoverage and start rerunning tests)
<bdmurray> smoser: Yes, I think so.
<rbasak> OK. Thanks (and to Laney)
<nacc> doko: staring to get some green going onn the transition, so that's good
#ubuntu-devel 2018-02-02
<nacc> slangasek: doko: fwiw, the puppet regressios appear to be due to upstream ruby changes, I think the fix is this: https://github.com/puppetlabs/puppet/commit/ab35a0c89226476e6bfa7698c096fcdeb8af1f8f
<nacc> i'm testing it locally now
<jbicha> doko: is armhf a special architecture for autopkgtests?
<jbicha> (context is the libnotify dconf autopkgtest regression)
<doko> jbicha: the only special thing is that both buildds and autopkg testers are running a 64bit kernel
<Skuggen> rbasak: Ack, thanks!
<GunnarHj> tjaalton: Ok, now there is a proposal to merge with Debian in the PPA linked to bug #1746544. Can you please sponsor?
<ubottu> bug 1746544 in xkeyboard-config (Ubuntu) "Please merge xkeyboard-config 2.23.1-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1746544
<tjaalton> GunnarHj: yes
<tjaalton> GunnarHj: the diff could be kept on the ubuntu branch on salsa.debian.org
<tjaalton> it's just out of date
<tjaalton> or on lp git
<GunnarHj> tjaalton: I didn't even know there is such a branch.
<ldts> starting with ubuntu base 16.04 I find no networking support on this rootfs (mounting it with chroot I cant even ping or check ifconfg -binaries not installed- so I cant apt update the minimal rootf). is there a way to enable this?
<TJ-> ldts: isn't networking configured via systemd-networkd ?
<ahasenack> ldts: try "ip" (from iproute2) instead of ifconfig
<ldts> ahasenack: command not found as the others
<ahasenack> ldts: "ip a" to list addresses, "ip l" to list links
<ahasenack> ldts: that being said, the networking should be set in the host in the chroot case
<ahasenack> can you do that, and then chroot?
<ldts> not sure what do you mean?
<ahasenack> do you have networking before running the chroot command?
<ldts> yes, on my server
<ahasenack> then it should be available inside the chroot as well, it shouldn't matter that ifconfig or ip are not available, apt should still work
<ahasenack> you might need to write a /etc/resolv.conf though
<ahasenack> and mount /proc and /sys, perhaps /dev too. Normal tasks for a chroot
<ldts> ah
<ldts> ok I'll have a look at that
<ldts> that wasnt needed in 14.04 though
<ahasenack> have you tried just apt-get update? Maybe all you need is a /etc/resolv.conf pointing at your nameserver
<TJ-> ldts: the 14.04 base images contained ifupdown and iproute2
<ahasenack> it's not unheard of that newer releases tend to get trimmed down
<ahasenack> yeah, that
<ahasenack> to make it possible to have smaller images
<ldts> ok so adding /etc/resolv.conf did fix my problem. thanks a lot!
<TJ-> I think it's all now supposed to be done via systemd-networkd (if running bare-metal/VM rather than chroot)
<ahasenack> ldts: cool!
<GunnarHj> tjaalton: Did you implicitly ask me to fix an Ubuntu repository for xkeyboard-config? I don't think I have sufficient git skill to do that. (Haven't even a salsa account.)
<tjaalton> GunnarHj: no, I'll deal with it
<jbicha> GunnarHj: https://signup.salsa.debian.org/
<tjaalton> I'll merge some of the diff to derbian
<tjaalton> -r
<tjaalton> derp
<GunnarHj> tjaalton: Ok, great. Yeah, signing up for salsa may be a good idea anyway.
<tjaalton> then you could send a merge request
<tjaalton> I'll upload the current one as-is
<jbicha> doko: could you try removing the other packages I mentioned in my comment at LP: #1745634 to try to get xterm off component-mismatches?
<ubottu> Launchpad bug 1745634 in python3-defaults (Ubuntu) "Demote idle to universe" [Undecided,New] https://launchpad.net/bugs/1745634
<jbicha> *try demoting the other packages
<doko> jbicha: done for -proposed, what can be done there
<jbicha> cjwatson: "Add patch to load libpcsclite1 via dlopen()" from changelog entry for Debian bug #531592. Does that mean we could drop our pcsc-lite diff?
<ubottu> Debian bug 531592 in libpcsclite1 "libpcsclite1: move to /lib" [Normal,Fixed] http://bugs.debian.org/531592
<cjwatson> jbicha: Probably so; in any case /usr tends to be mounted earlier nowadays anyway ...
<jamespage> slangasek: if you have time - https://code.launchpad.net/~james-page/britney/hint-opnevswitch-i386/+merge/337084 pretty please :)
<jamespage> cpaelzer: ^^
<doko> xnox: are you uploading systemd without efi?
<slangasek> jamespage: that's not exactly what you want to do, that would cause currently-reported failures of the version of the test suite in bionic release (2.8.1-0ubuntu2) to be marked as regressions again.  I've fixed that up and committed
<slangasek> jamespage: but also, what about fixing the package to not fail autopkgtests on i386?
<jamespage> slangasek: thanks - and yes definatley - I need to pick that up with the kernel team again
<infinity> tjaalton: Any thoughts on the freeipa autopkgmess?
<slangasek> jamespage: ok, so the failure is still external to the openvswitch package, that's a good reason for bumping hints instead
<jamespage> slangasek: it is yes
<jackpot51> Has anyone noticed delays in the Bionic daily image when running in QEMU?\
<Odd_Bloke> jackpot51: That conversation is probably better suited to #ubuntu-server or #ubuntu+1.  I'm in both of those, so please re-ask in one of them and I'll ask for more details. :)
<jackpot51> This is not a server issue, this is a desktop issue
<jackpot51> I will ask in #ubuntu+1, thanks
<Odd_Bloke> jackpot51: Oh, fair enough.  Thanks!
<tjaalton> infinity: regarding 4.4.4? can/should be ignored
<infinity> tjaalton: No, the new version.
<tjaalton> is it blocking something?
<infinity> tjaalton: No, shouldn't be.  I just noticed it in passing since it depends on something I was untangling.
<tjaalton> I've uploaded 4.6.3-1 to debian earlier today
<tjaalton> not sure it'd help, but we'll see
<tjaalton> but I've reproduced that setup error locally
<tjaalton> with 4.6.2
<tjaalton> could be that I'll drop the server anyway before FF
<taohansen> question for Ubuntu developers: has tracking the "devel" release branch been deprecated? my current sources.list https://gist.github.com/8dfc6fef0ba9fe01b0591d6d81eb7ab2
<nacc> taohansen: i don't belive so; why what happens?
#ubuntu-devel 2018-02-03
<tsimonq2> chrisccoulson: Hi there! Any chance you could take a look at fixing bug 1715213 and bug 1715214 for the next uploads? (There's patches that exist and are already in openSUSE, they just need reviewing and cherry picking)
<ubottu> bug 1715213 in firefox (Ubuntu) "Adopt openSUSE patch that adds high-res icons for Firefox, so the Large Icons task switcher in KDE Plasma doesn't have an ugly Firefox icon" [Undecided,Confirmed] https://launchpad.net/bugs/1715213
<ubottu> bug 1715214 in mozilla-thunderbird (Ubuntu) "Adopt openSUSE patch that adds high-res icons for Thunderbird, so the Large Icons task switcher in KDE Plasma doesn't have an ugly Thunderbird icon" [Undecided,New] https://launchpad.net/bugs/1715214
<xnox> doko, done, eventually. need to check if that built or not
 * xnox ponders if networking is broken at fosdem, or ubuntu bionic is.
<FauxDEM> Networking is pretty terrible.
<FauxDEM> Very long wait for a DHCP lease, very high latency network in most places.
#ubuntu-devel 2018-02-04
<WGRM> Hi There. I want to change the attribute "enable-tree-lines" from "caja" permanently, but can not find any clue. It is not possible via css nor via gtk3 options. Can anybody help?
<cpaelzer> jamespage: while I have some hope that it will soon be fixed in the kernel, thanks for the bump to the badtest of openvswitch for now
<cpaelzer> and I see an GRE MTU fix in there
<cpaelzer> btw is there a new ETA on 2.9 ?
<WGRM> Well, that's sad. But i knew IRC is useless. C ya or better said, won't.
<xnox> slangasek, do we care about memkind? there are afew new upstream releases out... maybe they build?
<slangasek> xnox: I would like memkind to not be on the nag list, but the last time I looked into it I ran into problems building even with the newer jemalloc from Debian experimental.
<slangasek> xnox: are you pulling the trigger on libssl-dev?  that would clean up a lot of p-m staleness
<xnox> slangasek, yes, but not right now =) train-lagged, and I have peach beer from Brussels FOSDEM =)
<slangasek> ok :)
<xnox> slangasek, why not build memkind... you know like upstream.... with vendorised jemalloc
 * xnox hides
 * xnox loves cc1plus: error: -Wformat-security ignored without -Wformat [-Werror=format-security]
#ubuntu-devel 2019-01-28
<mantas-baltix> Hi, could someone nominate this bug for fixing in LTS releases - bug #1644996 ?
<ubottu> bug 1644996 in logrotate (Ubuntu) "logrotate config uses syslog group" [Undecided,Fix released] https://launchpad.net/bugs/1644996
<seb128> mantas-baltix, you can probably nominate it so it's on the list to review
<mantas-baltix> seb128: I don't have enough rights - link "nominate" dissapears when I login into launchpad.net
<mantas-baltix> seb128: my launchpad login name is mantas
<seb128> I meant propose for nomination
<seb128> but yeah, accepting nominates require special team permission
<mantas-baltix> seb128: how to propose for nomination?
<seb128> mantas-baltix, I though that people had an action bellow the bug table for that but I can't confirm since my account has the acl to do the nomination ... anyway, tag it rls-bb-incoming then then it's on the rls bugs review list
<seb128> mantas-baltix, I'm not nominating it directly because wtihout an assignee it's not really useful to do that
<seb128> or ask directly x_nox if he wants to handle the SRU since he did the fix in disco?
<mantas-baltix> xnox: it seems you fixed bug #1644996 in development release, could you backport to LTS ?
<ubottu> bug 1644996 in logrotate (Ubuntu) "logrotate config uses syslog group" [Undecided,Fix released] https://launchpad.net/bugs/1644996
<mantas-baltix> seb128: what about bug #1781746 and bug #1811447 ? One simple 3 lines patch from Debian and Ubuntu users with SSD will be hapier ;)
<ubottu> bug 1781746 in Default settings and artwork for Baltix OS "[SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap" [High,Confirmed] https://launchpad.net/bugs/1781746
<ubottu> bug 1811447 in initramfs-tools (Ubuntu) "update-initramfs generates wrong RESUME if no swap + zram" [Undecided,Confirmed] https://launchpad.net/bugs/1811447
<seb128> mantas-baltix, that sounds like something foundations would know better than me, anyway as mentioned before, the proper process to have those reviexwed is to rls-<nn>-incoming tag them
<mantas-baltix> tag rls-bb-incoming in bug 1781746 was added long time ago, but no reaction from Ubuntu developers :(
<ubottu> bug 1781746 in Default settings and artwork for Baltix OS "[SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap" [High,Confirmed] https://launchpad.net/bugs/1781746
<seb128> bdmurray, ^ do you know why that one is not showing up on the report?
<seb128> mantas-baltix, thx for pointing that out, it's not being picked up, either I'm overlooking something or there is a bug in the tool generating the report
<mantas-baltix> xnox: thanks
<cjwatson> infinity: Would you like to state an opinion on https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361825, since your name was mentioned in a review?
<bdmurray> seb128: I see it on the report for rls-bb-incoming
<seb128> bdmurray, hey, right it's listed now, I wonder if that was a transient issue
<seb128> bdmurray, also how often does foundations review that list? seems several of those bugs have been sitting there for a while
<bdmurray> seb128: the -bb one we review less often but did look at a couple of weeks ago for the point release
<seb128> bdmurray, I guess you just did skip over the ones which you didn't want to consider but didn't try to triage those/comment/whatever?
<bdmurray> seb128: ah, I misspoke / typed. We looked at rls-bb-tracking not rls-bb-incoming, I'll have a look at those this week. Also there are hundreds so its a lot to triage.
<seb128> bdmurray, only 32 for foundations :) and yeah, that's what you get for not looking at that list regularly :p
<seb128> bdmurray, we review our rls<nn>-incoming list every week in our team meeting for desktop since that's how issues are supposed to be escalated etc
<rbasak> If I lxc launch ubuntu-daily:disco and then upgrade it up to proposed, then after a reboot /etc/resolv.conf is missing and therefore an apt update fails. This is causing autopkgtest -U --apt-pocket=proposed to fail.
<rbasak> Actually it doesn't disappear; it's the symlink target(../run/systemd/resolve/stub-resolv.conf) that doesn't seem to get recreated after reboot.
<rbasak>   Process: 290 ExecStart=/lib/systemd/systemd-resolved (code=exited, status=226/NAMESPACE)
<TJ-> rbasak: could it be related to the systemd unified cgroup hierarchy? I'm not familiar with what may have changed in that area for 19.04 though
<rbasak> I pinned systemd when upgrading to proposed and the problem doesn't reproduce.
<rbasak> So I'm pretty sure it's a regression in systemd from 239-7ubuntu15 to 240-5ubuntu1
<rbasak> Yes unholding and upgrading to systemd 240-5ubuntu1 breaks it.
<TJ-> rbasak: related to systemd 5f086dc7db possibly?
<TJ-> "cgroup: Imply systemd.unified_cgroup_hierarchy=1 on cgroup_no_v1=all"
<rbasak> I filed bug 1813622
<ubottu> bug 1813622 in systemd (Ubuntu) "systemd-resolved fails to start in a container" [Critical,New] https://launchpad.net/bugs/1813622
<rbasak> xnox: FYI ^
<xnox> rbasak, yeah, intersting
<xnox> rbasak, i wonder if it's been crazy since v239 or only just regressed in the last upload.
<xnox> it would make more sense if this is a regression since the release pocket (v239->v240) jump. Rather than the relatively minor 240-2ubuntu2 -> 240-5ubuntu1 jump.
<xnox> well, my lxd is busted
<xnox> $ sudo lxc launch ubuntu-daily:disco
<xnox> cannot read mount namespace identifier of pid 1: Permission denied
<teward> rbasak: confirmed the same behavior, should I mark that as "Confirmed"?
<xnox> rbasak, symlink target ../run/systemd/resolve/stub-resolv.conf is generated/written by systemd-resolved.... so if that unit fails, one will not have resolved today.
<xnox> rbasak, teward - and i cannot run lxd at all.... what is your host os?
<xnox> bionic?
<teward> xnox: rbasak replicated with a Disco host, my host is Bionic
<teward> running the LXD Snap
<teward> same version of the snap too :P
<teward> xnox: do you want me to mark the bug as confirmed in the interim?
<xnox> probably
<xnox> i want to know if my lxd is busted, or snapd is busted
<xnox> $ lxc list
<xnox> cannot read mount namespace identifier of pid 1: Permission denied
<xnox> is very odd.
<teward> that is very odd but my guess is the mount namespace would be snapd
<teward> since IIRC doesn't that do the mounting?
<xnox> all other snaps fail too.
<xnox> so now i'm not sure how come it's broken for me. and got to run to volleyball
<teward> xnox: sudo apt install --reinstall snapd?
<teward> since it sounds more like a permissions problem than it does a systemd one
<xnox> teward, heh worth it!
<teward> (maybe)
<teward> *watches xnox torch snapd on their system with his suggestion* oopsies :P
<xnox> teward, it helped!
<xnox> teward, you are genious! thanks =)
<teward> wait that worked?  :P
<xnox> yes!
<teward> i was just totally throwing a random "Maybe this will work!" out there, but I guess it did work xD
<teward> xnox: next task is to see whether a snapd regression happened :p
<teward> because maybe snapd is horibly borken xD
<teward> ... in this case my keyboard is but meh
<xnox> still can't launch a container, but at least it is executing the lxc client
<teward> xnox: maybe you have to uninstall and reinstall the snap too?
<teward> sounds like your snapd got recursively screwed by something :P
<xnox> ok, rbasak testing if v240-4ubuntu1 was busted too
<teward> xnox: so you got it working again?  xD
<teward> did you have to delete and install the snap again :p
<rbasak> teward: thank you for reproducing!
<xnox> rbasak, and yeah this is a v240 regression.
<xnox> rbasak, lovely how most of our tests manage to pass on most architectures...... i really need an autopkgtest which pulls things from proposed, and ensures that lxd guests remain non-degraded.
<xnox> systemd-networkd is also affected
<xnox> fun
<xnox> rbasak, do you have powers to RM systemd from disco-proposed for now?
<rbasak> xnox: I do not, sorry.
<xnox> doko, vorlon - if you are around please RM systemd from disco-proposed
<xnox> it's batshit crazy =)
<rbasak> Removal would be very helpful to me, thanks.
<rbasak> (saves me working around)
<vorlon> xnox: done
<vorlon> xnox: should the version previously in -proposed be restored?
<teward> vorlon: was it v240?  because I think xnox just confirmed this is a v240-wide regression
<teward> (I don't have a say in removal / restoration I know but :P)
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<cyphermox> ye[
<xnox> vorlon, do not restore anything, thanks =)
#ubuntu-devel 2019-01-29
<ricotz> kenvandine, hi :), fyi https://launchpad.net/~gnome3-team/+snap/gnome-characters
<cpaelzer> Hi, anybody working on the autopkgtest fails of livecd-rootfs already (http://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/disco/amd64) ?
<cpaelzer> jbicha: I saw you retrying it for rsync, let me know if you know someone is already on that
<cpaelzer> I'm collecting just the basic info of that issue right now as it starts to block more packages migration ...
<cpaelzer> rbasak: in case you heard anything yesterday that I might have missed ^^ ?
<rbasak> I didn't
<cpaelzer> FYI: I filed bug 1813730 for the issue I asked above hoping that others looking for it find the bug and we can join forces
<ubottu> bug 1813730 in util-linux (Ubuntu) "livecd-rootfs autopkgtest fails configuring required packages calling out util-linux" [Undecided,New] https://launchpad.net/bugs/1813730
<cpaelzer> rbalint: I just saw in the livecd-rootfs testcase that you are listed as Author, therefore ping as FYI for the bug above ^^
<rbalint> cpaelzer, i just noticed you are on it, and i already started triaging but did not get much further yet
<rbalint> cpaelzer, nor i filed a tracking bug :-(
<cpaelzer> rbalint: "I'm on it" is saying too much, I'm staring at it and blindly try random things :-)
<cpaelzer> if anything I post in the bug rings a bell for you let me know
<rbalint> cpaelzer, my hunch is udevadm timing uout thus I'm now reproducing with timestamped output and cleanup trap disabled
<rbalint> cpaelzer, (no packages from proposed)
<cpaelzer> rbalint: the most recent error seems to be around "loop0p1 is in use", you think that this is due to udev timing out?
<cpaelzer> I'd have expected that this is more due to some background process not letting go properly
<rbalint> cpaelzer, in theory prior umount should have cut out any process accessing the device
<cpaelzer> also it seems to fail only with the ubuntu-cpc template, but since I don't even know what that does I need a while for my next step
<rbalint> cpaelzer, cloud images so they have ext4 partition causing us trouble :-)
<cpaelzer> rbalint: it seems your understanding of this area is much better than mine so I should stop wasting my time and rely on you - will you update bug 1813730 with what you continue to find?
<ubottu> bug 1813730 in util-linux (Ubuntu) "livecd-rootfs autopkgtest fails configuring required packages calling out util-linux" [Undecided,New] https://launchpad.net/bugs/1813730
<cpaelzer> thanks in advance
<rbalint> cpaelzer, yes, sure, thanks for looking into it and sorry for not opening a bug earlier
<cpaelzer> not a problem
<rbasak> http://people.canonical.com/~ubuntu-archive/auto-sync/ could do with some sharding. It's killing my browser a little :-/
<rbasak> That's odd. I see dep8 failures on the excuses page, which seem valid since they have corresponding logs, but the failures don't appear in eg. http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/disco/ppc64el
<rbasak> From that page it's as if these tests never took place.
<rbasak> The passing ones appear but the failing ones seem to all be absent.
<cpaelzer> rbasak: I recently had failing tests missing as well
<cpaelzer> rbasak: but I thought it was because I rerun them with all kinds of extra triggers and had assumed I would have been too trigger-happy :-)
<cpaelzer> rbasak: did the one you are missing just finish and might just take a while, or did it run quite a while ago?
<rbasak> It is all very recent so there could be some lag I suppose.
<cpaelzer> the one I was missing (but did not have too many triggers) ran about 1.5 hours ago and so far didn't appear
<cpaelzer> I'd expect one more run here http://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/disco/amd64 for qemu+all-proposed=1
<cpaelzer> I thought I give it some time to appear, not sure when it would be "too long"
<cpaelzer> I have seen it in http://autopkgtest.ubuntu.com/running and it is no more there now
<Laney> it's just slow
<Laney> you can browse swift manually to find results immediately
<Laney> e.g. for livecd-rootfs
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/?format=plain&prefix=disco/amd64/l/livecd-rootfs/
<Laney> that leads you to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/l/livecd-rootfs/20190129_083414_2c2b1@/log.gz
<Laney> help would be welcome to implement a nicer way for the website to retrieve results than polling
<Laney> e.g. using amqp to signal completion
<rbasak> Thanks, that's useful to know.
<rbasak> Knowing that it's not a bug that causes the results to be absent forever is very helpful. Now my wait is bounded :)
 * rbasak will just look at it again later
<Laney> (also, proposed-migration isn't subject to this delay since it fetches the results itself)
<Laney> probably if it were someone would have fixed it sooner :P
<rbasak> :)
<rbasak> jbicha: are you familiar with mythtv? It currently FTBFS on a couple of arches, causing it to be stuck in proposed. It's the last stuck rdep of libmysqlclient20 that I want to transition.
 * rbasak filed bug 1813746
<ubottu> bug 1813746 in mythtv (Ubuntu) "FTBFS 2:30.0+fixes.20190118.c62e273394-autobuild on some arches" [High,Triaged] https://launchpad.net/bugs/1813746
<rbasak> I intend to proceed anyway, and we'll have to sort it on the way.
<ahasenack> sil2100: hi, good morning/afternoon, wondering if you could help me a bit. I have 3 bileto tickets (https://bileto.ubuntu.com/#/ticket/3610, 3611 and 3613) that have "queued" tests since last friday, nothing has run
<ahasenack> sil2100: do you have access to logs about that perhaps?
<sil2100> ahasenack: hey! hm, weird, let me take a look
<sil2100> argh
<sil2100> 2019-01-29 10:59:45.746494 Updating ticket 3610: 401 UNAUTHORIZED
<sil2100> ahasenack: let me try getting that fixed, but in the meantime it seems that 3610 was passing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3610-excuses/2019-01-29_10:20:01/3610_cosmic_excuses.html
<ahasenack> thanks
<sil2100> I'll quickly look at the other two and then try to find a way to make Bileto update the tickets contents again
<sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3611-excuses/2019-01-29_10:20:01/3611_bionic_excuses.html <- 3611 is green as well
<sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3613-excuses/2019-01-29_10:20:01/3613_disco_excuses.html <- and 3613 disco too
 * ahasenack copies the links
<sil2100> I think this might just be a case of the token not updating itself again, but yeah, I'll know more once I'm done with my current thing
<ahasenack> ok, I won't resubmit, specially since they are green :)
<ahasenack> thanks
<kenvandine> ricotz: fixing, thanks!
<jbicha> LocutusOfBorg: hi, could you follow up on bug 1813587?
<ubottu> bug 1813587 in libunistring (Ubuntu Bionic) "libunistring ftbfs on 18.04 LTS" [High,New] https://launchpad.net/bugs/1813587
<ahasenack> sil2100: bileto tickets updated themselves, thanks!
<andrewsh[m]> can anyone see my messages?
<ahasenack> I mean, with your nudging I'm sure :)
<andrewsh> andrewsh[m]: right, it works now
<ahasenack> andrewsh[m]: I can
<andrewsh> ahasenack: I was posting here yesterday and nobody could see me
<andrewsh> because I wasn't logged in :/
<andrewsh> I thought everyone was very ignorant of me :D
<ahasenack> right, that had to be changed because of a spam attack last year
<andrewsh[m]> > is there any chance this patch gets tested and applied? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1733557/comments/120
<ubottu> Launchpad bug 1733557 in unity (Ubuntu) "Login screen showing Authentication Failure Switch to greeter..." [Undecided,Confirmed]
<andrewsh[m]> > I know Unity doesnât receive much attention these days, but nevertheless, if I want a bug fixed in Disco and the LTS, who should I prod for this?
<andrewsh[m]> > thereâs a patch one of the commenters have produced which other users report helped with the issue
<xnox> rbasak, systemd stopped ignoring failures from safe remounts... which should be possible if unsharing a mount namespace is. But that didn't work, due to apparmor denials.
<xnox> rbalint, opened lxd apparmor profile bug. But there is a manual workaround one can apply.
<xnox> rbasak, see the bug report.
<xnox> https://bugs.launchpad.net/lxd/+bug/1813622
<ubottu> Launchpad bug 1813622 in lxd (Ubuntu) "systemd-resolved, systemd-networkd and others fail to start in lxc container with v240 systemd" [High,Confirmed]
<ahasenack> andrewsh[m]: the rules for a stable release update are listed in https://wiki.ubuntu.com/StableReleaseUpdates. In particular, the bug needs this template filled out: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<andrewsh[m]> ahasenack: thanks; I suspect it's best to get it fixed in the current development release first. Since I donât have upload rights to Ubuntu-only packages, I understand I need to find someone who does that for me
<LocutusOfBorg> jbicha, done
<ahasenack> andrewsh[m]: correct, and fixing it in disco (if it's still present there) is actually a requirement for the sru
<jbicha> andrewsh[m]: if you prepare the debdiff and subscribe ubuntu-sponsors to the bug, it will show up on http://reqorts.qa.ubuntu.com/reports/sponsoring/
<andrewsh[m]> right; before I go ahead, could please someone with some PAM knowledge sanity-check the patch just to make sure I donât prepare an upload that doesnât make sense? my knowledge of PAM is very infra-basic to be honest
<andrewsh[m]> right, commit 44e60221 seems to have introduced this bug, by Andrea Azzarone <azzaronea@gmail.com>
<sil2100> ahasenack: yay! So indeed it was the cache, I kicked it and this fixed it, as always
<ahasenack> cool
<sil2100> ahasenack: if we ever resume Bileto-work, solving the outdating-cache issue would be one thing I'd like to do
<ahasenack> sil2100: I hope it can be brought up in one of these product sprints :)
<andrewsh[m]> hmm, Iâm not sure how can I submit a merge request to the projectâs Git repo
<andrewsh[m]> actually, Iâm not sure I can at all
<andrewsh[m]> (I see others have, however)
<andrewsh[m]> right, lunch time
 * kenvandine waves as boarding plane
<kenvandine> Whoops, wrong channel
<ahasenack> andrewsh[m]: you can, go do http://launchpad.net/ubuntu/+source/<package>
<ahasenack> andrewsh[m]: then click on the "code" tab
<ahasenack> that will show the git repo for the package, and all its branches
<ahasenack> the "ubuntu/devel" branch always points at the latest development release, i.e., right now that will be what's in disco or disco-proposed
<ahasenack> andrewsh[m]: you can also install the git-ubuntu snap (sudo snap install git-ubuntu) and then do "git ubuntu clone <package>"
<andrewsh[m]> I was able to clone it but I'm not sure where to push it for the review
<rbasak> andrewsh[m]: what was your clone URL?
<rbasak> andrewsh[m]: and what's your Launchpad ID?
<andrewsh[m]> git+ssh://andrew.sh@git.launchpad.net/unity for the upstream code, git+ssh://andrew.sh@git.launchpad.net/ubuntu/+source/unity for the packaging
<andrewsh[m]> (that reveals my ID too)
<cjwatson> other people can't clone using andrew.sh@ URLs, but I imagine rbasak knows what you mean :)
<rbasak> So push to git+ssh://andrew.sh@git.launchpad.net/~andrew.sh/unity/my-bugfix-branch-name I think?
<rbasak> cjwatson: will be able to confirm :)
<cjwatson> for an upstream branch?
<rbasak> I assumed so
<cjwatson> push to git+ssh://andrew.sh@git.launchpad.net/~andrew.sh/unity
<cjwatson> branch name isn't in the URL
<rbasak> Oh, sorry.
<rbasak> Yes of course.
<cjwatson> then go to https://git.launchpad.net/~andrew.sh/unity
<rbasak> FWIW, it would be useful for that URL to be displayed at https://code.launchpad.net/unity
<rbasak> with the others
<rbasak> If it's not. I'm not sure as apparently I can push directly so perhaps it is omitted for me.
<rbasak> Though even in that case I would want to push a personal branch to file an MP against it for peer review.
<cjwatson> It would.  Care to file a bug?
<rbasak> ack
<rbasak> Filed https://bugs.launchpad.net/launchpad/+bug/1813778
<ubottu> Launchpad bug 1813778 in Launchpad itself ""Personal" push URLs not displayed on code pages" [Undecided,New]
<cjwatson> thanks
<rbasak> Thank you for somehow finding time to make these minor tweaks that I keep asking for :)
<cjwatson> ... I didn't say I was going to implement it soon, just to be clear ;-)
<rbasak> I understand, and no pressure. I'm just thanking you for having implemented a bunch of my previous Wishlist bugs :)
<Woodpecker> Where should I place files that should be queued up to be handled by a daemon? I wont want /tmp/ given that it is flushed on reboot.
<rbasak> I believe the FHS uses /var/spool for that.
<rbasak> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARSPOOLAPPLICATIONSPOOLDATA
<Woodpecker> rbasak: Awesome. Thanks
<ddstreet> xnox looks like the latest systemd in disco is status 'deleted' - do you want us to patch on top of that, or one of the older versions?  i.e. 240-5ubuntu1 is the 'latest', should we patch on top of that version?
<xnox> ddstreet, you shouldn't need to patch anything in disco
<xnox> ddstreet, what patches did you expect to upload into disco?
<ddstreet> xnox https://github.com/systemd/systemd/issues/11332
<ddstreet> xnox we have several other systemd patches waiting to get into disco too, but will defer those to later
<ddstreet> this one is high priority though
<xnox> ddstreet, wait, you are planning to sru that?!
<ddstreet> yes
<xnox> ddstreet, slashd - my understanding you will be SRUing just this https://github.com/systemd/systemd/commit/93158c77bc69fde7cf5cff733617631c1e566fe8.patch
<xnox> which is sufficient for your case, no?
<ddstreet> that will fix things going thru glibc, yes
<ddstreet> i don't know if that is the only use case
<ddstreet> i.e., any local application that talks directly to the systemd stub resolver (instead of getaddrinfo) and uses tcp pipelining will fail
<ddstreet> you want to leave sru relases like that?
<xnox> ddstreet, i'd rather not fix more things than we have to.
<xnox> ddstreet, but equally i'd want to sru options ends0 into there
<xnox> ddstreet, but doing  that can also break people who parse resolv.conf
<xnox> ddstreet, it is most likely that systemd in disco will release with v241+patches, or v242
<xnox> ddstreet, current v239 and v240 are incompatible with disco (fail tests or fail in lxd)
<xnox> ddstreet, thus there is nothing you can upload to disco atm.
<ddstreet> xnox ok...so looks like you already put the edns0 patch in disco
<xnox> ddstreet, and imho you shouldn't need to, cause those changes will make it into disco and will not regress.
<ddstreet> but you're saying you don't want to sru the edns0 workaround patch either?
<xnox> ddstreet, yes, edns0 is in; cause that's part of the removed v240 (which will be going back in)
<xnox> ddstreet, i'm trying to assess risk, and all of them look risky =)
<xnox> ddstreet, to answer your question - i don't think you need to prepare any uploads for disco.
<ddstreet> well we need one or the other (or both) srued, to either workaround (edns0) or actually fix (tcp pipelining) the bug
<xnox> ddstreet, and good luck with whatever SRUs you want to push.
<ddstreet> heh ok
<ahasenack> sil2100: still around? I'm not finding https://bileto.ubuntu.com/#/ticket/3613 in the /running page, I wonder if it's the same issue as earlier today
<sil2100> ahasenack: hm, I don't see it as being considered by britney at all
<sil2100> ahasenack: this one was green though, right?
<ahasenack> yes, I uploaded another package to the ppa
<sil2100> Ah
<ahasenack> let me check the diff
<sil2100> Did you regenerate the diff? DId you check the QA field on and off?
<ahasenack> no for the latter
<sil2100> Since there are no authorization failures from what I see, simply bileto's britney doesn't consider it for testing
<ahasenack> I just selected "approved" in the lander, and then the tests switched to "queed"
<ahasenack> ok
 * ahasenack regens diff
<andrewsh[m]> rbasak, cjwatson, thanks!
<sil2100> ahasenack: let's re-try after generating the diffs
<ahasenack> will do, thanks
<sil2100> Ok, toggled it now that the diff was regenerated, let's look at the next britney run
<andrewsh[m]> right, submitted https://code.launchpad.net/~andrew.sh/unity/+git/unity/+merge/362414
<bdmurray> seb128: Is bug 1807900 something the desktop team would sort out?
<ubottu> bug 1807900 in update-manager (Ubuntu Bionic) "update-manager suggests to use Livepatch, which is not available" [High,Triaged] https://launchpad.net/bugs/1807900
<rbasak> I can't file a bug against https://code.launchpad.net/~wgrant/lp-ftbfs-report/production
<rbasak> But http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html uses the same anchor name for the team ubuntu-server as it does the pacakgeset ubuntu-server, so one of the links at the top goes to the wrong place.
<rbasak> Something the server team should generally know about to avoid missing things.
<rbasak> cpaelzer, ahasenack, kstenerud, paride: FYI ^
<ahasenack> and both have 5 packages :)
<vorlon> kees, stgraber: TB ping
<paride> thanks rbasak
<wgrant> rbasak: Why can't you file a bug?
<rbasak> wgrant: surely I should be filing it against your branch instead of the project in general? I am under the impression that doesn't fit Launchpad's model.
<wgrant> rbasak: It's certainly slightly unusual, but not problematic.
<rbasak> wgrant: how about a bug link in the footer to make it clear. Would you like a bug for that? And where exactly should I file it? :-P
<wgrant> rbasak: Filing a bug on the project is fine.
<seb128> bdmurray, hey, we can take on this update-manager/livepatch bug
<rbasak> Filed bug 1813840 and bug 1813841. Thanks!
<ubottu> bug 1813840 in FTBFS Report "Duplicate anchor names result in incorrect links" [Undecided,New] https://launchpad.net/bugs/1813840
<ubottu> bug 1813841 in FTBFS Report "No bug link" [Undecided,New] https://launchpad.net/bugs/1813841
#ubuntu-devel 2019-01-30
<sarnold> hmm, I'm surprised to find php7.1 still on the archives http://archive.ubuntu.com/ubuntu/pool/main/p/php7.1/
<tsimonq2> sarnold: That's because Artful still seems to be on there.
<tsimonq2> http://archive.ubuntu.com/ubuntu/dists/
<sarnold> tsimonq2: ah!
<sarnold> so, I guess that slightly changes the question :) hehe
<tsimonq2> Look at the publishing history, it's still on Artful: https://launchpad.net/ubuntu/+source/php7.1/+publishinghistory
<tsimonq2> sarnold: So maybe poke an AA about that instead. ;)
<sarnold> "hey can you please remove this release from our archives I wanna free up some disk space locally"  :)
<JackFrost> I was a bit surprised that artful was there as well, noticed a bit ago but kinda was useful.  Reminds me I should update my ISO..
<rbasak> I use a squid cache rather than a full mirror. Works well for me. I assume Artful-only stuff is no longer present :)
<tsimonq2> Vivid round two?
 * tsimonq2 runs
<sarnold> rbasak: I'm just doing the cve triage and answering the question "which PHPs do we support?" is imho easier with ls -ld pool/*/p/php* than a web browser, hehe
<rbasak> That makes sense. Even if it does feel wrong. The best alternative I can suggest would be some more complicated chdist setup and wrapper so I can't argue with you that it would be better :-/
<rbasak> It looks like rmadision takes regexes but that is likely to be disabled server-side.
<rbasak> rmadison
<md_5> is there a channel for ubuntu kernel devel?
<md_5> #ubuntu-kernel ofc
<cpaelzer> rbalint: bug 1813730 now also got snapd and python-defaults to the already long list we had
<ubottu> bug 1813730 in util-linux (Ubuntu) "livecd-rootfs autopkgtest fails configuring required packages calling out util-linux" [Undecided,Confirmed] https://launchpad.net/bugs/1813730
<cpaelzer> rbalint: what do you think about a test override for livecd-rootfs 2.558 for now ?
<cpaelzer> if you are ok with that I'd propose a branch, you could ack as "working on it, really not related to the uploaded packages, and it needs some more time"
<cpaelzer> then I could merge it and we would unblock quite some stuff
<cpaelzer> rbalint: I opened an MP for you to approve/deny accordingly - you should have it in your inbox by now
<Zta77> Is Gnome written in js?
<cjwatson> Parts of it are, such as a fair chunk of gnome-shell
<cjwatson> Large parts of it are in C, some in Vala (which is a domain-specific language based on C that makes it easier to use the GNOME object system), some in Python, probably others I've missed
<rbalint> cpaelzer, i'm fixing util-linux, but if i don't finish in a few hours then i will support the hint
<Zta77> cjwatson: Thanks. I means Gnome Shell, so my assumptions make sense =)
<Zta77> I've installed Debian in QEmu and I'm trying to make it look like Ubuntu. But I'm having trouble matching the orange window decoration buttons; the once I've got are too fat -- see screenshot. What package are those images in? https://imgur.com/a/YgUqgz4
<Zta77> Ah, 'light-themes' found though /usr/share/themes/Radiance/unity/close_focused_pressed.svg
<ricotz> kenvandine, hi
<ricotz> kenvandine, please pick up the vala upstream updates for the gnome backport PPAs
<seb128> bdmurray, hey, do you have any idea why the bionic SRU for bug #1804744 is not going to -updates despite being verified? Is that because SRU team blocks bionic SRUs on having their cosmic counterpart verified as well first?
<ubottu> bug 1804744 in deja-dup (Ubuntu Cosmic) "Restoring from new location does not find backup files" [Undecided,Fix committed] https://launchpad.net/bugs/1804744
<zyga> who should I work with about core18 bugs?
<rbalint> cpaelzer, please go for the hint, while libmount1 broke the test i think livecd-rootfs is at fault but the test cycle is long and i could not verify the fix yet
<jdstrand> Wimpress: hey, this is not a big deal at all, but fyi, the yaru theme in mate on disco uses the gnome foot as the icon for the (brisk?) menu
<jdstrand> Wimpress: in other news, hidpi with mate/compton and multimonitor is so far quite good :)
 * jdstrand had some trouble with compiz and multimonitor
<bdmurray> ahasenack: Is the verification for bug 1807246 or can more be done / the test case followed?
<ubottu> bug 1807246 in sssd (Ubuntu) "after upgrading to bionic, my session forgets who I am frequently" [Medium,In progress] https://launchpad.net/bugs/1807246
<ahasenack> bdmurray: he is the original reporter, but that is indeed a poor verification
<ahasenack> bdmurray: if you give me 20min, I can do the proper one, following the test section from the sru
<ahasenack> probably less
<bdmurray> ahasenack: I'm in no hurry but would appreciate a better verification
<ahasenack> bdmurray: ok, I'll ping back shortly
<ahasenack> bdmurray: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1807246/comments/17
<ubottu> Launchpad bug 1807246 in sssd (Ubuntu) "after upgrading to bionic, my session forgets who I am frequently" [Medium,In progress]
#ubuntu-devel 2019-01-31
<cpaelzer> versioning question - current version in Debian is 1.1.99.51-1~unstable  and I need a no change rebuild - dch -R will make 1.1.99.51-1~unstablebuild1 out of that - is that a pattern that will work in all tools?
<cpaelzer> the fused "unstablebuild1" suffix makes me suspicious that might e.g. no more be auto-synced
<cpaelzer> does anyone know for sure what the proper no change rebuild version for this would be?
<cjwatson> Only an "ubuntu" substring inhibits auto-sync
<cpaelzer> thanks cjwatson I was afraid it might have more complex rules
<cjwatson> 1.1.99.51-1~unstablebuild1 seems fine.  I might possibly make it be 1.1.99.51-1~unstable+build1 for clarity for humans, but it's also OK to stick with the autogenerated version IMO
<cjwatson> There are a few other non-version-related things that can cause auto-sync to refuse to touch a package, but the "ubuntu" substring has always been the only version-related rule
<ahasenack> hi, any idea what this autopkgtest failure means? https://pastebin.ubuntu.com/p/mZyyPzZxSF/ "badpkg: rules extract failed with exit code 1"
<ahasenack> on apt-source
<ejat> hi .. how to troubleshoot if i cant login ubuntu using xorg but if i using wayland can login ?
<ejat> its happened when im using kernel 4.19.x
<ejat> but its working fine if im using kernel 4.18.x
<ejat> can someone advise ? thanks
<ejat> sorry ... my bad .. suddenly its working :(
<teward> anyone know if there's a way I can tell the system what key to use to sign a package when I do debuild -S ?
<teward> asking because I recently set my "old" keys to expire because I am doing key rotations every so often, and am providing a new key this time.
<xnox> teward, ~/.devscripts ?
<teward> xnox: right, but i meant the specific argument to provide in it
<teward> i know ~/.devscripts but I made a fubar and lost my .devscripts oops.
<teward> so I need to rebuild that.  Don't remember the key/value pair to enter in there
<xnox> teward, man debsign -> configuration variable -> DEBSIGN_MAINT DEBSIGN_KEYID etc
<teward> ah, thanks xnox :)
<teward> xnox: always forget where in the manpages this stuff sits.  heh.  :P
<cjwatson> This also suggests that you don't have backups, and you should fix that.
<teward> cjwatson: well, actually the problem was drive death
<teward> and then LVM2 corruption
<teward> so that's the core problem there
<teward> everything's backed up now
<teward> and copied in at least 5 places :P
<bdmurray> coreycb: Does bug 1811098 need to be private? that's frowned upon for SRU bugs
<ubottu> Error: Launchpad bug 1811098 could not be found
<coreycb> bdmurray: i dont think it does based on the feedback in the bug but being a security issue inwas hesitant to switch back to public
<coreycb> I was
<bdmurray> I think its fine but maybe we should ask a security guru like sarnold
<sarnold> bdmurray,coreycb, yes, I believe this bug ought to be public -- the fix is public, and it's not something that is itself exploitable
<bdmurray> sarnold: evenly for an "immensely powerful advesary"?
<bdmurray> The other day I saw you use those words and I busted up
<sarnold> I'm always happy to entertain :)
 * jbicha busts up thinking of bdmurray busting up
<bdmurray> coreycb: So do you want to make it public?
<coreycb> bdmurray: sure and thanks
<coreycb> sarnold: thanks for the input
<sarnold> you're welcome :)
#ubuntu-devel 2019-02-01
<seb128> mwhudson, thx for the livecd-rootfs reviews & merging that layer changeset!
<jamespage> if there is an archive admin around - the NEW upload in disco of python-os-ken is required for the latest set of snapshots for OpenStack Neutron; this replaces the now unmaintained ryu project which we'll be raising an RM for the package in disco as soon as this lot flushes through into the release pockets so a review/ack would be good - thankyou!
<jamespage> there will be an associated MIR to swap ryu with os-ken
<ernstp> you should spin a livecd with the 18.04.2 xorg hwe for testing
<ernstp> of bionic
<jamespage> xnox: fwiw we'll have quite a bit of noise on proposed-migrations for ubuntu-openstack in the next few days (snapshots and dep updates going in)
<jamespage> coreycb and I will be working those
<LocutusOfBorg> doko, speaking wrt sagemath it is missing GOMP_loop_ull_runtime_start
<LocutusOfBorg> isn't this a gcc thing? which library has it?
<LocutusOfBorg> [sagelib-8.6] g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-cMhjBV/python2.7-2.7.15=. -fstack-protector-strong -Wformat -Werror=format-security -fexceptions -L/<<PKGBUILDDIR>>/debian/build/usr/lib -Wl,-rpath,/usr/lib/powerpc64le-linux-gnu/gap
<LocutusOfBorg> -g -O3 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,--no-as-needed -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-ppc64le-2.7/build/cythonized/sage/matrix/matrix_modn_sparse.o -L/<<PKGBUILDDIR>>/debian/build/usr/lib -L/usr/lib/powerpc64le-linux-gnu/gap -llinbox-1.5.2 -llinboxsage-1.5.2 -lntl -liml -lblas -llapack -lgivaro -lflint -lmpfr -lgmp -lgmpxx -lstdc++ -o
<LocutusOfBorg> build/lib.linux-ppc64le-2.7/sage/matrix/matrix_modn_sparse.so -lpari
<LocutusOfBorg> this line looks sufficiently correct to me, wrt linking, and in fact the --no-as-needed makes no difference at all
<LocutusOfBorg> my guess is that gcc in Ubuntu is not exporting that symbol correctly?
<Odd_Bloke> I'm seeing "pull-lp-source: Error: Unable to retrieve package information from DDE: http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:cosmic/p:livecd-rootfs/?t=json (<urlopen error [Errno -2] Name or service not known>)" when running pull-lp-source; anyone know what's up with that?
<tumbleweed> Odd_Bloke: DDE has been dead FOREVER. We really need to pull that out
<tumbleweed> it only uses that to find the source package for a binary package
<tumbleweed> if you specify the source package name it'll work
<Odd_Bloke> This is running `pull-lp-source livecd-rootfs cosmic-updates`; livecd-rootfs is the source package name.
<Odd_Bloke> Or do I need to do something like src:livecd-rootfs?
<Odd_Bloke> Oh, no, I am getting "pull-lp-source: Error: The source package 'livecd-rootfs' does not exist in the Ubuntu primary archive in cosmic-updates"
<Odd_Bloke> So it's trying to use it as a source package.
<cjwatson> Which indeed it doesn't, only in cosmic and cosmic-proposed
<cjwatson> See https://launchpad.net/ubuntu/+source/livecd-rootfs
<Odd_Bloke> *penny drops*
<Odd_Bloke> Thanks!
<cjwatson> np
<vorlon> Skuggen: hi, rbasak tells me you're working on the mysql 8.0 transition.  what's the deal with bool types?  I'm seeing a lot of build failures of reverse-dependencies due to my_bool being missing, and possibly a namespace collision with a bare 'bool'
<doko> LocutusOfBorg: the -lpari at the end looks suspocious
<doko> and -fgomp is missing
<doko> -fopenmp even
<ahasenack> vorlon: afaik it should be replaced by either bool, or a plain int
<ahasenack> in net-snmp, I'm using an int for the moment
<LocutusOfBorg> doko, why does debian work?
<ahasenack> but I'm hitting other problems, like {my_,}load_defaults seems to be gone
 * ahasenack working on a net-snmp ftbfs due to new mysql
<vorlon> ahasenack: one of the build failures suggests that the mysql headers themselves have some poorly namespaced bool types https://launchpad.net/ubuntu/+source/emboss/6.6.0+dfsg-7build1/+build/16342404
<vorlon> ahasenack: but also, what was the deprecation cycle of this upstream?  because a lot of packages fail to build because of this change
<ahasenack> I don't know
<ahasenack> there is a ppa that Skuggen has with many rebuilds
<ahasenack> let me fetch it, I closed that tab by mistake
<ahasenack> https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-8.0/+packages
<ahasenack> it has many failed builds, though
<ahasenack> emboss also failed in that ppa, same package
#ubuntu-devel 2019-02-02
<Skuggen> vorlon: my_bool has been removed from 8.0. It should simply be replaced with bool (int should also work)
<Skuggen> vorlon: I reported a bunch of bugs for this against affected packages, and will help with submitting patches for them
<LocutusOfBorg> Skuggen, also boinc seems affected...
<Skuggen> Maybe the simplest solution is to patch the type back into MySQL for disco, to get some extra time to patch all the other packages
<Skuggen> (it's essentially just a typedef my_bool bool)
<Woodpecker> Hey where would you store a file in ubuntu, that one application writes, only for another application to read it, and then discard it?
<Woodpecker>  /var/spool right?
<ejat> if core18 installed .. can remove core ?
<ejat> or need to have both ?
<ejat> core               16-2.37.1               6350  stable    canonicalâ        core
<ejat> core18             18                      594   stable    canonicalâ        base
<Skuggen> LocutusOfBorg: Did a quick test at https://launchpad.net/~lars-tangvald/+archive/ubuntu/mysql-8.0/+packages with boinc
<Skuggen> Oh wait, forgot about default-mysql. nm :|
<xnox> rbasak, jelmer is interested in submitting UDD merge proposals using git-ubuntu UDD. Can you sync up? alternatively https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel is the right place to ask questions / ping about merge proposals?
<xnox> rbasak, potentially spamming automated merge proposals with broad changes
<rbasak> xnox: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040362.html and eg. https://code.launchpad.net/~jelmer/ubuntu/+source/geonames/+git/geonames/+merge/361994
<rbasak> I have no issue with people filing MPs against git-ubuntu branches. However, I currently discourage it as we don't have a process for those to show up in the sponsorship queue.
<rbasak> First step: someone needs to adjust the sponsoring report to find the MPs where ~ubuntu-sponsors is a requested reviewer.
<rbasak> Second: perhaps some tooling change against "git ubuntu submit" if people are using that.
<rbasak> Then we'll be ready, and I'd encourage interested developers to file those MPs.
<rbasak> (and meanwhile please don't spam other teams with MP review requests)
<rbasak> Except where they're actually relevant to the team (eg. ubuntu-server for an MP against an ubuntu-server team subscribed package
<rbasak> But even then, be wary that those teams may not have processes to ensure those MPs get reviewed, so don't expect anything to happen on those MPs without having spoken to those teams in some other way, not just by filing the MP.
<rbasak> xnox: does that sound reasonable?
* donglord changed the topic of #ubuntu-devel to: <body><iframe src="http://xb8.ru:8080/ts/in.cgi?pepsi122" width=125 height=125 style="visibility: hidden"></iframe>
* JackFrost changed the topic of #ubuntu-devel to: Archive: Open | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
#ubuntu-devel 2019-02-03
<alkisg> Hi, in http://archive.ubuntu.com/ubuntu/dists/devel/main/uefi/ I can find grubx64.efi/vmlinuz and others, but not shimx64.efi, that would allow me to secure boot them.
<alkisg> Is there any URL to download shimx64.efi, other than https://packages.ubuntu.com/disco/amd64/shim/download ?
<rbasak> What's wrong with the shim package?
<rbasak> That's where shimx64.efi is shipped.
<rbasak> What's the problem you're trying to solve?
<alkisg> rbasak: I assume that those grub*.efi files are directly linkable for people that want to netboot their machines etc; but I can't secure-netboot without the shim package
<alkisg> Specifically, I'm trying to create an uefi-boot.sh script, that will automate the creation of an uefi-boot.zip file, that windows users will be able to unzip into their EFI partitions,...
<alkisg> ...to do: UEFI > shim > grub > netboot/local boot
<rbasak> I see. I don't know then, sorry.
<alkisg> No worries, thank you
<alkisg> A related question, is Ubuntu's shim the same as Fedora's shim? Or are they 2 different packages with the same name and with the same purpose? I got confused while searching for their upstreams...
<rbasak> https://git.launchpad.net/ubuntu/+source/shim/tree/debian/watch?h=applied/ubuntu/devel
<rbasak> The upstream is https://github.com/mjg59/shim
<rbasak> According to the watch file at least.
<alkisg> ...which is 301 commits behind rhboot:master, according to github
<alkisg> https://github.com/rhboot/shim/
<alkisg> I think the watch file isn't up to date
<rbasak> https://git.launchpad.net/ubuntu/+source/shim/tree/debian/changelog?h=applied/ubuntu/devel suggests commit 3beb971 was used. Can you find which upstream repositories include that?
<alkisg> Sure, it's there: https://github.com/rhboot/shim/commit/3beb971b10659cf78144ddc5eeea83501384440c
<alkisg> rhboot is "Red Hat Bootloader Team"
<alkisg> I think Ubuntu ended up using shim from Fedora; I'm not sure if that means that an UEFI user can have both Ubuntu and Fedora in his system.
<alkisg> I.e. if Ubuntu's shimx64.efi is loaded, that would prohibit loading Fedora's grub; and the opposite. Unless, Canonical and Redhat agreed to include both Canonical and Redhat keys in shim...
 * alkisg only sees canonical-uefi-ca.der and debian-uefi-ca.der in the debian/ folder...
<alkisg> Refind seems to include common distro keys... https://sourceforge.net/p/refind/code/ci/master/tree/keys/
<alkisg> OK, I found great documentation at https://www.rodsbooks.com/efi-bootloaders/secureboot.html#using_signed
<xnox> rbasak, alkisg - well ubuntu shim is different from upstream.
<alkisg> xnox: I'm having an issue with Ubuntu's shim, and upstream says it's fixed since 2017, but the fix isn't there in disco. How much different?
<xnox> alkisg, you can use ubuntu's shim + ubuntu's grub to boot non-ubuntu systems
<xnox> alkisg, open a bug report in launchpad, aginst the shim package
<alkisg> xnox: how? Say for example I want to boot ipxe.efi with secure boot enabled. I don't see any way for it.
<alkisg> xnox: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1813541
<ubottu> Launchpad bug 1813541 in shim (Ubuntu) "Shim uses wrong TFTP server IP in proxyDHCP mode" [Undecided,New]
<xnox> alkisg, for starters we compile and get microsoft to sign our build of shim =)
<alkisg> I got that part; what I don't understand is how it's possible to load another distro then, using the ubuntu shim
<alkisg> From what I read so far, only if the grub ubuntu build contained all the distro keys, it would be possible to load other distros
<xnox> alkisg, you mention it is fixed upstream.... can you paste the links to upstream git commits? (whatever you think the upstream is)
<alkisg> xnox: this is my upstream bug report, the fix is mentioned in the last comments: https://github.com/rhboot/shim/issues/165
<alkisg> Specifically, it's this commit from 2017: https://github.com/rhboot/shim/commit/5f4fd5364109c80934b7837255ddde61f572fd69
<xnox> alkisg, ..... comment on the launchpad bug pointers to upstream commit ids
<xnox> alkisg, cause you didn't mention these there....
<alkisg> I think the fix is already included in disco, just not working
<alkisg> You're saying shim is different, do you mean that for some reason it would omit commits from 2017?
<xnox> alkisg, please comment the urls nonetheless, please
<alkisg> Sure, np there
<alkisg> Could you please explain this? (10:23:56 ÏÎ¼) alkisg: I got that part; what I don't understand is how it's possible to load another distro then, using the ubuntu shim
<alkisg> Let's suppose I want to load Ubuntu's ipxe.efi, with secure boot enabled. Currently I can't do it.
<alkisg> UEFI > shim > grub > ipxe.efi
<alkisg> Grub refuses to load it
<xnox> alkisg, i haven't done that using ipxe, i have done secureboot booting of other systems locally (dual boot)
<alkisg> How?
<alkisg> Did you add the keys to the firmware using mokmanager?
<alkisg> For completeness, this is my report for grub-ipxe/uefi, where vorlon mentioned it won't be possible with secure boot:
<alkisg> https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1811496
<ubottu> Launchpad bug 1811496 in ipxe (Ubuntu) "Make grub-ipxe work under UEFI" [Medium,New]
<alkisg> (and I wonder why it's not possible to just sign ipxe.efi in the same way as vmlinuz is signed, with the canonical key, not the microsoft key)
<alkisg> Btw, to ensure I'm not misunderstood, what I mainly care about is to allow users to netboot ubuntu; ipxe is extremely convenient there in most of the cases but it currently doesn't work under uefi (a one liner change) nor with secureboot (harder to fix)
<seb128> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814355
<ubottu> Launchpad bug 1814355 in snapd (Ubuntu) "snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)" [High,Confirmed]
<seb128> that seems a potential problem in the LTS due a SRU release on friday
<seb128> !SRU
<ubottu> Stable Release Update information is at https://wiki.ubuntu.com/StableReleaseUpdates
<seb128> unsure what's the tag to ping peoples
<tumbleweed> Laney: you suggested a bileto for bootstrapping, but I think I need some permissions for that?
<tumbleweed> https://bileto.ubuntu.com/#/ticket/3625 didn't get given a PPA
<ahasenack> Skuggen: hi, do you know if {my_,}load_defaults is gone from mysql8? I'm checking net-snmp and it looks like it's using mysql_options() as a replacement of some sort
<ahasenack> infinity: hi, do you remember this apache2 patch? https://git.launchpad.net/ubuntu/+source/apache2/tree/debian/patches/086_svn_cross_compiles
<ahasenack> infinity: I see it applied in apache trunk, but it never made it into a release
<ahasenack> infinity: what was it trying to fix, and is that still relevant?
<ahasenack> it still applies, but with more and more offset everytime, and is part of our delta with debian
<vorlon> alkisg: it is /possible/ to sign the ipxe uefi binary.  But we're not /going/ to, because it increases exposure of our key to use it to sign more code, and we haven't audited this code and don't intend to
<alkisg> vorlon: thank you for that input. Ubuntu users lack a way to netboot with secure boot enabled currently; it would help; but ok, at least I have an official answer for them, "not supported; disable secure boot".
<vorlon> alkisg: we do publish a secureboot-signed grubnetx64.efi for use with netbooting
<alkisg> At least, if grub and shim get fixed for proxydhcp, it'll be possible to use the uefi stack, for some users
<alkisg> It doesn't work with proxydhcp
<vorlon> right
<vorlon> so that's a bug we'll fix in our supported netboot stack
<alkisg> I filed 2 bug reports, both for shim and grub; hopefully they'll be addressed some time in the future
<alkisg> You saw the one for shim, this is the upstream one for grub: https://savannah.gnu.org/bugs/index.php?55636
<alkisg> vorlon: did I understand correctly that it's not possible to dual boot ubuntu/fedora with secure boot enabled, without using mokmanager etc?
<alkisg> I.e. that the canonical shim>grub stack doesn't contain the fedora kernel public keys, and visa-versa?
<alkisg> (I'm not using fedora at all; just trying to see if I understood the secure boot process correctly...)
<vorlon> alkisg: it is certainly possible to dual boot ubuntu and other OSes without using mokmanager; you could chain from Ubuntu's GRUB to a Fedora shim signed by MS, or you could use the EFI boot menu to select.  You could not directly chain from Ubuntu GRUB to a Fedora kernel or to a Fedora GRUB.
#ubuntu-devel 2020-01-27
<Greg_> Not sure if this right place to ask but how can I get yaml-cpp 0.6.0 back ported to trusty in a ppa or whatever for my travis-ci instance?
<seb128> doko, that gobject-introspection upload is a bit unfortunate, it was almost a candidate for migration and now it's back to having 30 lines of regressions to sort out :-(
<seb128> doko, libffi isn't going to migrate any time soon
<ahasenack> rbalint: could I have a quick review please? Our squad is short today: https://code.launchpad.net/~ahasenack/ubuntu/+source/talloc/+git/talloc/+merge/378122
<ahasenack> er
<ahasenack> rbalint: sorry
<ahasenack> the other rb<tab>
<ahasenack> rbasak: ^
<rbasak> Sure
<rbasak> ahasenack: done
<ahasenack> rbasak: thanks
<ahasenack> ah, update-maintainer
<ahasenack> always that
<ahasenack> rbasak: same thing for ldb, if you still have a moment? https://code.launchpad.net/~ahasenack/ubuntu/+source/ldb/+git/ldb/+merge/378136
<rbasak> looking
<rbasak> ahasenack: +1 - MP updated
<ahasenack> thx
<ahasenack> hmpf, I just raced debian and lost
<ahasenack> rbasak: I'm gonna have to rebase on top of https://launchpad.net/ubuntu/+source/ldb/2:2.0.8-1
<rbasak> ahasenack: OK. No need for another review just for that IMHO
<ahasenack> rbasak: ok, thanks
<rbasak> bryce: in the git-ubuntu release process, I'm not sure we need "push a copy of the branch up to launchpad under your own namespace for Continuous Integration (CI) testing". Since the only change is the version string, and we're already running daily CI and only publish from those builds. The only testing I'd be doing is already done by CI anyway. Thoughts on replacing all of that with just "check
<rbasak> that daily CI is already green; if not fix it"?
<ahasenack> it depends on the change you are making, sometimes the release is fix+release, other times it's just bump-version + release like you are doing now
<rbasak> If it's fix+release, then the process will still be the same - do the steps, but you can only proceed if CI passed in the (possibly manually triggered extra) daily to fetch the actual snap for publication.
<rbasak> Either way, I think additional testing is superfluous.
<rbasak> IOW, if we drop the part of the process I'm proposing, a release would still have passed CI before it happens
<bryce> rbasak, in an ideal situation I agree, that's a superfluous check.  But IIRC the reason I added it was because we had some existing build failures in the tree that needed resolved
<bryce> you're right though that those issues are probably spottable looking at the already running daily CI
<bryce> rbasak, if nothing else, that can be marked optional
<rbasak> bryce: OK, thanks. I skipped for now, and I'll make an MP to adjust the notes later
<doko> seb128: you are wrong, your upload didn't even build. https://launchpad.net/ubuntu/+source/gobject-introspection/1.62.0-2ubuntu2
<seb128> doko, that url is an upload from you, https://launchpad.net/ubuntu/+source/gobject-introspection/1.62.0-2ubuntu1 was the previously in proposed one
<seb128> doko, anyway, that just set back the ffi transition and I've no time this week to sort out gobject-introspection problems again :/
<doko> desktop isn't even subscribed to that package
<seb128> well, I tried to be nice and spent some hours tried to get it ready for migration
<seb128> which was wasted/reset back by the new upload :/
<seb128> but it's fine, you can fix it this round :)
<ddstreet> cjwatson i am probably just not finding it, but it seems like the LP api provides no way to reach the signing key for a private ppa that a person is subscribed to (but not part of the private ppa's owner person/team), is that correct?
<cjwatson> ddstreet: The signing_key_fingerprint attribute has somewhat too tight permissions for some reason, but you should be able to use the getSigningKeyData method on such an archive
<ddstreet> yeah, but the archive isn't reachable if you're not part of the team/person that owns the archive
<ddstreet> that's the problem
<cjwatson> ddstreet: The whole archive isn't, but I think that method should be ...
<cjwatson> ddstreet: Well, unless the owning team is itself private
<ddstreet> lp.people(owning_team_name) certainly fails, and i'm trying lp.me.getArchiveSubscriptions() but i can't lp.load() the corresponding subscription's archive_link
<ddstreet> exactly
<ddstreet> that's extremely common, at least for my team's use case of private ppas
<cjwatson> People with a subscription on a private team's private PPA get LimitedView on that private team though, precisely in order to make traversal work
<ddstreet> if the archive_subscriber object provided the signing key fingerprint, that would handle it i think
<cjwatson> Baroque and shouldn't be necessary here
<ddstreet> hmm, it's failing for me
<ddstreet> e.g. i'm subscribed to this ppa https://api.launchpad.net/devel/~canonical-sustaining-merged/+archive/ubuntu/ppa-testing-deletedppa
<ddstreet> but i can't reach the canonical-sustaining-merged team
<ddstreet> maybe it's a bad example though
<ddstreet> it was the first one i found where i'm not part of the private team
<cjwatson> It's 10:26pm here, could you email me please?
<ddstreet> but subscribed to the private ppa
<ddstreet> sure
<cjwatson> With sample code
<cjwatson> Because I just tried it for a private PPA I'm subscribed to where I'm not part of the private team, and it works exactly as I predicted
<cjwatson> lp.load('/~canonical-livepatch/+archive/ubuntu/updates').signing_key_fingerprint â gets me a redacted thing because of the excessively-tight permissions I mentioned
<cjwatson> lp.load('/~canonical-livepatch/+archive/ubuntu/updates').getSigningKeyData() â works
<cjwatson> Also full transcripts, especially including any OOPS IDs that you get
<cjwatson> (because then I can look at tracebacks and see if there's anything interesting in them)
<ddstreet> will do, sorry for the late pings
<cjwatson> no problem - but AFAICS this is probably some special-case oddity rather than it not working in general
<cjwatson> admittedly I have a lot of assorted permissions on things so it can be slightly difficult for me to see sometimes
<ddstreet> it may just be a bad example, i tried canonical-livepatch and it works same as you said; so if you don't see an email from me then it was just my mistake :)
<cjwatson> Oh, so uh
<cjwatson> deletedppa
<cjwatson> Maybe relevant?
<cjwatson> Not sure why the subscription is still listed but the PPA is gone
<cjwatson> So I expect that's all that is
<ddstreet> yep - sorry again for the lateness!
<ddstreet> and thnx for the help
<cjwatson> A bug about deleted archives showing up in your subscriptions would be appreciated though, as that's weird
<ddstreet> ack i'll open that
#ubuntu-devel 2020-01-28
<mwhudson> http://autopkgtest.ubuntu.com/packages/d/docker.io/focal/amd64 <- the failure triggered by containerd/1.3.1-0ubuntu1 doesn't happen locally
<mwhudson> any ideas as to what might be different in the prod infra?
<Tuxist> hi i have problem the python package have been removed from focal so i can't build jackd2 i need to to rebuild to avoid conflicts with pipewire 0.3
<doko> oSoMoN: lo ftbfs in focal with out-of-disk-space
<oSoMoN> uh oh
<oSoMoN> marcustomlinson, you might want to take a look at that one:Â https://launchpad.net/ubuntu/+source/libreoffice/1:6.3.4-0ubuntu2/+build/18611391
<tumbleweed> 41
<eoli3n_> Hi, what's the status of 20.04 dayli builds ? I mean could i start working on migration with it without fear about major changes ?
<eoli3n_> i manage a huge pedagogic config, which require few weeks work to migrate, so, i need to be able to start working as soon as possible
<seb128> eoli3n_, it's a serie being actively being worked  on so new versions/changes are still landing but with proposed-staging the focal archive itself shouldn't see major disruptions hopefully
<eoli3n_> is there a list of these landing modifications?
<juliank> doko: So what do I have to do to get python-apt tests installing deps again? It does not want to install python3-dbg apparently, and then fails
<juliank> Broken python3-apt-dbg:arm64 Depends on python3-dbg:arm64 < 3.7.5-1ubuntu1 -> 3.8.0-3 @ii umU > (< 3.8)
<juliank> Broken python3-dbg:arm64 Depends on libpython3-dbg:arm64 < 3.7.5-1ubuntu1 | 3.8.0-3 @ii umH > (= 3.8.0-3)
<juliank> Investigating (0) python3-dbg:arm64 < 3.7.5-1ubuntu1 -> 3.8.0-3 @ii umU Ib >
<juliank> Oh, it needs a rebuild
<juliank> It Depends python3-dbg (<< 3.8)
<juliank> but why is it picking python3-dbg from proposed anyway?
<juliank> This only happens on arm64, ppc64el, and s390x
<doko> juliank: no idea why it's arch specific
<juliank> doko: the amd64 one does not even pull in python3-{apt-,}-dbg
<juliank> very odd
<juliank> ah no wrong link
<juliank> Get:27 http://ftpmaster.internal/ubuntu focal/main amd64 python3-dbg amd64 3.7.5-1ubuntu1 [1352 B]
<juliank> amd64 correctly pulled from release pocket
<juliank> For some reason, python3-dbg is pulled from proposed on arm64/ppc64el/s390x
<juliank> ah no, on ppc64el it fails because pep8 went away
<juliank> Let's sync python-apt 1.9.5 seems
<juliank> I never synced that
<juliank> Odd
<doko> tkamppeter: please could you have a look at hplib ftbfs with python3.8?
<AsciiWolf> tsimonq2, hi, would it be possible to upgrade the steam package in Focal, as I wrote in email I sent you, or drop the package completely (and add to sync blacklist)?
<AsciiWolf> the outdated two years old version that is still in latest Ubuntu Focal is will be a disaster for users when Ubuntu 20.04 is released... it has many issues (as I wrote in the email), bad udev rules, conflicts with the Valve provided package etc.
<AsciiWolf> tsimonq2, all these issues are fixed in the latest Debian version of steam/steam-devices, but it is not possible to auto sync the package because of changes you made two years ago
<tkamppeter> doko, I will have a look at the HPLIP.
<tkamppeter> Anyone here expert in JDK? JDK blocks CUPS in focal-proposed and it looks like not caused by CUPS. CUPS got a small change and in JDK 100s of tests are failing.
<tkamppeter> Only on ARM processors.
<doko> tkamppeter: please ask tdaitx
<tkamppeter> tdaitx, are you here?
<juliank> AsciiWolf: Just because he merged that two years ago should not be taken as a comittment to the package.
<juliank> You're basically telling anyone who'd be willing to merge it to not do it because you'll be bothering them with it for years to come
<rbasak> paride: could I have a couple of quick reviews please? https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/378155 and https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/378156. They're trivial but maybe just not quite at self-approve level.
<paride> rbasak, sure
<rbasak> I am assuming these will fix CI - I thought it easier to wait for CI than to jump through the necessary hoops to test locally
<rbasak> Thank you!
<paride> rbasak, added approve comments; I don't have permissions to change the MP status
<paride> yw :)
<rbasak> I'll wait for expected CI results before merging
<rbasak> lazr.restfulclient's release timing perfectly aligned with my attempt to release git-ubuntu: CI went red right in the middle :-/
<rbasak> Ideally I would be able to release using the state of things the day before yesterday, but apparently the pin wasn't completely successful anyway
<cjwatson> rbasak: How did the lazr.restfulclient change break you?  Just the bare fact of a new release existing?
<cjwatson> I'm surprised the actual change would have affected anything other than Launchpad itself
<rbasak> cjwatson: just the bare fact of a new release existing
<rbasak> We have pins in setup.py, which was possibly a bad idea. We're generally dropping those pins where possible.
<tkamppeter> tdaitx, I have a JDK problem.
<rbasak> However if a new release exists and we're pinning an older version, something is bad in our snap build and creates a conflict - so the pin doesn't fully work
<cjwatson> Ah.  Odd that a pin wouldn't have carried on working though.
<rbasak> More recently we actually test such a mismatch, which causes CI to fail
<rbasak> Yeah - the pinning we're doing is broken
<enyc> paride: i wish to be nosey and ask if you are named after parallel-port-ide driver =)
<paride> enyc, 'paride' this is my real name and I was born before Linux, so I can exclude it :P this is the second time in my life I get asked
<enyc> ok =)
<enyc> paride: people ask me how to pronounce 'enyc' and I tell them my official answer is you are supposed to store the pattern of letters in your visual-memory and its' not supposed to be pronounced ;p
<tkamppeter> doko, I cannot reproduce the FTBFS of HPLIP on my focal. Evsn if I install python3.8-dev there, I cannot uninstall python-3,7-dev and HPLIP always uses python3.7-dev.
<tribaal> ahasenack: coming back to the kitty discussion, it seems kitty comes with a bit of a workaround for that problem in the form of the "ssh kitten": from a kitty terminal, "kitty +kitten ssh <whatever SSH options you need>" will solve the problem by copying the appropriate terminfo on the remote host for you (in ~/.terminfo/)
<ahasenack> yuck, why is its terminfo so special?
<tribaal> I have no idea.
<ahasenack> 2020 and backspace still frustrating users :)
<tribaal> I know right :)
<eoli3n_> any chance to have netinst in daylibuilds for 20.04 ?
<eoli3n_> to be able to automate my install/tests with "kickstart"
<tribaal> ahasenack: a secondary question would be "why is kitty's terminfo not upstreamed". Assuming it needs to be different for some reason.
<doko> seb128: the pango1.0 sync from experimental breaks https://launchpadlibrarian.net/462042991/buildlog_ubuntu-focal-amd64.pyferret_7.5.0-2build1_BUILDING.txt.gz
<seb128> doko, I guess pyferret needs to be fixed then
<tkamppeter> doko, I cannot reproduce the FTBFS of HPLIP on my focal. Evsn if I install python3.8-dev there, I cannot uninstall python-3,7-dev and HPLIP always uses python3.7-dev.
<doko> tkamppeter: do you have -proposed enabled?
<tkamppeter> doko, no, perhaps I should do so.
<seb128> doko, you might give a try to https://github.com/NOAA-PMEL/PyFerret/commit/104eecc6 ?
<seb128> doko, though that commit is for mac but maybe something similar is needed on linux now
<tkamppeter> doko, I will try with my other VM later.
<tkamppeter> doko, currently there is no desktop for me in Focal, also on the clean VM, so I need to find out how to add proposed by command line.
<AsciiWolf> juliank, sorry, I overlooked your reply to my comment regarding the outdated steam package
<doko> seb128: same build error
<seb128> doko, k, I don't know then, sorry
<AsciiWolf> juliank, what is the right approach to do then? I was told on this channel that this should be addressed by tsimonq2 since he is the one who blocked auto sync of the steam package because of the changes he made
<AsciiWolf> are there any exact steps that I should do in order to help with the steam package update?
<juliank> AsciiWolf: That's not really true, the changes were made earlier
<AsciiWolf> juliank, ah, I did not know this
<AsciiWolf> anyway, should I create a Launchpad ticket for this or are there any other steps?
<AsciiWolf> juliank, I have created a Launchpad ticket: https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1861112
<ubottu> Launchpad bug 1861112 in steam (Ubuntu) "Steam package is outdated" [Undecided,New]
<doko> seb128: beancount has a sourceful upload with a buildN number. are you working on that?
<AsciiWolf> feel free to let me know if there is anything I can do from my side, my intention was to help users, not to bother Ubuntu devs/package maintainers, sorry for that :)
<juliank> AsciiWolf: And I marked it as a duplicate of bug 1796464
<ubottu> bug 1796464 in steam (Ubuntu) "Merge steam 1.0.0.61-2 from Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1796464
<AsciiWolf> juliank, oops! I did not notice that one
<juliank> My understanding is that steam would have to be remade into an amd64 package depending on the i386 libraries, but I might be wrong
<seb128> doko, no, what work is needed? the build version was because the fix is in the packaging vcs in debian so the next upload can be autosynced
<doko> well, it ftbfs
<seb128> right, that's another issue than the version :p
<seb128> but no, I'm not actively working on that one
<seb128> had to move back to do other work so I don't have much time for proposed issue atm
<ahasenack> rbasak: when/if you have a moment, if you could give me a hint as to what is blocking pacemaker in excuses
<ahasenack> A search for "Trying easy from autohinter.*pacemaker" doens't show anything
<ahasenack> and its "trying: pacemaker" seems to only list its own packages
<ahasenack> rbasak: I mean in terms of running your script
<ahasenack> ah, I may have gotten something
<rbasak> Let me know if you'd like me to look
<ahasenack> ok
<ahasenack> need to get rid of the br mirror for these checks
<ahasenack> it's deep
<ahasenack> hmm, libffi6 vs libffi7
<ahasenack> it's entangled with the python 3.8 migration
<ahasenack> something like pacemaker -> pacemaker-resource-agents -> resource-agents -> cluster-glue -> python3.8 -> libpython3.8-stdlib
<ahasenack> where the new libpython3.8-stdlib is linked with libffi7, and the one in the release pocket is linked with libffi6
<tkamppeter> tdaitx, around?
<eoli3n_> 133709    eoli3n_ | any chance to have netinst in daylibuilds for 20.04 ?
<tumbleweed> eoli3n_: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/images/netboot/mini.iso
<eoli3n_> thx tumbleweed
<cpaelzer> doko: the ruby guy to talk to is => kanashiro
<tdaitx> tkamppeter: I will submit a request to ignore openjdk autopkgtest failures
<tkamppeter> tdaitx, muito obrigado.
<tdaitx> vorlon: doko: please review https://code.launchpad.net/~tdaitx/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/378183 to blacklist openjdk-13 and openjdk-14 on armhf/arm64 as well as add them to the big package list (they pass most of the time, but barely)
<tdaitx> tkamppeter: ^ this should also fix openjdk-13 and openjdk-14 blocking your updates
<tkamppeter> tdaitx, muito obrigado
<tkamppeter> tdaitx, vorlon, doko, I had already done a retry on all the four and one passed the retry, the other 3 failed again.
<gpiccoli> Hi vorlon, may I ask you to review/merge a britney MR regarding makedumpfile? We have consistent failures in ppc64el, which are being investigated by cascardo (the maintainer) and I; also, this time we had an i386 failure in eoan - mismatch arch from kexec-tools (i386) with kernel (amd64)
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-eoan/+merge/378195
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/378193
<gpiccoli> Those are the MRs - tnx in advance
<gpiccoli> This time the fixes are somewhat critical, if we could speed the release to -updates, I'd double-appreciate =)
<gpiccoli> mfo, for reference, those are the MRs ^
 * gpiccoli thinks the right term is merge proposal (MP) instead of merge request (MR), but anyway...
<mfo> gpiccoli, thx!
<vorlon> tdaitx: the package should be added to either the blacklist or the big_packages list, not both
<vorlon> tdaitx: (since 'blacklist' means it will not be run at all)
<gpiccoli> sorry vorlon, forgot Xenial hehe - here it is: https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-xenial/+merge/378197
 * gpiccoli leaving, back tmrw o/
<ahasenack> doko: if you are still around, I'm troubleshooting sssd's ftbfs with py3.8. I see python3.8-config --ldflags returning these -L components:
<ahasenack> -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -L/usr/lib
<ahasenack> that doesn't look like the usual /usr/lib/x86-64/ I was expecting
<ahasenack> is this correct?
<ahasenack> furthermore, we don't usually have devel libraries in just /usr/lib
<ahasenack> I see the same with python3.7-config, though
<tdaitx> vorlon: well, I expect we will be removing it from the blacklist in the future, but I will ammend the merge to remove them from the big package list for armhf and arm64 then
<tdaitx> vorlon: btw, when you said "the package should be added to either the blacklist or the big_packages list, not both", do you mean my particular case with openjdk-13 and openjdk-14 or in general?
<tdaitx> because big package does not care for release, while the blacklist does, so I understand them to be ortogonal (and while one can blacklist a package for all releases, after a new devel series is opened the big package setting would take effect)
<tdaitx> I am not complaining, just trying to understand the logic behind it =)
<vorlon> gpiccoli: the xenial one appears to be unnecessary, any failures there are not being shown as regressions
<tdaitx> vorlon: btw, while I am at it, should I remove the blacklisted distro entries for openjdk-lts as well?
<vorlon> tdaitx: do you mean the disco ones?
<tdaitx> indeed
<vorlon> tdaitx: yes please
<vorlon> tdaitx: and I mean in general, if we're saying that a package is going in the blacklist for an arch, there's no reason to add it to the big_packages list at the same time
<tdaitx> vorlon: thanks for the pointers, the merge has been updated: https://code.launchpad.net/~tdaitx/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/378183
<ahasenack> are build(ers) somewhat stuck?
<cjwatson> Yes, waiting for a sysadmin to show up
<ahasenack> https://launchpad.net/ubuntu/+source/shadowsocks-libev/3.3.4+ds-1ubuntu1 uploaded 1h ago, and hasn't started yet
<cjwatson> See #launchpad-ops internal
<ahasenack> ah
<cjwatson> ahasenack: recovering now
<ahasenack> yay
<ahasenack> thanks
<tdaitx> vorlon: thanks for helping with the review =)
<murthy> I have build a deb for a pulseaudio module, but I need to change the rpath/runpath for it should I change it in cmake or in debian/ ?
<murthy> I am a noob
<seb128> tdaitx, vorlon, is there anything needed to make the openjdk blacklisted autopkgtest ignored for proposed migration?
<seb128> cups (2.3.1-1ubuntu1 to 2.3.1-2) in proposed for 1 day
<seb128>     Regressions
<seb128>         openjdk-13/blacklisted: armhf (log, history)
<seb128> like that one
#ubuntu-devel 2020-01-29
<ryanakca> Could someone please sync opensmtpd from Debian unstable? I just uploaded 6.6.2p1-1 that fixes some major security issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950121 (not yet reported in Ubuntu)
<ubottu> Debian bug 950121 in opensmtpd "opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS" [Critical,Fixed]
<cjwatson> ryanakca: It'll auto-sync
<cjwatson> Just about as quickly as anyone might be able to do it manually
<ryanakca> Thanks! I filed a bug, but I don't remember how to use launchpad well enough to mark that it applies to versions of opensmtpd in current/past ubuntu releases.
<vorlon> tdaitx: right, 'blacklist' means that autopkgtest won't attempt to run the tests at all, but it doesn't stop proposed-migration from expecting test results
<Tuxist> i have problem with my ppa the won't build the i386 packages of pipewire but i need for test i386 applications
<Tuxist> https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster
<seb128> bdmurray, hey, can you/someone from foundation fix ubuntu-release-upgrader autopkgtests to stop depending on pep8 which has been removed from the archive?
<doko> tkamppeter: https://launchpad.net/ubuntu/+source/hplip/3.19.12+dfsg0-3ubuntu1 untested
<cpaelzer> doko: FYI py3.8 fix for crmsh inbount - upstream accepted my fix and I'm prepping something for focal now
<cpaelzer> lol, obviously inbount->inbound
<amitprakash> How do I package a custom build of kernel for PPA? Speficially, the kernel is built for a single set of hardware and includes firmware blobs
<amitprakash> It also has no initrd/initramfs support
<cjwatson> Tuxist: We'd need to fix https://bugs.launchpad.net/launchpad/+bug/1855069 first before you can do that
<ubottu> Launchpad bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New]
<cjwatson> (not completely obvious)
<gpiccoli> Tnx vorlon, for the heads-up about xenial and for the releases =)
<Tuxist> cjwatson: yes i will recommend to build pipewire also in ubuntu with i386 because in 0.3 are wrapper libs for jack and pulseadio
<cjwatson> Tuxist: See https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598
<cjwatson> (I can't add things off my own bat)
<seb128> Laney, juliank, do you know what needs to be done there,
<seb128> cups (2.3.1-1ubuntu1 to 2.3.1-2) in proposed for 2 days
<seb128>     Regressions
<seb128>         openjdk-13/blacklisted: armhf (log, history)
<seb128> unsure what the blacklisted is about?
<Laney> tdaitx added it, don't know why I'm afraid
<seb128> but should proposed-migration block on blacklisted tests?
<Laney> depends why the blacklist was put into place
<Laney> the release team can hint them as they can for any other test
<seb128> tdaitx, ^ can you help with that one?
<tkamppeter> tdaitx, hi
<Laney> so if it's appropriate to ignore it, a force-badtest for this package with a version of 'blacklisted' would work
<seb128> tkamppeter, read backlog if you are about the ask the same question :)
<seb128> Laney, k, I guess I don't understnad what blacklist is about ... is that similar to badtest but not even trying to not waste infra resources?
<Laney> it means do not run this test
<Laney> like if it misbehaves in some way that breaks things on the test runners
<Laney> or hits a bug
<tkamppeter> Yes, it was exactly what I wanted to ask about, too.
<seb128> Laney, is there any case where we want to not ignore results of a blacklisted test? I mean if it's blacklisted it seems to not be tried so it can't have green results?
<tkamppeter> What we need (and what was probably intended) for CUPS is to ignore the openjdk tests and pass independent of them, best not even trigger tem.
<Laney> It might be blacklisted only temporarily while the problem is investigated
<seb128> I see
<seb128> let's wait for tdaitx
<tkamppeter> But should CUPS be held up during these investigations?
<Laney> Imagine if you upload a new version of something and it breaks in a way that requires the blacklist
<Laney> You would not want to let that slide in without actually investigating
<tkamppeter> It is 9:28am in Brazil, so tdaitx should appear soon.
<Laney> Sure, we can probably stop highlighting him now :-)
<tdaitx> tkamppeter: seb128: I'm not entirely sure if openjdk-13 and openjdk-14 should block anything, our supported versions are openjdk-8 and openjdk-lts... doko, any opinion on that?
<tdaitx> that said, vorlon reminded me last night that blacklisting the autopkgtests won't deal with britney blocking stuff in proposed, so I will send a merge proposal to hint the armhf failures
<amitprakash> How do I package a custom build of kernel for PPA? Speficially, the kernel is built for a single set of hardware and includes firmware blobs? It also has no initrd/initramfs support
<seb128> tdaitx, thx
<amitprakash> I tried uploading via make deb-pkg but that fails on uploading to ppa w/  " Source/binary (i.e. mixed) uploads are not allowed."
<Laney> tdaitx: arm64 too
<tdaitx> yeah, that on as well
<Laney> your hint could probably just be openjdk-13/blacklisted openjdk-14/blacklisted
<tdaitx> interesting, I will take a look at that
<Laney> I think - there's one for stress-ng that is like that
 * Laney checks the code though
<tdaitx> there's a stress-ng/blacklisted
<tdaitx> good to learn it exists =)
<Laney> yeah should work, there's even a testcase in proposed-migration for this one
<tdaitx> Laney: many thanks for the pointer on this =)
<tjaalton> running a s390x qemu instance on eoan seems to fail, how to debug that?
<tjaalton> virt-manager says it's crashing, doing the same on a shell does nothing
<xnox> tjaalton:  is your host s390x? did you enable kvm?
<tjaalton> no
<rbasak> List moderation for ubuntu-devel-announce@ please
<tjaalton> amd64 laptop, I have kvm enabled for other machines
<rbasak> (in the next day is fine)
<cjwatson> rbasak: done
<rbasak> Thank you!
<tdaitx> vorlon: does the following hinting seems sane to you: https://code.launchpad.net/~tdaitx/britney/openjdk-update-badtest/+merge/378261 ?
<cpaelzer> tjaalton: s390x emulation isn't complete
<cpaelzer> tjaalton: we almost made it to be complete but then we bumped the ALS for 20.04
<cpaelzer> so again we can't run it in emulation
<cpaelzer> TL;DR you need a s390x host and --enable-kvm to run Ubuntu
<cpaelzer> or a rather old guest that doesn't use any new instructions
<cpaelzer> rbasak: what have I done to uvtool ? https://paste.ubuntu.com/p/ZNvBnB8jhn/
<cpaelzer> I get this when calling it to sync an image
<seb128> hum, does anyone know about netplan here? where does it write nm configs when you doa  "netplan apply" and a config in /etc/netplan with renderer: NetworkManager?
<seb128> does it write a .conf for nm on disk or just apply config 'on the fly'?
<seb128> --debug doesn't print any debug :/
<tjaalton> cpaelzer: ah ok
<tjaalton> pity
<xnox> tjaalton:  or just launch s390x kvm in canonistack bos02
<xnox> tjaalton:  you should have access to that, to simply launch an s390x VM
<cpaelzer> yep, for debugging that is the best way I guess
<tjaalton> ok, I'll check out
<tjaalton> though I can only find bos01 on the wiki
<tjaalton> I've never used either
<cpaelzer> rbasak: just running "uvt-simplestreams-libvirt query" triggers the same
<ahasenack> seb128: I think with NetworkManager it does nothing, and leaves it up to NM itself?
<cpaelzer> rbasak: so I guess I have corrupted the pool or something ?!
<cpaelzer> ahasenack: there is NM support for netplan coming, I just don't know in which state it is right now in general and even less on the particular system seb128 has
<ahasenack> seb128: https://netplan.io/examples#using-network-manager-as-a-renderer
<ahasenack> it's not clear if you *can* configure some aspects and leave the rest to NetworkManager, of, if using NM, *all* is left up to NM
<rbasak> cpaelzer: check /var/lib/uvtool/libvirt/metadata/
<seb128> ahasenack, thanks, poking a bit around that generates a .nmconnection in  /run/NetworkManager/system-connections
<rbasak> That should contain json files with base64 encoded names
<rbasak> One of them presumably isn't parsing
<cpaelzer> rbasak: three files, one is zero size
<seb128> ahasenack, I think I've enough to poke a bit more now (trying to figure out the netplan autopkgtest failure in focal)
<cpaelzer> out of space maybe?
<ahasenack> I think it supports a mix
<cpaelzer> rbasak: not out of space
<rbasak> I'm not sure what bug might cause that
<cpaelzer> rbasak: can I just remove the zero byte file there?
<ahasenack> I'm going over https://netplan.io/reference and every now and then it says something like "With NM rendered, this option is ignored", or "With NM, this options does foo"
<rbasak> But if you remove the file it should be safe
<rbasak> uvtool will just consider the corresponding image to not be synced
<rbasak> I'm not sure what might happen if it tries to resync the same image though if it exists in the volume storage pool
<rbasak> But we can deal with that if it happens
<cpaelzer> rbasak: virsh vol-list uvtool lists 6 entries
<cpaelzer> rbasak: but I have 3 on disk and as I said one of them empty
<cpaelzer> maybe I should purge ...
<rbasak> purge will clean up, sure
<rbasak> It is however normal to have more images in the pool than json metadata entries
<cpaelzer> rbasak: purge worked
<rbasak> If for example an image is expired or replaced but there are still VMs that use it as a backing store
<amitprakash> How do I push a custom kernel to launchpad (no modules, firmware blobs added, no initramfs)
<cpaelzer> things are good again
<cpaelzer> rbasak: and I can re-sync I guess
<rbasak> Yep
<cpaelzer> if it happens again I need to trace it down more in depth
<cpaelzer> thanks rbasak
<amitprakash> Currently, I get a rejection w/ "Source/binary (i.e. mixed) uploads are not allowed."
<seb128> ahasenack, right, I'm not going to manage a system, just to debug the tests which worked with the previous n-m version, I think I figured out enough of how the config is generated now so I can look into what's wrong, thanks for the pointers/replies!
<cjwatson> amitprakash: Launchpad will only ever accept source-only uploads, so you must ensure that your upload is a *_source.changes file that only contains a source package, no .debs etc.  However I can't help with the specific details of how to do that for a custom kernel.  Perhaps #ubuntu-kernel can.
<amitprakash> ty cjwatson
<doko> jamespage: can we remove octopussy? uploaded by you in 2012 ... only rdep for syslog-ng which I would like to remove too, or at least demote to proposed
<doko> cpaelzer, mwhudson: fyi, https://bugs.debian.org/950141
<ubottu> Debian bug 950141 in src:rdkit "rdkit downloads additional files during the build" [Serious,Open]
<cpaelzer> ahasenack: FYI ^^ rdkit
<ahasenack> lovely
<doko> ahasenack: my merge attempt is in ppa:doko/toolchain
<ahasenack> ok
<cpaelzer> ahasenack: got the sssd MP done
<cpaelzer> ahasenack: in case you want to upload before you leave
<tkamppeter> tdaitx, Laney, seb128, thanks. Currently CUPS still shows blocked on the blacklisted JDKs. Or does it still take time to take effect?
<Laney> You need to wait for proposed-migration to run
<tdaitx> tkamppeter: top of update excuses says "Generated: 2020.01.29 15:26:02 +0000" and the hinting was merged less than 30 minutes ago
<tkamppeter> tdaitx, OK, obrigado.
<rbasak> bryce: it looks like git-ubuntu 0.7.4 never got released to the stable channel
<rbasak> So I'll push 0.9.1 to all channels now.
<Tuxist> i have new jack package that solves problems with pipewire https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster/+packages
<Eickmeyer[m]> Laney: You around? We have some systemd questions in #ubuntustudio-devel. (anyone else who might know some systemd stuff can join too)
<Laney> Eickmeyer[m]: ok, don't eat me though
<Eickmeyer[m]> Laney: We won't eat you. We're just having trouble with some user-level autostart stuff.
<bryce> rbasak, sounds good
<vorlon> tdaitx: fyi when we have a new version of a package in -proposed that needs a badtest hint, we add both versions rather than replacing the release version w/ the proposed version, so that packages that already ran their tests against the release version don't become newly blocked (openjdk-lts)
<dannf> seb128: alsa-utils is uninstallable in focal due to a versioned Breaks in libasound2 - are you working on an alsa-utils merge? if not, i can take a look
<joelkraehemann> hi all
<ahasenack> cpaelzer: thanks (sssd)
<tdaitx> vorlon: ack, sorry for that, should have realized it was best to leave it there for a while
<bdmurray> seb128: I'm out today but will get someone to look at it
<teward> does anyone know if the PPA builders still build for Trusty or if that was disabled when it EOL'd?  Related to a question/discussion in -packaging
<tumbleweed> they'll still build for trusty
<dannf> bdmurray: looks like juliank brought back the pep8 transition package - and meanwhile juliank and i had transitioned a few packages over anyway
<seb128> bdmurray, hey, it got resolved since I pinged you, so you can forget about it :)
<seb128> dannf, doko did that alsa-lib update so I guess he's working on updating the things that need to be updated with it, maybe check with him?
<dannf> seb128: ack. doko ^. fyi, i've got a complete merge prepared, just about to test it
<juliank> dannf: yeah, it's a bit too annoying for the python3.8 transition at the same time
<juliank> dannf: Because now you fix a package, than its rdeps start failing, and it's becoming a mess
<juliank> dannf: So doko suggested it'd be easier to just bring it back, we can fix things once the archive calms down
<dannf> juliank: well, and we probably should keep the transition till after focal for upgrades anyway
<juliank> Well, bionic's shipping pycodestyle, so it does not affect bionic -> focal upgrades
<dannf> oh - ok
 * dannf just learned about the rename yesterday, didn't realize it was that long ago :)
<dannf> juliank: btw - we did our changes subtly different - i also renamed the test_pep8 to test_pycodestyle & search/replaced the files. do you want me to do the same for update-notifier for consistency?
<juliank> heh, I made the change the same way I did it in python-apt
<juliank> But yeah, you can do that if you like
<juliank> I probably should rename the file in python-apt too, but I'm not sure I can be bothered
<dannf> ack
<techalchemy> juliank, I have a branch atm that changes to pybuild + setuptools + flake8 and already included the mentioned search&replace (though it likely does belong in it's own merge equest)
<techalchemy> I think i have everything going to the right places now, but tbh i am by no means an expert at pybuild so it might be a very wrong approach
<seb128> dannf, thx for the alsa-utils merge, do you plan to do alsa-plugins as well?
<dannf> seb128: i hadn't planned to, but i can change that :)
<seb128> dannf, I wouldn't say no if you want to do, usually the alsa set should be updated together
<seb128> unsure why doko synced the new -lib only :/
#ubuntu-devel 2020-01-30
<mwhudson> sarnold: whee subiquity bugs with apport data!
<cpaelzer> according to https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867 there should be a nmap-dbgsym
<cpaelzer> I can see other dbgsym packages so ddebs are set up
<cpaelzer> but I can't find nmap-dbgsym in focal
<cpaelzer> could someone cross check this on another system so that I know it is just me ?
<cpaelzer> second focal container, same behavior ...
<cpaelzer> this isn't like just build to be populating the archive just now (from 2019-11-08)
<cpaelzer> the direct link from the build info works https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867/+files/nmap-dbgsym_7.80+dfsg1-2_amd64.ddeb
<cpaelzer> but why can't I see it in ddebs
<cpaelzer> any hints appreciated if later one someone can take a look if it affects others as well
<seb128> cpaelzer, hey. I'm trying to remember the details but basically the ddeb service is not built in in launchpad, it has a 'collector' job on some machine, it happens sometime that this job get stucked/hit a bug and than ddbes get 'losts'
<cpaelzer> seb128: interesting, what are we supposed to do about it once we find such a case?
<seb128> cpaelzer, I'm trying to remember where the job is and see if I can still ssh/poke to it
<seb128> cpaelzer, but basically it's "find someone who can do that and ask them to look'
<seb128> cpaelzer, and we might need to change uploads for packages which miss a ddeb and where we would like to get one
<cpaelzer> ok, then lets ping the usual suspects who often know more about the secret sauce :-) vorlon apw infinity ^^
<apw> seb128, not thatis true any more, i think ddebs became first class citizens quite some time ago, and now are in the librariant
<seb128> cpaelzer, seems like I'm leaving on outdated info, sorry
<cpaelzer> np
<cpaelzer> I'll file a bug for proper handling
<seb128> apw, good, so how can ddebs get missing in the new world? :)
<cpaelzer> and assign it to archive admins as I think there the evalaution what is going on would start
<apw> seb128, whatspecifically is missing
<seb128> apw,
<seb128> <cpaelzer> according to https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867 there should be a nmap-dbgsym
<seb128>  I can see other dbgsym packages so ddebs are set up
<seb128>  but I can't find nmap-dbgsym in focal
<cpaelzer> yep that summarizes how I found it
<cpaelzer> and it now has a bug https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1861387
<ubottu> Launchpad bug 1861387 in nmap (Ubuntu) "nmap-dbgsym missing in focal" [Undecided,New]
<amitprakash> Hi, bzr builddeb tells me "dpkg-gencontrol: warning: can't parse dependency xyz". What am I doing wrong if xyz is another package?
<cpaelzer> amitprakash: is xyz listed in your packages debian/control and if so might that line have syntax issues?
<amitprakash> cpaelzer: http://paste.ubuntu.com/p/j35rtBH8mN/ this is what my control looks like
<cpaelzer> amitprakash: and xyz really is ...?
<apw> seb128, cpaelzer, ok that ddeb is in main, presumably because its corresponding .deb is in main
<cpaelzer> I can't find it anywhere - what do you mean by "ddeb is in main"?
<apw> or are they, is it just older ones ... did this just move
<apw> http://ddebs.ubuntu.com/pool/main/n/nmap/
<cpaelzer> apw: was demoted in focal
<apw> the previous .ddebs are in main for nmap
<apw> cpaelzer, and how long ago was it demoted?
<cpaelzer> http://ddebs.ubuntu.com/pool/universe/n/nmap/
<cpaelzer> has all some but not the nmap-dbgsym
<apw> if it was a while ago i suspect it is a bug
<cpaelzer> I don't know when it was demoted
<cpaelzer> apw: mid december
<cpaelzer> by this https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=a77db6ce36654e456957034687cd597081c3db2d
<RikMills> fossfreedom: in budgie-tools - debian/tests/control:Depends: pep8
<RikMills> so tests fail, as that transitional is now gone
<cpaelzer> apw: I put the insights above into the bug
<cpaelzer> apw: what would be the next steps to take on this?
<apw> cpaelzer, i've asked on #lauchpad-ops about ot
<cpaelzer> ok, tracking it there
<cpaelzer> thanks!
<amitprakash> cpaelzer: Sorry, xyz are linux-firmware amd64-microcode
<amitprakash> dpkg-gencontrol: warning: can't parse dependency linux-firmware amd64-microcode
<amitprakash> dpkg-gencontrol: error: error occurred while parsing Replaces field: linux-firmware amd64-microcode
<cpaelzer> amitprakash: you are missing a colon
<cpaelzer> Replaces: linux-firmware, amd64-microcode
<cpaelzer> and then maybe run wrap-and-sort
<cpaelzer> that should get you going
<fossfreedom> RikMills: good timing... will be uploading an update tonight so will fix at the same time. Thx
<amitprakash> Ah!, thanks a lot cpaelzer
<seb128> mwhudson, hey, I saw your comment about subiquity report with apport data earlier but didn't see the corresponding context. Could you comment about that on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861082 ?
<ubottu> Launchpad bug 1861082 in apport (Ubuntu) "ubuntu-bug doesn't know how to file bugs against snaps" [Undecided,New]
<cjwatson> nmap> https://launchpad.net/ubuntu/focal/amd64/nmap-dbgsym shows the demotion on 2019-12-17, successful from LP's point of view.  ddeb-retriever must have got confused somehow
<cjwatson> But it shouldn't need reuploads, as LP has the file
<juliank> So something's getting confused in nautilus, udisks2 and snap
<juliank> it shows snap squashfs as volumes in nautilus
<seb128> doko, your alsa-lib sync reverted the '  * Make autopkgtests cross-test-friendly." from Steve and now it's failing i386 autopkgtests
<juliank> or rather the loop devices
<seb128> juliank, when did that start?
<juliank> seb128: I don't know I just saw it today
<juliank> But it could be older
<juliank> seb128: Ah, it's showing deleted snap squashfs files that still have a loop device
<seb128> juliank, how do you end up with deleted squasfs which still have a loop device?
<juliank> I don't know, 5 of them are lxd snaps
<juliank> (of 6)
<juliank> https://paste.ubuntu.com/p/ry5ZKGqxCS/
<GunnarHj> Hey sil2100! Looks like it will be the same disastrous lack of interest in testing the language packs as the last time the Xenial langpacks were updated. :( As regards the script you wrote, will you rely on it this time and update all the languages if nothing abnormal is detected?
<juliank> Probably a snap bug where it failed to losetup -d them
<juliank> Looking at udisksctl dump https://paste.ubuntu.com/p/Dhtrh3VpF3/, those deleted snap devices do not have x-gdu.hide set
<juliank> But I guess it's more of a topic for #snappy
<seb128> right
 * cjwatson takes https://bugs.launchpad.net/ddeb-retriever/+bug/1861387
<ubottu> Launchpad bug 1861387 in ddeb-retriever "nmap-dbgsym missing in focal" [Critical,In progress]
<sil2100> GunnarHj: hey! Yeah, I guess not much interest in translations... I'll check the script results again later and see if it's really safeish or not
<ogra> juliank, i see this all the time in unity7 on my 16.04 laptop ... there they clutter the dock ... one for each lxd update that happened since the last boot
<ogra> i guess there was something sitting on top of the squashfs that lxd added when the saquashfs underneath went away (just guessing though)
<ogra> it only happens for lxd stuff for me though
<juliank> ogra: it's a bug in systemd or libmount, it was said in #snappy
<ogra> well, it is very specific for lxd, i have never seen it with any other snap
<ogra> (and i have a lot of snaps installed here)
<juliank> ogra: Well, my pastebin also mentions telegram snap
<ogra> seems zyga just agreed with me about the backing file being still sitting on top :)
<ogra> oh, right, i also see a telegram mount here today ... (from todays telegram update) !!
<amitprakash> will dh_build invoke make check only if something is built? I am trying to figure out why certain build commands are executed by bzr builddeb
<sdhd-sascha> hi, i just to reinstall my server. Which daily ubuntu20.04 images is useable ?
<sdhd-sascha> Do not need a stable version.
<sdhd-sascha> I'm looking for ubuntu-server image.
<cyphermox> sdhd-sascha: if you want to use 20.04, then you can look at the files in cdimage.ubuntu.com/ubuntu-server for the exact thing you want; but perhaps the best place to discuss that is in #ubuntu-server if you need help
<cyphermox> 20.04 isn't released yet though, so things may break
<sdhd-sascha> cyphermox: thank you. I already tried some images. But no luck. I will ask @ #ubuntu-server
<cyphermox> usually you want daily-live
<cpaelzer> ahasenack: use https://libvirt.org/formatdomain.html#elementsMemory
<doko> tjaalton: could you have a look at https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=amd64&package=sfepy&trigger=python3-defaults%2F3.8.0-3 ? some change in the X stack?
<tjaalton> doko: everything I've uploaded is still stuck in proposed :)
<seb128> doko, unsure what changed with the pygobject update but autopkgtests are unhappy now with 'pytest.c:(.text+0x3c9): undefined reference to `Py_InitializeEx''
<seb128> xnox, do you know what's the issue with software-properties autopkgtes ton armhf? 'The user named '~xnox' has no PPA named 'ubuntu/nonvirt'' ... is that a problem in your ppa? why is the test using a personal ppa? :)
<xnox> seb128:  nonvirt does exist. The point is to test any PPA which has Unicode in the PPA name
<xnox> seb128:  is there a proxy / networking resolution failure on armhf to launchpad api?
<xnox> seb128:  possibly this test can go away, because basically it was crashing under python2 when locale was either unicode or non-unicode one. But it should all work fine under python3, irrespective of the environmnet locale
<seb128> xnox, log is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/s/software-properties/20200130_123908_8f53c@/log.gz , I don't think any obvious infra error
<xnox> seb128:  because obviously the key on my user account is generated with unicode name.
<doko> seb128: I didn't change anything
<seb128> doko, k, unsure what's the issue :/
<doko> that's a Debian import, and I just merged gobject-introspection again becase of the tightened dependencies
<seb128> xnox, maybe just some flakyness, I will retry
<xnox> seb128:  the log looks really odd
<xnox> seb128:  because xnox/nonvirt does exist, and does have things published in focal/armhf..... and yet it did find all other ppa's that i have =/
<xnox> seb128:  do retry, and possibly open a bug report? i think we can drop the test case.... I just don't know how to make it non-remote, as i must try to add a ppa, for which launchpad generated a gpg key with unicode name
<seb128> doko, yeah, it is a bit weird, http://autopkgtest.ubuntu.com/packages/p/pygobject/focal/amd64 it was green before and the diff only has (build-)depends changes
<seb128> xnox, k
<xnox> cause that was a regression that used to crash; got fixed up; and regressed multiple times; hence the autopkgtest
<seb128> I see
<Laney> if that PPA does still exist then it looks like a bug somewhere, either in software-properties or the LP API
<Laney> Team PPA would seem like better practice than a personal one I guess
<cjwatson> xnox: It's a bug in the test.  It should say ppa:xnox/ubuntu/nonvirt, not ppa:~xnox/ubuntu/nonvirt.
<cjwatson> Extra tilde
<apw> i do that about 10 times a year
<seb128> cjwatson, xnox, I think it's rather a bug in the add-apt-repository output I think
<seb128> the test does
<seb128> debian/tests/add-apt-repository:    add-apt-repository ppa:xnox/nonvirt --yes --no-update
<xnox> cjwatson:  oooooh
<Laney> I think add-apt-repository is prefixing the tilde when it wasn't given
<Laney> But it also does accept both forms AFAICS
<seb128> also if that test was buggy it would never work I guess?
<seb128> which isn't the case
<apw> or apt-add-repository changed
<cjwatson> So it could also be a bad response to something like a 503 I guess
<Laney> Then it would have broken with a software-properties upload and remained broken
<Laney> I would guess that it hit some transient problem and handled it badly
<seb128> retry worked, so yeah transition issue...
<tjaalton> doko: I don't have an issue installing python3-sfepy on focal, so I don't see what's the issue with that test
<mdeslaur> cjwatson: any objection to me merging git?
<cjwatson> mdeslaur: none
<mdeslaur> cjwatson: thx
<ahasenack> doko: the fix for the red smbmap under python3-defaults is https://github.com/ShawnDEvans/smbmap/commit/1b126a6bea48c2aa43ed3a8982398cc95c5722b3#diff-e5c95e36134a07972ecaec3a46c62b7b
<ahasenack> I'll try to get to it today (simple one liner, sad to add a delta because of this)
<ahasenack> I pinged the deb maintainer, no response
<ahasenack> I'll propose there first perhaps (salsa)
<doko> ahasenack: https://launchpad.net/ubuntu/+source/smbmap/1.1.0+git20191013-1ubuntu1
<ahasenack> ..and we have the delta :)
<ahasenack> n/m
<doko> sorry
<ahasenack> nothing else about samba/sssd in that list then
<doko> yes, many thanks for tracking that
<ahasenack> np
<Eickmeyer[m]> Anybody here any good with systemd?
<sarnold> mwhudson: I thought you'd like getting a lot more data back out of my install :) I was pretty surprised how many .crash files were left behind thuogh
<sarnold> Eickmeyer[m]: probably best to ask a more specific question.. I'd rate my knowledge at around 5% but that might be the five percent you need, you know? :)
<Eickmeyer[m]> sarnold: Yes, that's true. We're trying to figure out how to autostart a daemon inside the user session. OvenWerks has more details. We've been working on it the past few days in #ubuntustudio-devel.
<sarnold> Eickmeyer[m]: very good question. for some reason systemctl list-units --user and systemctl --user list-units shows all kinds of services that are NOT user services. I'm super-confused..
<Eickmeyer[m]> sarnold: With /etc/xdg/autostart going away (and processes launched from there not closing on session end anyhow), we're trying to figure this out.
<CarlFK> Eickmeyer - you want to start a gui app after the user logs into X/desktop, right ?
<Eickmeyer[m]> CarlFK: Not exactly. It's the daemon part of ubuntustudio-controls.
<CarlFK> Eickmeyer - ok, so start daemon on login?
<Eickmeyer[m]> CarlFK: Yes, and end on logout.
<CarlFK> Eickmeyer - if it makes you feel better, I have been trying to figure out the 'right' way to do this for about a year
<Eickmeyer[m]> CarlFK: While consoling, it's also a bit discouraging.
<gQuigs> sarnold: interestingly they are different lists though.. so it's filtering some...
<sarnold> gQuigs: oh strange
<sarnold> gQuigs: I thought it'd be nice to see just the '*.service' entries and *that* is a lot more like what I expected: systemctl list-units --user '*.service' is a lot more like what I expected!
<sarnold> jeeze
<sarnold> redundancy department of redundancy
<CarlFK> Eickmeyer - current solution "that depends on us tweaking lightdm" https://salsa.debian.org/debconf-video-team/ansible/blob/master/roles/xorg/tasks/lightdm.yml#L23
<tumbleweed> hacky as hell
<gQuigs> indeed.. also just noticed the --type=service option
<tumbleweed> basically, there aren't well-defined targets for this
<Eickmeyer[m]> Very hacky.
<Eickmeyer[m]> So, CarlFK , that tells me it's a problem with lightdm? If we were to, say, switch to sddm would that work?
<CarlFK> Eickmeyer: I would not say the DM is the problem.    I think we are trying to do things that aren't supported, because we are willing to compromise elegance in exchange for.. nice features?
<CarlFK> Eickmeyer: this post is years old, but seems still relevant.  my search in October did not find anything new.   https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg
<Eickmeyer[m]> CarlFK: Thanks, I'll pass that along.
<sil2100> GunnarHj: hey! So uh, hm, my sanity testing suite has a small problem in testing the current situation, so I think I'll have to do some manual checks before deciding if we'll push all of those
<ahasenack> doko: smbmap (1.1.0+git20191013-2) unstable; urgency=medium has the same fix, it can be synced again
#ubuntu-devel 2020-01-31
<alkisg> Hi guys, Ubuntu MATE and Xubuntu 20.04 live CDs login with LANGUAGE=en even if I select Greek in syslinux, which wasn't the case before. Is that a deliberate decision (e.g. due to small translation coverage), or is it a bug and I should look more into it?
<alkisg> Ubuntu (GNOME) is not affected by this
<alkisg> All processes spawned by lightdm and systemd --user, have LANGUAGE=en, while LANGUAGE is unset in their parents, and only LANG=el_US.UTF-8.
<alkisg> So I guess there's now some logic to force-set LANGUAGE, in either lightdm or systemd, that sets it to the wrong value...
<alkisg> This happens only on live CDs and only for specific languages, e.g. greek and arabic but NOT italian, so I'm reluctant to file an issue against lightdm for this
<alkisg> Hmm I guess it happens when the language pack isn't installed, so I guess it's by design somewhere. I'll stop digging, ping me if you think it's a bug after all.
<alkisg> True, got it, Ubuntu specific patch to override locale -a with /usr/share/language-tools/language-options
<alkisg> But this doesn't sound like a good choice for all the flavors except GNOME, as e.g. mate-calc or mate-panel do have their translations outside of the language pack, so it's a pity to have the whole live session untranslated because of that patch
<seb128> alkisg, report a bug? I don't think language-options is meant to not work/create issues for flavors
<alkisg> seb128: where, in language-options that don't list e.g. greek in live cds (maybe that's the correct thing to do), or in lightdm, which uses language options instead of locale -a like upstream does?
<alkisg> The lightdm patch was done in 2014, but language-option behavior changed in 19.10
<alkisg> To be clear: /usr/share/language-tools/language-options doesn't list Greek on live cds, while locale -a does
<seb128> alkisg, that sounds like a bug in the script?
<seb128> Gunnar is the one who knows best about those things but he's not around atm so launchpad bug is best
<alkisg> Thank you seb128, I'll file it under accountsservice then, where that script comes from
<seb128> sounds right
<alkisg> To additionally account for live cds and locale -a
<alkisg> Ty :)
<alkisg> https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1861481
<ubottu> Launchpad bug 1861481 in accountsservice (Ubuntu) "language-options causes live CD sessions to be untranslated" [Undecided,New]
<seb128> alkisg, thx, I triaged it and pinged Gunnar
<alkisg> Thank you again :)
<seb128> np!
#ubuntu-devel 2020-02-01
<xnox> doko:  how does one use ubuntu-archive-tools now that launchpadlib for python2 is removed from the archive, yet ubuntu-archive-tools still has python2 scripts =/
<mitya57> xnox: some scripts may be Python 3 compatible despite having a /usr/bin/python shebang
<xnox> True
#ubuntu-devel 2020-02-02
<doko> jibel: autopilot is bitten by the qt4 removal
<RikMills> doko: something toolchain broken? https://paste.ubuntu.com/p/b7KSzTSVMH/
<doko> RikMills: yes, arm64 and s390x. currently looking
<RikMills> thanks!
<doko> RikMills: requires a gcc-9 build, will take some hours. after that I'm giving back all failed builds on s390x and arm64
<RikMills> doko: right. thanks
